KI-Agenten und Blockchain: Wo dezentrale Infrastruktur sinnvoll werden könnte – und wo nicht

Die entscheidende Frage lautet nicht: „Wie bringen wir KI auf die Blockchain?“ Sondern: „Welche Parteien müssen welchem Agenten, welcher Vollmacht und welchem Ergebnis vertrauen – und warum reicht dafür eine zentrale Lösung nicht?“

Was hier mit KI-Agent gemeint ist

Ein KI-Agent ist hier ein Softwaresystem, das ein Ziel verfolgt, dafür Informationen verarbeitet, Werkzeuge oder Schnittstellen nutzt und innerhalb vorgegebener Grenzen mehrere Arbeitsschritte ausführt. Ein Chatfenster, das nur eine Antwort formuliert, ist noch kein Agent. Auch ein fest verdrahteter Workflow wird nicht allein durch ein Sprachmodell zum Agenten.

Die Abgrenzung ist wichtig, weil die Risiken mit den Handlungsmöglichkeiten wachsen. Sobald ein System Daten abruft, Entscheidungen vorbereitet, Bestellungen auslöst oder anderen Systemen Anweisungen gibt, werden Identität, Berechtigung und Protokollierung zu Architekturfragen. Das US-amerikanische NIST beschreibt Identifizierung, Autorisierung, Auditierbarkeit und Nichtabstreitbarkeit deshalb als zentrale offene Themen für Software- und KI-Agenten. Das ist ein aktueller Arbeitsstand, kein fertiger Agentenstandard.

Für die praktische Gestaltung solcher Abläufe ist zuerst der Prozess zu klären: Ziel, erlaubte Aktionen, Datenzugriffe, Ausnahmefälle und menschliche Freigaben. Die Prozess- und Workflow-Automatisierung bei KI Prozesspartner vertieft diese operative Perspektive.

Was sich ändert, wenn Agenten für andere handeln

Ein Agent handelt nicht im eigenen wirtschaftlichen Interesse. Er handelt im Auftrag einer Person oder Organisation. Daraus entstehen mindestens sechs Fragen:

• Identität: Welches technische System sendet die Anfrage – und zu welcher Organisation gehört es?
• Vollmacht: Welche Handlung wurde erlaubt, für welchen Zweck und für welchen Zeitraum?
• Limits: Welche Beträge, Daten, Geschäftspartner oder Aktionen sind ausgeschlossen?
• Nachvollziehbarkeit: Welche Eingaben, Freigaben und Systemschritte müssen später rekonstruierbar sein?
• Widerruf: Wie wird eine Berechtigung sofort entzogen oder ein Nachweis ungültig gemacht?
• Verantwortung: Wer entscheidet bei Fehlern, Konflikten und nicht vorgesehenen Situationen?

Diese Fragen lassen sich mit klassischem Identity and Access Management, signierten Tokens, Datenbanken und Audit-Logs lösen. Blockchain ist nur eine mögliche Infrastrukturkomponente – und oft nicht die erste.

Vier mögliche Schnittstellen zu Blockchain und DLT

1. Überprüfbare Identitäten und Nachweise

Problem: Ein externer Dienst soll prüfen können, ob ein Agent zu einem bestimmten Unternehmen gehört, eine Qualifikation besitzt oder innerhalb einer gültigen Vollmacht handelt. Beteiligt sind mindestens der Auftraggeber, der Agent, eine ausstellende Stelle und der prüfende Dienst.

Verifiable Credentials können digital signierte Aussagen maschinenprüfbar machen. Das W3C hat das Verifiable Credentials Data Model 2.0 im Mai 2025 als Recommendation veröffentlicht. Decentralized Identifiers können als Identifikatoren oder Vertrauensanker dienen. Dabei ist eine wichtige Einschränkung: Der DID-Standard schreibt keine Blockchain vor; DID-Methoden können auch andere Register- oder Infrastrukturlösungen verwenden.

Wann DLT helfen könnte: Mehrere voneinander unabhängige Organisationen müssen Aussteller, Schlüssel oder Statusinformationen prüfen, ohne einen gemeinsamen zentralen Betreiber zu akzeptieren. Wenn ein etablierter Identity Provider oder ein gemeinsames Register akzeptiert wird, ist die zentrale Variante meist einfacher. Für Credential-Architektur, Rollen und Widerruf gibt es eine eigene Beratungsseite zu Verifiable Credentials und DIDs.

2. Organisationsübergreifende Berechtigungen und Status

Problem: Ein Agent darf bei mehreren Partnern nur bestimmte Aktionen ausführen. Die Partner müssen denselben aktuellen Status kennen: aktiv, eingeschränkt oder widerrufen. Dabei sind Auftraggeber, Plattformbetreiber, Geschäftspartner und möglicherweise eine Aufsicht oder Zertifizierungsstelle beteiligt.

Wann DLT helfen könnte: Wenn keine Partei allein die Berechtigungen führen soll, Änderungen für alle Beteiligten konsistent sichtbar sein müssen und gemeinsame Governance-Regeln existieren. Ein Smart Contract könnte technische Regeln abbilden, aber er ersetzt weder die fachliche Vollmacht noch die Klärung von Haftung und Ausnahmefällen. Kontrolliert ein Unternehmen alle Systeme, sind klassisches Rollenmanagement und eine zentrale Policy-Engine normalerweise direkter.

3. Maschinenlesbare Zahlungen und Abrechnung

Problem: Ein Agent bereitet im Auftrag eines Unternehmens einen Einkauf oder eine Abrechnung vor. Händler, Auftraggeber, Zahlungsdienstleister und Agentenplattform müssen nachweisen können, was autorisiert war und welche konkrete Transaktion daraus entstand.

Dass diese Fragen bereits praktisch bearbeitet werden, zeigt Googles 2025 vorgestelltes Agent Payments Protocol (AP2). Das offene Protokoll ist zahlungsmittelunabhängig und verwendet kryptografisch signierte Mandate, um Nutzerabsicht und Transaktionskontext zu dokumentieren. Gerade das zeigt: Agentenzahlungen benötigen nicht zwingend eine Blockchain.

Wann DLT helfen könnte: Wenn digitale Vermögenswerte ohnehin auf einer DLT geführt werden, mehrere Parteien ohne gemeinsame Abrechnungsstelle direkt verrechnen oder programmierbare Zahlungen mit einem gemeinsam geprüften Zustand verbinden möchten. Für normale Unternehmenskäufe mit Bank, Karte oder etabliertem Payment Provider bleibt die vorhandene Zahlungsinfrastruktur meist die naheliegendere Wahl.

4. Manipulationsresistente Protokolle und Herkunftsnachweise

Problem: Mehrere Organisationen möchten später prüfen, welcher Nachweis vorlag, welche Freigabe erteilt wurde und welcher Prozessschritt folgte. Beteiligt sind Datenlieferanten, Agentenbetreiber, prüfende Partner und gegebenenfalls interne oder externe Revision.

Blockchain-Ledger sind laut NIST IR 8202 manipulationsanzeigend und manipulationsresistent – nicht absolut unveränderlich. Sie können deshalb eine gemeinsame, nachträglich schwer veränderbare Belegspur unterstützen. Sie beweisen aber nicht, dass eine ursprüngliche Eingabe wahr, vollständig oder rechtmäßig war.

Wann DLT helfen könnte: Wenn mehrere Parteien unabhängig denselben Ereignisnachweis prüfen müssen und keine zentrale Log-Stelle akzeptiert wird. Für interne Audits reichen signierte, zugriffsgeschützte und unveränderbar archivierte Logs oft aus. Sensible Inhalte sollten nicht allein wegen der Nachvollziehbarkeit dauerhaft auf eine Blockchain geschrieben werden.

Ein bewusst hypothetisches Szenario

Angenommen, ein Beschaffungsagent soll für ein Industrieunternehmen ein Ersatzteil anfragen. Er darf nur bei freigegebenen Lieferanten bestellen, braucht für bestimmte Bauteile einen gültigen Qualitätsnachweis und darf eine definierte Betragsgrenze nicht überschreiten.

1. Der Agent findet ein Angebot und fordert einen maschinenprüfbaren Qualitätsnachweis an.
2. Er prüft Aussteller, Gültigkeitsstatus und Bezug zum konkreten Produkt.
3. Er bereitet die Transaktion mit Preis, Lieferbedingungen und verwendeten Nachweisen vor.
4. Liegt der Betrag über seinem Limit, fordert er eine menschliche Freigabe an.
5. Nach der Freigabe übergibt er die Zahlung an die vereinbarte Zahlungsinfrastruktur und protokolliert die relevanten Belege.

Eine DLT-Komponente wäre hier nur dann plausibel, wenn Lieferant, Käufer, Zertifizierungsstelle und weitere Prüfer einen gemeinsam überprüfbaren Status benötigen, ohne eine zentrale Plattform als verbindliche Instanz zu akzeptieren. Gibt es bereits ein anerkanntes Lieferantenportal mit Register, Berechtigungen und Audit-Log, löst Blockchain voraussichtlich kein zusätzliches Problem.

Entscheidungsmatrix: DLT oder klassische Infrastruktur?

Kein einzelnes Kriterium entscheidet den Use Case. Besonders kritisch ist die letzte Zeile: Wenn der Zusatznutzen gegenüber der klassischen Alternative nicht konkret beschrieben werden kann, sollte kein DLT-PoC gestartet werden. Der allgemeine Rahmen dazu steht im Artikel Wann ist Blockchain für Unternehmen sinnvoll?

Wann Blockchain bei KI-Agenten eher ungeeignet ist

• Ein Unternehmen betreibt Agent, Datenquellen und Zielsysteme selbst.
• Eine zentrale Datenbank oder Plattform wird von allen Beteiligten akzeptiert.
• Sehr geringe Latenz, hohe Vertraulichkeit oder einfache Korrekturen sind wichtiger als organisationsübergreifende Prüfbarkeit.
• Personenbezogene oder sensible Daten müssten unnötig breit oder dauerhaft repliziert werden.
• Vollmacht, Haftung, Widerruf und Eskalation sind fachlich noch nicht geregelt.
• Die Blockchain soll lediglich Vertrauen erzeugen, obwohl Herkunft und Qualität der Eingangsdaten ungeklärt bleiben.

In diesen Fällen sollte die Organisation zuerst Prozess, Daten und Kontrollmodell stabilisieren. Eine komplexere Infrastruktur macht ein unklares Mandat nicht belastbarer.

Was vor einem PoC geklärt sein muss

1. Rolle des Agenten: beraten, vorbereiten oder selbst ausführen?
2. Vollmacht und Limits: Wer autorisiert welche Aktion, mit welchem Betrag, Zeitraum und Zweck?
3. Datenobjekte: Welche Nachweise, Statusinformationen und Transaktionsdaten werden benötigt?
4. Fehlerfälle: Was passiert bei falschen Daten, Doppelaktionen, Ausfällen oder widersprüchlichen Ergebnissen?
5. Menschliche Freigabe: Welche Schwellenwerte und Risiken lösen einen Stopp oder eine Eskalation aus?
6. Widerruf: Wie werden Schlüssel, Credentials, Vollmachten und laufende Aufträge beendet?
7. Audit: Welche Belege müssen später von wem geprüft werden können?
8. Betriebsmodell: Wer betreibt Agent, Register, Nodes, Schnittstellen und Support?
9. Erfolgskriterium: Welche messbare Hypothese soll der PoC bestätigen oder widerlegen?

Diese Klärung gehört in eine strukturierte Use-Case-Bewertung vor dem Proof of Concept. Wenn mehrere Fachbereiche und Partner beteiligt sind, kann ein fokussierter Blockchain Use Case Workshop den Entscheidungsrahmen schaffen.

Fazit: Infrastrukturkomponente, nicht Grundvoraussetzung

Blockchain ist kein notwendiger Bestandteil von KI-Agenten. Identität, Autorisierung, Zahlung und Audit lassen sich in vielen Fällen mit bewährten zentralen Systemen besser lösen. DLT wird dort prüfenswert, wo mehrere unabhängige Organisationen einen gemeinsamen Zustand oder Nachweis benötigen, keine zentrale Instanz allein kontrollieren soll und Governance bereits konkret geregelt werden kann.

Der sinnvolle nächste Schritt ist daher weder Token noch Plattformwahl. Zuerst werden Agentenrolle, Vollmacht, Beteiligte, Daten, klassische Alternative und Erfolgskriterium beschrieben. Erst dann lässt sich entscheiden, ob Blockchain einen echten Infrastrukturvorteil bringt oder nur zusätzliche Komplexität.

Verwendete Primärquellen

• NIST/NCCoE: Identity and Authority of Software Agents – aktueller Konzeptstand zu Identität, Autorisierung und Audit von Agenten.
• W3C: Verifiable Credentials Data Model 2.0 und W3C: Decentralized Identifiers 1.0 – normative Grundlagen für überprüfbare Nachweise und DIDs.
• Google: Agent Payments Protocol – offizieller Überblick zum offenen, zahlungsmittelunabhängigen AP2.
• NIST IR 8202: Blockchain Technology Overview – Eigenschaften und Grenzen von Blockchain-Ledgern.