Der Vorstand eines Unternehmens genehmigt die Implementierung eines AI-Assistenten für den Kundenservice. Zwei Monate später stellt sich heraus, dass das Modell manchmal Fragen zu Preisen mit veralteten Daten beantwortet, niemand sagen kann, welche Entscheidungen auf AI-Empfehlungen basierten, und die Rechtsabteilung nicht weiß, ob das System als Hochrisikosystem im Sinne des AI Act registriert werden muss. Das ist kein Ausnahmefall. Das ist das Standardergebnis einer AI-Implementierung ohne Governance.
Im Folgenden beschreibe ich, wie Governance in der Praxis funktioniert: welche Richtlinien definiert werden müssen, welche Rollen geschaffen werden sollten, welche technischen Mechanismen implementiert werden müssen und wo der AI Act harte Grenzen setzt.
Was ist AI-Governance und warum gewinnt sie an Bedeutung
#AI-Governance ist eine Sammlung von Regeln, Verfahren und technischen Mechanismen, die es einer Organisation ermöglichen, AI-Systeme über ihren gesamten Lebenszyklus zu verwalten: von der Konzeption über die Implementierung, den Betrieb bis hin zur Außerbetriebnahme. Der Begriff umfasst drei Ebenen:
- Richtlinien — was das AI-System tun darf, welche Daten es verarbeiten darf, welche Entscheidungen es autonom treffen darf und welche einer menschlichen Bestätigung bedürfen.
- Organisation — wer der Eigentümer jedes AI-Systems ist, wer für dessen Betrieb verantwortlich ist und wer es stoppen kann.
- Technik — Guardrails, Audit-Logs, Alerts, Regressionstests, Incident-Verfahren.
Im Jahr 2026 hat Governance eine regulatorische Dimension erhalten. Der AI Act trat in die Phase der Anwendung für Systeme mit allgemeinem Verwendungszweck und Hochrisikosysteme ein. Die RODO verpflichtet den Datenverantwortlichen zur Risikobewertung (DPIA) vor der Implementierung eines Systems, das personenbezogene Daten verarbeitet. Das Fehlen von Governance ist nicht mehr eine Frage der Organisationskultur: Es wurde zur potenziellen Grundlage für die Verhängung von Strafen durch die UODO oder die Aufsichtsbehörde des AI Act.
Für Unternehmen, die AI in Polen implementieren, ist auch der praktische Kontext relevant: Die meisten Organisationen beschäftigen keine Dutzende von AI-Spezialisten. Governance muss proportional zur Skala sein und von einem Team aufrechterhalten werden können, das gleichzeitig andere Aufgaben wahrnimmt.
Karte der AI-Systeme: Ausgangspunkt jeder Governance
#Governance kann nicht funktionieren, wenn die Organisation nicht weiß, welche AI-Systeme sie betreibt. Der erste Schritt ist die Inventarisierung.
Die Inventarisierung sollte umfassen:
- Eigene Systeme (intern oder durch einen Technologiepartner entwickelt).
- SaaS-Systeme mit AI-Funktionen (z. B. CRM mit Scoring-Funktion, Rekrutierungsplattform mit CV-Screening).
- In bestehende Tools eingebettete Modelle (z. B. „vorgeschlagene Antwort“-Funktion im Helpdesk).
Für jedes System sollte festgelegt werden: welche Daten es verarbeitet (einschließlich personenbezogener Daten), welche Entscheidungen es unterstützt oder autonom trifft, und welche potenziellen Auswirkungen ein Fehler auf den Nutzer oder die Organisation hat.
Dieser letzte Punkt entscheidet über die Risikoklassifizierung. Der AI Act listet in Anhang III Kategorien von Hochrisikosystemen auf: Beschäftigung (Scoring, CV-Auswahl), Zugang zu Dienstleistungen (Kreditscoring, Versicherungsscoring), Bildung, kritische Infrastruktur, öffentliche Sicherheit. Ein System außerhalb dieser Kategorien kann dennoch eine DPIA gemäß RODO erfordern, wenn es personenbezogene Daten in großem Umfang oder sensible Daten verarbeitet.
Das Ergebnis der Inventarisierung ist ein Register der AI-Systeme: ein lebendiges Dokument, das bei jeder neuen Implementierung oder Architekturänderung aktualisiert wird.
AI-Richtlinien: Was muss festgelegt werden
#Die AI-Richtlinie ist ein operatives Dokument, keine Marketingerklärung. Eine gute Richtlinie enthält konkrete Regeln, keine allgemeinen Absichtserklärungen.
Schlüsselbereiche, die die Richtlinie abdecken sollte:
Zulässige Anwendungsfälle. Welche Prozesse durch AI unterstützt werden dürfen, welche zusätzliche Genehmigungen erfordern und welche ausgeschlossen sind (z. B. autonome Kreditentscheidungen ohne Human-Gate, Verarbeitung von Gesundheitsdaten durch ein Modell in einer externen Cloud ohne Data-Residency in der EU).
Regeln zur Datenverarbeitung. Ob und welche personenbezogenen Daten an das Modell gesendet werden. Ob Daten vor dem Senden an den LLM maskiert werden. Wo das Modell gehostet wird (Self-Hosting oder externes API) und wie sich dies auf die rechtliche Grundlage der Verarbeitung auswirkt.
Human-in-the-Loop. Welche Entscheidungen das Modell autonom treffen darf und welche einer menschlichen Bestätigung bedürfen. Für Hochrisikosysteme verlangt der AI Act menschliche Aufsicht als Bedingung für den Betrieb.
Incident-Management. Wie auf Modellfehler, Halluzinationen in operativen Entscheidungen oder Datenschutzverletzungen durch das AI-System reagiert wird. Wer die Entscheidung trifft, das System abzuschalten. Wie viel Zeit die Organisation hat, um dies der UODO zu melden (RODO: 72 Stunden ab Feststellung der Datenschutzverletzung).
Überprüfung und Aktualisierung. Die AI-Richtlinie sollte mindestens einmal jährlich oder nach jeder wesentlichen Änderung der Systemarchitektur überprüft werden.
Rollen und Verantwortlichkeiten: Wer ist wofür zuständig
#Governance ohne Zuweisung von Verantwortlichkeiten ist eine Wunschliste. Für jedes AI-System sollten klare Rollen definiert sein.
| Rolle | Verantwortungsbereich | Minimale Form |
|---|---|---|
| AI Owner (Systemverantwortlicher) | Verantwortlich für Entscheidungen über das System: Implementierung, Änderung, Abschaltung; Ansprechpartner für Audits | Konkrete Person, nicht „IT-Abteilung“ |
| Data Steward | Verantwortlich für die im System verwendeten Daten: Qualität, rechtliche Grundlage, Aufbewahrung, Löschung sensibler Daten | Kann mit der Rolle des IODO/DPO kombiniert werden |
| AI Engineer | Verantwortlich für die Implementierung von Guardrails, Audit-Logs, Regressionstests, Modellaktualisierungen | Technisches Team |
| Human Reviewer | Verantwortlich für die Überprüfung von Entscheidungen, die eine menschliche Freigabe erfordern; Eskalation von Anomalien | Operative Rolle, z. B. im Kundenservice oder HR |
| AI Auditor (intern oder extern) | Führt Compliance-Prüfungen durch, testet Red-Team, überprüft Logs | Kann bei kleineren Organisationen extern sein |
Für Hochrisikosysteme verlangt der AI Act die Benennung einer für die Aufsicht über das System verantwortlichen Person (Art. 26 ff.). In der Praxis ist dies die Rolle des AI Owner mit einem formalen Mandat zur Intervention im Systembetrieb.
Kleine Organisationen kombinieren oft mehrere Rollen in einer Person. Dies ist zulässig, sofern die Verantwortungsbereiche klar definiert sind und keine Interessenkonflikte entstehen (z. B. sollte der AI Engineer nicht der einzige AI Auditor seiner eigenen Systeme sein).
Technische Mechanismen: Wie Governance im Code funktioniert
#Richtlinien und Rollen sind nutzlos, wenn sie sich nicht in der technischen Architektur widerspiegeln. Governance auf Code-Ebene umfasst vier Kategorien von Mechanismen.
Guardrails. Barrieren am Eingang und Ausgang des Modells: Blockieren von Prompts, die versuchen, Daten außerhalb des zulässigen Bereichs abzurufen, Filtern des Outputs auf personenbezogene Daten, Blockieren von Antworten außerhalb des Systemthemas. Guardrails sind die erste Linie der Richtliniendurchsetzung in Echtzeit.
PII-Maskierung. Personenbezogene Daten werden identifiziert und anonymisiert oder pseudonymisiert, bevor sie an das Modell gesendet werden. Dies ist sowohl eine RODO-Anforderung (Datenminimierung) als auch ein Schutz vor Datenlecks über das Modell-API. Der LLM-Router (llm-router) ist der richtige Ort für die Implementierung dieser Schicht.
Human-Gate. Aktionen mit irreversiblen Folgen (Versand, Zahlung, Datenlöschung, Kreditentscheidung) erfordern eine menschliche Bestätigung vor der Ausführung. Implementierung über HMAC-Token: Der Agent generiert einen Aktionsvorschlag mit Token, der Mensch bestätigt, der Token wird vor der Ausführung verifiziert. Dieses Muster beschreiben wir detailliert im Artikel über die Rolle des Menschen in der AI-Schleife.
Observability und Audit-Logs. Jeder Modellaufruf sollte ein Log erzeugen, das Folgendes enthält: Sitzungs-ID (ohne PII), verwendete Tools (im Falle eines Agenten), Antwortzeit, Flag, ob die Antwort eine Eskalation erforderte. Logs sind die Grundlage für AI-Act-Audits und die Analyse nach einem Incident. Implementierungsdetails finden sich im Artikel über Monitoring der Qualität eines AI-Agenten.
Risikobewertung und DPIA: Wann ist sie verpflichtend
#Die DPIA (Data Protection Impact Assessment) ist verpflichtend, wenn die Verarbeitung personenbezogener Daten „ein hohes Risiko“ für betroffene Personen darstellen kann. Im Kontext von AI-Systemen weisen UODO (und EROD) insbesondere auf die Pflicht zur DPIA hin für:
- Systeme zum Profiling in großem Umfang,
- automatisierte Entscheidungsfindung mit rechtlichen oder ähnlich schwerwiegenden Folgen,
- Verarbeitung sensibler Daten (Gesundheit, Biometrie, politische Meinungen) durch AI,
- Überwachung von Mitarbeitern mit AI.
Die DPIA besteht aus drei Elementen: Beschreibung des Systems und des Verarbeitungszwecks; Bewertung der Notwendigkeit und Verhältnismäßigkeit; Bewertung der Risiken und Maßnahmen zu deren Begrenzung.
Für AI-Systeme ist das dritte Element entscheidend: Die Risikobewertung sollte sowohl Risiken für personenbezogene Daten (Datenlecks, unbefugter Zugriff) als auch Entscheidungsrisiken (falsche Modellentscheidung, Bias, Halluzination) umfassen. Die Maßnahmen zur Risikobegrenzung sind genau die in der vorherigen Sektion beschriebenen Mechanismen: Guardrails, PII-Maskierung, Human-Gate, Observability.
Die DPIA ist kein einmaliges Dokument. Sie sollte bei jeder wesentlichen Änderung des Systems aktualisiert werden: neues Basismodell, Erweiterung des Umfangs der verarbeiteten Daten, Wechsel des Infrastrukturproviders.
Lebenszyklus eines AI-Systems: Governance von der Konzeption bis zur Außerbetriebnahme
#Governance beginnt nicht mit der Implementierung. Jede Phase des Lebenszyklus hat ihre eigenen Anforderungen.
| Phase | Wichtige Governance-Maßnahmen |
|---|---|
| Konzeption und Bewertung | Risikoklassifizierung (Register der AI-Systeme), vorläufige Bewertung der Notwendigkeit einer DPIA, Überprüfung der rechtlichen Grundlage für die Datenverarbeitung |
| Design und Entwicklung | Dokumentation der Architektur (Eingabedaten, Modell, Agententools, Ausgabedaten), Implementierung von Guardrails und PII-Maskierung, Definition von Human-Gate für irreversible Aktionen |
| Testen | Funktionstests, Red-Team-Tests (Versuche von Injection, Datenlecks), Bias-Tests (ob das Modell sich für verschiedene Nutzergruppen unterschiedlich verhält), DPIA-Überprüfung |
| Implementierung | Pilot mit begrenztem Umfang (Shadow Mode), Monitoring von Qualitätsmetriken (Faithfulness, Halluzinationsrate, Eskalationen), Entscheidung über die Erweiterung nach Nachweis der Sicherheit |
| Betrieb | Regelmäßige Überprüfungen (vierteljährlich oder nach einem Incident), Regressionstests nach Modelländerungen, Aktualisierung der DPIA bei Systemänderungen |
| Außerbetriebnahme | Löschung personenbezogener Daten aus Indizes und Fine-Tunings, Archivierung von Audit-Logs gemäß Aufbewahrungsfristen, Dokumentation des Grundes für die Außerbetriebnahme |
Die Phase der Außerbetriebnahme wird oft übersehen, ist aber sowohl für die RODO (Recht auf Vergessenwerden erfordert die Löschung von Daten aus dem Modell, nicht nur aus der Datenbank) als auch für die Sicherheit wichtig (ein außer Betrieb genommenes Modell sollte nicht über vergessene API-Endpunkte zugänglich bleiben).
Live ausprobieren
#Beschreibe eines deiner AI-Systeme oder eine geplante Implementierung, und das Modell zeigt dir, welche Governance-Elemente dafür entscheidend sind und wo du anfangen solltest (Playground: PII maskiert, keine Speicherung):
FAQ
#Müssen auch kleine Unternehmen AI-Governance implementieren?
#Ja, allerdings proportional zur Skala. Der AI Act und die RODO haben keine Größengrenze für Organisationen: Die Pflichten ergeben sich aus der Art des Systems und der Art der verarbeiteten Daten, nicht aus der Anzahl der Mitarbeiter. Ein kleines Unternehmen, das einen Chatbot implementiert, der Kundendaten verarbeitet, ist verpflichtet, die rechtliche Grundlage für die Verarbeitung zu bewerten und technische Maßnahmen (Guardrails, PII-Maskierung) zu implementieren. Der Unterschied liegt in der Formalisierung: Eine große Organisation benötigt ein formelles Register der AI-Systeme und ein AI-Komitee; ein kleines Unternehmen kann dies durch den Systemverantwortlichen und eine einfache Checkliste umsetzen. Der Ausgangspunkt ist das Tool zur Bewertung der Einsatzbereitschaft.
Wann erfordert ein AI-System eine DPIA?
#Eine DPIA ist verpflichtend, wenn die Verarbeitung ein hohes Risiko für betroffene Personen darstellen kann. In der Praxis gilt dies für AI-Systeme, wenn das System Personen profiliert, Entscheidungen mit erheblichen Folgen für Menschen trifft oder unterstützt (Beschäftigung, Kredit, Versicherung), sensible Daten verarbeitet oder Mitarbeiter mit AI überwacht. Im Zweifelsfall empfiehlt die UODO, eine DPIA vorsorglich durchzuführen, da die Kosten für ihre Erstellung deutlich niedriger sind als die Kosten für eine Datenschutzverletzung. Details zu den DPIA-Anforderungen beschreiben wir im Artikel über AI Act und RODO 2026.
Wie oft sollte die AI-Richtlinie überprüft werden?
#Mindestens einmal jährlich sowie bei jeder wesentlichen Änderung des Systems: neues Basismodell, Erweiterung des Umfangs der verarbeiteten Daten, Wechsel des Infrastrukturproviders, Sicherheitsvorfall. Die Überprüfung muss nicht jedes Mal ein umfassendes Audit sein: Eine Checkliste, die verifiziert, ob die Richtlinie noch die technische Realität des Systems und die aktuellen regulatorischen Anforderungen widerspiegelt, reicht aus. Den Rhythmus der Überprüfungen sollte man in der AI-Richtlinie als formales Element festhalten.
Was bedeutet es, dass ein AI-System ein Human-Gate erfordert?
#Human-Gate ist ein Mechanismus, der eine menschliche Bestätigung vor der Ausführung von Aktionen mit irreversiblen oder hochriskanten Folgen verlangt. Beispiele: Entscheidung über die Ablehnung eines Kandidaten im Rekrutierungsprozess, Versand eines Angebots, Löschung von Daten, Durchführung einer Überweisung, Änderung der Systemkonfiguration durch einen Agenten. Der AI Act verlangt für Hochrisikosysteme Human-Oversight als Bedingung für den Betrieb. In der technischen Praxis wird Human-Gate durch HMAC-Token implementiert: Der Agent schlägt eine Aktion mit einem signierten Token vor, der Mensch überprüft und bestätigt, der Token wird vor der Ausführung verifiziert. Dieses Muster beschreiben wir im Artikel über mehrstufige AI-Agenten.
Wie beginnt man mit dem Aufbau von AI-Governance in einer Organisation, die noch keine Verfahren hat?
#Beginne mit drei Schritten. Erster Schritt: Inventarisierung der bestehenden AI-Systeme (eigene und in genutzten SaaS-Tools) mit Risikobewertung für jedes. Zweiter Schritt: Benennung eines Verantwortlichen für jedes System (konkrete Person, nicht „Abteilung“) und Festlegung grundlegender Regeln: was das System verarbeiten darf, welche Entscheidungen eine menschliche Bestätigung erfordern. Dritter Schritt: Implementierung eines technischen Minimums: Guardrails, PII-Maskierung, Audit-Log. Das dauert einige Wochen für ein einfaches System und schafft die Grundlage, auf der man formellere Strukturen aufbauen kann. Der Schritt-für-Schritt-Plan zur AI-Implementierung und der Agenten-Blueprint helfen, diesen Prozess zu strukturieren.