Warum AI-Agent-Piloten vor der Produktion scheitern: vier fehlende Schichten

Kurz gesagt: Agent-Piloten, die es nie in die Produktion schaffen, scheitern fast nie am Modell – sie scheitern, weil darunter vier Schichten fehlen: Semantik, Berechtigungen, Genehmigung und Audit. Ein stärkeres Modell behebt das nicht; diese vier Schichten schon.

Jenes Projekt erntete am Demo-Tag tosenden Applaus.

Der federführende Geschäftsverantwortliche Chen erinnert sich genau: Der Kundenservice-Agent beantwortete vor Ort sieben, acht knifflige Fragen, schnell und präzise, und im Konferenzraum klatschte jemand. Die Führungsebene beschloss auf der Stelle, die Investition auszuweiten, gab Budget, gab Personal. Es war einer der seltenen Glanzmomente seiner Laufbahn.

Vier Monate später wurde dieses Projekt stillschweigend abgeschaltet. Das Budget wurde als versunkene Kosten verbucht, und auch Chens Glaubwürdigkeit in den Augen der Führung bekam dabei einen Knick.

Getötet hat es nicht das Modell – das Modell war durchweg sehr schlagkräftig. Es war eine Frage, die die Rechtsabteilung in einem Go-live-Review stellte: „Können Sie garantieren, dass dieser Agent, wenn er Kunde A antwortet, nicht auch Informationen von Kunde B mit einfließen lässt? Wie beweisen Sie, dass er das nicht kann?”

Niemand konnte es beweisen. Nicht, weil er zwangsläufig etwas durchsickern lassen würde, sondern weil es im System schlicht keinen Ort gab, der ihn aufhalten oder hinterher klar belegen konnte, ob er es getan hatte. In jenem Moment verstand Chen: Von Anfang bis Ende lag das Problem nicht am Modell.

Er ist nicht allein. Branchenberichte nennen unterschiedliche Zahlen, zeigen aber in dieselbe Richtung: Viele Agent-Piloten stoppen vor der Produktion, und viele liefern keinen messbaren Return. So viele Glanzmomente münden am Ende alle in dasselbe stille Ende.

Warum ein stärkeres Modell nicht hilft

Angesichts eines solchen Zeugnisses ist die erste Reaktion der meisten Teams dieselbe: Das Modell ist nicht stark genug. Also wechselt man zum größeren Modell, feilt am präziseren Prompt, setzt komplexere Orchestrierung obendrauf.

Die Bestehensquote bewegt sich kaum. Denn die Wahrheit steckt in einem anderen Datensatz: Vom Piloten zur Produktion entfallen rund 80 % des Arbeitsaufwands auf Data Engineering, Governance, Prozessintegration und Messung, das Modell selbst macht nur einen winzigen Teil aus; bei den gestoppten Projekten nannten 44 % „Governance-Nacharbeit” als das vorrangige Hindernis. Die allermeisten Piloten sterben nicht an „nicht klug genug”, sondern an mehreren Schichten, die unter dem Modell fehlen – und die lassen sich durch kein noch so starkes Modell ergänzen, weil sie schlicht nicht auf der Seite des Modells liegen.

Erst einen PoC zur schnellen Validierung – ist das etwa falsch?

Hier muss man einen Einwand aufgreifen, der unanfechtbar klingt: Erst eine Demo bauen, einen PoC laufen lassen, um den Wert zu validieren, ist doch das richtige Vorgehen – sollte man eine Demo etwa von Anfang an überengineeren?

Der PoC an sich ist nicht falsch. Falsch ist, dass er das Falsche validiert.

Chens Demo validierte, „ob das Modell gut antwortet” – und genau das ist im ganzen Projekt der Teil, um den man sich am wenigsten Sorgen machen muss. Was sie nicht validierte und auch so entworfen war, es nicht zu berühren, sind jene vier Schichten, die wirklich über Leben und Tod entscheiden (Berechtigungen, Definition, Genehmigung, Spurhaltung). So gab der PoC der Führung ein falsches Vertrauen: Wenn die Demo so glatt läuft, dürfte das Risiko einer ausgeweiteten Investition doch gering sein? Erst vier Monate später entdeckten alle, dass die Glätte der Demo und die Machbarkeit in der Produktion kaum miteinander zusammenhängen.

Der richtige PoC sollte also nicht nur fragen „kann das Modell richtig antworten”, sondern mehr noch „kann diese Antwort in einer realen Umgebung mit vollständigen Berechtigungen, Genehmigungen und Spurhaltung sicher der richtigen Person geliefert werden”. Validiert man das falsche Objekt, ist eine umso schönere Demo eine umso tiefer vergrabene Grube.

Eine Demo braucht diese vier Schichten von Natur aus nicht – darum täuscht sie Sie

Warum klafft die Glätte der Demo so vollständig von der Produktion auseinander? Weil eine gute Demo so entworfen ist, dass sie keine Governance-Frage auslöst – sie nutzt einen exportierten Datensatz, zeigt ihn einer Person und fragt nicht „darf dieser Nutzer das sehen”, „muss dieser Schritt erst genehmigt werden”.

Daraus folgt eine grausame Schlussfolgerung: Jede erfolgreiche Demo verbirgt systematisch genau den Grund, an dem sie künftig scheitern wird. Je schöner das, was Sie sehen, desto tiefer sind jene Schichten versteckt. In dem Moment, in dem Produktivdaten angebunden werden, ändert sich die Umgebung grundlegend, und über Erfolg oder Misserfolg entscheidet, ob unter dem Modell diese vier Schichten liegen:

Was es beantworten können muss	Welche Schicht fehlt	Was passiert, wenn sie fehlt
Was meint „Kunde” eigentlich? Wo ist die Definition?	① Semantische Schicht	Am Thema vorbei, Definitionen kollidieren, das Geschäft erkennt es nicht an
Werden Informationen von Kunde A auf Kunde B angewendet?	② Berechtigungsschicht	Berechtigungsüberschreitung mit Datenleck, Veto der Rechtsabteilung
Sollte dieser Schritt erst auf eine menschliche Genehmigung warten?	③ Prozess- und Genehmigungsschicht	Was stoppen sollte, stoppt nicht, niemand traut sich, es handeln zu lassen
Wer hat diesen Vorgang wann und worauf gestützt getätigt?	④ Audit-Schicht	Kein Beweis vorlegbar, Compliance fängt es direkt ab

Chens Projekt starb an Zeile ②.

Warum diese vier Schichten immer fehlen

Warum baut man sie dann nicht von Anfang an? Weil nach traditioneller Vorgehensweise jede Schicht ein großer Klumpen querschnittlicher harter Ingenieursarbeit ist: Die semantische Schicht muss die Daten von einem Dutzend Systemen zu einem einheitlichen Objektmodell ausrichten; die Berechtigungsschicht muss die über die Anwendungscodes verstreuten Regeln zu einer konsistenten Policy zusammenführen; die Genehmigung muss an das bestehende System angebunden werden; das Audit muss die Handlungen von Mensch und KI in dasselbe Log zusammenführen. Sie sind nicht Teil einer einzelnen Funktion, sondern das Fundament unter allen Funktionen – schmutzig und langsam, und allesamt der Teil, den man in der Demo nicht sieht.

Schlimmer noch: Viele Teams bauen diese vier Schichten für jeden Piloten einzeln neu. Ist diese Runde vorbei und wechselt das Szenario, werden die vier Schichten von vorn aufgebaut. Budget und Geduld verbrauchen sich vollständig im wiederholten Gießen des Fundaments.

Ob Ihr Pilot es in die Produktion schafft, müssen Sie nicht vier Monate abwarten; je eine Frage an die vier Schichten genügt:

1. Semantik: Stellt eine andere Person dem Agent dieselbe Geschäftsfrage, ist die Definition konsistent? Oder antwortet jeder anders?
2. Berechtigung: Können Sie beweisen, dass er jeden nur die Daten sehen lässt, für die er berechtigt ist?
3. Genehmigung: Hält er bei hochriskanten Handlungen automatisch an und wartet auf eine Unterschrift, oder tut er es einfach?
4. Audit: Können Sie zu einer beliebig herausgegriffenen Sache, die er getan hat, den vollständigen Hergang aufrufen?

Beantworten Sie alle vier mit „ja”, gehören Sie mit hoher Wahrscheinlichkeit zu jenen 12 %. Beantworten Sie eine mit „ungewiss”, dann sind Sie der nächste Chen.

Wie jene 12 % aussehen

Es lohnt sich, ein Gegenbeispiel zu betrachten, denn sein Unterschied zu Chen liegt gerade nicht am Modell.

Ein anderes Unternehmen baute einen fast identischen Kundenservice-Agent und verwendete dabei ein sogar etwas schlichteres Modell. Aber es startete nicht damit, „das Modell schön antworten zu lassen”, sondern baute zuerst die vier Schichten auf einer einheitlichen Runtime auf: Kunde, Auftrag und Serviceauftrag sind dasselbe Objektset (Semantik komplett); der Agent handelt in der Identität des fragenden Mitarbeiters und kann nur die Daten sehen, für die dieser Mitarbeiter berechtigt ist (Berechtigung komplett); Rückerstattungen über dem Limit werden automatisch an einen Menschen weitergeleitet (Genehmigung komplett); jede Handlung geht ins selbe Log ein (Audit komplett).

Ihr Demo-Tag war nicht so spektakulär wie bei Chen – stabil beantwortet, aber nicht atemberaubend. Doch beim Go-live-Review stellte die Rechtsabteilung dieselbe Frage, und der Projektleiter rief an Ort und Stelle das Berechtigungsset und einen Audit-Datensatz auf und bewies, dass der Agent nur in der Identität des Mitarbeiters die Daten sehen kann, für die der Mitarbeiter berechtigt ist, und dass eine Berechtigungsüberschreitung von der Runtime an Ort und Stelle abgefangen und protokolliert wird. Die Rechtsabteilung nickte, das Projekt wurde freigegeben.

Genau hier liegt der Unterschied: Jene 12 %, die es in die Produktion schafften, gewannen nicht beim Modell, sondern hatten die vier Schichten vorab aufgebaut, sodass sie der Frage „wie beweisen Sie das” standhielten. Chen verlor nicht am technischen Anspruch, sondern an der Reihenfolge – er stellte das, worum man sich am wenigsten sorgen muss (das Modell), nach vorn und ließ das, was wirklich über Leben und Tod entscheidet (die vier Schichten), bis zum Schluss übrig.

Erst eine kalte Dusche: Auch mit vier Schichten ist Erfolg nicht garantiert

Hier muss man ehrlich einen Satz sagen, sonst wird es wieder eine Wunderpille.

Es gibt auch Studien, die sagen, dass 83 % der Piloten am Change Management sterben – die Leute nutzen es nicht, der Prozess ändert sich nicht, die Organisation erkennt es nicht an. Das widerspricht „am Fehlen der vier Schichten sterben” nicht, es sind zwei Seiten derselben Sache: Ein System, das die Rechtsabteilung nicht freizugeben wagt und dessen Definition das Geschäft nicht anerkennt, bekommt nicht einmal die Eintrittskarte, von der Organisation übernommen zu werden; aber umgekehrt: Vollständige vier Schichten verschaffen nur die Eintrittskarte, sie bedeuten nicht, das Spiel gewonnen zu haben.

Technische Reife ist eine notwendige Bedingung, keine hinreichende. Die vier Schichten machen die Handlungen des Agent kontrollierbar, nachvollziehbar, erklärbar, sodass die Organisation ihm überhaupt erst vertrauen und ihn übernehmen kann – aber damit es wirklich ankommt, muss noch jemand den Prozesswandel vorantreiben und jemand bereit sein, seine Gewohnheiten zu ändern. Wer sagt „füllt diese vier Schichten auf, und der Pilot wird ganz sicher erfolgreich sein”, verspricht zu viel. Sie räumt die technischen Todesursachen aus, nicht die organisatorischen.

Der Ausweg: Die vier Schichten kommen aus der Runtime, nicht aus dem Neuaufbau jedes Projekts

Was die Erfolgschancen verändert, ist nicht ein stärkeres Modell, sondern diese vier Schichten nicht mehr zur Eigenbau-Ingenieursarbeit jedes Projekts zu machen, sondern zu mitgelieferten Fähigkeiten der Runtime.

Nehmen wir ein Szenario zur Anlagenreparatur. Sie deklarieren nur das Objekt und seine Berechtigungen:

export const RepairTicket = ObjectSchema.create({
  name: 'ops_repair_ticket',
  label: 'Reparaturauftrag',
  fields: {
    device: Field.lookup('ops_device', { label: 'Anlage', required: true }),
    cost: Field.currency({ label: 'Reparaturkosten', min: 0 }),
  },
});

Die restlichen vier Schichten liefert die Runtime (ObjectOS) auf einen Schlag mit: Semantische Schicht – diese Deklaration selbst ist die Grundlage, auf der der Agent das Geschäft versteht; Berechtigungsschicht – wer Reparaturaufträge lesen und schreiben darf, verifiziert die Runtime bei jedem Aufruf zwingend; Prozess- und Genehmigungsschicht – „Reparaturkosten über dem Limit durchlaufen eine Genehmigung” ist ein am Objekt hängender deklarativer Prozess, der automatisch pausiert und auf eine Unterschrift wartet; Audit-Schicht – jede Handlung von Mensch und Agent geht ins selbe Log ein. Beim nächsten Szenario müssen diese vier Schichten nicht neu aufgebaut werden, man muss nur ein paar weitere Objekte deklarieren. Jene „80 % wiederholtes Fundament-Gießen” werden auf ein paar hundert Zeilen Deklaration zusammengedrückt.

Wäre Chens Projekt so gebaut gewesen, wäre jene Frage der Rechtsabteilung kein Todesurteil gewesen: Er hätte an Ort und Stelle das Berechtigungsset aufrufen und beweisen können, dass der Agent nur in der Identität des Fragenden die Daten sehen kann, für die der Fragende berechtigt ist – Schicht ② läge ohnehin unter seinen Füßen, und er hätte wie jene 12 % an Ort und Stelle freigeben können.

Schlusswort

Teams, die es in die Produktion schaffen, verlassen sich fast nie nur auf das beste Modell. Sie verlassen sich auf jene vier Schichten unter dem Modell – Semantik, Berechtigung, Prozess, Audit –, die fest stehen; und darauf, dass die Organisation es wirklich in den Einsatz bringt. Ersteres ist die Eintrittskarte, Letzteres das Spiel, man braucht beides.

Wenn Ihr Agent-Pilot also wieder feststeckt, wechseln Sie nicht voreilig das Modell. Stellen Sie die Frage, die Chen erst vier Monate später zu stellen lernte: Wie viele dieser vier Schichten unter seinen Füßen sind eigentlich gebaut? Das ist weit billiger, als noch eine Prompt-Version zu feilen, und kann ein Projekt und die Glaubwürdigkeit eines Menschen retten.

npm i -g @objectstack/cli && os start

Deklarieren Sie ein Objekt und seine Berechtigungen, lassen Sie einen Agent es nutzen – Sie werden feststellen, dass die vier Schichten bereits unter seinen Füßen liegen, und Sie haben nur ein paar Dutzend Zeilen geschrieben.