AI Governance im Service Management – Wenn AI Teil des Services wird

Wie Service Ownership, Lifecycle, Practices und Controls weiterentwickelt werden müssen, wenn AI nicht mehr nur unterstützt, sondern zunehmend selbst handelt.

Worum es in diesem Beitrag geht

Künstliche Intelligenz ist im Service Management angekommen – und mit Agentic AI verändert sich die Frage grundlegend: Nicht mehr nur wie wir AI im Service Management einsetzen, sondern wie wir Services steuern, wenn AI selbst Teil ihrer Leistungserbringung wird. Dieser Beitrag zeigt, warum AI Governance nicht neben dem Service Management System entstehen darf, sondern darin wirksam werden muss – und wie ein praktikables Operating Model dafür aussehen kann.

Der Beitrag ist in zehn Kapitel gegliedert:

1. Wenn AI Teil des Services wird – vom automatisierten Workflow zum handelnden Agenten und warum Service Management AI Governance operativ macht
2. Die Governance-Lücke – sechs Lücken, die entstehen, weil unsere Betriebsmodelle für Menschen und Systeme gebaut wurden
3. Vom AI Inventory zum Service Model – warum eine Liste der AI-Systeme nicht genügt und die CMDB zum System of Context wird
4. Autonomie braucht Governance – ein Modell mit fünf Autonomie-Leveln, Guardrails und Reversibility
5. AI Governance gehört in das Service Management System – was sich in den einzelnen Practices konkret verändert
6. ISO 42001, ISO 20000 und ITIL – drei Ebenen, eine Governance statt drei Welten
7. Shadow AI wird zu Shadow Agents – wenn aus unkontrollierten Informationskanälen unkontrollierte Akteure werden
8. Regulierung macht aus Best Practice eine Governance-Anforderung – AI Act, AI Literacy, Evidenz und der AI Proof Gap
9. Ein praktisches AI Governance Operating Model – Discover → Classify → Assign → Control → Observe → Improve
10. AI Governance darf Innovation nicht verhindern – sie muss Autonomie ermöglichen: von Human in the Loop zu Human in the Lead

1. Wenn AI Teil des Services wird

Künstliche Intelligenz ist im Service Management längst vertrautes Terrain: Virtuelle Assistenten beantworten Anfragen, AI klassifiziert Incidents, fasst Informationen zusammen, durchsucht Wissensbestände und schlägt Lösungen vor. Mit Agentic AI verändert sich die Situation. Agenten können Aufgaben planen, Informationen aus unterschiedlichen Quellen zusammenführen, Anwendungen und Tools nutzen, Entscheidungen vorbereiten und – sofern berechtigt – selbst Aktionen ausführen.

Damit verschiebt sich die Fragestellung. Es geht nicht mehr nur darum, wie AI im Service Management eingesetzt werden kann, sondern wie Services gemanagt und kontrolliert werden müssen, wenn AI selbst Bestandteil ihrer Leistungserbringung wird.

Ein Beispiel: Ein AI Agent analysiert Monitoring-Daten, bezieht Configuration Information und bekannte Fehlerbilder ein, durchsucht Knowledge und leitet daraus eine wahrscheinliche Ursache und eine Massnahme ab. Bleibt es bei einer Empfehlung, entscheidet weiterhin der Mensch. Derselbe Agent könnte aber auch einen Standard Change initiieren, eine Konfiguration anpassen, einen Benutzerzugriff verändern oder über eine API eine Recovery-Aktion auslösen. Der Unterschied ist erheblich – nicht technisch, Automatisierung kennen wir seit Jahrzehnten, sondern hinsichtlich Governance, Kontrolle und Verantwortung: Ein technisches System erhält Handlungs- und unter Umständen Entscheidungsbefugnisse innerhalb eines produktiven Services.

Ein Agent benötigt ausreichend Zugriff und Handlungsspielraum, um seine Aufgabe zu erfüllen. Gleichzeitig müssen Identität, Rolle, aufgabenspezifische Berechtigungen und zulässige Aktionen definiert sein, Aktivitäten nachvollziehbar bleiben und mit wachsender Autonomie die menschliche Aufsicht zunehmen. Das sind bekannte Governance-Prinzipien. Neu ist das Objekt, auf das wir sie anwenden.

Vom automatisierten Workflow zum handelnden Agenten

Klassische Automatisierung folgt vorgegebenen Abläufen: Ein Workflow prüft definierte Bedingungen und führt die dafür konfigurierte Aktion aus. Solche Mechanismen können komplex sein, ihr Entscheidungsweg bleibt aber bestimmt. Bei agentenbasierter AI wird dieser Weg variabler. Ein Agent interpretiert den Kontext, kombiniert Informationen und wählt selbst, welche Tools, Datenquellen oder Schnittstellen er für einen Auftrag nutzt. Darin liegt sein Nutzen – und das zusätzliche Risiko.

Mehr Autonomie darf nicht mit einer Verlagerung von Verantwortung auf die AI verwechselt werden. Ein Agent kann eine Aktion ausführen, aber keine organisatorische Accountability übernehmen. Diese verbleibt bei der Organisation und den dafür bestimmten Rollen.

Je grösser der operative Handlungsspielraum eines Agenten, desto klarer müssen Auftrag, Entscheidungsgrenzen, Berechtigungen, Überwachung und verantwortliche Rollen definiert sein.

Bei mehreren zusammenwirkenden Agents wird das anspruchsvoller: Welcher Agent hat welche Entscheidung getroffen? Auf welcher Informationsgrundlage? Mit welcher Berechtigung? Wo endet die delegierte Entscheidungsbefugnis? Für das Service Management ist das keine abstrakte Debatte, sondern Betriebsrealität. Was geschieht, wenn ein Agent einen technisch erfolgreichen, aus Business-Sicht aber problematischen Change ausführt? Liegt ein Service Incident vor, ein Information Security Incident, ein Problem in der Entscheidungslogik? Wer darf den Agenten stoppen? Welche Modell-, Prompt-, Knowledge- oder Configuration-Version war zum Zeitpunkt der Aktion aktiv? Spätestens hier wird AI Governance operativ.

Nicht der Agent allein, sondern der Servicekontext zählt

Viele Organisationen beginnen mit einem Inventar der eingesetzten AI-Systeme, Modelle, Use Cases und Agents. Das ist unverzichtbar – für Service Management aber nicht ausreichend. Ein Agent existiert nicht isoliert. Er unterstützt einen Geschäftsprozess, wirkt in einem digitalen Service, verwendet Daten und Knowledge, besitzt Zugriffsrechte auf Anwendungen und Plattformen und nutzt Schnittstellen zu anderen Systemen – häufig ergänzt um Modelle oder AI-Funktionen externer Provider.

Die Frage „Welche AI Agents haben wir?“ genügt deshalb nicht. Aus Service-Management-Sicht interessiert: In welchen Services wirken diese Agents, welche Outcomes und Service Commitments können sie beeinflussen, welche Ressourcen dürfen sie nutzen und welche Risiken, Verantwortlichkeiten und Abhängigkeiten entstehen daraus?

Das offizielle ITIL AI Governance Book verfolgt dieselbe Sicht: AI wird nicht als isoliertes Tool betrachtet, sondern im Kontext von Produkten, Services, Practices, Value Streams, Projekten, Lieferantenbeziehungen und operativen Umgebungen. Im Product and Service Lifecycle wird das besonders deutlich. Governance beginnt nicht mit der Freigabe einer fertigen AI-Lösung und endet nicht mit dem Go-live: Bereits bei Discover und Design stellen sich Fragen nach Nutzen, Risiken, Daten, Human Oversight und Lieferanten; beim Build kommen Security, Datenqualität, Testing und Integration hinzu; in Transition werden Controls und Verantwortlichkeiten operationalisiert; in Operate, Deliver und Support sind Verhalten, Incidents, Servicequalität und Abweichungen zu überwachen. Damit wird aus einem AI Use Case ein Thema des Service Managements.

AI Governance allein betreibt keinen Service

Governance definiert Richtung, Grundsätze, Verantwortlichkeiten, Entscheidungsbefugnisse und Grenzen – etwa, dass ein Agent bestimmte Aktionen autonom ausführen darf, bei höherem Risiko jedoch eine menschliche Freigabe benötigt. Im Betrieb reicht diese Vorgabe nicht. Es braucht einen Workflow, Rollen und Eskalationswege; Berechtigungen müssen technisch durchgesetzt, Entscheidungen protokolliert, Configuration und Changes nachvollziehbar gehalten und Abweichungen erkannt werden. Dasselbe gilt für Risiken: Ein AI Risk Assessment kann Model Drift, fehlerhafte Daten oder einen externen Provider als wesentliche Risiken feststellen. Beherrscht sind sie damit noch nicht – dafür braucht es Monitoring, Messgrössen, Schwellenwerte, Verantwortlichkeiten und definierte Reaktionen.

Das ITIL AI Governance Book trennt die beiden Ebenen bewusst: Governance gibt Richtung und Kontrolle vor; Management organisiert Ressourcen und Aktivitäten innerhalb dieses Rahmens. AI Governance soll dabei nicht als separates Kontrollsystem neben dem bestehenden Management aufgebaut, sondern in das bestehende System der digitalen Produkt- und Serviceerbringung eingeordnet werden.

AI Governance definiert die Leitplanken. Service Management übersetzt sie in die konkrete Gestaltung, Steuerung und Kontrolle digitaler Services. Oder verdichtet: Service Management macht AI Governance operativ.

Die eigentliche Herausforderung beginnt im Betrieb

Bisher lautete eine typische Frage: Wie setzen wir Technologie ein, um einen Service effizienter und zuverlässiger zu erbringen? Künftig kommt eine zweite hinzu: Wie gestalten und steuern wir Services, wenn technische Systeme innerhalb dieser Services zunehmend selbst beobachten, interpretieren, entscheiden und handeln?

Dafür muss Service Management nicht neu erfunden werden. Service Ownership, Risk Management, Information Security Management, Supplier Management, Change Enablement, Service Configuration Management, Incident und Problem Management, Monitoring and Event Management, Knowledge Management und Continual Improvement sind vorhanden. Ihre Anwendung muss sich allerdings verändern. Ein AI Agent braucht keine Personalnummer, aber eine kontrollierbare Identität. Er hat keine Stellenbeschreibung, benötigt aber einen definierten Auftrag und abgegrenzte Befugnisse. Er kann handeln, trägt aber keine organisatorische Verantwortung. Und wo seine Entscheidungen Services, Kunden, Daten, Sicherheit oder Compliance betreffen, braucht es Entscheidungsgrenzen, wirksame Kontrollen, Monitoring und einen Weg zurück zum Menschen.

Genau dort beginnt AI Governance im Service Management.

2. Die Governance-Lücke: Unsere Betriebsmodelle wurden für Menschen und Systeme gebaut

Unsere Governance- und Betriebsmodelle folgen einer klaren Logik: Menschen erhalten Rollen, Verantwortlichkeiten und Berechtigungen. Anwendungen werden inventarisiert, Changes kontrolliert, Komponenten konfiguriert und überwacht. Lieferanten unterliegen Verträgen und Service Levels. Für Risiken gibt es Owner und Controls, für Abweichungen Eskalationswege. Das funktioniert, weil wir zwischen handelnden Menschen und den von ihnen genutzten Systemen unterscheiden konnten.

AI Agents passen nicht mehr in diese Trennung. Sie sind keine Mitarbeitenden und können keine Verantwortung übernehmen. Gleichzeitig sind sie mehr als passive Komponenten: Sie interpretieren Informationen, nutzen Credentials, wählen Werkzeuge, initiieren Aktivitäten und führen – je nach Autonomiegrad – selbständig Aktionen in produktiven Systemen aus. Daraus entsteht eine Governance-Lücke.

Das Problem ist nicht, dass neue Prinzipien erfunden werden müssten. Accountability, Least Privilege, Segregation of Duties, Traceability, Change Control, Risk Ownership und Lifecycle Management kennen wir längst. Schwieriger ist: Unsere Mechanismen wurden nicht dafür konzipiert, diese Prinzipien auf eine grosse Zahl teilautonomer, softwarebasierter Akteure anzuwenden. Die Cloud Security Alliance beschreibt dies in ihrer Analyse zu Shadow AI als strukturelles Problem: Security-Architekturen, Discovery-Werkzeuge und Governance-Prozesse wurden für klassische Software und Cloud Services entwickelt; AI-Systeme und insbesondere Agents passen nur bedingt in diese Kontrollmodelle.

Aus Service-Management-Sicht lässt sich die Lücke in sechs verbundene Bereiche aufteilen.

Visibility Gap – was wir nicht sehen, können wir nicht steuern

Governance setzt voraus, dass bekannt ist, was gesteuert werden soll. Bei klassischen IT Assets ist das selbstverständlich; bei AI ist diese Transparenz vielerorts nicht gegeben. Es geht längst nicht mehr nur um Mitarbeitende, die einen nicht freigegebenen öffentlichen AI Service nutzen. AI Capabilities werden Bestandteil bereits zugelassener SaaS-Produkte – neue Funktionen kommen mit einem Release hinzu, obwohl die ursprüngliche Risikobeurteilung erfolgte, als diese Funktion noch nicht existierte. Parallel entstehen intern entwickelte Agents, API-Integrationen und Automatisierungen, die das Experimentierstadium verlassen, ohne dass der Übergang in einen produktiven Service formal wahrgenommen wird.

Die CSA unterscheidet deshalb drei Dimensionen von Shadow AI: nicht autorisierte eigenständige AI Tools, nachträglich in freigegebene SaaS-Produkte integrierte AI-Funktionen und autonome Agents. Gerade bei den beiden letzten greifen klassische Discovery-Mechanismen nur eingeschränkt – AI operiert innerhalb erlaubter Anwendungen oder über reguläre APIs und erscheint technisch unauffällig.

Eine Organisation kann keine AI Governance betreiben, wenn sie nicht weiss, wo AI eingesetzt wird und worauf sie zugreifen kann.

Visibility bedeutet deshalb mehr als ein einmal erstelltes AI Inventory. Relevant sind neue AI Capabilities, veränderte Berechtigungen, zusätzliche Datenzugriffe und neue Schnittstellen. Bei Agents kommt die Identität hinzu: Welche Systeme dürfen sie aufrufen? Welche Daten verwenden sie? Wer hat dies autorisiert? In welchem Scope dürfen sie handeln? Die CSA fordert entsprechend systematische Discovery, Risikoklassifizierung, kontinuierliches Monitoring und Lifecycle Governance – für Agents sollen Identität, Datenzugriffe, aufrufbare Systeme, autorisierende Personen und operativer Scope nachvollziehbar sein.

Quelle: Cloud Security Alliance – Shadow AI and the Enterprise Visibility Crisis

Ownership Gap – ein Agent kann handeln, aber keine Verantwortung tragen

Bei einem klassischen Service ist klar, wer für Leistung und Weiterentwicklung verantwortlich ist; für Informationsrisiken gibt es Risk Owner, für Daten Data Owner, für Komponenten verantwortliche Teams. Bei AI beginnt diese Logik zu verschwimmen. Wer verantwortet einen Agenten, der Bestandteil eines produktiven Services ist? Der Service Owner? Das Entwicklungsteam? Der Owner des Modells? Der Data Owner? Information Security? Der externe Provider?

Die falsche Antwort lautet: die AI. Accountability lässt sich nicht an ein Modell delegieren. Ein Agent kann eine Aufgabe übernehmen und innerhalb vorgegebener Grenzen entscheiden. Die Verantwortung für die Delegation selbst verbleibt bei der Organisation. Das ITIL AI Governance Book ist hier klar: AI-enabled Products und Services benötigen weiterhin Owner, Decision Rights, Eskalationswege und Assurance. AI verändert die Verteilung von Aufgaben und Entscheidungsbefugnissen, beseitigt aber nicht die organisatorische Accountability. In der Praxis wird das schnell unangenehm: Nach einer Fehlentscheidung reicht es nicht zu wissen, welches Modell verwendet wurde. Es muss klar sein, wer die Nutzung freigegeben, den Handlungsspielraum definiert und das Restrisiko akzeptiert hat.

Authority Gap – was darf die AI eigentlich entscheiden?

Ein benannter Owner beantwortet noch nicht, welche Entscheidungen an einen Agenten delegiert werden dürfen. Ein Agent kann ausschliesslich Informationen liefern, Empfehlungen aussprechen, eine Entscheidung zur Freigabe vorbereiten – oder innerhalb bestimmter Grenzen selbst entscheiden und handeln. Diese Stufen sind governance-seitig nicht gleichwertig: Ein Agent, der einen Knowledge Article findet, braucht ein anderes Kontrollniveau als einer, der Benutzerberechtigungen verändert oder eine Recovery-Aktion auf einer produktiven Plattform ausführt.

Entscheidend ist deshalb nicht allein, was ein Agent technisch kann, sondern was er organisatorisch darf. Ein Capability Upgrade darf nicht automatisch zu einer Erweiterung der delegierten Authority führen. Nur weil ein Agent nach einem Update einen Change selbständig ausführen könnte, sollte er dazu nicht automatisch berechtigt sein. Autonomie wird zu einer expliziten Governance-Entscheidung – wie solche Autonomie-Level gestaltet werden, zeigt Kapitel 4.

Capability beschreibt, was AI kann. Authority definiert, was sie darf. Dazwischen liegt Governance.

Control Gap – Nachvollziehbarkeit reicht nicht bis zum Logfile

Definierte Entscheidungsbefugnisse bleiben wirkungslos, wenn ihre Einhaltung nicht kontrolliert werden kann. Berechtigungen müssen technisch begrenzt, Entscheidungen und Aktionen nachvollziehbar, Abweichungen erkennbar sein – und bei kritischen Entwicklungen braucht es die Möglichkeit einzugreifen, bis zur vollständigen Deaktivierung eines Agenten.

Ein Logfile allein löst das nicht. Für Audit und Assurance ist nicht nur interessant, dass eine Aktion stattgefunden hat. Je nach Risiko muss rekonstruierbar sein, welcher Agent gehandelt hat, auf welcher Informationsbasis, mit welchen Berechtigungen und unter welchen damals gültigen Konfigurationen und Entscheidungsgrenzen – anspruchsvoll, wenn mehrere Agents, Modelle, Tools und externe Services zusammenspielen. Hinzu kommt Reversibility: Bei kritischen Aktionen muss vorab geklärt sein, ob und wie eine Entscheidung rückgängig gemacht, ein Agent gestoppt oder auf einen kontrollierten Betriebsmodus zurückgesetzt werden kann.

Genau hier liegt eine Schwäche vieler AI-Initiativen: Die funktionale Capability wird entwickelt, bevor die operativen Kontrollmechanismen in vergleichbarer Tiefe definiert sind. Ein Beitrag von THE D*AI*LY BRIEF vom Mai 2026 greift dazu eine Gartner-Prognose auf, wonach ein erheblicher Teil agentischer AI-Projekte bis 2027 wieder eingestellt oder in seiner Autonomie zurückgestuft werden könnte. Die konkrete Prozentzahl stammt aus einer Sekundärquelle und ist entsprechend vorsichtig zu interpretieren. Der zugrunde liegende Punkt ist dennoch relevant: Autonomie muss abgestuft und mit Kontrollmechanismen verbunden werden; höhere Autonomie verlangt stärkere Anforderungen an Monitoring, Freigabe, Reversibility und menschliche Eingriffsmöglichkeiten.

Quelle: THE D*AI*LY BRIEF – Gartner: 40% of AI Agents Are Dead by 2027. Here’s Why

Lifecycle Gap – AI verändert sich auch nach der Freigabe

Eine weitere Lücke entsteht, wenn AI als einmal zu genehmigender Use Case behandelt wird. Ein AI System ist nach der Einführung nicht statisch: Modelle werden aktualisiert, Prompts ändern sich, Knowledge Sources kommen hinzu, ein Provider passt das Modellverhalten an, ein Agent erhält Zugriff auf zusätzliche APIs, seine Berechtigungen wachsen mit neuen Aufgaben. Jede Änderung kann technisch klein erscheinen und trotzdem das Risiko- oder Kontrollprofil des Services verändern.

Das ITIL AI Governance Book weist deshalb ausdrücklich auf adaptive Governance hin: Veränderungen an Modellversionen, Prompts, Daten, Providern, Benutzerverhalten oder Betriebsumgebung können beeinflussen, ob eine AI-Lösung weiterhin für ihren Zweck geeignet ist. Daraus entstehen Fragen, die Service Management gut kennt: Was ist eine genehmigungspflichtige Änderung? Wann muss ein AI Risk Assessment aktualisiert werden? Muss ein neuer Datenzugriff erneut freigegeben werden? Wie wird eine neue Modellversion getestet? Wer beurteilt einen Provider Change? Wann werden Berechtigungen rezertifiziert? Und was geschieht bei der Ausserbetriebnahme mit Credentials, Tokens, Datenzugriffen und Schnittstellen? Ein Agent braucht nicht nur ein Deployment. Er braucht einen kontrollierten Lifecycle.

Service Management Gap – AI wird als Technologie eingeführt, nicht als Servicebestandteil

Die aus meiner Sicht entscheidende Lücke liegt an anderer Stelle. Viele AI-Initiativen starten als Technologieprojekte: Use Case, Proof of Concept, Modell, vielleicht ein AI Risk Assessment, irgendwann die Freigabe. Was fehlt, ist die Einordnung in das bestehende Service Management System. Welchen Service verändert die AI? Welche Outcomes beeinflusst sie? Welche Rollen und Practices sind betroffen? Welche Abhängigkeiten und welche Configuration Information werden relevant? Was bedeutet eine Fehlfunktion für Service Continuity oder Service Levels? Wer überwacht den Provider? Und wie fliesst Betriebserfahrung zurück in die Weiterentwicklung?

Genau hier wird AI Readiness zur Service-Management-Frage. ITSM.tools argumentiert im Beitrag zum „ITSM Reset“ 2026, dass AI nicht losgelöst von der operativen Reife der Organisation skaliert werden kann. Schwächen bei Datenqualität, Knowledge Management, Configuration Management, Governance oder Prozessen verschwinden durch AI nicht – AI arbeitet auf diesen Strukturen und verarbeitet vorhandene Inkonsistenzen mit höherer Geschwindigkeit und grösserer Reichweite weiter. Eine AI kann eine schlechte Wissensbasis schneller durchsuchen; sie bleibt eine schlechte Wissensbasis. Fehlende Service Ownership wird nicht dadurch gelöst, dass zusätzlich ein AI Owner benannt wird. AI legt solche Schwächen offen.

Quelle: ITSM.tools – ITSM Reset: Why AI Can’t Scale Without ITSM Maturity in 2026

Sechs Lücken – eine Aufgabe

Die Governance-Lücke ist nicht das Fehlen eines neuen AI Governance Frameworks. Sie entsteht dort, wo bestehende Mechanismen den neuen Akteur noch nicht erfassen:

• Visibility: Wir wissen nicht vollständig, wo AI eingesetzt wird.
• Ownership: Verantwortung und Accountability sind nicht eindeutig zugeordnet.
• Authority: Der zulässige Entscheidungs- und Handlungsspielraum ist nicht explizit definiert.
• Control: Entscheidungen und Aktionen lassen sich nicht ausreichend überwachen, nachvollziehen oder begrenzen.
• Lifecycle: Änderungen an Modellen, Agents, Daten, Tools und Berechtigungen werden nicht durchgängig gesteuert.
• Service Management: AI wird als Technologie betrachtet, obwohl sie längst Bestandteil der Serviceerbringung ist.

Diese Lücken mit sechs neuen AI-Sonderprozessen zu beantworten, wäre die falsche Konsequenz. Asset und Configuration Management, Identity and Access Management, Change Enablement, Risk Management, Information Security, Supplier Management, Monitoring, Incident und Problem Management existieren bereits. Die Aufgabe besteht darin, deren Governance-Objekt zu erweitern. Dafür reicht ein klassisches AI Inventory nicht: Wir müssen den Agenten in seinem Servicekontext verstehen – welchem Service dient er, welche Daten und welches Knowledge nutzt er, welche Systeme darf er ansteuern, von welchen Providern hängt er ab, welche Risiken und Controls gelten und welche Entscheidungen darf er tatsächlich treffen? Damit wird aus dem AI Inventory ein Service Model.

3. Vom AI Inventory zum Service Model

Die erste Reaktion auf fehlende Transparenz ist ein AI Inventory: Welche Systeme, Modelle und Agents nutzen wir? Wer ist Owner? Welche Daten werden verarbeitet? Welcher Provider steckt dahinter? Das ist notwendig, für wirksame Governance aber nicht ausreichend. Ein Inventar beantwortet, was vorhanden ist. Für Service Management ist mindestens ebenso wichtig: In welchem Kontext wirkt die AI? Ein Agent kann technisch einwandfrei funktionieren und trotzdem ein erhebliches Risiko darstellen – entscheidend ist, worauf er zugreifen kann, welche Informationen er verwendet, welche Aktionen er auslösen darf und welche Services von seinem Verhalten abhängen. Aus einer Inventarisierungsfrage wird eine Modellierungsfrage.

Ein AI Agent existiert nicht isoliert

Bei klassischen Configuration Items ist der Gedanke vertraut: Eine Datenbank ist nicht relevant, weil sie existiert, sondern wegen der Anwendungen und Services, die von ihr abhängen. Bei AI ist diese Beziehung noch wichtiger. Ein Agent bezieht Knowledge aus mehreren Quellen, verwendet ein extern bereitgestelltes Modell, greift auf interne Daten zu und interagiert über APIs mit Anwendungen – oft im Kontext eines Business Services, aber mit Komponenten, die mehrere Services gemeinsam nutzen. Das Inventory kennt den Agenten. Es erklärt nicht seine Wirkung.

Die Beziehungskette müsste deshalb weitergehen:

Business Service → IT / Digital Service → AI-enabled Capability → AI Agent / Model → Data + Knowledge → Tools / APIs + Applications → Infrastructure / Cloud → External Provider

Ergänzt um die Governance-Perspektive:

Owner – Identity – Authority – Risk – Control – Monitoring – Decision Log

Nicht jede Organisation wird diese Beziehungen exakt so modellieren. Entscheidend ist, dass die für Steuerung, Risiko und Betrieb relevanten Abhängigkeiten nachvollziehbar werden. Das entspricht einem Grundgedanken des Configuration Managements: Nicht möglichst viele Objekte machen ein CMS wertvoll, sondern die richtigen Informationen und Beziehungen für die erforderlichen Entscheidungen.

Die CMDB muss nicht zum Modellfriedhof werden

Es wäre der falsche Schluss, jedes Foundation Model, jeden Prompt, jede Modellversion und jeden Parameter als Configuration Item abzubilden. Solche Vollständigkeit klingt nach guter Governance, produziert aber Datenbestände, die niemand aktuell halten kann. Die relevantere Frage lautet: Welche Information benötigen wir, um den AI-enabled Service zu steuern, Risiken zu beurteilen und im Fehlerfall handlungsfähig zu bleiben?

Bei einem Agenten mit Lesezugriff auf freigegebenes Knowledge genügt eine schlanke Dokumentation. Greift derselbe Agent auf personenbezogene Daten zu, verändert Berechtigungen oder führt Aktionen in produktiven Systemen aus, werden weitere Beziehungen relevant: der betroffene Service und sein Owner, Zweck und Auftrag des Agenten, Modelle und Provider, Daten- und Knowledge-Quellen, Identität und Berechtigungen, zugelassene Tools und APIs, Autonomiegrad, Risiken und Controls sowie Monitoring und Eskalation. Die Detailtiefe sollte sich an Kritikalität, Risiko und Autonomie orientieren – nicht an der Begeisterung für vollständige Metadaten.

Das ITIL AI Governance Book verfolgt einen ähnlichen Ansatz: Ein AI Capability bzw. Use Case Register erfasst Zweck, Owner, AI Capabilities, Stakeholder, verwendete Daten, Supplier Involvement, Status, Risiken und Evidence Gaps. Für Service Management sollte dieses Register nicht isoliert stehen – die Verbindung zum Service Model ist entscheidend.

Identität wird Teil des Service Models

Bei Agentic AI kommt eine Beziehung hinzu, die wir bei klassischen Anwendungen anders behandelt haben: die operative Identität. Sobald ein Agent auf mehrere Systeme zugreift und Aktionen ausführt, wird seine Identität selbst zum Governance-Objekt. Wer oder was authentisiert sich gegenüber einem Zielsystem? Nutzt der Agent eine eigene technische Identität, delegierte Benutzerrechte oder einen gemeinsam verwendeten Service Account? Welche Credentials, Tokens und Secrets sind damit verbunden? Und lassen sich diese Berechtigungen gezielt entziehen, ohne den gesamten Service ausser Betrieb zu setzen?

Die aktuelle Diskussion um Identity and Access Management für AI Agents zeigt, dass herkömmliche Non-Human-Identity-Modelle an Grenzen geraten. Agenten nutzen Zugriffe dynamisch und kontextabhängig. Wichtig werden eine registrierte Agentenidentität, ein benannter Owner, ein explizit delegierter Scope und durchgängige Auditierbarkeit der Aktionen. Eine Genehmigung zur Erstellung eines Agenten ist nicht dasselbe wie die Autorisierung seiner späteren Aktionen.

Quelle: NHI Management Group – Gartner elevates IAM for AI agents as enterprise governance expands

Die Identität eines Agenten ist damit nicht nur ein Security-Attribut. Sie verbindet Accountability mit technischer Authority: Wenn ein Agent im Auftrag eines Services handelt, muss nachvollziehbar sein, welcher Service diesen Zugriff benötigt, wer ihn verantwortet und welche Aktionen zulässig sind. Ein generischer Service Account mit weitreichenden Berechtigungen wäre schon bei klassischer Automatisierung problematisch. Bei einem Agenten, der selbst entscheidet, welche Aktion er als Nächstes ausführt, entsteht ein grundsätzlich anderes Risikoprofil.

Datenqualität wird zur Qualität des Service Models

Modellierung hilft wenig, wenn die zugrunde liegenden Informationen unzuverlässig sind. Genau hier trifft AI auf ein Problem, das Service Management seit Jahren begleitet: fragmentierte Daten, veraltete Knowledge Articles, unvollständige Configuration Information, inkonsistente Kategorisierungen und schlecht integrierte Tools.

ITSM.tools weist im „ITSM Reset“ 2026 auf diese Diskrepanz hin: In der zitierten Untersuchung mit über 1’000 IT-Fachpersonen geben 95% an, AI zur Verbesserung von ITSM-Prozessen einzusetzen – gleichzeitig bezeichnen nur 12% ihre Service-Management-Practices als proaktiv und vollständig ausgereift. Die grössten Hindernisse für AI ähneln den seit Jahren bekannten Problemen des Service Managements: Security und Compliance, Integration, fehlende Expertise und fragmentierte operative Strukturen.

Quelle: ITSM.tools – ITSM Reset: Why AI Can’t Scale Without ITSM Maturity in 2026

Sind Servicebeziehungen falsch modelliert, arbeitet der Agent mit falschen Beziehungen. Ist Knowledge veraltet, findet AI veraltete Anweisungen sehr effizient und präsentiert sie überzeugend. Fehlt die Zuordnung eines Components zu einem kritischen Business Service, fehlt dieser Kontext auch bei einer AI-gestützten Impact Analysis. Ein Mensch erkennt möglicherweise, dass eine Information unplausibel ist, fragt nach oder kennt einen informellen Zusammenhang. Ein autonom handelnder Agent kann solche Abkürzungen nicht voraussetzen. Er braucht einen belastbaren digitalen Kontext.

Je mehr Entscheidungen wir an AI delegieren, desto stärker müssen die für diese Entscheidungen relevanten Serviceinformationen digital verfügbar, verknüpft und verlässlich sein.

Nicht auf perfekte Daten warten – aber wissen, wo die Grenzen liegen

Umgekehrt müssen Organisationen nicht vor dem ersten AI-Einsatz ihre gesamte CMDB sanieren. Eine Marktstudie von TeamDynamix mit 392 IT-Fachpersonen aus 23 Branchen zeigt, wie verbreitet das Problem ist: 62% bewerten ihre Daten hinsichtlich AI Readiness als „fair“ oder „poor“, nur 5% als „excellent“. Interessant ist die Konsequenz: Die Studie empfiehlt nicht, mit AI zu warten, bis alle Datenprobleme behoben sind, sondern begrenzte Use Cases gerade dazu zu nutzen, Qualitätslücken sichtbar zu machen und die Datenbasis schrittweise zu verbessern.

Quelle: TeamDynamix – AI ITSM in 2026: What’s Working & How to Scale It

Das ist pragmatisch – solange daraus nicht der Schluss gezogen wird, mangelhafte Daten seien bei autonomen Agents unproblematisch. Zwischen einer AI, die einen Knowledge Article vorschlägt, und einem Agenten, der auf Basis derselben Informationen eine produktive Änderung ausführt, liegt ein erheblicher Unterschied. Bei geringer Auswirkung kann AI helfen, schlechte Daten sichtbar zu machen. Mit wachsender Autonomie wird deren Qualität zur Voraussetzung für kontrollierbares Handeln. Auch hier bleibt Governance risikobasiert.

Vom System of Record zum System of Context

Damit verändert sich langfristig die Rolle von CMDB und Service Repository. Die klassische CMDB wurde als System of Record verstanden: Welche CIs existieren, wie sind sie konfiguriert, welche Beziehungen bestehen? Für AI-enabled Services ist das zu eng. Ein Agent benötigt Kontext: zu welchem Service eine Anwendung gehört, welche Business-Kritikalität besteht, welche Daten verarbeitet werden, welcher Provider beteiligt ist, welche Changes zulässig und welche Risiken oder Controls relevant sind. Das Configuration Management System entwickelt sich zu einem System of Context.

Nicht zwingend, indem alle Informationen physisch in einer CMDB gespeichert werden. In modernen Service-Management-Architekturen werden relevante Informationen ohnehin aus verschiedenen Systemen zusammengeführt: Enterprise Architecture Management, Asset Management, Cloud Management, IAM, Security, Contract Management, Monitoring oder GRC. Entscheidend ist die logische Verbindung.

Damit lässt sich eine wichtigere Frage beantworten als mit einem reinen Inventory. Nicht nur: Welche AI haben wir? Sondern: In welchem Servicekontext handelt sie, auf welcher Informationsbasis trifft sie Entscheidungen, worauf darf sie zugreifen und welche Auswirkungen kann ihr Handeln haben?

Genau diese Beziehungen werden benötigt, wenn etwas schiefläuft. Bei einem Incident muss der betroffene Service erkennbar sein. Bei einer Sicherheitsanalyse müssen Identität und Zugriffe nachvollzogen werden können. Bei einem Change interessiert, welche AI Capabilities betroffen sind. Im Audit braucht es Evidenz über Owner, Controls und Entscheidungen. Und beim Providerwechsel muss klar sein, welche Services von einem externen Modell abhängen.

Governance entsteht nicht durch die Liste der AI-Systeme, sondern durch das Verständnis ihrer Beziehungen, Abhängigkeiten und Entscheidungsräume innerhalb der Services.

Damit stellt sich die Frage, die dieses Modell erst steuerbar macht: Wie viel Entscheidungs- und Handlungsfreiheit geben wir einem Agenten? Denn nicht jede AI braucht dieselbe Governance – Autonomie braucht Abstufung, und jede Stufe braucht die passenden Controls.

4. Autonomie braucht Governance – ein Modell mit Autonomie-Leveln

In der Governance wird häufig noch binär gedacht: AI ist erlaubt oder nicht erlaubt. Eine Anwendung wird freigegeben, ein Use Case genehmigt, ein Agent für den produktiven Einsatz zugelassen – und die Governance-Frage scheint beantwortet. Bei Agentic AI reicht das nicht. Entscheidend ist nicht nur, ob ein Agent eingesetzt werden darf, sondern welche Entscheidungs- und Handlungsbefugnisse ihm innerhalb eines konkreten Services übertragen werden. Autonomie wird selbst zum Governance-Objekt.

Capability beschreibt, was AI kann. Authority definiert, was sie darf. Autonomie beschreibt, wie weit sie dabei ohne menschliche Entscheidung handeln kann. Diese drei Dinge sollten nicht verwechselt werden.

Human-in-the-Loop ist noch kein Governance-Modell

Die häufigste Antwort lautet derzeit „Human-in-the-Loop“. Das Prinzip ist richtig, als Governance-Modell aber zu unscharf. Ein Mensch kann eine Entscheidung vor der Aktion genehmigen, lediglich informiert werden, Ausnahmen bearbeiten, während Standardfälle autonom laufen, oder erst eingreifen, wenn Monitoring eine Abweichung erkennt. All dies ist Human Oversight – mit völlig unterschiedlicher Kontrollwirkung.

Hinzu kommt: Wenn ein Agent 10’000-mal täglich eine klar definierte, reversible und risikoarme Aktion ausführt, macht eine Einzelgenehmigung den Zweck der Automatisierung zunichte. Umgekehrt wäre es kaum vertretbar, einen Agenten autonom über einen kritischen Produktions-Change entscheiden zu lassen, nur weil seine bisherigen Empfehlungen meistens richtig waren. Die Intensität menschlicher Aufsicht muss zur möglichen Auswirkung passen.

PwC formuliert diesen Zusammenhang klar: Agents benötigen eine eigene verifizierte Identität, definierte Rollen, aufgabenspezifische Berechtigungen, auditierbare Aktivitäten und klare Grenzen autonomen Handelns. Mit steigender Autonomie soll auch die menschliche Aufsicht zunehmen – besonders bei Entscheidungen mit Auswirkungen auf Kunden, Mitarbeitende, sensitive Daten, finanzielle Ergebnisse oder rechtliche Verpflichtungen.

Quelle: PwC – AI agents as workforce counterparts: what governance should look like

Nicht möglichst viel Human-in-the-Loop ist das Ziel, sondern die richtige Form von Human Oversight für den jeweiligen Entscheidungsraum.

Fünf Autonomie-Level für AI-enabled Services

Ein praktikables Governance-Modell sollte deshalb unterschiedliche Autonomiegrade unterscheiden. Für Service Management bietet sich eine Einteilung in fünf Level an:

Level	Rolle der AI	Beispiel im Service Management	Governance-Schwerpunkt
0 – Informieren	AI stellt Informationen bereit	Knowledge Search, Zusammenfassung eines Incidents	Logging, Daten- und Quellenqualität
1 – Empfehlen	AI bewertet Informationen und schlägt eine Handlung vor	Lösungsvorschlag, Priorisierung, mögliche Root Cause	Human Review, Nachvollziehbarkeit
2 – Entscheiden mit Freigabe	AI bereitet Entscheidung und Aktion vor	Change vorbereiten, Recovery-Massnahme vorschlagen	Human Approval, Segregation of Duties
3 – Begrenzt autonom handeln	AI entscheidet und handelt innerhalb definierter Grenzen	Standard Request ausführen, bekannte Recovery durchführen	Guardrails, Least Privilege, Monitoring, Reversibility
4 – Autonom handeln	AI erkennt Situationen, entscheidet und führt Aktionen weitgehend selbständig aus	Incident erkennen, Ursache bestimmen und Service automatisch wiederherstellen	Continuous Control, Echtzeit-Monitoring, definierte Eskalation, Kill Switch

Das Modell ist bewusst einfach gehalten und beantwortet eine operative Frage: Wie weit darf ein Agent gehen, bevor ein Mensch entscheiden muss? Diese Grenze kann für denselben Agenten je nach Aktion unterschiedlich sein: Er analysiert einen Incident auf Level 1 und empfiehlt eine Root Cause; einen bekannten Recovery-Schritt darf er auf Level 3 ausführen; eine Änderung an einer geschäftskritischen Anwendung bleibt Level 2 und braucht eine explizite Freigabe. Nicht der Agent als Ganzes wird einem Level zugeordnet, sondern sein Entscheidungs- und Handlungsspielraum innerhalb eines definierten Kontextes.

Autonomie ist immer kontextabhängig

Dieselbe technische Aktion kann je nach Service völlig unterschiedliche Auswirkungen haben. Der Neustart einer Testinstanz ist etwas anderes als der Neustart einer Komponente, von der ein kritischer Geschäftsprozess abhängt. Der Zugriff auf öffentliches Knowledge unterscheidet sich vom Zugriff auf Personaldaten. Eine automatische Gutschrift über zehn Franken ist anders zu behandeln als eine Transaktion mit erheblichem Betrag. Governance muss deshalb mindestens drei Dimensionen zusammenbringen:

Autonomie × Kritikalität × mögliche Auswirkung

Dazu kommen regulatorische Anforderungen, Datenklassifikation und die Reversibilität einer Aktion. Gerade Reversibilität wird unterschätzt: Ein Agent, der eine falsche Konfiguration setzt und sie automatisch zurücknehmen kann, erzeugt ein anderes Risiko als einer, dessen Entscheidung nicht oder nur mit erheblichem Aufwand rückgängig zu machen ist.

Die Cloud Security Alliance betont bei der Operationalisierung von AI Governance, dass mit zunehmender Einbettung von AI in operative Workflows die Anforderungen an Monitoring, Datenqualität und Lifecycle Governance steigen. Entscheidungen autonomer Systeme müssen erklärbar, accountable und bei entsprechenden Anwendungen reversibel bleiben. Governance sollte nicht als nachgelagerte Compliance-Kontrolle verstanden werden, sondern in technische und operative Abläufe eingebettet sein.

Quelle: Cloud Security Alliance – AI Governance and ISO 42001 FAQs: What Organizations Need to Know in 2026

Die klassische Risikobetrachtung bekommt damit eine zusätzliche Dimension: Nicht nur Wahrscheinlichkeit und Auswirkung eines Fehlers sind relevant, sondern auch, wie weit ein Agent handeln kann, bevor der Fehler erkannt und begrenzt wird.

Berechtigungen müssen dem Auftrag folgen – nicht den technischen Möglichkeiten

Ein Agent sollte keinen Zugriff erhalten, weil er für irgendeinen künftigen Use Case nützlich sein könnte. Seine Berechtigungen müssen aus seinem konkreten Auftrag und dem zugelassenen Handlungsspielraum abgeleitet werden. Das ist Least Privilege – bei Agentic AI mit zusätzlicher Bedeutung. Ein Agent kann mehrere Tools kombinieren, Informationen aus verschiedenen Quellen zusammenführen und Aktionen sequenziell auslösen; in Multi-Agent-Architekturen ruft er andere Agents auf. Einzeln legitime Berechtigungen können in ihrer Kombination einen Handlungsspielraum ergeben, der nie vorgesehen war.

Besonders kritisch sind indirekte Privilegien: Ein Agent hat selbst keine Berechtigung für eine Änderung, kann aber einen anderen Agenten oder ein Tool aufrufen, das sie besitzt. Technisch ist jeder Zugriff korrekt; governance-seitig entsteht eine nicht autorisierte Privilegienkette – in der Agent-Governance-Diskussion als „permission laundering“ bezeichnet. Für Agent-to-Agent-Interaktionen wird empfohlen, Berechtigungen nicht entlang einer Aufrufkette weiterzureichen: Jeder Agent handelt in seinem eigenen autorisierten Scope, und die gesamte Aktivitätskette bleibt nachvollziehbar.

Ein Agent darf seine eigene Authority nicht dadurch erweitern können, dass er andere Agents oder Tools mit weitergehenden Berechtigungen aufruft. Für IAM, API Management und Service Management wird diese Frage erheblich an Bedeutung gewinnen.

Guardrails müssen technisch wirksam sein

Policies allein begrenzen keinen Agenten. Eine Vorgabe, dass ein Agent keine produktiven Changes ohne Freigabe durchführt, wird erst wirksam, wenn Berechtigungen und Workflows diese Grenze technisch durchsetzen. Dasselbe gilt für finanzielle Limiten, Datenzugriffe, erlaubte APIs, zeitliche Berechtigungen oder die Anzahl bestimmter Aktionen. Guardrails sollten möglichst nahe an der tatsächlichen Handlung wirken: auf Tools beschränkte Berechtigungen, zeitlich begrenzte Tokens, freigegebene Aktionstypen, Transaktionslimiten, Approval Gates, Segregation of Duties oder die technische Sperrung kritischer Operationen.

Bei höherer Autonomie kommt Verhaltens-Monitoring hinzu: ungewöhnliche Tool-Aufrufe, unerwartete Aktionsketten, steigende Fehler- oder Override-Raten, Abweichungen vom Scope oder Veränderungen nach einem Modell-Update. Und es braucht einen letzten Mechanismus: die Möglichkeit, Autonomie zurückzunehmen. Ein Kill Switch klingt dramatischer, als er sein sollte. Im Kern ist er eine definierte Betriebsfähigkeit: Ein Agent muss gestoppt, isoliert oder auf einen weniger autonomen Modus zurückgesetzt werden können, ohne dass dafür zunächst seine Architektur analysiert werden muss.

Besonders bemerkenswert: ISO/IEC TS 20000-19

Dass diese Fragen im Kern des Service Managements angekommen sind, zeigt eine für diesen Blog besonders relevante Entwicklung. Mit ISO/IEC AWI TS 20000-19 – Guidance on the use of AI in a service management system based on ISO/IEC 20000-1 entsteht erstmals eine ISO-Publikation, die sich ausdrücklich mit AI innerhalb eines Service Management Systems beschäftigt. Das Projekt wurde am 18. Mai 2026 genehmigt und am 9. Juni 2026 in das Arbeitsprogramm von ISO/IEC JTC 1/SC 40 aufgenommen. Es ist damit ein Approved Work Item und noch kein publizierter Standard.

Quelle: ISO – ISO/IEC AWI TS 20000-19: Guidance on the use of AI in a service management system

Die geplante Technical Specification soll Organisationen bei einer verantwortungsvollen, wirksamen und auditierbaren Nutzung von AI innerhalb eines auf ISO/IEC 20000 basierenden Service Management Systems unterstützen – über den gesamten Service Lifecycle von Planung und Design über Transition und Delivery bis zur Verbesserung. Als Governance-Themen nennt ISO Transparenz, Accountability, Risk Management, Datenqualität und Human Oversight. Das bestätigt: AI Governance wird nicht ausserhalb des Service Management Systems stattfinden können. Gerade Human Oversight muss im Service Management zu einer konkreten Designentscheidung werden: Welche Aktionen darf ein Agent selbst ausführen? Wann braucht es Approval? Welche Entscheidungen werden nur protokolliert? Wann erfolgt eine Eskalation? Unter welchen Bedingungen wird Autonomie automatisch eingeschränkt? ISO/IEC TS 20000-19 dürfte damit eine wichtige Brücke zwischen AI Governance und etabliertem Service Management schlagen.

Autonomie muss veränderbar bleiben

Das Autonomie-Level eines Agenten sollte nicht dauerhaft festgeschrieben sein. Ein Agent kann auf Level 1 starten; seine Empfehlungen werden über einen definierten Zeitraum überprüft. Sind Datenqualität, Zuverlässigkeit und Kontrollmechanismen ausreichend, können bestimmte Aktionen auf Level 2 oder 3 angehoben werden. Der umgekehrte Weg muss genauso vorgesehen sein: Steigt die Fehlerquote, verändert sich das Modell, treten ungewöhnliche Aktionen auf oder ändern sich regulatorische Rahmenbedingungen, wird Autonomie reduziert – etwa von autonomer Ausführung zurück zu Human Approval. Autonomie wird zu einer dynamischen, risikobasierten Berechtigung. Das passt zur Lifecycle-Sicht des ITIL AI Governance Book: Eine einmal erteilte Freigabe reicht nicht, wenn sich die Voraussetzungen verändern, unter denen sie erteilt wurde.

Ein hoher Autonomiegrad ist deshalb kein Reifegradabzeichen. Nicht jede Organisation muss Level 4 erreichen, und nicht jeder Use Case sollte dorthin gelangen. Reife zeigt sich darin, bewusst entscheiden zu können, welcher Autonomiegrad für einen bestimmten Service und eine bestimmte Aktion vertretbar ist – und diese Grenze technisch durchsetzen und überwachen zu können.

Je höher die Autonomie und die mögliche Auswirkung, desto stärker müssen Identität, Berechtigungen, Nachvollziehbarkeit, Monitoring, Reversibilität und menschliche Eingriffsmöglichkeiten ausgestaltet sein.

Gute Governance verhindert Autonomie nicht. Sie schafft die Voraussetzungen, sie verantwortbar zuzulassen. Und genau deshalb dürfen diese Controls nicht in einem separaten AI Governance Framework enden. Sie müssen dort wirksam werden, wo AI tatsächlich handelt: im Service Management System.

5. AI Governance gehört in das Service Management System

Die bisherigen Überlegungen führen zu einer naheliegenden Versuchung: ein eigenes AI Governance Framework mit AI Board, AI Risk Process, AI Inventory, AI Controls, AI Incident Process und separatem Agent Lifecycle. Das kann kurzfristig Ordnung schaffen. Langfristig droht eine zusätzliche Kontrollwelt neben den bestehenden Managementsystemen. Wenn AI Bestandteil eines Services wird, müssen ihre Risiken, Abhängigkeiten und Entscheidungsbefugnisse dort gesteuert werden, wo auch der Service gesteuert wird. Ein Agent braucht möglicherweise zusätzliche Controls – aber keinen parallelen Managementapparat.

Die entscheidende Frage lautet nicht: Welche neuen AI-Prozesse müssen wir schaffen? Sondern: Welche bestehenden Management Capabilities müssen wir erweitern, damit sie auch AI-enabled Services und autonome Agents wirksam steuern können?

Das ITIL AI Governance Book verfolgt genau diesen Integrationsgedanken: AI Governance steht nicht isoliert neben Strategie, Product und Service Management, Change, Operations, Security, Risk, Supplier Management und Continual Improvement. Governance muss mit der AI-Adoption mitwachsen und bestehende Prozesse um konkrete Controls ergänzen, statt AI als zusätzliche Technologie zu behandeln. Was das für die einzelnen Practices bedeutet:

Service Portfolio Management – nicht jeder AI Use Case gehört in Produktion

Die erste Governance-Entscheidung fällt vor dem Betrieb. AI Use Cases sind nicht nur hinsichtlich technischer Machbarkeit zu beurteilen, sondern hinsichtlich ihres Beitrags zu Produkten und Services: Welches Problem wird gelöst? Welcher Service verändert sich? Welcher Nutzen wird erwartet? Welche Abhängigkeit entsteht? Rechtfertigt sich der operative und regulatorische Aufwand? Gerade bei Agentic AI ist das wichtig: Agents lassen sich schnell entwickeln, was zu vielen lokalen Optimierungen verleitet – ein Agent für Incident Triage, einer für Knowledge, einer für Changes, weitere für Monitoring, Security oder Benutzeranfragen. Jeder einzelne wirkt plausibel; in Summe entsteht eine schwer steuerbare Agentenlandschaft. Portfolio Governance muss Konsolidierung zulassen: Nicht jeder Proof of Concept wird produktiv, nicht jeder Agent wird dauerhaft betrieben. Das ist keine AI-spezifische Erkenntnis – es ist gutes Portfolio Management.

Service Design – Governance beginnt vor dem ersten Prompt

Viele Controls lassen sich nachträglich nur mit erheblichem Aufwand einbauen. Bereits im Design müssen Fragen geklärt werden, die bislang teilweise erst Security, Risk oder Operations gestellt haben: Welche Aufgabe übernimmt die AI? Welche Daten benötigt sie? Welche Entscheidungen darf sie treffen? Welche Systeme kann sie ansteuern? Welcher Autonomiegrad, welche menschliche Intervention? Was geschieht bei Unsicherheit oder widersprüchlichen Informationen? Dazu gehören nichtfunktionale Anforderungen: Logging und Auditability, Monitoring, Fallback-Verhalten, Reversibilität und die kontrollierte Deaktivierung. Bei externen AI Services kommen Provider-Abhängigkeiten, Datenverarbeitung und mögliche Modelländerungen hinzu. Neben Availability, Capacity, Continuity, Security und Service Levels braucht Service Design eine weitere Perspektive: Wie bleibt das Verhalten der AI innerhalb des vorgesehenen Entscheidungsraums kontrollierbar? Das ist Design for Governance.

Change Enablement – ein Modell-Update kann ein Service Change sein

Nicht jede Änderung an einem Prompt braucht ein CAB, und nicht jede Aktualisierung eines Foundation Models ist ein Major Change. Der umgekehrte Schluss wäre aber genauso problematisch: Eine neue Modellversion kann das Verhalten eines Agents verändern, eine zusätzliche Knowledge Source seine Informationsbasis, eine Änderung am System Prompt seine Entscheidungsgrenzen, ein neuer API-Zugriff seinen Handlungsspielraum. Entscheidend ist nicht, ob technisch etwas an der AI geändert wurde, sondern ob die Änderung Leistung, Verhalten, Risiken oder den autorisierten Handlungsspielraum des Services wesentlich beeinflussen kann.

Das ITIL AI Governance Book beschreibt den Fall eines Provider-Updates, nach dem ein AI-System vermehrt falsche Alerts erzeugt. Die Reaktion ist nicht, das als Eigenart des neuen Modells hinzunehmen: Rollback, Untersuchung von Modell, Daten, Schwellenwerten und Integration sowie kontrollierte Wiederaufnahme gehören zum normalen Management des Services. AI Change Governance muss risikobasiert sein: Ein Tippfehler in einem Prompt ist etwas anderes als eine Änderung, durch die ein Agent erstmals produktive Systeme verändern darf.

Service Configuration Management – neue Beziehungen werden relevant

Wir müssen nicht jedes Modellgewicht und jeden Prompt als CI verwalten, aber diejenigen Informationen kennen, die für Impact Assessment, Betrieb, Security, Audit und Wiederherstellung relevant sind: AI Capability, Agent, Modell bzw. Model Service, Daten- und Knowledge-Quellen, Identität, Berechtigungen, APIs, Provider und Autonomie-Level. Vor allem die Beziehungen zählen. Wenn ein Agent ausfällt oder sein Verhalten ändert, muss erkennbar sein, welche Services betroffen sind. Wird eine Knowledge Source geändert, sollte klar sein, welche Agents davon abhängen. Wird ein externer Provider ersetzt, interessiert nicht nur der Vertrag, sondern der Service Impact. Configuration Management wird so zur Grundlage für AI Governance – nicht als Inventarisierungsübung, sondern als Kontext für Entscheidungen.

Information Security Management – der Agent wird zur Identity

Ein Agent, der Informationen zusammenfasst, braucht vielleicht nur Read Access. Ein anderer verändert Benutzerkonten, konfiguriert Cloud-Ressourcen oder löst Security Controls aus – spätestens dann ist seine Identität kein technisches Detail mehr. Gartner ordnet IAM für Agents inzwischen als relevantes Emerging Technology Field ein. Die zentrale Herausforderung liegt weniger in der erstmaligen Authentisierung als in delegierter, dynamischer und kontextabhängiger Authority: Agents nutzen innerhalb einer Session verschiedene Tools und Datenquellen; statische Entitlement-Modelle bilden diesen Handlungsspielraum nur begrenzt ab (siehe die in Kapitel 3 zitierte NHI-Analyse).

Für Security und Service Management folgt daraus: Ein produktiver Agent ist als kontrollierte Non-Human Identity zu behandeln – mit benanntem Owner, explizit delegiertem Scope und nachvollziehbaren Berechtigungen. Besonders relevant ist die Laufzeit. Ein klassisches Access Review fragt periodisch, welche Berechtigungen eine Identität besitzt. Bei einem Agenten kommt hinzu: Welche davon nutzt er in welchem Kontext und über welche Aktionskette? Greift er direkt zu oder über ein anderes Tool? Kann er durch Kombination legitimer Berechtigungen einen nie vorgesehenen Handlungsspielraum erzeugen? Least Privilege bleibt richtig – es wird dynamischer.

Agent Identity, Task Scope, Tool Scope und Data Scope müssen zusammenpassen. Fehlt diese Verbindung, wird aus delegierter Authority unkontrollierte Reichweite.

Supplier Management – wir kaufen nicht nur Technologie, sondern Verhalten

Ein erheblicher Teil der AI Capabilities wird eingekauft: Modelle, AI Services, SaaS-Funktionen oder komplette Agents. Damit entstehen klassische Supplier-Risiken mit neuen Varianten: Ein Provider verändert sein Modell, ohne dass der Kunde den Change kontrolliert. Datenverarbeitung und Subprovider ändern sich. Ein SaaS-Produkt erhält neue agentische Fähigkeiten. Und das Verhalten eines neuen Modells lässt sich möglicherweise nicht vollständig mit dem bisherigen vergleichen. Supplier Management muss deshalb mehr erfassen als Availability und Support: Transparenz über wesentliche Änderungen, Security und Datenschutz, Datenverwendung, Subprovider, Modell- und Serviceänderungen, Incident Notification, Audit- und Assurance-Nachweise sowie Exit- und Substitutionsmöglichkeiten.

Das ITIL AI Governance Book betont diesen Service-Relationship-Kontext: AI Tools, Modelle, Plattformen, Datenservices und Automatisierungen können von Dritten bereitgestellt oder in umfassendere digitale Services eingebettet sein. Die eigene Organisation bleibt dafür verantwortlich zu verstehen, wie Value, Risk, Assurance, Monitoring und Improvement über diese Beziehungen hinweg gesteuert werden. Outsourcing bleibt Outsourcing – auch wenn der Lieferant jetzt ein Modell ist.

Incident Management – wann ist ein AI-Fehler ein Incident?

Ein Agent kann nicht verfügbar sein – das ist der einfache Fall. Schwieriger wird es, wenn er verfügbar ist und falsch handelt: einen kritischen Incident falsch klassifiziert, einem Benutzer eine falsche Anweisung gibt, eine unerwartete Aktion ausführt, Informationen an einen Unberechtigten weitergibt, oder ein Modell-Update die Entscheidungsqualität verändert. Nicht jeder AI-Fehler braucht einen eigenen „AI Incident“-Prozess. Beeinträchtigt das Verhalten Qualität oder Verfügbarkeit eines Services, ist es ein Service Incident. Liegt eine Verletzung von Vertraulichkeit, Integrität oder Berechtigung vor, kommt der Information Security Incident Process hinzu. Bei regulatorischen Auswirkungen entstehen weitere Melde- und Eskalationspflichten.

Wichtiger als das Label ist die Fähigkeit, den Zusammenhang zu erkennen: Welcher Agent war beteiligt? Welche Version? Welche Daten und Tools? Welche Aktion? Welcher Service ist betroffen? Kann die Autonomie sofort reduziert oder der Agent deaktiviert werden? Die Incident Response muss diese Informationen verfügbar haben, bevor der erste ernsthafte Agent Incident auftritt.

Problem Management – wenn der Fehler nicht im Code liegt

Bei klassischen Problemen suchen wir einen fehlerhaften Component, eine falsche Configuration oder einen Software-Defekt. Bei AI ist die Ursache weniger eindeutig: Modell ungeeignet? Datenbasis falsch? Knowledge veraltet? Prompt missverständlich? Entscheidungsgrenze zu weit? Tool falsch eingebunden? Oder hat der Agent innerhalb seiner Spezifikation gehandelt, aber ein im Servicekontext nicht akzeptables Ergebnis erzeugt? Problem Management muss Beziehungen untersuchen, die bisher nicht Teil der Root Cause Analysis waren:

Problem → Service → Agent → Modellversion → Prompt/Configuration → Data/Knowledge Source → Tool/API → Provider

Hinzu kommen menschliche Overrides. Wenn Mitarbeitende Entscheidungen eines Agents regelmässig korrigieren, ist das nicht nur Benutzerfeedback, sondern ein Frühindikator für ein strukturelles Problem. AI liefert neue Problem-Daten – vorausgesetzt, wir erfassen sie.

Monitoring & Event Management – Availability reicht nicht

Ein grüner Status sagt bei AI wenig darüber aus, ob der Service korrekt funktioniert. Ein Agent kann vollständig verfügbar sein und gleichzeitig zunehmend schlechtere Entscheidungen treffen. Observability muss deshalb erweitert werden: Neben technischen Metriken werden je nach Use Case Accuracy, Fehlerraten, Human Overrides, Eskalationen, ungewöhnliche Tool-Aufrufe, Scope-Abweichungen oder Veränderungen nach Modell- und Datenupdates relevant.

Ein sekundärer Bericht über Gartners Ansatz zur proportionalen Agent Governance unterscheidet vier Stufen – Observe, Advise, Act with Approval, Act Autonomously – und fordert für autonome Agents zusätzlich kontinuierliche Verhaltensüberwachung, Guardrails auf Aktionsebene, schnelle Rollback-Mechanismen und Circuit Breaker. Entscheidend ist die Proportionalität: Controls müssen zum tatsächlichen Handlungsspielraum des Agents passen, nicht zu seiner ursprünglichen Projektbeschreibung. Die Quelle ist eine Sekundärdarstellung, die dort verwendeten Prognosen sind entsprechend einzuordnen. Der operative Grundgedanke überzeugt dennoch: Monitoring darf nicht ergänzt werden, nachdem Autonomie eingeführt wurde. Es ist eine Voraussetzung dafür.

Quelle: THE D*AI*LY BRIEF – 40% of AI Agents Die by 2027: Gartner’s 4-Level Fix

Continual Improvement – menschliche Korrekturen sind Governance-Daten

AI-enabled Services erzeugen laufend Informationen darüber, wie gut ihre Governance funktioniert: Menschen korrigieren Empfehlungen, Agents eskalieren, Entscheidungen werden zurückgenommen, Guardrails greifen, Incidents treten auf, Benutzer umgehen die AI. Diese Daten sagen nicht nur etwas über das Modell aus, sondern über Service Design und Governance. Eskaliert ein Agent häufig an derselben Entscheidungsgrenze, ist vielleicht der Scope falsch definiert. Überschreiben Menschen einen Vorschlag systematisch, liegt ein Daten- oder Knowledge-Problem vor. Wird ein Kill Switch mehrfach benötigt, ist nicht nur der Agent zu untersuchen, sondern auch sein Autonomie-Level. Continual Improvement muss Modellqualität, Servicequalität und Governance-Wirksamkeit zusammen betrachten. Das ITIL AI Governance Book nennt entsprechend Performance und Reliability, Risiken, regulatorische Veränderungen, Supplier Changes, Feedback, Incidents, Near Misses und Audit Findings als Inputs für die laufende Anpassung von AI Governance.

Service Management ist nicht das Hindernis für AI – sondern die Voraussetzung für Skalierung

Dass AI im ITSM längst nicht mehr nur experimentell eingesetzt wird, zeigen aktuelle Marktdaten. Der von HCLSoftware gemeinsam mit ITSM.tools durchgeführte State of AI in ITSM 2025 Report basiert auf 186 ITSM-Fachpersonen. Danach haben 88% der Organisationen bereits AI-Fähigkeiten in ihren ITSM-Werkzeugen, mehr als die Hälfte nutzt oder testet sie aktiv. Als erwartete Hauptnutzen werden eine bessere End-User Experience (65%), die Optimierung der ITSM Operations (54%) und höhere Mitarbeiterproduktivität (50%) genannt.

Quelle: HCLSoftware – State of AI in ITSM 2025 Report

AI wandert vom Pilot in den operativen Servicebetrieb. Damit wird Governance nicht weniger wichtig, sondern konkreter. Service Management besitzt bereits einen grossen Teil der Mechanismen, die für kontrollierbare AI benötigt werden. Wir müssen diese Fähigkeiten nicht ersetzen. Wir müssen sie AI-fähig machen. Ein separates AI Governance Framework kann festlegen, was verantwortungsvolle AI bedeutet. Erst die Integration in das Service Management System stellt sicher, dass daraus im täglichen Betrieb kontrollierte Entscheidungen, nachvollziehbare Changes, begrenzte Berechtigungen, behandelbare Incidents und überprüfbare Controls entstehen.

AI Governance gehört nicht neben das Service Management System. Sie muss darin wirksam werden. Damit stellt sich die Frage nach dem Zusammenspiel der Managementsysteme und Best Practices – denn auch hier wäre es wenig hilfreich, drei parallele Welten aufzubauen.

6. ISO 42001, ISO 20000 und ITIL – nicht drei Welten bauen

Mit AI Governance wächst die Zahl der Referenzmodelle und Anforderungen. ISO/IEC 42001 etabliert ein Managementsystem für AI. ISO/IEC 20000 adressiert das Management von Services. ITIL liefert ein Modell für digitale Produkte, Services, Value Streams und Management Practices. Dazu kommen EU AI Act, NIST AI RMF, Security Frameworks und branchenspezifische Vorgaben. Die Gefahr liegt auf der Hand: Für jeden Anforderungskatalog entsteht ein eigenes Governance-Konstrukt – ein AIMS neben dem SMS, daneben das ISMS, zusätzliche Risk Assessments, separate Committees, eigene Kontrollkataloge und Reporting-Strukturen. Inhaltlich überschneiden sich diese Mechanismen; organisatorisch werden sie getrennt betrieben. Das Ergebnis ist nicht mehr Governance, sondern mehr Governance-Administration.

Gerade bei AI wäre das kontraproduktiv. AI lässt sich nicht sinnvoll ausserhalb der Services steuern, in denen sie eingesetzt wird. Ebenso wenig kann Service Management die übergeordneten Anforderungen an verantwortungsvolle AI allein definieren. Wir brauchen keine drei Welten, sondern müssen ihre unterschiedlichen Aufgaben verstehen und verbinden.

ISO/IEC 42001 schafft den Managementrahmen für AI

ISO/IEC 42001:2023 ist der erste internationale Managementsystemstandard für AI. Er spezifiziert Anforderungen für Aufbau, Implementierung, Aufrechterhaltung und kontinuierliche Verbesserung eines Artificial Intelligence Management Systems (AIMS) und richtet sich an Organisationen, die AI-basierte Produkte oder Services entwickeln, bereitstellen oder nutzen. Für Organisationen mit ISO-Erfahrung ist der Ansatz vertraut: Kontext und Scope bestimmen, Verantwortlichkeiten festlegen, Risiken und Chancen beurteilen, Controls definieren, Wirksamkeit überwachen, Verbesserungen steuern. Neu ist der Gegenstand – und dieser verlangt eine breitere Risikoperspektive: Neben Vertraulichkeit, Integrität und Verfügbarkeit werden Transparenz, Nachvollziehbarkeit, Datenqualität, Auswirkungen auf betroffene Personen, Bias, Robustheit, Human Oversight und die Folgen automatisierter Entscheidungen relevant.

ISO/IEC 42001 schafft dafür den organisatorischen Rahmen, beantwortet aber bewusst nicht jede operative Frage eines einzelnen Services. Ein AIMS legt nicht im Detail fest, wie ein AI-bedingter Incident im Service Desk behandelt, eine Modelländerung im Change Enablement bewertet oder die Abhängigkeit eines Agents von einem externen Provider im Configuration Management abgebildet wird. Genau dort beginnt die Verbindung zum Service Management.

Von Responsible AI zu vertrauenswürdigen Services

Diese Verbindung habe ich im Beitrag „ISO/IEC 42001 und AI-enabled Services: Von Responsible AI zu vertrauenswürdigen Services“ ausführlicher betrachtet. Die zentrale Überlegung: Responsible AI darf nicht bei Prinzipien wie Fairness, Transparency, Accountability oder Human Control stehen bleiben. Für einen AI-enabled Service müssen daraus konkrete Verantwortlichkeiten, Entscheidungsrechte, Controls und Nachweise entstehen.

Quelle: ISO/IEC 42001 und AI-enabled Services: Von Responsible AI zu vertrauenswürdigen Services

Dabei verändert sich unser Verständnis von Servicequalität. Ein AI-enabled Service muss weiterhin verfügbar, performant, sicher und wirtschaftlich sein. Zusätzlich stellt sich die Frage, ob Kunden, Anwender und Stakeholder darauf vertrauen können, wie AI in diesem Service eingesetzt wird. Ein leistungsfähiges Modell kann für einen konkreten Service ungeeignet sein. Eine automatisierte Entscheidung kann effizient und dennoch nicht nachvollziehbar sein. Ein Agent kann exakt das tun, wofür er konfiguriert wurde, und dabei einen Handlungsspielraum besitzen, den ihm organisatorisch niemand bewusst geben wollte. Responsible AI und Trustworthiness werden zu Qualitätsmerkmalen eines AI-enabled Service: Das AIMS schafft den Rahmen, das Service Management System sorgt dafür, dass diese Anforderungen im konkreten Service wirksam werden.

Ein Managementsystem ist noch kein Betriebsmodell

Die Cloud Security Alliance weist in ihrer Einordnung zu ISO/IEC 42001 auf einen wichtigen Punkt hin: Mit der Einbettung von AI in operative Workflows werden aus Fehlern isolierter Experimente systemische Auswirkungen auf Geschäftsprozesse; entsprechend steigen die Anforderungen an Model Monitoring, Datenqualität und Lifecycle Governance. Zugleich beschreibt die CSA eine typische Lücke zwischen Policy und technischer Umsetzung. Wirksame Organisationen verbinden übergeordnete Governance mit konkreten technischen und operativen Mechanismen – Risk Tiers, Model Cards, MLOps Controls, automatisierte Checks und Deployment Gates. Governance wird nicht nach der Entwicklung kontrolliert, sondern in die Arbeitsabläufe eingebettet.

Quelle: Cloud Security Alliance – AI Governance and ISO 42001 FAQs: What Organizations Need to Know in 2026

Für Service Management lässt sich derselbe Gedanke weiterführen. Legt ein AI Risk Assessment fest, dass ein Agent bei bestimmten Aktionen Human Approval benötigt, dokumentiert das AIMS Risiko, Behandlung und Verantwortlichkeit – im Service Management muss daraus ein Approval Workflow werden. Verlangt das AIMS nachvollziehbare Verantwortlichkeiten, müssen im Service Service Owner, AI Owner, Data Owner, Risk Owner und Supplier Responsibilities zusammenpassen. Fordert das AIMS Monitoring und Continual Improvement, müssen im Betrieb Events, Messgrössen, Incidents, Problems, Overrides, Eskalationen und Verbesserungsmassnahmen verarbeitet werden. Ein Managementsystem gibt Struktur und Anforderungen vor. Der Service Lifecycle macht sie operativ.

ISO/IEC 20000 bringt AI in den Servicekontext

ISO/IEC 20000-1 betrachtet ein Service Management System als integrierten Managementrahmen für Planung, Design, Transition, Delivery und Improvement von Services. Wenn AI Bestandteil dieser Services wird, müssen AI-spezifische Anforderungen innerhalb dieses Systems wirksam werden. Dass ISO genau an dieser Verbindung arbeitet, zeigt die in Kapitel 4 vorgestellte ISO/IEC AWI TS 20000-19. Damit wird etwas formalisiert, was bisher häufig zwischen AI Governance und ITSM liegen bleibt: Wie übersetzen wir AI Governance in die konkrete Steuerung eines Services? Genau deshalb ist ISO/IEC TS 20000-19 eine Entwicklung, die man im Service Management genau beobachten sollte – nicht weil wir einen weiteren Standard benötigen, sondern weil die Verbindung zwischen AI Governance und Service Management ausdrücklich zum Gegenstand internationaler Standardisierung wird.

ITIL liefert die Managementpraxis dazwischen

ISO/IEC 42001 und ISO/IEC 20000 sind Managementsystemstandards. ITIL hat eine andere Funktion: Es beschreibt, wie digitale Produkte und Services über Value Streams, Lifecycle-Aktivitäten und Management Practices gestaltet, betrieben und verbessert werden. Mit ITIL AI Governance wird diese Logik auf AI-enabled Products, Services und Arbeitsweisen erweitert. Die Governance reicht in Strategie, Portfolio, Product und Service Management, Projekte, Change, Operations, Data und Security, Risk und Compliance, Supplier Management und Continual Improvement hinein. Besonders wichtig ist die Lifecycle-Perspektive: Ein AI-enabled Service muss während Discover, Design, Acquire, Build, Transition, Operate, Deliver und Support gesteuert werden.

ISO/IEC 42001 kann fordern, AI-bezogene Risiken angemessen zu behandeln. ITIL hilft, diese Behandlung in Portfolio-Entscheidungen, Service Design, Change, Supplier Management, Monitoring, Incident Management und Continual Improvement zu verankern. Das ist keine Konkurrenz zwischen Framework und Standards. Es sind unterschiedliche Ebenen derselben Steuerungsaufgabe.

Drei Ebenen – eine Governance

Vereinfacht lässt sich das Zusammenspiel so darstellen:

ISO/IEC 42001 – AI Management System
Definiert den organisationsweiten Rahmen für verantwortungsvolle Entwicklung, Bereitstellung und Nutzung von AI: Governance, Policy, Accountability, Risk und Impact Assessment, Controls, Performance Evaluation und Continual Improvement.
↓
ISO/IEC 20000 / ITIL – Service Management System und Service Lifecycle
Ordnen AI in Produkte und Services ein. Ownership, Service Design, Lifecycle, Value Streams, Supplier Relationships und Management Practices schaffen den operativen Kontext.
↓
Operational Practices und Controls
Change Enablement, Service Configuration Management, Information Security Management, Incident und Problem Management, Monitoring and Event Management, Knowledge Management, Supplier Management und Continual Improvement setzen die Anforderungen im täglichen Betrieb um.
↓
AI Agents und AI-enabled Services
Hier wirken die Controls tatsächlich: bei Datenzugriffen, Entscheidungen, Modelländerungen, Tool-Aufrufen, Incidents, Human Approvals und autonomen Aktionen.

Die Richtung darf nicht nur von oben nach unten verstanden werden. Ein AI Incident kann einen neuen Risk Treatment auslösen. Häufige Human Overrides können zeigen, dass ein Autonomie-Level falsch gewählt wurde. Ein Provider Change kann eine Neubewertung des Risikos erforderlich machen. Ein Audit Finding kann Änderungen am Service Design oder an Guardrails auslösen. Governance funktioniert als Rückkopplung:

Policy → Service Design → Operation → Evidence → Improvement

Genau diese Verbindung verhindert, dass ISO/IEC 42001 zu einem Dokumentationssystem und Service Management zu einer rein operativen Disziplin wird.

Vom Nebeneinander zum integrierten Managementsystem

Für Organisationen mit etabliertem SMS und ISMS geht die Integration einen Schritt weiter. ISO/IEC 20000-1, ISO/IEC 27001 und ISO/IEC 42001 adressieren unterschiedliche Managementgegenstände, nutzen aber viele gemeinsame Mechanismen: Kontext und Stakeholder, Policies und Objectives, Governance und Verantwortlichkeiten, Risk Management, dokumentierte Informationen, Supplier Management, Monitoring, Internal Audit, Management Review und Continual Improvement. Das Ziel sollte deshalb nicht sein SMS + ISMS + AIMS = drei Managementsysteme, sondern IMS = gemeinsame Governance für Service Value + Information Security + Responsible AI.

Dabei dürfen die fachlichen Unterschiede nicht verwischt werden: Ein AI System Impact Assessment bleibt eine spezifische Fähigkeit des AIMS, Security Controls behalten ihre Tiefe, Service Management bleibt für die durchgängige Steuerung des Services verantwortlich. Integration bedeutet nicht Gleichmacherei, sondern dass eine Managemententscheidung nicht dreimal getroffen wird, nur weil sie drei Governance-Dimensionen berührt. Eine neue AI-Funktion kann gleichzeitig ein Service Change sein, ein Informationssicherheitsrisiko erzeugen, einen externen Provider einbeziehen und neue Auswirkungen auf Kunden oder Mitarbeitende haben. Diese Fragen nacheinander durch getrennte Silos zu schicken, schafft kaum zusätzliche Sicherheit.

Ein integriertes Managementsystem führt nicht Normen zusammen. Es führt Managemententscheidungen zusammen.

AI Governance braucht Integration – keine Framework-Sammlung

Eine Einordnung des Gartner Hype Cycle for AI in ITSM 2026 beschreibt eine Verschiebung von generativen Assistenzfunktionen hin zu agentischen Fähigkeiten, bei denen AI zunehmend Workflows orchestriert und Aktionen ausführt – und gleichzeitig Governance, Datenqualität und kontrollierte Autonomie stärker in den Vordergrund rücken. Als Sekundärdarstellung ersetzt sie die Gartner-Originalanalyse nicht; der beschriebene Entwicklungspfad ist für Service Management dennoch relevant.

Quelle: Central IT – Gartner Hype Cycle for AI in ITSM 2026: what’s changing

Je stärker AI selbst handelt, desto weniger funktioniert eine Governance, die auf der Ebene von Policies und Risk Assessments bleibt – und desto weniger sinnvoll ist es, für jeden Standard eine eigene organisatorische Welt zu schaffen. ISO/IEC 42001 beantwortet, wie eine Organisation AI systematisch und verantwortungsvoll steuert. ISO/IEC 20000 beantwortet, wie Services innerhalb eines Service Management Systems geplant, gestaltet, erbracht und verbessert werden. ITIL liefert die Practices und Managementlogik für Value Streams, Produkte, Services und den täglichen Betrieb.

Die Herausforderung besteht nicht darin, möglichst viele Frameworks zu implementieren, sondern ihre Anforderungen so zu integrieren, dass eine Entscheidung über AI nur einmal getroffen, aber dort wirksam wird, wo sie relevant ist. Ein Risk Treatment im AIMS muss sich im Service Design wiederfinden. Eine Autonomiegrenze muss durch Berechtigungen und Guardrails durchgesetzt werden. Eine Supplier-Anforderung gehört in den Vertrag. Eine Monitoring-Anforderung muss im Betrieb messbar sein. Ein Incident muss zurück in Risk und Continual Improvement fliessen. Erst dann entsteht ein Managementsystem, das diesen Namen verdient.

AI Governance braucht keine neue Insel in der Governance-Landschaft. Sie braucht Anschluss an die bestehenden Managementsysteme – und insbesondere an das Service Management.

Die nächste Herausforderung entsteht dort, wo dieser Anschluss gar nicht stattfindet. Denn nicht jede AI wird über ein geregeltes Portfolio, ein Risk Assessment oder einen kontrollierten Service Lifecycle eingeführt. Aus Shadow AI werden zunehmend Shadow Agents.

7. Shadow AI wird zu Shadow Agents

Shadow IT ist kein neues Phänomen: Fachbereiche beschaffen SaaS ohne IT, Entwickler nutzen nicht freigegebene Cloud Services, Mitarbeitende installieren Browser Extensions. Mit generativer AI kam Shadow AI hinzu – ein Vertrag wird in einen öffentlichen AI Service kopiert, proprietärer Source Code durch ein nicht freigegebenes Modell analysiert, interne Dokumente per Browser-Plugin zusammengefasst. Die Governance-Fragen sind bekannt: Welche Daten verlassen die Organisation? Wie werden sie verarbeitet? Werden Eingaben für Training verwendet? Welcher Provider steht dahinter?

Bei Shadow Agents verändert sich die Situation qualitativ. Ein Agent konsumiert nicht nur Informationen. Er kann Credentials besitzen, APIs aufrufen, Daten aus verschiedenen Systemen kombinieren, Workflows auslösen, andere Agents ansprechen und Aktionen durchführen. Aus einem nicht genehmigten Informationskanal wird ein nicht genehmigter Akteur.

Shadow AI gefährdet vor allem die Kontrolle über Informationen. Shadow Agents gefährden zusätzlich die Kontrolle über Aktionen. Deshalb gehört das Thema nicht allein in eine Acceptable-Use-Policy.

Ein Agent ist schnell gebaut – Governance weniger

Shadow Agents brauchen keine exotische Infrastruktur. SaaS-Plattformen bringen eigene Agent-Funktionen mit. Low-Code- und No-Code-Werkzeuge kombinieren AI, Datenquellen und Workflows. Entwickler verbinden Modelle über APIs mit internen Anwendungen. Persönliche Assistants werden um Plugins erweitert. Ein kleiner Automatisierungsversuch bekommt einen API Token – und einige Wochen später erledigt er produktive Aufgaben. Aus Sicht des Benutzers wirkt das harmlos: keine neue Anwendung beschafft, nur eine lizenzierte SaaS-Funktion aktiviert oder ein Workflow um einen AI-Schritt ergänzt. Governance-seitig hat sich trotzdem einiges verändert: Der Agent besitzt möglicherweise eine Non-Human Identity, greift auf mehrere Systeme zu, verarbeitet Informationen mit unterschiedlichen Schutzanforderungen, handelt mit den Rechten eines Service Accounts und entscheidet selbst, wann er welches Tool verwendet.

Die Cloud Security Alliance zeigt in ihrer Untersuchung zum Shadow AI Agent Problem genau diese Entwicklung. Shadow Agents werden besonders häufig in internen Automation- und Scripting-Umgebungen, LLM-Plattformen, SaaS-Anwendungen mit integrierter Automation sowie in von Entwicklern erstellten Workflows entdeckt – ausgerechnet jene Umgebungen, die auf schnelle, dezentrale Innovation ausgelegt sind. Das Problem ist also selten ein rebellischer Fachbereich. Oft ist Shadow Agentic AI das Nebenprodukt einer sehr niedrigen technischen Eintrittsschwelle.

Quelle: Cloud Security Alliance – The Shadow AI Agent Problem in Enterprise Environments

„Wir haben gute Sichtbarkeit“ ist noch keine Assurance

Besonders interessant sind die von der CSA veröffentlichten Zahlen: 68% der befragten Organisationen geben an, eine hohe Sichtbarkeit über ihre AI Agents und autonomen Workflows zu besitzen. Gleichzeitig hatten 82% innerhalb des vergangenen Jahres mindestens einen Agenten oder Workflow entdeckt, von dem Security oder IT nichts wussten. 65% berichteten über einen Security Incident mit AI Agents im gleichen Zeitraum – in allen Fällen mit konkretem Business Impact, am häufigsten durch Data Exposure. Die Zahlen stammen aus einer CSA-/Token-Security-Erhebung und sind wie jede Marktstudie nicht als universelle Häufigkeitswerte zu lesen. Der Widerspruch zwischen wahrgenommener Sichtbarkeit und tatsächlich entdeckten unbekannten Agents ist dennoch bemerkenswert.

Die CSA unterscheidet deshalb zu Recht zwischen Operational Visibility – wir haben ein vernünftiges Bild davon, was in unserer Umgebung läuft – und Assurance-grade Oversight: Wir können mit ausreichender Sicherheit davon ausgehen, dass relevante Agents, genehmigt oder nicht, identifiziert, einem Scope zugeordnet und in die vorgesehenen Kontrollmechanismen eingebunden sind. Ein Inventar mit 95% der Agents kann operativ beeindruckend sein. Der eine unbekannte Agent mit privilegiertem Zugriff auf produktive Systeme bleibt trotzdem das interessantere Audit Finding.

Governance braucht nicht nur Sichtbarkeit. Sie braucht hinreichende Vollständigkeit dort, wo Risiko entsteht.

Ein unbekannter Agent liegt ausserhalb fast aller Controls

Die eigentliche Gefahr eines Shadow Agents ist nicht, dass er auf keiner Liste steht, sondern die Folgewirkungen. Ist der Agent unbekannt, wurde sein Zweck nie definiert, sein Autonomiegrad nie festgelegt, seine Berechtigungen nie gegen den Auftrag geprüft. Es gibt keinen Owner. Monitoring kennt das erwartete Verhalten nicht. Incident Management weiss im Fehlerfall nicht, wer verantwortlich ist. Und wird der Agent nicht mehr benötigt, entfernt kein Lifecycle-Prozess seine Credentials. Mehrere Governance-Mechanismen brechen gleichzeitig weg. Die CSA bringt es auf den Punkt: Exception-based Governance funktioniert nur für bekannte Agents mit definierten Grenzen. Für einen unbekannten Agenten können Approval-, Least-Privilege-, Monitoring- und Lifecycle-Controls gar nicht wirksam werden.

Aus Service-Management-Sicht entsteht eine Kette fehlender Beziehungen:

kein Agent Record → kein eindeutiger Owner → kein definierter Servicekontext → keine genehmigte Authority → keine kontrollierten Permissions → kein verlässliches Monitoring → keine geregelte Decommissioning-Verantwortung

Das ist mehr als ein Asset-Management-Problem. Es ist eine Governance-Lücke über den gesamten Lifecycle.

Shadow Agents verschärfen das Identity-Problem

Ein klassischer Shadow-AI-Use-Case überträgt Daten an einen nicht freigegebenen Service. Ein Shadow Agent kann zusätzlich Credentials besitzen, die ihm Zugriff auf interne Systeme und dort Aktionen erlauben – und diese Credentials müssen nicht für ihn erstellt worden sein. Er kann bestehende OAuth-Berechtigungen verwenden, über einen Service Account handeln, die Berechtigungen eines Benutzers übernehmen oder über angeschlossene Tools indirekt Zugriff auf weitere Systeme erhalten. Damit entsteht eine Frage, die klassische IAM-Kontrollen nicht immer beantworten: Nicht nur: Welche Berechtigungen besitzt diese Identität? Sondern: Wer oder was handelt gerade mit ihnen – und für welchen Auftrag? Der technische Zugriff ist vielleicht legitim: Das Konto existiert, das Token ist gültig, die API akzeptiert den Request. Governance-seitig kann die Aktion trotzdem unautorisiert sein.

Deshalb werden Shadow Agents zunehmend als neue Kategorie von Non-Human-Identity-Risiken diskutiert – als Kombination aus autonomen Aktionen, privilegierten Zugriffen, fehlender zentraler Registrierung und unzureichender Überwachung. Die dort genannten Markt- und Sicherheitszahlen stammen teilweise aus Hersteller- und Forschungsquellen und sind vorsichtig zu interpretieren. Die strukturelle Aussage bleibt: Ein unbekannter Agent ist gleichzeitig ein unbekannter Access Path.

Quelle: iPrompt – The Agents Inside the Walls: Shadow AI Security in 2026

Der Blast Radius ist nicht mehr auf Daten beschränkt

Bei Shadow AI konzentriert sich die Diskussion zu Recht auf Data Leakage. Questa AI beschreibt Shadow AI als erhebliches Data-Governance-Problem und weist darauf hin, dass Verbote allein kaum verhindern, dass Mitarbeitende AI für produktive Aufgaben einsetzen.

Quelle: Questa AI – Shadow AI: The Biggest Data Risk in 2026

Bei Agents kommt Action Risk hinzu. Ein kompromittierter oder fehlgeleiteter Agent kann nicht nur Informationen offenlegen, sondern Tickets verändern, Benutzer anlegen, Dateien verschieben, Nachrichten versenden, Konfigurationen ändern, Code ausführen oder andere Prozesse starten. Besonders unangenehm: Die auslösende Information muss nicht aus einem kompromittierten internen System stammen. Agents verarbeiten Texte, Tickets, Dokumente und E-Mails. Enthalten diese manipulierte Anweisungen, die der Agent nicht von legitimen Instruktionen unterscheiden kann, wird aus einem Informationsproblem eine Aktion. Die Sicherheitsfrage lautet nicht mehr nur „Welche Daten darf die AI sehen?“, sondern zusätzlich „Was darf sie aufgrund dessen, was sie sieht, tun?“

Shadow Agents sind auch ein Service-Management-Problem

Es wäre zu kurz gegriffen, Shadow Agents nur als Cybersecurity-Thema zu behandeln. Ein Agent kann vollständig sicher entwickelt sein und dennoch ausserhalb des Service Management Systems laufen. Dann ist nicht bekannt, welcher Service von ihm abhängt. Seine Verfügbarkeit ist in keinem Service Level berücksichtigt. Änderungen erfolgen ausserhalb von Change Enablement. Seine Knowledge Sources sind nicht Teil des Service Designs. Der Model Provider wurde nie im Supplier Management betrachtet. Er taucht in keiner Impact Analysis auf. Und wenn er ausfällt, stellt die Organisation möglicherweise erstmals fest, dass ein operativer Prozess von einem Agenten abhängt, der offiziell gar nicht existiert. Das ist weniger spektakulär als ein Data Breach, aber organisatorisch nicht weniger relevant.

Ein unbekannter Agent kann zu einer bekannten betrieblichen Abhängigkeit werden, bevor Governance davon erfährt.

Deshalb muss Discovery mit Service Modelling verbunden werden. Einen Agenten nachträglich ins AI Inventory einzutragen, löst nur den ersten Teil des Problems. Danach muss geklärt werden, zu welchem Service er gehört, wer ihn verantwortet, welche Daten und Tools er verwendet, welche Authority er besitzt und welche Controls gelten – der Kreis schliesst sich zu Kapitel 3.

ISO/IEC 42001 verlangt Kontrolle über den AI-Lifecycle

ISO/IEC 42001 ist kein „Shadow Agent Standard“, und man sollte ihm keine Aussagen zuschreiben, die er nicht macht. Sein Managementsystemansatz verlangt jedoch, dass Organisationen ihren AI-Kontext bestimmen, Rollen und Verantwortlichkeiten festlegen, AI-bezogene Risiken behandeln und Lifecycle- und Kontrollmechanismen etablieren. Die europäische Übernahme SIST EN ISO/IEC 42001:2026 übernimmt ISO/IEC 42001:2023 und ordnet Governance, Risk Management, Verantwortlichkeiten und die kontrollierte Nutzung von AI in diesen Managementsystemkontext ein.

Quelle: SIST EN ISO/IEC 42001:2026 – AI Management System Standards Guide

Für Shadow Agents ergibt sich daraus eine einfache Konsequenz: Ein Managementsystem kann nur Risiken steuern, die es in seinen Scope und seine Prozesse bekommt. Eine AI Policy hilft wenig, wenn Agents ausserhalb der vorgesehenen Discovery-, Assessment-, Approval- und Monitoring-Prozesse entstehen. Das ist kein Versagen von ISO/IEC 42001. Es ist ein Versagen seiner Operationalisierung.

Governance muss dort greifen, wo Agents entstehen

Eine zentrale Freigabestelle allein löst das Problem nicht. Die CSA weist darauf hin, dass Shadow Agents gerade in dezentralen Umgebungen entstehen: SaaS, Developer Tooling, interne Automation, LLM-Plattformen und Orchestration Tools. Governance, die auf einen zentralen Architektur- oder Security-Review wartet, sieht viele Agents erst, wenn sie produktiv sind. Sie muss näher an die Entstehungspunkte rücken: Ein neuer autonomer Workflow sollte einen Governance Trigger auslösen – ebenso ein neues Tool, eine zusätzliche Datenquelle oder eine weitergehende Berechtigung für einen bestehenden Agenten. SaaS-Produkte sind nicht nur beim Einkauf zu beurteilen, weil neue AI- und Agent-Funktionen während des Lifecycle entstehen. Developer- und Automation-Plattformen brauchen Mechanismen, mit denen Agents entdeckt und registriert werden.

Governance muss dabei schnell genug sein, dass Umgehung nicht zum bequemeren Prozess wird. Ein sechsseitiges Risk Assessment für jeden Knowledge Assistant ist so wenig hilfreich wie völlige Kontrollfreiheit; auch hier sollte Governance proportional zu Datenzugriff, Kritikalität, Scope und Autonomie sein.

Der sichere Weg muss einfacher sein als der Schattenweg. Sonst gewinnt der Schattenweg.

Discovery allein genügt nicht

Organisationen brauchen eine Fähigkeit, die Asset Discovery, AI Inventory und Service Management verbindet. Ein praktikabler Ablauf:

Discover → Identify → Assign → Assess → Integrate → Monitor → Retire

• Discover: Wo existieren Agents und agentische Workflows – auch ausserhalb der freigegebenen Plattformen?
• Identify: Welche technische oder Non-Human Identity verwendet der Agent?
• Assign: Wer übernimmt die menschliche Accountability?
• Assess: Welche Daten, Systeme, Berechtigungen, Autonomie und möglichen Auswirkungen sind relevant?
• Integrate: Zu welchem Service gehört der Agent und welche bestehenden Governance- und Management Practices müssen ihn erfassen?
• Monitor: Handelt er weiterhin innerhalb seines Scopes?
• Retire: Werden Agent, Tokens, Credentials, Integrationen und Datenzugriffe kontrolliert entfernt?

Das Entscheidende ist Integrate. Ohne diesen Schritt entsteht lediglich ein besser gepflegtes AI Inventory. Das Ziel ist, den Agenten in die normale Governance des Services zu überführen. Genau deshalb ist die Arbeit von ISO/IEC JTC 1/SC 40 – IT Service Management and IT Governance relevant, wo Standards zu AI Governance und Service Management zusammengeführt werden – darunter die erwähnte ISO/IEC TS 20000-19.

Quelle: ISO/IEC JTC 1/SC 40 – IT service management and IT governance

Shadow Agents sind keine Argumente gegen Innovation

Eine mögliche Reaktion wäre, den Einsatz von Agents stark einzuschränken. Das dürfte kaum funktionieren. Schon Shadow IT hat gezeigt, dass Verbote attraktiver Technologien deren Nutzung nicht verhindern. Bei AI ist die Eintrittsschwelle noch geringer; viele Funktionen stecken bereits in Werkzeugen, die Organisationen längst einsetzen. Mitarbeitende verwenden sie nicht, um Governance zu umgehen, sondern weil sie ein Problem schneller lösen. Auch die CSA warnt davor, Innovation abzuschalten: Die Umgebungen, in denen Shadow Agents entstehen, sind dieselben, in denen legitimer Business Value durch Automation und AI entsteht.

Die Antwort lautet nicht: weniger AI. Sie lautet: bessere Sichtbarkeit, klarere Grenzen und ein Governance-Modell, das mit dezentraler Innovation umgehen kann. Eine jährliche Policy Review reicht nicht, ein einmaliges Risk Assessment reicht nicht, und eine Liste freigegebener AI Tools reicht schon gar nicht. Wir müssen wissen, welche Agents existieren, in wessen Auftrag sie handeln, welche Identität sie verwenden, worauf sie zugreifen, welche Entscheidungen sie treffen dürfen und zu welchem Service sie gehören.

Shadow AI war ein Visibility- und Data-Governance-Problem. Shadow Agents machen daraus zusätzlich ein Identity-, Authority-, Lifecycle-, Security- und Service-Management-Problem.

Und spätestens dort verlässt AI Governance den Bereich freiwilliger Best Practice: Wenn AI in relevante Services, Entscheidungen und Geschäftsprozesse eingebettet wird, treffen diese Fragen auf verbindliche regulatorische Anforderungen. Aus guter Governance wird regulatorische Erwartung.

8. Regulierung macht aus Best Practice eine Governance-Anforderung

Bis hierhin könnte man AI Governance als gute Managementpraxis betrachten: wissen, welche AI-Systeme eingesetzt werden, Verantwortlichkeiten definieren, Risiken beurteilen, Daten und Berechtigungen kontrollieren, Änderungen steuern, Agents überwachen. In Europa reicht diese Begründung nicht mehr. Mit dem EU AI Act werden Teile dessen, was wir als Responsible AI, Security by Design oder professionelles Service Management verstanden haben, zu regulatorischen Anforderungen. Parallel konkretisieren ISO/IEC 42001 und die entstehende ISO/IEC TS 20000-19, wie AI in Managementsysteme und Services eingebettet wird.

Die Frage lautet nicht mehr nur „Wie wollen wir AI verantwortungsvoll einsetzen?“, sondern zunehmend „Wie können wir nachweisen, dass wir AI kontrolliert, kompetent und entsprechend ihrer Risiken einsetzen?“ Der Unterschied liegt im Wort nachweisen.

Der AI Act ist seit August 2026 operative Realität

Der Zeitplan hat sich 2026 mehrfach verändert. Seit dem 2. Februar 2025 gelten die Verbote bestimmter AI-Praktiken und die AI-Literacy-Anforderungen nach Artikel 4. Seit August 2025 greifen wesentliche Regelungen für General-Purpose-AI-Modelle. Und seit dem 2. August 2026 gilt der AI Act grundsätzlich. Die im Juli 2026 in Kraft getretene Änderung durch den Digital Omnibus hat diesen Termin nicht verschoben – verschoben wurden wesentliche Anforderungen für bestimmte High-Risk-Systeme: nach Annex III auf den 2. Dezember 2027, für in regulierte Produkte eingebettete Systeme nach Annex I auf den 2. August 2028.

Quelle: DLA Piper – EU AI Act from 2 August 2026: What Applies Now and What Was Postponed

Die Verschiebung einzelner High-Risk-Anforderungen darf nicht als genereller Aufschub verstanden werden. Transparenzanforderungen nach Artikel 50 gelten seit dem 2. August 2026, Prohibited Practices und AI Literacy schon länger, für General Purpose AI gelten eigene Vorgaben. Und Organisationen müssen überhaupt erst wissen, welche AI-Systeme sie einsetzen und welche Rolle sie dabei einnehmen, bevor sie bestimmen können, welche Anforderungen einschlägig sind. Damit bekommt das AI Inventory aus Kapitel 3 eine zweite Bedeutung: Es wird zur Voraussetzung regulatorischer Einordnung.

Ohne Inventar keine Klassifikation – ohne Kontext keine belastbare Compliance

Der AI Act folgt einem risikobasierten Ansatz. Risikoklassifikation setzt aber voraus, dass bekannt ist, welche AI zu welchem Zweck in welchem Kontext eingesetzt wird – genau daran scheitert eine rein technische Inventarisierung. „Wir verwenden ein Large Language Model“ reicht regulatorisch so wenig wie für Service Management. Entscheidend ist die konkrete Verwendung: interne Knowledge Search? Service Desk? Direkte Kundeninteraktion? Vorbereitung von Entscheidungen über Personen? Bestandteil eines regulierten Produkts? Inhalte mit Transparenzpflichten? DLA Piper weist zudem darauf hin, dass Organisationen durch Customizing, Retraining oder Rebranding eines AI-Systems vom Deployer in eine Provider-Rolle wechseln können. Für Service Management ist das hochrelevant: Der regulatorische Status hängt nicht allein vom eingekauften Produkt ab, sondern kann sich verändern, wenn ein Service Team das Produkt anders einsetzt, erweitert oder in einen eigenen Service integriert.

Compliance hängt am Use Case – und der Use Case hängt am Servicekontext. Genau deshalb sollte das AI Inventory nicht neben Service Portfolio und Service Repository geführt werden.

AI Literacy ist bereits eine Governance-Anforderung

Artikel 4 verpflichtet Provider und Deployer seit dem 2. Februar 2025, bei Mitarbeitenden und weiteren in ihrem Auftrag handelnden Personen ein ausreichendes Niveau an AI-Kompetenz sicherzustellen; mit dem 2. August 2026 ist die Durchsetzung konkreter geworden. Die Europäische Kommission betont den kontextbezogenen Charakter: Die erforderliche Kompetenz orientiert sich an Vorwissen, Erfahrung, Nutzungskontext und betroffenen Personen. Das bedeutet gerade nicht, dass jeder denselben zweistündigen AI-Kurs absolviert. Ein Service Desk Agent, der generative AI zur Formulierung einer Antwort nutzt, braucht andere Kompetenzen als ein Service Owner, der über einen autonomen Agent entscheidet; Entwickler ein anderes Verständnis als Internal Audit; ein Risk Owner muss beurteilen können, welche Auswirkungen ein AI-enabled Service haben kann. Die Anforderung ist rollen- und risikobasiert umzusetzen.

Provimedia weist auf einen häufigen Irrtum hin: Der AI Act verlangt kein bestimmtes „AI Certificate“. Die Kommission sieht interne Nachweise über Trainings und andere geeignete Massnahmen als Weg, die Umsetzung nachvollziehbar zu dokumentieren.

Quelle: Provimedia – AI Literacy Art. 4 EU AI Act: Duty, Proof, Training

Damit wird AI Literacy zu mehr als Awareness – für Service Management zu einer Capability-Anforderung. Wer einen AI-enabled Service designt, betreibt, freigibt, überwacht oder auditiert, muss seine Rolle im Zusammenspiel mit AI verstehen: Grenzen des Systems, Risiken, Human Oversight, Eskalationswege und die Bedeutung AI-generierter Entscheidungen. Ein Training über Prompt Engineering allein erfüllt diesen Zweck kaum.

Transparenz muss im Service Design landen

Seit dem 2. August 2026 greifen die Transparenzanforderungen des Artikel 50: Personen müssen darüber informiert werden, dass sie mit einem AI-System interagieren; für bestimmte AI-generierte oder manipulierte Inhalte gelten Kennzeichnungspflichten. DLA Piper betont, dass diese Verpflichtungen keineswegs nur Anbieter von High-Risk-Systemen betreffen. Für Service Management stellt sich damit eine praktische Frage: Wo wird diese Transparenz im Service gestaltet? Bei einem AI-enabled Customer Service gehört sie in das Interaction Design. Bei einem Virtual Agent muss geklärt sein, wann und wie er sich als AI zu erkennen gibt. Bei AI-generierten Inhalten ist die Kennzeichnung festzulegen. Ändert ein Provider seine Funktionalität, sind neue Transparenzanforderungen zu prüfen. Legal kann die Anforderung interpretieren – umsetzen muss sie der Service. Aus einer regulatorischen Norm wird eine Service-Design-Anforderung und aus deren Einhaltung eine Frage von Change, Testing, Monitoring und Assurance.

Shadow AI wird damit auch zum Compliance-Problem

Kapitel 7 hat Shadow AI und Shadow Agents aus Governance-, Security- und Service-Management-Sicht betrachtet. Regulatorisch kommt eine Dimension hinzu: Eine Organisation kann nur solche AI-Systeme klassifizieren, dokumentieren und kontrollieren, von deren Existenz sie weiss. Mitarbeitende nutzen öffentliche AI Services oder Browser Extensions, weil sie Aufgaben schneller erledigen – und Unternehmensinformationen oder personenbezogene Daten gelangen in Umgebungen, die nie durch Governance-Prozesse gelaufen sind. Mit Agents verschärft sich das: Ein unbekannter Agent verarbeitet nicht nur Daten, sondern führt Aktionen aus und berührt neben Datenschutz- und Security- auch AI-spezifische Governance- und Transparenzpflichten.

Was nicht sichtbar ist, kann nicht klassifiziert werden. Was nicht klassifiziert ist, kann kaum nachweisbar compliant gesteuert werden. AI Discovery wird vom technischen Hygiene-Thema zum Bestandteil regulatorischer Governance.

DORA und NIS2 sind keine AI-Regulierungen

DORA und NIS2 werden gerne zusammen mit dem AI Act genannt, was den Eindruck erweckt, sie würden spezifische AI Governance verlangen. Das tun sie nicht. DORA adressiert die digitale operationelle Resilienz im Finanzsektor, NIS2 Cybersecurity Risk Management und Incident Reporting für die erfassten Sektoren. Beide sind technologieoffen. AI wird für sie relevant, wenn sie Bestandteil der erfassten ICT Services, Prozesse, Security Controls oder Lieferketten ist. Ein Agent, der eine kritische ICT-Funktion unterstützt, verschwindet nicht aus der DORA-Perspektive, weil er AI verwendet – seine Abhängigkeiten zu Daten, Cloud Services, Providern und Komponenten gehören in die Resilienzbetrachtung. Setzt eine Organisation AI für Security Detection, Incident Response oder Access Administration ein, bleiben die NIS2-Anforderungen bestehen.

Der AI Act reguliert AI. DORA und NIS2 regulieren bestimmte Risiken und Verantwortlichkeiten, in deren Erfüllung AI zunehmend eine Rolle spielt. Für Governance ist beides relevant – aber nicht dasselbe.

Regulierung verlangt zunehmend Evidenz – der AI Proof Gap

Eine Policy ist noch keine Evidenz dafür, dass Governance funktioniert. Ein AI Governance Framework kann hervorragend formuliert sein – im Audit folgt die nächste Frage: Wie wird das umgesetzt? Wer hat den Use Case genehmigt? Welche Risikoklassifikation? Wer ist accountable? Welche Daten darf der Agent verwenden? Welches Autonomie-Level wurde genehmigt? Wie wurden Mitarbeitende qualifiziert? Welche Modell- oder Provideränderungen fanden statt? Welche Human Overrides und Incidents gab es? Wie wurde auf Abweichungen reagiert? Und lässt sich das belegen?

Genau hier zeigt sich eine erhebliche Lücke zwischen AI-Adoption und Governance-Reife. Grant Thorntons 2026 AI Impact Survey unter 950 Führungskräften zeigt: 78% haben kein hohes Vertrauen, innerhalb von 90 Tagen ein unabhängiges Audit ihrer AI Governance zu bestehen; 46% nennen Governance- und Compliance-Probleme als wesentliche Ursache unzureichender AI-Performance. Bei Agentic AI wird es noch deutlicher: Fast drei Viertel der Organisationen geben Agents bereits Zugriff auf Daten und Prozesse – in Pilotierung, Skalierung oder Produktion. Nur 20% verfügen über einen getesteten Incident-Response-Plan für AI-Fehler. Lediglich 5% erlauben Agents autonome High-Stakes-Entscheidungen ohne Human Review; 60% begrenzen sie auf Automatisierung im moderaten Risikobereich. Technische Integration schreitet schnell voran; die Fähigkeit, im Fehlerfall kontrolliert zu reagieren und zu erklären, was geschehen ist, entwickelt sich langsamer. Grant Thornton nennt diese Differenz den AI Proof Gap.

Quelle: Grant Thornton – 2026 AI Impact Survey Report

Es genügt immer weniger zu sagen, dass AI verantwortungsvoll eingesetzt wird. Organisationen müssen zeigen können, welche Entscheidungen sie getroffen haben, welche Controls daraus entstanden sind und ob diese im Betrieb tatsächlich funktionieren.

Auditability wird zum Designprinzip

Auditability sollte nicht erst entstehen, wenn Internal Audit oder eine Aufsichtsbehörde Informationen verlangt – dann ist es zu spät, Daten zu rekonstruieren. Ein Service muss so gestaltet sein, dass Governance-Evidenz während seines Lifecycle entsteht:

• Inventory und Classification – Welche AI wird wo mit welchem Risikoprofil eingesetzt?
• Ownership – Wer verantwortet Service, AI Capability und Risiken?
• Decision Rights – Welche Aktionen darf ein Agent autonom ausführen?
• Change Evidence – Welche Änderungen an Modell, Prompt, Knowledge, Daten, Tools oder Berechtigungen wurden genehmigt?
• Human Oversight – Wo wurde eine Entscheidung überprüft, bestätigt oder überschrieben?
• Operational Evidence – Welche Aktionen führte der Agent aus, welche Incidents oder Abweichungen traten auf?
• Improvement Evidence – Welche Konsequenzen wurden aus Fehlern, Overrides, Near Misses oder Audit Findings gezogen?

Vieles davon kennen wir aus ISO 27001, ISO 20000, Risk Management und etablierten ITSM Practices. AI Governance muss diese Mechanismen nicht neu erfinden. Sie muss dafür sorgen, dass AI in ihnen vorkommt.

Regulierung sollte nicht zur Compliance-Maschine werden

Es besteht eine reale Gefahr, auf den AI Act mit einem weiteren grossen Compliance-Programm zu reagieren: neue Excel-Register, zusätzliche Freigabeformulare, ein zentrales AI Committee, das jeden Use Case einzeln beurteilt, noch ein jährliches Awareness Training, noch ein Dashboard. Formal sieht das nach Kontrolle aus; operativ bewirkt es das Gegenteil. Wenn Governance langsamer ist als die Technologie, entstehen Umgehungswege. Wenn jede risikoarme AI-Nutzung denselben Approval-Prozess durchläuft wie ein autonomer Agent in einem kritischen Service, wird Governance zum Engpass – und Shadow AI ist keine Überraschung mehr.

Grant Thornton weist auf genau dieses Skalierungsproblem hin: Zentralisierte Review Bodies werden mit wachsender Zahl von Use Cases überlastet. Als Gegenmodell beschreibt die Studie zentral definierte Policies und Risikokriterien, kombiniert mit delegierten Assessments durch qualifizierte Reviewer und einer Prüftiefe, die sich am Risiko orientiert. Das passt zu gutem Service Management: Governance definiert die Leitplanken, der Service Owner kennt den Kontext, Risk und Compliance definieren Kriterien und Eskalationsschwellen, Security definiert technische Mindestanforderungen, qualifizierte Teams entscheiden innerhalb dieser Grenzen – nur bei erhöhtem Risiko erfolgt eine intensivere zentrale Prüfung.

Risk-based Governance ist nicht nur effizienter. Sie ist bei einer grossen Zahl von AI Use Cases wahrscheinlich die einzige skalierbare Form von Governance.

Compliance ist nicht das Ziel

Der AI Act erhöht den Druck, AI Governance ernst zu nehmen – das ist positiv. Trotzdem wäre es ein Fehler, Compliance zum Ziel zu machen. Ein AI-enabled Service kann formal compliant und trotzdem schlecht gesteuert sein. Ein vorgeschriebenes Training garantiert keine kompetente Entscheidung, ein vollständiges Inventory keine aktuellen Servicebeziehungen, ein dokumentierter Human-Oversight-Prozess nicht, dass ein Mensch eine Entscheidung tatsächlich beurteilen kann. Compliance definiert einen notwendigen Rahmen. Governance muss darüber hinaus sicherstellen, dass AI im Servicekontext kontrollierbar bleibt. Dort treffen regulatorische Anforderungen auf operative Realität – Services, Owner, Daten, Lieferanten, Changes, Incidents, Controls – und dort entsteht die Evidenz, die für Compliance und Audit benötigt wird.

Der AI Act macht AI Governance verbindlicher. ISO/IEC 42001 macht sie systematischer. Service Management macht sie operativ.

Die Frage ist damit nicht mehr, ob eine Organisation AI Governance braucht, sondern wie sie diese so organisiert, dass sie mit der Zahl der AI Use Cases und Agents skaliert, ohne Innovation in einem neuen Kontrollapparat zu ersticken. Dafür braucht es ein praktikables Operating Model.

9. Ein praktisches AI Governance Operating Model

Nach acht Kapiteln bleibt eine Frage: Wie bringt man all das in eine Form, mit der eine Organisation arbeiten kann? Ein AI Inventory allein reicht nicht, ein AI Board auch nicht. ISO/IEC 42001 schafft den Managementrahmen, löst aber nicht die operative Umsetzung. Service Management verfügt über viele Practices, braucht aber ein Modell, das AI-spezifische Risiken, Autonomie und Controls systematisch integriert. Was fehlt, ist weniger ein weiteres Framework als ein Operating Model für AI Governance: leicht genug, um nicht jeden Use Case in einem Governance-Projekt enden zu lassen; belastbar genug, um bei einem autonomen Agenten mit Zugriff auf kritische Systeme Kontrolle zu ermöglichen; und vor allem skalierbar. Denn genau daran scheitern viele Ansätze – zentralisierte Review Bodies werden zum Bottleneck, ohne das Risiko zu reduzieren (siehe den in Kapitel 8 zitierten AI Proof Gap von Grant Thornton). Die Konsequenz ist nicht weniger Governance, sondern Governance, die näher an den tatsächlichen Entscheidungen arbeitet.

Dafür schlage ich einen Lifecycle mit sechs Schritten vor:

Discover → Classify → Assign → Control → Observe → Improve

Das Modell verbindet AI Governance, Service Management, Risk Management, Security und den AI Lifecycle. Jeder Schritt erzeugt Informationen, die im nächsten benötigt werden.

1. Discover – wissen, wo AI tatsächlich eingesetzt wird

Discover bedeutet nicht, ein Inventory zu öffnen und nachzusehen, was eingetragen ist, sondern AI Capabilities und Agents aktiv zu identifizieren: intern entwickelte Systeme, AI-Funktionen in SaaS-Produkten, externe Model Services, Automatisierungsplattformen, agentische Workflows – und bestehende Anwendungen, die durch ein Provider-Update AI-enabled werden. Der Schritt sollte mindestens beantworten: Was ist die AI Capability? Wo wird sie eingesetzt? Zu welchem Service gehört sie? Welches Modell oder welcher Provider? Welche Daten und Systeme sind betroffen? Ist ein Agent beteiligt, und besitzt er eine eigene oder delegierte Identität? Das Ergebnis ist ein registrierter Use Case oder Agent – nicht als Zeile in einem Register, sondern verbunden mit dem Service, in dessen Kontext er arbeitet (Beziehungskette aus Kapitel 3).

Die Sista-AI-Analyse zum Governance Gap reduziert Agent Governance auf fünf grundlegende Controls: Agent Inventory, definierte Autonomie-Level, Human-in-the-Loop für kritische Aktionen, Audit Logging und ein eindeutig benannter accountable Owner. Die Marktwerte stammen teilweise aus sekundär referenzierten Studien; die Struktur ist dennoch hilfreich. Der erste Schritt bleibt zwingend: Ein unbekannter Agent kann nicht gesteuert werden.

Quelle: Sista AI – The AI Governance Gap: Why Only 21% of Companies Are Ready for Agentic AI

2. Classify – nicht jede AI braucht dieselbe Governance

Hier entscheidet sich, ob Governance proportional oder bürokratisch wird. Ein interner Knowledge Assistant darf nicht wie ein Agent behandelt werden, der Zahlungen auslöst oder kritische Infrastruktur verändert. Mindestens vier Faktoren sind zu beurteilen: Risk (welche Schäden können entstehen?), Criticality (wie wichtig ist der betroffene Service oder Prozess?), Autonomy (wie weit darf die AI ohne menschliche Entscheidung handeln?) und Impact (wie gross kann die Auswirkung einer einzelnen Entscheidung sein?). Dazu kommen Kontextfaktoren: personenbezogene oder besonders schützenswerte Daten, regulatorische Anforderungen, externe Nutzer, finanzielle Konsequenzen, schwer reversible Aktionen.

Die Klassifikation soll keinen mathematischen Scheingenauigkeitsindex erzeugen, sondern eine Entscheidung über die angemessene Governance-Tiefe:

• niedriges Risiko + geringe Autonomie → vereinfachte Registrierung und Basiskontrollen
• mittleres Risiko oder begrenzte operative Autonomie → zusätzliche Risk-, Security- und Service-Management-Controls
• hohes Risiko + hohe Autonomie oder kritischer Service → formales Assessment, stärkere Approval Gates, Monitoring, Reversibility und Management Oversight

Die Autonomie-Level aus Kapitel 4 liefern dafür die Grundlage – ebenso wie die in Kapitel 5 zitierte Gartner-Systematik (Observe, Advise, Act with Approval, Act Autonomously), die höheren Stufen zunehmend stärkere Kontrollmechanismen zuordnet.

Proportional Governance ist der Schlüssel zur Skalierung. Zu wenig Governance erzeugt Risiko. Zu viel Governance erzeugt Shadow AI.

3. Assign – Verantwortung darf nicht im Modell verschwinden

Ein generisches Feld „AI Owner“ genügt häufig nicht. Für einen AI-enabled Service treffen mehrere Verantwortungen zusammen: Service Owner (Service und Outcomes), AI Capability Owner (konkrete AI-Funktion und ihre Weiterentwicklung), Risk Owner (akzeptiert oder behandelt Risiken), Data Owner (Verwendung und Qualität der Daten), Technical Owner (betreibt oder integriert die Capability) und Supplier Owner (steuert externe Provider). Die Rollen dürfen sich überschneiden; entscheidend ist nicht die Zahl der Titel, sondern dass es keine Verantwortlichkeitslücke gibt. Am Ende braucht es eine Person, die beantworten kann: Warum darf dieser Agent in diesem Service auf diese Weise handeln?

Die Cloud Security Alliance beschreibt für die Operationalisierung von ISO/IEC 42001 ein passendes Modell: zentral definierte Accountability und Governance kombiniert mit verteilter Umsetzung – Risk und Compliance definieren Guardrails, Legal interpretiert regulatorische Anforderungen, technische Teams operationalisieren die Controls. Trotz verteilter Ausführung verantwortet eine eindeutig accountable Rolle Entscheidungen und Trade-offs.

Quelle: Cloud Security Alliance – AI Governance and ISO 42001 FAQs

Central Governance – Federated Execution – Named Accountability. Governance muss nicht jede Entscheidung selbst treffen. Aber sie muss definieren, wer sie treffen darf.

4. Control – Governance muss technisch und operativ wirksam werden

Dieser Schritt ist der Übergang von Policy zu Realität. Ein Risk Assessment kann feststellen, dass ein Agent bestimmte Daten nicht sehen darf – wirksam wird das erst durch Zugriffskontrollen. Eine Policy kann Human Approval für kritische Changes verlangen – kontrolliert wird das erst durch einen Workflow oder Policy Enforcement Point. Ein dokumentiertes Autonomie-Level ist nur Dokumentation, wenn der Agent technisch jede API aufrufen darf. Controls müssen aus der Klassifikation abgeleitet und in den Service integriert werden – je nach Risikoprofil:

• Identity und Access Controls – eigene Agent Identity, Least Privilege, Credential Management, zeitlich oder kontextuell begrenzte Berechtigungen
• Human Oversight – Review, Approval Gates, Eskalation oder Intervention abhängig vom Autonomie-Level
• Technical Guardrails – erlaubte Tools, Aktionen, Transaktionslimiten, Datenzugriffe, Output Constraints, API Restrictions
• Change Controls – Freigabe relevanter Änderungen an Modellen, Prompts, Datenquellen, Tools, Berechtigungen oder Autonomie
• Reversibility – Rollback, Circuit Breaker, Kill Switch, Rückstufung auf ein niedrigeres Autonomie-Level
• Auditability – nachvollziehbar dokumentierte Entscheidungen und Aktionen

Die CSA betont bei ISO/IEC 42001 genau diese Verbindung zwischen High-Level Governance und technischen Blueprints – Risk Tiers, Model Cards, MLOps Controls, automatisierte Checks, Deployment Gates – damit Policies ausführbar werden.

Ein Control, das nur in einer Policy existiert, kontrolliert keinen Agenten.

5. Observe – wir müssen sehen, ob Governance funktioniert

Ein häufiges Missverständnis ist, Governance mit der Freigabe abzuschliessen. Agent registriert, Risk Assessment genehmigt, Owner benannt, Controls implementiert – damit beginnt der operative Teil erst. AI-Systeme, Daten, Provider-Modelle, Berechtigungen und Nutzungsformen verändern sich. Governance muss beobachten, ob die Annahmen der Freigabe weiterhin stimmen. Observe umfasst zwei Perspektiven:

• Performance Monitoring – Funktioniert die AI wie vorgesehen? Accuracy, Antwortqualität, Erfolgsrate, Service Impact, Durchlaufzeiten, Benutzerzufriedenheit.
• Governance Monitoring – Handelt die AI innerhalb des genehmigten Rahmens? Ungewöhnliche Tool-Aufrufe, unerwartete Datenzugriffe, steigende Human Overrides, Überschreitung definierter Limits, abweichende Aktionsmuster, Incident-Häufigkeit, Veränderungen nach einem Modell-Update.

Für Agentic AI wird die zweite Perspektive besonders wichtig. Grant Thornton fordert entsprechend den Übergang von statischer Policy zu kontinuierlicher Oversight: Agentenverhalten beobachten, Abweichungen erkennen, Controls anpassen, wenn sich Systeme verändern. Observability wird Teil der Governance.

Nicht nur der Service muss beobachtbar sein. Auch die Wirksamkeit seiner AI Controls.

6. Improve – Governance muss aus dem Betrieb lernen

Discover, Classify, Assign und Control produzieren Annahmen: dass das Risiko angemessen klassifiziert, die Berechtigungen ausreichend begrenzt sind und Human Oversight an den richtigen Stellen greift. Der Betrieb zeigt, ob sie stimmen. Viele Overrides weisen auf ein ungeeignetes Modell oder eine schlechte Knowledge Source hin. Wiederholte Eskalationen zeigen ein falsch gewähltes Autonomie-Level. Ein Security Event stellt die Berechtigungsarchitektur infrage. Ein Provider Change erfordert ein neues Risk Assessment. Und ein Agent, der kaum Nutzen liefert, sollte eingestellt werden – ein Punkt, der bei AI erstaunlich selten diskutiert wird. Grant Thornton beschreibt erfolgreiche Organisationen nicht als jene mit besonders vielen Pilots: Sie skalieren selektiver, messen konsequenter und haben klarere Exit-Kriterien.

Nicht jede AI muss verbessert werden. Manche sollte man abschalten. Continual Improvement braucht deshalb mindestens drei Entscheidungen: Scale (der Use Case funktioniert und wird erweitert), Adjust (Modell, Controls, Autonomie oder Service Design werden angepasst), Stop (Nutzen, Risiko oder Aufwand rechtfertigen den Betrieb nicht). Das verhindert, dass einmal eingeführte Agents Teil der Landschaft bleiben, obwohl niemand mehr prüft, ob sie benötigt werden.

Der Lifecycle ist nicht linear

Die sechs Schritte sehen wie ein Lifecycle aus; in Wirklichkeit sind sie ein Regelkreis. Eine Verbesserung erzeugt einen Change. Ein Change verändert Autonomie oder Risiko. Höhere Autonomie verlangt neue Controls. Ein neuer Provider verändert die Supply Chain. Ein Incident löst eine erneute Klassifikation aus. Das Modell ist keine Projektmethodik, sondern ein Governance Loop – im Einklang mit der adaptiven Sicht des ITIL AI Governance Book, wonach Monitoring, Feedback, Incidents, Near Misses und Audit Findings in Governance und Continual Improvement zurückfliessen müssen. AI Governance wird Teil des normalen Service Lifecycle: nicht einmal jährlich, nicht nur beim Go-live, sondern solange AI Bestandteil des Services ist.

Zentral steuern – dezentral entscheiden

Damit das Operating Model skaliert, muss die organisatorische Architektur stimmen. Ein zentrales AI Governance Board kann Standards, Policies, Risikoklassen, Autonomie-Level und Mindestcontrols definieren, sollte aber nicht jeden Knowledge Assistant einzeln genehmigen müssen. Ein praktikables Modell:

• Zentrale Governance definiert: Policies, Risk Criteria, Autonomy Model, Mandatory Controls, Reporting, Exception Rules und Escalation Thresholds.
• Service- und Product-Organisationen verantworten: Use Case, Business Value, Service Integration, operative Controls und Lifecycle.
• Risk, Security, Privacy und Compliance beraten bzw. genehmigen abhängig vom Risiko: nicht überall gleich intensiv, sondern proportional.
• Internal Audit bzw. Assurance prüft: ob das Modell funktioniert und Evidenz liefert.

Damit entsteht ein föderiertes Governance-Modell – die CSA beschreibt dieselbe Richtung als „federated model with centralized accountability“. Die Alternative wäre kaum skalierbar: Wird jede AI-Entscheidung zentral getroffen, wird Governance zum Flaschenhals; wird jede dezentral getroffen, verschwindet Governance. Federation verbindet Geschwindigkeit mit Konsistenz.

Governance muss selbst messbar werden

Zu einem Operating Model gehören Messgrössen – nicht nur für AI Performance, sondern für Governance Performance:

• Inventory Coverage – welcher Anteil produktiver AI Capabilities und Agents ist registriert?
• Ownership Coverage – wie viele besitzen eindeutig benannte Accountability?
• Control Compliance – sind die für die Risikoklasse vorgeschriebenen Controls umgesetzt?
• Autonomy Exceptions – wo überschreiten Agents den vorgesehenen Handlungsspielraum?
• Human Override Rate – wie häufig korrigieren Menschen AI-Entscheidungen?
• AI Incident Rate – welche AI-bezogenen Incidents und Near Misses treten auf?
• Change Compliance – wie viele relevante Modell-, Prompt-, Data- oder Permission-Changes wurden kontrolliert durchgeführt?
• Evidence Readiness – kann die Organisation kurzfristig belegen, wie ein Agent entschieden und gehandelt hat?

Der letzte Punkt ist der AI Proof Gap in Kennzahlenform. Grant Thornton reduziert ihn auf konkrete Managementfragen: Kann die Organisation zeigen, wo AI autonom handeln darf, wer Outcomes verantwortet, wie Entscheidungen zustande kommen und was passiert, wenn ein System versagt? Governance erhält damit ein eigenes Qualitätskriterium: Nicht nur kontrollieren – beweisen können, dass kontrolliert wird.

Ein Operating Model statt eines neuen Governance-Silos

Der gesamte Ansatz dieses Blogs in einem kompakten Modell:

Discover – Welche AI-Systeme und Agents existieren, und in welchen Services?
↓
Classify – Welche Risiken, Kritikalität, Auswirkungen und Autonomie bestehen?
↓
Assign – Wer trägt Accountability für Service, AI, Daten und Risiken?
↓
Control – Welche Permissions, Guardrails, Approval Gates, Change Controls und Sicherheitsmechanismen sind erforderlich?
↓
Observe – Wie verhalten sich AI und Controls im realen Betrieb?
↓
Improve – Was muss skaliert, angepasst oder beendet werden?

Das Modell schafft keine AI-Insel, sondern verbindet bestehende Fähigkeiten: Portfolio Management liefert Priorisierung, Service Design Kontext, Configuration Management Beziehungen, IAM kontrolliert Identity und Authority, Security schützt Daten und Systeme, Change Enablement steuert Veränderungen, Monitoring erzeugt Transparenz, Incident und Problem Management bearbeiten Fehlverhalten, Continual Improvement schliesst den Regelkreis. ISO/IEC 42001 liefert den Managementrahmen, ITIL und ISO/IEC 20000 den Servicekontext, technische Controls setzen die Vorgaben durch.

Das Ziel bleibt überraschend schlicht: Die Organisation muss jederzeit wissen, welche AI in welchem Service handelt, in wessen Auftrag sie handelt, was sie entscheiden darf, welche Controls gelten und ob diese Controls noch funktionieren. Wer diese fünf Fragen belastbar beantworten kann, ist bei AI Governance weiter als viele umfangreiche Policy-Sammlungen vermuten lassen.

Und es entsteht eine andere Perspektive: Governance wird nicht zum Gegenspieler von Autonomie. Sie schafft die Bedingungen, unter denen mehr Autonomie verantwortbar wird. Je stärker die Governance Capability einer Organisation, desto mehr AI-Autonomie kann sie kontrolliert zulassen.

10. AI Governance darf Innovation nicht verhindern – sie muss Autonomie ermöglichen

„If you don’t lead AI, AI will lead you.“ Dieser Satz aus dem Gartner Data & Analytics Summit 2026 ist zugespitzt, trifft aber den Kern. Eleanor Treharne-Jones fasste eine zentrale Botschaft der Konferenz so zusammen: Die vorsichtige Position gegenüber AI könnte langfristig selbst zum strategischen Risiko werden. AI-first Organisationen investieren nicht nur in Modelle und Tools, sondern gerade in die Grundlagen – Daten, Governance und Menschen.

Die grösste Gefahr besteht nicht darin, AI zu schnell einzusetzen – und ebenso wenig darin, sie möglichst stark zu kontrollieren. Die Herausforderung liegt darin, Autonomie dort zuzulassen, wo eine Organisation sie verantworten kann – und sie dort zu begrenzen, wo diese Fähigkeit fehlt. Genau dafür brauchen wir Governance.

Governance ist kein Gegenspieler von Innovation

Governance hat keinen guten Ruf: Policies, Freigaben, Kontrollgremien, Risk Assessments, Audit Findings. Deshalb entsteht bei AI schnell ein vermeintlicher Zielkonflikt zwischen Innovation, Geschwindigkeit und Experimentierfreude auf der einen und Governance, Compliance und Kontrolle auf der anderen Seite. Diese Gegenüberstellung ist falsch. Schlechte Governance bremst Innovation tatsächlich – wenn jede AI-Nutzung durch ein zentrales Committee muss, jeder Use Case denselben zwanzigseitigen Risk Assessment durchläuft und Verantwortlichkeiten unklar bleiben. Aber fehlende Governance erzeugt das andere Extrem: Shadow AI, unkontrollierte Agents, überprivilegierte Identitäten, unklare Accountability, schlechte Daten, Piloten ohne Business Case, AI-Systeme, die niemand abschalten möchte, weil ein operativer Prozess davon abhängt. Beides verhindert nachhaltige Skalierung.

Governance ist nicht der Preis, den wir für AI bezahlen müssen. Governance ist eine Capability, die bestimmt, wie viel AI wir verantwortbar einsetzen können. Oder einfacher: Governance Capability ↑ → verantwortbare AI Autonomy ↑. Je besser eine Organisation ihre Services, Daten, Verantwortlichkeiten, Risiken, Zugriffsrechte und Controls beherrscht, desto grösser kann der Handlungsspielraum von AI werden.

AI-first bedeutet nicht AI everywhere

Gartner beschreibt die Entwicklung hin zu AI-first Enterprises nicht als Auftrag, jede Entscheidung zu automatisieren. Eine Zusammenfassung der Gartner-Trends für Data & Analytics nennt drei Voraussetzungen: Agents, Governance und eine belastbare Datenbasis. Mit steigender Nutzung autonomer Agents wächst die Bedeutung von Decision Governance – automatisierte Entscheidungen müssen erklärbar, auditierbar und mit den beabsichtigten Outcomes verbunden bleiben.

AI-first bedeutet nicht AI-only. Und schon gar nicht AI-everywhere. Es bedeutet, AI bei der Gestaltung von Produkten, Services, Entscheidungen und Workflows systematisch als Option mitzudenken. Manchmal ist die richtige Lösung ein autonomer Agent, manchmal ein Copilot, manchmal klassische Automation – und manchmal ist die beste Entscheidung, keine AI einzusetzen. Diese Differenzierung ist Governance. Die technologische Möglichkeit, etwas zu automatisieren, ist noch kein Business Case dafür.

Der Hype ist kein Operating Model

Agentic AI befindet sich 2026 weit oben auf der Erwartungskurve. Die in Kapitel 6 zitierte Zusammenfassung des Gartner Hype Cycle for AI in ITSM 2026 nennt 23 AI-Technologien und ordnet Agentic AI, Agentic ITSM und AI Agents im Bereich besonders hoher Erwartungen ein. Die zentrale Botschaft ist dennoch bodenständig: Der Wert von AI hängt wesentlich von Data Quality und der Governance etablierter ITSM Practices ab – nicht vom Versprechen autonomer Automation.

AI kompensiert schwaches Service Management nicht. Sie skaliert es. Eine unvollständige Knowledge Base wird durch einen Agenten nicht vollständiger. Eine schlechte CMDB wird durch AI nicht zum Digital Twin. Unklare Ownership wird nicht besser, weil Entscheidungen schneller getroffen werden. Und ein chaotischer Prozess wird durch autonome Ausführung autonom chaotisch. Die Vorstellung, Agentic AI repariere strukturelle Defizite des Operating Models, dürfte zu kostspieligen Erfahrungen führen.

Gartner kommt bei AI in Infrastructure & Operations bereits zu einer nüchternen Bilanz: In einer Befragung von 782 I&O-Leadern erfüllten nur 28% der AI Use Cases die ROI-Erwartungen vollständig; 20% scheiterten. Als Ursachen wurden Skill Gaps sowie unzureichende Datenqualität oder -verfügbarkeit genannt. Erfolgreiche Initiativen waren stärker in bestehende Workflows und Systeme integriert und hatten häufiger Unterstützung aus Business und Management. Der interessante Punkt ist nicht die Prozentzahl, sondern die Ursache: Die erfolgreichen Organisationen haben AI nicht primär als Technologieprojekt behandelt.

Weniger Piloten. Bessere Piloten.

In vielen Organisationen gilt die Zahl der AI Use Cases als Fortschrittsindikator: 20 Piloten sind gut, 50 besser, 100 klingen nach Transformation. Die interessantere Frage: Welche davon erzeugen tatsächlich einen messbaren Service Value? SolarWinds liefert dazu Zahlen aus dem Service Management. Im 2026 State of ITSM wurden 844 IT Professionals befragt: 84% sagen, AI habe ihre ROI-Erwartungen erfüllt oder übertroffen. Gleichzeitig berichten 52% von einer gestiegenen Gesamtarbeitsbelastung nach der AI-Einführung, und nur 7% sagen, die tatsächlichen Kosten hätten den Erwartungen entsprochen.

Das illustriert die aktuelle Phase fast perfekt. AI beschleunigt einzelne Tätigkeiten – Ticket Triage, Incident Documentation, Knowledge Creation, End-User Responses. Aber eingesparte Minuten sind noch kein Business Outcome, und AI erzeugt neue Arbeit: Outputs müssen überprüft, Knowledge aktuell gehalten, Modelle und Tools gepflegt werden; Datenprobleme treten deutlicher zutage; Ownership wird notwendig. SolarWinds empfiehlt deshalb, AI als operativen Service und nicht als einmalige Implementierung zu behandeln. Genau das ist Service Management. Der Business Case eines AI Agents endet nicht beim Go-live. Er beginnt dort.

Data Quality ist Governance

Wenn AI einen Punkt immer wieder schmerzhaft sichtbar macht, dann die Qualität des organisationalen Kontextes. Unvollständige Daten führen zu unvollständigen Entscheidungen, widersprüchliche Informationen zu widersprüchlichem Verhalten; fehlender Kontext wird nicht durch grössere Modelle ersetzt. Gartner stellt deshalb Semantik und Datenkontext ins Zentrum AI-fähiger Data-&-Analytics-Architekturen: Agents brauchen konsistente Begriffe, Business Logic und Kontext, bevor sie verlässlich Entscheidungen unterstützen oder Aktionen ausführen. Wir diskutieren seit Jahren über schlechte Servicekataloge, inkonsistente CMDB-Daten, fragmentierte Knowledge Bases und unklare Service-Owner-Strukturen. AI macht daraus keine alten Probleme, sondern operative Abhängigkeiten. Ein Agent, der aufgrund falscher Daten eine falsche Empfehlung erstellt, ist ein Qualitätsproblem. Ein Agent, der aufgrund falscher Daten autonom handelt, ist ein Governance-Problem. Der Unterschied liegt in der Konsequenz.

Human in the Loop reicht nicht immer

„Human in the Loop“ ist fast zum universellen Beruhigungssatz geworden: Es gibt einen Menschen, also haben wir Kontrolle. Ganz so einfach ist es nicht. Ein Mensch, der täglich hunderte AI-Entscheidungen bestätigt, übt formal Oversight aus und faktisch kaum noch Kontrolle. Wer nur noch auf „Approve“ klickt, ist im Workflow vorhanden, aber nicht in der Entscheidung. Die entscheidende Frage lautet: Welche Entscheidung muss ein Mensch tatsächlich verstehen, beurteilen oder verantworten können? Bei niedrigen Autonomie-Leveln ist menschliche Freigabe sinnvoll; bei hohen Volumina führt sie zu Automation Bias und Approval Fatigue. Bei autonomen Agents braucht es deshalb ergänzend technische Guardrails, kontinuierliches Monitoring, klar begrenzte Authority, Reversibility und definierte Eskalation. Der Mensch muss nicht jeden Schritt ausführen. Aber er muss die Regeln bestimmen, nach denen AI handeln darf. Das ist der Unterschied zwischen Human in the Loop und Human in the Lead.

AI Literacy ist Teil dieser Führungsfähigkeit

Dazu gehört Kompetenz – und mit Artikel 4 des AI Act (siehe Kapitel 8) ist sie auch eine regulatorische Pflicht. Die praktische Konsequenz wird unterschätzt: Ein Service Owner muss verstehen, welche Auswirkungen ein Agent auf seinen Service hat. Ein Risk Owner muss Risiken beurteilen können. Security muss agentische Zugriffspfade verstehen. Entwickler müssen wissen, wann aus einer technischen Änderung ein governance-relevanter Change wird. Management muss entscheiden können, welches Autonomie-Level es verantworten will. Und Internal Audit muss erkennen, ob ein AI Control wirksam ist. AI Literacy wird Bestandteil organisationaler Readiness.

Eine Organisation kann AI nicht weiter autonomisieren, als ihre Menschen in der Lage sind, diese Autonomie zu verstehen und zu steuern. Auch das ist Governance.

Compliance definiert die Untergrenze – nicht das Zielbild

Mit AI Act, ISO/IEC 42001 und weiteren Anforderungen steigt der formale Druck. Das ist notwendig. Aber Compliance allein erzeugt keine vertrauenswürdigen Services. Eine Organisation kann alle Schulungen dokumentieren und trotzdem schlechte AI-Entscheidungen treffen, ein vollständiges AI Inventory besitzen und nicht wissen, welche Services davon abhängen, Human Oversight definieren und einen Prozess schaffen, in dem Menschen nur noch automatisiert zustimmen – und ein AIMS zertifizieren lassen, während im Service Management niemand weiss, wer einen problematischen Agenten stoppen darf. Compliance schafft einen Mindeststandard. Governance schafft Führungsfähigkeit.

Die Analyse der Kriv AI Foundation bringt die Situation auf den Punkt: AI-Adoption hat die Governance vieler Organisationen überholt. Gleichzeitig zeigen die ausgewerteten Studien, dass Unternehmen mit strukturierter Governance, Auditierung, unabhängiger Validierung und überarbeiteten Workflows eher zu den AI-High-Performern gehören. Der Report ist eine Synthese öffentlicher Studien, keine eigene Erhebung; als Gesamtbild ist er dennoch bemerkenswert.

Quelle: Kriv AI Foundation – State of AI Governance 2026

Governance ist nicht das administrative Ende eines AI-Projekts. Sie gehört an seinen Anfang.

Genau hier kommt Service Management ins Spiel

AI Governance wird häufig aus drei Richtungen diskutiert: Compliance, Data- und AI-Governance, Cybersecurity. Alle drei sind notwendig. Aber sie beantworten nicht vollständig, wie AI als Bestandteil eines digitalen Services gesteuert wird: Wer entscheidet über den Einsatz? Zu welchem Service gehört der Agent? Welche Outcomes unterstützt er? Welche Daten, Knowledge Sources und Tools darf er verwenden? Welche Authority besitzt er? Welche Änderungen sind zu kontrollieren? Wie erkennen wir Fehlverhalten? Wer reagiert bei einem Incident? Wie wird aus Betriebserfahrung Verbesserung? Das sind klassische Fragen des Service Managements – erweitert um einen neuen Akteur. Genau deshalb ist die Entwicklung von ISO/IEC AWI TS 20000-19 (Kapitel 4) mehr als ein weiteres Dokument im ISO-Katalog. Sie bestätigt: AI Governance und Service Management wachsen zusammen.

Service Management muss sich dabei selbst verändern

Das bedeutet nicht, einen AI-Abschnitt in bestehende Prozessbeschreibungen zu schreiben. Configuration Management muss neben klassischen CIs auch AI Capabilities, Modelle, Agents, Knowledge Sources und ihre Abhängigkeiten abbilden. Change Enablement muss verstehen, dass ein neues Modell, eine veränderte Prompt-Konfiguration oder eine zusätzliche Agent Permission das Verhalten eines Services verändert. Incident Management muss AI-bedingte Fehler erkennen und eskalieren. Supplier Management muss berücksichtigen, wie externe Model- und AI-Service-Provider in Entscheidungen und Outcomes eingreifen. Monitoring muss neben Availability und Performance auch Verhalten, Drift, Overrides und Autonomiegrenzen beobachten. Continual Improvement muss Human Corrections, Incidents und Agent Behaviour als Lernsignale verarbeiten. Vor allem aber muss Service Management wieder stärker das tun, wofür es gedacht ist: nicht Prozesse verwalten, sondern Services beherrschbar machen. AI macht diese Aufgabe wichtiger, nicht weniger wichtig.

Von Service Automation zu kontrollierter Service Autonomy

Automation bedeutet klassisch: Ein definierter Prozess wird ohne menschliche Ausführung durchgeführt. Agentic AI geht weiter: Ein Agent entscheidet innerhalb vorgegebener Grenzen selbst, welchen Weg er zum Outcome nimmt. Das ist keine reine Automation mehr, sondern Service Autonomy. Und genau dort entscheidet sich, wie leistungsfähig Governance ist. Eine Organisation mit unreifen Daten, unklarer Ownership und schwachen Controls wird autonome AI stark begrenzen müssen. Eine Organisation mit belastbarem Service Model, klaren Decision Rights, kontrollierten Identitäten, hoher Data Quality, Monitoring und funktionierenden Governance Loops kann mehr Autonomie zulassen – nicht weil sie risikofreudiger ist, sondern weil sie das Risiko besser beherrscht.

Governance muss den Raum für Autonomie definieren

Früher fragte Governance: Dürfen wir das? Bei AI sollte sie zusätzlich fragen: Unter welchen Bedingungen dürfen wir das autonom tun lassen? Diese Bedingungen müssen konkret sein: Welcher Zweck? Welche Daten? Welche Systeme? Welche Entscheidungen? Welche Limiten? Welche Eskalationen? Welche Kontrollmechanismen? Welche Evidence? Und wer trägt am Ende die Verantwortung? Je klarer diese Fragen beantwortet sind, desto weniger muss Governance im Einzelfall eingreifen. Gute Governance kontrolliert nicht jede Bewegung. Sie definiert den Raum, in dem Bewegung sicher möglich ist.

Der Mensch bleibt accountable

AI übernimmt Aufgaben, bereitet Entscheidungen vor, trifft bestimmte Entscheidungen und orchestriert zunehmend komplexe Aktionen über mehrere Systeme. Aber eine Organisation kann ihre Accountability nicht an ein Modell delegieren. Wenn ein Agent Schaden verursacht, wird die Antwort gegenüber Kunden, Mitarbeitenden, Aufsichtsbehörden oder Verwaltungsrat kaum lauten können: „Der Agent hat das entschieden.“ Governance bedeutet nicht, den Menschen überall operativ im Prozess zu behalten. Sie bedeutet, menschliche Verantwortung auch dort eindeutig zu erhalten, wo menschliche Ausführung verschwindet. Das ist eine der wichtigsten Aufgaben für das kommende Service Management.

AI Governance ist eine Readiness-Frage

Am Ende ist AI Governance weniger eine Frage nach dem richtigen Framework. ISO/IEC 42001 hilft, ITIL hilft, ISO/IEC 20000 hilft, der AI Act setzt verbindliche Grenzen, Security Frameworks liefern Controls. Keines davon ersetzt die organisatorische Fähigkeit, daraus ein funktionierendes Betriebsmodell zu bauen. Die entscheidenden Fragen sind einfacher: Kennen wir unsere AI Capabilities und Agents? Kennen wir ihren Servicekontext? Sind Verantwortlichkeiten klar? Sind Daten und Knowledge vertrauenswürdig? Sind Decision Rights und Autonomie definiert? Können wir Verhalten überwachen? Können wir eingreifen? Können wir nachweisen, was passiert ist? Und lernen wir daraus?

Genau darum ging es in diesem Blog: nicht um die nächste Governance-Disziplin, sondern um die Fähigkeit, AI zunehmend in unsere Services zu integrieren, ohne Kontrolle, Verantwortung und Vertrauen aufzugeben.

Von Human in the Loop zu Human in the Lead

„If you don’t lead AI, AI will lead you.“ Der Satz ist keine Warnung vor AI, sondern vor fehlender Führung. AI wird leistungsfähiger, Agents übernehmen mehr Aufgaben, Autonomie nimmt zu. Die Frage ist nicht, ob wir diese Entwicklung vollständig kontrollieren können, sondern ob unsere Organisationen schnell genug lernen, sie zu führen. Dazu brauchen sie weniger zusätzliche Bürokratie als klare Ownership, gute Daten, transparente Services, proportionale Controls, kompetente Menschen und ein Operating Model, das aus Erfahrung lernt. Kurz: Discover → Classify → Assign → Control → Observe → Improve.

Dann wird Governance nicht zum Bremsklotz der nächsten Generation digitaler Services. Sie wird zu ihrer Voraussetzung.

Gute Governance begrenzt AI nicht. Sie definiert den Raum, in dem AI sicher und zunehmend autonom handeln darf.

Und genau darin liegt vielleicht die wichtigste Aufgabe von Service Management im Zeitalter von AI: Nicht den Menschen aus dem Loop zu nehmen – sondern dafür zu sorgen, dass der Mensch in der Führung bleibt.