KI und interne Kontrollen: SOX-Aspekte für Finanzteams

Von Jane Ha · Aktualisiert am 11. Oktober 2026

KI und interne Kontrollen ist die Frage, wie sich ein KI-Tool, das die Finanzberichterstattung berührt, in die Kontrollen einfügt, die ein börsennotiertes Unternehmen nach SOX unterhalten muss: wer es verantwortet, was es tun darf, wie sein Ergebnis geprüft wird und welcher Nachweis belegt, dass die Prüfung stattgefunden hat. KI schafft kein neues Regelwerk. Sie fügt einen neuen Akteur hinzu, der schnell, uneinheitlich und schwer erklärbar sein kann, und zwar in einem Kontrollrahmen, der um Menschen und deterministische Systeme herum entworfen wurde.

Dieser Leitfaden richtet sich an Controller, CFOs, SOX-Programmleiter und Finanzmanager, die KI in Prozessen wie Kreditorenbuchhaltung, Bankabstimmung oder Monatsabschluss einführen. Er gehört zur Collection AI for Finance. Beginnen Sie mit KI im Finanz- und Rechnungswesen, wenn Sie zuerst das größere Bild möchten.

Wichtige Fakten

• Die SEC-Regeln verlangen, dass das Management eines Emittenten am Ende jedes Geschäftsjahres das interne Kontrollsystem für die Finanzberichterstattung (ICFR) bewertet, und zwar anhand eines geeigneten, anerkannten Kontrollrahmens, der in einem ordnungsgemäßen Verfahren entstanden ist (17 CFR 240.13a-15).
• PCAOB AS 2201 definiert eine wesentliche Schwäche (Material Weakness) als einen Mangel oder eine Kombination von Mängeln im ICFR, die eine hinreichende Möglichkeit schafft, dass eine wesentliche falsche Darstellung nicht rechtzeitig verhindert oder aufgedeckt wird (PCAOB AS 2201).
• Die COSO-Veröffentlichung vom Februar 2026, Achieving Effective Internal Control Over Generative AI, wendet die fünf Komponenten des Internal Control-Integrated Framework an und ordnet Anwendungsfälle generativer KI acht Fähigkeitstypen zu (Journal of Accountancy).
• In ihrem Spotlight vom Juli 2024 berichteten PCAOB-Mitarbeiter, dass Prüfungsgesellschaften erwarten, generative KI werde Menschen ergänzen, nicht ersetzen, und dass die Gesellschaften die PCAOB-Prüfungsstandards nicht als Hindernis für ihren Einsatz sahen (PCAOB).
• Nach AS 2201 darf ein Prüfer für eine vollständig automatisierte Anwendungskontrolle nur dann „Benchmarking“ einsetzen, wenn die allgemeinen Kontrollen über Programmänderungen, Programmzugriff und Rechenbetrieb wirksam sind und die Kontrolle sich seit der Festlegung der Baseline nicht verändert hat (PCAOB AS 2201).

Warum KI eine SOX-Frage ist und nicht nur eine IT-Frage

SOX Section 404 legt die Verantwortung auf das Management. Die SEC-Regel verlangt, dass das Management das ICFR jedes Jahr anhand eines anerkannten Rahmens bewertet. Das Internal Control-Integrated Framework von COSO ist der Rahmen, den die meisten Finanzteams kennen. Wenn ein KI-Tool einen Buchungssatz vorbereitet, eine Bankzeile zuordnet, eine Offenlegung entwirft oder eine Rechnung klassifiziert, fließt sein Ergebnis in die Finanzberichte, und das Kontrollumfeld darum herum gehört zum Prüfungsumfang.

Das Spotlight der PCAOB-Mitarbeiter ist hier nützlich, weil es beschreibt, was Ersteller bereits berichteten. Einige nutzten generative KI für erste Entwürfe interner Dokumente und für weniger komplexe, repetitive Arbeit wie die Vorbereitung von Kontenabstimmungen. Ersteller wiesen auch auf die „Blackbox“-Natur mancher Tools und auf uneinheitliche Ergebnisse hin, was Fragen zur Prüfbarkeit dessen aufwirft, was das Tool liefert. Und einige Prüfer merkten an, der Einsatz generativer KI durch Ersteller könne bestehende IT-Risiken wie die Funktionstrennung verstärken oder Risiken schaffen, die es zuvor nicht gab.

Diese drei Punkte rahmen den Rest dieses Leitfadens: ein Tool, das für echte Buchhaltungsarbeit eingesetzt wird, Ergebnisse, die variieren, und alte Kontrollrisiken an neuen Stellen.

Wie AS 2201 Technologie behandelt (und warum das für KI zählt)

AS 2201 ist der Standard, dem externe Prüfer bei der Prüfung des ICFR folgen. Drei seiner Ideen bestimmen, wie Prüfer KI betrachten werden.

Ein Top-down-Ansatz. Der Prüfer beginnt auf der Ebene der Finanzberichte und konzentriert sich auf Kontrollen auf Unternehmensebene, bevor er sich zu den wesentlichen Konten und ihren relevanten Aussagen vorarbeitet (PCAOB AS 2201). Ein KI-Tool in einer risikoarmen, nicht finanziellen Ecke des Unternehmens wird womöglich nie getestet. Eines innerhalb eines wesentlichen Kontos wird es.

IT wird nicht getrennt bewertet. Der Standard besagt, der Prüfer solle verstehen, wie die IT den Transaktionsfluss des Unternehmens beeinflusst, und die Identifizierung von Risiken und Kontrollen innerhalb der IT sei „ein integraler Bestandteil des Top-down-Ansatzes“ und keine getrennte Bewertung. Für Sie heißt das: Ein KI-System sollte als Teil des Prozesses bewertet werden, den es unterstützt, nicht in einer isolierten Technologieprüfung.

Automatisierte Kontrollen stützen sich auf allgemeine Kontrollen. AS 2201 sagt, eine automatisierte Kontrolle sei im Allgemeinen risikoärmer, wenn die relevanten IT-General-Controls wirksam sind, und erlaubt Benchmarking vollständig automatisierter Anwendungskontrollen, wenn die Kontrollen zu Programmänderungen, Zugriff und Betrieb halten. Hier wird es bei KI unbequem. Eine herkömmliche automatisierte Kontrolle verhält sich jedes Mal gleich, sodass eine Baseline gültig bleibt, bis jemand den Code ändert. Ein Modell, dessen Verhalten sich mit einem Anbieter-Update, neuen Trainingsdaten oder einem geänderten Prompt verschiebt, gibt dem Prüfer diese Sicherheit nicht. Planen Sie, Modell- und Prompt-Änderungen so zu behandeln wie Code-Änderungen.

Wo KI das Kontrollumfeld berührt

Die COSO-Leitlinien zu generativer KI ordnen Kontrollen den fünf Komponenten des Rahmens zu (Kontrollumfeld, Risikobeurteilung, Kontrollaktivitäten, Information und Kommunikation sowie Überwachung) und gruppieren Anwendungsfälle in acht Fähigkeitstypen: Erfassung, Transformation, Buchung, Orchestrierung, Beurteilung, Überwachung, regulatorische Informationsgewinnung und Mensch-KI-Interaktion (Journal of Accountancy). Die Veröffentlichung enthält für jeden Fähigkeitstyp Beispiele, Mindestanforderungen an Kontrollen und beispielhafte Kennzahlen. COSO hat außerdem frühere ergänzende Leitlinien zu Robotic Process Automation veröffentlicht, die Finanzteams mit älterer Automatisierung parallel lesen können.

Die folgende Tabelle wendet dieses Fähigkeitsdenken auf typische Finanzarbeit an. Sie ist ein Beispiel dafür, wie Sie Ihre eigene Analyse gliedern können, keine Kopie der COSO-Zuordnung.

Die Fragen zum Kontrolldesign, die Sie zu jedem KI-Tool stellen sollten

Wenn ein Tool in einem Finanzprozess landet, stellen Sie dieselben Fragen wie bei jeder Kontrolle, plus einige, die speziell KI betreffen.

1. Welche Rolle hat es: Ersteller, Prüfer oder keines von beidem? Eine KI, die entwirft, ist ein Ersteller. Eine KI, die die Arbeit einer anderen KI prüft, ist im SOX-Sinn keine unabhängige Prüfung, solange nicht ein Mensch das Ergebnis verantwortet.
2. Was prüft der menschliche Prüfer tatsächlich? Eine Kontrolle, die lautet „Controller prüft KI-Ergebnis“, ist schwach, wenn der Prüfer nur eine Zusammenfassung sieht. Legen Sie fest, was er ansieht, welcher Schwellenwert einen genaueren Blick auslöst und was er tut, wenn etwas nicht stimmt.
3. Auf welche Informationen stützt sich die Kontrolle? Wenn die Prüfung eines Prüfers von einem Bericht abhängt, den die KI erstellt hat, gehören Vollständigkeit und Richtigkeit dieses Berichts zur Kontrolle.
4. Ist das Ergebnis reproduzierbar? Wenn dieselbe Eingabe unterschiedliche Ergebnisse liefern kann, sagen Sie das in der Kontrollbeschreibung und gestalten Sie die Prüfung so, dass sie die Schwankung auffängt.
5. Wer kann es ändern? Modelle, Prompts, Retrieval-Quellen und Geschäftsregeln sind Konfiguration. Sie brauchen Verantwortliche und Änderungsprotokolle. Behandeln Sie Prompts, Retrieval-Konnektoren und Transformationsregeln als gesteuerte Konfigurationen.
6. Was passiert, wenn es falsch liegt oder ausfällt? Benennen Sie den manuellen Ausweichprozess und die Person, die das Tool pausieren kann.

IT-General-Controls für KI

IT-General-Controls (ITGC) decken das Umfeld rund um Anwendungen ab: Zugriff, Änderungsmanagement und Betrieb. KI ersetzt sie nicht. Sie dehnt sie.

• Zugriffsmanagement. Begrenzen Sie, wer das Tool nutzen darf, welche Daten es lesen und was es schreiben kann. Ein Servicekonto, das eine Buchung sowohl anlegen als auch freigeben kann, fasst die Funktionstrennung in einer einzigen Zugangsberechtigung zusammen. Das PCAOB-Spotlight hält die Sorge von Prüfern fest, dass KI genau diese Art von Risiko verstärken könnte.
• Änderungsmanagement. Verfolgen Sie Modellversionen, Prompt-Änderungen, Änderungen der Retrieval-Quellen und Anbieter-Updates. Testen Sie vor der Freigabe in einer Nicht-Produktivumgebung. Das PCAOB-Spotlight vermerkt, dass einige Ersteller neue Technologie vor der Einführung in einer Parallelumgebung betreiben, eine bewährte Gewohnheit, die sich auch hier anbietet.
• Betrieb und Überwachung. Protokollieren Sie Eingaben, Ergebnisse und Overrides. Achten Sie auf Drift: Plötzliche Verschiebungen bei Volumen, Beträgen oder Override-Quoten sind frühe Zeichen, dass sich das Verhalten geändert hat.
• Drittanbieter- und Datenrisiko. Wenn ein Anbieter das Modell hostet, verstehen Sie, welche Finanzdaten Ihre Umgebung verlassen und wie der Anbieter damit umgeht. Das Spotlight zeigt Gesellschaften, die begrenzen, was in KI-Tools hochgeladen werden darf, damit vertrauliche Daten nicht öffentlich werden, und Finanzteams brauchen dieselbe Regel für Hauptbuchdaten und Bankinformationen.

Nachweise: Was ein Prüfer sehen will

An den Nachweisen scheitern KI-Projekte häufig, weil das Tool gebaut wird, um Zeit zu sparen, und niemand den Prüfpfad aufbaut. Planen Sie ihn von Anfang an ein. Das Spotlight beschreibt Gesellschaften, die ihre eigenen KI-Tools so entwerfen, dass die zugrunde liegenden Quelldaten dokumentiert werden, und dasselbe Prinzip gilt für Ihre.

Zu den zugrunde liegenden Eingaben behandelt Datenbereitschaft im Finanzwesen die Datenqualität, die jede dieser Kontrollen voraussetzt.

So binden Sie ein KI-Tool in Ihr SOX-Programm ein, Schritt für Schritt

1. Erfassen Sie jeden KI-Einsatz im Finanzbereich. Beziehen Sie Tools ein, die einzelne Teams gekauft haben, und Funktionen, die in bestehenden Systemen eingeschaltet wurden. Halten Sie das Inventar aktuell, denn ständig kommen neue Einsätze hinzu.
2. Stufen Sie nach Auswirkung auf die Finanzberichterstattung ein. Erreicht das Ergebnis ein wesentliches Konto, eine Offenlegung oder eine Schätzung? Tools, bei denen das nicht der Fall ist, können einer leichteren Richtlinie folgen.
3. Benennen Sie für jedes Tool einen Verantwortlichen. Eine benannte Person ist für Umfang, Änderungen und Überwachung zuständig.
4. Dokumentieren Sie Prozess und Kontrolle. Aktualisieren Sie die Prozessbeschreibung und die Risiko-Kontroll-Matrix, sodass sichtbar ist, wo die KI sitzt, was sie tut und wer sie prüft. Seien Sie bei der Prüfung konkret.
5. Trennen Sie Aufgaben. Die KI sollte nicht denselben Vorgang vorbereiten und freigeben, und kein einzelnes Konto sollte beide Rechte haben.
6. Richten Sie die ITGC-Abdeckung ein. Zugriff, Änderungsmanagement, Protokollierung und Anbieterprüfung für das Tool und seine Konfiguration.
7. Testen Sie vor dem Go-live. Fahren Sie einige Zyklen parallel zum bestehenden Prozess und vergleichen Sie Zeile für Zeile. Halten Sie die Ergebnisse als Nachweis fest.
8. Sprechen Sie früh mit Ihrem externen Abschlussprüfer. Teilen Sie das Design, bevor die Kontrolle live geht, nicht erst bei den Walkthroughs zum Jahresende. Zur Sicht der internen Revision siehe KI in der internen Revision.
9. Überwachen und testen Sie erneut. Verfolgen Sie Override-Quoten, Ausnahmen und Genauigkeit. Wiederholen Sie die Tests, wenn sich Modell, Prompt oder Datenquelle ändern.

Häufige Fallstricke

• „Ein Mensch prüft es“ als die Kontrolle behandeln. Ohne definierte Prüfung, Schwellenwert und Protokoll gibt es keine Kontrolle, die sich testen ließe.
• Der KI eine Freigabe überlassen. Die automatische Freigabe einer Buchung durch dasselbe System, das sie vorbereitet hat, ist ein Mangel in der Funktionstrennung, der darauf wartet, gefunden zu werden.
• Konfigurationsänderungen ignorieren. Eine Prompt-Änderung oder ein Modell-Update des Anbieters kann das Verhalten ohne Code-Release und ohne Ticket verändern.
• Kein Inventar. Schatten-KI in einem Finanzteam ist ein Risiko, das Sie nicht bewerten können, wenn Sie nicht wissen, dass es sie gibt.
• Nachweise im Nachhinein. Protokolle und Prüfernotizen lassen sich Monate später nur schwer rekonstruieren. Erfassen Sie sie, während die Kontrolle läuft.
• Annehmen, die Zusicherung des Anbieters decke Sie ab. Ein Anbieterbericht kann helfen, aber Ihre Kontrollen darüber, wie Sie das Tool einsetzen, bleiben Ihre.
• Betrug vergessen. Modelle können missbraucht oder manipuliert werden. In KI-gestützte Betrugserkennung im Finanzwesen sehen Sie, wie KI in beide Richtungen wirkt.
• Ermessensbereiche übersehen. Umsatz und schätzungslastige Bereiche brauchen besondere Sorgfalt; KI bei der Umsatzrealisierung zeigt, wo das Ermessen liegt.

Was Sie messen sollten

• Abdeckung: Anteil der KI-Anwendungsfälle, die inventarisiert, zugewiesen und eingestuft sind.
• Kontrollleistung: von Prüfern gefundene Ausnahmen, Override-Quote und Zeit bis zur Klärung jeder einzelnen.
• Genauigkeit: Fehlerquote gegenüber Quelldokumenten oder Ist-Werten, je Tool.
• Änderungsdisziplin: Änderungen an Modellen, Prompts und Regeln mit Genehmigung gegenüber solchen ohne.
• Nachweisbereitschaft: Anteil der Kontrollen mit vollständigen Protokollen und Freigaben zum Quartalsende.

Wie es weitergeht

Wenn Sie in diesem Quartal nur eines tun, bauen Sie das Inventar auf und stufen Sie jedes Tool danach ein, ob es ein wesentliches Konto erreicht. Verschärfen Sie dann den Prüfschritt für die Tools der höchsten Stufe und beginnen Sie jetzt, Nachweise zu protokollieren. Entscheiden Sie danach, wer welche Kontrolle verantwortet, wenn sich die Arbeit verschiebt, und halten Sie das schriftlich fest.