KI Kontrollsystem: Interne Kontrollen für eine belastbare AI Act Governance

Vom Risiko zum Kontrollziel

Ein unternehmensweites KI Kontrollsystem ist im AI Act nicht als eigenständige Universalpflicht bezeichnet. Es kann jedoch konkrete Pflichten und die allgemeine Governance operationalisieren. Ausgangspunkt ist nicht eine möglichst lange Standardcheckliste, sondern der einzelne Use Case: Welche Rolle hat das Unternehmen, welche Personen sind betroffen, welcher Schaden kann entstehen und welche Regel soll eingehalten werden? Daraus entsteht ein Kontrollziel, beispielsweise unzulässige Dateneingaben zu verhindern oder Fehlentscheidungen vor ihrer Außenwirkung zu erkennen.

Kontrollen müssen zum Lebenszyklus passen. In der Beschaffung stehen Lieferantenprüfung, Rollenklärung und Vertragsinformationen im Vordergrund; vor dem Go-live sind Tests, Berechtigungen und Freigaben wichtig; im Betrieb zählen Protokolle, Stichproben, Beschwerden und Änderungsüberwachung. Bei Stilllegung kommen Datenrückgabe, Zugriffsentzug und Nachweisaufbewahrung hinzu. Diese Kette verhindert, dass eine gute Eingangskontrolle durch unbemerkte Modell-, Zweck- oder Datenänderungen ihre Wirkung verliert.

• Kontrollziel mit konkretem Risiko und anwendbarer Anforderung verknüpfen.
• Rolle, Systemklasse und Lebenszyklusphase im Kontrollregister ausweisen.
• Nur Kontrollen aufnehmen, deren Durchführung und Ergebnis nachweisbar sind.

Quellen: [1] [2]

Präventive Kontrollen vor und während der Nutzung

Präventive Kontrollen sollen unerwünschte Ereignisse vermeiden. Dazu gehören ein Katalog zugelassener Werkzeuge, rollenbasierte Berechtigungen, klare Datenregeln, Lieferantenprüfung, dokumentierte Freigabe und kontextbezogene Kompetenzmaßnahmen. Technische Beschränkungen sind verlässlicher als bloße Hinweise, wenn sensible Daten oder kritische Funktionen betroffen sind. Wo technische Sperren nicht möglich sind, müssen verständliche Regeln, Vier-Augen-Prinzip, Freigabegrenzen und stichprobenartige Überprüfung zusammenwirken.

Menschliche Aufsicht darf nicht nur als Feld im Formular erscheinen. Die ausgewählte Person braucht Kompetenz, Zeit, Zugriff auf relevante Informationen und die Befugnis, Ergebnisse zu verwerfen oder den Prozess anzuhalten. Die konkrete Ausgestaltung hängt vom System ab: Bei einem Assistenzwerkzeug kann eine fachliche Endkontrolle genügen; bei folgenreichen Entscheidungen können unabhängige Zweitprüfung, dokumentierte Begründung und ein alternativer manueller Prozess notwendig sein. Automatisierungsbias ist bei Schulung und Oberflächengestaltung mitzudenken.

• Zugelassene Tools und erlaubte Datenarten technisch und organisatorisch absichern.
• Freigaben mit klaren Nutzungsgrenzen und Rollen verbinden.
• Menschliche Aufsicht mit realer Eingriffs- und Stoppbefugnis ausstatten.

Quellen: [1] [2]

Detektive Kontrollen machen Abweichungen sichtbar

Detektive Kontrollen suchen nach Fehlern, die trotz Prävention auftreten. Geeignete Signale sind abhängig vom Zweck: fachliche Fehlerraten, ungültige Ausgaben, Drift, Robustheits- oder Sicherheitsereignisse, Unterschiede zwischen betroffenen Gruppen, ungewöhnlich viele menschliche Übersteuerungen, Beschwerden und Nutzungen außerhalb der Freigabe. Eine Kennzahl ist nur hilfreich, wenn Datenquelle, Baseline, Messfrequenz, Verantwortlicher und Schwellenwert feststehen. Reine Dashboard-Fülle ohne Reaktionsregel erzeugt Sichtbarkeit, aber keine Steuerung.

Protokolle und Stichproben müssen datenschutzgerecht ausgestaltet werden. Nicht jede mögliche Information soll unbegrenzt gespeichert werden; Zweck, Zugriff, Integrität und Aufbewahrungsfrist sind festzulegen. Bei fremden Systemen muss der Vertrag ausreichende Informationen und Änderungsmitteilungen sicherstellen. Können entscheidende Kontrollen mangels Daten nicht durchgeführt werden, ist dies ein Freigaberisiko und kein bloßes Reportingproblem. Ersatzkontrollen oder eine Einschränkung des Einsatzes sind dann ausdrücklich zu entscheiden.

• Baseline sowie Warn- und Stoppschwellen vor dem Produktivbetrieb festlegen.
• Technische Kennzahlen mit Beschwerden und fachlichen Stichproben verbinden.
• Fehlende Monitoringdaten als Risiko dokumentieren und kompensieren.

Quellen: [1] [2]

Reaktive Kontrollen begrenzen Schäden

Reaktive Kontrollen legen fest, was nach einer Abweichung geschieht. Je nach Schwere kann die Organisation einzelne Ergebnisse korrigieren, Nutzer sperren, Datenquellen deaktivieren, den Einsatz einschränken oder vollständig aussetzen. Parallel werden Systemzustand, Modellversion, relevante Eingaben und Logs gesichert. Betroffene Personen sind zu schützen, und mögliche Informations- oder Meldepflichten aus AI Act, Datenschutz, Cybersicherheits-, Produkt- oder Arbeitsrecht werden getrennt geprüft.

Eine Re-Freigabe erfolgt nicht allein nach technischer Fehlerbehebung. Erforderlich sind Ursachenanalyse, dokumentierte Korrektur, Wirksamkeitsprüfung und eine erneute Bewertung der rechtlichen sowie fachlichen Risiken. Das Kontrollregister wird aktualisiert, wenn eine Kontrolle zu spät ausgelöst hat oder keine ausreichende Evidenz lieferte. Wiederkehrende Ausnahmen sind keine Einzelfälle mehr; sie weisen auf ein ungeeignetes Kontrolldesign, unrealistische Schwellen oder fehlende Ressourcen hin und gehören in das Management Reporting.

• Sofortmaßnahmen, Beweissicherung und externe Meldeprüfung parallel organisieren.
• Re-Freigabe an Ursachenanalyse und Wirksamkeitsnachweis binden.
• Wiederkehrende Ausnahmen als strukturellen Kontrollmangel behandeln.

Quellen: [1] [2]

Hochrisikoanforderungen in das System integrieren

Für Anbieter von Hochrisiko-Systemen bilden Artikel 9 bis 17 künftig einen zusammenhängenden Rahmen. Dazu gehören Risikomanagement, Daten und Daten-Governance, technische Dokumentation, Protokollierung, Informationen für Betreiber, menschliche Aufsicht, Genauigkeit, Robustheit, Cybersicherheit und Qualitätsmanagement. Diese Anforderungen sollten nicht in getrennten Projektsilos umgesetzt werden. Eine Kontrollmatrix kann Anforderung, Risiko, Kontrolle, Evidenz und Verantwortlichkeit verbinden und dadurch Überschneidungen sowie Lücken sichtbar machen.

Für Betreiber liegt ein wichtiger Bezugspunkt in Artikel 26, etwa bei Nutzung nach Anleitung, menschlicher Aufsicht, relevanten Eingabedaten, Logs und Meldungen. Nach der Verordnung (EU) 2026/1744 gelten die einschlägigen Hochrisikopflichten für Anhang-III-Systeme grundsätzlich ab 2. Dezember 2027 und für Systeme nach Artikel 6 Absatz 1 grundsätzlich ab 2. August 2028. Für Produkte nach Anhang I Abschnitt B begrenzt Artikel 2 Absatz 2 die unmittelbare Geltung; das sektorale Produktrecht bleibt maßgeblich. Eine freiwillige Vorimplementierung kann sinnvoll sein, darf aber nicht als bereits gesetzlich fällige Pflicht dargestellt werden. Bereits geltende andere Rechtsvorschriften sind unabhängig davon einzuhalten.

• Artikel 9 bis 17 als zusammenhängenden Anbieterrahmen abbilden.
• Betreiberkontrollen aus tatsächlicher Nutzung und Artikel 26 ableiten.
• Künftige Hochrisikopflichten und bereits geltendes Recht zeitlich trennen.

Quellen: [2] [1]

Wirksamkeit belegen und Mängel schließen

Jede Kontrolle braucht einen Owner, eine Frequenz, einen Auslöser, erwartete Evidenz und ein Verfahren für Ausnahmen. Die bloße Existenz einer Policy belegt nicht, dass Eingaben geprüft oder Schwellen überwacht wurden. Geeignete Evidenz kann aus Freigabevermerken, unveränderbaren Logs, Testprotokollen, Stichprobenergebnissen, Schulungsnachweisen oder Incident Tickets bestehen. Der Umfang richtet sich nach Risiko und Rolle; unnötige Datensammlung ist zu vermeiden. Versionierung zeigt, welche Kontrolle zu welchem Zeitpunkt galt.

Die zweite Linie überwacht Design und Durchführung, die interne Revision kann unabhängig prüfen. Mängel werden nach Schwere priorisiert, mit Verantwortlichem und Zieltermin versehen und bis zur bestätigten Behebung verfolgt. Das Management Reporting konzentriert sich auf ausgefallene Schlüsselkontrollen, überfällige Maßnahmen, Stoppschwellen, wesentliche Vorfälle und akzeptierte Restrisiken. Auch ein gut dokumentiertes Kontrollsystem garantiert weder Fehlerfreiheit noch Konformität oder Haftungsfreiheit; es muss im Betrieb nachweisbar funktionieren und fortlaufend angepasst werden.

• Designwirksamkeit und tatsächliche Durchführung getrennt testen.
• Mängel mit Schweregrad, Owner, Termin und Abschlussnachweis verfolgen.
• Managementberichte auf entscheidungsrelevante Ausnahmen und Restrisiken begrenzen.

Quellen: [1] [2]

Häufige Fragen