Kapitel 14 · Governance, Audit und Vertrauen
Was wir in diesem Kapitel diskutieren: Prüfbarkeit und Souveränität wandeln sich von nachgelagerten Dokumentationspflichten zu genuinen Architektureigenschaften: Wer sein organisationales Selbstwissen governt, versioniert und maschinenlesbar führt, erzeugt geforderte Nachweise fortlaufend im Betrieb anstatt hektisch vor dem Stichtag. Einordnung der KI-Prüfarchitektur A5 sowie des Souveränitäts-Vorschlags CADA von der Alltagsebene zur Konzeptebene.
Dein Hebel als Entscheider: Die Frage "Können Sie jederzeit lückenlos belegen, warum Ihre digitalen Systeme genau so entscheiden, wie sie es tun?" wird Dir von Wirtschaftsprüfern, Kunden und Aufsichtsbehörden gestellt werden, unabhängig vom Schicksal einzelner Gesetzesinitiativen. Organisationen, deren Nachweise als lebender Datenbestand im Betrieb mitlaufen, beantworten diese Frage beiläufig; alle anderen starten vor jeder Prüfung eine zeitraubende Manufakturarbeit. Der physische Rechenort Deines konsolidierten Selbstwissens bildet dabei einen zentralen Teil Deiner strategischen Antwort.
Dieses Kapitel folgt konsequent einer klaren Dramaturgie. Jeder Hauptabschnitt setzt auf der Ebene der betrieblichen Alltagserfahrung an (warum das Thema das Risikomanagement jedes Vorstands berührt) und steigt erst im zweiten Schritt auf die konzeptionelle Ebene auf. Auf dieser Konzeptebene beantwortet der Text stets dieselbe entscheidende Frage: Warum stellt eine governte, maschinenlesbare Ontologie den einzig tragfähigen Weg dar, um diese Prüfanforderungen zu erfüllen, und warum lässt sich dieser Weg erst heute wirtschaftlich beschreiten?
14.1 Vertrauen wird zum Prüfgegenstand
Beginnen wir auf der Ebene der betrieblichen Alltagserfahrung. Wenn ein Wirtschaftsprüfer heute die Bilanz Deines Unternehmens testiert, verlässt er sich keineswegs auf Dein mündliches Ehrenwort. Er stützt sein Urteil auf ein eingespieltes Betriebssystem aus standardisierten Buchungsregeln, revisionssicheren Belegen und lückenlosen Abschlüssen, das eine objektive Prüfung überhaupt erst ermöglicht. Für Software- und KI-Systeme, die operative Entscheidungen beeinflussen, existiert ein vergleichbarer Prüfmaßstab bislang nicht. Er entsteht jedoch gerade mit hoher Dynamik in internationalen Standards sowie europäischen Rechtsakten und fordert Antworten auf zwei fundamentale Fragen.
Erstens: Arbeitet das eingesetzte System nachvollziehbar und vertrauenswürdig? Und zweitens: Rechnet die zugrundeliegende Infrastruktur an einem Ort, dessen Rechtsrahmen Du genau kennst und bewusst wählst? Beide Fragen berühren keineswegs bloß die IT-Abteilung, sondern das Herz Deines Geschäftsmodells; wer sie nicht belastbar beantworten kann, verliert künftig Ausschreibungen, Industriekunden und im regulierten Umfeld schlichtweg die Betriebserlaubnis. Die Thesen dieses Kapitels zeigen auf, wie Du die erforderlichen Antworten automatisch im Betriebsalltag erzeugst, anstatt wertvolle Managementressourcen in Nachtschichten vor dem Audit-Termin zu verbrennen.
45 Minuten, 460 Millionen Dollar
Was es kostet, den eigenen Systembestand nicht belegen zu können, hat der US-Broker Knight Capital am 1. August 2012 vorgeführt. Sein Handelssystem schickte binnen 45 Minuten über vier Millionen ungewollte Börsenaufträge in den Markt; der Verlust lag bei mehr als 460 Millionen Dollar. Die Ursache war kein Angriff, sondern banale Bestandsführung: Ein Techniker hatte neue Software auf sieben von acht Servern installiert, auf dem achten schlummerte seit Jahren stillgelegter Alt-Code, den das neue Steuerungssignal versehentlich weckte. Niemand prüfte die Installation nach (schriftliche Verfahren dafür existierten nicht), und im laufenden Betrieb konnte niemand belegen, welche Systemversion wo tatsächlich arbeitete. Die Börsenaufsicht wertete den Fall nüchtern als Versagen der Kontrollen über die eigenen automatisierten Systeme. Es ist exakt die Frage dieses Kapitels: Kannst Du jederzeit belegen, was bei Dir wirklich läuft?
— U.S. Securities and Exchange Commission, In the Matter of Knight Capital Americas LLC (2013)
14.2 A5: das KI-System nachweisbar machen
Zuerst die betriebliche Alltagsrelevanz. Einen Personenaufzug in Deinem Bürogebäude darfst Du schlicht deshalb betreiben, weil eine unabhängige Prüfstelle ihn nach einem gesetzlich anerkannten Verfahren auf Herz und Nieren getestet hat. Niemand verlangt von Dir als Betreiber, dass Du den Sicherheitsversprechungen des Herstellers blind vertraust. Für komplexe KI-Systeme etabliert sich aktuell eine exakt vergleichbare Logik. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat hierfür einen öffentlich diskutierten Entwurf vorgelegt: die Prüfarchitektur A5, ausgeschrieben als "AI Audit and Assurance Assessment Architecture".
Der Kerngedanke lässt sich vollkommen ohne Fachsprache auf den Punkt bringen. Wer ein KI-System produktiv einsetzt, muss künftig präzise belegen können, aus welchen Komponenten es zusammengesetzt ist, auf welchen Datenquellen seine Antworten fußen und über welche Regeln es zu seinen Ergebnissen gelangt. Das ist dieselbe Logik, mit der eine Zutatendeklaration auf der Lebensmittelverpackung den Inhalt offenlegt. Für die technischen Bestandteile nutzt der Standard das Konzept einer maschinenlesbaren Stückliste, der sogenannten AI-BOM (AI Bill of Materials, also einer strukturierten Inventarliste der Modell-, Daten- und Softwarekomponenten).
Auf der Konzeptebene führt diese Anforderung zu einer schmerzhaften Erkenntnis, die als erste These dieses Kapitels verankert ist:
Solche Nachweise lassen sich im digitalen Zeitalter nicht mehr sinnvoll rückwirkend konstruieren.
Ein Prüfnachweis, der vor jedem Audit mühsam in Handarbeit zusammengesucht wird, gleicht einem Fahrtenbuch, das erst in der Nacht vor der Steuerprüfung nachträglich geschrieben wird. Tragfähig ist einzig ein Nachweis, der vollautomatisch im laufenden Betrieb entsteht: bei jeder Anpassung am System, bei jeder Aktualisierung der Quellsysteme und bei jeder Korrektur organisatorischer Regeln. Genau an diesem Punkt wird die Frage der governten Ontologie unausweichlich.
Mitlaufende Nachweise setzen zwingend voraus, dass das Wissen über das System selbst maschinenlesbar, versioniert und verantwortet vorliegt; exakt diesen Bestand sichert die Architektur aus Kapitel 7 und 13. Aus einem solchen zentralen Wissensnetz lassen sich geforderte Nachweisformate jederzeit auf Knopfdruck exportieren, bis hin zu standardisierten Spezifikationen wie OSCAL (Open Security Controls Assessment Language, einem maschinenlesbaren Format für Sicherheits- und Compliance-Nachweise). Warum wird dieser Weg erst jetzt gangbar? Weil die ökonomische Timing-These aus Kapitel 2 auch hier voll durchschlägt: Erst seitdem automatisierte Extraktion und strukturierte Konsolidierung bezahlbar geworden sind, kann auch ein mittelständisches Unternehmen einen solchen Nachweisbestand führen, ohne eine eigene Stabsabteilung dafür gründen zu müssen. Der konkrete Aufwandsvergleich zwischen der traditionellen manuellen Audit-Vorbereitung und einem integrierten, konsolidierten Bestand liegt als vorläufiger Orientierungswert vor: rund 320 Personenstunden je Prüfungsbereich manuell gegenüber einem Zielband von 120 bis 160 Stunden nach Konsolidierung.
14.3 CADA: die Infrastruktur einstufbar machen
Auch hier empfiehlt sich der Blick auf die Alltagspraxis. Auf jedem neuen Kühlschrank klebt ein gut sichtbares Energielabel, und kein Verbraucher muss Ingenieurwissenschaften studieren, um die Effizienzklasse A von der Klasse G zu unterscheiden. Die Europäische Kommission hat im Juni 2026 einen Verordnungsvorschlag eingebracht, der eine vergleichbar transparente Einstufung für Cloud- und KI-Infrastrukturen schaffen soll: den Cloud and AI Development Act, kurz CADA. Das strategische Ziel dahinter lautet: Digitale Souveränität (also die verlässliche Klärung der Frage, welcher Rechtsraum und welche ausländischen Behörden Zugriff auf Deine Daten besitzen) wandelt sich vom schwammigen Marketing-Adjektiv zu einer objektiv geprüften, gestuften Produkteigenschaft. Einordnende Analysen weisen zu Recht darauf hin, dass zwischen dem politischen Anspruch und der praktischen Umsetzung noch beträchtliche Gestaltungsfragen offen sind. Die Positionierung des Bitkom hinsichtlich der Mittelstandstauglichkeit und der Anrechnung bereits existierender Zertifizierungen bleibt derzeit eine offene Verbandsfrage.
Für Unternehmensentscheider gewinnt eine solche Einstufungslogik rasch an Brisanz, was direkt zur zweiten These führt. Der Verordnungsentwurf behandelt jene Daten mit der höchsten Sensibilität, die bei der täglichen Nutzung von KI-Systemen entstehen und das intellektuelle Innenleben einer Organisation abbilden. Das konsolidierte Selbstverständnis aus diesem Buch bildet exakt einen solchen hochsensiblen Bestand; es speichert schließlich transparent, wie Dein Haus arbeitet, wo operative Regeln kollidieren und welche Strategien Du verfolgst.
An welchem physischen Ort und unter welchem rechtlichen Mantel dieser Bestand rechnet, wird damit zur existenziellen Vorstandsentscheidung – keineswegs zur beiläufigen Entscheidung der IT-Infrastruktur.
Auch hier stellt sich die Ontologie-Frage zwingend von selbst: Eine behördliche oder auditorische Souveränitätseinstufung kann stets nur prüfen, was eindeutig strukturiert ausweisbar ist. Ein governter Bestand mit lückenloser Herkunft, aktiven Versionen und transparenter Rechenort-Deklaration ist mühelos einstufbar; ein unstrukturierter Dateiberg ist es nicht. Ob öffentliche Auftraggeber und Konzernkunden solche Souveränitätsstufen künftig zur zwingenden Voraussetzung in Ausschreibungen machen werden, bleibt derzeit eine fundierte Prognose und ist als wissenschaftliche Hypothese gekennzeichnet.
14.4 Zwei Etiketten, ein Vertrauensnachweis
Die beiden besprochenen Regelwerke adressieren unterschiedliche Dimensionen, und erst in ihrer Kombination entfalten sie ein vollständiges Bild. Die A5-Logik prüft das digitale System selbst: Arbeitet es nachvollziehbar, regelkonform und vertrauenswürdig? Die CADA-Logik prüft den gewählten Betriebsort: Läuft die Infrastruktur unter Rahmenbedingungen, die die Organisation genau kennt und eigenverantwortlich bestimmt?
Ein drittes Element führt beide Stränge in der Führungspraxis zusammen: das sogenannte Betreiber-Attest, also die rechtlich belastbare Selbstauskunft der Unternehmensleitung über System und Datenbestand, gespeist aus dem laufenden, versionierten Selbstwissen. Mit dem Betreiber-Attest übernimmt der Vorstand die persönliche Verantwortung für die Vertrauenswürdigkeit und Souveränität seiner digitalen Operations. Wie diese Verbindung im realen Einsatz gelingt, zeigt Fall A eindrucksvoll: eine souveräne Plattform einer öffentlichen Verwaltung, deren Sicherheits- und Verfahrenslage als versionierter, jederzeit prüfbarer Bestand im Betrieb mitläuft.
Case Study — Fall A und Fall C: Eine Landeshauptstadt betreibt ihre Plattform souverän und führt die Sicherheitsnachweise versioniert im Betrieb mit; ein Luftfahrt-Instandhalter mit hoher Audit-Taktung konsolidiert zwei Systemwelten, um die Audit-Vorbereitungszeit je Prüfbereich messbar zu senken. → ausführlich Kap. 11.
14.5 Mitbestimmung und Datenschutz: Gestaltungsfragen, keine Fußnoten
Auch an dieser Stelle steht die betriebliche Praxis an erster Stelle: Ein Betriebssystem, das fortlaufend konsolidiert, wie in einer Organisation tatsächlich gearbeitet wird, berührt unmittelbar die Menschen, deren tägliches Handeln es erfasst. Aus diesem Grund gehören Betriebsrat und Datenschutzbeauftragte ab dem ersten Tag der Scope-Definition an den Verhandlungstisch, keinesfalls erst zur abschließenden Abnahmerunde (das Einführungskapitel 15 verankert diese Pflicht im Vorgehensmodell, während Kapitel 17 den Mitbestimmungseinwand in seiner schärfsten Form aufgreift).
Die Governance-Ebene der vorgestellten Architektur erweist sich dabei nicht als bürokratische Hürde, sondern als das entscheidende Gestaltungswerkzeug: Spezifische Auswertungsgrenzen, differenzierte Rollenrechte und anonymisierte Abfrageklassen werden exakt in demselben Bestand geregelt, der auch die Compliance-Nachweise trägt. Eine praxiserprobte Muster-Betriebsvereinbarung für Systeme dieser Klasse bildet derzeit noch ein Desiderat und ist als offene Forschungsaufgabe ausgewiesen.
14.6 Die Muster AG: ein Audit-Tag, zwei Fassungen
Bislang bedeutet die jährliche Zertifizierungsprüfung bei der Muster AG mindestens drei Wochen intensivsten Vorlauf: Dokumente in verschiedenen Wikis zusammensuchen, widersprüchliche Versionsstände auflösen und Abweichungen zwischen QM-Handbuch und operativer Praxis vor dem Prüfer rechtfertigen. Mit einem mitlaufenden, governten Bestand schrumpft dieser hektische Vorlauf auf das reine Erzeugen eines strukturierten Auszugs.
Der Auszug beantwortet am Audit-Tag vier zentrale Fragen auf Knopfdruck: Welche organisatorische Regel gilt aktuell, seit welchem Datum ist sie formell in Kraft, wer hat sie freigegeben und wo weicht die operative Praxis aus dokumentierten Gründen ab? Der Auditor erhält dadurch keine aufwendig aufbereitete Präsentation, sondern ein direkt aus dem System abgeleitetes, operatives Gesamtbild: Auch die aktuell noch offenen Konflikte sind transparent ausgewiesen, inklusive Bearbeitungsstatus und klarer Verantwortlichkeit im Zonen-Review. Erfahrene Prüfer honorieren diese Transparenz keineswegs aus Milde, sondern weil explizit gewürdigte Abweichungen das genaue Gegenteil von vertuschten Mängeln darstellen. Wie stark dieser Vorlauf tatsächlich schrumpft, ist keine Glaubensfrage, sondern eine messbare Größe: die Audit-Vorbereitungszeit aus Kapitel 10, deren Fall-C-Werte in Abschnitt 14.2 als vorläufige Orientierungswerte ausgewiesen sind.
Damit sind Prüfbarkeit und Souveränität als fundamentale Architektureigenschaften moderner Organisationen bestimmt. Wie der praktische Einstieg in dieses Modell gelingt, ohne die eigene Organisation zu überfordern, beantwortet das Vorgehensmodell der ersten neunzig Tage im folgenden Kapitel.
💡 Das haben wir diskutiert
Regulatorische Vorgaben und künftige Prüfstandards verwandeln den Nachweis von Systemvertrauen und digitaler Souveränität von einer lästigen Pflichtaufgabe in einen zentralen Betriebsparameter.
Ein versionierter Wissensbestand versetzt Dich in die Lage, Nachweise zu Systemlogik und Rechenort fortlaufend im Betrieb zu erzeugen, anstatt Prüfunterlagen vor Audits manuell zusammenzusuchen.
Wenn Du Belegfähigkeit, Souveränitätsanforderungen und Mitbestimmung frühzeitig verankerst, verliert der jährliche Audit-Tag seinen Schrecken und wird zur routinierten Bestätigung gelebter Ordnung.
Auf welche Weise Dir der operative Einstieg in diese neue Praxis ohne Überforderung Deiner Mannschaft gelingt, verdeutlicht das strukturierte 90-Tage-Muster im nächsten Kapitel.