Eigene KI-Agenten schlagen SaaS erst ab diesem Punkt

In der klassischen IT-Beschaffung gab es eine verlässliche Faustregel: Kaufen Sie, was Commodity ist. Bauen Sie, was Ihr Geschäft unterscheidet. CRM, Buchhaltung, Ticketsystem – kaufen. Preislogik, Lagersteuerung, das Kernprodukt – bauen, wenn es den Unterschied zum Wettbewerb ausmacht. Diese Regel galt, weil Softwareentwicklung teuer und langsam war. Ein eigenes CRM zu bauen hätte Jahre gekostet und wäre am Ende schlechter gewesen als eine etablierte Lösung von der Stange.

Bei KI-Agenten stimmt die Grundannahme nicht mehr. Ein Agent, der Rechnungen prüft, Support-Anfragen beantwortet oder Angebote vorbereitet, lässt sich mit einem Sprachmodell, ein paar Werkzeugen und wenigen Wochen Entwicklungszeit bauen – wenn die Daten zugänglich sind. Der teuerste Teil klassischer Softwareentwicklung, die Logik von Grund auf zu programmieren, entfällt weitgehend. Was bleibt, ist Integrationsarbeit: Zugriff auf die richtigen Systeme, saubere Werkzeuge für den Agenten, ein Gespür dafür, wo er selbstständig entscheiden darf und wo nicht.

Die meisten SaaS-Produkte, die sich KI-Agent nennen, verkaufen drei Dinge: einen vorgefertigten Prompt, eine Oberfläche und einen Vertrag mit einem Sprachmodell-Anbieter. Die eigentliche Intelligenz mieten diese Anbieter selbst bei OpenAI, Anthropic oder Google ein und schlagen eine Marge darauf. Ihr Beitrag ist die Feinarbeit: Prompt-Engineering für den jeweiligen Anwendungsfall, ein paar Standardintegrationen, eine Benutzeroberfläche.

Das ist ein legitimes Geschäftsmodell, aber es lohnt sich, es zu durchschauen. Sie zahlen nicht für einzigartige Technologie. Sie zahlen für die Abkürzung, diese Feinarbeit nicht selbst zu machen. Bei einem generischen Anwendungsfall, den zehntausend andere Unternehmen genauso haben, ist das ein fairer Deal. Bei einem Anwendungsfall, der eng mit Ihren eigenen Daten und Prozessen verwoben ist, bezahlen Sie für eine Anpassung, die selten so gut passt wie eine eigene.

Ein einfacher Test hilft bei der Einordnung: Fragen Sie den Anbieter, was genau passiert, wenn Sie Ihre Daten exportieren und den Vertrag kündigen. Bleibt ein funktionierendes System übrig, das Sie selbst weiterbetreiben können, war der Vertrag eine Abkürzung. Bleibt nichts übrig, war der Vertrag eine Abhängigkeit, die als Produkt verkauft wurde.

Kaufen Sie, wenn drei Dinge zusammenkommen. Erstens: Der Anwendungsfall ist Commodity – E-Mail-Entwürfe, Meeting-Zusammenfassungen, generische Recherche. Zweitens: Der Anbieter hat einen echten Datenvorsprung, den Sie nicht replizieren können, etwa ein Anbieter mit jahrzehntelang gepflegten Fachdatenbanken. Drittens: Sie haben kaum interne Engineering-Kapazität, und die Zeit bis zum ersten Ergebnis zählt mehr als die Kontrolle über die Lösung.

In diesen Fällen ist eine eigene Entwicklung Zeitverschwendung. Sie würden eine schwächere Version von etwas bauen, das bereits existiert, und die eigentliche Aufgabe – die KI produktiv nutzen – würde sich unnötig verzögern.

Ein weiteres, oft übersehenes Signal für Buy ist die Wechselhäufigkeit des Anwendungsfalls. Wenn sich die Anforderungen an eine Funktion – etwa Rechtschreibung, Übersetzung oder allgemeine Recherche – schnell mit dem allgemeinen Stand der Technik weiterentwickeln, profitieren Sie davon, dass ein spezialisierter Anbieter diese Weiterentwicklung für Sie verfolgt. Bei einem selbst gebauten System müssten Sie diese Pflege selbst übernehmen, für einen Anwendungsfall, der gar keinen strategischen Unterschied macht.

Bauen Sie, wenn der Workflow selbst Teil Ihres Wettbewerbsvorteils ist: eine Preislogik, die Marktdaten mit internen Margenregeln verbindet; ein Kundenservice-Agent mit Zugriff auf Ihre komplette Produkt- und Vertragshistorie statt auf eine generische Wissensdatenbank; eine Qualitätsprüfung, die Ihre spezifischen Fertigungstoleranzen kennt. Der Wert liegt hier in der Verbindung aus Modell, Ihren Daten und Ihrer Prozesslogik. Das kauft Ihnen niemand ab, weil niemand außer Ihnen sie besitzt.

Bauen lohnt sich auch ab einem bestimmten Volumen. Agenten-SaaS wird fast immer pro Sitz, pro Anfrage oder pro verarbeitetem Dokument abgerechnet. Bei niedriger Nutzung ist das günstig. Ab einer gewissen Menge übersteigen die laufenden Lizenzkosten das, was ein eigener Agent auf Basis einer Sprachmodell-API kosten würde, deren Grenzkosten pro Anfrage gering sind.

Der dritte Grund ist Governance. Wenn ein Agent Entscheidungen mit rechtlicher oder finanzieller Tragweite trifft, verlangen der EU AI Act und in der Regel auch die eigene Compliance-Funktion Nachvollziehbarkeit: Welche Daten hat der Agent gesehen, welche Regel hat er angewendet, wer kann das prüfen. Diese Nachvollziehbarkeit lässt sich in ein selbst gebautes System einbauen. In eine fremde SaaS-Blackbox nicht.

Der Vergleich Lizenzgebühr gegen einmalige Entwicklungskosten ist unvollständig, in beide Richtungen. SaaS wirkt günstig, weil die Kosten linear mit der Nutzung wachsen und selten in einer einzigen großen Rechnung sichtbar werden. Über zwei bis drei Jahre und wachsendes Volumen kippt das häufig.

Umgekehrt wird der Aufwand für Build regelmäßig unterschätzt: Er entsteht erst nach der ersten Version. Sprachmodelle ändern sich, Prompts driften, Schnittstellen von Drittsystemen brechen. Ein selbst gebauter Agent braucht laufende Pflege: Monitoring, Nachjustierung, Regressionstests, genau wie jede andere produktive Software. Wer Build wählt, ohne diese Betriebskosten einzuplanen, hat nur die halbe Rechnung gemacht. Wer sie einplant, baut in der Regel günstiger, als der SaaS-Vertrag nach zwei Jahren wäre.

Eine saubere Rechnung berücksichtigt deshalb drei Positionen, nicht zwei: die einmaligen Entwicklungskosten, die laufenden Betriebskosten für Pflege und Monitoring, und die Opportunitätskosten der Kontrolle – was es wert ist, das Preismodell und die Weiterentwicklung nicht von einem externen Anbieter abhängig zu machen. Diese dritte Position taucht in keiner Rechnung eines SaaS-Vertriebs auf, ist für die tatsächliche Entscheidung aber oft die wichtigste.

In technischen Due Diligences begegnet uns das Build-or-Buy-Thema regelmäßig von der anderen Seite: als Risiko im Portfolio, nicht als offene Entscheidung. Ein Portfoliounternehmen hat sich in ein Bündel spezialisierter Agenten-SaaS-Verträge verstrickt, jeder mit eigenem Datenexport, eigener Preislogik, eigener Kündigungsfrist. Kein einzelner Vertrag ist teuer. In Summe binden sie Budget, das für einen eigenen, integrierten Ansatz gereicht hätte – und sie erzeugen Abhängigkeiten, die bei einer Exit-Prüfung als Risiko auffallen, weil niemand im Haus die Logik hinter den Entscheidungen des Agenten erklären kann.

Die umgekehrte Situation kommt genauso häufig vor: ein Unternehmen hat früh selbst gebaut, aber ohne die Betriebsdisziplin, die produktive Software braucht. Der Agent lief in einer Demo überzeugend, nie aber mit echtem Volumen, echten Fehlerfällen und einem Verantwortlichen für den laufenden Betrieb. Für eine Investment Committee ist das schwer einzuschätzen: Ist das ein funktionierendes System oder ein Prototyp mit gutem Marketing? Diese Unsicherheit selbst ist bereits ein Bewertungsabschlag.

Die robustesten Lösungen, die wir in Kundenprojekten aufbauen, sind selten reines Build. Sie kaufen die Infrastruktur – ein Sprachmodell über eine API, eine Automatisierungsplattform wie n8n für die Orchestrierung, Standardwerkzeuge für Monitoring – und bauen die geschäftsspezifische Logik selbst: welche Daten der Agent sieht, welche Schritte er ausführen darf, wann ein Mensch eingreift. Das hält die Entwicklungszeit kurz, ohne Sie von einer Agenten-SaaS abhängig zu machen, deren Preismodell und Entscheidungslogik Sie nicht kontrollieren.

Diese Aufteilung ist auch der Grund, warum Build heute etwas anderes bedeutet als vor wenigen Jahren. Sie bauen keine KI. Sie bauen die Verbindung zwischen einer gemieteten KI und Ihrem Geschäft. Das ist eine deutlich kleinere und beherrschbare Aufgabe, als es klingt.

Am Ende ist Build-or-Buy keine einmalige, unternehmensweite Entscheidung, sondern eine Frage pro Anwendungsfall, die Sie regelmäßig neu stellen sollten. Ein Unternehmen kann für die Terminplanung eine Standardlösung kaufen und für die Angebotserstellung einen eigenen Agenten betreiben – beides gleichzeitig, beides richtig, wenn die Begründung pro Fall stimmt. Problematisch wird es erst, wenn die Entscheidung nach Bauchgefühl oder nach dem lautesten Vertriebsanruf fällt, statt nach den Kriterien, die tatsächlich zählen: Wie unternehmensspezifisch ist der Workflow, wie hoch ist das Volumen, wie viel Nachvollziehbarkeit braucht die Entscheidung, und wer trägt die Lösung danach im Betrieb.

Wir haben kein Interesse daran, jeden Anwendungsfall zu einem Bauprojekt zu machen. Ein ehrlicher Rat, eine SaaS-Lösung zu nutzen, spart Ihnen häufiger Geld und Zeit, als es ein Verkaufsgespräch für ein eigenes System täte. Die Entscheidung sollte der Anwendungsfall treffen, nicht der Anbieter im Raum.