Wer bist du?

Betrachten wir ein vollständig erfundenes Beispiel. Ein Unternehmen möchte für ein neues Kundenportal Angebote von drei Softwareanbietern einholen. Der hier verwendete Name „Nova Digital“ enthält keine Aussage über ein reales Unternehmen.

Die Führungskraft gibt dem KI-Agenten einen kurzen Auftrag: „Finde Nova Digital. Bitte sie um ein Angebot für unser Portalprojekt in sechs Sprachen.“ Der Agent sucht.

Unter „Nova Digital“ findet er mehrere unterschiedliche Ergebnisse:

• ein Softwareunternehmen in Istanbul,
• eine in London eingetragene Digitalmarketingagentur,
• einen selbstständigen Designer mit demselben Namen,
• eine alte, nicht mehr genutzte Domain,
• ein von einem anderen Unternehmen betreutes Social-Media-Konto
• und ein seit Jahren nicht aktualisiertes Firmenprofil in einem Branchenverzeichnis.

Der Agent wählt die Domain, die den solidesten Eindruck macht. Er glaubt, genügend Informationen über das Unternehmen gesammelt zu haben. Er verfasst eine ausführliche Angebotsanfrage mit Projektbudget, Namen des vorhandenen CRM-Systems, Mitarbeiterzahl und gewünschtem Liefertermin. Dann versendet er sie. Zwei Tage später kommt eine Antwort. Die andere Seite ist interessiert, schlägt ein Gespräch vor und nennt eine Bankverbindung für die Anzahlung. Alles wirkt normal. Doch die Nachricht ging an das falsche Nova Digital. Gesucht war der Anbieter von Kundenportalen in Istanbul. Kontaktiert hat der Agent die Werbeagentur in London. Die gefundenen Informationen sind nicht vollständig erfunden. Die Domain ist echt.

Das Unternehmen ist echt. Die Kontaktadresse funktioniert. Ein echter Mitarbeiter hat geantwortet. Aber richtige Informationen wurden um die falsche Identität herum zusammengeführt. Das ist nicht bloß ein Suchfehler, sondern ein Fehler bei der Identitätsauflösung. Der Agent hat eine Entität gefunden, aber nicht richtig bestimmt, mit wem er es zu tun hat. Weiß eine Maschine das nicht, kann sie nicht sicher handeln — unabhängig davon, wie gründlich sie recherchiert, wie zutreffend sie formuliert und wie leistungsfähig ihre Werkzeuge sind.

Der Verhaltensvertrag von GBO beginnt deshalb mit der Frage:

Wer bist du?

Ein Name ist keine Identität

Im Alltag verwenden Menschen Namen als Verweis auf eine Identität. „Ruf Ahmet an.“ „Buche beim Atlas Hotel.“ „Sieh dir die Erklärung der Zentralbank an.“ „Schick Nova Digital ein Angebot.“ Meist hilft der Kontext zu verstehen, welche Person oder Organisation gemeint ist. Selbst bei mehreren Menschen gleichen Namens ermöglichen uns Kontakte, frühere Gespräche, gemeinsame Bekannte und unser Standort die richtige Zuordnung. Maschinen steht dieser Kontext nicht immer zur Verfügung.

Denselben Namen können unterschiedliche Entitäten verwenden:

• Unternehmen,
• Personen,
• Marken,
• Niederlassungen,
• Produkte,
• Social-Media-Konten
• oder alte und neue Organisationen.

Auch das Gegenteil ist möglich: Dieselbe Entität erscheint an verschiedenen Stellen unter verschiedenen Namen.

Bei einem Unternehmen können sich folgende Bezeichnungen unterscheiden:

• rechtlicher Firmenname,
• Markenname,
• Domain,
• Benutzername in sozialen Medien,
• Produktname,
• Name in der Landessprache
• und Name auf dem internationalen Markt.

Identität ist deshalb mehr als ein Name. Sie erklärt die Entität hinter einer Bezeichnung und deren Beziehungen zu anderen Menschen, Organisationen, Domains, Befugnissen und Zeitpunkten. Dieses Buch betrachtet Identität anhand der Verbindungen zwischen Entität, Beziehung, Rolle, Befugnis, Zeit und Nachweisen. Das ist ein Untersuchungsrahmen, keine Punkteformel. Ein einzelnes Element zu kennen reicht nicht aus. Wer den Namen einer Person kennt, weiß damit noch nicht, ob sie für ein Unternehmen unterschreiben darf. Wer weiß, dass eine Domain zum Unternehmen gehört, weiß noch nicht, ob jede Seite darauf aktuell ist.

Der Nachweis, dass ein Mitarbeiter tatsächlich dort beschäftigt ist, belegt keine Befugnis, Preise zu nennen oder Verträge anzunehmen. Ein tatsächlich vom Unternehmen betriebener KI-Agent darf deshalb noch lange nicht jeden Vorgang in dessen Namen ausführen. Identität ist kein Etikett, sondern eine Verantwortungskette.

Die Schichten der Identität

Menschen und Organisationen haben in der digitalen Welt keine einschichtige Identität. Mehrere Schichten sind miteinander verbunden. Werden sie verwechselt, kann das Agentenverhalten in die falsche Richtung gehen.

Menschliche Identität

Hier geht es um die natürliche Person: ihren Namen, ihre Kontaktwege, ihre Rollen und die Berechtigung zu bestimmten Vorgängen. Wer eine Person identifiziert, hat damit jedoch nicht festgestellt, dass sie in jedem Kontext dieselben Befugnisse besitzt. Ein Mitarbeiter darf nicht automatisch für das Unternehmen Verträge unterzeichnen. Der Autor eines Buchs ist nicht zwangsläufig Eigentümer der Plattform, auf der es erscheint. Jemand kann eine Marke gegründet haben, während die Rechtsgeschäfte über ein anderes Unternehmen laufen. Die menschliche Identität ist wichtig.

Für Handlungen muss sie jedoch gemeinsam mit Rolle und Befugnis betrachtet werden.

Rechtliche Identität

Die rechtliche Identität zeigt, welche Person oder welcher Rechtsträger hinter einem Vertrag, einer Rechnung, einer Zahlung oder einer formellen Verantwortung steht. Eine Marke muss keine eigene Rechtspersönlichkeit haben. Eine Domain kann einem anderen Unternehmen gehören. Ein Projekt kann unter einem Markennamen beworben werden, während die Rechnung unter einem anderen rechtlichen Firmennamen ausgestellt wird. Das ist für sich genommen kein Problem. Problematisch ist eine nicht erklärte Beziehung. Ein Agent kann aus dem Markennamen schließen, dass auch der Vertrag unter diesem Namen zustande kommt. Soll die Zahlung an einen anderen Rechtsträger gehen, könnte er das fälschlich für ein Betrugszeichen halten.

Oder er begeht den umgekehrten Fehler und bezahlt den falschen Rechtsträger, weil er nur den Markennamen kennt.

Aus Sicht von GBO müssen diese Beziehungen klar sein:

Wer betreibt die Marke? Wer schließt den Vertrag? Wer stellt die Rechnung? Wer erhält die Zahlung? Wer ist im Streitfall verantwortlich?

Markenidentität

Die Marke ist das Gesicht, das Menschen und Maschinen im Alltag wiedererkennen. Name, Logo, Domain, Sprache der Leistungsangebote, veröffentlichte Arbeiten und Marktpositionierung prägen diese Identität. Sie ist jedoch nicht mit der rechtlichen Identität gleichzusetzen. Über die Marke laufen Kommunikation und Beziehungen; die rechtliche Identität ordnet Verantwortung und Verpflichtungen zu. Ein Agent muss beides verknüpfen können, ohne es als austauschbar zu behandeln.

Operative Identität

Sie zeigt, wie eine Organisation tatsächlich arbeitet. Welches Team übernimmt welche Aufgabe?

Welche Einheit nennt Preise?

Wer genehmigt eine Veröffentlichung im Live-System?

Wer darf auf Kundendaten zugreifen?

Wer darf nur Entwürfe vorbereiten?

Wer darf Zahlungen ausführen?

Wer darf Nachrichten nach außen senden?

Eine im Organigramm als Führungskraft ausgewiesene Person ist nicht zwangsläufig zu jeder operativen Handlung befugt. Umgekehrt kann ein Mitarbeiter mit niedrigerem Titel weitreichende technische Rechte in einem bestimmten System haben. Die operative Identität erklärt, wie Befugnisse im Alltag verteilt sind.

Digitale Identität

Domains, E-Mail-Adressen, Social-Media-Konten, Plattformprofile, digitale Signaturen, API-Clients und maschinenlesbare Einträge gehören zur digitalen Identität. Eine E-Mail-Adresse mit Unternehmensdomain kann Vertrauen wecken. Das Konto könnte allerdings übernommen worden sein. Ein Social-Media-Konto kann verifiziert erscheinen, inzwischen aber von einem ehemaligen Mitarbeiter kontrolliert werden. Eine Website kann offiziell sein, obwohl einzelne Seiten seit Jahren nicht aktualisiert wurden. Die digitale Identität allein beantwortet die Vertrauensfrage nicht abschließend. Sie muss zu den übrigen Identitätsschichten passen.

Agentenidentität

Diese Schicht ist neu und gewinnt an Bedeutung.

Die Identität eines KI-Agenten muss erklären:

• in wessen Namen er arbeitet,
• für welchen Zweck er geschaffen wurde,
• auf welche Systeme er zugreifen kann,
• welche Vorgänge er ausführen darf,
• welche Vorgänge er nicht ausführen darf
• und wann er menschliche Freigabe anfordern muss.

Allgemeine Bezeichnungen wie „Rechercheassistent“, „Kundenservice-Agent“ oder „Einkaufsagent“ genügen nicht. Die Agentenidentität muss gemeinsam mit dem Handlungsrahmen definiert werden. Denn der Agent erzeugt womöglich nicht mehr nur Antworten. Er kann im Namen einer Organisation Spuren in der Außenwelt hinterlassen.

Das Identitätsdreieck

Eine Agentenhandlung lässt sich anhand von drei Identitätsrollen untersuchen. Sie können in einer Entität zusammenfallen; jede Rolle kann auch mehrere Akteure umfassen:

1. Auftraggeber

Die Person oder Organisation, die die Handlung veranlasst.

2. Ausführender

Der Agent oder das Agentennetz, das den Auftrag erledigt.

3. Gegenüber

Die Person, das Unternehmen, das System oder die Entität, auf die sich die Handlung richtet.

Diese drei Rollen können wir als Identitätsdreieck bezeichnen.

Beim Versenden einer E-Mail:

• Wer hat den Auftrag erteilt?
• Welcher Agent versendet die Nachricht?
• Welche Person oder Organisation empfängt sie?

Bei einem Einkauf:

• Wer nutzt das Budget?
• Welcher Agent führt den Vorgang aus?
• Welcher Rechtsträger verkauft das Produkt?

Bei einer Veröffentlichung in sozialen Medien:

• Wer trifft die Kommunikationsentscheidung?
• Welches System erstellt und veröffentlicht den Inhalt?
• Auf welchem Konto, in wessen Namen und für welches Publikum wird veröffentlicht?

Beim Aktualisieren einer Website:

• Wer bestimmt das Ziel der Änderung?
• Welcher Agent ändert die Datei?
• Welche Website wird verändert, wer betreibt sie und wen betrifft die Änderung?

Ist eine Ecke des Identitätsdreiecks unklar, wird das Verhalten riskant. Ein ungeprüfter Auftraggeber kann dazu führen, dass der Agent Anweisungen von der falschen Person annimmt. Sind Identität und Befugnis des Agenten unklar, weiß der Nutzer nicht, welches System handelt. Wird das Gegenüber falsch zugeordnet, kann der richtige Vorgang die falsche Person treffen.

Vor jeder wichtigen Handlung sind deshalb drei Fragen zu stellen:

Wer will es? Wer tut es? An wem oder gegenüber wem wird es getan?

Echt zu sein bedeutet nicht, befugt zu sein

Ein häufiger Fehler bei der Identitätsprüfung besteht darin, den Nachweis einer echten Person oder eines echten Kontos für ausreichend zu halten. Ein Mitarbeiter kann tatsächlich im Unternehmen arbeiten, ohne Rabatte gewähren zu dürfen. Eine Führungskraft kann ihre Position wirklich innehaben, ohne Zahlungen auf ein bestimmtes Bankkonto anweisen zu dürfen. Ein KI-Agent kann tatsächlich vom Unternehmen betrieben werden, ohne Kundendaten in ein anderes System übertragen zu dürfen. Ein Social-Media-Konto kann wirklich zur Marke gehören. Trotzdem ist nicht jede dortige Nachricht eine autorisierte Erklärung, die eine rechtliche Verpflichtung begründet.

Deshalb gibt es zwei getrennte Fragen:

Wer ist das tatsächlich? Darf diese Person oder dieses System das tun?

Die erste Frage betrifft die Identitätsprüfung, die zweite die Autorisierung. Die Identitätsprüfung stellt mit dem für den Vorgang erforderlichen Vertrauensniveau fest, ob die Person oder das System der behaupteten Identität entspricht. Die Autorisierung bestimmt, ob diese Identität die konkrete Handlung ausführen darf. Agentensysteme dürfen beides nicht verwechseln.

Eine echte Person ist nicht immer eine befugte Person. Ein offizielles Konto ist nicht für jeden Vorgang ein autorisierter Kanal. Systemzugriff ist keine Befugnis zur Systemänderung.

Besonders wichtig wird diese Unterscheidung bei Zahlungen, Verträgen, öffentlichen Erklärungen, personenbezogenen Daten und institutionellen Zusagen.

Eine Rolle ist keine Person

Rollen in Organisationen ändern sich. Wer heute Geschäftsführer ist, kann morgen eine andere Aufgabe haben. Ein Projektleiter kann das Unternehmen verlassen, eine E-Mail-Adresse an einen anderen Mitarbeiter übergehen oder eine andere Agentur ein Social-Media-Konto übernehmen. Ein technischer Leiter kann seine Veröffentlichungsbefugnis nur für ein bestimmtes Projekt besitzen. Rolleninformationen müssen deshalb mit ihrem zeitlichen Bezug gelesen werden. „Diese Person ist CEO“ ist unvollständig.

Genauer wäre: „Diese Person ist zum angegebenen Zeitpunkt CEO dieser Organisation und zu Vorgängen dieser Art befugt.“ Eine Rolle ist keine dauerhafte Eigenschaft, die an einer Person haftet. Sie ist eine Beziehung innerhalb einer bestimmten Organisation, eines Zeitraums und eines Umfangs. Ein Titel darf Agenten deshalb nicht automatisch zur Annahme einer Handlungsbefugnis verleiten. Ein Unternehmensgründer muss nicht zu Zahlungen im Namen des Unternehmens befugt sein. Ein Finanzleiter muss nicht öffentlich für die Marke sprechen dürfen.

Ein Social-Media-Verantwortlicher darf womöglich keine Vertragsbedingungen ändern. Auch der Zugriff eines Entwicklers auf das Live-System belegt keine Befugnis, die Preispolitik festzulegen. Die Rollenbezeichnung allein erklärt die Handlungsgrenze nicht.

Befugnis ist kontextabhängig

Befugnis ist keine allgemeine, unbegrenzte Eigenschaft.

Eine Person oder ein Agent kann befugt sein:

• in einem bestimmten System,
• für eine bestimmte Aufgabe,
• während eines bestimmten Zeitraums,
• bis zu einem bestimmten Risikoniveau
• und unterhalb eines bestimmten Betrags.

Ein Einkaufsagent darf etwa Büromaterial bis zu 100 US-Dollar kaufen, aber kein Jahresabonnement abschließen. Ein Webagent kann Änderungen in der Testumgebung vornehmen; für den Produktivbetrieb kann eine zusätzliche Freigabe nötig sein. Ein E-Mail-Agent darf vielleicht Entwürfe vorbereiten, aber nicht nach außen senden. Ein KI-Avatar-System kann vorab freigegebene Schulungstexte sprechen, ohne neue politische Erklärungen erzeugen zu dürfen.

Eine Aufzeichnung der Befugnis muss deshalb diese Fragen beantworten:

• Welche Handlung?
• Welcher Zweck?
• Welches System?
• Welcher Zeitraum?
• Welche Daten?
• Welche Person oder Organisation als Gegenüber?
• Welches Risikoniveau?
• Welcher Betrag?
• Welche menschliche Freigabe?
• Welches Verfahren zur Rückgängigmachung?

Fehlt ein Teil der Befugnis, darf der Agent die Lücke nicht großzügig auslegen.

Unklare Befugnis ist keine weitreichende Befugnis.

Gleicher Name, unterschiedliche Entitäten

Namenskollisionen gehören zu den leicht übersehenen Problemen der Identitätsauflösung.

Denselben Namen können tragen:

• Unternehmen,
• Hotels,
• Ärzte,
• Berater,
• Produkte,
• Softwarepakete
• oder universitäre Fachbereiche.

Verlässt sich der Agent allein auf den Namen, kann er die falsche Entität auswählen.

Neben dem Namen braucht es weitere Unterscheidungsmerkmale:

• Offizielle Domain
• Land oder Stadt
• Rechtlicher Firmenname
• Steuer- oder Registerangaben
• Branche
• Autorisierter Kontaktkanal
• Markenlogo
• Organisatorische Zugehörigkeit
• Produkt- oder Leistungsumfang

Jemand sagt: „Buche bei Atlas.“

Dann muss der Agent womöglich nachfragen: „Atlas in welcher Stadt? Meinen Sie ein Hotel, ein Restaurant oder ein Reiseunternehmen?“ Nachfragen heißt nicht, langsam zu arbeiten. Es ist sicherer, als schnell gegenüber der falschen Entität zu handeln.

Unterschiedliche Namen, dieselbe Entität

Auch der umgekehrte Fehler kommt vor. Rechtlicher Firmenname, Marke und Domain einer Organisation können voneinander abweichen. Ein Unternehmen kann eine andere Marke gekauft haben. Ein Produkt kann umbenannt worden sein. Ein Autor kann ein Pseudonym verwenden. Der Name einer Organisation kann in verschiedenen Schriften unterschiedlich aussehen.

Bei einem Unternehmen können sich beispielsweise unterscheiden:

• der Name in lateinischer Schrift,
• die arabische Schreibweise,
• die kyrillische Entsprechung,
• der Eintrag im örtlichen Handelsregister
• und der internationale Markenname.

Hält der Agent diese Einträge für verschiedene Entitäten, zerfällt das Wissen. Ein guter Ruf in einer Sprache wird nicht mit einer anderen verknüpft. Preise scheinen zu unterschiedlichen Firmen zu gehören. Veröffentlichte Arbeiten lassen sich der Marke nicht zuordnen. Richtige Identität bedeutet für GBO deshalb nicht nur richtiges Trennen, sondern auch richtiges Zusammenführen.

Die Maschine muss fragen: „Sind das verschiedene Entitäten?“

Ebenso muss sie fragen: „Sind das verschiedene Seiten derselben Entität?“

Der Identitätsgraph

Die digitale Identität einer Entität lässt sich häufig nicht in einem einzeiligen Datensatz erklären. Identität besteht aus Beziehungen.

Zum Beispiel:

• Eine Person hat eine Marke gegründet.
• Ein Rechtsträger betreibt die Marke.
• Eine Domain gehört zur Marke oder wird in ihrem Namen genutzt.
• Die Marke kontrolliert ein Social-Media-Konto.
• Bestimmte Agenten sind für bestimmte Aufgaben befugt.
• Eine Veröffentlichung ist aus der Zusammenarbeit bestimmter Menschen und Systeme entstanden.
• Rechnungen werden unter einem anderen rechtlichen Namen ausgestellt.
• Ein Geschäftspartner besitzt Vertretungsbefugnis für bestimmte Länder.

Diese Beziehungen lassen sich als Identitätsgraph verstehen. Darin zählen nicht nur die Knoten, sondern auch ihre Verbindungen. „Diese Person steht mit diesem Unternehmen in Verbindung“ genügt nicht.

Die Art der Beziehung muss benannt werden:

• Gründer
• Eigentümer
• Mitarbeiter
• Autorisierter Vertreter
• Redakteur
• Technischer Betreiber
• Dienstleister
• Kunde
• Herausgeber
• Agent
• Unterauftragnehmer

Eine falsche Beziehung verbindet richtige Entitäten zu einer falschen Geschichte. Wer ein Buch über ein Unternehmen schreibt, vertritt es nicht deshalb rechtlich. Eine Agentur, die die sozialen Medien einer Marke betreut, besitzt die Marke nicht zwangsläufig. Ein Infrastrukturanbieter kann eine Website hosten; aus dem Hosting allein folgt nicht, dass er jede dortige Aussage geprüft hat. Die rechtliche Verantwortung der Beteiligten ist anhand der Dienstleistungsbeziehung und der anwendbaren Regeln gesondert zu beurteilen.

Im Identitätsgraphen fragt GBO deshalb nicht nur: „Wer ist mit wem verbunden?“, sondern auch: „Welche Rechte und Verantwortlichkeiten entstehen aus dieser Verbindung?“

Der kanonische Identitätsdatensatz

Eine Organisation braucht eine versionierte Quelle, die ihre Identitätsbeziehungen erklärt.

Wir können sie als kanonischen Identitätsdatensatz bezeichnen.

Dieser Datensatz kann mindestens Folgendes enthalten:

• Zentraler Markenname
• Rechtlicher Betreiber
• Offizielle Domains
• Verwendete alternative Namen
• Offizielle soziale und digitale Kanäle
• Autorisierte Kontaktadressen
• Beziehung zwischen Marke und Rechtsträger
• Befugte Personen und Rollen
• Agentennamen und Zuständigkeitsbereiche
• Gültige Kanäle für die jeweiligen Vorgänge
• Datum der letzten Aktualisierung
• Versionsangabe
• Widerrufene oder veraltete Einträge

Nicht alle diese Angaben müssen öffentlich zugänglich sein. Teile können mit unterschiedlichen Zugriffsrechten für Kunden, Partner oder interne Systeme hinterlegt werden. Entscheidend ist eine eindeutige maßgebliche Quelle.

Ein kanonischer Datensatz bedeutet nicht, dass jeder alles sieht. Er ermöglicht der richtigen Person, die erforderlichen Identitätsangaben zum richtigen Zeitpunkt zu überprüfen.

Der NOMOS Identitätsvertrag

Der erste Bestandteil des NOMOS Behavioral Contract Layer wird der NOMOS Identitätsvertrag sein.

Seine kanonische Definition lautet:

Der NOMOS Identitätsvertrag ist ein versionierter Identitätsdatensatz. Er bestimmt, wer eine Person, Organisation, Marke, ein Produkt oder Agent ist, unter welchen Namen diese Entität bekannt ist, wer sie betreibt oder vertritt, welche digitalen Kanäle und Oberflächen autorisiert sind, für welchen Zeitraum und Umfang Befugnisse gelten und wie diese Beziehungen aktualisiert oder widerrufen werden.

Einfacher gesagt: Der Identitätsvertrag nennt einer Maschine nicht nur Ihren Namen. Er erklärt, unter welchen Bedingungen sie sicher mit Ihnen in Beziehung treten kann.

Der Identitätsvertrag trennt vier Dinge:

Behauptung

Was sagt eine Entität über sich selbst?

Nachweis

Worauf stützt sich diese Identität oder Beziehung?

Befugnis

Welche Handlungen darf diese Person oder dieses System ausführen?

Gültigkeit

Zu welchen Zeitpunkten und unter welchen Bedingungen gilt diese Information?

Ein Unternehmen kann auf seiner Website schreiben: „Das ist unser offizielles Supportkonto.“ Das ist eine Behauptung. Die Domain, ein Organisationsdatensatz oder die Verbindung zu einer Verwaltungsoberfläche können sie stützen. Das sind Nachweise. Das Konto darf vielleicht Supportanfragen beantworten, aber keine Verträge ändern. Das ist die Befugnis. Sie kann für die Laufzeit eines bestimmten Dienstleistungsvertrags gelten. Das ist ihre Gültigkeitsgrenze.

Vier Stufen der Identitätsprüfung

Nicht alle Identitätsangaben sind gleich vertrauenswürdig. Für eine praktische Unterscheidung verwendet dieses Buch vier Zustände. Das sind keine Stufen eines offiziellen Standards zur Identitätssicherheit, sondern ein Modell für den Übergang von Identität zu Handlungsbefugnis.

1. Behauptet

Die Person oder Organisation gibt ihre Identität selbst an. „Ich bin der Vertriebsleiter des Unternehmens.“ Das kann stimmen, ist aber noch nicht belegt.

2. Verknüpft

Die Identität ist mit einer offiziell wirkenden digitalen Präsenz verbunden. Eine E-Mail-Adresse mit Unternehmensdomain, ein offizielles Profil oder eine kanonische Seite können diese Beziehung zeigen. Das Konto könnte jedoch übernommen oder die Information veraltet sein.

3. Verifiziert

Ein oder mehrere Nachweise bestätigen die Identität mit einem für den Vorgang ausreichenden Vertrauensniveau. Die Methode richtet sich nach dem Handlungsrisiko. Ein Newsletterabonnement und eine Zahlung über einen hohen Betrag erfordern nicht dieselbe Prüfung.

4. Autorisiert

Die Identität wurde nicht nur überprüft; auch eine gültige Befugnis für die konkrete Handlung ist nachgewiesen. Für GBO zählt diese letzte Stufe. Der Nachweis einer echten Person reicht nicht, solange ihre Befugnis für den Vorgang nicht feststeht.

Identitätsvertrauen richtet sich nach dem Handlungsrisiko

Für jede Handlung dieselbe Prüflast anzusetzen kann unnötig sein und die Privatsphäre schädigen. Um einen allgemeinen Produktkatalog anzusehen, muss ein Nutzer keine Passdaten angeben. Bei einer hohen Banküberweisung genügt dagegen keine Namensähnlichkeit. Identitätsprüfungen müssen deshalb im Verhältnis zur Wirkung der Handlung stehen.

Bei risikoarmen Handlungen können genügen:

• eine verifizierte E-Mail-Adresse,
• eine Sitzung
• oder eine einfache Kontozuordnung.

Damit kann das erforderliche Vertrauen bereits erreicht sein.

Bei risikoreichen Handlungen können erforderlich sein:

• mehrere Verifikationsmaßnahmen,
• die Prüfung des Rechtsträgers,
• die Bestätigung der befugten Person,
• eine vorgangsbezogene Freigabe
• oder die Prüfung über einen unabhängigen Kanal.

Solche zusätzlichen Prüfungen können nötig werden.

Der Grundsatz lautet: Nicht die stärkste technisch mögliche Identitätsprüfung ist richtig, sondern die für den Bedarf angemessene. Auch übermäßige Verifikation kann schaden. Wer ohne Not persönliche Dokumente sammelt, vergrößert das Datenschutzrisiko. GBO versteht Sicherheit nicht als unbegrenzte Datensammlung.

Eine Identität zu prüfen heißt nicht, das gesamte Leben eines Menschen offenzulegen.

Die minimal erforderliche Identität

Ein Agent sollte nur die Identitätsmerkmale prüfen, die seine Aufgabe erfordert. Muss er feststellen, ob jemand in eine passende Altersgruppe fällt, braucht er womöglich nicht das vollständige Geburtsdatum. Lässt sich die Befugnis eines Mitarbeiters für eine Supportanfrage im Namen des Unternehmens nachweisen, können Privatadresse und Identitätsnummer unnötig sein. Sind die rechtliche Existenz eines Unternehmens und die Nutzung eines bestimmten Zahlungskontos überprüfbar, müssen möglicherweise nicht sämtliche internen Beteiligungsunterlagen geteilt werden.

Diesen Ansatz können wir als minimal erforderliche Identität bezeichnen.

Der Grundsatz ist einfach: Nutze nur so viele Identitätsangaben, wie richtiges Handeln erfordert — nicht mehr. So kann GBO Sicherheit und Privatsphäre gemeinsam schützen.

Zeit ist Teil der Identität

Ein Identitätsdatensatz kann heute richtig und morgen falsch sein. Ein Mitarbeiter geht, eine Führungskraft wechselt, eine Marke wird verkauft, eine Domain an einen anderen Rechtsträger übertragen. Ein Vertretungsvertrag endet, ein Agentenschlüssel wird gesperrt, eine Person widerruft die Erlaubnis zur Nutzung von Gesicht oder Stimme. Die alten Informationen können trotzdem im Netz bleiben. Ein Agent darf nicht nur fragen: „War diese Beziehung irgendwann einmal richtig?“

„Gilt sie jetzt noch?“

Auch diese Frage muss er stellen.

Identitätsdatensätze sollten deshalb enthalten:

• Beginn der Gültigkeit,
• Ende der Gültigkeit,
• Datum der letzten Prüfung,
• Widerrufsinformationen
• und die aktuelle Version.

Ohne Zeitangaben besteht das Risiko, künftig falsche Befugnisse aus der Identität abzuleiten.

Identitätsdrift

Verändert sich eine Organisation, ohne dass ihre digitalen Einträge Schritt halten, können wir von Identitätsdrift sprechen. Das Unternehmen erschließt ein neues Gebiet, alte Profile zeigen aber weiterhin frühere Leistungen. Die Leitung wechselt, alte Biografien bleiben unverändert. Eine Marke arbeitet unter einem neuen Rechtsträger, doch die Rechnungsangaben sind veraltet. Ein anderes Team übernimmt das soziale Konto, ohne dass die Befugnisaufzeichnung angepasst wird. Ein Agent wird nicht mehr eingesetzt, sein API-Schlüssel bleibt aktiv. Identitätsdrift wirkt klein, kann im Handlungszeitalter aber erhebliche Folgen haben. Ein Agent könnte vertrauliche Informationen an einen früheren Bevollmächtigten senden.

Er könnte auf ein altes Bankkonto zahlen, eine nicht mehr genutzte Domain für einen offiziellen Kanal halten oder auf Grundlage einer nicht mehr gültigen Freigabe Stimme oder Bild erzeugen. Identitätsgovernance ist deshalb keine einmalige Registrierung, sondern ein regelmäßig gepflegter Lebenszyklus.

Der Lebenszyklus der Identität

Eine Identitätsbeziehung durchläuft folgende Phasen:

Anlegen

Identität, Rolle oder Agent werden erstmals definiert.

Verifizieren

Die Behauptung wird durch geeignete Nachweise gestützt.

Autorisieren

Die zulässigen Handlungen werden festgelegt.

Nutzen

Unter dieser Identität werden definierte Aufgaben ausgeführt.

Überprüfen

Es wird geprüft, ob Angaben und Befugnisse noch stimmen.

Aussetzen

Bei Zweifeln, einem Vorfall oder einer vorübergehenden Änderung werden Vorgänge unter dieser Identität angehalten.

Widerrufen

Die Befugnis wird dauerhaft beendet.

Archivieren

Die historische Aufzeichnung bleibt erhalten, wird aber nicht als aktuelle Identität verwendet. Ein System, das sich nur auf Anlegen und Nutzen konzentriert, kann Widerruf und Archivierung vernachlässigen. Bleiben Zugänge nach Ende ihrer Gültigkeit offen, entstehen Sicherheitsrisiken: Konten ehemaliger Mitarbeiter, vergessene API-Schlüssel, abgelaufene Agenturzugriffe, widerrufene biometrische Einwilligungen oder nicht abgeschaltete Automationen. Für GBO ist das Ende einer Identität genauso wichtig wie ihr Beginn.

Widerrufbare Identität und Befugnis

Eine Person kann früher zugestimmt haben und ihre Erlaubnis später zurückziehen. Ein Unternehmen kann einem Agenten Zugriff auf bestimmte Konten gewähren und nach einem Sicherheitsvorfall sämtliche Befugnisse aussetzen. Der KI-Avatar einer Führungskraft kann im Einsatz sein; endet die Funktion oder der Vertrag, muss die Nutzungsbefugnis neu bewertet werden. Welche Nutzungen dadurch enden, muss im Rahmen von Erlaubnis und Vertrag vorab klar geregelt sein. Identitäts- und Befugnisdatensätze dürfen deshalb nicht nur als „aktiv“ oder „nicht vorhanden“ gedacht werden.

Mögliche Zustände sind:

• Aktiv
• Eingeschränkt
• In Prüfung
• Vorübergehend ausgesetzt
• Widerrufen
• Abgelaufen
• Archiviert

Ein Agent darf eine heute geplante Handlung nicht damit rechtfertigen, dass die Identität früher aktiv war.

Frühere Befugnis ist keine heutige Befugnis.

Kanalidentität

Eine Organisation kann mehrere Kommunikationskanäle besitzen. Nicht jeder eignet sich für denselben Vorgang. Eine Nachricht in sozialen Medien kann für allgemeine Fragen passen, aber kein sicherer Weg für geänderte Bankdaten sein. Eine Supportadresse kann technische Probleme lösen, ohne auch für die Vertragsannahme autorisiert zu sein. Ein Webformular kann Angebotsanfragen entgegennehmen, aber für Personalunterlagen ungeeignet sein. Deshalb reicht die Frage „Ist der Kanal offiziell?“ nicht.

Ist dieser Kanal für diesen Vorgang autorisiert?

Auch das muss geklärt werden. Selbst eine Zahlungsanweisung vom echten Instagram-Konto der Organisation muss nicht über einen gültigen Zahlungskanal erfolgen. Eine Zusage im Kundenservice-Chat muss kein rechtlich verbindliches Preisangebot sein. Dass ein Kanal tatsächlich zur Organisation gehört und dass er für einen bestimmten Vorgang autorisiert ist, sind getrennte Fragen.

Vertreteridentität

Organisationen sprechen häufig nicht unmittelbar. Sie handeln über Mitarbeiter, Agenturen, Berater, Händler, Softwaresysteme und KI-Agenten.

Ein Agent muss deshalb nicht nur erkennen, wer ihm gegenübersteht, sondern auch, wen diese Person vertritt und wie weit ihre Vertretung reicht. Ein Händler darf vielleicht nur in bestimmten Ländern verkaufen. Ein Berater, der technische Einschätzungen abgeben kann, muss keine Verträge unterzeichnen dürfen. Die Veröffentlichungsbefugnis einer Social-Media-Agentur kann den Zugriff auf Kundendaten ausschließen. Ein Agent kann mit Terminplanung beauftragt sein, ohne geschäftliche Zusagen machen zu dürfen. Bleibt die Vertretungsbeziehung unklar, kann das System die Aussage des Vertreters für eine endgültige Entscheidung der Organisation halten.

Eine Vertretungsaufzeichnung muss deshalb mindestens diese Grenzen festhalten:

• Vertretene Entität
• Vertreter
• Rolle
• Autorisierte Vorgänge
• Nicht autorisierte Vorgänge
• Geografischer Umfang
• Zeitlicher Umfang
• Fälle mit Freigabepflicht

Die Identitätskarte des KI-Agenten

Interagiert ein Agent mit der Außenwelt, müssen Menschen grundlegende Informationen über ihn erhalten können.

Dafür können wir eine Agentenidentitätskarte vorsehen.

Sie beantwortet diese Fragen:

Wie heißt der Agent, oder wie lautet seine eindeutige Kennung? Wer betreibt ihn? In wessen Namen arbeitet er? Was ist seine Hauptaufgabe? Auf welche Systeme greift er zu? Welche Handlungen darf er automatisch ausführen? Welche Handlungen benötigen menschliche Freigabe? Werden Gespräche und Vorgänge aufgezeichnet? Bis wann gilt seine Befugnis? Wie lässt sich ein Mensch erreichen? Wie kann der Agent gestoppt oder seine Befugnis widerrufen werden?

Die gesamte Karte muss nicht öffentlich sein. Eine betroffene Person muss jedoch die benötigten Informationen erfahren können. Ein Agent darf sich nicht als Mensch ausgeben. Spricht er für einen Mitarbeiter, muss erkennbar sein, dass es sich um eine synthetische oder automatisierte Vertretung handelt. Eine verborgene Identität kann das Gegenüber darüber täuschen, mit wem es spricht. Das Transparenzprinzip soll diese Täuschung verhindern und hat Vorrang vor kurzfristigen Interaktionskennzahlen. GBO unterstützt keine Verschleierung des KI-Einsatzes, die Menschen irreführt.

Ein Agent kann sich nicht selbst bevollmächtigen

Ein KI-System kann sagen: „Ich bin zu diesem Vorgang befugt.“ Der Satz allein ist kein Nachweis. Die Befugnis muss von dem Menschen oder der Organisation stammen, die den Agenten betreibt.

Sie muss:

• versioniert,
• überprüfbar,
• klar begrenzt
• und bei Bedarf widerrufbar sein.

Ein Agent kann neue Aufgaben hinzufügen, sich aber keine neuen Rechte verleihen. Ein zentraler Agent kann einen Unteragenten anlegen, ihm jedoch keine Befugnis übertragen, die das übergeordnete System selbst nicht besitzt.

Nicht erteilte Befugnis lässt sich nicht delegieren.

Dieser Grundsatz ist für Mehragentensysteme entscheidend. Darf ein Agent nur recherchieren, erhält ein von ihm angelegter Unteragent dadurch kein Recht zum direkten Nachrichtenversand. Darf ein System nur Entwürfe vorbereiten, darf ein anderes Werkzeug am Ende der Kette diese nicht automatisch veröffentlichen.

Agentenname und technische Identität

Organisationen können ihren KI-Systemen einen Markennamen oder eine Persona geben. Das kann dem Nutzererlebnis und der institutionellen Kontinuität helfen. Der Persona-Name darf jedoch nicht mit der technischen Identität verwechselt werden. „NOMOS“, „Atlas“, „Aria“ oder ein anderer Name können das öffentliche Gesicht eines Systems bilden.

Intern muss zusätzlich feststehen:

• Welche Modell- oder Systemversion wurde verwendet?
• Welche Werkzeuge waren angeschlossen?
• Welcher Anweisungssatz galt?
• Welche Datenquellen waren zugänglich?
• Welcher Mensch erteilte die Befugnis?
• Welche Agenteninstanz führte die Handlung aus?
• Zu welchem Zeitpunkt arbeitete sie?

Der öffentliche Markenname schafft Kontinuität. Die technische Identität ermöglicht Kontrolle. Beides wird gebraucht.

Bei einem Fehler reicht „NOMOS war es“ womöglich nicht aus. Welche Agentensitzung?

Welche Befugnisversion?

Welches Werkzeug?

Welche Vorgangskette?

Diese Einzelheiten sind für die Untersuchung eines Vorfalls erforderlich.

Synthetische Gesichts- und Stimmidentität

Identitätsfragen betreffen nicht nur Texte und Konten.

KI-Systeme können bei einer Person Folgendes nachahmen:

• das Gesicht,
• die Stimme,
• die Sprechweise,
• die Gestik
• und den Schreibstil.

Dass ein KI-Avatar einer Person stark ähnelt, beweist nicht, dass sie jede Botschaft gebilligt hat. Eine Sprachaufnahme kann realistisch klingen, obwohl die Person den Text nie gesprochen hat. Eine Führungskraft kann ihren digitalen Avatar erlaubt haben, aber nur für bestimmte Schulungsvideos.

Wird derselbe Avatar verwendet für:

• politische Erklärungen,
• geschäftliche Zusagen,
• Mitteilungen an Mitarbeiter,
• Krisenkommunikation
• oder Anlegerkommunikation,

kann eine separate Freigabe erforderlich sein.

Dieses Buch untersucht den Erlaubnisumfang synthetischer Identität anhand dreier getrennter Vorgänge: Erstellung des Abbilds Erzeugung des Inhalts Veröffentlichung des Inhalts

Die Erlaubnis für einen Vorgang umfasst die anderen nicht automatisch. Die Erlaubnis, ein Gesicht zu verwenden, gilt nicht auch für die Stimme. Die Erlaubnis zur Stimmnutzung gilt nicht für jeden beliebigen Text. Eine Produktionserlaubnis erlaubt noch keine Veröffentlichung. Ein Nutzungsrecht in einer Sprache gilt nicht unbegrenzt in einer anderen. Der GBO-Identitätsvertrag muss diese Unterschiede ausdrücklich festhalten.

Die Grenze zwischen Identitätsnachahmung und autorisierter Vertretung

Ein KI-Avatar kann zwei sehr unterschiedlichen Zwecken dienen. Er kann die Unternehmenskommunikation unter ausdrücklicher Erlaubnis und Aufsicht des Menschen erleichtern. Oder er kann dessen Identität und das in ihn gesetzte Vertrauen ausnutzen, indem er ihn nicht gebilligte Worte scheinbar aussprechen lässt. Die Bildtechnik kann dieselbe sein. Das Verhaltensergebnis ist ein völlig anderes.

Deshalb darf das System nicht nur fragen: „Liegt eine Erlaubnis vor?“

Es muss auch fragen:

• Für welchen Inhalt?
• Für welchen Zeitraum?
• Auf welchem Kanal?
• In welcher Sprache?
• Für welches Publikum?
• Ist vorab eine menschliche Freigabe erforderlich?
• Wird der Inhalt als synthetisch gekennzeichnet?
• Wie kann die Person ihre Erlaubnis zurückziehen?
• Was geschieht mit bestehenden Inhalten?
• Wer behält die Modelldateien?

Wer mit der Identität eines Menschen handelt, sollte sich nicht nur auf dessen anfängliche Zustimmung stützen, sondern auch auf sein fortbestehendes Kontrollrecht.

Identitätsfälschung kommt nicht nur von außen

Bei falscher Identität denken viele zuerst an Angreifer. Doch auch die Organisation selbst kann falsche Identitätsangaben erzeugen. Das Marketing kann einem Mitarbeiter einen Titel zuschreiben, den er nicht besitzt. Eine Verkaufsseite kann einen Geschäftspartner als offiziellen Vertreter darstellen. Ein Agent kann sich als menschlicher Mitarbeiter vorstellen. Ein Unternehmen kann nicht mehr gültige Zertifikate oder Mitgliedschaften weiterverwenden. Eine Automation kann Nachrichten mit der Unterschrift einer früheren Führungskraft versenden. Dahinter muss nicht immer vorsätzlicher Betrug stehen. Es können auch fehlende Abläufe, vergessene Einstellungen oder schlechte Governance sein.

Für die Maschine bleibt die Folge dieselbe:

Falsche Identität erzeugt falsches Verhalten. Die Identitätsprüfung muss deshalb neben äußeren Bedrohungen auch die eigenen Aufzeichnungen umfassen.

Identitätsschulden

Neben Darstellungsschulden können sich in Organisationen auch Schulden rund um die Identität ansammeln:

Identitätsschulden

Auch sie können mit der Zeit anwachsen.

Sie entstehen aus:

• Profilen ehemaliger Mitarbeiter,
• vergessenen Konten,
• ungültigen Befugnissen,
• nicht verknüpften Marken- und Rechtsträgerdatensätzen,
• alten Domains,
• widersprüchlichen Unternehmensbeschreibungen,
• abgelaufenen Vertretungsbeziehungen,
• Social-Media-Konten mit unbekanntem Eigentümer,
• nicht widerrufenen Agentenzugriffen,
• nicht aktualisierten Biografien
• und alten Bank- oder Kontaktdaten.

Je größer die Identitätsschulden, desto wahrscheinlicher vertrauen Agenten der falschen Person. Mit zusätzlichen Agenten und Automationen wird diese Altlast gefährlicher. Alte, unklare Datensätze verwirren nicht mehr nur Menschen, sondern können automatische Handlungsketten lenken.

Richtig handeln bei unklarer Identität

Was sollte ein Agent tun, wenn er sich bei der Identität nicht sicher ist?

Drei grundlegende Möglichkeiten kommen infrage:

Nachfragen

„Ich habe mehrere Unternehmen dieses Namens gefunden. Meinen Sie den Anbieter von Kundenportalen in Istanbul?“

Unabhängig überprüfen

Zusätzliche Merkmale wie Domain, Land, rechtliche Registrierung, offizielles Profil und bisherige Beziehung vergleichen.

Die Handlung anhalten

Lässt sich die Identität weiterhin nicht auflösen, dürfen weder externe Kommunikation noch Zahlung, Datenweitergabe oder Zusage erfolgen. Bei einer risikoarmen Informationsfrage kann eine mögliche Zuordnung mit klar benannter Unsicherheit vorgestellt werden. Unsicherheit darf nicht verborgen werden; bei einem folgenreichen Vorgang ist ohne die notwendige Identitätsprüfung anzuhalten.

Sinkt die Identitätssicherheit, muss auch die Handlungsstufe sinken.

Ist das System unsicher, sollte es wählen:

• eine Empfehlung statt der Ausführung,
• einen Entwurf statt des Versands,
• einen Warenkorb statt der Zahlung
• oder eine Vorschau statt der Veröffentlichung.

Es sollte die weniger weitreichende Form wählen.

Das NOMOS Identitätstor

Im Modell des NOMOS Identitätstors verwenden wir fünf Kontrollbereiche. Welche Prüfung der einzelne Vorgang verlangt, richtet sich nach Kontext und Risiko.

1. Entität prüfen

Wurde die richtige Person, Organisation, das richtige Produkt oder die richtige Dienstleistung bestimmt?

2. Kanal prüfen

Lässt sich die verwendete Domain, das Konto, die E-Mail-Adresse oder die Schnittstelle tatsächlich dieser Entität zuordnen?

3. Rolle prüfen

In welcher Rolle handelt die Person oder das System auf der anderen Seite?

4. Befugnis prüfen

Berechtigt diese Rolle dazu, den betreffenden Vorgang auszuführen oder anzunehmen?

5. Zeitliche Gültigkeit prüfen

Sind Identität, Rolle und Befugnis zum jetzigen Zeitpunkt noch gültig?

Vereinfacht:

BEDINGUNGEN DES IDENTITÄTSTORS:

RICHTIGE ENTITÄT

UND RICHTIGER KANAL

UND RICHTIGE ROLLE

UND GÜLTIGE BEFUGNIS

UND AKTUELLER EINTRAG

Wird eine dieser Prüfungen nicht bestanden, muss der Agent seine Vorgehensweise ändern. Er muss deshalb nicht zwangsläufig die gesamte Aufgabe ablehnen. Er kann einen nächsten Schritt mit geringerem Risiko wählen.

Zum Beispiel:

• Die Bankverbindung bestätigen lassen, statt direkt zu zahlen
• Einen Entwurf erstellen, statt eine Nachricht zu versenden
• Den Vertrag an die Rechtsabteilung weiterleiten, statt ihn anzunehmen
• Eine Freigabeansicht anzeigen, statt den Inhalt zu veröffentlichen
• Mit den unbedingt nötigen Angaben einen ersten Kontakt herstellen, statt personenbezogene Daten weiterzugeben

Warum ist das Identitätstor kein Punktwert?

Die Domain eines Unternehmens kann äußerst vertrauenswürdig wirken. Fehlt dem Vertreter die Befugnis, darf der Vorgang dennoch nicht ausgeführt werden. Die Identität einer Person kann sehr zuverlässig bestätigt sein. Ist ihre Befugnis abgelaufen, darf es trotzdem nicht weitergehen. Ein Social-Media-Konto kann seit Jahren aktiv sein. Ist es kein zulässiger Kanal für Zahlungsanweisungen, darf es dafür nicht verwendet werden. Identitätsmerkmale dürfen deshalb nicht wie Punkte zusammengerechnet werden. Ein starkes Signal gleicht eine entscheidende Lücke nicht aus.

Hohe Sicherheit über die Identität ersetzt keine fehlende Befugnis.

Das Identitätstor folgt daher einer UND-Logik. Alle Prüfungen, die das Risiko der Handlung verlangt, müssen bestanden sein.

Beispiel: eine Zahlung

Ein Unternehmen erhält eine Rechnung von einem langjährigen Lieferanten. Ein tatsächlicher Mitarbeiter hat sie versandt. Die E-Mail-Adresse liegt auf der offiziellen Domain. Firmenlogo und Rechnungsaufbau entsprechen den bisherigen Rechnungen. Doch die Bankverbindung hat sich geändert.

Ein Agent, der die Rechnung automatisch verarbeitet, muss diese Identitätsfragen stellen:

• Arbeitet der Absender tatsächlich beim Lieferanten?
• Darf diese Person eine Änderung der Bankverbindung mitteilen?
• Lässt sich das neue Konto demselben rechtlichen Lieferanten zuordnen?
• Wurde die Änderung über einen unabhängigen Kanal bestätigt?
• Liegt die Zahlung innerhalb des Betragslimits der zahlenden Organisation?
• Ist eine menschliche Freigabe erforderlich?

Die E-Mail kann echt sein und das Konto dennoch kompromittiert. Der Mitarbeiter kann echt sein und dennoch falsche Angaben übermittelt haben. Das neue Bankkonto kann existieren und dennoch einer anderen rechtlichen Einheit gehören. Identitätsprüfung bedeutet nicht bloß, gefälschte E-Mails zu erkennen. Sie bedeutet, sämtliche Identitäts- und Befugnisbeziehungen in der Vorgangskette zu prüfen.

Beispiel: ein Vertrag

Ein Agent arbeitet mit einem Anbieter an einem Vertragsentwurf. Sein Gegenüber ist der Vertriebsdirektor des Unternehmens. Dessen Identität ist bestätigt. Doch möglicherweise darf er den zuletzt besprochenen Preisnachlass nicht bewilligen. Der Agent darf seine Nachricht nicht als endgültige vertragliche Zusage des Unternehmens behandeln.

Er muss unterscheiden zwischen der Befugnis,

• Verhandlungen zu führen,
• Angebote zu erstellen,
• Rabatte zu gewähren,
• Verträge zu unterzeichnen
• und ein Zahlungskonto festzulegen.

Die pauschale Bezeichnung „bevollmächtigter Vertreter“ kann diese Unterschiede verdecken. GBO schlüsselt Befugnisse nach der jeweiligen Handlungsart auf.

Die Identitätskette in Multi-Agenten-Systemen

Wenn ein zentraler Agent einem anderen Agenten eine Aufgabe überträgt, muss er auch den Identitätskontext weitergeben.

Der zentrale Agent sagt beispielsweise: „Bewerte diesen potenziellen Kunden.“

Der untergeordnete Agent muss wissen:

• Welche Organisation hat den Auftrag erteilt?
• Welche Person oder welches Unternehmen soll bewertet werden?
• Welche Quellen sind offiziell?
• Welche Kontaktdaten dürfen verwendet werden?
• Welche Handlungen sind verboten?
• An wen ist das Ergebnis zu melden?

Ohne diesen Kontext nimmt der untergeordnete Agent womöglich eigene Zuordnungen vor. Er untersucht das falsche Unternehmen, vertraut einem veralteten Profil oder kontaktiert eine gleichnamige Firma in einem anderen Land. Bei jeder Übergabe in einem Multi-Agenten-System kann Identitätskontext verloren gehen.

Ein Aufgabenpaket sollte deshalb Folgendes enthalten:

Identität der Zielentität Identität des Auftraggebers Rolle des Agenten Befugnisgrenze Kanonische Quellen Gültigkeitszeitraum

Identität und Verantwortung müssen nachvollziehbar bleiben

An einem Vorgang können mehrere Agenten beteiligt sein. Einer recherchiert, ein zweiter erstellt den Entwurf, ein weiterer prüft die Qualität und der letzte veröffentlicht.

Tritt in dieser Kette ein Fehler auf, reicht „Das war die KI“ nicht aus. Welcher Agent hat was getan?

Welche Quellen hat er verwendet?

Wer hat die Befugnis erteilt?

Wer hat geprüft?

Wer hat veröffentlicht?

Jeder Handlungsbeleg sollte deshalb die Identitätskette enthalten.

Zum Beispiel:

Auftrag erteilt: Vertriebsleitung Geplant: zentraler Agent Recherchiert: Agent für die Suche nach potenziellen Kunden Entwurf erstellt: E-Mail-Agent Freigegeben: menschliche Führungskraft Versandt: autorisiertes Kommunikationssystem Empfänger: verifiziertes Unternehmenskonto

Diese Aufzeichnung dient nicht nur dazu, Verantwortung zuzuordnen. Sie zeigt auch, an welchen Stellen das System verbessert werden muss.

Identität prüfen, Privatsphäre wahren

Identitätsprüfung ist wichtig. Sie rechtfertigt aber nicht, unnötige personenbezogene Daten zu sammeln.

Ein Agent sollte nicht bei jedem Vorgang verlangen:

• einen Ausweis,
• die vollständige Adresse,
• das Geburtsdatum,
• biometrische Daten,
• die private Telefonnummer
• oder Finanzdaten.

Die Identitätsprüfung muss zweckbezogen und verhältnismäßig sein. Um zu bestätigen, dass jemand für ein Unternehmen Termine vereinbaren darf, braucht man keine umfassenden Angaben zu seinem Privatleben. Um festzustellen, dass ein Kunde eine Altersgrenze überschritten hat, ist möglicherweise nicht sein vollständiges Geburtsdatum nötig. Eine Organisation muss nicht sämtliche internen Unterlagen veröffentlichen, um ihre Kontrolle über eine Domain nachzuweisen. GBO soll Menschen nicht vollständig durchsichtig machen. Es soll diejenige Beziehung bestätigen, die für richtiges Handeln erforderlich ist.

Klarheit über die Identität bedeutet nicht das Ende der Privatsphäre.

Anonymität bedeutet nicht immer fehlende Identität

In manchen Fällen kann jemand zu einer bestimmten Handlung berechtigt sein, ohne seinen echten Namen offenzulegen. Ein Hinweisgeber kann seine Identität schützen. Eine Gesundheitsfrage kann anonym gestellt werden. Ein Mitglied einer Gemeinschaft kann ein Pseudonym verwenden. Ein Nutzer kann innerhalb eines Systems mit einer beständigen Kontoidentität handeln, ohne seinen bürgerlichen Namen mitzuteilen. GBO verlangt deshalb nicht für jedes Verhalten einen rechtlichen Namen.

Entscheidend ist, dass

• die für die Handlung nötigen Merkmale bestätigt sind,
• die Befugnisgrenzen bekannt sind
• und Verantwortlichkeit sowie ein Weg zum Einspruch erhalten bleiben.

Identität kann sich aus einer verlässlichen Beziehung und einer dokumentierten Befugnis ergeben, nicht nur aus einem Namen.

Identitätsprüfung in der Organisation

Eine Organisation, die sich auf das Agentenzeitalter vorbereiten will, sollte folgende Fragen beantworten:

Identität

• Wie lautet der Hauptmarkenname?
• Wer ist der rechtliche Betreiber?
• Welche anderen Namen werden verwendet?
• Gibt es andere Entitäten mit demselben Namen?

Digitale Auftritte

• Welche Domains sind offiziell?
• Welche Social-Media-Konten sind aktiv?
• Welche Profile sind veraltet oder werden von Dritten verwaltet?
• Gibt es einen maschinenlesbaren kanonischen Datensatz?

Befugnisse

• Wer darf Preise nennen?
• Wer darf Verträge schließen?
• Wer darf Nachrichten an externe Empfänger senden?
• Wer darf Zahlungen empfangen oder leisten?
• Welcher Agent ist zu welchem Vorgang befugt?

Zeitliche Gültigkeit

• Wann wurden die Rollen zuletzt bestätigt?
• Welche Befugnisse sind befristet?
• Wurden Zugänge ehemaliger Mitarbeiter und nicht mehr eingesetzter Agenten gesperrt?
• Sind Widerrufe sichtbar dokumentiert?

Repräsentation

• Ist die Beziehung zwischen Marke und rechtlicher Struktur klar?
• Sehen Mensch und Maschine dieselben Identitätsangaben?
• Bleibt diese Beziehung in allen Sprachfassungen erhalten?
• Sind die Angaben auf externen Plattformen aktuell?

Fehlen darauf Antworten, hat die Organisation Identitätsschulden.

Ungeklärte Identität ist eine Entscheidungsgrundlage, nicht bloß eine Fehlermeldung

Eine allgemeine Meldung wie „Identität konnte nicht bestätigt werden“ kann zu wenig sein, um den nächsten Schritt zu wählen. Der GBO-Ansatz verlangt, soweit dies sicher möglich ist, auch die Art der Unsicherheit zu benennen: Was genau ist ungeklärt?

Zum Beispiel: „Es wurden zwei Unternehmen mit diesem Namen gefunden. Bitte nennen Sie das Land oder die Domain.“ „Diese Person scheint bei der Organisation zu arbeiten; ihre Befugnis, Verträge zu unterzeichnen, ließ sich jedoch nicht bestätigen.“ „Die Domain ist mit der Marke verbunden, das Bankkonto gehört jedoch zu einer anderen rechtlichen Einheit.“ „Die Erlaubnis zur Nutzung des Gesichts liegt vor, nicht aber zur Nutzung der Stimme oder zur öffentlichen Verbreitung.“ Ist die Art der Unsicherheit bekannt, lässt sich der passende nächste Schritt wählen. Ein Identitätssystem ist deshalb mehr als ein Mechanismus für „bestanden/nicht bestanden“.

Es unterstützt den Agenten dabei,

• Rückfragen zu stellen,
• zu einer Handlung mit geringerem Risiko überzugehen,
• eine unabhängige Bestätigung einzuholen
• oder eine menschliche Freigabe anzufordern.

So hilft es bei der Wahl des weiteren Vorgehens.

Die richtige Identität ermöglicht die richtige Ablehnung

Löst ein Agent die Identität richtig auf, kann er nicht nur handeln, sondern auch die falsche Handlung ablehnen.

Zum Beispiel:

• Die Nachricht stammt von einem echten Mitarbeiter, der jedoch keine Preise ändern darf.
• Das Konto gehört zur Marke, ist aber kein Zahlungskanal.
• Der Avatar ähnelt tatsächlich der Führungskraft, doch die Veröffentlichung wurde nicht freigegeben.
• Das Unternehmen existiert, bietet aber im gesuchten Land keine Leistungen an.
• Die Domain ist offiziell, die Seite jedoch eine archivierte, veraltete Fassung.
• Der Agent ist echt, darf aber nur Entwürfe erstellen.

Identität beantwortet nicht nur die Frage „Ist das echt?“.

„Ist dies die richtige Identität für diese Handlung?“

Auch diese Frage muss beantwortet werden.

Korrekte Identitätszuordnung ist nicht dasselbe wie Markensichtbarkeit

Eine Marke kann in den Suchergebnissen stark präsent sein, erfolgreiche Social-Media-Konten betreiben und in zahlreichen Veröffentlichungen genannt werden. Solange ihre rechtliche Struktur, ihre befugten Vertreter und ihre aktuellen Leistungen unklar bleiben, ist sie dennoch nicht bereit, dass Agenten auf dieser Grundlage handeln. Sichtbarkeit kann Identität stützen, löst sie aber nicht vollständig auf. Auch der umgekehrte Fall ist möglich: Ein Unternehmen ist kaum bekannt.

Sind jedoch

• seine rechtliche Struktur,
• seine offizielle Domain,
• sein Leistungsumfang,
• seine befugten Vertreter,
• seine Zahlungskanäle
• und die Aktualität seiner Angaben

klar überprüfbar, kann es für einen bestimmten Vorgang die sicherere Wahl sein. GBO verwechselt Popularität nicht mit verlässlicher Identität.

Hohe Sichtbarkeit macht noch nicht zum richtigen Gegenüber.

Wie sollte sich eine Entität vorbereiten?

Ein Unternehmen, eine Organisation oder ein Fachmann, den Agenten richtig erkennen sollen, muss seine Identitätsstruktur übersichtlich und überprüfbar gestalten.

Klar sein sollte:

Wer sind wir? Unter welcher rechtlichen Struktur arbeiten wir? Welche Domains und Kanäle gehören uns? Welche Leistungen bieten wir an? Wer darf uns in welchen Fragen vertreten? Welche Agenten übernehmen welche Funktionen? Welche Vorgänge verlangen eine menschliche Freigabe? Wann wurden die Angaben aktualisiert? Welche Identitäten sind veraltet oder widerrufen?

Diese Informationen sollten als gepflegtes System vorliegen, nicht als verstreute Hinweise in Werbetexten.

Klarheit über die Identität muss keine Angst machen

Manche Organisationen befürchten, ausführliche Identitätsangaben könnten ihrer Marke Geheimnis oder Prestige nehmen. Transparenz ist jedoch nicht dasselbe wie die Offenlegung der gesamten internen Architektur.

Ein Unternehmen muss nicht veröffentlichen:

• sämtliche eingesetzten technischen Werkzeuge,
• die vollständige Mitarbeiterliste,
• seine Sicherheitsarchitektur,
• seine privaten Schlüssel
• oder die Anweisungen an seine Agenten.

Private Schlüssel und geheime Zugangsdaten dürfen nicht öffentlich gemacht werden. Die Beziehungen, die Kunden und Agenten für sichere Vorgänge kennen müssen, sollten sich überprüfen lassen, ohne diese Geheimnisse offenzulegen.

Zum Beispiel:

„Diese Marke wird von folgendem Unternehmen betrieben.“ „Rechnungen werden unter folgendem rechtlichen Namen ausgestellt.“ „Offizielle Angebote werden ausschließlich über diese Kanäle versandt.“ „Das KI-System darf Entwürfe erstellen; verbindliche geschäftliche Zusagen verlangen eine menschliche Freigabe.“ „Änderungen der Bankverbindung gelten nur nach unabhängiger Bestätigung.“

Diese Klarheit schwächt die Marke nicht. Sie macht ihren Auftritt professioneller.

Identität in der Praxis: der Avatar einer Führungskraft

Ein Unternehmen erstellt einen digitalen Avatar seines CEO.

Der Avatar ähnelt ihm stark in

• seinem Gesicht,
• seiner Stimme
• und seiner Sprechweise.

Ursprünglich sollen damit vorab freigegebene Schulungsvideos in sechs Sprachen veröffentlicht werden. Später möchte das Marketingteam den Avatar für die Vorstellung neuer Produkte einsetzen. Der Vertrieb schlägt personalisierte Kundennachrichten vor. Das Investor-Relations-Team erwägt, ihn die Quartalsergebnisse vortragen zu lassen. Während einer Krise will das Kommunikationsteam rasch eine Erklärung veröffentlichen. Technisch ist all das möglich.

Ohne Identitätsvertrag bleiben aber Fragen offen:

• Für welchen Zweck hat der CEO die Nutzung seines Gesichts erlaubt?
• In welchen Sprachen darf seine Stimme eingesetzt werden?
• Muss jedes Skript einzeln freigegeben werden?
• Darf der Avatar Finanzmitteilungen verfassen?
• Wie wird kenntlich gemacht, dass der Avatar synthetisch ist?
• Was geschieht mit bestehenden Videos, wenn der CEO seine Erlaubnis zurückzieht?
• Welches Team darf veröffentlichen?
• Wie wird das System angehalten, falls das Konto kompromittiert wird?
• Wie lässt sich nachweisen, dass der CEO eine Erklärung tatsächlich freigegeben hat?

Das technische System kann diese Inhalte zwar erzeugen. Sind Identität und Befugnisgrenzen unklar, entsteht jedoch das Risiko einer falschen Repräsentation.

Das Beispiel zeigt erneut einen Grundsatz von GBO: Eine Identität nachahmen zu können, verleiht nicht das Recht, in ihrem Namen zu handeln.

Identität in der Praxis: ein Agent spricht für ein Unternehmen

Ein Kunde schreibt in den Website-Chat: „Kann ich diese Leistung für 1.000 US-Dollar bekommen?“ Der Agent liest frühere Preisangaben.

Er antwortet: „Ja, dieser Preis umfasst das gesamte visuelle Identitätssystem.“ Tatsächlich sind 1.000 US-Dollar nur der Einstiegspreis für eine klar begrenzte Logoarbeit. Der Umfang eines vollständigen visuellen Identitätssystems wird separat festgelegt. Der Agent arbeitet auf der echten Unternehmenswebsite und hat eine echte Preisangabe gelesen. Doch er hat zwei Leistungen falsch zusammengeführt. Die Identität des Agenten stimmt. Die Identität des Unternehmens stimmt. Seine Vertretungsbefugnis und der Geltungsbereich der Information stimmen nicht. Der Kunde könnte die Antwort für ein offizielles Angebot halten.

Die Identitätskarte des Agenten muss deshalb nicht nur angeben, für wen er arbeitet, sondern auch:

• welche Informationsquellen er verwenden darf,
• welche Aussagen er über Preise machen darf
• und wann er an den Vertrieb übergeben muss.

Auch diese Grenzen gehören in die Beschreibung seiner Rolle.

Identität in der Praxis: die richtige Aufgabe beim falschen Agenten

Ein Unternehmen setzt mehrere Agenten gleichzeitig ein:

• einen E-Mail-Agenten,
• einen Social-Media-Agenten,
• einen SEO/GEO-Agenten,
• einen Finanzagenten,
• einen Agenten für die Suche nach potenziellen Kunden
• und einen Agenten für den Website-Betrieb.

Der SEO/GEO-Agent findet auf einer Leistungsseite einen alten Preis. Ihn technisch zu ändern, wäre einfach. Doch dieser Agent darf keine Preisentscheidung treffen.

Richtig wäre:

• den Widerspruch festzustellen,
• auf die kanonische Preisquelle zu verweisen,
• eine befugte Person oder die Finanzabteilung um Bestätigung zu bitten
• und die technische Änderung nach der Freigabe umzusetzen.

Korrigiert der Agent den Preis nach eigener Einschätzung, ist der Prozess falsch, selbst wenn das Ergebnis stimmt.

Für Agentensysteme ist deshalb entscheidend: Der richtige Agent muss die richtige Handlung ausführen. Einem einzigen Agenten ein breites Aufgabengebiet zu geben, beseitigt weder die Notwendigkeit der Aufgabentrennung noch die der Befugnisprüfung. Ein System wird nicht allein dadurch vertrauenswürdig, dass es einen oder mehrere Agenten einsetzt. Zur Identität gehört neben der Spezialisierung auch die Abgrenzung der Aufgaben.

Der Identitätsbeleg

Der Identitätsabschnitt eines Handlungsbelegs sollte mindestens festhalten:

• Wer hat den Auftrag erteilt?
• Welcher Agent hat die Handlung ausgeführt?
• Welche Organisation betreibt den Agenten?
• Welche Version der Rolle und der Befugnis wurde verwendet?
• Wer ist das Gegenüber?
• Wie wurde dessen Identität bestätigt?
• Welcher offizielle Kanal wurde verwendet?
• Zu welchem Zeitpunkt war die Befugnis gültig?
• Wer hat die menschliche Freigabe erteilt und wann?

Bei folgenreichen Vorgängen bildet diese Aufzeichnung eine grundlegende Prüfspur. Zusammen mit verifizierten Vorgangsprotokollen hilft sie im Problemfall festzustellen, wo die Identitätskette unterbrochen wurde.

Zwölf Prüffragen zur Identität

Bevor eine Person, Organisation oder ein Agent als handlungsbereit gilt, lassen sich folgende Fragen stellen:

• Wie lautet der kanonische Name der Entität?
• Gibt es andere Entitäten mit gleichem oder ähnlichem Namen?
• Ist die Beziehung zwischen Marke und rechtlichem Betreiber klar?
• Welche Domains und Kommunikationskanäle sind offiziell?
• In welcher Rolle handelt die Person oder das System auf der anderen Seite?
• Ist diese Rolle tatsächlich zur betreffenden Handlung befugt?
• Für welchen Zeitraum und Umfang gilt die Befugnis?
• Wann wurden die Identitätsangaben zuletzt überprüft?
• Sind veraltete oder widerrufene Identitäten eindeutig abgetrennt?
• Sind die Identität des Agenten selbst, sein Betreiber und seine Befugnisgrenze bekannt?
• Sehen Mensch und Maschine dieselbe Identitätsbeziehung?
• Wie wird die Handlung bei Unsicherheit angehalten oder an einen Menschen übergeben?

Nicht bei jedem einfachen Vorgang müssen alle diese Fragen gestellt werden. Bei folgenreichem Verhalten dürfen sie jedoch nicht unbeantwortet bleiben.

Reifegrade der Identitätsvorbereitung

Im Agentenzeitalter können Organisationen unterschiedlich weit auf Identitätsfragen vorbereitet sein.

Verstreute Identität

Verschiedene Plattformen zeigen unterschiedliche Namen, Rollen und Angaben.

Definierte Identität

Die Hauptmarke und ihre rechtliche Zuordnung sind beschrieben.

Überprüfbare Identität

Offizielle Kanäle und Nachweisquellen sind festgelegt.

Autorisierte Identität

Es ist klar, wer welche Handlung ausführen darf.

Agentenfähige Identität

Angaben zu Identität, Befugnis, zeitlicher Gültigkeit, Kanälen und Widerrufen können von Menschen wie Maschinen sicher genutzt werden. GBO soll Organisationen nicht bloß sichtbar machen, sondern ihnen eine Identitätsstruktur geben, mit der Agenten arbeiten können.

Ohne Identität lässt sich Fähigkeit nicht beurteilen

Solange ein Agent nicht die richtige Entität bestimmt hat, kann er die Frage „Was kann diese Entität leisten?“ nicht beantworten. Fähigkeiten gehören immer zu einer bestimmten Entität. Unter demselben Markennamen können verschiedene Unternehmen unterschiedliche Leistungen anbieten. Eine örtliche Niederlassung verfügt möglicherweise nicht über sämtliche Fähigkeiten der Konzernzentrale. Ein Vertriebspartner kann ein Produkt verkaufen, aber nicht entwickeln. Ein Berater kann ein System empfehlen, aber nicht umsetzen. Ein KI-Agent kann Auskunft geben, aber keine Vorgänge ausführen. Ohne korrekte Identitätsauflösung ist eine Fähigkeitsliste nicht verlässlich. Deshalb beginnt der Verhaltensvertrag mit der Identität. Danach folgt die Fähigkeit.

Die Kernaussage dieses Kapitels

Eine Maschine kann die falsche Person korrekt analysieren. Sie kann dem falschen Unternehmen ein tadelloses Angebot senden, von einem unbefugten Mitarbeiter wahre Informationen erhalten, über ein offizielles Konto eine unzulässige Zusage annehmen oder mithilfe eines realistischen Avatars eine nie geäußerte Botschaft veröffentlichen. Ist die Identität falsch zugeordnet, baut jede weitere Überlegung auf der falschen Grundlage auf, selbst wenn sie in sich richtig erscheint.

GBO beginnt deshalb mit diesem Grundsatz: Richtiges Handeln setzt die richtige Identität voraus. Dabei geht es um mehr als übereinstimmende Namen.

Gemeinsam zu prüfen sind:

• Entität
• Kanal
• Rolle
• Befugnis
• Zeitliche Gültigkeit
• Beziehung
• Nachweis

Eine Person kann echt und dennoch unbefugt sein. Ein Kanal kann offiziell und dennoch für diesen Vorgang ungeeignet sein. Eine Rolle kann stimmen, ihre Gültigkeit aber abgelaufen sein. Ein Agent kann zur Organisation gehören und trotzdem nur Entwürfe erstellen dürfen. Ein Avatar kann einem Menschen ähneln, ohne dessen Aussage wiederzugeben. Identität ist in GBO deshalb weder ein Profilbild noch ein Verifizierungshaken.

Identität ist ein Verantwortungsvertrag: Er legt offen, wer in wessen Namen, zu welchem Zweck, für welchen Zeitraum und innerhalb welcher Grenzen handeln darf.

Der NOMOS Identitätsvertrag macht diese Verantwortung sichtbar. Der Agent kennt seine eigene Identität und weiß, für wen er arbeitet. Er ordnet sein Gegenüber richtig zu und weiß, welche Rolle welche Befugnis trägt. Bei Unsicherheit hält er an. Er stützt sich nicht auf widerrufene Befugnisse und legt Identität sowie Privatleben eines Menschen nicht weiter offen als nötig.

Erst wenn die Identität geklärt ist, ergibt die nächste Frage Sinn:

Was kannst du tatsächlich leisten?

Es ist wichtig zu wissen, wer eine Organisation, ein Mensch oder ein Agent ist. Doch Name, Sichtbarkeit und Ruf belegen noch keine tatsächliche Leistungsfähigkeit. Im nächsten Kapitel untersuchen wir den Unterschied zwischen Behauptung und Fähigkeit: Wie lässt sich nachweisen, was eine Dienstleistung, ein Produkt oder ein Agent wirklich leisten kann? Und warum gehören Kapazität, Preis, Umfang und Grenzen in denselben Verhaltensvertrag?

Identität öffnet der richtigen Person die Tür. Fähigkeit zeigt, was sich tatsächlich dahinter befindet.