Agentic Commerce im Versicherungsvertrieb – ein Proof of Concept

Veröffentlicht von sklaffke am

Wie KI-Agenten autonom Versicherungen vergleichen und empfehlen – und was die Branche dafür wirklich braucht

Was die Branche diskutiert

Der Versicherungsvertrieb steht vor einem strukturellen Wandel – darüber sind sich Analysten, Fachmedien und Brancheninsider einig. Was noch vor zwei Jahren als futuristische Vision galt, wird heute in Fachzeitschriften, auf Konferenzen und in Vorstandsetagen konkret diskutiert.

Der Versicherungsbote beschreibt, wie KI-Plattformen zunehmend die Rolle des zentralen Kundenzugangs übernehmen: Versicherungsprodukte werden nicht mehr ausschließlich über Websites oder Apps angeboten, sondern direkt innerhalb eines Gesprächs mit einem KI-Assistenten wie ChatGPT oder Claude. Der spanische Digitalversicherer Tuio arbeitet bereits daran, personalisierte Hausratversicherungen direkt über Chat-Interfaces anzubieten. Die Schlussfolgerung des Versicherungsboten: Versicherer, Vermittler und digitale Plattformen müssen sich jetzt im Wettbewerb um den direkten Kundenzugang behaupten.

Das Handelsblatt (AWS-Gastbeitrag, November 2025) beschreibt die agentische KI als nächste Evolutionsstufe: Während generative KI unterstützt und berät, handeln KI-Agenten eigenständig und treffen Entscheidungen. Sie orchestrieren komplexe Workflows über System- und Unternehmensgrenzen hinweg – auch bei Beschwerdebearbeitung, Kulanzentscheidungen oder Rabattverhandlungen.

Die Unternehmensberatung Oliver Wyman warnt in ihrer Studie „Versicherung 2035″: KI-Assistenten machen es Endkunden einfacher, Produkte zu vergleichen, wodurch bisher profitable Marktsegmente von 55 Prozent auf geschätzte 30 Prozent innerhalb des nächsten Jahrzehnts schrumpfen werden. Die entscheidende Frage lautet nicht mehr, ob agentische KI die Versicherungsbranche erreichen wird – sondern wie schnell Versicherer bereit sind, ihre Geschäftsmodelle zu transformieren.

Das IT-Finanzmagazin (Sollers Consulting, November 2025) benennt die technische Grundvoraussetzung klar: „Voraussetzung für den Einsatz von agentischer KI sind cloud-native Plattformen mit Event-Streams, API-first-Architektur und sicheren Integrationsstandards.“ Und weiter: „Ein Schlüsselbaustein ist das Model Context Protocol (MCP), das sich als offener Standard für die Anbindung von KI-Agenten etabliert.“

Der Versicherungsmonitor (Juni 2025) formuliert es als Vorstandsagenda: Trotz großer Aufmerksamkeit und hoher Budgets bleibt der praktische Nutzen von KI in der Versicherungsbranche bisher begrenzt. Viele Initiativen verpuffen in ineffektiven Taskforces oder generischen Software-Lizenzen. Die nächste Generation – spezialisierte, agentenbasierte Lösungen – eröffne revolutionäre Möglichkeiten.

Ich wollte wissen, ob das heute schon funktioniert – und habe es einfach gebaut.

Die fünf Interaktionsmodelle

Das Beratungsunternehmen ai-risk.co hat in seinem Artikel „Agentic Commerce: The Insurance Distribution Takeover“ fünf Interaktionsmodelle beschrieben, die einen klaren Entwicklungspfad zeigen – vom einfachen Web-Scraping bis zur vollautonomen Agent-to-Agent-Transaktion:

Modell 1 – Web Scraping: Ein KI-Agent navigiert Carrier-Websites, extrahiert Preis- und Deckungsinformationen und präsentiert die Ergebnisse dem menschlichen Käufer. Der Mensch entscheidet. Heute bereits operational.

Modell 2 – Broker Discovery: Der Agent ermittelt und präqualifiziert Spezialisten und Makler. Der menschliche Experte führt die eigentliche Platzierung durch. KI übernimmt die Recherche, der Mensch die Beratung.

Modell 3 – API-Integration: Carrier stellen maschinenlesbare APIs bereit. Aggregatoren und Plattformen integrieren direkt. Transaktionen ohne menschliche Interaktion werden möglich. Im Aufbau.

Modell 4 – Embedded Commerce: Eine KI-Plattform kauft Versicherung als Teil eines größeren Workflows – etwa bei einer Reisebuchung, einem Fahrzeugkauf oder einem Hypothekenabschluss. Der Mensch gibt den Rahmen vor, der Agent handelt autonom.

Modell 5 – Agent-to-Agent: Vollautonome Peer-to-Peer-Transaktion zwischen Brand Agents verschiedener Organisationen. Carrier und Broker betreiben je einen eigenen KI-Agenten mit eigener organisationeller Identität (DID, Verifiable Credential), die ohne menschlichen Eingriff miteinander verhandeln und Angebote austauschen. Der Mensch gibt einmalig die Rahmendaten vor – danach läuft alles autonom. Erwartete Marktreife laut ai-risk.co: 2027–2028.

Wo steht der PoC? Ehrlich eingeordnet liegt er zwischen Modell 3 und Modell 5: Die Anbieterseite ist vollständig Modell-5-ready, die Kundenseite entspricht heute noch Modell 3. Was das bedeutet und was der nächste Schritt wäre, beschreibe ich am Ende des Artikels.

Das Szenario

Ein Kunde möchte eine Tierversicherung abschließen. Statt selbst Anbieter zu recherchieren, Formulare auszufüllen oder anzurufen, überlässt er das seinem digitalen Assistenten – Claude Desktop. Der Assistent ermittelt selbstständig verfügbare Versicherungsanbieter, holt Angebote ein, vergleicht sie und spricht eine Empfehlung aus.

Kein Maklerportal. Kein Formular. Kein Anruf.

Im PoC sind drei fiktive Versicherungsanbieter registriert: Wuffi Pet Insurance, AlliPaws Versicherungs AG und EGO Travel Insurance – jeder davon ein eigenständiger KI-Agent. Die Anbieter wurden für den PoC ausgedacht, die Architektur dahinter ist real.

Die Architektur im Überblick

Der PoC besteht aus vier unabhängigen Diensten, die über standardisierte Protokolle miteinander kommunizieren:

Architektur POC

Das Besondere: Claude Desktop übernimmt die gesamte Orchestrierung. Es gibt keinen zusätzlichen Agent-Layer auf Kundenseite – der CustomerAgentMcpServer ist ein reiner Tool-Wrapper ohne eigenes Sprachmodell. Das Reasoning, die Tool-Auswahl und das Gesprächsgedächtnis liegen vollständig bei Claude.

Von der Demo zur Realität: Was sich hinter dem MCP-Server verbirgt

Im PoC simuliert der InsuranceMcpServer einfache Tarifdaten. In der Realität würde dieser Server die Rolle eines intelligenten Gateways übernehmen: Er wrappt die bestehenden API-Gateways des Versicherers und macht sie für den KI-Agenten nutzbar – ohne dass die Kernsysteme direkt exponiert werden müssen.

Das bedeutet: Der Insurance Agent ist kein reiner Angebotsautomat. Er könnte in einer produktionsreifen Umsetzung ein vollständiges Spektrum an Kundeninteraktionen abdecken:

  • Angebotsprozess: Tarife abfragen, Prämie berechnen, Angebot erstellen
  • Vertragsfragen: Deckungsumfang, Ausschlüsse, Sonderbedingungen – beantwortet über eine RAG-Wissensbasis auf den Vertragsdokumenten
  • Antragsstrecke: Formulardaten übergeben, Antrag einreichen (sobald DID-basierte Identifikation verfügbar ist)
  • Schadenmeldung: Erstmeldung aufnehmen, Dokumente entgegennehmen, Statusabfragen beantworten
  • Vertragsverwaltung: Adressänderungen, Zahlungsmodalitäten, Kündigungen

Der KI-Agent wird damit zum vollständigen digitalen Ansprechpartner des Versicherers – nicht nur im Vertrieb, sondern über den gesamten Kundenlebenszyklus. Und das alles über eine standardisierte A2A-Schnittstelle, die jeder zugelassene Broker-Agent nutzen kann.

Für Versicherer bedeutet das: Wer seine Kernsysteme heute API-first aufbaut und einen MCP-Gateway-Layer darüber legt, ist morgen für agentische Vertriebskanäle bereit – ohne die Kernsysteme nochmals anfassen zu müssen.

Zwei Schlüsselprotokolle: MCP und A2A

Model Context Protocol (MCP)

MCP ist ein offenes Protokoll von Anthropic, das es ermöglicht, KI-Modelle mit externen Tools und Systemen zu verbinden. Es standardisiert, wie ein Sprachmodell Werkzeuge aufruft, Ergebnisse empfängt und im Kontext weiterarbeitet. Das IT-Finanzmagazin bezeichnet MCP bereits als „offenen Standard für die Anbindung von KI-Agenten“, der sich branchenübergreifend etabliert.

Im PoC wird MCP auf zwei Ebenen genutzt:

Ebene 1 – STDIO (Claude Desktop → CustomerAgentMcpServer): Claude Desktop kommuniziert mit dem CustomerAgentMcpServer über Standard-Input/Output. Wichtige Randbedingung: System.out ist für das MCP-Protokoll reserviert – alle Logs müssen in Dateien geschrieben werden, niemals auf stdout.

Ebene 2 – STDIO (InsuranceAgentService → InsuranceMcpServer): Der InsuranceAgentService (Org B) startet den InsuranceMcpServer beim Hochfahren als STDIO-Subprocess – über StdioMcpTransport aus der LangChain4J-MCP-Bibliothek. Der MCP-Server hat keinen eigenen HTTP-Port; er kommuniziert ausschließlich über stdin/stdout mit dem Agent-Prozess.

Die drei Tools, die Claude über MCP zur Verfügung stehen:

ToolFunktion
listRegisteredInsurersFragt die Trust Registry ab – welche Agenten sind für welches Produkt und welchen Markt registriert?
startInsuranceConsultationEröffnet eine neue Beratungssession bei einem konkreten Versicherungsagenten per A2A
continueConsultationSetzt eine laufende Session fort – für Rückfragen oder Angebotsdetails

Agent-to-Agent (A2A)

A2A ist das Protokoll, über das zwei KI-Agenten verschiedener Organisationen miteinander kommunizieren – ohne gemeinsamen Supervisor, ohne geteilte Infrastruktur. Der PoC orientiert sich an der Google A2A Specification.

Jeder Versicherungsagent exponiert zwei Endpunkte:

  • POST /a2a/tasks – nimmt eine Aufgabe entgegen
  • GET /.well-known/agent.json – liefert die AgentCard: Identität, Capabilities, unterstützte Sprachen und A2A-Endpunkt

Die AgentCard ermöglicht es, dass Claude einen Agenten findet, versteht was er kann, und ihn direkt anspricht – ohne vorherige manuelle Konfiguration.

Die Trust Registry – das Herzstück des Modells

Das architektonisch entscheidende Element ist der InsuranceRegistryService – eine Simulation einer EIOPA-Infrastruktur für KI-Agenten.

Kein Versicherungsagent ist bei Claude hardcodiert. Stattdessen registrieren sich Anbieter eigenständig in der Registry. Claude fragt dort nach, welche Agenten zugelassen sind – und handelt auf dieser Basis.

GET /agents

→ [
    { "name": "Wuffi Pet Insurance Agent", "url": "http://...:8091", ... },
    { "name": "AlliPaws Versicherungs AG", "url": "http://...:8092", ... }
  ]

Das System ist offen und skalierbar: Ein neuer Anbieter registriert sich in der Registry – und Claude findet ihn automatisch beim nächsten Lookup. Kein Code-Update, kein manueller Eingriff.

Exkurs: Dezentralisierte Identität und was Europa plant

Die Trust Registry im PoC löst die Frage: Welche Agenten sind zugelassen? Was sie noch nicht löst: Wie verifiziert man, ob ein Agent wirklich der ist, der er vorgibt zu sein?

In einer Produktionsumgebung braucht es hierfür Dezentralisierte Identitäten (DID) und Verifiable Credentials. Jeder Agent besitzt eine kryptografisch gesicherte Identität, die unabhängig von einem zentralen Verzeichnis verifiziert werden kann – ein Insurance Agent könnte ein Credential vorweisen, das von der BaFin oder EIOPA ausgestellt wurde und bestätigt: „Dieser Agent ist als Versicherungsvermittler zugelassen.“

Europa schafft dafür gerade die regulatorische Grundlage:

eIDAS 2.0 (Verordnung EU 2024/1183, in Kraft seit Mai 2024) erweitert den bestehenden eIDAS-Rahmen um die European Digital Identity Wallet (EUDI Wallet). Bis Ende 2026 muss jeder EU-Mitgliedstaat mindestens eine solche Wallet für Bürger, Unternehmen und Organisationen bereitstellen. Sie ermöglicht das sichere Speichern und Teilen verifizierter digitaler Nachweise – von der nationalen ID bis zu Berufsqualifikationen und Unternehmenslizenzen.

Für den Versicherungskontext bedeutet das: Ein Versicherungsagent – ob Mensch oder KI – könnte künftig ein EUDI-Wallet-Credential vorweisen, das seine Zulassung als Vermittler belegt. Die Gegenseite verifiziert dieses Credential kryptografisch, ohne eine zentrale Datenbank abzufragen. Das Architecture Reference Framework (ARF) – die technische Blaupause, nach der alle 27 EU-Mitgliedstaaten ihre Wallets bauen müssen – liegt bereits in Version 2.7.3 vor und wird iterativ weiterentwickelt. Es legt fest, welche Standards und Protokolle für den Datenaustausch gelten, wie Credentials ausgestellt und präsentiert werden und wie Vertrauen über sogenannte Trusted Lists organisiert ist.

Was das für den PoC bedeutet: Die heute simulierte Trust Registry und das EUDI-Wallet sind in einer Produktionsumgebung komplementär – sie lösen zwei verschiedene Probleme:

FrageLösung
Welche Agenten sind zugelassen?Trust Registry – ein einfacher Lookup, bleibt erhalten
Ist dieser Agent wirklich der, der er vorgibt zu sein?EUDI Wallet + Verifiable Credential
Darf dieser Agent diese Aktion ausführen?Cedar Policy

Wie wird das EUDI-Wallet eines Agenten gefüllt?

Heute füllt ein Mensch sein EUDI-Wallet mit Credentials, die von einer Behörde ausgestellt werden – Personalausweis von der Gemeinde, Führerschein vom Kraftfahrtamt. Bei einem KI-Agenten wäre der Prozess analog: Die Organisation – also der Versicherer – beantragt bei der BaFin oder EIOPA die Zulassung als Versicherungsvermittler für ihren Agenten. Die Behörde stellt ein Verifiable Credential aus, das an die dezentralisierte Identität (DID) des Agenten gebunden wird. Der Agent trägt dieses Credential in seinem EUDI-Wallet und präsentiert es bei jedem A2A-Handshake kryptografisch signiert.

EIOPA / BaFin
     │  stellt aus: Verifiable Credential
     │  "AlliPaws-Agent ist zugelassener Versicherungsvermittler"
     │  → signiert mit EIOPA-Schlüssel
     ▼
EUDI Wallet des Insurance Agents
     │  DID: did:web:allipaws.de/agent
     │  Credential: EIOPA-Zertifikat (kryptografisch signiert)
     ▼
A2A Handshake mit CustomerAgent
     │  Agent präsentiert Credential
     │  CustomerAgent verifiziert Signatur
     │  → EIOPA hat diesen Agenten tatsächlich zertifiziert ✓

Der Vertrauenskreis schließt sich – auch für den Kunden

Das ist der entscheidende Unterschied zur heutigen Trust Registry im PoC: Die Registry sagt „dieser Agent ist eingetragen“. Das EUDI-Credential sagt „dieser Agent wurde von EIOPA zertifiziert – und ich kann das beweisen, ohne EIOPA selbst befragen zu müssen.“

Der Vertrauenskreis schließt sich auf drei Ebenen:

1. Für den CustomerAgent: Er kann vor dem ersten A2A-Call kryptografisch verifizieren, dass er mit einem echten, behördlich zugelassenen Versicherungsagenten spricht – nicht mit einem Fake-Agenten, der sich nur in der Registry eingetragen hat.

2. Für den Kunden: Er weiß, dass nur Versicherer Angebote abgeben können, die tatsächlich von EIOPA zertifiziert wurden. Kein nicht-zugelassener Anbieter kann sich in den Prozess einschleichen – die Signatur ist fälschungssicher.

3. Für den Regulierer: Jede Transaktion ist nachvollziehbar – welcher Agent hat wann mit welchem Credential gehandelt. Audit-Trails entstehen nicht aus LLM-Logs, sondern aus kryptografisch signierten Ereignissen.

Die Trust Registry bleibt dabei als Single Point of Discovery erhalten – der CustomerAgent macht weiterhin einen einfachen Lookup und bekommt die Liste zugelassener Agenten mit ihren DIDs. Das EUDI-Wallet kommt als Verifikationsschicht obendrauf, ohne die Einfachheit des Lookups zu zerstören:

CustomerAgent / Claude
     │
     │  1. GET /agents → Trust Registry
     │     Antwort: Liste mit Name, URL, DID
     │
     │  2. A2A Handshake → Insurance Agent
     │     Agent präsentiert EUDI-Credential (EIOPA-signiert)
     │     CustomerAgent verifiziert Signatur lokal ✓
     │     Cedar Policy: darf dieser Agent für Produkt "pet", Markt "DE"?
     │
     │  3. Transaktion – kryptografisch gesichert, auditierbar

Das ist die Architektur, die ai-risk.co als Voraussetzung für Modell 5 beschreibt. Der PoC hat den Discovery- und den Transaktions-Layer. Was noch fehlt, ist die Verifikationsschicht – und Europa baut sie gerade.

Der LangChain4J-Agent auf Versicherungsseite

Auf Kundenseite orchestriert Claude vollständig – kein eigener Agent-Layer. Auf Anbieterseite steckt hinter jedem Versicherungsagenten ein echter LangChain4J-Agent mit eigenem Sprachmodell (claude-sonnet-4-20250514), implementiert mit der AiServices-API (LangChain4J 1.12.1):

 InsuranceBackendAgent.java – deklarativer Agenten-Kontrakt als Interface
@AiService
public interface InsuranceBackendAgent {

    @SystemMessage("""
            Du bist ein spezialisierter Versicherungsagent (Wuffi Pet Insurance).
            Frage immer nach Tierart, Rasse, Alter und bekannten Vorerkrankungen.
            Prüfe zuerst mit checkBreedConditions auf rassenspezifische Aufschläge,
            bevor du mit getPetInsuranceQuote ein Angebot berechnest.
            """)
    @UserMessage("{{userMessage}}")
    String chat(String userMessage);
}

// InsuranceAgentService.java – imperativer Aufbau via AiServices.builder()
@Service
public class InsuranceAgentService {

    private final InsuranceBackendAgent agent;

    public InsuranceAgentService(
            @Value("${anthropic.api-key}") String apiKey,
            @Value("${insurance.mcp-server.jar}") String mcpServerJar) {

        // MCP-Client: startet insurance-mcp-server als STDIO-Subprocess
        McpTransport transport = new StdioMcpTransport.Builder()
                .command(List.of("java", "-jar", mcpServerJar))
                .build();

        McpClient mcpClient = new DefaultMcpClient.Builder()
                .transport(transport).build();

        McpToolProvider toolProvider = McpToolProvider.builder()
                .mcpClients(mcpClient).build();

        AnthropicChatModel model = AnthropicChatModel.builder()
                .apiKey(apiKey)
                .modelName("claude-sonnet-4-20250514")
                .build();

        // Tool-Dispatch und MCP-Verbindung werden vom Builder übernommen
        this.agent = AiServices.builder(InsuranceBackendAgent.class)
                .chatModel(model)
                .toolProvider(toolProvider)
                .build();
    }

    public String process(String message, String contextId) {
        return agent.chat(message);
    }
}

Der A2A-Controller auf Org-B-Seite nimmt eingehende Anfragen entgegen:

@PostMapping("/a2a/tasks")
public ResponseEntity<A2ATask> submitTask(@RequestBody A2ATask incomingTask) {
    String agentResponse = agentService.process(
            incomingTask.userText(), incomingTask.contextId());
    // A2ATask mit Status "completed" und Artifact zurückgeben
    return ResponseEntity.ok(completedTask);
}

@GetMapping("/.well-known/agent.json")
public AgentCard agentCard() { /* Name, Capabilities, Endpoint */ }

@AiService, @SystemMessage und @UserMessage definieren den Agenten als Interface-Kontrakt. AiServices.builder() verbindet deklarativ Sprachmodell, MCP-Tool-Provider und optionales Memory – ohne manuellen Orchestrierungscode.

Einordnung im PoC: Modell 3 auf Kundenseite, Modell 5 auf Anbieterseite

Was heute funktioniert

Auf Anbieterseite ist der PoC vollständig Modell-5-ready:

  • Jeder Insurance Agent ist ein autonomer LangChain4J-Agent mit eigenem LLM
  • Jeder Agent hat eine AgentCard unter /.well-known/agent.json
  • Discovery läuft über die Trust Registry – kein Agent ist hardcodiert
  • A2A HTTP ermöglicht echte Peer-to-Peer-Kommunikation zwischen Organisationen
  • Sessionbasierte Konversation: Rückfragen und Präzisierungen sind möglich

Auf Kundenseite entspricht der PoC heute Modell 3:

  • Claude Desktop ist ein generischer Orchestrator, kein organisationseigener Brand Agent
  • Es gibt keine AgentCard der Broker-Organisation
  • Es gibt keine DID-basierte Identität auf Kundenseite
  • Der Mensch interagiert aktiv mit Claude – es ist kein vollautonomer Prozess

Was echtes Modell 5 zusätzlich braucht

Der Schritt zu vollem Modell 5 ist konzeptionell klar: Der Mensch gibt einmalig die Rahmendaten vor –

„Labrador, 3 Jahre, Krankenversicherung, max. 50 €/Monat, Markt DE“

– und ab diesem Moment läuft alles autonom:

Mensch gibt Rahmendaten vor
     │
     ▼
Brand Agent Broker (Org A)          ← eigene AgentCard, DID-Credential
     │  1. Registry-Lookup: Wer ist zugelassen?
     │  2. AgentCards prüfen: Capabilities, Sprachen, Endpunkte
     │  3. A2A: Angebote bei allen relevanten Agenten einholen
     │  4. Vergleichen, gewichten, empfehlen
     │  5. Rückfragen autonom klären
     │  6. Abschluss initiieren
     ▼
Insurance Agents (Org B, C, D)      ← eigene AgentCard, DID-Credential
     │  Angebot berechnen
     │  Antworten und ggf. Gegenfragen stellen
     ▼
Ergebnis: Empfehlung oder Police – ohne weiteren Eingriff des Menschen

Technisch wäre dieser Schritt im PoC überschaubar: Der CustomerAgentMcpServer bekommt ein eigenes LLM, eine eigene AgentCard und eine organisationelle Identität. Claude Desktop wird zur reinen Eingabemaske für die Rahmendaten. Die gesamte Anbieterseite bleibt unverändert.

Die eigentliche Hürde ist nicht technisch – sie ist regulatorisch: Wer haftet für die autonome Empfehlung? Braucht der Brand Agent eine BaFin-Zulassung als Versicherungsmakler? Gilt die IDD für einen KI-Agenten?

Was noch klassisch läuft

Der Vertragsabschluss – Antragsstrecke, Datenübergabe, Bezahlung – erfolgt heute noch auf klassischem Weg. Mit dezentralisierten Identitäten (DID/EUDI Wallet) und Agent-to-Agent-Zahlungsmethoden wäre auch das durchgängig automatisierbar. Die regulatorischen und technischen Bausteine entstehen gerade in Europa.

Die eigentliche Erkenntnis

Ohne saubere Daten, eine eventgetriebene Anwendungsarchitektur und API-fähige Kernsysteme bleibt auch der beeindruckendste KI-Versicherungsagent Zukunftsmusik. Das IT-Finanzmagazin formuliert es präzise: „Wer echte Vorteile erzielen will, muss auf Microservices, Domain-driven Design und Event-Driven-Architekturen setzen.“ Wer das heute noch nicht hat, steht vor einem Modernisierungsprojekt – nicht vor einem KI-Projekt.

Und wo bleibt die persönliche Beratung? Gerade bei Versicherungen, die mehr persönliche Daten und ein echtes Beratungsgespräch erfordern, greift nach wie vor die telefonische, kompetente Beratung. KI ersetzt hier nicht den Menschen – sie übernimmt das Standardgeschäft und gibt dem Berater den Raum für das, was wirklich zählt.

Exkurs: Wer haftet – und wie macht man Agenten-Entscheidungen erklärbar?

Nach der Veröffentlichung dieses Artikels auf LinkedIn gab es einen Kommentar, der den juristischen Kern des Problems präzise benannte und den ich hier aufgreifen möchte.

Die Frage ist: Was macht eine Entscheidung zu einem juristischen Akt? Die Antwort lautet: ein Wertepaar aus Absicht und Wirkung. Ein KI-Agent hat trotz seines Namens keine Agency im juristischen Sinne und damit keinen Intent. Es gibt nur Wirkung – ohne erklärbare Entscheidungen. Genau das ist das Problem, das EU AI Act und DORA adressieren: Entscheidungen müssen erklärbar sein, eine Entscheidung ohne Absicht ist nicht erklärbar.

Das bedeutet: In einem agentischen KI-System muss die Entscheidung axiomatisch und transparent delegiert werden, damit eine nachvollziehbare Entscheidungsstruktur erkennbar wird. Nicht der Agent haftet – sondern die Organisation, die den Agenten mit definierten, überprüfbaren Regeln betreibt.

Cedar – Policy-as-Code für KI-Agenten

Genau hier kommt Cedar ins Spiel – eine von Amazon Web Services entwickelte, open-source Policy-Sprache, die formale Entscheidungsregeln für KI-Agenten ermöglicht.

Cedar ist eine deklarative Autorisierungssprache: Statt Entscheidungslogik in den Agenten-Code einzubetten, werden Regeln als externe, versionierbare Policies formuliert. Das Prinzip ist einfach – jede Policy folgt dem PARC-Modell:

permit(
  principal is Agent::"BrokerAgent",
  action == Action::"requestInsuranceQuote",
  resource == InsuranceAgent::"AlliPaws"
)
when {
  context.product == "pet" &&
  context.market == "DE" &&
  context.monthlyBudget <= 100
};

Die Policy-Engine gibt für jeden Tool-Call eine binäre Antwort: PERMIT oder DENY – bevor die Aktion ausgeführt wird. Kein probabilistisches Verhalten, kein „der Agent hat entschieden“ – sondern: der Agent hat im Rahmen der Policy P gehandelt, die von Entscheidungsträger X autorisiert wurde.

Was Cedar von anderen Ansätzen unterscheidet: Die Sprache ist formal verifizierbar. Politiken können durch automatisches Reasoning auf Widersprüche und Lücken geprüft werden – bevor sie produktiv gehen. Das ist der Unterschied zwischen KI-basierter Safety (probabilistisch) und formaler Policy-Enforcement (deterministisch).

AWS setzt Cedar bereits produktiv in Amazon Bedrock AgentCore ein: Jeder Tool-Call eines Agenten wird am Gateway abgefangen und gegen Cedar-Policies geprüft. Policies können per Natural Language oder direkt als Cedar-Code erstellt werden – und lassen sich in CI/CD-Pipelines integrieren, versionieren und auditieren.

Was das für den PoC bedeutet

In meinem PoC ist die Governance-Schicht bewusst ausgeblendet – es geht um die technische Machbarkeit. Für einen produktiven Einsatz wäre Cedar oder ein vergleichbarer Policy-Layer das fehlende Stück zwischen „der Agent empfiehlt“ und „die Organisation haftet nachvollziehbar dafür“.

Konkret: Der CustomerAgent dürfte nur bei Agenten anfragen, die in der Trust Registry registriert sind und für die eine Policy explizit das Erlaubnis erteilt. Der InsuranceAgent dürfte nur Angebote bis zu einer definierten Prämienhöhe ohne menschliche Freigabe erstellen. Jede Aktion wäre auditierbar – nicht als LLM-Trace, sondern als formaler Policy-Entscheid.

Das verschiebt auch die IDD-Frage in eine handhabbare Richtung: Nicht der Agent ist der Vermittler – sondern die Organisation, die ihn mit definierten, erklärbaren Policies betreibt. Und für diese Organisation gelten die bestehenden Zulassungspflichten.

Demo

Fazit

Der PoC zeigt: Die Technologie für autonomen Agentic Commerce im Versicherungsvertrieb ist heute verfügbar. LangChain4J, MCP und A2A ermöglichen es, zwei vollständig unabhängige Agenten verschiedener Organisationen miteinander kommunizieren zu lassen – ohne gemeinsamen Supervisor, ohne geteilte Infrastruktur.

Die eigentlichen Hürden liegen woanders. Auf der technischen Seite brauchen Versicherer saubere Daten, API-fähige Kernsysteme und eine eventgetriebene Architektur – wer das heute nicht hat, steht vor einem Modernisierungsprojekt, nicht vor einem KI-Projekt. Auf der Governance-Seite braucht es formale Policy-Layer wie Cedar, die Agenten-Entscheidungen deterministisch und auditierbar machen – die Technologie dafür ist vorhanden. Auf der regulatorischen Seite sind die Fragen nach Haftung, IDD-Konformität und kryptografischer Agent-Identität (DID, EUDI Wallet) noch offen – Europa arbeitet daran, die Antworten bis 2026 zu liefern.

Was dieser PoC nicht ersetzt: die persönliche Beratung für komplexe Versicherungsprodukte, die mehr als Tarifdaten erfordern. KI übernimmt das Standardgeschäft – und gibt dem Berater den Raum für das, was wirklich zählt.

Technologie-Stack: LangChain4J 1.12.1 | Spring Boot 3.5.11 | Java 21 | Claude Sonnet 4 (claude-sonnet-4-20250514)

Quellenverweise

Kategorien: AIUncategorized
Tags:

0 Kommentare

Schreibe einen Kommentar

Avatar-Platzhalter

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert