Wenn jemand etwas online kauft, läuft im Hintergrund ein ganzes Räderwerk rechtlicher Mechanismen. Der Käufer akzeptiert die Geschäftsbedingungen, der Händler erfasst diese Zustimmung, und falls bei der Bestellung etwas schiefgeht, gibt es eine Quittung, Rückgabebedingungen und eine identifizierbare Partei, die zur Verantwortung gezogen werden kann. Überträgt man denselben Kauf einem KI-Agenten, entfällt dieser Mechanismus. Der Agent findet das Produkt, akzeptiert die Geschäftsbedingungen und wickelt die Zahlung ab, ohne dass eine Person dies überwacht. Wenn die Ware nie ankommt oder sich herausstellt, dass die Bedingungen von dem abweichen, was der Agent verstanden hat, wird unklar, wer was vereinbart hat, unter welcher Rechtsordnung und über welchen Kanal eine Beschwerde geklärt werden würde. Für den größten Teil des vergangenen Jahres gab es für den Handel mit Agenten keine eindeutige Antwort.
Am 24. Juni 2026 schloss sich eine Koalition unter der Führung der American Arbitration Association, der seit einem Jahrhundert bestehenden Institution zur Beilegung von Handelsstreitigkeiten, und Integra Ledger zusammen hat das Legal Context Protocol (LCP) eingeführt um eine solche bereitzustellen. LCP ist ein offener Standard, der es einem KI-Agenten ermöglicht, die rechtlichen Bedingungen eines Händlers zu ermitteln, dessen Zustimmung dazu zu dokumentieren und im Voraus festzulegen, wie ein Streitfall beigelegt werden soll – und zwar in einer Form, die von einer anderen Maschine gelesen und später überprüft werden kann. Im Endeffekt verleiht er einer agentengesteuerten Transaktion die Nachweiskette, die auch bei einem menschlichen Bezahlvorgang entsteht, sodass es eine eindeutige Aufzeichnung darüber gibt, was vereinbart wurde und was folgt, falls etwas schiefgeht. Die Gründungsmitglieder haben großes Gewicht. Zu ihnen gehören Google, IBM, Circle und Wayfair sowie eine Reihe von Blockchain- und Identitätsunternehmen. Unabhängig davon ist der Standard so konzipiert, dass er mit den wichtigsten bereits bestehenden Protokollen für den agentengesteuerten Handel zusammenarbeitet, darunter das „Trusted Agent Protocol“ von Visa und „Verifiable Intent“ von Mastercard.
Der Zeitpunkt ist bewusst gewählt. Gartner Prognosen zufolge werden bis 2028 90% der B2B-Einkäufe über KI-Agenten abgewickelt, wodurch Ausgaben in Höhe von mehr als $15 Billionen über KI-Agenten-Börsen getätigt werden. Die Branche hat bei den Komponenten, die es einem Agenten ermöglichen zu zahlen – nämlich den Zahlungswegen und den Identitätsprüfungen – rasche Fortschritte erzielt. Die rechtliche Ebene, also die Dokumentation der getroffenen Vereinbarungen und der Weg zur Beilegung von Streitigkeiten, hat damit jedoch nicht Schritt gehalten. Bei einem einzelnen Auftrag im Wert von $30 ist eine fehlende Aufzeichnung unerheblich. Bei automatisierten Transaktionen im Wert von Billionen Dollar ist dies jedoch genau die Art von Lücke, die das gesamte Modell behindern kann. LCP ist ein Versuch, diese Lücke zu schließen, bevor dieses Volumen erreicht wird.
Die wichtigsten Erkenntnisse
- LCP ist ein offener Standard, der es einem KI-Agenten ermöglicht, die rechtlichen Bestimmungen, die Einwilligungserklärungen und das Streitbeilegungsverfahren eines Dienstes in maschinenlesbarer Form zu ermitteln.
- Der normative Kern ist winzig: eine JSON-Datei an einem festen Speicherort mit einem einzigen Pflichtfeld. Es sind weder eine Blockchain noch eine API noch Kryptografie erforderlich.
- Vier optionale Vertrauensstufen ermöglichen eine an die jeweilige Transaktion angepasste Sicherheitsstufe – von einer auffindbaren Konditionsdatei bis hin zu hash-verifizierten, digital signierten und für Streitfälle vorbereiteten Vereinbarungen.
- Es wurde so konzipiert, dass es neben Zahlungs- und Identitätsprotokollen, darunter auch Visas TAP, zum Einsatz kommt und den Stack vervollständigt: Das Zahlungsprotokoll gibt an, was bezahlt wurde, das Identitätsprotokoll gibt an, wer gehandelt hat, und LCP gibt an, zu welchen Bedingungen.
Was LCP eigentlich ist
Lässt man die Koalition und den Rahmen einmal außer Acht, ist der Standard bemerkenswert klein. Ein Dienst, der für Agenten lesbar sein soll veröffentlicht eine einzelne JSON-Datei an einem bekannten Speicherort: /.well-known/legal-context.json, bereitgestellt über HTTPS. Die Datei enthält genau ein Pflichtfeld, nämlich einen Link zu den Nutzungsbedingungen:
{
"terms": "https://example.com/terms/v3.md"
}
Das ist die einzige zwingende Anforderung. Die Bedingungen müssen als eigenständiges, herunterladbares Dokument vorliegen und dürfen nicht Teil einer Webseite sein, damit ein Agent sie in einer einzigen Anfrage abrufen und auswerten kann. Die Spezifikation empfiehlt maschinenlesbare Formate wie Markdown, JSON oder reinen Text gegenüber PDF und Word, da Layoutformate von einer Maschine nicht zuverlässig ausgewertet werden können. Es sind weder eine Blockchain noch eine API, noch Kryptografie noch Dienste von Drittanbietern erforderlich, und das Ganze wird unter der freizügigen Apache-2.0-Lizenz veröffentlicht. Ein Einzelentwickler und eine Bank setzen das Konzept auf dieselbe Weise um: eine JSON-Datei erstellen und auf einen Server stellen.
Man sollte die Entwicklung im richtigen Zusammenhang betrachten. Die Übernahme erfolgt auf freiwilliger Basis, und die Verwaltung soll weiterhin an eine neutrale Stiftung übergehen. Es handelt sich also um einen vorgeschlagenen Standard, der an Dynamik gewinnt, und nicht um einen bereits etablierten. Das Konzept ist jedoch bewusst so gestaltet, dass man ihm leicht zustimmen kann – und genau so setzen sich Standards in der Regel durch.
Vier Vertrauensstufen
Das einzige Pflichtfeld ist „Level 1“. Darauf aufbauend definiert die Norm Vier Stufen der Vertrauenssicherung, wobei jede dieser Bestimmungen optional ist und beiden Seiten einer Transaktion zusätzliche Beweiskraft verleiht, anstatt den Verkäufer zu begünstigen.
- Stufe 1, Informativ. Der Akteur findet die Bedingungen, und das Fortfahren gilt als stillschweigende Zustimmung. Dies ist das heutige „Browsewrap“-Modell, jedoch mit einem festen Ort. Es eignet sich für Transaktionen mit geringem Wert und hohem Volumen, wie beispielsweise API-Aufrufe oder den Kauf von Standardwaren.
- Stufe 2, nachweisbar. Die Datei enthält einen „atrHash“, einen SHA-256-Hash des Vertragsdokuments, der als „Agentic Transaction Record“ bezeichnet wird. Er belegt eindeutig, welches Dokument gültig war und dass es nachträglich nicht verändert wurde. Dies ist immer dann von Bedeutung, wenn Streitigkeiten über den Inhalt der Vertragsbedingungen naheliegend sind, wie beispielsweise bei der B2B-Beschaffung.
- Stufe 3, mit Unterschrift. Ein „acceptanceRequired“-Flag in Verbindung mit einer digitalen Signatur belegt die ausdrückliche Absicht – insbesondere in regulierten Branchen und bei Verträgen mit hohem Wert, bei denen das Gesetz eine Unterschrift vorschreibt.
- Stufe 4, integriert. Bereiche der Streitbeilegung und eine API binden die Transaktion in eine echte rechtliche Infrastruktur ein: Treuhandkonto, Compliance-Prüfung und ein klar definierter Regressweg.
Das Leitprinzip ist die Verhältnismäßigkeit. Eine Datenabfrage im Wert von wenigen Cent und ein sechsstelliger Lieferantenvertrag sollten natürlich nicht mit denselben Gemeinkosten verbunden sein; daher soll die Qualitätssicherung entsprechend dem jeweiligen Risiko skaliert werden.
So funktioniert es zum Zeitpunkt der Transaktion
Der Ablauf ist bewusst unspektakulär gehalten. Bevor ein Kauf abgeschlossen wird, fordert der Agent Folgendes an: /.well-known/legal-context.json von der Domain des Händlers, liest das Feld „terms“ aus und ruft das darin angegebene Terms-Dokument ab. Auf Stufe 1 reicht das aus: Der Agent verfügt über die Bedingungen und fährt mit der Einwilligungserfassung fort. Auf Stufe 2 geht er noch einen Schritt weiter: Er berechnet den SHA-256-Hash des soeben heruntergeladenen Dokuments neu und vergleicht ihn mit dem „atrHash“ in der Discovery-Datei. Stimmen beide überein, verfügt der Agent über einen kryptografischen Nachweis, dass die gelesenen Bedingungen genau den vom Händler veröffentlichten Bedingungen entsprechen und nicht verändert wurden. Auf den Stufen 3 und 4 sorgen eine digitale Signatur und ein API-Aufruf für eine ausdrückliche Zustimmung sowie einen Weg zur Streitbeilegung. Es müssen keine neuen „Rails“ und kein Plugin installiert werden: eine gewöhnliche HTTPS-Anfrage sowie ein optionaler Hash-Vergleich, den der Agent lokal durchführen kann.
Wo es sich im Stapel befindet
LCP steht nicht in Konkurrenz zu den bereits laufenden Arbeiten im Bereich Zahlungsverkehr und Identitätsmanagement. Es wurde entwickelt, um diese zu ergänzen. Die Einführung schafft eine klare Struktur der Ebenen: Zahlungsprotokolle wie x402 Und das Trusted Agent Protocol gibt Auskunft darüber, was bezahlt wurde; Identitäts- und Koordinationsrahmen geben Auskunft darüber, wer gehandelt hat; das LCP gibt Auskunft darüber, zu welchen Bedingungen, nach welchem Recht und mit welchen Rechtsmitteln.
An dieser Stelle kommen wir wieder auf ein Thema zurück, das wir bereits behandelt haben. Das kürzlich europaweit eingeführte TAP-System von Visa überprüft, ob ein Vertreter, der bei einem Händler vor der Tür steht, vertrauenswürdig ist. Es gibt Aufschluss darüber, wer der Vertreter ist. Über die Bedingungen des Geschäfts, das dieser Vertreter anschließend abschließt, sagt es jedoch nichts aus. LCP ist das Element, das diese Bedingungen festlegt und überprüfbar macht, und der Standard dokumentiert bereits wie die beiden zusammenwirken sollen. Die Identität verschafft dem Akteur Zugang. Die Bedingungen legen fest, wozu er sich verpflichtet hat.
Warum dies für die Preisgestaltung von Bedeutung ist
Hier kommt der Punkt, auf den ein Preisgestaltungsteam besonders achten sollte. In einem von Vermittlern geprägten Markt ist ein Preis niemals wirklich nur eine Zahl für sich. Es ist eine Zahl, die an bestimmte Bedingungen geknüpft ist: das Rückgaberecht, die Stornierungsfrist, die Liefergarantie, die Regressmöglichkeiten, falls die Ware nie ankommt. Ein Mensch überfliegt dieses Kleingedruckte gelegentlich. Ein Vermittler liest es jedes Mal vollständig durch, und sobald LCP zum Einsatz kommt, werden die Bedingungen ebenso maschinenlesbar verarbeitet wie alles andere. Der Preis wird zu einem Feld in einem strukturierten, überprüfbaren Angebot, das gegen die damit verbundenen Bedingungen abgewogen wird.
Dies hat zwei Konsequenzen für die Festlegung und Durchsetzung von Preisen.
Zunächst einmal müssen Preis und Konditionen stimmig sein. Wenn Ihre Preisgestaltung und Ihre veröffentlichten Konditionen nicht übereinstimmen, wird ein Makler, der strukturierte Angebote vergleicht, dies bemerken, und die Unstimmigkeit wird zu einem Grund, Sie zu umgehen, anstatt nur ein Detail zu sein, das niemand liest.
Zweitens spielt die Nachweisbarkeit erst auf der Preisebene eine Rolle, nicht nur auf der Ebene der Vertragsbedingungen. Dynamische Preise ändern sich ständig; wenn also ein Akteur um 14:32 Uhr einen Kauf tätigt und es anschließend zu einem Streitfall kommt, stellt sich die Frage, wie der Preis und die Vertragsbedingungen genau in diesem Moment aussahen. LCP beantwortet den Teil bezüglich der Vertragsbedingungen: Es atrHash sichert die zum Zeitpunkt des Verkaufs geltenden genauen Vertragsbedingungen, die auch lange nachträglich noch nachprüfbar sind. Für den Preisbestandteil gibt es keinen solchen Standard, daher muss dieser von Ihrer Seite kommen. Das bedeutet, dass Sie eine mit einem Zeitstempel versehene, rekonstruierbare Aufzeichnung des um 14:32 Uhr gültigen Preises und der Signale, die dazu geführt haben, führen müssen. Einfach ausgedrückt: Zu einer hash-verifizierten Aufzeichnung der Geschäftsbedingungen auf der einen Seite gehört eine audit-verifizierte Preisaufzeichnung auf der anderen Seite. Eine auditierbare Preisgestaltung ist dann nicht mehr nur eine Frage der Compliance, sondern wird zum strukturellen Gegenstück zu dem, was LCP einführt.
Der Stapel füllt sich schnell. Unter „Zahlung“ steht, was bezahlt wurde. Unter „Identität“ steht, wer gehandelt hat. Unter „LCP“ steht, zu welchen Bedingungen. Die Frage, die sich jeder Händler selbst stellen muss, lautet: Können seine Preise in diesem Datensatz klar und nachweisbar festgehalten werden – und zwar genau in dem Moment, in dem ein Vertreter eine Entscheidung trifft?.
Häufig gestellte Fragen
Was ist das „Legal Context Protocol“?
Es handelt sich um einen offenen Standard, der im Juni 2026 von der American Arbitration Association, Integra Ledger und einem Zusammenschluss von Technologie- und Zahlungsdienstleistern eingeführt wurde und es KI-Agenten ermöglicht, die rechtlichen Bedingungen, Einwilligungserklärungen und Streitbeilegungsverfahren eines Dienstes zu ermitteln und zu überprüfen. Im Kern handelt es sich um eine einzelne JSON-Datei, die unter einer festen Webadresse veröffentlicht wird.
Benötigt LCP eine Blockchain?
Nein. Der Basisstandard verlangt lediglich eine über HTTPS bereitgestellte JSON-Datei mit einem Feld, das auf ein Dokument mit den Nutzungsbedingungen verweist, das heruntergeladen werden kann. Hash-Verfahren, Signaturen, Schnittstellen zur Streitbeilegung und APIs sind optionale, über den Basisstandard hinausgehende Funktionen und keine Anforderungen; selbst die Hash-Ebene erfordert keine Blockchain.
Was bedeutet LCP für die Preisgestaltung im Einzelhandel?
Dadurch werden die mit einem Preis verbundenen Konditionen maschinenlesbar, sodass ein Handelspartner Preis und Konditionen gemeinsam als ein strukturiertes Angebot bewertet. Zudem werden die Anforderungen an die Nachvollziehbarkeit erhöht: Da die Konditionen zum Zeitpunkt des Verkaufs per Hash-Verifizierung überprüfbar sind, benötigen Einzelhändler Preisangaben, die sie für genau diesen Zeitpunkt rekonstruieren und erläutern können – insbesondere bei dynamischer Preisgestaltung.
