Responsible AI braucht ein Managementsystem

Kaum ein Begriff wird in der AI-Diskussion so häufig verwendet wie Responsible AI. AI soll transparent sein, fair, sicher, datenschutzkonform, erklärbar und robust. Dagegen lässt sich kaum etwas einwenden. Schwieriger wird die nächste Frage: Wie wird aus diesen Prinzipien eine steuerbare Realität?

Responsible AI entsteht nicht durch eine Policy, ein Ethics Board oder eine Liste von AI Principles auf der Website. Sie muss im täglichen Betrieb funktionieren – und das wird umso wichtiger, je tiefer AI in Geschäftsprozesse, Produkte und Services integriert wird. Generative AI unterstützt Entscheidungen, greift auf Unternehmenswissen zu und interagiert mit Kunden. Mit Agentic AI kommt eine weitere Dimension hinzu: AI verwendet Werkzeuge und APIs, führt Prozessschritte aus und handelt innerhalb definierter Grenzen zunehmend selbständig. Damit verschiebt sich die Governance-Frage: Es geht nicht mehr nur darum, ob wir AI verantwortungsvoll entwickeln, sondern darum, wie wir AI verantwortungsvoll betreiben.

Diese Entwicklung ist auch in den Regulierungs- und Governance-Ansätzen sichtbar. Der NIST AI Risk Management Framework beschreibt Trustworthy AI über mehrere verbundene Eigenschaften – valid und zuverlässig, sicher, resilient, accountable, transparent, erklärbar, privacy-enhanced und fair – und warnt ausdrücklich davor, sie isoliert zu betrachten, weil zwischen ihnen Zielkonflikte entstehen. Der EU AI Act verlangt für High-Risk-AI Risikomanagement, Datenqualität, Logging und Traceability, Dokumentation, Human Oversight, Robustheit und Cybersecurity – und ein Quality Management System, das diese Anforderungen über den Lifecycle trägt. Die entscheidende Frage lautet deshalb nicht mehr «Welche Prinzipien verfolgen wir?», sondern: Wie können wir nachweisen, dass diese Prinzipien über den gesamten AI Lifecycle eingehalten werden?

Genau hier wird ISO/IEC 42001 interessant – und zwar weniger wegen der Controls in Annex A als wegen Annex C. Dort werden mögliche organisatorische Objectives für den verantwortungsvollen Umgang mit AI beschrieben: Accountability, AI Expertise, Data Quality, Environmental Impact, Fairness, Maintainability, Privacy, Robustness, Safety, Security sowie Transparency & Explainability. Auf den zweiten Blick steckt darin mehr als eine Liste von Qualitätszielen. Diese Objectives beschreiben gemeinsam, was eine Organisation beherrschen muss, wenn sie AI verantwortungsvoll einsetzen will – und sie zeigen, warum Responsible AI keine isolierte Disziplin sein kann. Data Quality braucht Data Governance, Privacy braucht Privacy Management, Security gehört ins ISMS, Maintainability führt ins Service Management, AI Expertise betrifft HR, Environmental Impact verbindet AI mit Sustainability und FinOps, Accountability reicht bis in die Corporate Governance.

Dieser Beitrag betrachtet die Objectives von Annex C deshalb nicht als weitere Compliance-Checkliste, sondern als Designprinzipien für ein integriertes AI Management System – und führt in zehn Kapiteln von den Prinzipien über die einzelnen Objectives bis zu dem, was am Ende zählt: Responsible AI Operations.

1. Responsible AI braucht mehr als Prinzipien

Kaum eine Organisation würde bestreiten, dass AI fair, sicher, transparent und nachvollziehbar eingesetzt werden sollte. Viele haben AI Principles formuliert oder erste AI Policies eingeführt. Das ist wichtig, löst das Problem aber nicht. Zwischen dem Bekenntnis zu Responsible AI und dem verantwortungsvollen Betrieb liegt eine erhebliche Lücke: Eine Organisation kann Fairness als Grundsatz definieren – ohne festgelegt zu haben, was Fairness für einen konkreten Use Case bedeutet und wie sie gemessen wird. Sie kann Transparenz fordern – ohne nachvollziehen zu können, welche Modelle, Daten, Prompts oder externen Services an einer Entscheidung beteiligt waren. Und sie kann Human Oversight verlangen – ohne geklärt zu haben, wann ein Mensch eingreifen muss und wie ein AI-System gestoppt werden kann. Responsible AI ist zunächst eine gute Absicht. Erst Governance macht daraus eine organisatorische Fähigkeit.

GenAI verschärft das Problem – Agentic AI verändert es grundlegend

Solange AI analysiert, klassifiziert oder empfiehlt, liegt die letzte Aktion beim Menschen. Diese Grenze verschiebt sich: AI Agents beschaffen Informationen, rufen APIs auf, lösen Workflows aus und führen innerhalb definierter Berechtigungen selbständig Aktionen durch. Damit wandert die zentrale Governance-Frage von «Ist der Output dieser AI vertrauenswürdig?» zu «Unter welchen Bedingungen darf diese AI handeln?» Drei Begriffe müssen dabei auseinandergehalten werden:

• Capability beschreibt, was eine AI kann.
• Authority definiert, was sie darf.
• Autonomy beschreibt, wie weit sie dabei ohne menschliche Entscheidung handeln kann.

Ein Fehler in einem Chatbot erzeugt eine falsche Antwort. Ein Fehler in einem Agenten löst eine falsche Aktion aus.

Regulation macht aus Prinzipien nachweisbare Anforderungen

Mit dem EU AI Act verschiebt sich die Frage erneut – von «Haben wir Responsible-AI-Principles?» zu «Können wir nachweisen, dass sie funktionieren?» Das verlangt Evidence: Wer war verantwortlich? Welche Risiken wurden bewertet? Welche Daten wurden verwendet? Welche Modellversion war produktiv? Welche Controls waren aktiv? Wie wurde die Performance überwacht? Wer hat Änderungen genehmigt? Responsible AI wird damit von einer Wertefrage zunehmend zu einer Assurance-Frage.

Responsible AI endet nicht mit dem Go-live

ISO/IEC 5338 beschreibt, was AI von klassischen Systemen unterscheidet: Datenabhängigkeit, probabilistisches Verhalten, eingeschränkte Vorhersagbarkeit, potentielle Autonomie sowie Data Drift und Concept Drift. Deshalb gehören Operation, Monitoring, Continuous Validation, Maintenance, Re-evaluation und Retirement zum AI-Lifecycle. Ein AI-System, das heute zuverlässig, fair und sicher arbeitet, muss dies morgen nicht automatisch auch tun: Daten verändern sich, Provider aktualisieren Modelle, Prompts werden angepasst, Knowledge Bases wachsen, Benutzer verwenden Systeme anders als erwartet. Governance muss deshalb über den gesamten Lifecycle funktionieren.

Genau hier beginnt die Bedeutung eines AIMS

Ein Artificial Intelligence Management System sollte nicht primär als zusätzliche Sammlung von AI Controls verstanden werden. Sein Wert liegt darin, AI systematisch zu steuern: Policies mit Verantwortlichkeiten zu verbinden, Risiken mit Controls, Controls mit Prozessen, Prozesse mit Rollen, Rollen mit Kompetenzen, AI-Systeme mit ihrem Lifecycle – und all dies mit Monitoring, Evidence und Continual Improvement. Das ist der Unterschied zwischen Responsible AI Principles und Responsible AI Management:

Principles → Objectives → Risks → Controls → Lifecycle → Evidence → Improvement

NIST bezeichnet AI-Systeme ausdrücklich als sozio-technische Systeme: Ihre Trustworthiness hängt nicht nur vom Modell ab, sondern von organisatorischem Verhalten, Daten, Entscheidungen der Betreiber und der Interaktion zwischen Menschen und AI. Deshalb kann Responsible AI nicht Aufgabe eines Data-Science-Teams allein sein. Sie ist eine Querschnittsfähigkeit der Organisation. Annex C lenkt den Blick weg von der Frage «Welche AI Controls brauchen wir?» hin zur fundamentaleren Frage: «Welche organisatorischen Ziele müssen wir beherrschen, damit AI verantwortungsvoll eingesetzt werden kann?»

2. Annex C zeigt, was Responsible AI eigentlich erreichen soll

Während sich die Aufmerksamkeit meist auf die Anforderungen des Managementsystems und die Controls in Annex A richtet, stellt Annex C eine andere Frage: Er beschreibt organisatorische Ziele und Risikofelder, die durch Entwicklung und Nutzung von AI beeinflusst werden. Entscheidend ist nicht die Liste, sondern der Perspektivwechsel: Responsible AI beginnt nicht bei der Frage, welche Controls implementiert werden müssen, sondern bei der Frage, welche Ziele eine Organisation mit ihrer AI Governance schützen und erreichen will.

Annex C ist keine Responsible-AI-Checkliste

Es wäre verlockend, die Objectives wie eine Compliance-Checkliste abzuhaken: Accountability erfüllt, Privacy erfüllt, Security erfüllt. Genau das würde den Wert verfehlen. Die Objectives beeinflussen sich gegenseitig – und geraten teilweise in Konflikt:

• Maximale Transparenz kann Privacy, Intellectual Property oder Security beeinträchtigen.
• Ein auf Accuracy optimiertes Modell kann für einzelne Personengruppen schlechtere Ergebnisse produzieren.
• Zusätzliche Robustness braucht mehr Tests, Redundanz oder Rechenleistung – und erhöht den Environmental Impact.
• Mehr Automatisierung steigert Effizienz, macht Accountability und Human Oversight aber anspruchsvoller.

Responsible AI bedeutet deshalb nicht «alle Objectives maximieren», sondern: die für den Kontext relevanten Objectives identifizieren, ihre Wechselwirkungen verstehen und bewusste, risikobasierte Entscheidungen treffen. Damit wird Responsible AI zu einer Managemententscheidung.

Die elf Objectives im Überblick

• Accountability – das organisatorische Fundament. Wer verantwortet das AI-System, den Use Case, die Risiken? Wer darf die Autonomie erhöhen, wer kann den Einsatz stoppen? Capability beschreibt, was AI kann; Authority definiert, was sie darf; Accountability bestimmt, wer dafür verantwortlich bleibt.
• AI Expertise – betrifft längst nicht nur Data Scientists. Management, Risk, Security, Procurement, Service Management und Fachverantwortliche müssen beurteilen können, was sie steuern. Besitzt die Organisation genügend AI Capability, um die Verantwortung zu tragen, die sie mit AI eingeht?
• Training and Test Data – bei Machine Learning entsteht Verhalten nicht durch Code, sondern durch Daten. Data Quality ist kein technisches Vorproblem von AI Governance; sie ist Teil davon. Bei GenAI kommen Knowledge Bases, Retrieval Sources und Context hinzu.
• Fairness – «unsere AI soll fair sein» ist als Prinzip sinnvoll, als Objective aber nicht operationalisierbar. Fair gegenüber wem, nach welchem Massstab, mit welchen Schwellenwerten? Fairness bleibt eine organisatorische Wertentscheidung.
• Privacy – Datenschutz beginnt nicht mit AI. Das AIMS darf keine zweite Privacy Governance aufbauen, sondern muss AI Use Cases in die bestehenden Mechanismen integrieren.
• Robustness, Safety, Security – Robustness betrifft zuverlässiges Funktionieren unter schwierigen Bedingungen, Safety mögliche Schäden, Security Manipulation und Angriffe. Mit zunehmender Autonomie wachsen die drei zusammen: Eine Prompt Injection ist ein Security-Problem, führt aber zur Safety-Frage, wenn ein Agent deshalb falsch handelt.
• Transparency & Explainability – Transparency schafft Sichtbarkeit über System und Kontext, Explainability über Verhalten und Ergebnisse. Bei Agentic AI kommt Traceability hinzu: Welche Aktion, mit welcher Identity, aufgrund welcher Informationen?
• Maintainability – wirkt unspektakulär, gehört aber zu den wichtigsten Objectives. Ein AI-System, das heute die Anforderungen erfüllt, erfüllt sie morgen nicht automatisch.
• Environmental Impact – AI braucht Compute, Energie und Hardware. Mit GenAI und Agents steigt die Bedeutung der laufenden Inference. Steht der Ressourcenverbrauch im Verhältnis zum Business Value?

Elf Objectives – aber ein Governance-System

Die Objectives lassen sich einzeln beschreiben, funktionieren aber als System: Data Quality beeinflusst Fairness und Robustness. AI Expertise beeinflusst praktisch alles. Transparency ermöglicht Accountability. Maintainability sichert langfristige Robustness und Security. Privacy kann mit Transparency in Konflikt geraten. Environmental Impact steht im Spannungsverhältnis zu Performance.

Responsible AI Objectives → Kontext & Stakeholder → Risiken & Auswirkungen → bewusste Trade-offs → Controls & Verantwortlichkeiten → Monitoring & Evidence → Continual Improvement

3. Accountability: Wenn AI handelt, muss Verantwortung menschlich bleiben

Accountability ist wahrscheinlich das Objective, dessen Bedeutung mit dem Übergang zu Agentic AI am stärksten zunimmt. Solange AI Empfehlungen abgibt, ist die Verantwortungsfrage vertraut: Ein Mensch entscheidet, was mit dem Output geschieht. Wenn Agents Tools verwenden, Workflows auslösen und Aktionen in operativen Systemen ausführen, entsteht eine neue Frage: Was bedeutet Accountability, wenn der Handelnde nicht mehr der Verantwortliche ist?

Autonomie verändert Verantwortung – sie beseitigt sie nicht

Technisch können wir AI mehr Autonomie übertragen. Organisatorisch können wir damit nicht die Verantwortung delegieren. Ein Agent kann technisch in der Lage sein, einen Benutzeraccount zu sperren. Das heisst nicht, dass er dazu autorisiert sein sollte. Wird ihm diese Authority erteilt, muss entschieden werden, unter welchen Bedingungen er autonom handeln darf – und wer dafür verantwortlich ist.

Mit zunehmender Autonomie droht eine Responsibility Gap: Bei einer problematischen Entscheidung beginnt die Suche nach dem Verantwortlichen – der Entwickler, der Anbieter des Foundation Models, der Prompt-Ersteller, der Data Owner, der Fachbereich, der Service Owner, der Benutzer? Komplexe AI-Systeme bestehen aus Ketten von Komponenten und erstrecken sich über mehrere Organisationen. Accountability muss deshalb explizit gestaltet werden.

Accountability braucht Ownership

Die einfachste und wirkungsvollste Regel lautet: Kein produktives AI-System ohne benannten Owner. Das klingt trivial, ist es aber nicht – AI Use Cases entstehen dezentral: SaaS mit integrierter AI, selbst konfigurierte Assistants, externe Modelle über APIs, zentrale AI Services. Je nach Operating Model braucht es mehrere Rollen:

• Business Owner – Zweck und Business Outcome
• AI System / Capability Owner – die AI-Fähigkeit und deren Lifecycle
• Service Owner – der Service, in den AI integriert ist
• Data Owner – relevante Daten und deren zulässige Nutzung
• Risk Owner – Akzeptanz und Behandlung der Risiken
• Technical Owner – Plattform und Betrieb
• Supplier Owner – externe Provider und Abhängigkeiten

Mehr Rollen bedeuten aber nicht bessere Accountability. Wenn sechs Personen «mitverantwortlich» sind, ist am Ende niemand verantwortlich. Jedes AI-System braucht eine eindeutig benannte Accountability. Shared contribution is necessary. Shared accountability is dangerous.

Accountability beginnt zudem nicht beim Betrieb, sondern bei der Entscheidung, AI überhaupt einzusetzen: Welches Problem soll AI lösen? Warum ist AI dafür geeignet? Welche Stakeholder sind betroffen, welche Schäden möglich, welche Autonomie vorgesehen? Wer akzeptiert das verbleibende Risiko?

Von Human in the Loop zu Human in the Lead

Ein Mensch, der jede AI-Entscheidung bestätigen muss, schafft noch keine gute Governance. Bei tausenden Entscheidungen pro Stunde ist das unrealistisch, und eine formale Freigabe kann eine Illusion menschlicher Kontrolle erzeugen. Entscheidend ist nicht, dass ein Mensch immer im operativen Loop sitzt, sondern dass Menschen die Regeln des Loops bestimmen: Welche Entscheidungen darf AI treffen? Welche Grenzen gelten? Wann muss eskaliert werden? Wann ist Freigabe zwingend? Wann wird die Autonomie reduziert oder das System gestoppt?

Accountability sollte mit Autonomie und Impact skalieren:

• AI informiert → menschliche Entscheidung
• AI empfiehlt → Mensch bewertet und entscheidet
• AI entscheidet mit Freigabe → AI bereitet vor, Mensch autorisiert
• AI handelt begrenzt autonom → innerhalb definierter Guardrails
• AI handelt weitgehend autonom → starke Governance, Monitoring, Logging, Reversibility und Eskalation erforderlich

Nicht die Intelligenz eines Systems bestimmt den Governance-Bedarf. Entscheidend sind Authority, Autonomy und Impact.

Accountability braucht Traceability – und endet nicht an der Unternehmensgrenze

Verantwortung ohne Nachvollziehbarkeit bleibt theoretisch. Wer für AI-Entscheidungen verantwortlich ist, muss rekonstruieren können, was geschehen ist. Bei einem Agenten heisst das: Agent Identity → Auftrag → Context → Modellversion → Tool/API → Berechtigung → Entscheidung → Aktion → Ergebnis → Human Override. Logging dient damit nicht mehr nur der Fehleranalyse. Es wird zu Governance Evidence. Und weil die meisten Organisationen Foundation Models, SaaS und AI Services externer Anbieter nutzen, muss das AIMS mit Supplier Management verbunden sein: Welche Modelle verwendet der Provider, wie werden Änderungen angekündigt, welche Logs stehen zur Verfügung, wie werden Incidents gemeldet, was geschieht bei einem Model Change? Technische Verantwortung lässt sich vertraglich verteilen – Accountability gegenüber Kunden, Mitarbeitenden und Behörden nicht.

Accountability muss operationalisiert und messbar werden

Die Policy-Aussage «Accountability must be established» reicht nicht. Sie muss in Managementmechanismen übersetzt werden: AI Inventory ohne System ohne registrierten Owner, Risk Assessments mit benanntem Risk Owner, Service Ownership für AI-enabled Services, kontrollierte Änderungen an Modellen, Daten, Prompts und Autonomie, eigene Identitäten für Agents, definierte Eskalationswege für AI Incidents. Und sie braucht Kennzahlen, die mehr über gelebte Accountability aussagen als eine unterschriebene AI Policy:

• Ownership Coverage – Anteil der AI-Systeme mit eindeutigem Owner
• Autonomy Coverage – Anteil produktiver Systeme mit explizit definiertem Autonomiegrad
• Decision Traceability – Anteil kritischer Entscheidungen, die rekonstruiert werden können
• Human Override Rate – wie häufig Menschen AI-Entscheidungen korrigieren
• Accountability Exceptions – produktive Systeme ohne vollständig definierte Ownership, Authority oder Eskalation

Die Zukunft wird nicht darin bestehen, dass Menschen jede AI-Aktion freigeben. Menschliche Verantwortung verschiebt sich von der einzelnen Aktion zur Gestaltung, Autorisierung, Überwachung und Überprüfung des Systems. Die Frage lautet deshalb nicht «War ein Mensch im Loop?», sondern: «War ein Mensch in der Führung?»

4. Data Quality, Fairness und Privacy: Responsible AI beginnt bei den Daten

In Governance-Modellen werden diese drei Themen getrennt behandelt: Data Quality gehört zur Data Governance, Privacy zum Datenschutz, Fairness zur Ethics-Diskussion. Für AI funktioniert diese Trennung nur bedingt. Dieselben Daten, die bestimmen, ob ein System fachlich zuverlässig arbeitet, bestimmen auch, ob Gruppen benachteiligt werden und ob personenbezogene Informationen rechtmässig verarbeitet werden.

Data → Context → AI Behaviour → Decision → Impact

Wer nur das Modell kontrolliert, setzt zu spät an.

Data Quality bedeutet bei AI mehr als korrekte Daten

Ein Datensatz kann technisch korrekt und trotzdem für einen Use Case ungeeignet sein. Entscheidend ist Fitness for Purpose: Repräsentieren die Daten den Einsatzkontext? Sind relevante Gruppen und Situationen vertreten? Sind sie aktuell, ist ihre Herkunft nachvollziehbar, dürfen sie für diesen Zweck verwendet werden? ISO/IEC 5338 adressiert Data Drift und Concept Drift als AI-spezifische Veränderungen, die dazu führen, dass die ursprüngliche Leistungsfähigkeit im Betrieb nicht erhalten bleibt. Data Quality ist bei AI keine einmalige Eingangskontrolle – sie ist eine Lifecycle Capability.

Bei Generative AI reicht der Blick auf Trainingsdaten nicht mehr. Ein AI Assistant basiert auf einem Foundation Model, dessen Trainingsdaten die Organisation weder kennt noch kontrolliert, und erhält seinen Kontext aus Prompts, System Prompts, RAG-Dokumenten, Knowledge Bases, Conversation History und angebundenen Business Applications. Ein leistungsfähiges Modell mit veralteter Knowledge Base liefert überzeugend falsche Antworten. Ein Agent führt auf Basis mangelhafter Stammdaten eine technisch einwandfreie, geschäftlich aber falsche Aktion aus.

Training Data Quality → Context Quality → Knowledge Quality → Decision Quality → Action Quality

Fair gegenüber wem?

Enthalten Daten historische Verzerrungen, übernimmt AI diese Muster. Aber Fairness ist komplexer als «Bias entfernen». NIST betont den sozio-technischen Charakter: Fairness kann nicht allein am Modell beurteilt werden. Daraus folgt eine unangenehme Erkenntnis: Fairness lässt sich nicht vollständig an Data Scientists delegieren. Bevor sie gemessen werden kann, muss die Organisation definieren, was sie im Kontext darunter versteht: Welche Gruppen sind betroffen? Welche Unterschiede in der Behandlung sind sachlich gerechtfertigt, welche problematisch? Welche Metrik ist angemessen, welche Abweichung tolerierbar, wer entscheidet über den Schwellenwert? Verschiedene Fairness-Metriken können zu unterschiedlichen Ergebnissen führen – Fairness wird damit zur Governance-Entscheidung:

Stakeholder → Impact → Fairness Objective → Metric → Threshold → Monitoring → Escalation

Und Fairness ist keine einmalige Prüfung vor dem Go-live. Benutzerpopulation, Geschäftsprozesse, Datenverteilungen und Modellversionen verändern sich. Ein Fairness Assessment ist keine Freigabe für die Lebensdauer eines AI-Systems.

Und dann kommt Privacy

Die naheliegende Reaktion auf Data-Quality- und Fairness-Probleme lautet: Wir brauchen mehr Daten. Genau hier entsteht der Zielkonflikt: Data Quality sagt, wir benötigen zusätzliche Daten. Fairness sagt, wir müssen bestimmte Merkmale kennen, um Benachteiligungen zu erkennen. Privacy fragt: Dürfen und sollen wir diese Informationen überhaupt verarbeiten? GenAI verändert das Privacy-Risiko zusätzlich, weil Daten auf neuen Wegen in AI-Systeme gelangen – kopierte Prompts, eingebundene Dokumente, gespeicherte Conversation History, Agents mit Zugriff auf CRM, ERP, HR und Service-Management-Systeme. Die Frage lautet nicht mehr «Welche Daten verarbeitet das Modell?», sondern «Auf welche Informationen kann das gesamte AI-System zugreifen?»

Organisationen mit etabliertem Datenschutz besitzen die Mechanismen bereits: Privacy Impact Assessments, Verarbeitungsverzeichnisse, Zugriffskontrollen, Löschkonzepte, Betroffenenrechte. Ein integriertes AIMS bindet AI Use Cases systematisch darin ein – etwa indem ein AI Impact Assessment automatisch prüft, ob ein Privacy Impact Assessment nötig ist, oder ein Use Case ohne geklärte Data Ownership nicht in die nächste Lifecycle-Phase gelangt.

Die drei Objectives bilden einen Regelkreis

Data Lineage – Herkunft, Version, Transformationen, Qualitätsprüfungen, Nutzungsbedingungen – wird damit zu Evidence für Responsible AI. AIMS, Data Governance, Privacy Management, Risk Management, Information Security, Business Ownership und Model/Data Teams dürfen nicht wie einzelne Kontrollstationen nacheinander arbeiten, sondern müssen Teil desselben Lifecycle-Prozesses sein:

• Welche Daten haben wir? → Data Quality
• Welche Auswirkungen entstehen für Stakeholder? → Fairness
• Welche Daten dürfen wir verwenden und wie schützen wir sie? → Privacy
• Verändert sich etwas im Betrieb? → Monitoring
• Müssen Daten, Modell oder Controls angepasst werden? → Continual Improvement

Data Quality bestimmt, worauf AI ihre Entscheidungen stützt. Fairness betrachtet, wie sich diese Entscheidungen auswirken. Privacy setzt Grenzen, welche Informationen dafür verwendet werden dürfen. Responsible AI entsteht dort, wo eine Organisation alle drei Perspektiven gleichzeitig beherrscht.

5. Robustness, Safety und Security: Wenn aus falschen Antworten falsche Aktionen werden

Die drei Begriffe adressieren unterschiedliche Fragen – Robustness: Funktioniert das System auch unter unerwarteten Bedingungen? Safety: Kann durch sein Verhalten Schaden entstehen? Security: Ist es gegen Manipulation und unberechtigten Zugriff geschützt? Bei klassischen Systemen lassen sich diese Perspektiven trennen. Bei AI verschwimmen die Grenzen: Eine Security-Schwachstelle verändert das Verhalten, ein Robustness-Problem führt zu einer gefährlichen Aktion, ein Safety-Control hängt von Security-Mechanismen ab.

Robustness bedeutet kontrolliertes Verhalten ausserhalb des Idealfalls

ISO/IEC 5338 beschreibt AI als probabilistisch, datenabhängig und in ihrem Verhalten schwer vorhersehbar. Die relevante Frage lautet nicht «Funktioniert das System?», sondern: «Funktioniert es auch dann ausreichend zuverlässig, wenn die Bedingungen nicht den getesteten entsprechen?» Was geschieht bei unvollständigen oder widersprüchlichen Daten, bei ausgefallenen Datenquellen, bei unerwarteten Tool-Fehlern, bei manipuliertem Context? Und erkennt das System, wenn es die Grenzen seiner Verlässlichkeit erreicht? Ein robustes System muss nicht unter allen Umständen eine Antwort liefern. Die verantwortungsvollste Reaktion kann sein: nicht entscheiden, nicht handeln, eskalieren. Fallback, Graceful Degradation, Confidence Thresholds und Human Escalation werden damit zu Governance-relevanten Designentscheidungen.

Agentic AI verändert den Charakter des Risikos

Ein LLM kann halluzinieren. Ein Chatbot gibt deshalb eine falsche Antwort. Ein Agent führt auf Basis derselben Information eine Aktion aus – versendet eine Nachricht, verändert einen Datensatz, sperrt einen Benutzer, startet einen Workflow. Damit verändert sich das Risikomodell:

• Generative AI: Input → Model → Output → Mensch → Aktion
• Agentic AI: Input → Model → Entscheidung → Tool/API → Aktion

Der Mensch befindet sich nicht mehr zwischen AI Output und realer Wirkung. Je weiter ein System in der Kette AI Behaviour → Decision → Action → Impact selbständig voranschreitet, desto stärker wird Safety zur zentralen Governance-Frage.

Security schützt auch AI-Verhalten

Klassische Informationssicherheit schützt Vertraulichkeit, Integrität und Verfügbarkeit. Bei AI kommt hinzu: die Integrität des Verhaltens. Ein Angreifer muss das System nicht übernehmen – es reicht, den Context zu manipulieren, auf dessen Grundlage es entscheidet. Ein Beispiel: Ein Agent im Service Management analysiert Incidents, liest Tickets und Knowledge Articles und führt bei Standardfällen selbständig Aktionen aus. Ein manipulierter Inhalt enthält eine Anweisung, die ursprünglichen Instruktionen zu ignorieren. Das ist gleichzeitig ein Security-Problem (Manipulationsversuch), ein Robustness-Problem (unerwartete Eingabe), ein Safety-Problem (schädliche Aktion), ein Accountability-Problem (wer ist verantwortlich?) und ein Transparency-Problem (lässt sich die Aktion rekonstruieren?). Genau deshalb sollte Annex C nicht als Liste isolierter Objectives gelesen werden.

Least Privilege wird für Agents fundamental

Ein Agent braucht Identity und Authority. Er sollte nicht die Berechtigungen des Benutzers übernehmen oder mit einem weitreichenden technischen Account arbeiten. Zu klären ist: Welche Systeme darf er ansprechen? Welche Daten lesen, welche verändern? Welche Aktionen selbständig ausführen, welche nur mit Freigabe? Wie lange gelten Berechtigungen, wie werden Credentials geschützt, wie kann die Berechtigung sofort entzogen werden? Capability und Authority müssen bewusst getrennt bleiben.

Safety braucht zudem Grenzen, nicht nur Überwachung: Action Boundaries, Approval Gates für kritische Aktionen, Transaktionslimiten, Tool Allow Lists, Input- und Output-Validation, Rate Limits, sichere Default-Zustände und automatische Unterbrechung bei Abweichungen. Bei kritischen Aktionen ist Reversibility entscheidend: Je weniger reversibel eine AI-Aktion ist, desto höher müssen Validation, Authority und Human Oversight sein.

Ein AIMS ersetzt kein ISMS

Security lässt sich nicht kurz vor dem Go-live durch einen Penetration Test hinzufügen. Risiken entstehen bei der Modellwahl, bei Trainingsdaten, Architektur, Schnittstellen, externen Services und Berechtigungen – und im Betrieb kommen neue hinzu, wenn Modelle, Provider, Datenquellen und Tools sich verändern. Secure AI Development reicht nicht; es braucht einen Secure AI Lifecycle. Eine Organisation mit ISMS nach ISO/IEC 27001 besitzt die wesentlichen Fähigkeiten bereits: Risk Management, IAM, Vulnerability Management, Supplier Security, Incident Management, Logging, Change Management. Das AIMS erweitert sie um AI-spezifische Risiken:

• Das Asset Inventory erfasst AI-Systeme und Modelle.
• IAM berücksichtigt Agent Identities.
• Supplier Risk Management bewertet Foundation-Model- und AI-Service-Provider.
• Vulnerability Management und Security Monitoring kennen AI-spezifische Schwachstellen und Angriffsmuster.
• Incident Management behandelt AI Incidents; Change Management Model-, Prompt-, Data- und Agent-Änderungen.

Von Model Security zu System Resilience

Nicht jede AI braucht jeden Control. Die Intensität der Governance muss vom Kontext abhängen: Impact × Autonomy × Exposure × Reversibility. Und Responsible AI darf nicht nur fragen, ob das Modell sicher ist. Ein modernes AI-System besteht aus Model, Data, Prompt, Context, Knowledge Base, Agent, Identity, Tools, APIs, Infrastructure, Provider und Human Interaction. Ein sicheres Modell in einer unsicheren Agent-Architektur ist kein sicheres AI-System. Die Betrachtung muss sich verschieben: Model Risk → AI System Risk → AI-enabled Service Risk → Business Risk. Je stärker AI selbständig handelt, desto kürzer wird der Weg von Wrong Output über Wrong Decision zu Wrong Action mit Business Impact. Aus klassischer AI Security wird damit etwas Grösseres: AI Resilience als gemeinsame Fähigkeit von AIMS, ISMS, Service Management und Business Continuity.

6. Transparency & Explainability: Ohne Nachvollziehbarkeit keine Governance

Beide Begriffe werden häufig verkürzt auf die Frage: «Kann die AI erklären, warum sie zu diesem Ergebnis gekommen ist?» Für ein AI Management System greift das zu kurz. Eine Organisation muss auch wissen, welches AI-System eingesetzt wird, wofür, mit welchen Daten und Modellen, mit welchen Grenzen – und zunehmend: welche Aktionen daraus entstanden sind. Aus Model Explainability wird System Transparency, Decision Traceability und Action Traceability. Responsible AI verlangt nicht in jedem Fall vollständige technische Erklärbarkeit. Aber sie verlangt ausreichende organisatorische Nachvollziehbarkeit.

Transparency und Explainability sind nicht dasselbe

Transparency schafft Sichtbarkeit darüber, was ein System ist und wie es eingesetzt wird: Zweck, Verantwortliche, Modell, Datenquellen, Provider, Einschränkungen, Autonomie. Explainability fragt, ob ein konkretes Ergebnis für relevante Stakeholder verständlich gemacht werden kann: Warum diese Empfehlung? Warum wurde ein Fall anders behandelt? Warum hat ein Agent diese Aktion gewählt? Ein System kann transparent dokumentiert sein, ohne dass jede Modellentscheidung erklärbar ist – und umgekehrt. Responsible AI braucht beides.

Erklärbarkeit ist zudem keine absolute Eigenschaft. Ein Data Scientist braucht eine andere Erklärung als die Geschäftsleitung, ein Auditor andere Informationen als ein Benutzer, ein betroffener Kunde wieder eine andere Form. Die Frage lautet deshalb nicht «Ist unsere AI erklärbar?», sondern: «Was muss für wen, zu welchem Zweck und in welcher Tiefe nachvollziehbar sein?» NIST verbindet Transparency ausdrücklich mit Accountability: Ohne Informationen über Design, Betrieb und Nutzung lässt sich keine Verantwortung zuordnen. Zu «Accountability braucht Ownership» kommt: Accountability braucht Traceability.

Generative und Agentic AI verändern die Explainability-Frage

Bei klassischem Machine Learning fragte Explainability nach Features und Scores. Ein LLM-Output wird dagegen von vielen Faktoren beeinflusst: Model, Model Version, System Prompt, User Prompt, Context, Retrieval Data, Conversation History, Parameter, Guardrails. Gibt ein AI Assistant eine falsche Auskunft, kann die Ursache eine veraltete Knowledge Base sein, ein falsches Retrieval, ein geänderter System Prompt oder eine neue Modellversion des Providers. Explainability wird zur Systemeigenschaft. Bei Agenten kommt die Frage «Warum hat der Agent diese Aktion ausgeführt?» hinzu – und damit eine neue Traceability Chain:

Identity → Context → Reasoning/Decision → Authority → Tool → Action → Outcome

Wir müssen dabei nicht die «Gedanken» einer AI protokollieren. Governance braucht die relevanten Inputs, Entscheidungen, Systemzustände und Aktionen: Welche Version war aktiv? Welche Datenquellen wurden verwendet? Welche Policies galten? Welche Tools standen zur Verfügung? Welche Aktion wurde ausgelöst, welche Freigabe lag vor, welche Wirkung entstand? Nicht vollständige interne Erklärbarkeit, sondern ausreichende Governance Traceability. Configuration Management wird dabei unterschätzt: Das Verhalten hängt von einer Kombination aus Application Version, Model Version, Trainingsdaten, System Prompt, RAG-Konfiguration, Knowledge Base, Guardrails, Tools und Agent-Konfiguration ab. Die Configuration-Item-Struktur endet nicht beim Modell.

Transparency beginnt mit einem AI Inventory

Bevor eine Organisation AI erklären kann, muss sie wissen, wo AI überhaupt eingesetzt wird – und das wird mit eingebetteter AI in SaaS-Produkten, Collaboration Tools, Security Tools und dezentralen Assistants zunehmend schwierig. Ein AI Inventory ist deshalb ein grundlegendes Governance-Instrument. Es ist keine Liste von Tools, sondern erfasst pro AI-System: Use Case, Business und Service Owner, Purpose, Provider und Modell, Risikoklassifikation, betroffene Stakeholder, verwendete Daten, Autonomy Level, Integrationen, Lifecycle Status und relevante Annex-C-Objectives.

Transparenz betrifft auch Benutzer und Betroffene: dass AI eingesetzt wird, wofür, mit welchen Grenzen, ob ein Mensch die Entscheidung prüft, wie ein Ergebnis angefochten werden kann. Mehr Transparenz ist aber nicht automatisch besser – vollständige Offenlegung technischer Details kann Security gefährden, Privacy verletzen oder Intellectual Property betreffen. Responsible AI bedeutet nicht maximale, sondern angemessene Transparenz für den jeweiligen Stakeholder und Zweck. Und Explainability braucht Eskalationsfähigkeit: Kann ein Ergebnis mit relevantem Impact nicht ausreichend erklärt werden, muss die Organisation entscheiden, ob eine Human Review nötig ist oder die zulässige Autonomie reduziert werden muss. Je höher der Impact, desto höher die erforderliche Nachvollziehbarkeit.

Von Explainable AI zu Explainable Organisation

Die benötigten Capabilities existieren meist bereits: Configuration Management kennt Versionen, Service Management kennt Ownership und Changes, das ISMS kennt Logging und Audit Trails, Data Governance kennt Lineage, Supplier Management kennt Abhängigkeiten. Das AIMS baut sie nicht ein zweites Mal auf – es sorgt dafür, dass sie gemeinsam eine ausreichende AI Traceability Chain erzeugen. Und es führt zu einer weitergehenden Interpretation von Annex C: Nicht nur das Modell muss erklärbar sein. Die Organisation selbst muss erklären können, welche AI sie einsetzt, warum, wer verantwortlich ist, welche Risiken identifiziert wurden, welche Autonomie das System hat, wie es überwacht wird und was geschieht, wenn etwas nicht funktioniert. Das ist Explainable Governance.

7. AI Expertise und Maintainability: Responsible AI ist eine dauerhafte Capability

Zwei Objectives wirken weniger spektakulär als Fairness oder Security – und werden gerade deshalb unterschätzt. Sie adressieren eine zentrale Herausforderung: Eine Organisation muss AI nicht nur verantwortungsvoll einführen, sondern diese Fähigkeit dauerhaft erhalten. Modelle werden aktualisiert, Daten verändern sich, Provider ändern Services, neue Schwachstellen und Regulierungen entstehen. Gleichzeitig müssen die Menschen, die über AI entscheiden, diese Entwicklungen verstehen. Eine Organisation kann AI langfristig nur verantwortungsvoll betreiben, wenn sich ihre Kompetenzen mindestens so schnell weiterentwickeln wie ihre AI-Systeme.

AI Expertise ist mehr als AI Literacy

Mitarbeitende müssen verstehen, was AI kann und wo ihre Grenzen liegen. Für ein AIMS reicht allgemeine AI Literacy jedoch nicht. Ein Benutzer muss wissen, was er eingeben darf und wann eine Überprüfung nötig ist. Ein Service Owner muss Risiken eines AI-enabled Service beurteilen können. Security braucht Kenntnisse über Prompt Injection, Data Poisoning und Agent Identities. Data Governance muss verstehen, wie Provenance und Drift das Verhalten beeinflussen. Procurement muss Anforderungen an Provider stellen. Und das Management muss verstehen, welche Verantwortung mit der Freigabe von AI verbunden ist. AI Expertise ist eine verteilte organisatorische Capability – differenziert nach Rollen:

• Awareness – AI verantwortungsvoll nutzen können
• Practitioner Expertise – AI-Systeme entwickeln, konfigurieren, betreiben oder kontrollieren können
• Governance Expertise – Risiken, Verantwortlichkeiten und Controls beurteilen können
• Decision Expertise – ausreichend verstehen, um Managemententscheidungen zu treffen

Der EU AI Act macht AI Literacy zur Pflicht – risikobasiert, abhängig von Wissen, Erfahrung und Einsatzkontext. ISO/IEC 5338 betrachtet Human Resource Management als Lifecycle-Prozess: Neue Modelle, neue Angriffsmethoden und der Übergang vom Assistant zum autonomen Agenten verlangen neue Kompetenzen. Competence Management wird Teil von Continual Improvement. Und weil Data Scientists Modelle verstehen, Security Bedrohungen, Legal Anforderungen, Service Management den Betrieb und Audit Evidence, braucht Responsible AI keine grosse zentrale AI-Governance-Organisation, sondern einen Mechanismus, der bestehende Kompetenzen an den relevanten Entscheidungspunkten zusammenbringt – ob AI Governance Board, Center of Excellence oder Community of Practice.

Maintainability beginnt dort, wo das AI-Projekt endet

Viele AI-Initiativen werden wie Projekte behandelt: Use Case, Modell, Proof of Concept, Test, Go-live. Aus Sicht von Responsible AI beginnt dort ein neuer Teil des Risikos. AI-Systeme altern anders als klassische Software: Sie können sich verändern, ohne dass der Code geändert wird. Umwelt, Daten, Benutzerverhalten und Geschäftsprozesse verschieben sich – Data Drift und Concept Drift entstehen. Maintainability bedeutet deshalb nicht «Können wir das System technisch warten?», sondern: «Können wir sicherstellen, dass es über seine Lebensdauer für seinen Zweck geeignet bleibt?»

Bei GenAI hängt das Verhalten eines Service von Application, Foundation Model, System Prompt, Knowledge Base, Retrieval-Konfiguration, Guardrails, APIs, Tools und Provider Services ab – und jede Komponente kann sich ändern. Die Frage lautet nicht mehr «Welche Softwareversion läuft produktiv?», sondern «Welche Kombination von Komponenten erzeugt aktuell das Verhalten unseres AI-enabled Service?» Besonders kritisch: Ein Provider stellt eine neue Modellversion bereit, die API funktioniert weiter, das Verhalten ändert sich trotzdem. Ein Supplier Change verändert den eigenen Service, ohne dass die eigene Applikation geändert wurde. Bei Agents erweitert ein neues Tool nicht nur die Funktionalität, sondern die Authority. Change Management muss deshalb fragen: Verändert dieser Change Capability, Authority, Autonomy oder Impact? Wenn ja, braucht es eine erneute Risikobewertung.

Maintainability braucht Continuous Validation und ein Betriebsmodell

Ein AI-System muss auch dann überprüft werden, wenn formal kein Change stattgefunden hat: Performance, Accuracy, Hallucination Rates, Drift, Fairness Metrics, Security Events, Human Overrides, Nutzerbeschwerden, unerwartete Agent Actions. Die Managementlogik bleibt gleich:

Expected Behaviour → Measurement → Threshold → Deviation → Action

Hier zeigt sich eine Schwäche vieler AI-Governance-Ansätze: Sie konzentrieren sich auf die Freigabe. Responsible AI braucht ebenso ein Modell für die Zeit danach: Wer überwacht das System? Wer bewertet Abweichungen, entscheidet über Changes, behandelt Incidents? Wann wird revalidiert, wann die Autonomie reduziert, wann ein Modell ersetzt, wann das System ausser Betrieb genommen? Diese Fragen führen direkt ins Service Management. Ein etabliertes Service Management System besitzt Service Ownership, Configuration Management, Change Enablement, Incident und Problem Management, Monitoring, Service Level Management, Supplier Management und Continual Improvement. Das AIMS erweitert sie um AI-spezifische Anforderungen.

Expertise und Maintainability treffen sich im Betrieb: Continuous Validation nützt wenig, wenn niemand die Messwerte interpretieren kann; ein Drift Alert nützt wenig, wenn unklar ist, wer ihn beurteilt. Daraus entsteht ein Kreislauf – Operate → Monitor → Learn → Build Competence → Improve → Operate. Als Evidence dienen nicht Trainingszahlen, sondern Competence Coverage, Critical Role Coverage und Skill Gap Closure; für Maintainability Model Change Frequency, Revalidation Coverage, Drift Detection Time, AI Incident Rate, Human Override Trends, Configuration Traceability und Retirement Compliance. Denn auch das gehört zu Responsible AI: AI-Systeme geordnet ausser Betrieb nehmen zu können – Daten behandeln, Credentials entziehen, Schnittstellen deaktivieren, Audit Records erhalten. Ein System, das eine Organisation nicht kontrolliert verändern oder stilllegen kann, ist kein verantwortungsvoll beherrschtes System.

8. Environmental Impact: Das oft übersehene Responsible-AI-Ziel

Accountability, Fairness, Privacy und Security werden selbstverständlich mit Responsible AI verbunden. Die ökologischen Auswirkungen stehen seltener im Zentrum. Das ist bemerkenswert, denn AI ist keine virtuelle Ressource: Hinter jedem Modell stehen Rechenzentren, Prozessoren, Energie und Kühlung. Und mit Agentic AI erhält die Frage eine operative Dimension – ein Agent führt für eine einzige Aufgabe mehrere Modellaufrufe durch, sucht, analysiert, ruft weitere Agents auf und überprüft seine Ergebnisse. Responsible AI muss deshalb eine unbequeme Frage stellen: Ist der Ressourcenverbrauch im Verhältnis zum tatsächlichen Business Value gerechtfertigt?

Mehr als der Energieverbrauch beim Training

Die öffentliche Diskussion konzentriert sich auf das Training grosser Foundation Models. Die meisten Unternehmen trainieren aber kein eigenes Modell – sie konsumieren AI. Damit verlagert sich die relevante Umweltwirkung auf die Nutzung: Inference. Jeder Prompt erzeugt Rechenaufwand; hinzu kommen RAG, Embeddings, Vector Databases, Fine-Tuning, Testing und Monitoring. Ein klassischer Assistant folgt der Logik Prompt → Model → Response. Ein Agent arbeitet anders: Goal → Plan → Model → Tool → Model → Retrieval → Model → Agent → Validation → Action. Eine einzelne Anfrage löst eine Kette compute-intensiver Operationen aus. Damit entsteht eine neue Governance-Frage: Wie viel AI benötigen wir eigentlich, um eine Aufgabe sinnvoll zu lösen? Nicht jede Aufgabe braucht das leistungsfähigste Modell, nicht jede Entscheidung mehrere Agents.

Die International Energy Agency erwartet, dass der Stromverbrauch von Rechenzentren bis 2030 auf rund 945 TWh steigen könnte – mehr als doppelt so viel wie 2022 – mit AI als wesentlichem Treiber. Sie betont zugleich das Potential von AI, Energieverbrauch und andere Systeme effizienter zu machen. Beide Seiten sind für Responsible AI wichtig. Die relevante Managementfrage lautet: Welchen Net Impact erzeugt der konkrete AI Use Case?

Vom «Can we?» zum «Should we?»

Hier unterscheidet sich Environmental Impact von anderen Objectives: Es geht nicht nur um Risikominimierung, sondern um Verhältnismässigkeit. Ein AI-System mit erheblichem Ressourcenverbrauch, das den Energieverbrauch eines Produktionsprozesses wesentlich senkt, erzeugt einen positiven Nettoeffekt. Ein hochkomplexer Agent, der eine geringwertige administrative Aufgabe automatisiert, steht kaum im Verhältnis zum Nutzen. AI Governance fragt meist «Can we use AI?» – technisch möglich, Daten vorhanden, Security ausreichend, rechtlich zulässig? Environmental Impact ergänzt: «Should we use AI this way?» Vielleicht reicht ein kleineres Modell. Vielleicht löst ein klassischer Algorithmus die Aufgabe effizienter. Vielleicht muss ein Agent nicht fünf Modelle konsultieren.

Environmental Impact trifft FinOps – und die Supply Chain

Compute, Inference, Tokens, Speicher und API Calls kosten Geld. Viele Mechanismen, die AI wirtschaftlicher machen, reduzieren gleichzeitig den Ressourcenverbrauch: kleinere Modelle, optimierte Prompts, reduzierter Context, Caching, Routing zwischen Modellen, effizientere RAG-Architekturen, Vermeidung unnötiger Agent Loops, Batch Processing, klassische Automation, wo AI keinen Zusatznutzen erzeugt. Cost Efficiency und Environmental Efficiency ergänzen sich – FinOps wird zu einer überraschend wichtigen Capability eines AIMS. Kosten sind aber kein vollständiger Umweltindikator: Strommixe, Hardwareauslastung, Rechenzentren und Wasserverbrauch unterscheiden sich, und nicht alle Auswirkungen werden im Preis sichtbar. Weil die meisten Unternehmen Foundation Models nicht selbst betreiben, hängt ihre Umweltwirkung wesentlich von Providern ab: Welche Informationen über Energieverbrauch und Effizienz stellt der Provider bereit? Gibt es kleinere Modellvarianten? Welche Sustainability-Ziele verfolgt er? Environmental Impact wird Teil des Supplier Managements.

Vom einzelnen Use Case zum Portfolio – und zur Evidence

Eine einzelne AI-Anwendung mag vernachlässigbar sein. Wenn 20’000 Mitarbeitende mehrere Assistants verwenden oder tausende Agents kontinuierlich Modelle aufrufen, entsteht eine andere Grössenordnung. Environmental Impact ist deshalb auch eine Portfolio-Governance-Frage: Wie effizient ist unser gesamtes AI Portfolio? Das AIMS verbindet dafür Sustainability Management, Enterprise Architecture, FinOps, Procurement, Service Management und Portfolio Management – ohne Sustainability zu duplizieren. Je nach Relevanz können erhoben werden: verwendetes Modell, Usage Volume, Compute Consumption, Cost per AI Transaction, Model Efficiency, Agentic Overhead, Provider Sustainability Information und Net Environmental Benefit. Daraus entstehen Kennzahlen wie AI Cost per Business Transaction, Tokens per Completed Task, Agent Steps per Successful Outcome oder Compute Growth vs. Business Value Growth.

Nicht jeder Use Case braucht eine CO₂-Bilanz. Das AIMS sollte nicht für jeden internen Assistant eine Lifecycle-Bilanz verlangen – das wäre weder wirtschaftlich noch risikobasiert. Relevant werden hohe Nutzungsvolumina, rechenintensive Anwendungen, grossflächiger Einsatz, kontinuierlich laufende Agents, eigene Modelltrainings oder Use Cases, bei denen Sustainability Teil des Business Case ist. Das Prinzip: Assess → determine materiality → measure proportionately → improve. Nicht: measure everything.

9. Warum ein isoliertes AIMS nicht funktionieren kann

Nach der Betrachtung der einzelnen Objectives wird eines deutlich: Responsible AI ist keine isolierte Managementdisziplin. Accountability braucht Governance, Data Quality braucht Data Governance, Privacy braucht Datenschutzmanagement, Robustness und Security brauchen Informationssicherheit, Maintainability führt ins Service Management, AI Expertise ins Competence Management, Environmental Impact zu Sustainability und FinOps. Viele dieser Fähigkeiten existieren bereits. Genau deshalb wäre es ein Fehler, für AI eine neue Governance-Welt aufzubauen.

Annex C durchschneidet die bestehenden Managementsysteme

ISO/IEC 42001 ist ein Managementsystemstandard – mit derselben Logik aus Kontext, Leadership, Planung, Betrieb, Performance Evaluation und Continual Improvement, die Organisationen aus ISO/IEC 27001 oder ISO 9001 kennen. Fast keines der Annex-C-Objectives gehört ausschliesslich dem AIMS:

Annex-C-Objective	Primäre bestehende Management Capability
Accountability	Corporate Governance, Enterprise Risk Management
AI Expertise	HR, Competence & Knowledge Management
Training & Test Data	Data Governance, Quality Management
Environmental Impact	Sustainability, FinOps, Enterprise Architecture
Fairness	Risk, Compliance, Ethics, Business Governance
Maintainability	Service, Change & Configuration Management
Privacy	Privacy Management, Data Governance
Robustness	Quality, Resilience & Service Management
Safety	Risk, Safety & Business Continuity Management
Security	ISMS / Information Security Management
Transparency & Explainability	Governance, Audit, Risk, Data & Service Management

Die Zuordnung ist nicht exklusiv – genau das ist der Punkt. Annex C beschreibt kein AI-Silo, sondern ein Netzwerk organisatorischer Fähigkeiten. Klassische Organisationen sind vertikal aufgebaut: Security, Privacy, Data Governance, Risk, Service Management, Procurement und HR besitzen je eigene Prozesse. AI verhält sich horizontal – ein einziger Agent, der Kundenanfragen bearbeitet, betrifft alle gleichzeitig. Das AIMS ist deshalb weniger eine neue vertikale Funktion als eine horizontale Governance-Schicht über bestehenden Management Capabilities.

Integration bedeutet nicht Zentralisierung – und nicht nur Reuse

Ein integriertes AIMS heisst nicht, dass alle AI-Entscheidungen zentral getroffen werden; das wäre nicht skalierbar. Es gilt: zentrale Leitplanken – dezentrale Verantwortung. Zentral definiert werden AI Policy, Risikoklassifikation, Mindestanforderungen, zulässige Technologien, Assessment-Methoden, Lifecycle Gates und Evidence Requirements. Die Verantwortung für den konkreten Use Case bleibt beim Business oder Service Owner, der den Kontext versteht. Das ist Federated AI Governance.

Dabei muss das AIMS vorhandene Controls wiederverwenden: Brauchen Agents eigene Identitäten, definiert das AIMS die Anforderung (eindeutig identifizierbar, Least Privilege), das IAM des ISMS liefert die Capability (Identity Lifecycle, Authentication, Privileged Access, Access Review). Das AIMS definiert den AI Context, das bestehende Managementsystem liefert die Management Capability. Integration darf aber nicht einfach «Verweis auf bestehende Prozesse» bedeuten. «Security wird durch das ISMS behandelt» reicht nicht, wenn das ISMS Prompt Injection oder Agent Identities noch nicht kennt. «Changes laufen über den Change-Prozess» reicht nicht, wenn dieser nicht erkennt, dass ein Wechsel des Foundation Models das Verhalten eines Services verändert. Integration bedeutet Reuse und Extension: ISMS, Service Management, Data Governance, Supplier Management und Competence Management müssen AI-aware werden.

Der Lifecycle als Integrationspunkt

Der beste Integrationspunkt ist nicht die Policy, sondern der AI Lifecycle:

Discover → Assess → Design → Build / Acquire → Validate → Deploy → Operate → Monitor → Improve → Retire

• Discover – Sollen wir diesen Use Case überhaupt verfolgen? Welche Aufgabe, warum AI, welche Stakeholder?
• Assess – Welches Risiko gehen wir ein? Impact Assessment, regulatorische Anforderungen, Privacy, Security, Fairness – und damit die Intensität der Governance.
• Design – Human Oversight, Access Controls, Data Quality, Logging, Fallback, Safety Boundaries werden zu Design Input, nicht zur Kontrolle am Ende.
• Build / Acquire – Supplier Management gehört zwingend dazu: Modelle, Datenverarbeitung, Changes, Logs, Service Levels, Exit-Möglichkeiten.
• Validate – Ist genügend Evidence vorhanden, um das verbleibende Risiko bewusst zu akzeptieren?
• Deploy – ein Governance Gate: Ownership geklärt, Controls implementiert, Benutzer informiert, Support vorbereitet, Monitoring aktiv.
• Operate & Monitor – Performance, Incidents, Drift, Overrides, Security Events, Supplier Changes: Hier beginnt Responsible AI Operations.
• Improve – Erkenntnisse aus Incidents, Audits und Monitoring fliessen zurück in Controls und Systemdesign.
• Retire – Daten behandeln, Credentials entziehen, Schnittstellen deaktivieren, Evidence erhalten.

Legt man die Annex-C-Objectives als zweite Dimension über diesen Lifecycle, entsteht eine Governance Matrix. Nicht jedes Feld braucht einen Control, aber die Matrix zwingt zur bewussten Entscheidung: Welches Objective ist in welcher Phase relevant – und welche bestehende Management Capability übernimmt es? Das ist wesentlich leistungsfähiger als eine statische Checkliste.

AIMS als Orchestrator

Ein unreifes Modell stellt Business, ISMS, Privacy, Data Governance, SMS, AIMS und Sustainability nebeneinander – jedes System arbeitet für sich. Das Zielbild sieht anders aus:

Business Objectives & Values → Responsible AI Objectives (Annex C) → AI Risk & Impact Assessment → AIMS Governance & Lifecycle → bestehende Management Capabilities (ISMS | SMS | QMS | Privacy | Data Governance | Risk | Supplier | HR | Sustainability) → AI-enabled Products & Services → Monitoring, Evidence & Continual Improvement

Integration schafft auch bessere Evidence: Dokumentiert das ISMS Access Reviews, kann das AIMS sie nutzen; dokumentiert Service Management Changes, werden AI-relevante Changes darüber nachgewiesen; liefert Data Governance Lineage, braucht es keine zweite Dokumentation. Dieselbe Organisation sollte nicht drei Wahrheiten über dasselbe System besitzen. Und Integration verhindert Governance Fatigue: Wenn jede neue Anforderung aus Cybersecurity, Datenschutz, Business Continuity, Cloud Governance und AI Regulation ein eigenes Managementsystem mit eigenen Assessments und Rollen erzeugt, verbringt die Organisation ihre Zeit damit, Governance zu verwalten statt Risiken zu steuern. One Control – multiple Objectives. One Evidence – multiple Assurance Needs. One Lifecycle – multiple Governance Perspectives.

Integration bedeutet dabei nicht weniger Governance, sondern bessere: Security sieht die Schwachstelle, Privacy die personenbezogenen Daten, Service Management den Incident, Risk Management den Business Impact – das AIMS sorgt für ein gemeinsames Risikobild. Und das Ziel ist nicht ein integriertes ISO-Handbuch, sondern Management-Integration: dass eine Entscheidung über AI gleichzeitig Business Value, Risiko, Daten, Menschen, Security, Privacy, Service, Supplier, Sustainability und Compliance berücksichtigt.

Objectives → Risks → Controls → Capabilities → Lifecycle → Evidence → Improvement

Darin liegt der Unterschied zwischen einem AIMS als Compliance-System und einem integrierten AIMS als Managementsystem. Das eine verwaltet AI-Anforderungen. Das andere hilft der Organisation, AI tatsächlich zu beherrschen. Daraus folgt die letzte Konsequenz: Aus Governance vor dem Go-live muss eine dauerhafte operative Fähigkeit werden.

10. Von Responsible AI zu Responsible AI Operations

Auch ein integriertes AIMS bleibt wirkungslos, wenn Responsible AI hauptsächlich aus Policies, Assessments, Gremien und periodischen Audits besteht. AI findet nicht im Managementhandbuch statt. AI findet in Produkten, Services und Geschäftsprozessen statt – Modelle werden aktualisiert, Mitarbeitende entwickeln neue Use Cases, Agents erhalten zusätzliche Tools, Incidents treten auf. Responsible AI muss dort wirksam werden, wo AI lebt: im operativen Lifecycle.

Annex C wird vom Zielsystem zum Betriebsmodell

Bis hierher haben wir die Objectives als Ziele betrachtet: Ist Accountability gewährleistet? Sind die Daten geeignet? Ist das System fair, robust, sicher? Im Betrieb werden daraus kontinuierliche Managementfragen: Ist Accountability noch klar? Sind die Daten noch geeignet? Verhält sich das System weiterhin fair? Können wir seine Aktionen weiterhin nachvollziehen? Besitzen unsere Mitarbeitenden noch die Kompetenzen? Ist der Ressourcenverbrauch weiterhin angemessen? Das Wort «weiterhin» ist entscheidend. Und aus statischen Controls werden Control Loops:

• Validation: Test → Deploy → Monitor → Detect Deviation → Assess → Correct → Revalidate
• Data Quality: Define Quality → Measure → Monitor Drift → Investigate → Correct
• Security: Protect → Monitor → Detect → Respond → Learn
• Fairness: Define → Test → Monitor → Detect Bias → Reassess
• Accountability: Assign → Monitor Change → Review Ownership → Reconfirm Authority
• Maintainability: Baseline → Change → Validate → Operate → Revalidate

Monitoring muss mehr messen als Verfügbarkeit

Ein AI Service kann zu 100% verfügbar sein und trotzdem schlechte Entscheidungen treffen, schnell antworten und zunehmend halluzinieren, alle Service Levels erfüllen und häufiger übersteuert werden. Responsible AI Operations braucht neben System Monitoring auch Behavioural und Governance Metrics: Task Success, Hallucination Rate, Human Override Rate, Escalation Rate, Drift und Fairness Indicators, Policy Violations, Security Events, unerwartete Agent Actions, Provider Changes, User Complaints. Der Human Override wird dabei zu einem wichtigen Signal: Korrigieren Menschen AI-Ergebnisse regelmässig, weist das auf Data Quality, Model Performance, veränderten Business Context, falsche Autonomie oder mangelnde Akzeptanz hin. Der Mensch ist nicht nur Sicherheitsnetz – er wird zum Sensor im Responsible-AI-Control-Loop.

Dasselbe gilt für Incidents: Ein AI Incident ist nicht nur ein Modellausfall, sondern auch systematisch falsche Antworten, eine unerwartete Agent Action, eine Privacy-Verletzung durch einen Prompt, eine erfolgreiche Prompt Injection, ein Performance Drift oder ein externer Model Change – und kann gleichzeitig Security-, Privacy-, Service-, Compliance- und Business Incident sein. Und für Changes: Neue Modellversion, neuer System Prompt, veränderte Knowledge Base, neues Tool, neue Berechtigung, neue Nutzergruppe, veränderter Business Purpose. Nicht jeder Change braucht ein Re-Assessment – aber das AIMS muss erkennen, welche Veränderungen Capability, Authority, Autonomy oder Impact verändern. Change Management wird zum Bindeglied zwischen AIMS und Service Management.

Agentic AI braucht Runtime Governance

Bei klassischer AI findet Governance vor der Nutzung statt. Ein Agent muss zur Laufzeit wissen: Welche Tools darf ich verwenden? Auf welche Daten zugreifen? Welche Aktion autonom ausführen, welche nur mit Approval? Welche Transaktionsgrenze gilt, wann muss ich stoppen oder eskalieren? Policies werden nicht mehr nur von Menschen gelesen – sie müssen technisch durchgesetzt werden: Identity and Access Controls, Policy Enforcement, Tool Allow Lists, Transaction Limits, Approval Gates, Guardrails, Kill Switches. Responsible AI wird Teil der technischen Betriebsarchitektur.

Evidence by Design und Continuous Assurance

In vielen Managementsystemen beginnt kurz vor dem Audit die Suche nach Nachweisen. Bei AI wird das schwierig: Traceability, Model Changes, Agent Actions, Overrides und Data Provenance müssen während des Betriebs entstehen. Evidence should be generated by operation – not reconstructed for audit. Logging, Versionierung, Approvals und Change Records sollten gleichzeitig operative Steuerung und Assurance unterstützen. Und wo Risiko und Technik es rechtfertigen, ersetzt Continuous Assurance den jährlichen Audit: Wenn Model Performance in Wochen driftet oder ein Provider morgen sein Modell verändert, ist die Risikobewertung von gestern bereits unvollständig. Drift Indicators, Security Events, Model Changes, Policy Violations und Control Failures können kontinuierlich entstehen.

Ein reifes AIMS wird deshalb nicht über eine Dokumentenablage gesteuert, sondern über ein Management Cockpit: Welche AI-Systeme sind produktiv, welche hoch autonom, welche High-Impact? Wo fehlen Owner? Welche Assessments laufen aus? Welche Systeme zeigen Drift? Wo steigen Overrides? Welche Provider Changes stehen an? Welche Controls sind nicht wirksam? Welche Systeme müssen revalidiert werden?

Nicht alles braucht dieselbe Governance-Intensität

Ein interner Writing Assistant braucht andere Governance als ein Agent, der autonom geschäftskritische Aktionen ausführt. Der Betrieb muss risikobasiert skalieren – entlang von vier Dimensionen:

• Impact – wie gross kann die Wirkung sein?
• Autonomy – wie selbständig handelt die AI?
• Exposure – wie stark ist das System externen Inputs und Bedrohungen ausgesetzt?
• Reversibility – wie gut lassen sich Aktionen rückgängig machen?

Je höher Impact, Autonomy und Exposure und je geringer Reversibility, desto intensiver Monitoring, Validation, Human Oversight und Assurance. Das verhindert zwei Extreme: zu wenig Governance für kritische AI und zu viel Governance für triviale AI. Der PDCA-Zyklus bekommt damit eine operative Bedeutung – als Management Cycle (Plan → Do → Check → Act) und darunter als AI Operations Cycle (Deploy → Monitor → Detect → Respond → Learn → Improve). Responsible AI Operations verbindet beide. Ein reifes AIMS beeinflusst Governance, Organisation, Rollen, Daten, Technologie, Service Management, Security, Supplier Management, Kompetenzen und Assurance – es wird Teil des AI Operating Models.

Responsible AI Principles → Responsible AI Objectives → AI Management System → Integrated AIMS → Responsible AI Operations

Responsible AI wird dort sichtbar, wo Entscheidungen getroffen werden

Am Ende entscheidet sich Responsible AI nicht in der AI Policy, sondern in konkreten Situationen: Wenn ein Business Owner über einen Use Case entscheidet. Wenn ein Data Owner eine Datenquelle freigibt. Wenn Security einem Agenten eine Berechtigung erteilt. Wenn ein Provider sein Modell verändert. Wenn Monitoring einen Drift erkennt. Wenn ein Mensch eine AI-Entscheidung übersteuert. Wenn ein Change die Autonomie erhöht. Oder wenn entschieden wird, eine AI ausser Betrieb zu nehmen. Genau dort muss das AIMS funktionieren.

Das ist die eigentliche Zielsetzung eines integrierten AIMS: nicht möglichst viel zusätzliche AI Governance, sondern eine Organisation, die AI genauso selbstverständlich verantwortet, steuert, überwacht und verbessert, wie sie heute ihre kritischen Services, Informationen und Geschäftsrisiken steuert. Vielleicht ist das die wichtigste Botschaft von Annex C: