Alle wollen KI-Agenten. “Die haben so viel Potenzial.” “Damit lassen sich endlich viele Probleme lösen.” Beiden Sätzen stimme ich zu, unter einer Bedingung: dass die notwendigen Rahmenbedingungen verstanden und hergestellt sind.
Zwei Konstellationen habe ich mehrfach erlebt. In der einen steht der Wunsch nach Agenten im Raum, und bei der Frage nach der Datenbasis stellt sich heraus, dass sie in Excel liegt. In der anderen soll ein ordentlicher Stoß Dokumente “einfach mal” zielgerichtet durchsuchbar werden. “Das muss KI doch können.”
In beiden Fällen ist die Erwartung an das Modell höher als die Investition in das, worauf es laufen soll. Wer so startet, hechelt einer Utopie hinterher, die weder dem Anspruch noch dem Mehrwert gerecht wird.
Kapitel 11 hat zwei Takte synchronisiert. Der schnellste davon ist KI. Damit aus dem Prototyp ein verlässlicher Teil des Betriebs wird, muss Führung liefern. Darum geht es in diesem letzten Kapitel.
Von Assistenz zu Autonomie, in dieser Reihenfolge
KI wirkt in Engineering, Produktion und Service dann als Enabler, wenn sie entlang eines klaren Reifegrads ausgerollt wird: von Assistenz über Automatisierung bis zu teilweiser Autonomie.
Entscheidend ist das System um das Modell herum, und es besteht aus vier Teilen:
- Daten und Telemetrie,
- Verantwortung im Betrieb,
- Guardrails für Safety, Security, Compliance und Qualität,
- und eine Führung, die Risk Tolerance, Freiräume und Eskalation explizit macht.
KI wirkt also dann, wenn Technik, Betrieb und Führung im selben Takt laufen.
Warum dieses Kapitel genau hier folgt
KI bringt ein eigenes Missverständnis ins Unternehmen. Viele halten ein starkes Modell schon für Wirkung. Die Arbeit beginnt nach der Demo, bei Logging, Oversight, Risk Management, Ownership und Incident Response. Deshalb steht dieses Kapitel am Ende und nicht am Anfang, denn alles, was vorher beschrieben wurde, ist die Voraussetzung dafür, dass KI im Betrieb überhaupt etwas taugt.
Worum es geht
Drei Dinge stehen im Mittelpunkt: eine saubere Reifegradleiter von Assistenz bis teilweiser Autonomie, Governance als Guardrail statt als Gatekeeper und die Betriebsfähigkeiten, ohne die KI nicht skaliert. KI als Showroom kommt darin nicht vor, der pauschale Ruf nach mehr Autonomie ebenso wenig.
Erst die Begriffe klären, sonst diskutiert jeder etwas anderes
Viele Organisationen sagen wir führen KI ein, als wäre das eine einzige Kategorie, und genau dort fängt das Problem an. Für dieses Buch trenne ich deshalb drei Stufen:
- Assistenz: Das System macht Vorschläge, der Mensch entscheidet.
- Automatisierung: Standardfälle laufen automatisch, Abweichungen eskalieren.
- Teilweise Autonomie: Das System handelt innerhalb definierter Guardrails, während Menschen
on the loopbleiben und übersteuern oder stoppen können.1
Mit jeder Stufe ändern sich die Anforderungen an Messung, Logging, Human Oversight, Freigaben und Incident Response. Der EU AI Act passt zu dieser Sicht, denn er beschreibt AI-Systeme als Systeme mit varying levels of autonomy.2 Die Führungsfrage lautet damit: Welchen Grad an Autonomie wollen wir hier?
Prinzip 1: KI ist ein System, kein Tool
Die meisten KI-Initiativen scheitern am fehlenden Betrieb. Die Demo ist da, aber Logging, Ownership, Guardrails und Eskalation fehlen.3 Daraus folgt die erste Regel dieses Kapitels: Fang mit dem System an, nicht mit dem Tool.
Konkret heißt das, vier Fragen zu beantworten:
- Welches Ergebnis soll besser werden?
- Welche Stufe ist gemeint: Assistenz, Automatisierung oder teilweise Autonomie?
- Wer ist verantwortlich, wenn das System falsch liegt?
- Welche Daten und welche Signale brauchst du, um das zu wissen?
Solange diese Fragen offen sind, diskutierst du Projektromantik.
Prinzip 2: Governance als Guardrail statt Gatekeeper
NIST strukturiert AI Risk Management über die vier Funktionen govern, map, measure und manage.4 Wichtiger ist die zweite Aussage: Governance ist bewusst cross-cutting und Risikomanagement soll kontinuierlich über den gesamten Lebenszyklus laufen.5
Das widerspricht einer Logik, die in Unternehmen tief sitzt: Governance als Freigabe am Ende. Bau Governance stattdessen als stabiles Set aus Policies, Grenzen, Messung und Eskalation. Denn wer sie als Gatekeeper baut, kennt das Muster: Das Feedback rutscht nach hinten, Risiken zeigen sich spät, und jede Diskussion über Tempo kippt früher oder später in Risikoabwehr.6
Guardrails funktionieren anders. Sie geben Teams einen verlässlichen Rahmen, in dem sie lernen können, ohne Vertrauen zu verlieren. Die SSDF-Analogie passt: Security gilt dort als core set an Praktiken und gemeinsames Vokabular, das in SDLCs integriert wird, nicht als Add-on.7
Prinzip 3: Data Governance und Logs sind zentrale Betriebsfähigkeiten
Ein häufiger Irrtum ist, KI als Modell plus UI zu denken. Damit unterschlägst du die Systemanteile, an denen der Betrieb später hängt: Data Governance, Logging, Oversight und Incident Response.8 Sculley und Kollegen haben diese Logik früh beschrieben: Quick Wins in ML kommen nicht gratis; reale ML-Systeme können massive laufende Wartungskosten und systemische Risiken erzeugen.9
In regulierten oder besonders kritischen Umgebungen wird das sofort konkret. Für High-Risk-Systeme verlangt der EU AI Act unter anderem:
- ein dokumentiertes Risk-Management-System als kontinuierlich-iterativen Lebenszyklusprozess,10
- Data- und Data-Governance-Praktiken für Trainings-, Validierungs- und Testdaten,11
- und automatische Logs über die Lebensdauer für Traceability und Post-market Monitoring.12
Ohne Data Governance und ohne Logs skalierst du in solchen Kontexten nicht robust, weil dir die Basis für Nachvollziehbarkeit, Monitoring und Oversight fehlt.
Woran das in der Praxis scheitert, habe ich in einem Projekt zum Aufbau einer Datenplattform gelernt. Meine Aufgabe war die Migration aus Excel: zwei Datentöpfe zusammenführen und konsistent machen. Vollständig gelungen ist mir das nie.
Auf der obersten Konsolidierungsebene standen Zeilen, die in keiner Systematik auftauchten. Intern hießen sie “Optimierungszeilen”. Ihr Zweck war, die Gesamtsumme für die Geschäftsleitung schöner aussehen zu lassen. Dazu kam ein zweiter Befund: Die für die Migration korrekt umgesetzte Geschäftslogik erzeugte einen Datenschiefstand gegenüber der bisherigen Auswertung. Sie rechnete richtig, und genau das war das Problem.
Die Antwort darauf kam ohne Zögern: “Die Zahlen kennt die Geschäftsleitung schon, überlegt euch was für die Harmonisierung. Darf aber nicht auffallen und zu Fragen führen.”
Excel ist unter anderem deshalb so beliebt, weil es keine Governance hat. Zeilen einfügen und ausblenden, Formeln nach bestem Wissen und Gewissen, Summen nach Belieben. Das funktioniert, solange ein Mensch die Tabelle liest und weiß, was darin gemeint ist. Sobald ein Modell darauf läuft, fällt dieses Wissen weg. Ein Agent stellt keine Rückfrage zu einer Optimierungszeile. Er rechnet sie mit und schreibt sie fort.
Damit schließt sich der Kreis zum Anfang dieses Kapitels. Bevor ein Agent auf eine Datenbasis losgelassen wird, gehört geklärt, wem die Zahlen darunter gehören und wer für sie geradesteht. Data Governance ist an dieser Stelle keine Dokumentationspflicht, sondern die Voraussetzung dafür, dass Automatisierung nicht die Kosmetik mitautomatisiert.
Prinzip 4: Human Oversight und Incident Response sind Teil des Produkts
Sobald ein System Vorschläge macht oder selbstständig Standardfälle abwickelt, brauchst du eine klare Antwort auf die wichtigste Betriebsfrage: Wer stoppt es, wenn es falsch liegt?
Der EU AI Act macht Human Oversight für High-Risk-AI explizit verpflichtend; je nach Risiko, Kontext und Autonomiegrad müssen Override oder Stop möglich sein.13 NIST zieht denselben Gedanken praktisch weiter: Monitoring und Incident Response, einschließlich appeal and override, sind Prozesse, die menschliche Adjudikation von System-Outputs ermöglichen sollen.14
Und Führung bleibt in dieser Frage zentral. Das NIST Playbook sagt klar: Executive Leadership trägt Verantwortung für Entscheidungen über Risiken in Entwicklung und Deployment.15 Das Modellteam kann diese Verantwortung nicht übernehmen, sie bleibt bei der Führung.
Responsible AI by Design: fünf Controls
Diese vier Prinzipien lassen sich in fünf konkrete Controls übersetzen. Responsible AI by Design heißt im Betrieb: fünf Dinge, die du bauen, messen und üben kannst.
- Data Governance: Herkunft, Labeling, Cleaning und Bias-Prüfung der Daten sind geregelt, nicht improvisiert.16
- Logging und Auditierbarkeit: Input, Output und Events sind über die Lebensdauer nachvollziehbar protokolliert.17
- Monitoring: Das System meldet selbst, wenn Qualität, Drift oder Risiko aus dem Rahmen laufen, statt dass es erst beim Kunden auffällt.18
- Human Oversight mit Stop und Override: Ein Mensch kann übersteuern und anhalten, mit Kompetenz und echter Autorität.19
- Incident Response: Für den Fehlerfall gibt es einen geübten Ablauf, nicht nur einen Verantwortlichen auf dem Papier.20
Die Reihenfolge ist kein Zufall. Ohne Daten keine belastbaren Outputs. Ohne Logs kein Audit. Ohne Monitoring kein früher Eingriff. Ohne Oversight kein Stop. Ohne geübte Incident Response kein Vertrauen, wenn es ernst wird.
Wo KI konkret wirkt: Engineering, Produktion, Service
Die Versuchung ist groß, KI nur über Assistenztools zu lesen. Der betriebliche Hebel ist breiter.
Engineering
Hier geht es um Geschwindigkeit ohne Qualitätsverlust: Review-Unterstützung, Testgenerierung, Simulation, Dokumentation oder Change-Impact. Die Management-Frage lautet damit: Wie sichern wir Traceability, Review und Definition of Done für KI-Artefakte?
Produktion
Hier geht es um Stabilität und Lernen zugleich: visuelle Qualitätsprüfung, Anomalieerkennung, Prozessfenster, Planung oder Wartung. Und genau hier zeigt sich der Unterschied zwischen Demo und Enabler, denn in der Produktion zählen Ausschuss, Stillstand, Drift, Safety und Auditierbarkeit. Gute Screenshots zählen nicht.
Service
Hier wird aus Tickets ein Feedback-Loop: Diagnose-Assistenten, Wissensdatenbanken, Remote-Assist oder bessere Einsatzplanung. Servicedaten verbessern dabei Engineering und Betrieb gleich mit, und genau diesen Hebel unterschätzen wir regelmäßig.
Umsetzung: 90 Tage, die nicht nach Pilot riechen
Schritt 1: Drei Use Cases schneiden
Wähle drei Use Cases, idealerweise je einen aus Engineering, Produktion und Service. Und entscheide pro Use Case gleich am Anfang, welche Stufe gemeint ist: Assistenz, Automatisierung oder teilweise Autonomie.
Schritt 2: Guardrails definieren
Drei Dinge müssen festgelegt sein, bevor irgendetwas produktiv geht:
- Risk Tolerance: Was ist nicht verhandelbar?
- Oversight: Wer überwacht wann und mit welcher Kompetenz?
- Stop- und Override-Mechanik: Wo liegt sie, und wer darf sie auslösen?
Wenn du in High-Risk-Kontexte fällst oder dorthin willst, orientiere dich systematisch an Risk Management, Data Governance, Record-Keeping und Human Oversight.21222324
Schritt 3: Logging und Traceability klein, aber konsequent bauen
Minimal heißt hier: klein startbar und voll ernst genommen. Vier Angaben reichen für den Anfang:
- Input: Was kam rein?
- Output: Was kam raus?
- Events: Was ist unterwegs passiert?
- Outcome: Was war am Ende das Ergebnis?
Gerade in High-Risk-Kontexten gehören Logs zur robusten Betriebsfähigkeit.25
Schritt 4: Ownership im Betrieb festnageln
Es braucht mindestens einen Owner für Outcome, einen Owner für Change und einen Owner für Betrieb und Incident Response. Und übt mindestens einen Incident als Trockenlauf, bevor er echt ist.
Schritt 5: Skalieren oder stoppen
Skalieren solltest du nur, wenn du beides gleichzeitig siehst, Wert und Kontrolle. Wenn du den Wert siehst, aber nicht die Kontrolle, dann ziehst du erst Govern, Measure und Manage nach.26
Anti-Patterns, die du früh erkennen kannst
Vier Muster tauchen dabei immer wieder auf, und alle vier sind früh sichtbar:
Wir machen erst mal einen Chatbot, ohne Outcome-Messung.- Autonomie ohne Stop/Override und ohne klare Verantwortung.2728
- Die Datenpipeline als Nebenprojekt, bei der Labeling, Cleaning und Bias-Prüfung zu spät auftauchen.2930
- Governance als Gremien-Queue statt als stabile Leitplanke.31
Die Reihenfolge, die trägt
Der Weg, der in der Praxis funktioniert, ist unspektakulär. KI startet als Assistenz, etwa in der visuellen Qualitätsprüfung: Das System markiert Auffälligkeiten, der Mensch entscheidet. Erst wenn das Team die Fehlalarme versteht, die Datenlabel stabil sind und der Stop-Mechanismus getestet ist, läuft ein abgegrenzter Teilbereich automatisch, während Randfälle eskalieren. Über Teilautonomie wird gesprochen, nachdem Logs, Oversight und Incident Response sitzen.
Zuerst skaliert die Operabilität, dann die Modellgenauigkeit.
Ampel-Check
Den Selbstcheck zu diesem Kapitel (5 Dimensionen, Grün/Gelb/Rot) findest du gebündelt im Anhang: Selbstcheck.
Takeaways
- KI wird zum Enabler, wenn du das System um das Modell herum führst.
- Die Reifegradleiter Assistenz, Automatisierung und teilweise Autonomie schafft Klarheit über Risiko und Betrieb.
- Governance ist Querschnittsfunktion und Lebenszyklus-Arbeit, kein Gatekeeper-Prozess.3233
- Data Governance und Logs sind zentrale Betriebsfähigkeiten für Nachvollziehbarkeit, Lernen und robusten Rollout.3435
- Human Oversight braucht Kompetenz, Autorität und eine echte Stop- oder Override-Mechanik.3637
- Führung trägt die Risikoentscheidungen und die Letztverantwortung.38
Damit steht das letzte Stück des German Way: KI wird zum Enabler, wenn Technik, Betrieb und Führung zusammenkommen.
Checkliste (Do this tomorrow)
- Wähle drei KI-Use-Cases und weise ihnen explizit Assistenz, Automatisierung oder teilweise Autonomie zu.
- Definiere für jeden Fall Risk Tolerance, Oversight und Stop-Mechanik.
- Baue Logging und Outcome-Messung klein, aber voll ernsthaft auf.
- Benenne Outcome-, Change- und Betriebsverantwortung explizit.
- Entscheide nach 90 Tagen nach Wert plus Kontrolle.
Schluss: Das Pulver gehört in den Maschinenraum
Wir sind beim Fundament gestartet, bei Stärken, die real sind. Dann kam die Reibung, die sie ausbremst. Dann der Bauplan: Wirkung statt Pilot-Prestige, Iterieren mit Guardrails, Zukunftsfähigkeit als Qualitätsversprechen, zwei Takte synchronisiert, KI als Enabler im Betrieb.
The German Way ist die Disziplin, Substanz schnell wirksam zu machen. Das Pulver ist da. Es liegt nur im Schaufenster statt im Maschinenraum.
Vor einigen Jahren sagte ein guter Freund einen Satz zu mir, wie man ihn abends so sagt: “Lass mal was zusammen starten.” Ich habe geantwortet, wie man darauf antwortet, halb ernst, halb Spaß: “Logo, das wird groß.”
Ziemlich genau zehn Jahre später hatten wir ein Unternehmen aufgebaut und für die nächste Wachstumsphase an einen neuen Eigentümer übergeben.
Was ich daran bis heute bemerkenswert finde: Der Satz hat nichts gekostet. Keine Analyse, kein Business Case, keine Freigabe. Er kostete nur den Mut, ihn ernst zu nehmen. Zwischen dem Abend und der Übergabe lagen zehn Jahre Arbeit, aber ohne diesen einen Satz hätte es sie nicht gegeben.
Solche Sätze fallen in deutschen Unternehmen jede Woche. In der Kantine, auf dem Parkplatz, nach dem Meeting, wenn die Folien schon zu sind. Meistens nickt jemand und geht zurück an die Arbeit.
Wie heißt es so schön: Und dann kam einer, der hat es einfach gemacht.
Bei mir liegt auch noch was im Schaufenster. Ich fange schon mal an.
Quellen
Autor, Arbeitsdefinition (Assistenz/Automatisierung/(Teil-)Autonomie als Reifegradleiter), synthesized 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), definition of “AI system” (varying levels of autonomy), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
Autor, Praxisbeobachtung (Demo vs Betrieb; Engpass Daten/Telemetrie/Ownership), synthesized 2026-03-14.↩︎
NIST AI RMF 1.0 online excerpt, “5 AI RMF Core” (four functions; not a checklist), https://airc.nist.gov/AI_RMF_Knowledge_Base/AI_RMF/Core_And_Profiles/5-sec-core, accessed 2026-03-14.↩︎
NIST AI RMF 1.0 online excerpt, “5 AI RMF Core” (govern cross-cutting; continuous lifecycle risk management), https://airc.nist.gov/AI_RMF_Knowledge_Base/AI_RMF/Core_And_Profiles/5-sec-core, accessed 2026-03-14.↩︎
Autor, Praxisbeobachtung (Governance als Gatekeeper vs Guardrails; Feedback nach hinten vs nach vorn), synthesized 2026-03-14.↩︎
NIST CSRC, NIST SP 800-218 (SSDF v1.1) publication page (Abstract), https://csrc.nist.gov/pubs/sp/800/218/final, accessed 2026-03-14.↩︎
Autor, Praxisbeobachtung (“Modell + UI” unterschlägt Systemanteile wie Data Governance/Logging/Oversight/Incident Response), synthesized 2026-03-14.↩︎
D. Sculley et al., “Hidden Technical Debt in Machine Learning Systems” (NeurIPS 2015) abstract, https://proceedings.neurips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 9 (risk management system; continuous iterative lifecycle process), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 10 (data and data governance), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 12 (record-keeping; automatic logs; post-market monitoring support), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14 (human oversight; level of autonomy; override/stop), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
NIST AI RMF Playbook, “Govern” (GOVERN 1.5 monitoring, incident response, appeal/override), https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Govern, accessed 2026-03-14.↩︎
NIST AI RMF Playbook, “Govern” (GOVERN 2.3 executive leadership responsibility), https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Govern, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 10 (data and data governance), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 12 (record-keeping; automatic logs; post-market monitoring support), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
NIST AI RMF 1.0 online excerpt, “5 AI RMF Core” (govern cross-cutting; continuous lifecycle risk management), https://airc.nist.gov/AI_RMF_Knowledge_Base/AI_RMF/Core_And_Profiles/5-sec-core, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14 (human oversight; level of autonomy; override/stop), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
NIST AI RMF Playbook, “Govern” (GOVERN 1.5 monitoring, incident response, appeal/override), https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Govern, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 9 (risk management system; continuous iterative lifecycle process), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 10 (data and data governance), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 12 (record-keeping; automatic logs; post-market monitoring support), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14 (human oversight; level of autonomy; override/stop), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 12 (record-keeping; automatic logs; post-market monitoring support), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
NIST AI RMF 1.0 online excerpt, “5 AI RMF Core” (govern cross-cutting; continuous lifecycle risk management), https://airc.nist.gov/AI_RMF_Knowledge_Base/AI_RMF/Core_And_Profiles/5-sec-core, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14 (human oversight; level of autonomy; override/stop), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
Autor, Praxisbeobachtung (Demo vs Betrieb; Engpass Daten/Telemetrie/Ownership), synthesized 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 10 (data and data governance), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
D. Sculley et al., “Hidden Technical Debt in Machine Learning Systems” (NeurIPS 2015) abstract, https://proceedings.neurips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html, accessed 2026-03-14.↩︎
Autor, Praxisbeobachtung (Governance als Gatekeeper vs Guardrails; Feedback nach hinten vs nach vorn), synthesized 2026-03-14.↩︎
NIST AI RMF 1.0 online excerpt, “5 AI RMF Core” (four functions; not a checklist), https://airc.nist.gov/AI_RMF_Knowledge_Base/AI_RMF/Core_And_Profiles/5-sec-core, accessed 2026-03-14.↩︎
NIST AI RMF 1.0 online excerpt, “5 AI RMF Core” (govern cross-cutting; continuous lifecycle risk management), https://airc.nist.gov/AI_RMF_Knowledge_Base/AI_RMF/Core_And_Profiles/5-sec-core, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 10 (data and data governance), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 12 (record-keeping; automatic logs; post-market monitoring support), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
NIST AI RMF Playbook, “Govern” (GOVERN 1.5 monitoring, incident response, appeal/override), https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Govern, accessed 2026-03-14.↩︎
Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14 (human oversight; level of autonomy; override/stop), https://eur-lex.europa.eu/eli/reg/2024/1689/oj, accessed 2026-03-14.↩︎
NIST AI RMF Playbook, “Govern” (GOVERN 2.3 executive leadership responsibility), https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Govern, accessed 2026-03-14.↩︎