Wenn ein großes Sprachmodell eine Anwaltsprüfung bestehen kann, gehen Unternehmen davon aus, dass es Versicherungsansprüche, onkologische Aktenprüfungen oder Umsatzprozesse mit minimaler Aufforderung bearbeiten sollte. Die meisten Teams, mit denen wir zusammenarbeiten, haben diese Annahme in einem Pilotprojekt getestet und die Antwort auf die harte Tour gelernt.

Die Adoptionszahlen sprechen eine deutlichere Sprache als der Hype. 22 % der Gesundheitsorganisationen haben bereits domänenspezifische KI-Tools implementiert. Das ist ein 7-facher Sprung gegenüber 2024 und ein 10-facher gegenüber 2023. Im Versicherungswesen, 34 % der Versicherer berichten von einer vollständigen Integration von KI in ihre Wertschöpfungskette im Jahr 2025. Die Entwicklung geht nicht in Richtung generischer Chatbots. Sie geht hin zu Systemen, die für einen spezifischen Workflow entwickelt wurden, wobei die Einschränkungen und Daten dieses Workflows fest integriert sind.

Technische Führungskräfte sollten sich nun überlegen, welche Workflows die architektonische Investition in ein domänenspezifisches System rechtfertigen und welche nicht. Wenn Fehler finanzielle, klinische oder rechtliche Auswirkungen haben, liegt das Versagen selten daran, dass das Modell offensichtlich falsch ist. Es sind Designfehler. Die Architektur, der operative Kontext und die Governance waren nie für diese Aufgabe ausgelegt.

Dieser Artikel behandelt, wo generische Agenten in der Produktion versagen, was ein domänenspezifisches System tatsächlich erfordert und welche Kriterien Ihnen sagen, welche Workflows ein solches System benötigen.

Warum generische Agenten in der Produktion versagen

Die NANDA-Forschung des MIT hat die Lücke zwischen Pilotprojekt und Produktion quantifiziert und festgestellt, dass 95 % der generativen KI-Pilotprojekte keinen messbaren Gewinn-und-Verlust-Effekt erzielen. Der Bericht identifiziert die Ursache als Integration und Passung zum Workflow, nicht als Modellfähigkeit. Darüber hinaus prognostiziert Gartner, dass mehr als 40 % der agentenbasierten KI-Projekte bis Ende 2027 eingestellt werden, unter Verweis auf steigende Kosten, unklaren Geschäftswert und unzureichende Risikokontrollen. Keine der Zahlen besagt, dass die Technologie nicht funktioniert. Sie besagen, dass das meiste, was ausgeliefert wird, nicht für die Workflows konzipiert ist, die es bearbeiten soll.

Pilotprojekte sind erfolgreich, weil die Aufgaben begrenzt und die Risiken gering sind. Der Agent beantwortet eine Frage, eine Person liest die Antwort, und der Austausch ist beendet. Die Produktion ist das Gegenteil. Aufgaben verketten sich über mehrere Tool-Aufrufe, ziehen Daten aus fragmentierten Quellen und müssen die seltenen Grenzfälle behandeln, die am wichtigsten sind.

Der Fehlerfall, über den man sich Sorgen machen muss, ist nicht die sichtbare Halluzination. Es ist die Antwort, die sprachlich korrekt, intern überzeugend und operativ falsch ist. Nichts in der Ausgabe des Modells weist darauf hin. Ein Support-Mitarbeiter empfiehlt eine Rückerstattung, die gegen eine regionale Richtlinie verstößt, weil die Richtlinie nicht im Kontextfenster war. Ein Schadensregulierer genehmigt einen Antrag, weil er die tatsächliche Deckung des Versicherungsnehmers nicht überprüft hat. Das System sieht auf den ersten Blick gesund aus, und die Folgekosten zeigen sich Wochen später bei Abgleichen und Prüfungen.

Generische Agenten sind gut genug, um eine E-Mail zu entwerfen oder ein öffentliches Dokument zusammenzufassen. Sie sind nicht gut genug für Arbeiten, die in einem regulierten Prozess in ein führendes System zurückschreiben.

Was einen KI-Agenten wirklich domänenspezifisch macht

Ein domänenspezifischer KI-Agent ist nicht nur ein allgemeines LLM mit einem spezialisierten System-Prompt. Es ist ein gesteuertes operatives System, das darauf ausgelegt ist, innerhalb der Regeln, Datenstrukturen und Risikogrenzen einer spezifischen Geschäftsfunktion zu agieren. Ein wirklich domänenspezifischer Agent besitzt vier entscheidende Eigenschaften:

1. Regeln. Die Ausgaben des Agenten sind an die tatsächlichen Richtlinien, die Berechtigungslogik und die Compliance-Schwellenwerte des Bereichs gebunden. Ohne dies liefert das Modell Antworten, die sich gut lesen und gleichzeitig gegen Richtlinien verstoßen.
2. Datenverankerung. Das System hat über Abrufmuster, die das Team besitzt und überwachen kann, einen vertrauenswürdigen, aktuellen Zugriff auf interne Aufzeichnungen. Dies umfasst das Fachvokabular: zum Beispiel zu erkennen, dass „SOB“ in einer klinischen Notiz „shortness of breath“ (Atemnot) und nicht etwas anderes bedeutet. Ohne verankerten Abruf ersetzt der Agent plausibel klingende Fakten durch die echten.
3. Workflow-Verständnis. Der Agent versteht die Abfolge, die Genehmigungsschritte, die Übergaben an menschliche Spezialisten und die Ausnahmepfade. Ohne dies wird jeder nicht-standardmäßige Fall zu einem stillen Fehler oder einem Support-Ticket.
4. Governance. Berechtigungen, Audit-Protokolle und Mensch-in-der-Schleife (HITL)-Prüfpunkte sind Teil der Architektur. Ohne Governance verlieren Sie die Fähigkeit, eine Entscheidung zu erklären oder zu verteidigen, wenn jemand den Verlauf anfordert.

Warum kritische Workflows die Grenzen generischer Agenten aufzeigen

Workflows mit hohen Risiken sind solche, bei denen Fehler zu erheblichen finanziellen Verlusten, klinischen Schäden oder rechtlicher Haftung führen. In diesen Umgebungen haben generische Agenten Schwierigkeiten, weil sie das von Regulierungsbehörden oder Stakeholdern geforderte Präzisionsniveau nicht garantieren können.

Im Gesundheitswesen betonen beispielsweise die FDA und die WHO, dass KI über ihren gesamten Lebenszyklus hinweg bewertet werden muss, um Risiken im Zusammenhang mit Sicherheit und Voreingenommenheit zu managen. Ein generischer Agent, der Patientenakten prüft, könnte eine kritische Kontraindikation übersehen, weil er die Langzeitgeschichte des Patienten nicht mit den neuesten pharmazeutischen Leitlinien abgleichen kann.

Im Finanzwesen wünscht sich ein Prüfer tatsächlich eine Entscheidungsnachvollziehbarkeit: einen reproduzierbaren Pfad von der Eingabe zur Ausgabe, wobei jeder Tool-Aufruf, Datenabruf und jede Richtlinienprüfung protokolliert wird. Generische Agenten produzieren dies nicht. Sie erzeugen Prosa. Entscheidungsnachvollziehbarkeit ist etwas, das die Orchestrierungs- und Protokollierungsschicht um das Modell herum erzeugen muss, und das ist ein technisches Artefakt, keine Modellfähigkeit.

Wo die Produktionszuverlässigkeit tatsächlich zu Hause ist

Das LLM ist eine Komponente eines Agenten, nicht der Agent selbst. Was bestimmt, ob das System in der Produktion standhält, ist die Orchestrierungsschicht: der Code, der entscheidet, welches Tool aufgerufen wird, in welcher Reihenfolge, mit welchem Zustand und wie sich das System erholt, wenn ein Schritt fehlschlägt.

Drei Muster wiederholen sich bei domänenspezifischen Implementierungen.

• Sequenzielle Orchestrierung ketten Agenten in einer festen Reihenfolge aneinander, wie ein Entwurfsschritt, gefolgt von einem Compliance-Prüfschritt. Es ist das am einfachsten zu verstehende Muster und am leichtesten zu prüfen. Die Kosten sind Latenz: Jeder Schritt blockiert den nächsten.
• Parallele Orchestrierung führt mehrere Agenten parallel mit derselben Eingabe aus und gleicht dann deren Ausgaben ab. Eine Finanzrisikobewertung könnte gleichzeitig eine technische und eine regulatorische Prüfung durchführen. Die Kosten sind die Abgleichlogik. Wenn die beiden Agenten nicht übereinstimmen, muss die Orchestrierungsschicht wissen, wie dies zu lösen ist, und „wissen“ bedeutet, dass jemand diese Regel explizit entworfen hat.
• Übergabemuster lassen einen Agenten erkennen, wann eine Aufgabe außerhalb seines Zuständigkeitsbereichs liegt, und die Kontrolle an einen anderen Spezialisten übergeben. Die meisten Produktionsausfälle treten an den Schnittstellen zwischen Spezialisten auf, daher benötigt die Übergabelogik die gleiche Prüfung wie die Agenten selbst.

Die zweite architektonische Entscheidung ist der Tool-Zugriff. Einem Agenten einen breiten Satz aufrufbarer Funktionen zu geben, ist der schnellste Weg, ein System zu bauen, das gelegentlich etwas Katastrophales tut. Kontrollierter Tool-Zugriff, bei dem jede Funktion vorvalidiert, in einer Sandbox ausgeführt und auf einen bestimmten Zweck zugeschnitten ist, ist die Einschränkung, die die Autonomie des Agenten sicher für den Einsatz macht.

Die Orchestrierungsebene hat ebenfalls ihre eigenen Fehlerursachen. Wiederholungsversuche, Teilausfälle, Idempotenz und der Zustandsabgleich bei asynchronen Tool-Aufrufen müssen alle im System berücksichtigt werden. Teams, die diese Ebene überspringen und die Orchestrierungslogik in den Prompt verlagern, liefern Systeme aus, die zwar Tests bestehen, sich aber unter Last unvorhersehbar verhalten.

Was unterschätzt wird

Vier Anforderungen sind die Grundlage jeder produktionsreifen Agentenentwicklung. Teams, die diese unterschätzen, verlieren die ersten sechs Monate.

Workflow-Mapping. Man kann nicht automatisieren, was man nicht abgebildet hat. Und was man tatsächlich abbilden muss, ist, wie die Arbeit erledigt wird – nicht das, was in der SOP steht. Die SOP beschreibt den Idealfall. Im Produktivbetrieb scheitert es an den Ausnahmen: die manuelle Überschreibung, die jemand über Slack vornimmt, der Abgleichschritt, der in einer Tabelle stattfindet, die niemandem gehört, die Genehmigung, die technisch erforderlich, aber praktisch übersprungen wird. Ein Agent, der nur die SOP kennt, wird scheitern, sobald die Realität davon abweicht.

Datenbereitschaft. Retrieval-Augmented Agents scheitern häufiger beim Abrufen von Informationen als bei der Generierung. Das macht die Form und Aktualität Ihrer internen Daten zum größten Einzelfaktor für die Zuverlässigkeit des Agenten. Wenn Ihre führenden Systeme inkonsistent sind, Ihr Berechtigungsmodell unklar ist oder Ihre Pipelines Stunden hinterherhinken, werden diese Probleme zu Agentenproblemen. Es gibt keinen Prompt, der eine veraltete oder umstrittene Quelle der Wahrheit kompensieren kann.

Beobachtbarkeit. Ein produktiver Agent benötigt die gleiche Beobachtbarkeit wie jeder andere Dienst, plus ein paar Dinge, die die meisten Dienste nicht haben: Groundedness-Scores pro Antwort, Kostenverfolgung auf Token-Ebene und nachvollziehbare Ausführungspfade über Tool-Aufrufe hinweg. Wenn Ihr Team anhand der Logs nicht beantworten kann, "warum der Agent diesen spezifischen Aufruf zu diesem spezifischen Zeitpunkt gemacht hat", ist das System nicht betriebsfähig.

Lebenszyklus-Governance. Die Modellversion, die der Agent verwendet, die Prompts, die er ausführt, und die Tool-Definitionen, die er aufrufen kann – all das ändert sich. Jede Änderung ist eine potenzielle Regression. Behandeln Sie Agentensysteme wie jede andere Software unter Änderungskontrolle: versioniert, überprüft, reversibel. Governance ist keine Checkbox vor dem Launch. Es ist die operative Disziplin, die das System nach dem Launch vertrauenswürdig hält.

Wie Sie entscheiden, ob Ihr Workflow einen domänenspezifischen Agenten benötigt

Nicht jeder Workflow verdient eine maßgeschneiderte Agentenarchitektur. Sechs Kriterien bestimmen in der Regel, ob dies der Fall ist. Wenn drei oder mehr zutreffen, ist der domänenspezifische Build fast immer die richtige Wahl. Wenn ein oder zwei zutreffen, ist eine leichtere Einrichtung meist die richtige.

Die erste Zeile ist diejenige, die die meisten Fälle entscheidet. Nur-Lese-Agenten, die Empfehlungen geben und den Menschen entscheiden lassen, sind eine andere Systemkategorie als Agenten, die den Zustand im Produktivbetrieb ändern. Wenn Ihr Workflow diese Grenze überschreitet, behandeln Sie ihn als Softwaresystem, nicht als KI-Funktion.

Wo generische KI-Agenten noch sinnvoll sind

Nicht jeder Workflow benötigt diese Architektur. Generische Agenten sind eine vernünftige Wahl, wenn drei Bedingungen erfüllt sind: Ein Mensch liest und beurteilt die Ausgabe des Agenten, bevor eine nachgelagerte Aktion erfolgt; die Arbeit weist keine strengen Compliance- oder Richtlinienbeschränkungen auf; und es gibt keinen Rückschreibvorgang in ein führendes System.

Das deckt mehr Arbeit ab, als Teams normalerweise erwarten. Interne Entwurfserstellung, Forschungszusammenfassungen auf Basis öffentlicher Daten und Prototypenvalidierung, bevor man sich zu einem vollständigen Build verpflichtet, werden alle gut von einem sofort einsatzbereiten Agenten mit moderatem Prompt Engineering bedient. Für diese Aufgaben einen generischen Agenten zu wählen, ist richtig. Die Skalierung desselben Setups in einen Workflow, der diese drei Bedingungen nicht erfüllt, führt jedoch zu Problemen für die Teams.

Warum die Partnerwahl wichtiger ist als das Modell

Die Wahl des Basismodells ist echte Ingenieurskunst. Kontextfenster, Latenz, Zuverlässigkeit der Tool-Aufrufe, Kosten pro Token und Unternehmensgarantien sind alle wichtig, und kein Team sollte sie abtun. Aber sie sind nachgelagert zu den Entscheidungen, die bestimmen, ob das System überhaupt funktioniert. Architektur, Workflow-Mapping und Governance erfolgen vor der Modellwahl, und kein Modell-Upgrade behebt ein System, das falsch konzipiert wurde.

Deshalb ist bei einem risikoreichen Projekt der Implementierungspartner meist die wichtigere Entscheidung. Der richtige Partner hinterfragt Ihre Workflow-Annahmen, bevor er Code schreibt. Er sagt Ihnen, welche Schritte, die Sie automatisieren möchten, noch nicht tatsächlich automatisiert werden können. Er konzipiert die Orchestrierungs- und Governance-Ebenen als erstklassige Komponenten des Systems, nicht als Funktionen, die in Version zwei angeflanscht werden.

Suchen Sie nach nachweislicher Erfahrung in regulierten oder komplexen Bereichen. Codebridge hat ein Tool zur Verwaltung von Krebsbehandlungen entwickelt, das in Schweizer Krankenhaussysteme integriert ist, und eine Wissensmanagementplattform für die Steuer- und Rechtsabteilung einer Big-4-Wirtschaftsprüfungsgesellschaft. Diese Projekte waren erfolgreich, weil die Teams zuvor bereits in regulierten Arbeitsabläufen gearbeitet hatten und wussten, was Auditoren, Kliniker und Compliance-Prüfer akzeptieren würden. Das zugrunde liegende Modell war für das Ergebnis nebensächlich.

Fazit

Generische Agenten sind nützliche Werkzeuge für die Wissensarbeit. Sie versagen, wenn sie auf die tatsächlichen Betriebsregeln eines regulierten Geschäftsprozesses treffen. Die Frage für eine technische Führungskraft ist nicht, ob KI-Agenten eingesetzt werden sollen. Sondern welche Workflows die architektonische Investition in eine domänenspezifische Entwicklung rechtfertigen?

Drei Bedingungen machen die Antwort zu einem Ja: der Agent ändert den Status in einem System of Record, Fehler verursachen echte Kosten, oder die Ausgabe muss nachträglich erklärbar sein. Wenn diese Bedingungen erfüllt sind, ist das Basismodell die kleinste Entscheidung, die Sie treffen werden. Die Architektur, die Datengrundlage, das Workflow-Design und die Governance-Schicht bestimmen, ob das System sicher im großen Maßstab betrieben werden kann. Hierin liegt die eigentliche Investition, und dafür ist ein erfahrener Implementierungspartner da.