Auch Ihre KI-Agenten brauchen Identity Governance: Was sich mit dem EU AI Act 2026 wirklich ändert

Jede Diskussion über KI-Regulierung dreht sich um Modelle und Daten. Doch Aufsichtsbehörden richten den Blick zunehmend auf etwas Grundsätzlicheres: wer diese Modelle betreibt, Workflows auslöst und auf regulierte Daten zugreift - einschließlich Ihrer KI-Agenten.

Ab August 2026 ist es nicht mehr nur technischer Schuldenaufbau, KI-Agenten als anonyme Skripte oder "bloße Automatisierung" zu behandeln - es wird zum aufsichtsrechtlichen Risiko. Dieser Beitrag erklärt, was der EU AI Act und kommende Regelwerke tatsächlich für nicht-menschliche Identitäten verlangen, warum SSO-Ansätze allein scheitern und wie Identity Governance sich anpassen muss.

Der Durchsetzungszeitpunkt 2026: KI wandert von Experimenten in regulierte Infrastruktur

Der EU AI Act ist von der Präsentationsfolie in die Realität gewandert: Er ist Gesetz - mit gestaffelter Einführung.

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

Für die meisten Unternehmen sind insbesondere folgende Daten relevant:

• 2. August 2026 - die Pflichten für Hochrisiko-KI-Systeme nach Anhang III (Beschäftigung, Kreditvergabe, kritische Dienste usw.) greifen
• Verstöße können zu Geldbußen von bis zu 35 Millionen Euro oder 7 % des weltweiten Jahresumsatzes führen

Und die Regulierer bleiben nicht dabei stehen:

• NIS2: Die Mitgliedstaaten müssen die Cybersicherheitsvorgaben bis zum 17. Oktober 2024 in nationales Recht umsetzen; für wesentliche Einrichtungen drohen Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Umsatzes
• DORA (Verordnung (EU) 2022/2554): gilt ab dem 17. Januar 2025; verlangt u. a. Ereignisprotokollierung für Zugriffssteuerung und Identitätsverwaltung bei Finanzunternehmen
• HIPAA Security Rule: schreibt für Systeme mit elektronischen geschützten Gesundheitsinformationen eindeutige Benutzerkennungen, Zugriffskontrollen und Prüfprotokolle vor

Unterschiedliche Abkürzungen, derselbe Grundsatz: Aufsichtsbehörden erwarten Nachweise, wer (oder was) worauf, wann und unter welcher Richtlinie zugegriffen hat. Das umfasst KI-Agenten, Bots, Servicekonten - jede nicht-menschliche Identität, die beteiligt ist.

KI-Regulierungen definieren "Identität" leise neu

Viele verstehen Identität noch als Menschen, die sich einloggen. Regulierer nicht.

Der AI Act adressiert Anbieter und Betreiber von KI, Risikomanagement und Protokollierung. NIS2 und DORA treiben Identitätsverwaltung, Zugriffskontrollen und manipulationssichere Protokolle voran. HIPAA und CMMC fokussieren auf eindeutige Kennungen und prüfbare Zugriffe für jedes System, das mit geschützten Daten arbeitet.

Es spielt keine Rolle, ob eine Aktion ausgelöst wurde durch:

• Einen Menschen mit SSO
• Eine kopflose Automatisierung mit einem API-Token
• Einen KI-Agenten, der über Jira, GitHub, Slack oder Ihr KIS agiert

Für die Aufsicht sind das alles Identitäten:

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

"Nicht-menschliche Identität" ist kein Spezialthema der IAM-Abteilung mehr - sie ist ein eigener Compliance-Gegenstand:

• KI-Agenten, die im Auftrag von Nutzern handeln
• LLM-Copiloten mit Zugriffstokens
• RPA-Bots, Integrationsnutzer in SaaS
• Servicekonten hinter MLOps

Wenn Sie nicht beantworten können: "Welche KI-Agenten existieren, was dürfen sie, wem gehören sie?", haben Sie eine Lücke in der Identity Governance - nicht nur in der KI-Governance.

Warum SSO allein und manuelle Kontrollen bei KI-Agenten scheitern

Die meisten wachstumsstarken Unternehmen stützen sich auf:

• SSO für die 20 % der Anwendungen mit einfacher Integration
• Manuelle Bereitstellung für die übrigen 80 %
• Ad-hoc-Skripte und API-Schlüssel für Bots und Agenten

Für menschliche Logins reicht das oft aus. Es bricht jedoch sofort zusammen, sobald Prüfer die Aktionen von KI-Agenten Ende-zu-Ende nachverfolgen wollen.

Die strukturellen Lücken

1. Keine erstklassige Identität für Agenten
   Agenten laufen häufig unter:

   • Geteilten "Automations"-Konten
   • Langfristig gültigen Tokens mit weitreichenden Berechtigungen
   • Lokalen Servicekonten außerhalb von SSO

2. Keine fein granulare Sicht auf Agentenzugriffe
   Selbst wenn Sie die Anwendung kennen, erfassen Sie selten:

   • Welche Repositories der Agent in GitHub anfasst
   • Welche Slack-Kanäle er liest
   • Welche Patienten- oder Finanzakten er abfragt

3. Kein durchgängiger Nachweispfad
   Protokolle sind:

   • Über viele Anwendungen verstreut
   • Nie zu einer nicht-menschlichen Identität zusammengeführt
   • Nicht gemeinsam mit menschlichen Zugriffen prüfbar

4. Abnicker-Reviews statt echter Entscheidungen
   Zugriffsüberprüfungen für Menschen sind heute schon oft "Tabellentheater". Mit Agenten genehmigen Führungskräfte Identitäten, die sie nicht einmal kennen.

Nur Human-only-IGA auf eine KI-getriebene Identitätslandschaft loszulassen, ist wie mit einem Messer zu einer Schießerei zu erscheinen. Sie erfüllen Formvorgaben - aber Sie steuern das Risiko nicht.

Was Aufsichtsbehörden Sie tatsächlich nachweisen lassen (für KI-Agenten)

Wer AI Act & Co. liest, sieht drei wiederkehrende Themen: Nachvollziehbarkeit, Verantwortlichkeit, Verhältnismäßigkeit.

1. Nachvollziehbarkeit

Hochrisiko-KI nach dem AI Act erfordert Protokolle, technische Dokumentation und Marktüberwachung - also einen Einblick in das tatsächliche Systemverhalten.

Für KI-Agenten bedeutet das:

• Die Aktion eines Agenten in einer SaaS-Anwendung verknüpfen mit:
  • Einer eindeutigen nicht-menschlichen Identität
  • Der Richtlinie, die seine Berechtigung gewährt
  • Einer verantwortlichen menschlichen Person

Wenn Sie nicht aus unveränderlichen Protokollen rekonstruieren können: "Dieser Agent hat einen Fall geschlossen, diesen Datensatz geändert, diese Zahlung ausgelöst", stehen Sie unter AI Act, DORA oder HIPAA auf dünnem Eis.

2. Verantwortlichkeit

NIS2 und DORA machen Vorstände und Geschäftsleitungen ausdrücklich für IKT-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 Betreuer
• Bei der Stilllegung müssen Agent-Tokens, Servicekonten und Anwendungsberechtigungen entfernt werden - nicht nur ein Benutzer offgeboardet

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

Der AI Act ist risikobasiert. HIPAA, DORA und CMMC verwenden eigene Begriffe - landen aber alle bei Minimalprinzip, Funktionstrennung und strengeren Kontrollen für kritische Systeme.

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

• Eng gefasste API-Berechtigungen (z. B. reine Leserechte)
• Zeitlich begrenzte, bedarfsorientierte Höherstufung für sensible Aktionen
• Klare Trennung von "vorschlagen" und "ausführen"

SSO-only, manuell und vollständige IGA: Wie sie bei KI-Agenten abschneiden

Viele gehen davon aus: "Wir haben SSO und Protokolle - also sind wir auf der sicheren Seite." So passt das zu den Anforderungen ab 2026:

Kurz gesagt: Wenn Ihre Governance nur Menschen in SCIM-fähigen Anwendungen abdeckt, liegen Sie neben dem risikobasierten Verständnis der Aufsicht.

Identity Governance für KI-Agenten aufbauen, die 2026er Audits besteht

Sie brauchen keinen "maßgeschneiderten KI-Compliance-Stack". Sie brauchen vollständige Identity Governance, die KI-Agenten als gleichwertige Identitäten behandelt.

Darauf kommt es an.

1. Ein einziges Inventar aller Identitäten schaffen

Für jeden KI-Agenten, Bot oder jedes Servicekonto sollten Sie erfassen:

• Zweck (welches Problem er löst, fachlicher Owner)
• Datendomänen (welche Systeme/Daten er berührt)
• Technische Spur (SaaS/On-Prem/Cloud-Konten, Schlüssel, Anmeldedaten)
• Compliance-Auswirkung (HIPAA, PCI, kritische Infrastruktur, Kundendaten usw.)

Tabellenkalkulationen geraten bereits bei einer Handvoll Agenten an die Grenze.

2. Zuständigkeit und Verantwortung zuweisen

Jeder KI-Agent braucht:

• Einen fachlichen Owner (Direktor/Führungskraft), der für seinen Zweck geradesteht
• Einen technischen Owner (Team), das für Betrieb und Stabilität verantwortlich ist
• Onboarding-/Offboarding-Regeln - verlässt der Owner das Unternehmen, wird der Agent überprüft oder stillgelegt

Das ist die Antwort auf: "Wer hat diesen Agentenzugriff genehmigt?"

3. Least Privilege fein granular durchsetzen

Least Privilege für KI-Agenten heißt konkret:

• Welche Projekte/Repos/Queues sind zugänglich?
• Darf der Agent Produktionsdaten ändern oder nur Vorschläge machen?
• Ist Schreibzugriff zeitlich und auf bestimmte Workflows begrenzt?

Iden bringt Governance bis auf die Ressourcenebene - Kanäle, Repositories, Projekte - nicht nur bis zu Gruppen oder Rollen.

Diese Detailtiefe ist entscheidend, wenn Prüfer fragen, warum ein KI-Incident-Response-Agent in sensiblen Systemen nur lesen, nicht aber schreiben darf.

4. Lebenszyklus automatisieren: Joiner, Mover, Leaver - auch für Agenten

Joiner/Mover/Leaver-Prozesse gelten ebenso für KI-Agenten.

Das bedeutet:

• Erstellung - Agenten werden richtlinienbasiert bereitgestellt, nicht per Skript
• Änderung - Umfangserweiterungen erfordern Begründung und Genehmigung
• Stilllegung - ausgediente Agenten verlieren überall Zugriffe/Tokens/Konten, nicht nur in einigen Apps

Iden wendet Lebenszyklusautomatisierung auf menschliche und nicht-menschliche Identitäten an - über alle Anwendungen hinweg, auch ohne SCIM oder APIs.

5. Zugriffsüberprüfungen aus Tabellen in Echtzeitentscheidungen überführen

Zugriffsreviews für Agenten dürfen kein jährlicher Kraftakt sein. Sie müssen:

• Kontinuierlich sein (ausgelöst durch Änderungen - Risiko, Nutzung, Ownership)
• Kontextscharf (angereichert mit realer Agentenaktivität)
• Handlungsorientiert (mit einem Klick über Systeme hinweg entziehen oder passend zuschneiden)

Agentische Workflows (KI-gestützte, autonome Abläufe) ermöglichen es der Plattform, riskante Muster (z. B. inaktive Agenten mit übermäßigen Rechten) zu erkennen und gezielte Korrekturen vorzuschlagen.

Wie vollständige Identity-Governance-Plattformen die Lücke bei nicht-menschlichen Identitäten schließen

Stellen Sie keine KI-Spezialtools auf ein fragmentiertes Identitätsfundament. Sanieren Sie den Kern: Steuern Sie jede Identität - menschlich wie maschinell - in jeder Anwendung.

Iden ist genau für dieses Fundament gebaut.

Iden automatisiert die Bereitstellung in mehr als 175 Anwendungen und verwaltet menschliche und nicht-menschliche Identitäten - einschließlich KI-Agenten und Servicekonten - in einer zentralen Plattform.

Zentrale Governance-Funktionen für KI-Agenten:

• Universelle Abdeckung ohne SCIM-Aufschlag
  • Integration mit SCIM-, API- und Nicht-API-Anwendungen - auch den Nischenwerkzeugen, in denen Agenten sich verstecken
  • Unterstützung im Standardtarif - keine erzwungenen Enterprise-Upgrades nur für Agentenautomatisierung
• Vereinheitlichte Identitätssicht für Menschen und Maschinen
  • Ein Dashboard: Mitarbeitende, Dienstleister, KI-Agenten, Servicekonten
• Fein granulare Kontrollen gemäß Aufsichtsanforderungen
  • Kanal-, Repo- und Projektebene bei Berechtigungen, damit Minimalprinzip gelebte Praxis wird
• Unveränderliche Audit-Logs, kontinuierliche Governance
  • Banktaugliche Verschlüsselung und unveränderliche Spuren liefern Echtzeit-Nachweise für die Aufsicht
• Agentische Workflows für Compliance
  • KI-gestützte, autonome Workflows gleichen Identitäten ab, markieren Anomalien und setzen Richtlinien automatisch durch

Bauen Sie keine Parallelinfrastruktur speziell für KI auf - erweitern Sie Ihre Identity Governance, um diese neue Identitätsgattung mit derselben Automatisierung und Strenge abzudecken, die menschliche Nutzer schon immer gebraucht haben.

Konkrete nächste Schritte bis August 2026

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

Innerhalb von 30 Tagen:

• Inventarisieren Sie KI-Agenten, Bots und Servicekonten in kritischen Systemen
• Markieren Sie diejenigen, die mit folgenden Bereichen in Berührung kommen:
  • EU-Bürgern (AI Act, NIS2)
  • Finanzdienstleistungen (DORA, CMMC)
  • Gesundheitsdaten (HIPAA)
• Identifizieren Sie Agenten, die SSO umgehen (API-Schlüssel, anwendungslokale Konten)

Innerhalb von 90 Tagen:

• Weisen Sie für jede nicht-menschliche Identität fachliche und technische Owner zu
• Pilotieren Sie fein granulare, richtliniengesteuerte Zugriffe für ausgewählte Agenten in 3-5 zentralen Anwendungen
• Implementieren Sie zentrale, unveränderliche Audit-Logs für Agentenaktivitäten

Vor dem 2. August 2026:

• Führen Sie vollständige Identity Governance über Ihren gesamten SaaS-Stack ein - inklusive Nicht-SCIM-/Nicht-API-Anwendungen
• Automatisieren Sie Joiner/Mover/Leaver-Flows und Zugriffsreviews für alle Identitäten
• Mappen Sie Kontrollen auf AI Act, NIS2, DORA, HIPAA, SOC 2, CMMC - seien Sie in der Lage, zu zeigen, nicht nur zu versprechen

Wenn Sie KI-Agenten als vollwertige Identitäten behandeln, bestehen Sie Audits schneller und arbeiten agiler als Wettbewerber, die noch Skripte, Tickets und Wunschdenken zusammenstückeln.

Häufig gestellte Fragen

Wie wirkt sich der EU AI Act konkret auf unsere internen KI-Agenten aus?

Wenn Ihre Agenten Hochrisiko-KI-Systeme nach Anhang III mit antreiben - etwa in Beschäftigung, Kreditvergabe oder kritischen Diensten -, dann gelten die Anforderungen des AI Act zu Risikomanagement, Protokollierung, Dokumentation und Aufsicht für Ihr gesamtes System, nicht nur für externe Anbieter. Sie müssen klar nachweisen können, welche Agenten existieren, welche Zugriffe sie haben und wie Governance und Protokollierung funktionieren.

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

Klassisches IAM/SSO kümmert sich um Authentifizierung und Gruppen für menschliche Nutzende in einem Teil Ihres Anwendungsstapels. Sobald KI-Agenten, Bots und Servicekonten eigenständig in SaaS handeln - oft ohne SCIM oder nutzbare APIs - benötigen Sie vollständige Identity Governance:

• Inventar aller nicht-menschlichen Identitäten
• Steuerung von Berechtigungen auf granularer Ebene
• Automatisierung von Lebenszyklus und Zugriffsreviews - über alle Systeme hinweg

Andernfalls können Sie die prüffähigen Nachweise, die Aufsichtsbehörden erwarten, nicht liefern.

Wie greifen NIS2 und DORA zusammen mit dem EU AI Act bei KI-Agenten?

NIS2 und DORA sprechen nicht explizit von "KI-Agenten" - sie verlangen Identitätsverwaltung, Zugriffskontrolle und Protokollierung überall dort, wo kritische Funktionen unterstützt werden. Wenn ein Agent Handel, Zahlungen oder Incident Response beeinflussen kann, fällt er in den Anwendungsbereich. Der AI Act legt anschließend KI-spezifische Anforderungen oben drauf - in der Annahme, dass eine solide Identity Governance bereits existiert.

Wir haben ein schlankes IT-Team. Wie realistisch ist es, all das bis 2026 umzusetzen?

Wenn Sie versuchen, alles manuell und pro Anwendung zu konfigurieren, ist es unrealistisch. Genau hier liefern Automatisierungs-first-IGA-Plattformen wie Iden Mehrwert: steckfertige Konnektoren, Onboarding ohne Entwicklungsaufwand, richtliniengesteuerte Workflows über den gesamten Stack.

Beginnen Sie mit Ihren Hochrisiko-Anwendungen und -Agenten: Sie werden schnell Verbesserungen sehen - weniger Tickets, saubereres Offboarding, bessere Auditfähigkeit - ohne ein eigenes IAM-Team aufbauen zu müssen.

Geht es hier um KI-Governance oder um Identity Governance?

Um beides. Aber KI-Governance ohne Identity Governance ist Theater. Sie können hervorragende KI-Richtlinien und Register haben - wenn:

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

setzen Sie auf Vertrauen statt auf Kontrolle.

Behandeln Sie KI-Agenten als neue Gattung von Identitäten. Steuern Sie sie kontinuierlich und automatisiert - genau wie Ihre Mitarbeitenden. So wird 2026 nicht zum Compliance-Feuerwehr-Einsatz, sondern zu einem Wettbewerbsvorteil.