SaaS: Wenn Software die Arbeit übernimmt, verkaufen Anbieter keine Werkzeuge mehr, sondern Ergebnisse.
Der Übergang vom Werkzeug-Modell zum Ergebnis-Modell verändert die Software-Industrie. Die ökonomische Pointe ist größer, als die meisten Analysten bisher eingepreist haben.
Zusammenfassung (TL; DR):
- Der Übergang vom klassischen SaaS-Modell zu „Service as Software“ transformiert die Softwareindustrie. Anbieter verkaufen statt Werkzeugen fertige Arbeitsergebnisse und stelle die Preisgestaltung von Nutzer-Seats auf Arbeitsergebnisse um.
- Diese agentischen Systeme, gestützt durch massive Investitionen in KI-Infrastruktur, übernehmen ganze Workflows. Branchen wie Cybersecurity sind aufgrund messbarer Ergebnisse Vorreiter dieser Entwicklung.
Die SaaS-Industrie diskutiert seit Monaten ihren eigenen Tod. Investmentbanken sprechen vom Ende der Per-Seat-Ökonomie. Analysten skizzieren eine „SaaS-pocalypse“. Auf der anderen Seite stehen Risikokapitalgeber und eine neue Anbietergeneration unter dem Etikett „Service as Software“. Ihr Versprechen reicht über die klassische Mitarbeiter-Beschleunigung hinaus. Sie wollen den Workflow vollständig übernehmen. An dieser These ist viel Richtiges. Was sie allerdings unterbeleuchtet lässt, ist die ökonomische Mechanik, die den Wandel eigentlich antreibt: Das Wertvollste, was ein Software-Unternehmen verkaufen kann, ist nicht mehr das Werkzeug. Es ist die fertige Arbeit.
SaaS: Vom Werkzeug zum Ergebnis
Das alte Modell ist nüchtern beschreibbar. Ein Unternehmen mietet eine Software, ein Mitarbeiter loggt sich ein und erledigt damit seine Aufgaben schneller als ohne dieses Werkzeug. Bezahlt wird pro Seat, also pro bereitgestelltem Zugang. Was der Mitarbeiter damit tatsächlich produziert, ist für die Abrechnung irrelevant. Der Anbieter schöpft einen kleinen Anteil des erzielten Produktivitätsgewinns ab. Das Paradigma stammt aus der Ära von Fabriken und Maschinen: Man bezahlt das Instrument, die Arbeit, die es führt, bezeichnet den Wert.
In agentischen Architekturen kippt dieses Verhältnis. Die Plattform selbst führt den Workflow aus, der Mitarbeiter überwacht das Ergebnis. Konsequent verschiebt sich auch die Preislogik. Wer eine Aufgabe vollständig automatisiert, verkauft fertige Arbeit, keine Seats. In diesem Moment hören Anbieter auf, um das Software-Budget zu konkurrieren — endlich, gut kontrolliert, einige tausend Dollar pro Mitarbeiter und Jahr — und beginnen, um das Personalbudget zu konkurrieren, das in den meisten Unternehmen ein Vielfaches davon beträgt. Das ist die ökonomische Pointe der Service-as-Software-These. Und es ist der Grund, warum die Kategorie um eine Größenordnung mehr Investorenaufmerksamkeit auf sich zieht, als es die Per-Seat-Ära je getan hat.
Wie ernst die Hyperscaler diese Verschiebung nehmen, lässt sich direkt an ihren Bilanzen ablesen. Die vier großen US-Hyperscaler Microsoft, Alphabet, Amazon und Meta haben für 2026 zusammen Capex-Pläne in Höhe von rund 725 Milliarden Dollar angekündigt. Das ist etwa 77 Prozent über dem Rekordjahr 2025, wobei der Großteil davon in AI-Infrastruktur fließt statt in klassische Cloud-Erweiterungen. Eine Größenordnung wie diese ist keine Wette auf eine neue Anwendungswelle. Sie ist das physische Fundament einer Software-Generation, die Workflows ausführt, wo bisherige Generationen sie nur unterstützt haben.
Wo die Verschiebung zuerst Fuß fasst
Nicht jede Software-Kategorie wird diesen Wandel im gleichen Tempo durchlaufen. Die Kategorien, die zuerst kippen, teilen einige strukturelle Eigenschaften: Der Großteil der Arbeit ist automatisierbar, die Ausnahmen brauchen aber echte Expertise; die Ergebnisse sind objektiv messbar; und das Budget existiert bereits in irgendeiner Outsourcing-Position, bereit, umgeleitet zu werden.
Nach diesen Kriterien steht die Cybersecurity ganz vorn. Der Fachkräftemangel ist strukturell — laut der letzten Lückenschätzung von ISC2 fehlen weltweit rund 4,8 Millionen qualifizierte Fachkräfte — und er verschärft sich, je weiter die Angriffsfläche sich ausdehnt. Die Ergebnisse sind inhärent verifizierbar: Eine Schwachstelle existiert oder nicht, ein System erfüllt einen Compliance-Rahmen oder nicht. Und das Budget liegt bereits bereit: Managed Security Service Provider und Beratungsfirmen erledigen seit Jahren die Arbeit, die AI-native Plattformen heute übernehmen können. Eine ausgelagerte Sicherheitsleistung durch eine software-gelieferte zu ersetzen, ist ein Anbieterwechsel, keine organisatorische Umstrukturierung.
Angrenzende Kategorien — IT-Operations, Observability, Teile von Finance und Legal — teilen genug dieser Eigenschaften, um auf einer ähnlichen Kurve nachzuziehen. Marketing und Design werden irgendwann folgen, aber das Verifizierbarkeits-Problem ist dort schwerer und die Schwelle für glaubwürdige Ergebnisse entsprechend höher.
Die Architektur, die in der Praxis funktioniert
Die stärkste Variante des Service-as-Software-Modells ist nicht reine Automatisierung. In jeder hochkritischen Domäne hat eine selbstbewusste, aber falsche Aktion eines autonomen Agenten Folgen, die die Effizienzgewinne, die er liefern sollte, leicht überwiegen. Die glaubwürdigen Architekturen verbinden agentische AI mit menschlichen Experten: AI für Volumen und Geschwindigkeit bei der regelbasierten, verifizierbaren, automatisierbaren Arbeit, und Menschen für Urteilsvermögen und Vertrauen bei den Randfällen, den Risiko-Abwägungen und dem Kontextverständnis, das sich noch nicht auf ein Modell reduzieren lässt. Reine Automatisierung hat eine Decke. AI plus Experten-Aufsicht nicht.
Das ist das Muster, das ernsthafte Service-as-Software-Anbieter von der Welle der „AI-native“-SaaS-Umetikettierungen unterscheidet, die einen Chatbot auf ein bestehendes Tool setzen und den Workflow für erledigt erklären.
Die alten Schwächen wandern mit
Bei aller berechtigten Aufregung löst der Architekturbruch die Betriebsprobleme des klassischen SaaS-Modells nicht. Eher verschärft er sie.
Ein klassischer SaaS-Ausfall blockiert ein Tool. Ein agentischer Ausfall blockiert ganze Geschäftsprozesse. Wer die Wertschöpfung an einen Dienst delegiert, übernimmt das volle operative Risiko des Dienstes mit. Der AWS-Vorfall im Oktober 2025, der unter anderem britische Verwaltungsdienste lahmlegte, hat dieses Konzentrationsrisiko nüchtern vorgeführt.
Hinzu kommt eine regulatorische Dimension, die europäische Käufer nicht ignorieren können. Plattformen, die Workflows autonom ausführen, brauchen weit mehr Kontext als ein Dashboard — oft den vollständigen Kunden- und Transaktionsbestand, oft in Echtzeit. Für Workloads in regulierten Branchen entsteht daraus die Pflicht, sorgfältig zu prüfen, wo die Daten liegen und welche Jurisdiktion sie regiert. Die EU hat ihren Regulierungsstapel — DSGVO, NIS2, DORA, Data Act — genau deshalb aufgebaut, weil die Antworten relevant sind. Nichts davon ist ein Grund, vom Outcome-Modell zurückzutreten. Es ist ein Grund, es bewusst zu konstruieren, mit Deployment-Optionen, die zum regulatorischen Profil des Workloads passen.
Was Anwender und Anbieter daraus ableiten sollten
Für Anwender folgt daraus eine ungewohnte Beschaffungslogik. Bewertet wird nicht mehr Software-Verfügbarkeit und Benutzeroberfläche, sondern Arbeitsqualität und Fehlerquote. Outcome-basierte Kennzahlen — Erledigungsraten, Fehlerquoten, Mean Time to Resolution — ersetzen Feature-Checklisten. Das Pricing folgt: Per-Outcome-, Per-Asset- oder Per-Transaktion-Modelle bringen die Anreize des Anbieters mit dem gelieferten Wert in einer Weise in Übereinstimmung, wie es Per-Seat-Lizenzierung nie konnte. Und die operative Folge ist real: Wenn Plattformen die Routinearbeit absorbieren, führen weniger Mitarbeiter im Junior-Bereich Aufgaben aus, und mehr Architekten definieren Richtlinien, prüfen Agenten-Outputs und steuern die Systeme, die in ihrem Auftrag handeln.
Für Anbieter heißt das, die Architektur grundlegend zu öffnen. Software, die nur in der eigenen Umgebung deploybar ist, hat in hochregulierten Sektoren ein Verfallsdatum. Pricing wandert von Seat-basiert zu nutzungs- oder Outcome-basiert. Der Support läuft komplexer, weil mehrere Deployment-Modelle parallel zu betreuen sind. Die Anforderung an Transparenz steigt entsprechend: Autonome Ausführung erfordert Vertrauen, und das heißt: offene Audit-Trails jeder automatisierten Aktion, offene und erweiterbare Fundamente statt Black Boxes, und echte menschliche Experten im Loop, die Outputs validieren und die Randfälle behandeln können, die reine Automatisierung unweigerlich produziert.
Die Meta-Dimension
Schließlich gibt es eine Meta-Dimension, die hier erwähnt werden sollte. Während AI-Agenten sich quer durch jede Unternehmensfunktion ausbreiten — Vertrieb, Finanzen, Operations, Engineering — entsteht aus dem Bedarf, diese Agenten zu steuern, ein eigener Markt. Dieselben agentischen Fähigkeiten, die Arbeit automatisieren, müssen auch abgesichert, überwacht und in die Verantwortung genommen werden. Zwei benachbarte Disziplinen konvergieren: Agenten zur Erledigung der Arbeit einsetzen — und die Agenten, die sie ausführen, absichern. Die Unternehmen, die die erste Hälfte richtig hinbekommen, finden sich für die zweite Hälfte einzigartig aufgestellt wieder.
Die Service-as-Software-Ära kommt; dafür sorgt schon der Zinseszinseffekt der Hyperscaler-Investitionen. Welche Anbieter sich darin durchsetzen, hängt aber nicht allein von der Qualität ihrer Agenten ab. Es hängt davon ab, ob sie die eigentliche Arbeit verkaufen — nicht nur das Werkzeug, sondern das Ergebnis — und ob sie diese Arbeit glaubwürdig genug liefern, um mit dem Personalbudget betraut zu werden, nicht nur mit dem Software-Budget.
