KI-native Services vs. KI-gestütztes SaaS: Was sollten Sie wirklich bauen?

2024 hat Emergence Capital einer Entwicklung einen Namen gegeben, die schon ein paar Jahre leise im Gange war: KI-native Services, kurz AINS (AI-native services). Die Idee klingt einfach. Statt ein Tool zu verkaufen und die Arbeit dem Kunden zu überlassen, verkaufen Sie das fertige Ergebnis und bleiben dafür verantwortlich. Kein Dashboard, das man lernen muss, keine Lizenz, die eingerichtet werden will, kein „So würden Sie unsere API nutzen, um das selbst zu lösen“. Der Kunde übergibt Ihnen die Aufgabe. Sie liefern das Ergebnis zurück.

2026 ist das keine VC-These mehr. Es ist eine konkrete Entscheidung, die jeder Gründer treffen muss, der mit KI baut, meist ohne zu merken, dass er sie gerade trifft. Bauen Sie ein Tool, das jemand bedient, oder einen Service, der sich selbst bedient? In einer Demo sehen beide ähnlich aus. Im Betrieb, in der Preisgestaltung und im Vertrieb sind es völlig verschiedene Geschäfte. Wer hier falsch liegt, verliert ein Jahr.

Was ist der tatsächliche Unterschied zwischen einem KI-nativen Service und KI-gestütztem SaaS?

KI-gestütztes SaaS ist immer noch Software. Die KI macht sie schneller oder klüger, aber die Arbeit erledigt weiterhin der Kunde: Er lädt die Daten hoch, prüft die Ergebnisse und entscheidet, was damit passiert. Sie verkaufen eine Fähigkeit. Der Wert zeigt sich erst, wenn jemand im Team des Kunden gelernt hat, sie gut zu nutzen.

Ein KI-nativer Service überspringt diesen Schritt komplett. Der Anbieter verantwortet das Ergebnis, nicht nur das Werkzeug, das vielleicht eines liefert. Ein AINS-Unternehmen für Schadensbearbeitung verkauft Ihnen keine Schadenssoftware, es bearbeitet die Schäden. Ein AINS-Unternehmen für Buchhaltung verkauft Ihnen kein klügeres Hauptbuch, es schließt Ihre Bücher ab. Wird die Aufgabe nicht erledigt, ist das das Problem des Anbieters, kein Support-Ticket.

Deshalb funktioniert ergebnisbasierte Preisgestaltung bei AINS so, wie sie bei SaaS nie ganz funktioniert hat. Softwareanbieter versuchen seit zehn Jahren, den Preis an den Wert zu koppeln, und stoßen dabei auf das Zuordnungsproblem: Wie viel vom Erfolg des Kunden kam vom Tool, und wie viel von dessen eigener Arbeit? Ein KI-nativer Service hat dieses Problem nicht. Der Service ist das Ergebnis. Sie können pro bearbeitetem Schadensfall abrechnen, pro abgestimmtem Konto, pro Anruf, der zu einem Termin wurde, weil es in der Wertschöpfungskette nichts anderes gibt, worüber man streiten könnte.

Warum heben KI-native Services gerade jetzt ab?

Die ehrliche Antwort lautet: wegen der Budgets, nicht wegen der Neuheit. Pear VC hat die Zahlen hinter seinen AINS-Investments klar benannt: Die Ausgaben für Rechtsdienstleistungen liegen etwa beim 40-Fachen der Ausgaben für Rechtssoftware. Im Finanzbereich ist es etwa das 26-Fache. Im Recruiting fast das 38-Fache. Genau in dieser Lücke liegt die ganze Chance. Das Budget existiert bereits, es wird bereits für Menschen ausgegeben, die die Arbeit von Hand erledigen, und niemand muss von einer neuen Budgetposition überzeugt werden. Sie verkaufen kein neues Tool in ein stagnierendes Budget. Sie bieten an, dieselbe Arbeit, für die der Kunde schon bezahlt, schneller und günstiger zu erledigen.

Das funktioniert allerdings nur bei bestimmten Arten von Arbeit. Das Muster greift dort, wo die Aufgabe in großen Mengen und wiederholbar anfällt, wo die Logik regelbasiert und nicht wirklich urteilsintensiv ist und wo sich messen lässt, ob etwas korrekt erledigt wurde. Versicherungsschäden, Fondsverwaltung, KYC-Prüfungen, medizinische Kodierung und Abrechnungsmanagement, Zollabwicklung: Diese Bereiche tauchen im AINS-Dealflow ständig auf, weil sie unter all dem Papierkram dasselbe Problem sind. Viel Volumen, klare Regeln, ein überprüfbares Ergebnis.

Vier Fragen, bevor Sie entscheiden, was Sie bauen

Wenn Sie als Gründer herausfinden wollen, ob Ihre Idee ein Tool oder ein Service ist, sind das die Fragen, die beides wirklich voneinander trennen:

Ist die Arbeit regelbasiert oder urteilsintensiv? AINS gewinnt bei Ersterem. Wenn jeder Fall echtes Urteilsvermögen erfahrener Menschen erfordert, ohne wiederholbares Muster darunter, bauen Sie ein Werkzeug zur Entscheidungsunterstützung, keinen Service, der den Entscheider ersetzt.

Können Sie das Ergebnis tatsächlich messen? Nicht „der Kunde wirkt zufriedener“, sondern eine Zahl: Schadensfall korrekt bearbeitet, Konto abgestimmt, Anruf in einen Termin umgewandelt. Wenn Sie das nicht sauber messen können, können Sie es nicht als Ergebnis bepreisen, und Sie verkaufen wieder Software.

Gibt es das Budget schon? Die besten AINS-Ideen ersetzen eine bestehende Budgetposition (ein Team, einen externen Dienstleister, einen manuellen Prozess), statt vom Kunden zu verlangen, neues Budget für eine Kategorie zu finden, die er noch nie gekauft hat.

Macht jeder Auftrag das System besser? Ein echtes AINS-Unternehmen baut vom ersten Tag an ein Daten-Schwungrad auf, bei dem jeder bearbeitete Fall den nächsten verbessert. Wenn Ihre Leistungserbringung sich nicht so aufschaukelt, betreiben Sie ein Dienstleistungsgeschäft mit KI-Funktion. Das ist ein gutes Geschäft, nur eben nicht dieses.

Was ist „Mirage PMF“ und wie vermeiden Sie es?

Die nützlichste Warnung in diesem Feld betrifft nicht die Marktgröße, sondern Selbsttäuschung. Emergence nennt es „Mirage PMF“: Umsatz- und Kundenwachstum, das wie ein Beweis aussieht, dass die KI funktioniert, während in Wahrheit ein Team von Menschen still hinter der Oberfläche die Arbeit macht. In diese Falle tappt man leicht, denn dem Kunden ist egal, wie das Ergebnis zustande kommt, solange es kommt. Und früher Umsatz macht Gründer immer zuversichtlicher, als es die tatsächliche Hebelwirkung rechtfertigt.

Das Warnsignal steckt in den Stückkosten, nicht im Umsatz. Wenn die Kosten pro bearbeitetem Fall mit wachsendem Volumen nicht sinken, haben Sie keinen KI-nativen Service. Sie haben ein Dienstleistungsgeschäft mit KI-Logo, und sobald ein gut finanzierter Wettbewerber denselben Ablauf wirklich automatisiert, wird diese Lücke sehr schnell sehr sichtbar.

Es gibt noch einen zweiten Kostenfaktor, den viele unterschätzen: Wer das Ergebnis verantwortet, haftet auch, wenn die KI etwas falsch macht. Das ist ein anderes Risikoprofil, als Code auszuliefern und ein Tool zu übergeben, das jemand anderes bedient. Dieses Risiko sollten Sie von Anfang an einpreisen, nicht erst nach dem ersten falsch bearbeiteten Schadensfall oder der ersten verpassten Compliance-Frist.

Wo wir das selbst gespürt haben

Wir wollten keinen Grundsatzartikel über AINS schreiben. Wir haben das Muster bemerkt, weil wir schon halb hineingebaut hatten, mit Callen AI, dem KI-Rezeptionisten, den wir für Praxen entwickelt haben und betreiben. Callen verkauft kein Dashboard. Es nimmt den Anruf an, bucht den Termin und trägt ihn in den Kalender ein. Die Praxis bedient kein Tool, ihre Anrufe werden beantwortet.

Und trotzdem bepreisen und verpacken wir Callen derzeit wie SaaS: eine feste Monatsgebühr, gestaffelt nach Anrufvolumen, so wie man jedes Abo-Produkt bepreist. Genau das ist die Spannung, um die es in dieser ganzen Kategorie geht. Die ROI-Rechnung, die wir zu Callen veröffentlicht haben, also eine Praxis, die etwa 1.000 € im Monat an Terminen zurückholt bei Kosten von rund 99 € im Monat, ist im Kern ein ergebnisbasiertes Argument, auch wenn die Rechnung wie eine Softwarerechnung aussieht. Wir könnten stattdessen pro beantwortetem Anruf oder pro gebuchtem Termin abrechnen, und das würde wohl ehrlicher abbilden, was die Praxis tatsächlich kauft. Diesen Schritt haben wir noch nicht gemacht, und wir tun nicht so, als sei die Entscheidung offensichtlich. Es ist dieselbe Abwägung, vor der jeder Gründer in diesem Feld steht: Ergebnisbasierte Preise sind besser zu verteidigen, aber auch eine schwerere Verpflichtung, operativ wie rechtlich, als eine Abo-Zeile.

Was uns die Entwicklung von Callen gelehrt hat, unabhängig davon, welches Preismodell sich durchsetzt: Disziplin beim Umfang ist wichtiger als die KI selbst. Die Version für die Praxisrezeption funktioniert, weil sie eine Aufgabe vollständig erledigt, statt ein Allzweck-Sprachagent sein zu wollen. Das gilt, ob Sie ein Tool oder einen Service bauen. Wählen Sie die engste Version der Aufgabe, beweisen Sie, dass Sie sie von Anfang bis Ende erledigen können, und entscheiden Sie erst dann, wie Sie dafür abrechnen wollen.

Was das für Sie praktisch bedeutet

Wenn Sie als Gründer in der Pre-Seed- oder Seed-Phase entscheiden, was Sie als Nächstes bauen, ist die AINS-Frage nicht akademisch. Sie verändert Ihre gesamte Roadmap. Ein Tool braucht Onboarding-Abläufe, Dokumentation und einen Self-Service-Funnel. Ein Service braucht Lieferkapazität, Glaubwürdigkeit in der Branche und eine Preisgestaltung, die einer Prüfung Ihrer eigenen Stückkosten standhält. Wer das Falsche baut, scheitert nicht laut. Das Geschäft wächst einfach langsamer, als es sollte, aus Gründen, die wie ein Go-to-Market-Problem aussehen, aber eigentlich ein Geschäftsmodellproblem sind.

Wenn Sie gerade vor dieser Entscheidung stehen und eine zweite, technisch ehrliche Einschätzung wollen, bevor Sie Entwicklungszeit in das eine oder andere Modell stecken, ist das genau die Art von Gespräch, das wir gern führen, bevor jemand Code schreibt.