Ihre AI Agents brauchen ebenfalls Identity Governance: Was sich mit dem EU AI Act 2026 wirklich ändert

Jede Diskussion über AI-Regulierung dreht sich um Modelle und Daten. Aber Aufsichtsbehörden fokussieren sich zunehmend auf etwas Grundsätzlicheres: wer diese Modelle ausführt, Workflows anstößt und auf regulierte Daten zugreift - einschließlich Ihrer AI Agents.

Ab August 2026 ist es nicht mehr nur technischer Schuldenaufbau, AI Agents wie anonyme Scripts oder "nur Automatisierung" zu behandeln - es wird zum regulatorischen Risiko. Dieser Artikel erklärt, was der EU AI Act und kommende Rahmenwerke tatsächlich für nicht-menschliche Identitäten verlangen, warum reine SSO-Ansätze scheitern und wie sich Identity Governance anpassen muss.

Der Enforcement-Moment 2026: AI wechselt vom Experiment zur regulierten Infrastruktur

Der EU AI Act ist von der Präsentation in die Realität gewechselt: Er ist jetzt Gesetz - mit gestufter Einführung.

Der AI Act ist am 1. August 2024 in Kraft getreten, die meisten Vorschriften gelten ab dem 2. August 2026.

Für die meisten Unternehmen sind insbesondere relevant:

• 2. August 2026 - Pflichten für Hochrisiko-AI-Systeme in Anhang III (Beschäftigung, Kreditvergabe, kritische Dienste usw.) greifen
• Verstöße können zu Bußgeldern von bis zu 35 Mio. € oder 7 % des weltweiten Jahresumsatzes führen

Und die Aufsichtsbehörden bleiben nicht dabei stehen:

• NIS2: Die Mitgliedstaaten müssen die Cybersicherheitsvorschriften bis 17. Oktober 2024 umsetzen; Sanktionen für wesentliche Einrichtungen können 10 Mio. € oder 2 % des weltweiten Umsatzes erreichen
• DORA (Verordnung (EU) 2022/2554): gilt ab dem 17. Januar 2025; verlangt Event-Logging für Zugriffskontrolle und Identity Management in Finanzunternehmen
• HIPAA Security Rule: schreibt eindeutige User-IDs, Zugriffskontrollen und Audit-Trails für Systeme vor, die elektronische besonders schützenswerte Gesundheitsdaten verarbeiten

Unterschiedliche Akronyme, gleicher Grundsatz: Aufsichtsbehörden erwarten Nachweise, wer (oder was) wann unter welcher Policy worauf zugegriffen hat. Das schließt AI Agents, Bots, Service-Accounts - jede beteiligte nicht-menschliche Identität - ausdrücklich ein.

AI-Regulierung definiert "Identität" stillschweigend neu

Viele definieren Identität immer noch als Menschen, die sich einloggen. Regulierer tun das nicht.

Der AI Act adressiert Provider und Operatoren von AI, Risikomanagement und Logging. NIS2 und DORA treiben Identity Management, Zugriffskontrollen und manipulationssichere Logs. HIPAA und CMMC fokussieren auf eindeutige IDs und prüfbare Zugriffe für jedes System, das mit geschützten Daten arbeitet.

Ob eine Aktion ausgeführt wurde von:

• einem Menschen via SSO,
• einer headless Automation mit einem API-Token oder
• einem AI Agent, der quer durch Jira, GitHub, Slack oder Ihr KIS/EMR agiert,

ist für Regulierer unerheblich. All das sind Identitäten:

• Sie greifen auf sensible Daten zu
• Sie können Systemzustände verändern
• Sie können Sicherheitsvorfälle auslösen

"Non-human identity" ist kein Nischenthema im IAM mehr - es ist ein Compliance-Objekt:

• AI Agents, die im Auftrag von Usern handeln
• LLM-Copilots mit Tokens
• RPA-Bots, Integrations-User in SaaS
• Service-Accounts im MLOps-Stack

Wenn Sie die Frage "Welche AI Agents existieren, was dürfen sie, wem gehören sie?" nicht beantworten können, haben Sie eine Lücke in Ihrer Identity Governance - nicht nur in Ihrer AI Governance.

Warum SSO-only und manuelle Kontrollen bei AI Agents versagen

Die meisten schnell wachsenden Unternehmen stützen sich auf:

• SSO für 20 % der leicht integrierbaren Apps
• Manuelles Provisioning für die anderen 80 %
• Ad-hoc-Skripte und API-Keys für Bots und Agents

Für menschliche Logins reicht das oft aus. Es bricht in dem Moment zusammen, in dem Auditoren die Aktionen eines AI Agent end-to-end nachverfolgen wollen.

Die strukturellen Lücken

1. Keine First-Class-Identity für Agents
   Agents laufen häufig unter:

   • geteilten "Automation"-Accounts
   • langlebigen, breit berechtigten Tokens
   • lokalen Service-Accounts außerhalb von SSO

2. Keine fein granulare Sicht auf Agent-Zugriffe
   Selbst wenn Sie die App kennen, fehlt meist das Tracking:

   • welche Repos der Agent in GitHub anfasst
   • welche Slack-Channels er liest
   • welche Patienten- oder Finanzakten er abfragt

3. Kein durchgängiger Nachweis-Trail
   Logs sind:

   • über viele Apps verstreut
   • nie zu einer nicht-menschlichen Identität zusammengeführt
   • nicht gemeinsam mit menschlichen Zugriffen reviewbar

4. Abnick-Reviews statt echter Entscheidungen
   Access Reviews für Menschen geraten bereits oft zur "Spreadsheet-Show". Bei Agents genehmigen Manager Identitäten, die sie nicht einmal zuordnen können.

Reine Human-IGA auf AI-getriebene Identity-Sprawl anzuwenden, ist wie mit einem Messer zu einer Schießerei zu erscheinen. Sie erfüllen vielleicht Formalien - aber Sie steuern das Risiko nicht.

Was Aufsichtsbehörden Sie tatsächlich nachweisen lassen (für AI Agents)

Wer den AI Act und seine Pendants liest, erkennt drei wiederkehrende Themen: Nachvollziehbarkeit, Verantwortlichkeit, Verhältnismäßigkeit.

1. Nachvollziehbarkeit

Hochrisiko-AI unter dem AI Act verlangt Logs, technische Dokumentation und Post-Market-Monitoring - also Nachweise über das tatsächliche Systemverhalten.

Für AI Agents heißt das:

• Jede Aktion eines Agent in einer SaaS-App ist verknüpft mit:
  • einer eindeutigen nicht-menschlichen Identität
  • der Policy, die seine Berechtigung gewährt
  • einem verantwortlichen menschlichen Owner

Wenn Sie aus unveränderlichen Logs nicht rekonstruieren können: "Dieser Agent hat einen Fall geschlossen, diesen Datensatz geändert, diese Zahlung ausgelöst", sind Sie unter AI Act, DORA oder HIPAA exponiert.

2. Verantwortlichkeit

NIS2 und DORA machen Boards und Management explizit für ICT-Risiken und Identity Governance verantwortlich.

Für nicht-menschliche Identitäten heißt das:

• Jeder Agent braucht einen Owner (Team oder Rolle) - nicht nur einen technischen Maintainer
• Beim Decommissioning müssen Agent-Tokens, Service-Accounts und App-Berechtigungen entzogen werden - nicht nur ein User offgeboardet

3. Verhältnismäßigkeit (Least Privilege in der Praxis)

Der AI Act ist risikobasiert. HIPAA, DORA und CMMC nutzen eigene Begriffe - alle laufen auf Least Privilege, Funktionstrennung und strengere Kontrollen für kritische Systeme hinaus.

Für Agents bedeutet Verhältnismäßigkeit:

• enge API-Scopes (z. B. read-only)
• zeitlich befristete, just-in-time Elevation für sensible Aktionen
• explizite Trennung von "vorschlagen" vs. "ausführen"

SSO-only, manuell und vollständige IGA: Wie sie bei AI Agents abschneiden

Viele gehen davon aus: "Wir haben SSO und Logs - also passt das schon." So steht das im Vergleich zu den Anforderungen 2026:

Kurz gesagt: Wenn Ihre Governance nur Menschen in SCIM-kompatiblen Apps abdeckt, liegen Sie quer zu der Art von Risiko, auf die Regulierer inzwischen zielen.

Identity Governance für AI Agents aufbauen, die 2026er Audits besteht

Sie brauchen keinen "maßgeschneiderten AI-Compliance-Stack". Sie brauchen vollständige Identity Governance, die AI Agents als First-Class Citizens behandelt.

Darauf kommt es an.

1. Ein zentrales Inventar aller Identitäten schaffen

Für jeden AI Agent, Bot oder Service-Account sollten Sie dokumentieren:

• Zweck (welches Problem er löst, fachlicher Owner)
• Daten-Domains (welche Systeme/Daten er berührt)
• technischer Footprint (SaaS/On-Prem/Cloud-Accounts, Keys, Credentials)
• Compliance-Auswirkung (HIPAA, PCI, kritische Infrastruktur, Kundendaten usw.)

Spreadsheets stoßen an ihre Grenzen, sobald Sie mehr als eine Handvoll Agents betreiben.

2. Ownership und Verantwortlichkeit zuweisen

Jeder AI Agent braucht beides:

• einen Business Owner (Director/Manager) für Zweck und Einsatz
• einen Technical Owner (Team) für Betrieb und Wartung
• klare Onboarding/Offboarding-Regeln - verlässt der Owner das Unternehmen, wird der Agent überprüft oder stillgelegt

Das ist die Antwort auf: "Wer hat den Zugriff dieses Agent genehmigt?"

3. Least Privilege fein granular durchsetzen

Least Privilege für AI Agents bedeutet konkret:

• Welche Projekte/Repos/Queues sind erreichbar?
• Darf der Agent Produktivdaten verändern oder nur Vorschläge machen?
• Ist Schreibzugriff zeitlich begrenzt und an bestimmte Workflows gebunden?

Iden bringt Governance bis auf Ressourcenebene - Channels, Repos, Projekte - statt nur auf Gruppen- oder Rollenebene.

Diese Detailtiefe ist entscheidend, wenn Auditoren fragen, warum ein AI-Incident-Response-Agent in sensiblen Systemen nur lesen, aber nicht schreiben darf.

4. Lifecycle automatisieren: Joiner, Mover, Leaver - auch für Agents

Joiner/Mover/Leaver-Flows gelten gleichermaßen für AI Agents.

Das bedeutet:

• Creation - Agents werden Policy-gesteuert provisioniert, nicht via Skript-Bastelei
• Change - Scope-Erweiterungen erfordern Begründung und Freigabe
• Retirement - ausgemusterte Agents verlieren überall Zugriff/Tokens/Accounts, nicht nur in ein paar Apps

Iden bringt Lifecycle-Automatisierung für menschliche und nicht-menschliche Identitäten in alle Apps - auch ohne SCIM oder APIs.

5. Access Reviews von Spreadsheets zu echten Echtzeit-Entscheidungen machen

Access Reviews für Agents dürfen kein jährlicher Kraftakt sein. Sie müssen:

• kontinuierlich sein (ausgelöst durch Änderungen - Risiko, Nutzung, Ownership)
• kontextualisiert sein (angereichert mit tatsächlicher Agent-Aktivität)
• umsetzbar sein (mit einem Klick Rechte über Systeme hinweg entziehen oder anpassen)

Agentic Workflows (AI-gesteuerte, autonome Workflows) ermöglichen es der Plattform, riskante Muster (z. B. inaktive Agents mit überzogenen Rechten) zu erkennen und präzise Korrekturen vorzuschlagen.

Wie vollständige Identity-Governance-Plattformen die Non-Human-Lücke schließen

Stellen Sie keine zusätzlichen AI-Spezialtools auf ein fragmentiertes Identity-Fundament. Beheben Sie den Kern: Steuern Sie jede Identität - menschlich und maschinell - in jeder App.

Iden ist genau für dieses Fundament gebaut.

Iden automatisiert Provisioning über 175+ Anwendungen und verwaltet menschliche und nicht-menschliche Identitäten - einschließlich AI Agents und Service-Accounts - in einer einzigen Plattform.

Zentrale Fähigkeiten für AI-Agent-Governance:

• Universelle Abdeckung ohne SCIM-Aufschlag
  • Integration mit SCIM-, API- und Non-API-Apps - inklusive der Long-Tail-Tools, in denen sich Agents gerne verstecken
  • Unterstützung im Standard-Tarif - keine erzwungenen Enterprise-Upgrades nur für Agent-Automation
• Vereinheitlichte Identitätssicht für Menschen und Maschinen
  • Ein Dashboard: Mitarbeitende, externe Kräfte, AI Agents, Service-Accounts
• Fein granulare Kontrollen gemäß regulatorischen Anforderungen
  • Channel-, Repo-, Projekt-Level-Entitlements, damit Least Privilege tatsächlich Realität wird
• Unveränderliche Audit-Logs, kontinuierliche Governance
  • Bankentaugliche Verschlüsselung und unveränderliche Trails liefern Echtzeit-Nachweise für Regulierer
• Agentic Workflows für Compliance
  • AI-gesteuerte, autonome Workflows führen Identitäten zusammen, markieren Anomalien und setzen Policies automatisch durch

Stapeln Sie keine Parallel-Stacks nur für AI - erweitern Sie Ihre Identity Governance so, dass sie diese neue Spezies von Identitäten mit derselben Automatisierung und Strenge abdeckt, die menschliche User schon immer gebraucht haben.

Konkrete nächste Schritte vor August 2026

IT-Leitung, CISOs, Compliance-Verantwortliche - pragmatische nächste Schritte für schlanke Teams:

Innerhalb von 30 Tagen:

• Inventarisieren Sie AI Agents, Bots und Service-Accounts in kritischen Systemen
• Markieren Sie diejenigen, die mit folgenden Daten arbeiten:
  • EU-Bürgern (AI Act, NIS2)
  • Finanzdienstleistungen (DORA, CMMC)
  • Gesundheitsdaten (HIPAA)
• Identifizieren Sie Agents, die SSO umgehen (API-Keys, App-lokale Accounts)

Innerhalb von 90 Tagen:

• Weisen Sie für jede nicht-menschliche Identität fachliche und technische Ownership zu
• Pilotieren Sie fein granulare, Policy-gesteuerte Zugriffe für ausgewählte Agents in 3-5 Schlüssel-Apps
• Etablieren Sie zentrale, unveränderliche Audit-Logs für Agent-Aktivitäten

Vor dem 2. August 2026:

• Führen Sie vollständige Identity Governance über Ihren SaaS-Stack ein - inklusive Non-SCIM-/Non-API-Apps
• Automatisieren Sie Joiner/Mover/Leaver-Flows und Access Reviews für alle Identitäten
• Mappen Sie Kontrollen auf AI Act, NIS2, DORA, HIPAA, SOC 2, CMMC - seien Sie bereit, zu zeigen, statt nur zu versprechen

Wenn Sie AI Agents als vollwertige Identitäten behandeln, bestehen Sie nicht nur schneller Audits - Sie arbeiten auch agiler als Wettbewerber, die noch Skripte, Tickets und Hoffnungen zusammenstöpseln.

Häufig gestellte Fragen

Wie wirkt sich der EU AI Act konkret auf unsere internen AI Agents aus?

Wenn Ihre Agents Hochrisiko-AI-Systeme nach Anhang III betreiben - Beschäftigung, Kreditvergabe, kritische Dienste - gelten die Anforderungen des AI Act zu Risikomanagement, Logging, Dokumentation und Aufsicht für Ihr gesamtes System, nicht nur für externe Provider. Sie müssen klar nachweisen können, welche Agents existieren, welche Zugriffe sie haben und wie Governance und Logging geregelt sind.

Brauchen wir wirklich Identity Governance für nicht-menschliche Identitäten oder reicht klassisches IAM?

Klassisches IAM/SSO löst Authentifizierung und Gruppensteuerung für menschliche User in einem Teil Ihres App-Stacks. Sobald AI Agents, Bots und Service-Accounts über SaaS hinweg agieren - oft ohne SCIM oder nutzbare APIs - brauchen Sie vollständige Identity Governance:

• Inventar aller nicht-menschlichen Identitäten
• Steuerung von Entitlements auf granularer Ebene
• automatisierte Lifecycle- und Access-Reviews - stackweit

Andernfalls können Sie die auditfesten Nachweise, die Regulierer erwarten, nicht erbringen.

Wie greifen NIS2 und DORA beim Thema AI Agents in den EU AI Act ein?

NIS2 und DORA sprechen nicht ausdrücklich von "AI Agents" - sie verlangen Identity Management, Zugriffskontrolle und Logging überall dort, wo kritische Funktionen unterstützt werden. Kann ein Agent Handel, Zahlungen oder Incident Response beeinflussen, ist er im Scope. Der AI Act legt anschließend AI-spezifische Anforderungen oben drauf - und setzt voraus, dass ein belastbares Identity-Fundament bereits existiert.

Wir sind ein schlankes IT-Team. Ist es realistisch, das alles bis 2026 zu schaffen?

Wenn Sie versuchen, alles manuell und per App-Konfiguration zu lösen, ist es unrealistisch. Genau hier liefern Automation-first-IGA-Plattformen wie Iden ihren Mehrwert: Plug-and-Play-Connectors, Onboarding ohne Engineering-Aufwand, Policy-gesteuerte Workflows über den gesamten Stack.

Starten Sie mit Ihren Hochrisiko-Apps/-Agents: Sie sehen schnell Effekte - weniger Tickets, saubereres Offboarding, bessere Audit-Position - ohne ein eigenes IAM-Team aufbauen zu müssen.

Geht es hier um AI Governance oder Identity Governance?

Um beides. Aber AI Governance ohne Identity Governance ist Theater. Sie können exzellente AI-Policies und Register haben - wenn:

• Sie nicht wissen, welche Agents welche Aktionen ausführen können und
• Sie Zugriffe nicht schnell genug verkleinern oder entziehen können,

dann vertrauen Sie nur - Sie steuern nicht.

Behandeln Sie AI Agents als neue Identitätsspezies. Govern Sie sie kontinuierlich und automatisiert - genau wie Ihre Mitarbeitenden. So machen Sie aus 2026 keinen Compliance-Notfall, sondern einen Wettbewerbsvorteil.