Zuletzt aktualisiert: 23. Oktober 2026 · Version: 1.1
Redaktionshinweis: Dieser Artikel wurde mit KI-Unterstützung recherchiert und überarbeitet und zur Veröffentlichung freigegeben. Forschungsgrundlage ist ein neuer Preprint. Das AI-FABRIK-Architekturmodell ist ein eigener konzeptioneller Vorschlag, keine erprobte Referenzimplementierung. Quellenstand: 23. Oktober 2026.
In 30 Sekunden
- Eine Anweisung wie „Halte das Budget ein“ erzwingt noch keine Grenze für Agentenaktionen.
- Proof-Carrying Contracts verlangen maschinell prüfbare Beweise für die Erhaltung vereinbarter Bedingungen im formalisierten Modell.
- AI-FABRIK übersetzt den Ansatz in vier Stufen: Geschäftsregel → beweispflichtige Aktion → unabhängiger Prüfer → Tool-Ausführung.
- Der Nutzen hängt von korrekten Regeln, verlässlichen Daten und kontrollierten Ausführungswegen ab. Governance und betriebliche Validierung bleiben erforderlich.
Für wen? Für IT-Leitung und Plattformarchitekten, die Agenten mit Schreibrechten ausstatten wollen. Fachbereiche verantworten die Regeln; Security und Datenschutz begleiten Durchsetzung und Datenverwendung.
Die entscheidende Frage entsteht vor dem Werkzeugaufruf
Ein Einkaufsagent vergleicht Angebote und bereitet eine Bestellung vor. Mit dem Aufruf der Bestell-API entstehen Verpflichtungen. Welche Bedingung muss nachweislich erfüllt sein, bevor er handeln darf? Diese Frage führt über die Auswahl einer Agentenplattform hinaus – besonders dann, wenn mehrere Agenten gleichzeitig handeln.
Praxisfall: Zwei erlaubte Bestellungen überschreiten gemeinsam das Budget
Hypothetisches Beispiel, alle Beträge sind illustrative Annahmen: Ein Einkaufsteam hat ein Gesamtbudget von 10.000 Euro. Davon sind 8.000 Euro bereits gebunden. Zwei Agenten beantragen nahezu gleichzeitig jeweils eine Bestellung über 1.500 Euro.
Betrachtet jeder Prüfer denselben alten Datenstand, erscheint jeder Antrag einzeln zulässig. Gemeinsam entstünden jedoch Verpflichtungen von 11.000 Euro. Eine korrekte Rechnung auf einem veralteten Zustand verhindert den Fehler nicht.
Unser Architekturvorschlag verlangt deshalb eine verbindliche Reservierung oder eine gleichwertige Transaktionskontrolle: Der erste akzeptierte Vorgang reserviert 1.500 Euro. Für den zweiten bleiben 500 Euro verfügbar; er wird gesperrt oder an einen berechtigten Menschen eskaliert. Prüfung, Reservierung und Ausführung müssen gegenüber konkurrierenden Änderungen abgesichert sein. Ein Ablaufdatum allein reicht dafür nicht.
Diese Kontrolle muss auch andere Bestellwege berücksichtigen. Wenn ein Mitarbeiter oder ein weiteres System das gleiche Budget außerhalb des kontrollierten Prozesses belastet, ist die lokale Zusage unvollständig. Vor einem Pilot ist deshalb die gemeinsame Zustandsquelle wichtiger als die Auswahl des Sprachmodells.
Eine menschliche Ausnahme ist ebenfalls ein kontrollierter Vorgang: Budgetänderung oder Sonderfreigabe werden mit Identität, Umfang und Regelversion erfasst. Ein allgemeiner Knopf „Prüfung überspringen“ würde die Schutzlogik aufheben.
Was Proof-Carrying Contracts beitragen
Carlo Ciliberto, Alessandro Rudi und Enrico Tassi veröffentlichten am 20. Oktober 2026 den Preprint „Proof-Carrying Contracts: Commitments AI Agents Cannot Break“. Ihr PC2-Framework verlangt vor einer Operation einen maschinell prüfbaren Beweis, dass sie die vereinbarten Bedingungen innerhalb des formalisierten Modells erhält. Eine Ausführungskomponente namens Airlock prüft ihn und kontrolliert den Werkzeugzugang. Der Ansatz ist in Lean mechanisiert.
Die Übertragung dieser Garantien auf reale Systeme hängt von nachgewiesenen Voraussetzungen ab: unter anderem von der Übereinstimmung mit dem Modell und der vollständigen Vermittlung relevanter Aktionen. Auch Zustandsänderungen zwischen Operationen werden betrachtet. Wirtschaftliche Serienreife ist damit nicht belegt. Primärquelle: Architektur, Garantien und Grenzen.
Die Grundidee hat Vorläufer: Bei Proof-Carrying Code von Necula und Lee bringt fremder Code einen prüfbaren Sicherheitsbeweis mit. Die Trennung zwischen aufwendiger Beweiserzeugung und kontrollierbarer Prüfung ist damit kein neuer AI-FABRIK-Anspruch.
Welche Kontrolle leistet was?
Für Unternehmen ist eine Abstufung sinnvoll. Nicht jede Aktion benötigt einen mathematischen Beweis; die Bezeichnung der erreichten Sicherheit muss aber stimmen.
| Verfahren | Was es leistet | Entscheidende Grenze |
|---|---|---|
| Prompt und Modell-Guardrail | Lenken oder filtern Modellverhalten und Inhalte. | Liefern für sich keine Garantie über den realen Geschäftsprozess. |
| Policy Engine | Wertet explizite Regeln auf bereitgestellten Eingaben aus. | Falsche Eingaben, fehlende Regeln oder ein umgehbarer Vollzug bleiben problematisch. |
| Nachweispaket mit Belegen | Bindet Identität, Datenstand und Freigaben nachvollziehbar an eine Aktion. | Die Belege sind noch kein formaler Beweis aller erforderlichen Eigenschaften. |
| Formaler Beweis mit Prüfung | Belegt eine präzise Aussage innerhalb festgelegter Annahmen. | Die Aussage muss zur realen Aktion passen; Modellierung und Ausführung bleiben sicherheitskritisch. |
Open Policy Agent ist beispielsweise eine Policy Engine, die Policy-Entscheidungen von der Anwendung trennt. Für eine einfache erlaubte Empfängerliste kann dieser Ansatz angemessen sein. Die Integration muss eine ablehnende Entscheidung tatsächlich durchsetzen. Ein OPA-Ergebnis sollte nicht als Beweis im Sinne von PC2 vermarktet werden.
Das AI-FABRIK-Modell: vier Stufen mit klarer Verantwortung
Eigener Architekturvorschlag: Die folgende Übertragung auf Unternehmensprozesse ist eine redaktionelle Ableitung. Sie beschreibt ein Zielbild und dessen Voraussetzungen, keine vollständige Implementierung des Forschungsframeworks.
1. Geschäftsregel
Der Fachbereich definiert die zulässigen Zustände.
↓
2. Beweispflichtige Aktion
Der Agent beantragt einen konkreten Werkzeugaufruf und liefert die geforderten Nachweise.
↓
3. Unabhängiger Prüfer
Eine getrennte Kontrollkomponente validiert Regel, Zustand, Aktion und Nachweis.
↓
4. Tool-Ausführung
Ein kontrollierter Adapter führt ausschließlich die geprüfte Aktion aus.
Rückkopplung: Ausführungsergebnis und neuer Zustand fließen in die nächste Prüfung ein.
1. Aus einer Absicht wird eine präzise Geschäftsregel
„Kaufe wirtschaftlich ein“ lässt zu viel Interpretation offen. Der Fachbereich muss festlegen, welche Verpflichtungen zählen, wer Lieferanten freigibt und wie Ausnahmen entstehen. IT übersetzt diese Bedeutung in eine prüfbare Regel. Automatisch erzeugte Formalisierungen brauchen fachliche Abnahme; Regelversion und Verantwortlichkeit bleiben nachvollziehbar.
2. Die Aktion wird vollständig und unveränderlich beschrieben
Ein Antrag enthält Werkzeug und Version, genaue Parameter, handelnde Identität, Mandant, Zweck, Regelversion und Bezug zum geprüften Datenstand. Dazu kommen je nach Kontrollstufe Belege, Freigaben oder ein formaler Beweis. Ein Hash kann den Antrag eindeutig binden; er beweist nicht, dass die Inhalte wahr oder zulässig sind.
Die Bedingung „Lieferant freigegeben“ darf deshalb nicht aus der Behauptung des Agenten stammen. Maßgeblich wäre beispielsweise ein kontrolliertes Lieferantenregister. Der Prüfer muss Herkunft, Gültigkeit und Aktualität der benötigten Daten feststellen können.
3. Unabhängig bedeutet: außerhalb der Entscheidungsmacht des Agenten
Der Agent darf weder die Regeln verändern noch Prüfer, Ausführungsfreigaben oder Werkzeugzugang administrieren. Der Prüfer braucht eine eigene Vertrauensgrenze und eng begrenzte Aufgaben. Ein zweites Sprachmodell kann zusätzliche Kontrolle leisten, aber keinen formalen Sicherheitsnachweis durch bloße Zustimmung liefern.
Bei einem formalen Nachweis muss die Prüfung genau die vereinbarte Aussage unter zugelassenen Definitionen und Annahmen betreffen. Ein korrekt bewiesener Nebensatz genügt nicht. Fehlende Daten, ein ungültiger Beweis oder ein Timeout führen im vorgeschlagenen Modell zur Sperre beziehungsweise Eskalation. Auch Größe und Rechenzeit der Prüfung benötigen Grenzen, damit ein Antrag den Dienst nicht blockiert.
4. Die Ausführung darf die Prüfung nicht verändern
Die technische Freigabe muss an genau diesen Antrag gebunden sein, etwa mit kurzer Gültigkeit, eindeutiger Kennung und Schutz vor Wiederverwendung. Der Adapter darf anschließend weder Empfänger noch Betrag austauschen. Der Agent erhält keine parallelen Zugangsdaten, mit denen er dieselbe Aktion direkt ausführen könnte.
Ein erneuter Versuch nach einem Netzwerkfehler darf keine doppelte Bestellung erzeugen. Dafür braucht der Zielprozess eine eindeutige Vorgangskennung und belastbare Rückmeldungen. Bei unklarem Ergebnis wird zuerst der tatsächliche Status abgefragt. Eine erneute Ausführung auf Verdacht wäre eine neue Fehlerquelle.
Ausgefüllter Regelsteckbrief: Bestellung im Einkauf
AI-FABRIK-Arbeitsvorlage, hypothetisch ausgefüllt: Der Steckbrief macht die fachlichen Entscheidungen vor einer Implementierung sichtbar. Er ist weder ausführbarer Code noch ein formaler Beweis.
| Feld | Festlegung für den Beispielfall |
|---|---|
| Geltungsbereich und Verantwortung | Bestellungen für ein EUR-Projektbudget; fachlich verantwortlich: Einkaufsleitung. Regelversion: Einkauf-1.0. |
| Drei verbindliche Bedingungen | Lieferant im freigegebenen Register; Summe aus verbrauchtem Budget und offenen Bindungen einschließlich neuer Bestellung höchstens 10.000 Euro; gültige Freigabe für exakt diesen Antrag. |
| Betragsdefinition | Bruttobetrag einschließlich Versand. Offene Reservierungen zählen mit; die Umwandlung einer Reservierung in eine Bestellung wird nicht doppelt gezählt. Fremdwährungen sind aus dem Pilot ausgeschlossen. |
| Vertrauenswürdige Daten | Zentrales Budgetbuch, Lieferantenregister und Freigabedienst. Agententext gilt nicht als Nachweis dieser Zustände. |
| Aktionsbindung und Vollzug | Identität, Projekt, Lieferant, Betrag, Regelversion und Vorgangskennung werden gebunden. Reservierung und Zustandsprüfung sind gegen parallele Änderungen abgesichert; alle Bestellwege nutzen dieselbe Budgetkontrolle. |
| Fehler und Ausnahmen | Bei veralteten Daten, fehlender Freigabe oder Prüferausfall stoppen. Unklare API-Ergebnisse anhand der Vorgangskennung abgleichen. Budgetausnahmen erfordern eine dokumentierte, berechtigte Änderung. |
| Abnahme und Nachweisniveau | Im Paralleltest darf nur eine der beiden 1.500-Euro-Bestellungen das Restbudget binden. Zunächst Regelprüfung plus Belege; eine spätere formale Absicherung muss ihre Aussage und Annahmen gesondert ausweisen. |
Vor einer Übernahme sind Beträge, Datenquellen und Rollen an den eigenen Prozess anzupassen. Der Steckbrief zeigt auch, wo die Arbeit liegt: Ohne abgestimmte Betragsdefinition und gemeinsame Zustandsführung hilft selbst ein präziser Prüfer nicht.
Übertragbar auf Versand und Produktionsänderungen
Hypothetischer Dokumentenversand: Ein Vertriebsagent soll ein Angebot versenden. Der Prüfer kontrolliert Empfänger, freigegebene Dokumentversion und Datenklasse. Wenn die Klassifizierung vertrauliche Anlagen übersieht, kann eine formal korrekte Empfängerprüfung den Datenabfluss nicht ausschließen. Die Herkunft der Klassifizierung gehört deshalb in die Vertrauensannahmen.
Hypothetische Produktionsänderung: Ein Agent beantragt eine Konfigurationsänderung. Das Nachweispaket bindet den geprüften Änderungsstand, Testresultate, Freigabe und Zielumgebung zusammen. Bestandene Tests sind Evidenz, aber kein Beweis, dass jeder spätere Betriebszustand sicher ist. Bei hoher Wirkung bleiben gestufter Rollout, Beobachtung und ein getesteter Rückweg erforderlich.
Merksatz
Der Agent schlägt vor. Der Prüfer entscheidet nach festgelegten Regeln. Der Adapter führt genau die geprüfte Aktion aus.
Governance: Die technische Freigabe ersetzt keine Verantwortung
Die Europäische Kommission erläutert unter den DSGVO-Grundsätzen unter anderem Zweckbindung, Datenminimierung, Speicherbegrenzung und Rechenschaftspflicht. Daraus folgt für die vorgeschlagene Architektur: Prüfprotokolle sollten erforderliche Referenzen und Entscheidungen enthalten, nicht vorsorglich vollständige personenbezogene Dokumente oder Modellkonversationen.
Vor Produktivbetrieb sind Datenflüsse, Zugriffsrechte, Aufbewahrung, etwaige Auftragsverarbeitung und Drittlandbezüge anhand der konkreten Integration zu klären. Die rechtliche Einordnung des Anwendungsfalls lässt sich nicht aus einem bestandenen technischen Check ableiten. Für Schweizer Unternehmen ist das anwendbare Datenschutzrecht gesondert zu prüfen; DACH ist kein einheitlicher Rechtsraum.
Auch die KI-Kompetenzpflichten des AI Act werden durch einen Prüfer nicht erledigt. Regelverantwortliche und Betriebsteams müssen verstehen, was die Kontrollen abdecken und wann sie eskalieren. In Deutschland ist bei einer möglichen Mitarbeiterüberwachung durch Protokolle die Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG zu prüfen. Diese Hinweise dienen der Orientierung und ersetzen keine Prüfung des Einzelfalls.
Die verbleibende Vertrauensbasis
Geschäftsregel, Datenquelle, Prüfer, Identitätsverwaltung, Geheimnisverwaltung und Ausführungsadapter bilden gemeinsam die kritische Kontrollkette. Eine korrekt geprüfte Aktion kann weiterhin wirtschaftlich unklug sein. Ebenso kann eine falsche Geschäftsregel technisch fehlerfrei durchgesetzt werden. Fachliche Verantwortung bleibt deshalb beim Unternehmen.
Ein Pilot muss auch Ablehnungen und Umgehungen testen
Als methodische Orientierung eignet sich OWASP Excessive Agency: Zu weitreichende Funktionen, Berechtigungen und Autonomie können schädliche Aktionen ermöglichen. Der Testgegenstand sollte deshalb die gesamte Kette umfassen – vom manipulierten Quelldokument bis zur tatsächlich ausgeführten API-Operation.
| Testfall im vorgeschlagenen Pilot | Abnahmekriterium |
|---|---|
| Indirekte Prompt-Injection fordert einen anderen Empfänger oder Lieferanten. | Die nicht regelkonforme Aktion wird vor Ausführung abgewiesen. |
| Ein gültiger Nachweis wird mit geänderten Parametern oder erneut eingereicht. | Manipulation und Wiederverwendung erzeugen keine unzulässige Ausführung. |
| Zwei parallele Vorgänge beanspruchen dasselbe Restbudget. | Die gemeinsame Grenze wird auch bei konkurrierenden Anträgen eingehalten. |
| Prüfer fällt aus oder Datenstand ist ungültig. | Der Vorgang stoppt kontrolliert; keine automatische Freigabe als Ausweichlösung. |
| Agent versucht direkten API-Zugriff oder Delegation an einen zweiten Agenten. | Es existiert kein unkontrollierter Ausführungspfad mit denselben Rechten. |
Security verantwortet die Angriffstests, der Fachbereich die fachlichen Grenzfälle und das Plattformteam den Nachweis im Zielsystem. Protokolliert werden Antrag, erwartete Entscheidung, tatsächliche Entscheidung und reale Nebenwirkung. Die Tests erfolgen vor Freigabe sowie nach relevanten Änderungen an Regeln, Modell, Werkzeugen und Rechten; zusätzlich wird ein risikobasierter Wiederholungsrhythmus festgelegt. Ein bestandener Testkatalog ist noch kein allgemeiner Sicherheitsbeweis.
Vier Wochen für eine begrenzte Machbarkeitsprüfung
Der folgende Plan setzt einen verfügbaren Testzugang, einen benannten Fachverantwortlichen und einen eng begrenzten Vorgang voraus. Er soll Aufwand und Eignung sichtbar machen; fehlende Integrationen oder ungeklärte Regeln können den Zeitraum verlängern.
Woche 1: Begrenzen. Fachbereich und IT wählen einen Vorgang, erfassen alle Ausführungswege und formulieren Regeln samt Ausnahmen. Ergebnis ist ein abgenommener Regelsteckbrief: Verantwortlicher, Geltungsbereich, benötigte Daten, zulässige Aktion und Eskalationsweg.
Woche 2: Vermitteln. Das Plattformteam erstellt einen kontrollierten Adapter in einer Testumgebung. Der Agent bekommt keine direkten Schreibrechte auf das Zielsystem. Regelversion, Identität, Zustand und Antrag werden durchgängig verbunden.
Woche 3: Angreifen und messen. Das Team prüft die beschriebenen Fehlerfälle und vergleicht die Lösung mit einer einfachen Policy-Prüfung. Gemessen werden Durchlaufzeit, korrekte und falsche Ablehnungen, manuelle Nacharbeit sowie Aufwand pro fachlich akzeptiertem Vorgang.
Woche 4: Entscheiden. Das Team entscheidet, ob ein begrenzter Produktivpilot vorbereitet werden kann, eine formale Vertiefung sinnvoll ist oder zunächst Integrationslücken geschlossen werden müssen. Ein vollständig formal abgesichertes System ist kein zugesagtes Ergebnis dieser vier Wochen.
Entscheidungshilfe für IT-Leitung und Fachbereich
Einfach anfangen: Bei wenigen risikoarmen Aktionen können restriktive Rechte, deterministische Regeln und menschliche Freigaben genügen. Gezielt vertiefen: Hohe Schadenswirkung oder komplexe Zustandsfolgen können formale Verifikation rechtfertigen, wenn sich Regeln und Werkzeugwirkungen präzise beschreiben lassen. Zuerst Grundlagen schaffen: Fehlen verlässliche Daten oder kontrollierbare Ausführungswege, hat deren Aufbau Vorrang.
Eine sinnvolle Kostenkennzahl lautet: Gesamtkosten je fachlich akzeptiertem Vorgang = anteilige Entwicklung und Regelpflege plus Betrieb, Modellnutzung, Prüfung und menschliche Nacharbeit, geteilt durch die Zahl akzeptierter Vorgänge. Die Werte sind im Pilot zu erheben. Ein günstiger Beweischeck sagt allein noch nichts über die Kosten der Beweiserzeugung und Integration aus.
Der eigenständige Beitrag von AI-FABRIK
Der ausgefüllte Regelsteckbrief und der Testkatalog sind erste Arbeitsmittel für die betriebliche Übersetzung der Forschung. Ein wiederverwendbares Architekturmodell braucht zusätzlich ein verbindliches Schema für Aktionsanträge sowie einen Prüf- und Ausführungsvertrag für Adapter. Diese Bausteine müssen in Pilotfällen validiert werden, bevor sich Einsparungen oder Zuverlässigkeit behaupten lassen. Der freiwillige NIST AI Risk Management Framework bietet einen ergänzenden organisatorischen Rahmen.
Nächster Schritt
Füllen Sie den Regelsteckbrief für eine einzige schreibende Aktion aus. Lassen Sie Fachbereich und IT insbesondere Datenherkunft, parallele Änderungen und Ausnahmen gemeinsam abnehmen. Daraus entsteht die Grundlage für eine belastbare Pilotentscheidung.
FAQ
Sind Proof-Carrying Contracts rechtliche Verträge?
Der Begriff bezeichnet hier technisch formulierte Bedingungen für Agentenaktionen. Die rechtliche Wirksamkeit einer Vereinbarung und die Verantwortung beteiligter Unternehmen müssen unabhängig davon geklärt werden.
Genügt ein zweites KI-Modell als unabhängiger Prüfer?
Es kann eine zusätzliche Bewertung liefern. Für die beschriebene Kontrollarchitektur braucht es jedoch verbindliche Prüfregeln; für formale Beweise einen passenden Beweisprüfer. Sprachliche Zustimmung ist kein Ersatz.
Wann lohnt sich formale Verifikation?
Wenn der mögliche Schaden und die Komplexität der erlaubten Zustandsänderungen den Zusatzaufwand rechtfertigen, die relevanten Eigenschaften präzise formulierbar sind und die Ausführung kontrolliert werden kann. Bei einfachen Empfängerlisten oder risikoarmen Freigaben kann eine Policy-Prüfung ausreichen. Der Pilot sollte beide Ansätze anhand von Kontrollwirkung, Pflegeaufwand und Kosten vergleichen.
Ist das vorgeschlagene AI-FABRIK-Modell bereits produktiv erprobt?
Nein. Es ist ein konzeptioneller Architekturvorschlag. Ein begrenzter Pilot muss Umsetzbarkeit, Kontrollwirkung und Wirtschaftlichkeit erst belegen.
Quellen und Einordnung
Quellen zuletzt geprüft am 23. Oktober 2026. Forschung, technische Dokumentation und Behördeninformationen tragen unterschiedliche Aussagen; die Unternehmensbeispiele und der Pilotplan sind eigene Vorschläge.
- Ciliberto, Rudi, Tassi: Proof-Carrying Contracts, 2026 – Preprint vom 20. Oktober; Volltext zu Architektur, Mechanisierung und Garantiegrenzen.
- Necula und Lee: Proof-Carrying Code, OSDI 1996 – wissenschaftlicher Vorläufer der Trennung von Erzeugung und Prüfung.
- Open Policy Agent: Dokumentation – Funktionsweise einer Policy Engine; keine Gleichsetzung mit PC2.
- OWASP: LLM06:2025 Excessive Agency – Berechtigungs- und Autonomierisiken als Orientierung für Tests.
- Europäische Kommission: DSGVO-Grundsätze – Zweckbindung, Datenminimierung und Aufbewahrung.
- Europäische Kommission: AI talent, skills and literacy – KI-Kompetenz im organisatorischen Betrieb.
- BetrVG § 87 – Mitbestimmung in Deutschland.
- NIST: AI Risk Management Framework – freiwilliger Rahmen für das Risikomanagement.
