Einen KI-Agenten zusammenzuklicken ist heute kein Hexenwerk mehr. n8n, Make, LangChain, Voiceflow: Die Tools sind ausgereift, Tutorials gibt es im Überfluss, und wer einen KI-Agent erstellen will, hat oft schon nach einem Wochenende einen laufenden Prototyp. Genau das macht die Frage schwieriger, nicht einfacher.
Wer einen laufenden Agenten sieht, versteht selten, was er nicht sieht: das Datenschutz-Setup, die Fehlerbehandlung, das Monitoring, die Modell-API-Kostenkurve, den menschlichen Freigabepfad. Der Prototyp ist der einfache Teil. Was danach kommt, ist das eigentliche Projekt.
Kurzfassung
KI-Agenten lassen sich heute relativ schnell bauen. Produktionsreif betreiben ist eine andere Aufgabe: Datenschutzkonformität, zuverlässige Fehlerbehandlung, Monitoring und laufende Pflege brauchen entweder internes Know-how oder externe Unterstützung. Die richtige Frage ist nicht “Bauen oder kaufen?”, sondern “Wer trägt den Betrieb?”
Was beim KI-Agent erstellen wirklich schnell geht
Die Low-Code-Plattformen haben ihren Job gut gemacht. Mit n8n, Make oder Voiceflow kann man einen Agenten aufbauen, der eine eingehende E-Mail liest, eine Kategorisierung trifft und eine Antwortvorlage erstellt, ohne eine Zeile Code zu schreiben. Das Sprachmodell steckt dahinter, der Workflow verknüpft die Teile.
Warum das verlockend ist, liegt auf der Hand: niedrige Einstiegshürde, schnelles erstes Ergebnis, keine Infrastrukturkosten zu Beginn. Wer einen ersten Prototyp für einen gut abgegrenzten Use-Case bauen will, kommt damit weit.
Was die Plattformen nicht automatisch lösen: die Fragen, die in jedem produktiven Einsatz kommen. Was passiert, wenn das Sprachmodell halluziniert? Wer bemerkt es, wer korrigiert es, wer protokolliert es? Welche Daten fließen in welches Modell, auf welchem Server, unter welchen Vertragsbedingungen?
Diese Fragen treten im Prototyp-Stadium selten auf, weil noch kein produktiver Prozess davon abhängt. Sobald echter Betrieb beginnt, sind es die entscheidenden Fragen. Was ein produktionsreifer KI-Agent architektonisch braucht, erklärt der Beitrag Was ist ein KI-Agent?.
Was zwischen Prototyp und produktivem Betrieb liegt
Die meisten Unternehmen unterschätzen diese Lücke. Auf fünf Ebenen ist produktiver Betrieb deutlich aufwendiger als ein Prototyp:
Datenschutz und Auftragsverarbeitungsverträge. Jedes Mal, wenn ein Agent Daten an ein externes Sprachmodell schickt, ist das eine Verarbeitung im Sinne des Datenschutzrechts. Für jede Datenklasse braucht es eine Rechtsgrundlage, für jede Weitergabe an externe Anbieter einen Auftragsverarbeitungsvertrag. Ein Prototyp läuft im Testbetrieb, ein produktiver Agent läuft gegen echte Daten, oft täglich und mit vertraulichen Inhalten.
Human-in-the-Loop bei kritischen Entscheidungen. Sobald ein Agent Entscheidungen mit rechtlicher oder finanzieller Wirkung vorbereitet oder trifft, verlangt das Datenschutzrecht in bestimmten Konstellationen einen menschlichen Eingriff. Das ist kein optionales Feature, sondern ein Architekturmerkmal, das von Anfang an eingeplant sein muss.
Monitoring und Fehlerbehandlung. Was passiert, wenn das Sprachmodell eine falsche Kategorisierung trifft? Wenn die externe API nicht antwortet? Wenn ein Workflow abbricht, ohne Fehlermeldung? Im Prototyp schaut jemand drüber. Im produktiven Betrieb läuft der Agent ohne permanente Aufsicht. Ohne Monitoring und definierte Fehler-Recovery wird jeder Ausfall zum Brandfall.
Modell-API-Kosten und Rate Limits. Wer mit dem kostenlosen Tier eines No-Code-Tools beginnt, trifft im Produktionsbetrieb schnell auf Rate Limits und Kostensprünge. Hochvolumige Agenten, die täglich Tausende Anfragen verarbeiten, haben eine andere Kostenstruktur als ein Prototyp mit ein paar Testläufen. Wer das nicht im Vorfeld durchrechnet, erhält überraschende Monatsrechnungen.
Updates und Versionskontrolle. Sprachmodelle ändern sich. Anbieter aktualisieren ihre APIs, ändern Defaults, veröffentlichen neue Versionen. Ein Agent, der auf einem bestimmten Modellverhalten aufgebaut wurde, kann sich nach einem Update anders verhalten. Produktiver Betrieb braucht eine Teststrategie, bevor Updates deployed werden.
Selbst bauen oder betreiben lassen: ein Vergleich
| Kriterium | Selbst bauen (DIY) | Betreiben lassen |
|---|---|---|
| Initialer Aufwand | Gering (Low-Code) bis hoch (Custom Dev) | Gering bis mittel (Setup + Einweisung) |
| Laufender Aufwand | Hoch (Monitoring, Updates, Fehler) | Gering (liegt beim Betreiber) |
| Datenschutz-Setup | Liegt beim Unternehmen | Eingebettet in den Service |
| Auftragsverarbeitungsverträge | Eigenverantwortung | Geregelt durch Betreiber |
| Anpassbarkeit | Hoch (alles unter eigener Kontrolle) | Mittel (im Rahmen des Serviceangebots) |
| Time-to-Value | Wochen bis Monate | Tage bis Wochen |
| Interne Ressourcen nötig | Ja (Dev + Ops) | Nein |
Total Cost of Ownership beachten
Die initialen Tool-Kosten sehen beim DIY-Pfad oft günstig aus. Was die Rechnung kippt: Entwicklungszeit, internes Ops-Know-how, Monitoring-Infrastruktur und Compliance-Setup. Wer diese Posten nicht einrechnet, vergleicht einen Prototyp mit einem Produktivsystem.
Wann Selbstbauen die richtige Wahl ist
Eigenentwicklung lohnt sich unter drei Bedingungen.
Internes Dev- und Ops-Team vorhanden. Wer in der Lage ist, einen Agenten zu bauen, ihn zu deployen und dauerhaft zu betreiben, hat dafür die richtige Infrastruktur, wenn dieses Team auch langfristig verfügbar bleibt und nicht durch andere Prioritäten absorbiert wird.
Geringe Datenklassen-Anforderungen. Wenn der Agent ausschließlich mit öffentlich verfügbaren Daten oder nicht-sensiblen internen Informationen arbeitet, ist der Datenschutz-Setup überschaubar. Das ist bei spezifischen Use-Cases denkbar, zum Beispiel einem Agenten, der öffentliche Marktberichte zusammenfasst. Bei Agenten mit Kunden- oder Mitarbeiterdaten ist die Lage deutlich anspruchsvoller.
Voller Bedarf an Kontrolle und Anpassbarkeit. Wenn ein Prozess hochspezifische Logik erfordert, die kein Standardangebot abdeckt, oder wenn das Unternehmen aus strategischen Gründen volle Infrastrukturkontrolle benötigt, ist Eigenentwicklung der richtige Pfad, vorausgesetzt, die Ressourcen für den laufenden Betrieb stehen bereit.
Für viele Mittelstandsbetriebe trifft keiner dieser drei Punkte vollständig zu, oder nur der erste, aber ohne das zweite.
Wann Betreiben-Lassen sinnvoller ist
Sensible Daten werden verarbeitet. Mandatsdaten, Personalakten, Finanzdaten, Gesundheitsdaten: Diese Datenklassen erfordern ein Datenschutz-Setup, das von Anfang an in die Architektur eingebaut sein muss. Ein spezialisierter Betreiber bringt dieses Setup mit, statt es nachträglich nachzurüsten. Wo Daten das Unternehmen nicht verlassen dürfen, ist eine private KI-Infrastruktur die belastbarere Grundlage.
Kein DevOps-Team vorhanden. Einen Agenten zu bauen ist eine Sache. Ihn stabil zu betreiben, Ausfälle zu erkennen, Updates sicher einzuspielen und Kapazitäten zu skalieren, ist eine andere Kompetenz. Wer diese intern nicht hat, kauft sie entweder ein oder zahlt dafür, sie aufzubauen.
Time-to-Value zählt. Ein begleitetes Erstprojekt ist oft in wenigen Wochen produktiv, weil das Setup nicht von Null gelernt werden muss. Wer einen selbst gebauten Agenten das erste Mal in Produktion bringt, rechnet realistisch mit Wochen bis Monaten, nicht mit Tagen.
Betriebsstabilität ist entscheidend. Wenn ein Prozess täglich läuft und bei Ausfall Menschen oder Kunden direkt betroffen sind, zählt Verlässlichkeit. Das ist kein Argument gegen Eigenentwicklung grundsätzlich, aber ein Argument dafür, dass Betriebsressourcen und Monitoring von Anfang an geklärt sein müssen, nicht erst wenn etwas schiefläuft.
Die Umsetzung als KI-Agenten auf eigener Plattform richtet sich genau an Unternehmen, die Agenten produktiv betreiben wollen, ohne selbst Ops-Kapazität aufzubauen.
Typische DIY-Fallen
Häufige Probleme beim Selbstbauen
Diese Fehler treten fast immer auf, wenn der Schritt vom Prototyp zur Produktion nicht bewusst geplant wird.
Keine Audit-Trails. Im Produktionsbetrieb muss nachvollziehbar sein, welche Entscheidungen der Agent getroffen hat und auf welchen Eingaben sie basierten. Wer das nicht von Anfang an in die Architektur einbaut, hat bei einem Fehler weder Ursache noch Nachweis.
AVV fehlt oder ist unvollständig. Viele Unternehmen starten mit dem kostenlosen Tier eines Modellanbieters und merken erst später, dass dieser Tier keinen Auftragsverarbeitungsvertrag beinhaltet und Eingaben für das Modell-Training verwendet werden können. Bei personenbezogenen Daten kann das eine Datenschutzverletzung sein.
Rate-Limit-Überraschungen. Wer einen Agenten mit einem kleinen Datensatz testet, trifft im Produktionsbetrieb plötzlich auf Ratenbeschränkungen der Modell-API. Das kann einen ganzen Workflow zum Stillstand bringen, mitten im laufenden Betrieb.
Update-Regression unbemerkt. Ein Anbieter aktualisiert das Sprachmodell, der Agent ändert sein Verhalten subtil, keiner merkt es zunächst. Ohne Monitoring und Regressionstests ist das ein realistisches Szenario in jedem längerfristigen Betrieb.
Verdict
Der Vergleich ist kein Entweder-oder, sondern eine Ressourcenfrage. Wer intern die Dev- und Ops-Kompetenz hat, mit unkritischen Daten arbeitet und Anpassbarkeit mehr zählt als Time-to-Value, baut selbst. Wer sensible Daten verarbeitet, kein Ops-Team aufstellen will und schnell in Produktion gehen muss, ist mit einem begleiteten Setup besser bedient.
Die meisten Mittelstandsbetriebe stehen vor der zweiten Situation, auch wenn die erste verlockender klingt, weil der Prototyp glauben lässt, der Rest sei ähnlich einfach.
Was der richtige Einstiegspunkt ist, hängt von den Prozessen, der Datenklasse und den internen Ressourcen ab. Das ist genau das, was das KI-Prozess-Audit klärt: 30 Minuten, erste Einordnung zu Use-Case, Datenschutzlage und dem richtigen Betriebsmodell für dein Unternehmen. Wer direkt mit einem begleiteten Agentenprojekt starten will, findet das Angebot unter Prozessautomatisierung.
