Eine AI-Governance-Charta schreiben, die ein Audit übersteht

# Eine AI-Governance-Charta schreiben, die ein Audit übersteht

2024 stellten die Automated Decision Systems Task Force der Stadt New York und später das Büro des NYC Comptroller fest, dass mehrere städtische Behörden algorithmische Werkzeuge einsetzten (von Betrugserkennung bis zu Bewerber-Screenings), ohne einheitliches Inventar, ohne dokumentierte Risikoprüfung und ohne klaren Verantwortlichen für den Fall, dass etwas schiefgeht. Ein städtischer Inspector General, der den Chatbot-Einsatz einer Behörde prüfte, fand niemanden, der belegen konnte, wer ihn genehmigt hatte, mit welchen Daten ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → trainiert wurde oder wie Beschwerden bearbeitet wurden. Diese Lücke, nicht die Technologie selbst, ist das, was Auditoren zuerst aufgreifen.

Diese Lektion baut das interne Dokument, das diese Lücke schließt: eine AI-Governance-Charta. Kein Policy-Poster. Ein Arbeitsdokument, das ein Auditor, ein Inspector General (IG, die unabhängige Stelle, die Verschwendung, Betrug und Missmanagement innerhalb einer Behörde untersucht) oder ein Aufsichtsausschuss des Stadtrats zur Hand nehmen und Zeile für Zeile nachvollziehen kann.

Warum „Charta“ und nicht nur „Policy“

Eine Policy formuliert Grundsätze („wir setzen AI verantwortungsvoll ein“). Eine Charta weist Verantwortlichkeit zu: wer entscheidet, wer prüft, wer freigibt und was passiert, wenn ein System eine Prüfung nicht besteht. Auditoren prüfen keine Absichten. Sie prüfen Paper Trails und Entscheidungsrechte.

Das US Government Accountability Office (GAO) und die Inspectors General der Behörden nennen in AI-Aufsichtsprüfungen durchgängig dasselbe Fehlermuster: Werkzeuge, die ohne formales Risk Assessment beschafft wurden, kein benannter verantwortlicher Amtsträger und kein Incident Log (GAO AI Accountability Framework, 2021, weiterhin der Referenzstandard für Prüfungen im öffentlichen Sektor). Ihre Charta existiert, um genau dieses Prüfungsergebnis zu verhindern.

Kernklausel 1: Systeminventar und Risk Tiering

Jedes AI-System, das von der Behörde oder in ihrem Auftrag genutzt wird (einschließlich Vendor-Tools, die in Beschaffungssoftware eingebettet sind), muss vor dem Deployment erfasst werden. Mindestfelder:

• Systemname, Vendor, Zweck
• Dateneingaben (berührt es personenbezogene Daten, Leistungsberechtigung, Vorstrafen?)
• Entscheidungswirkung: rein informativ, oder beeinflusst es den Zugang einer Person zu einer Leistung, einem Anspruch oder einer Vollzugsmaßnahme?
• Risk Tier: low (internes Hilfsmittel zum Entwurf), medium (Entscheidungsunterstützung mit menschlicher Prüfung), high (wirkt sich materiell auf Berechtigung, Leistungen, Polizeiarbeit oder Einstellungen aus)

Das spiegelt die Tiering-Logik des EU AI Act (Verordnung (EU) 2024/1689, in Kraft seit August 2024), der bestimmte Anwendungen vollständig verbietet und Systeme in Strafverfolgung, Migration, Beschäftigung und essenziellen öffentlichen Diensten als „hochriskant“ einstuft, was verpflichtende Konformitätsbewertungen vor dem Deployment auslöst. US-Behörden nutzen zunehmend freiwillig ein ähnliches Tiering und beziehen sich dabei auf das OMB Memo M-24-10 (2024) des White House Office of Management and Budget, das Bundesbehörden verpflichtet, einen Chief AI Officer zu benennen und Risk Assessments für „safety-impacting“ und „rights-impacting“ AI-Anwendungsfälle durchzuführen.

Formulierung der Charta-Klausel:

> „Kein AI-System darf vom Pilot in den Produktivbetrieb übergehen, ohne einen Eintrag im AI-Systeminventar und einen zugewiesenen Risk Tier, der mindestens jährlich oder bei materiellem Modell-Update überprüft wird.“

Kernklausel 2: benannte Rollen, keine Abteilungen

Das mit Abstand häufigste Prüfungsergebnis ist ein Verantwortungsvakuum. Beheben Sie es mit benannten Rollen, nicht mit „der IT-Abteilung“:

• AI Accountable Official: gibt vor dem Deployment frei; persönlich im Audit auskunftspflichtig. In Bundesbehörden ist das oft die unter OMB M-24-10 vorgeschriebene Rolle des Chief AI Officer.
• Model Risk Reviewer: unabhängig von dem Team, das das System gebaut oder beschafft hat; prüft auf Bias, Datenqualität und Drift (die Genauigkeit eines Modells verschlechtert sich, wenn sich die realen Bedingungen von den Trainingsdaten entfernen).
• Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen →: bestätigt, welche Daten das System trainiert haben oder es speisen, und ob darunter geschützte Kategorien sind, die nach Gesetzen wie dem Fair Housing Act oder Title VII besondere Prüfung erfordern, sofern das System Wohnungs- oder Beschäftigungsentscheidungen berührt.
• Public Records Officer: stellt sicher, dass die Dokumentation (siehe Klausel 4) gemäß dem Public-Records-Recht des Staates und der Kommune aufbewahrt wird, da AI-Entscheidungslogs zunehmend als Gegenstand von Public-Records-Anfragen gelten (wie mehrere Gerichte einzelner Bundesstaaten zu Predictive-Policing-Werkzeugen entschieden haben).

Kernklausel 3: Eskalationspfad vor und nach dem Deployment

Vor dem Deployment definieren Sie einen verpflichtenden Haltepunkt: Jedes System mit Einstufung „medium“ oder „high“ darf ohne schriftliche Freigabe des Model Risk Reviewer und des Accountable Official nicht live gehen.

Nach dem Deployment definieren Sie die Incident-Leiter:

1. Mitarbeitende an der Front oder Bürger melden eine Anomalie (falsche Ablehnung einer Leistung, verzerrte Markierung).

2. Erfassung innerhalb von 48 Stunden beim Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen →.

3. Der Model Risk Reviewer bewertet innerhalb von 5 Werktagen: Ist das ein Einzelfehler oder ein systemisches Muster?

4. Wenn systemisch, entscheidet der Accountable Official: aussetzen, patchen oder neu trainieren, mit dokumentierter und datierter Entscheidung.

5. Jede Aussetzung, die einen bürgernahen Dienst betrifft, löst eine Benachrichtigung des Aufsichtsgremiums aus (Ausschuss des Stadtrats, AI-Task-Force des Landesparlaments oder IG-Büro, je nach Zuständigkeit).

Genau diese Leiter prüft ein IG-Audit tatsächlich: nicht „hatten Sie eine Policy“, sondern „haben Sie beim letzten Zwischenfall Ihren eigenen Eskalationspfad befolgt“.

Kernklausel 4: Dokumentationsstandards, die halten

Auditoren wollen Artefakte, keine Erzählungen. Mindestdokumentation pro System:

/ai-system-record/
  01_intake_form.pdf        (purpose, vendor, data sources)
  02_risk_assessment.pdf    (tier, bias testing results, sign-off dates)
  03_human_review_log.csv   (every override of an AI recommendation)
  04_incident_log.csv       (date, description, resolution, owner)
  05_annual_review.pdf      (re-certification or retirement decision)

Die Aufbewahrungsfrist sollte dem Public-Records-Recht Ihrer Zuständigkeit entsprechen, typischerweise derselben Frist, die für die zugrunde liegende staatliche Funktion gilt (Leistungsakten, Beschaffungsakten, Personalakten). Das ist keine optionale Archivierung; mehrere IG-Berichte von Städten und Bundesstaaten haben fehlende Aufbewahrungsfristen ausdrücklich als Prüfungsmangel benannt, da unvollständige Akten die Rekonstruktion einer strittigen Entscheidung verhindern.

Guardrails, die vor jedem Deployment laufen

Bevor ein System den Haltepunkt aus Klausel 1 passiert, führen Sie diese Prüfungen durch:

1. Bias- und Disparate-Impact-Test: Ergebnisse über demografische Gruppen hinweg vergleichen, soweit die Daten es erlauben, mit etablierten Fairness-Metriken (z. B. Demographic Parity, Equalized Odds).

2. Data-Provenance-Prüfung: bestätigen, dass Trainings- und Eingabedatenquellen rechtmäßig beschafft und im Umfang angemessen sind (keine unbefugten personenbezogenen Daten).

3. Human-in-the-Loop-Bestätigung: Bei jedem High-Risk-Tier muss ein Mensch prüfen und übersteuern kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen, bevor die Entscheidung für eine Person wirksam wird, nicht danach.

4. Vendor-Transparenzprüfung: Gibt der Vertrag der Behörde Auditrechte an der Logik des Modells und dessen Update-Historie? Viele Beschaffungsfehler gehen auf Vendor-Verträge zurück, die das blockieren.

5. Prüfung der öffentlichen Bekanntmachung: Verlangt die Zuständigkeit eine öffentliche Offenlegung des Einsatzes automatisierter Entscheidungssysteme (wie NYCs Local Law 144 es für automatisierte Einstellungsentscheidungs-Tools fordert)?

Wie das in der Praxis aussieht

Stellen Sie sich eine mittelgroße Stadt vor, die ein AI-Tool einsetzt, um 311-Serviceanfragen (Bürgerbeschwerden ohne Notfallcharakter) nach Dringlichkeit zu triagieren. Unter der Charta: Es geht als Medium Risk ins Inventar (es beeinflusst die Reihenfolge der Bearbeitung, aber keine Berechtigung oder Rechte). Der Model Risk Reviewer testet es auf Bias auf Stadtteilebene, da die Dringlichkeitsbewertung einkommensschwächere Gegenden systematisch nach hinten schieben kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnte. Der Accountable Official gibt frei, wobei ein menschlicher Dispatcher die Override-Befugnis behält. Drei Monate später meldet das Büro eines Ratsmitglieds ein Muster: Beschwerden aus einem Distrikt werden durchgängig nach hinten priorisiert. Die Incident-Leiter greift, das Muster wird bestätigt, und das Modell wird mit dokumentierter Begründung neu trainiert. Als das Büro des Comptroller der Stadt das Programm später prüft, hat jeder Schritt einen Zeitstempel und einen Namen.

🎬 [VIDEO: „How Government Agencies Are Regulating AI“ - youtube.com - suchen Sie nach Erklärvideos von GAO oder Brookings Institution zu bundesstaatlichen AI-Aufsichtsframeworks und Accountability-Strukturen in Behörden]

Wichtigste Erkenntnisse

• Eine Governance-Charta weist benannte Verantwortlichkeit und dokumentierte Entscheidungspunkte zu; eine Policy mit Grundsatzerklärungen übersteht kein Audit.
• Stufen Sie jedes AI-System nach Risiko ein (low, medium, high), mit einem Framework, das zu OMB M-24-10 (US-Bund) oder den Risikokategorien des EU AI Act passt (für Zuständigkeiten, die sich an der EU-Praxis orientieren).
• Bauen Sie einen zweiteiligen Eskalationspfad: einen Haltepunkt vor dem Deployment mit erforderlicher Freigabe und eine Incident-Leiter nach dem Deployment mit festen Reaktionsfristen.
• Dokumentation muss artefaktbasiert sein (Logs, Freigaben, datierte Reviews) und gemäß Public-Records-Recht aufbewahrt werden, da diese Aufzeichnungen zunehmend Gegenstand von Open-Records-Anfragen und IG-Prüfungen sind.
• Testen Sie auf Bias, Data ProvenanceData ProvenanceData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.Vollständige Definition ansehen →, menschliche Override-Fähigkeit und Vendor-Auditrechte, bevor ein System live geht, nicht erst, wenn eine Beschwerde die Frage aufwirft.