KI-Agent selbst bauen oder kaufen: Build-vs-Buy ehrlich gerechnet

Die Szene kenne ich aus jedem zweiten Erstgespräch. Geschäftsführer und IT-Leiter sitzen im selben Raum, die Aufgabe ist klar, der Bedarf ebenfalls. Dann sagt der IT-Leiter den Satz, der jedes Build-vs-Buy-Gespräch eröffnet: "Im Prinzip bauen wir das schnell selbst. Wir haben n8n im Haus, einen OpenAI-API-Key gibt es auch, das macht der Werkstudent in zwei Wochen."

Manchmal hat er recht. Häufiger nicht. Welche Variante zutrifft, hängt an ein paar Faktoren, die in der ersten Aufwandsschätzung selten auftauchen.

Ich versuche das hier ehrlich durchzurechnen. Mit Zahlen, nicht mit Gefühlen. Und mit dem Eingeständnis, dass ich selbst einen Managed-Service anbiete und damit ein Interesse habe, dass Sie kaufen statt bauen. Trotzdem trenne ich die Fälle, in denen Eigenbau die richtige Wahl ist. Wer mir nicht glaubt, kann die Rechnung in der eigenen Excel nachvollziehen.

Der Markt sagt: bauen

Wenn Sie nach "KI-Agent erstellen" suchen, ist das Angebot eindeutig. Botpress, Microsoft Copilot Studio, Salesforce Agentforce, Oracle Digital Assistant, automationanywhere, Voiceflow, LangGraph, CrewAI, n8n, Flowise. Alle wollen Ihnen eine Plattform verkaufen, auf der Sie Ihren Agenten zusammenklicken oder zusammenprogrammieren. Die Marketing-Botschaft ist überall dieselbe: einfach, schnell, volle Kontrolle.

Das ist nicht falsch, nur unvollständig. Was diese Plattformen verkaufen, ist die Logik-Engine, in der der Agent läuft. Was sie nicht verkaufen, sind die anderen vier Fünftel: Tool-Anbindungen, DSGVO-Setup, Memory, Monitoring, Wartung, Eskalations-Logik, Skill-Management. Wer eine fertige Lizenz bucht und glaubt, damit sei der Agent fertig, merkt in Woche drei, dass die eigentliche Arbeit gerade erst anfängt.

Ich habe in den letzten zwölf Monaten mit etwa vierzig Mittelständlern gesprochen, die einen Agenten bauen wollten oder gebaut haben. Drei davon haben ihn produktiv im Einsatz. Der Rest steckt im Prototyp-Stadium, hat das Projekt eingefroren oder den Mitarbeiter verloren, der ihn gebaut hat. Das ist keine Statistik, das ist Anekdote. Aber die Quote ist hartnäckig.

Was beim Selbstbauen unterschätzt wird

Vor der Kostenrechnung steht die Aufwands-Inventur. Wer ehrlich kalkulieren will, sollte wissen, was tatsächlich gebaut werden muss. Ich gehe das in der Reihenfolge durch, in der die Posten in einem realen Projekt auftauchen.

Der erste Posten ist das Prompt-Engineering. Klingt trivial, ist es nicht. Ein Agent, der bei der Müller GmbH dieselbe Mail anders einordnet als bei Ihnen, nur weil ein Wort im Systemprompt zu vage ist, ist kein Bug. So sind Sprachmodelle nun mal, und es kostet Iterationen, bis das Verhalten stabil ist. Rechnen Sie mit drei bis fünf Tagen reinem Prompt-Tuning für einen halbwegs ernsten Use-Case, bevor das Verhalten wiederholbar wird.

Der zweite Posten sind die Tool-Bindings. Ihr Agent soll im CRM lesen und schreiben, Mails versenden, Kalender prüfen, in der Buchhaltung Belege ablegen. Jede dieser Schnittstellen ist eigene Arbeit. APIs haben Quoten, OAuth-Tokens laufen ab, Fehlerfälle wollen behandelt werden. Wer Composio oder einen ähnlichen Tool-Layer einkauft, spart hier Wochen, zahlt aber laufend Lizenz. Wer es selbst baut, hat eine Pflegelast, die bleibt.

Der dritte Posten ist das Gedächtnis. Ein Agent ohne Memory ist ein Chatbot. Sobald der Agent über mehr als einen Vorgang hinweg lernen soll, brauchen Sie eine Architektur dafür. Vektordatenbank, semantischer Speicher, strukturierter Wissensspeicher, und eine Logik, die entscheidet, was wo landet. Wer das auf der grünen Wiese baut, lernt zuerst die Tücken von pgvector, dann die von Chroma, dann die von Weaviate, und kommt nach drei Wochen drauf, dass die richtige Architektur zwei Schichten braucht statt einer. Das ist normal. Es ist nur Zeit, die niemand eingeplant hat.

Der vierte Posten ist das DSGVO-Setup. Sobald Ihr Agent personenbezogene Daten verarbeitet, also spätestens bei Mails oder CRM-Zugriff, brauchen Sie einen Auftragsverarbeitungsvertrag mit dem LLM-Anbieter, ein dokumentiertes Verarbeitungsverzeichnis, Standardvertragsklauseln für die US-Anbieter, eine Risiko-Folgenabschätzung. OpenAI bietet das an, Anthropic auch, Composio auch. Das durchzulesen, zu verstehen und sauber in Ihre interne Compliance zu bringen, kostet entweder Ihren Datenschutzbeauftragten zwei bis drei Tage oder eine externe Beratung in vergleichbarem Umfang. Hosting in der EU ist eine separate Entscheidung. Wer den Agenten auf AWS Frankfurt laufen lässt, hat zwar einen deutschen Server, aber AWS ist ein US-Konzern, also bleiben die SCC-Themen. Hetzner oder eine deutsche Alternative ist die saubere Lösung, kostet aber Setup-Zeit, weil Sie die Server selbst administrieren.

Der fünfte Posten ist das Monitoring. Was tut Ihr Agent gerade? Welche Tool-Aufrufe macht er, wie viele Tokens verbraucht er, wo fängt er an im Kreis zu laufen? LangSmith, Langfuse oder Phoenix sind brauchbare Tools dafür, aber sie kosten Lizenz und Konfiguration. Ohne Observability fliegen Sie blind. Sie merken erst, dass etwas falsch läuft, wenn der Endkunde sich beschwert oder die OpenAI-Rechnung im nächsten Monat das Vierfache zeigt. Das ist kein theoretisches Risiko. Ich kenne einen Schweizer SaaS-Anbieter, der über einen Endlos-Loop in seinem selbstgebauten Agenten in einer Woche 14.000 Franken verbrannt hat, bevor jemand das gemerkt hat. Auf eine geplante Monats-Budgetierung von 800 Franken.

Der sechste Posten ist die Wartung, wenn Modelle wechseln. OpenAI hat zwischen Januar 2025 und März 2026 acht Mal die Modellauswahl angepasst, Anthropic sechs Mal. Manche Updates sind kompatibel, andere brechen Prompts, die vorher zuverlässig liefen. Wer einen Agenten produktiv betreibt, muss diese Wechsel testen, neu validieren und Prompts nachziehen. Rechnen Sie mit zwei bis drei Tagen Aufwand pro Modell-Wechsel, also etwa einem halben Tag pro Monat im Schnitt.

Der siebte Posten ist die Eskalations-Logik. Wann legt der Agent eine Aufgabe einem Menschen vor, statt selbst zu entscheiden? Das ist keine rein technische Frage. Da hängen Compliance, Haftung und Qualität dran. Wer das nicht sauber baut, hat einen Agenten, der entweder zu viel selbst macht (und gelegentlich Mist) oder bei jeder Kleinigkeit nachfragt (und damit nutzlos wird). Einen Default für gute Eskalations-Regeln gibt es nicht. Die muss man für jeden Use-Case durchdenken.

Der achte Posten ist das Vault- und Knowledge-Management. Wo speichert der Agent, was er über Ihre Firma weiß? Wer pflegt das? Wie wird es auditierbar? Wenn der Vertriebsleiter heute eine Regel reinschreibt, wer prüft das morgen? Ein Markdown-Repo mit Git-Versionierung, wie wir es einsetzen, ist eine pragmatische Lösung. Aber auch die ist nicht von alleine da. Die muss aufgesetzt, dokumentiert und in den Alltag der Mitarbeiter integriert werden.

Diese acht Posten sind kein theoretischer Katalog. Das ist die Liste, die Sie sich an die Bürowand kleben können, wenn Sie ein Build-Projekt starten. Wer einen Posten überspringt, baut keinen produktiven Agenten, sondern einen Demonstrator.

Was Build tatsächlich kostet

Jetzt die Zahlen, an denen sich die meisten Build-Projekte verkalkulieren. Ich rechne hier mit Werten, die ich aus realen Angeboten von DACH-Freelancern und kleineren Agenturen kenne, nicht mit Wunschdenken.

Für einen halbwegs ernsten Use-Case (sagen wir, ein Backoffice-Agent, der Posteingang sortiert, Rechnungen extrahiert und ans DATEV-Vorsystem übergibt) liegt die Bauphase bei 15 bis 25 Entwicklertagen. Inhouse-Entwicklertag im Mittelstand kostet voll umgelegt 800 bis 1.200 Euro, Freelancer mit Erfahrung 900 bis 1.400 Euro. Ich rechne mittig mit 1.000 Euro. Macht 15.000 bis 25.000 Euro für die Erstinstallation. Plus interne Stakeholder-Zeit für die Spezifikation, also Geschäftsführer, Fachbereich, IT, Datenschutz. Realistisch zehn Personen-Tage Begleitung, auch wenn das selten verbucht wird.

Nach der Bauphase laufen monatlich Kosten weiter. Hosting bei einem deutschen Provider 50 bis 120 Euro für eine sinnvolle VM. LLM-Tokens für einen mittelaktiven Agenten 150 bis 600 Euro im Monat, je nachdem ob Sie GPT-5.5, Claude oder GLM einsetzen. Composio-Lizenz oder vergleichbarer Tool-Layer 200 bis 500 Euro. Monitoring-Lizenz (Langfuse Cloud, LangSmith) 100 bis 300 Euro. Macht zwischen 500 und 1.500 Euro reine Betriebskosten ohne Personalanteil.

Dazu die Wartung. Realistisch zwei bis vier Entwicklertage pro Monat für Bug-Fixes, Model-Updates, Tool-Bindings nachziehen, neue Skills anlegen. Bei 1.000 Euro pro Tag also 2.000 bis 4.000 Euro Personalanteil. Plus etwa einen Tag interne Fachbereichszeit pro Monat für Feedback-Loop und Kuration.

Erstes Jahr Gesamtkosten Build: 15.000 bis 25.000 Euro Setup, plus 12 mal 2.500 bis 5.500 Euro laufend, also 30.000 bis 41.000 Euro im konservativen Fall und 45.000 bis 91.000 Euro im großzügigen. Mittlerer Korridor: 35.000 bis 50.000 Euro im ersten Jahr für einen einzigen produktiven Agenten.

Diese Zahlen klingen hoch, weil die Marketing-Botschaft der Build-Plattformen niedrige Lizenzen verspricht. Die Lizenz ist auch niedrig. Sie ist nur ein Bruchteil der Wahrheit.

Was Buy tatsächlich kostet

Zum Vergleich der Managed-Service. Bei Agentenkollege ist der Einstieg ein 30-Tage-Pilot ab 990 Euro für die kleineren Agenten, bis zu 2.490 Euro für die spezialisierten. Im Pilot ist alles drin: Einrichtung, Hosting, LLM-Nutzung, Tool-Anbindungen, Monitoring, Wartung, AVV.

Nach dem Pilot zahlen Sie monatlich nach Agent. Backoffice 1.500 Euro, Customer-Success oder Operations 2.200 Euro, Sales oder Recruiting 2.800 Euro, Marketing 3.200 Euro, Legal oder Research mit Opus 5.000 Euro. Erstes Jahr für einen Backoffice-Agenten: 990 Euro Pilot plus elf mal 1.500 Euro, also 17.490 Euro. Für einen Sales-Agenten: 1.890 Euro Pilot plus elf mal 2.800 Euro, also 32.690 Euro.

Im Korridor 15.000 bis 35.000 Euro im ersten Jahr, je nach Agententyp. Build liegt bei 35.000 bis 50.000 Euro im ersten Jahr. Im zweiten Jahr verschiebt sich das. Build kostet nur noch laufenden Betrieb, also etwa 30.000 bis 65.000 Euro. Buy bleibt gleich oder geht durch Bundle-Rabatte runter, also 18.000 bis 38.000 Euro.

Im fünften Jahr, wenn niemand kündigt und niemand Sonderwünsche hat, könnte Build günstiger werden. Das setzt voraus, dass der Mitarbeiter, der ihn gebaut hat, noch da ist, dass die Modelle, gegen die programmiert wurde, noch leben, und dass keine größere Architektur-Anpassung nötig wird. Bei drei Mittelständlern, die ich kenne, ist mindestens eine dieser Voraussetzungen nach 18 Monaten gerissen.

Detaillierte Kostenblöcke im allgemeinen Fall sind in Was kostet ein KI-Agent aufgeschlüsselt. Wer die Build-vs-Buy-Rechnung im eigenen Excel nachbauen will, findet dort die Zahlen pro Block.

Ein DACH-Beispiel

Eine Wiener Logistik-Firma mit 80 Mitarbeitern, die ich begleiten durfte, ist beide Wege gegangen. Erst Build, dann Buy.

Zwischen März und August 2025 hat ein interner Entwickler einen Mail-Triage-Agenten auf n8n plus OpenAI gebaut. Ziel: eingehende Kundenanfragen vorsortieren, Standardfragen automatisch beantworten, alles andere ans Team weiterleiten. Erste Demo nach drei Wochen, alle waren begeistert. Pilotbetrieb startete im Mai, lief sechs Wochen, dann häuften sich die Probleme. Mails wurden falsch eingeordnet, die OpenAI-Rechnung explodierte einmal auf 2.300 Euro in einem Monat wegen einer Schleife, und der Entwickler war im Urlaub, als drei wichtige Kundenmails an der falschen Stelle landeten.

Im September wurde das Projekt eingefroren. Aufwand bis dahin: rund 22 Entwicklertage zu 950 Euro intern voll umgelegt, plus 4.100 Euro Token-Kosten, plus 600 Euro Hosting und Tooling. Macht knapp 25.600 Euro für nichts Produktives. Plus der Frust des Entwicklers, der danach gekündigt hat, allerdings aus anderen Gründen, wie er versichert.

Im November haben wir den Backoffice-Agent als Managed-Service aufgesetzt. Pilot 990 Euro, danach 1.500 Euro pro Monat. Vier Wochen Pilot mit Freigabe-Modus, ab Woche fünf kam der Agent in den selbständigen Betrieb für die Routinekategorien. Stand heute, Mai 2026, läuft er seit sechs Monaten ohne nennenswerten Eingriff. Gesamtkosten in dem Zeitraum: 990 plus fünfmal 1.500, also 8.490 Euro für sechs Monate produktiven Betrieb.

Die Geschäftsführerin hat mir gesagt: Build hätte vielleicht funktioniert, wenn sie nicht den einen Entwickler verloren hätten. Hätte. Wäre. Die Rechnung im Nachhinein ist eindeutig. Build hätte sich frühestens in Jahr vier amortisiert, wenn alles perfekt gelaufen wäre. Stattdessen 25.600 Euro versenkt, weil ein Pfeiler weggebrochen ist.

Eine Anekdote, keine Statistik. Aber es ist die typische Form, in der Build-Projekte im Mittelstand scheitern: nicht an der Technik, sondern an der Personalabhängigkeit.

Wann Build wirklich besser ist

Es gibt Fälle, in denen Build die richtige Wahl ist, und ich wäre unredlich, würde ich die hier verschweigen.

Der erste Fall sind Use-Cases mit IP-relevantem Workflow. Wenn Ihr Agent eine Aufgabe übernimmt, die so eng mit Ihrem Kern-Know-how verwoben ist, dass die Prompts und Skills selbst Geschäftswissen sind, wollen Sie das nicht in einer Managed-Lösung haben, selbst bei DSGVO-konformem Hosting. Das gilt für etwa fünf Prozent der Use-Cases, die ich sehe, meist in der Produktion, in der Konstruktion oder in der Forschung. Für eine Kanzlei, die ihren spezifischen Recherche-Workflow als Wettbewerbsvorteil pflegt, kann Build die richtige Wahl sein.

Der zweite Fall ist ein Inhouse-AI-Team mit echter Kapazität. Wer drei oder mehr Entwickler hat, die LLM-Erfahrung mitbringen, kann Build wirtschaftlich betreiben. Voraussetzung ist, dass dieses Team auf absehbare Zeit besetzt bleibt. Wer eine Fluktuation von 20 Prozent pro Jahr hat, sollte nicht auf ein selbstgebautes System setzen, das die Person mitnimmt.

Der dritte Fall sind Datensouveränitäts-Anforderungen über DSGVO-Niveau. Wenn Sie in einem regulierten Bereich arbeiten (Verteidigung, Geheimdienst-nahe Behörden, militärische Zulieferer) und keine US-LLMs einsetzen dürfen, ist Build auf einem Mistral-On-Premise oder einem Llama-3-Setup die einzige Option. Das ist deutlich aufwändiger als ein OpenAI-basierter Build, aber es gibt keinen Managed-Service, der das anbietet, weil der Markt zu klein ist. Für 99 Prozent der Mittelständler trifft diese Anforderung nicht zu. Für das eine Prozent, das es betrifft, ist sie nicht verhandelbar.

In allen drei Fällen gilt: Wer Build wählt, sollte mit einem realistischen Budget rechnen, nicht mit der Marketing-Zahl der Plattform-Anbieter. Und mit einem Plan, was passiert, wenn der Hauptentwickler kündigt.

Wann Buy klar gewinnt

Die Gegenseite ist breiter.

Wenn Ihr Use-Case standardisiert ist, also Sales-Vorsortierung, Customer-Success, Backoffice, Recruiting-Screening oder Operations-Routinen, hat ihn jeder Mittelständler in ähnlicher Form. Einen davon selbst zu bauen ist, als würden Sie Ihre eigene Buchhaltungssoftware programmieren, weil Sie ja eine Programmiersprache beherrschen. Geht. Lohnt sich nicht.

Wenn Sie weniger als drei Entwickler im Team haben. Mit ein oder zwei Entwicklern, die LLM-Erfahrung haben, ist Build technisch möglich, aber operativ fragil. Krankheit, Urlaub, Kündigung, und der Agent steht. Bei einem Managed-Service sind die Risiken im Vertrag verteilt.

Wenn Sie einen Pilotbetrieb in weniger als 30 Tagen brauchen. Build dauert in der Praxis mindestens drei Monate bis zum stabilen Pilot. Wer schneller ein Ergebnis sehen will, fährt mit Buy. Das ist keine Marketing-Aussage, das ist die Bauzeit-Realität.

Wenn die Wartung außer Haus soll. Selbstgebauter Code, der nicht gewartet wird, verrottet schneller, als die meisten denken. APIs ändern sich, Modelle wechseln, Compliance-Anforderungen kommen dazu. Wer den Agenten als Asset behandelt und nicht als Dauerprojekt, ist mit Buy besser bedient.

Build wird in keinem dieser Fälle technisch unmöglich. Aber Gesamtkosten und Risiken sind so verteilt, dass Buy die ehrlichere Wahl ist.

Das Hybrid-Modell

Es gibt einen Mittelweg, den wir bei Kunden sehen, die teils standardisierte und teils eigene Anforderungen haben. Sie nehmen den Managed-Agent als Plattform und legen eigene Skills oder Prompts obendrauf. Die Plattform liefert Hosting, Monitoring, Tool-Bindings, AVV und Modell-Updates. Der Kunde steuert Inhalte und Spezifika.

Bei Agentenkollege heißt das konkret: Sie bekommen Zugriff auf den Vault des Agenten, ein Git-Repo mit Markdown-Dateien für Regeln, Wissensbasis und Skills. Sie können dort lesen, schreiben und committen. Der Agent zieht beim nächsten Lauf die neue Version. Wer Entwicklerkompetenz hat, kann eigene Skills schreiben. Wer das nicht hat, sagt dem Agenten in normaler Sprache, was er sich merken soll, und der schreibt den Skill selbst.

Für viele Mittelständler ist das der praktisch beste Punkt. Sie haben Kontrolle über die Inhalte, ohne die Last des Plattform-Betriebs zu tragen.

Ein ehrlicher Check

Bevor Sie sich entscheiden, sind ein paar Fragen hilfreicher als jede Anbieter-Folie.

Wer im Haus betreibt das System in zwei Jahren? Wenn die Antwort eine Person ist, ist das ein Risiko. Wenn die Antwort "wir nicht, das soll extern laufen" ist, hat sich Build erledigt.

Wie viele Mannmonate haben Sie tatsächlich für den Aufbau? Nicht im optimistischen Fall, sondern im realistischen. Wer ehrlich rechnet, sollte mindestens fünf Mannmonate für einen ernsten Build veranschlagen. Wer das nicht hat, sollte nicht starten.

Wie spezifisch ist die Aufgabe? Wenn Sie sie in einem Satz beschreiben können und jeder Wettbewerber sie ähnlich hätte, gehört sie in eine Managed-Lösung. Wenn die Beschreibung drei Seiten braucht und niemand außerhalb Ihrer Branche das versteht, lohnt der Eigenbau die Mühe womöglich.

Wenn Sie unsicher sind, welcher Pfad zu Ihnen passt, sind die Kostenrechnung im Detail und der Vergleich gegen Workflow-Tools gute nächste Lesungen. Ich nenne im ersten Gespräch lieber den Pfad, der für Ihren Fall passt, auch wenn das gegen unsere eigene Lösung spricht. Wer Build braucht, hört das bei uns ehrlicher als bei einer Plattform, deren Geschäftsmodell darauf beruht, dass Sie Lizenzen kaufen.