Zum Inhalt springen
Governance & Compliance

Cert-Ready by Design – Prüfungssichere KI von Anfang an

Cert-Ready by Design bedeutet: Controls sind First-Class-Datenobjekte, Evidence wird automatisch erzeugt, Prüfer sehen Live-Status statt Snapshot. Architektur für ISA, PS 951, IDW, GoB/GoBD.

Gosign GmbH 5 Min. Lesezeit

Das Problem: Prüfungsbereitschaft als Projekt

In den meisten Unternehmen ist die Vorbereitung auf eine Prüfung – Jahresabschlussprüfung, Betriebsprüfung, SOC-2-Audit – ein Projekt. Wochen vor der Prüfung werden Dokumente zusammengestellt, Screenshots angefertigt, Nachweise aus verschiedenen Systemen exportiert und in Ordner sortiert.

Dieses Vorgehen hat drei Probleme: Es ist aufwendig, es ist fehleranfällig und es zeigt einen Snapshot statt eines Zustands. Der Prüfer sieht, wie das System zum Zeitpunkt der Dokumentation aussah – nicht wie es tatsächlich läuft.

Wenn KI-Agenten geschäftskritische Entscheidungen treffen, verschärft sich das Problem. Jede einzelne Agenten-Entscheidung muss nachvollziehbar sein. Bei Tausenden von Entscheidungen pro Monat ist eine manuelle Dokumentation nicht mehr möglich.

Was Cert-Ready by Design bedeutet

Cert-Ready by Design kehrt den Ansatz um: Die Prüfungsbereitschaft ist kein nachträglicher Prozess, sondern ein Architekturprinzip. Controls sind technische Datenobjekte im System. Evidence wird automatisch erzeugt. Prüfer sehen Live-Status statt Snapshot.

Controls als First-Class-Datenobjekte

In der Cert-Ready-Architektur ist jede Kontrolle ein technisches Datenobjekt mit definierten Attributen:

ElementFunktion
Control_IDEindeutige Identifikation der Kontrolle
Technical_ImplementationKonkrete technische Umsetzung (z.B. RLS-Policy, API-Check, Konfidenz-Schwellenwert)
Rule_VersionVersion der zugrunde liegenden Entscheidungslogik
Evidence_GeneratorAutomatischer Prüfmechanismus der Evidence erzeugt
Evidence_HistoryHistorisierte Prüfergebnisse mit Zeitstempel
Auditor_ViewDrill-Down-fähige Darstellung bis zur Implementierung

Controls sind keine Word-Dokumente in einem SharePoint-Ordner. Sie sind technische Objekte die im System leben, automatisch geprüft werden und ihren Status in Echtzeit widerspiegeln.

Automatische Evidence-Generierung

Evidence wird nicht nachträglich zusammengestellt. Sie wird automatisch erzeugt – bei jeder Agenten-Entscheidung, bei jeder Regeländerung, bei jedem Systemereignis.

Ein Beispiel: Der Agent verarbeitet eine Eingangsrechnung. Der Decision Layer wendet Regel SKR03-7890 in Version 4.2 an. Konfidenz: 97%. Ergebnis: Buchungsvorschlag auf Konto 4400, Kostenstelle 1200. Keine Eskalation (Konfidenz über Schwellenwert, Betrag unter Wertgrenze).

Die Evidence für diesen Vorgang wird automatisch erzeugt: Input-Daten, angewandte Regel mit Version, Konfidenzwert, Routing-Entscheidung, Ergebnis, Zeitstempel. Diese Evidence ist unveränderlich und mit dem Buchungsbeleg verknüpft.

Auditor Portal

Prüfer sehen im Auditor Portal den Live-Status aller Controls. Kein PDF-Export, kein Snapshot – sondern den aktuellen Zustand des Systems.

Das Auditor Portal bietet Drill-Down: Von der Control-Übersicht (Ampel-Dashboard: grün/gelb/rot) über die einzelne Kontrolle bis zur konkreten technischen Implementierung und der Evidence-Historie.

Framework-Mapping

Controls werden auf etablierte Prüfungsstandards gemappt:

ISA (International Standards on Auditing): Für Jahresabschlussprüfungen. Die Controls bilden die internen Kontrollen ab, die der Abschlussprüfer im Rahmen seiner Prüfung beurteilt.

PS 951 (IDW): Für IT-Prüfungen. Die technischen Implementierungen der Controls werden auf die Anforderungen des PS 951 gemappt.

GoB/GoBD: Für die Ordnungsmäßigkeit der Buchführung. Die Versionierung der Regelwerke, die Unveränderlichkeit des Audit Trail und die Nachvollziehbarkeit jeder Buchungsentscheidung erfüllen die Anforderungen der GoBD.

Dieses Framework-Mapping stellt sicher, dass die automatisch erzeugte Evidence die Sprache spricht, die Prüfer verstehen.

Cert-Ready in der Praxis

Eine Wirtschaftsprüfungsgesellschaft führt die Jahresabschlussprüfung bei einem Mandanten durch. Der Mandant setzt KI-Agenten für die Belegverarbeitung ein.

Der Prüfer öffnet das Auditor Portal. Er sieht: 12 Controls für die Belegverarbeitung, alle grün. Er klickt auf Control “BV-003: Vollständigkeit der Buchungsbelege”. Er sieht: Die technische Implementierung (API-Check gegen Belegeingang), die aktuelle Regelversion, die Evidence der letzten 12 Monate (alle automatischen Prüfungen bestanden), den Konfidenz-Durchschnitt und die Eskalationsrate.

Er kann Drill-Down machen: Einzelne Belege stichprobenartig prüfen, den Entscheidungspfad nachvollziehen, die angewandte Regel in der zum Entscheidungszeitpunkt gültigen Version einsehen.

Das Ergebnis: Die Prüfung der IT-gestützten Verarbeitung dauert Stunden statt Wochen. Die Evidence ist vollständig, automatisch erzeugt und manipulationssicher.

Mehr dazu: Cert-Ready by Design im Detail

Termin vereinbaren – Wir zeigen Ihnen das Auditor Portal live.

Cert-Ready Audit Controls ISA IDW Governance
Artikel teilen

Häufige Fragen

Was bedeutet Cert-Ready by Design?

Cert-Ready by Design bedeutet, dass Prüfungsbereitschaft kein nachträglicher Prozess ist, sondern ein Architekturprinzip. Controls sind technische Datenobjekte im System, Evidence wird automatisch erzeugt, und Prüfer sehen Live-Status statt nachträglich zusammengestellte Dokumentation.

Was ist ein Control Object?

Ein Control Object ist ein technisches Datenobjekt das eine Kontrolle repräsentiert. Es enthält: Control_ID, Technical_Implementation, Rule_Version, Evidence_Generator, Evidence_History und Auditor_View.

Welche Prüfungsstandards werden abgedeckt?

Das Framework-Mapping bildet Controls auf ISA (International Standards on Auditing), PS 951 (IDW-Prüfungsstandard für IT-Prüfungen), IDW-Standards und GoB/GoBD ab.

Welcher Prozess soll Ihr erster Agent übernehmen?

Sprechen Sie mit uns über einen konkreten Use Case.

Termin vereinbaren