Die Produktarchitektur hinter vertrauenswürdigen KI-Experiences

Moderne Anwendungen sehen sich mit widersprüchlichen Anforderungen konfrontiert und werden gleichzeitig in alle Richtungen gezogen, während sie Sicherheit, Datenschutz und User Experience in Einklang bringen müssen. Von ihnen wird erwartet, dass sie Conversion und Personalisierung maximieren und gleichzeitig immer raffiniertere automatisierte Bedrohungen abwehren. In der Regel behandeln Entwicklungsteams diese als separate Arbeitsströme: Ein Wachstumsteam kümmert sich um die Benutzeroberfläche, während ein Security-Team den Perimeter verwaltet.

Diese Trennung scheitert, wenn Sie KI einführen. Wenn autonome Agenten beginnen, mit Ihren Daten zu interagieren, verschwindet der „Perimeter“. Das Einzige, was noch bleibt, um das System zu steuern, ist die Identität.

In den meisten Legacy-Architekturen war das Identity-Management nur ein abzuhakender Punkt auf der Liste: eine Login-Seite und eine Datenbank für gehashte Passwörter. Aber in einem Produkt-Ökosystem, in dem KI-Agenten im Namen von Nutzer:innen handeln können, muss das Identity-Management vom Rand der Architektur direkt in deren Zentrum rücken.

Wenn Sie nicht genau wissen, wer oder was eine Aktion ausführt und welcher spezifische Kontext dies zulässt, entwickeln Sie kein KI-Experience, sondern ein Risiko.

In diesem Artikel sehen wir uns an, wie sich Identity-Management von einem Feature zu einem zentralen Bestandteil der Produktarchitektur entwickelt hat und warum es zur Grundlage für die Entwicklung vertrauenswürdiger KI-Experiences wird.

Identität ist jetzt Teil Ihrer Produktarchitektur

Traditionell war Identity-Management eine äußere Hülle. Sie haben eine App entwickelt und dann „Authentifizierung hinzugefügt“. Dies führte zu einer fragmentierten Realität, in der die Identitätslogik an verschiedenen Stellen angesiedelt war: teils im Gateway, teils in den Microservices und teils fest im Frontend codiert.

Wenn das Identity-Management fragmentiert ist, verlangsamt sich Ihr Produkt. Nicht, weil Ihr Code schlecht ist, sondern weil Ihre „Informationsquelle“ verstreut ist. Ein Benutzender ist möglicherweise autorisiert, eine Ressource in der Web-App anzuzeigen, wird jedoch durch eine veraltete Richtlinie in der API blockiert. Diese Inkonsistenzen verursachen „Identity-Altlasten“, wodurch es unmöglich wird, neue Features schnell bereitzustellen.

In modernen Architekturen fungiert Identity-Management als ein gemeinsam genutztes System. Es bietet eine konsistente Methode zur Handhabung von Authentifizierung (Ist diese Person diejenige, die sie vorgibt zu sein?) und Autorisierung (Was darf sie in diesem Moment tun?). Durch diese Zentralisierung verlagern Sie die Komplexität aus den einzelnen Diensten in eine dedizierte Ebene. Dadurch können sich Ihre Entwickler:innen darauf konzentrieren, Features zu entwickeln, anstatt OAuth-Flows mühsam zu implementieren.

Warum sich Identität direkt auf das Wachstum auswirkt, nicht nur auf die Sicherheit

Wenn das Wachstum nachlässt, wird dies oft als Produkt- oder Marketingproblem betrachtet. Die Konversionsrate sinkt, die Kundenbindung lässt nach oder die Expansion dauert länger als erwartet. In vielen Fällen liegt das Problem jedoch tiefer im System. Dies zeigt sich darin, wie Benutzer:in Ihr Produkt aufrufen, darin navigieren und zu ihm zurückkehren.

Konversion

Die erste Interaktion ist die empfindlichste. Wenn Ihr Onboarding-Flow zu viele manuelle Eingaben erfordert oder ein Zurücksetzen des Passworts erzwingt, bevor ein Benutzer:in den Mehrwert des Produkts überhaupt erkannt hat, verlässt diese:r die Anwendung.

Modernes Identity-Management ermöglicht die progressive Profilerstellung und die Erfassung von Daten nur dann, wenn sie benötigt werden. Durch die Nutzung von Social Logins oder Passkeys verkürzen Sie die Wertschöpfung. Noch wichtiger ist: Das Identity-Management liefert das anfängliche „Wer“ – und ermöglicht es so, bereits die allererste angezeigte Bildschirmseite individuell auf die jeweilige Person zuzuschneiden.

Kundenbindung und Kundenengagement

Benutzer:innen denken nicht in Sessions oder Systemen. Sie erwarten Kontinuität. Wenn sie einen Workflow auf einem Mobilgerät beginnen und auf einem Desktop abschließen, sollten sie nicht das Gefühl haben, mit zwei verschiedenen Unternehmen zu interagieren.

Wenn das Identity-Management nicht in die Architektur integriert ist, geht der Kontext verloren. Sitzungen laufen zu früh ab oder Einstellungen werden nicht synchronisiert. Eine einheitliche Identity-Ebene sorgt dafür, dass der Status der einzelnen Personen über jeden Berührungspunkt hinweg erhalten bleibt – und genau das ist die eigentliche Voraussetzung für eine hohe Bindungsrate.

Ausbau

Für B2B-Plattformen bedeutet die Phase der „Expansion“ in der Regel den Übergang von einem einzelnen Benutzer:in zu einer gesamten Organisation. Dies erfordert mehr als nur ein einfaches Login; es erfordert eine robuste Mandantenfähigkeit und eine ausgereifte Governance.

Wenn Ihr Identity-System komplexe Organisationshierarchien oder „Bring Your Own Identity“ (BYOID) für Firmenkundschaft nicht verarbeiten kann, wird Ihr Vertriebsteam schnell an seine Grenzen stoßen. Vertrauen bei der Firmenkundschaft nachhaltig aufzubauen bedeutet zu beweisen, dass Sie deren spezifische Sicherheitsrichtlinien über die gesamte Mandantenstruktur hinweg durchsetzen können – ohne dabei den Workflow zu stören.

Wenn Identität ein zentraler Architekturpfeiler ist, ist Mandantenfähigkeit kein „Hack“, der einer Datenbank überlagert wird; sie ist eine strikte Grenze, die Datenisolation ermöglicht und gleichzeitig flexiblen, attributbasierten Zugriff in großem Maßstab zulässt.

KI ändert die Spielregeln: Identity-Management muss jetzt Maschinen steuern

Das Aufkommen agentenbasierter KI, die Aktionen ausführen kann und nicht nur Texte zusammenfasst, schafft eine massive Sicherheitslücke. Traditionelle Identitätsmodelle wurden für menschliche Sessionen entwickelt, die einige Stunden dauern und bei denen ein Mensch auf einen Button klickt.

KI-Agenten funktionieren so nicht.

Actions sind nicht mehr an Sessions gebunden

Ein KI-Agent könnte eine Abfolge von Ereignissen auslösen, die sich über Tage hinweg erstreckt. Er ruft womöglich fünf verschiedene Microservices auf, um eine einzige Aufgabe zu erledigen. Wenn Ihr Sicherheitsmodell auf einem temporären Browser-Cookie basiert, greift es hier nicht mehr.

Sie benötigen eine Möglichkeit, einem Agenten „zweckgebundene“ Anmeldedaten auszustellen. Diese müssen zwar auf die ursprüngliche menschliche Absicht zurückgehen, in ihren tatsächlichen Ausführungsrechten jedoch strikt eingeschränkt sein. Genau an dieser Stelle wird das Management nicht-menschlicher Identitäten (NHI) zum wichtigsten Teil Ihres Stacks.

Zugriffsentscheidungen müssen in Echtzeit getroffen werden

In einer agentischen Welt können Berechtigungen nicht statisch sein. Sie können einer KI nicht einfach „Administrator“-Rechte erteilen und auf das Beste hoffen. Zugriffsentscheidungen müssen zum Zeitpunkt der Anfrage bewertet werden.

Die herkömmliche Rollenbasierte Zugriffskontrolle (RBAC) ist dafür zu grob. Einem Agenten die Rolle "Manager" zuzuweisen, ist eine massive Überprivilegierung; dadurch erhält die KI jederzeit Zugriff auf alles, was ein Manager sehen kann. Stattdessen muss das System die Beziehung zwischen dem Akteur, der Aktion und der spezifischen Ressource verstehen.

Dies erfordert eine Umstellung auf kontinuierliche Authentifizierung. Das System sollte den dynamischen Kontext der Anfrage überprüfen:

• Fordert der Agent mehr Daten an, als er für diese spezifische Teilaufgabe benötigt?
• Erfolgt diese Anfrage in einer ungewöhnlichen Häufigkeit?
• Hat dieser spezifische Agent in genau diesem Moment eine nachgewiesene Beziehung zu dieser spezifischen Datenzeile für diesen spezifischen Tenant?

Wenn Identität in die Architektur integriert ist, prüft das System nicht nur eine statische „Rolle“ in einer Datenbank; es bewertet die laufende Beziehung. Sobald eine Anomalie erkannt oder eine Beziehungsgrenze überschritten wird, kann das System die Session sofort beenden.

Attribution wird zu einer Anforderung, nicht zu einem Feature

Wenn ein KI-Agent einen Fehler macht oder ein böswilliger Akteur diesen manipuliert, benötigen Sie einen deterministischen Audit-Trail. Sie müssen beantworten können:

1. Welches Modell hat diese Anfrage gestellt?
2. Welcher Benutzer:in hat den Agenten autorisiert zu handeln?
3. Welche spezifische Richtlinie hat diesen Datenzugriff erlaubt? Ohne eine zentralisierte Identity-Ebene lassen sich diese Fragen nicht beantworten. Die Identität liefert den "Herkunftsnachweis" für jede von einer KI ausgeführte Aktion.

Wie sich die Identitätsarchitektur auf bestimmte Branchen auswirkt

Diese architektonischen Veränderungen führen schnell von der Theorie zu technischen Schulden. Wenn die Autorisierungslogik über verschiedene Dienste hinweg fragmentiert ist, führt dies zu Inkonsistenzen im Verhalten von Produkten, insbesondere wenn Systeme zunehmend verteilt sind und KI-Agenten eingeführt werden.

Einzelhandel

Im Einzelhandel liegt die Identität direkt auf dem Umwandlungspfad und macht den Unterschied zwischen einem „gewöhnlichen“ Geschäft und einem personalisierten Concierge aus. Wenn ein Kunde im Web, auf Mobilgeräten und in der Filiale erkannt wird, kann der Einzelhändler einen einzigen, einheitlichen Warenkorb anbieten.

Wenn jedoch ein KI-Einkaufsassistent eingeführt wird, benötigt dieser Assistent eingeschränkten Zugriff auf die Zahlungsinformationen der Benutzer:in – genug, um den Kauf abzuschließen, aber nicht genug, um die Lieferadresse zu ändern oder die gesamte Bestellhistorie einzusehen. Genau dieses Scoping übernimmt das Identity-Management.

Finanzdienstleister

Bei Finanzdienstleistungen werden ständig Identity-Entscheidungen getroffen, und der Spielraum für Fehler ist geringer. Benutzer:innen erwarten ein schnelles Onboarding und reibungslosen Zugriff, aber auch starken Schutz, wenn Aktionen sensibel werden.

Vertrauen im Fintech-Bereich basiert auf dem Prinzip der schrittweisen Authentifizierung. Sie benötigen keinen Fingerabdruck-Scan, um Ihren Kontostand abzufragen, aber Sie benötigen ihn definitiv, um 10.000 $ zu überweisen. Moderne Identity-Architekturen ermöglichen eine „Risk-Based Authentication“ – das System fordert eine zusätzliche Sicherheitsüberprüfung nur dann ein, wenn das Risiko es tatsächlich erfordert.

Wenn KI zur Automatisierung von Handel oder Betrugserkennung eingesetzt wird, stellt Identität sicher, dass diese automatisierten Agenten innerhalb strenger gesetzlicher und regulatorischer Grenzen agieren.

Gesundheitswesen

Im Gesundheitswesen ist Identität eng mit Vertrauen und Datenschutz verbunden, und dort steht am meisten auf dem Spiel.

Patientendaten müssen „isoliert“, aber für die richtigen Anbieter zur richtigen Zeit zugänglich sein. Wenn KI zur Analyse von Laborergebnissen eingesetzt wird, bestätigt die Identity-Ebene, dass die KI nur die spezifischen Datensätze sieht, die sie für diese Analyse benötigt (das Least-Privilege-Prinzip) und dass die Zustimmung der Patienten in Echtzeit überprüft wird, bevor die Daten entschlüsselt werden.

B2B-SaaS-Plattformen

In SaaS-Umgebungen nimmt die Identitätskomplexität schnell zu.

Sie verwalten nicht nur Benutzer:innen, sondern auch Organisationen, Rollen, Berechtigungen und zunehmend auch KI-Features, die direkt in Workflows eingebettet sind. Agenten können im Namen von Benutzer:innen handeln, systemübergreifend Aktionen auslösen oder mit externen Diensten interagieren.

Im Grunde bewegt sich B2B-SaaS hin zu einer mandantenfähigen KI. Das bedeutet, dass Ihre KI-Funktionen Daten für Tausende von verschiedenen Unternehmen gleichzeitig verarbeiten. Das größte Risiko besteht hierbei im mandantenübergreifenden Datenabfluss. Eine robuste Identity-Architektur stellt sicher, dass der KI-Agent, der für Unternehmen A im Einsatz ist, unter keinen Umständen Einsicht in die Daten von Unternehmen B erhält – selbst wenn beide auf dasselbe zugrundeliegende LLM zugreifen.

Umsetzung von Identity

Die Verlagerung der Identität von einem peripheren Feature zu einer zentralen Architekturkomponente ist ein bedeutender technischer Wandel. Die meisten Teams scheitern hier, weil sie Identität als einmalige Integrationsaufgabe und nicht als fortlaufende operative Disziplin betrachten.

Entkopplung von Richtlinie und Code

Der häufigste Fehler in der Produktarchitektur besteht darin, Autorisierungslogik direkt in den Anwendungscode einzubetten. Wenn sich Anweisungen wie if (user.role == 'admin') quer über alle Microservices verteilen, entsteht ein Albtraum bei der Wartung. Um Identity-Management operabel zu machen, muss die Berechtigungsrichtlinie konsequent von der zugrundeliegenden Geschäftslogik entkoppelt werden.

Durch den Wechsel zu einem externalisierten Autorisierungsdienst, insbesondere einem, der für beziehungsbasierte Zugriffskontrolle (Relationship-Based Access Control, ReBAC) entwickelt wurde, ermöglichen Sie es Sicherheits- und Produktteams, Zugriffsregeln in Echtzeit dynamisch zu aktualisieren.

Anstatt Code neu bereitzustellen, um eine Berechtigung zu ändern, aktualisieren Sie einfach den Beziehungsgraphen. Dies bestätigt, dass sich Ihre Sicherheitslage mit der Weiterentwicklung Ihrer KI-Agenten ebenfalls weiterentwickelt, ohne auch nur eine einzige Zeile der Microservice-Logik anzutasten.

Lösung des Token-Austausch-Problems

In einem verteilten System, insbesondere wenn KI-Agenten beteiligt sind, ändert sich die „Identität“ des Akteurs häufig, während dieser den Stack durchläuft. Ein Benutzender meldet sich an (Benutzerkontext) und aktiviert einen KI-Agenten (Servicekontext), der dann eine Datenbank aufruft (Ressourcenkontext).

Um dies zu operationalisieren, ist ein robustes Token-Austausch-Muster erforderlich. Das ursprüngliche JSON Web Token (JWT) der zugreifenden Person kann nicht einfach durch die gesamte Aufrufkette weitergereicht werden. Das stellt ein erhebliches Sicherheitsrisiko dar und gewährt viel zu umfassende Zugriffsrechte. Stattdessen muss Ihre Architektur die Token-Einschränkung unterstützen, bei der jeder Schritt in der Anfragekette ein Token mit dem absolut minimalen Umfang erhält, der zur Ausführung seiner spezifischen Aufgabe erforderlich ist.

Automatisierung des NHI-Lebenszyklus

Wenn Ihr Plan für KI-Agenten darin besteht, einen Service-Account zu erstellen und den API-Key in einem Secret-Manager zu speichern, operationalisieren Sie nicht; Sie schaffen lediglich eine Hintertür.

NHIs erfordern die gleiche (oder eine strengere) Governance wie menschliche Benutzer:innen. Das bedeutet:

• Automatische Rotation: Schlüssel und secret sollten ohne menschliches Eingreifen ablaufen und rotieren.
• Verhaltensbezogenes Monitoring: Da Agenten keine „normalen“ Bürozeiten haben, müssen Sie eine Baseline für „normales“ Verhalten festlegen. Wenn ein Agent plötzlich einen Massenexport einer Datenbank anfordert, obwohl er normalerweise nur einzelne Zeilen abfragt, sollte die Identity-Ebene seine Anmeldedaten automatisch widerrufen.
• Attributionszuordnung: Jede nicht-menschliche Identität (NHI) muss einer verantwortlichen Person im Prozess (Human-in-the-Loop) oder einer spezifischen Service-Eigentümerschaft zugeordnet sein. Wenn ein Agent Fehlfunktionen aufweist, sollte niemand stundenlang Logs durchsuchen müssen, um herauszufinden, wer ihn erstellt hat.

Auf den Dauerbetrieb vorbereiten

Die meisten Identity-Projekte konzentrieren sich auf „Tag 1“ – also darauf, Personen erfolgreich zum Login zu bewegen. Operative Exzellenz zeigt sich jedoch erst an „Tag 2“: Was passiert, wenn jemand den physischen MFA-Schlüssel verliert? Was geschieht, wenn der Tenant einer Kundenorganisation in eine andere Region mit abweichenden Datenschutzgesetzen migriert werden muss?

Identity-Management operabel zu machen bedeutet, das technische Fundament für solche Grenzfälle bereits frühzeitig aufzubauen. Dazu gehören eine zentralisierte Protokollierung, die in Ihr SIEM (Security Information and Event Management) einfließt, Self-Service-Wiederherstellungsabläufe, die keine manuellen Helpdesk-Tickets erfordern, und eine Not-Aus-Schalter-Funktion, die alle Sessions für eine kompromittierte Organisation in all Ihren Diensten sofort widerrufen kann.

Mit Identity-Management skalieren Sie Vertrauen

Während sich Anwendungen von "Werkzeugen, die wir nutzen" zu "Agenten, die für uns handeln" entwickeln, verschwindet der Spielraum für Fehler. Ohne eine beziehungsbasierte Identity-Ebene könnte eine einfache Eingabeaufforderung wie "Fasse die Leistung meines Teams zusammen" einem Agenten Zugriff auf sämtliche Gehaltsdaten und privaten Personalakten im Unternehmen gewähren.

Eine einzige falsch konfigurierte Berechtigung oder ein zu weit gefasstes Token ist kein kleiner Fehler mehr; es ist eine massive Schwachstelle. Komplexität ist der Feind der Sicherheit. Wenn die Identitätslogik auf 20 verschiedene Dienste verteilt ist, haben Sie 20 verschiedene Fehlerquellen.

Indem Sie das Identity-Management als zentrale Architekturebene behandeln, tun Sie mehr, als nur die Tür abzuschließen. Sie erstellen ein System, das konsistent, nachvollziehbar und skalierbar ist. Sie geben Ihren Teams die Freiheit, ehrgeizige KI-Features zu entwickeln, da Sie wissen, dass das zugrunde liegende Identity-Framework diese Features innerhalb ihrer Grenzen hält.

Jede Interaktion, ob ein Mensch auf einen Link klickt oder ein KI-Agent eine API aufruft, beginnt mit derselben grundlegenden Frage: "Wer ist das, und was darf er tun?" Diese Frage jedes einzelne Mal richtig zu beantworten, ist der einzige Weg, ein Produkt zu entwickeln, dem Nutzerinnen und Nutzern wirklich vertrauen.

Möchten Sie mehr darüber erfahren, wie Identity-Management KI, Wachstum und Vertrauen fördert?
Erkunden Sie Absicherung aller Interaktionen: Identity-Management-Leitfaden für agentenbasierte Umgebungen.