Ich habe heute einen alten dotnetpro-Stapel aus dem Schrank gezogen. Ausgabe
12/2020. Darin ein Artikel mit dem Titel "Intelligente Systeme aus der
Cloud", geschrieben von zwei Adesso-Leuten. Untertitel:
Artificial Intelligence as a Service (AIaaS) ist eine Möglichkeit,
KI-Anwendungen schnell und ohne große Investitionen in Hardware, Software
oder Know-how zu bauen.
Das war Dezember 2020. ChatGPT kam zwei Jahre später. Die Hälfte dessen, was
heute "KI" heißt, gab es schlicht noch nicht.
Trotzdem lese ich den Artikel und denke: 70% davon stehen erstaunlich gut da.
Die anderen 30% sind ein Lehrstück darüber, wie sehr eine einzige
Architektur-Welle ein ganzes Mental-Model wegspülen kann.
Was 2020 als das nächste große Ding galt
Der Artikel führt eine schöne Schichten-Grafik an:
┌──────────────────────────┐
│ KI-Services (APIs) │ ← AIaaS-Layer
├──────────────────────────┤
│ Processing │
├──────────────────────────┤
│ Integrationsschicht │ ← PaaS
├──────────────────────────┤
│ Daten │ ← IaaS
└──────────────────────────┘
Die Idee dahinter: Statt Tensorflow-Modelle selbst zu trainieren, ruft die
Anwendung eine fertige API auf — Microsoft Azure Cognitive Services, AWS
Rekognition, Google Vision. Der Artikel nennt als konkretes Beispiel:
Als beispielsweise Uber nach Möglichkeiten suchte, die Identität eines
Fahrers zu überprüfen, entschied das Unternehmen, dafür die Microsoft
Azure Cognitive Services (Face-API) zu verwenden, anstatt eine eigene
Lösung zu entwickeln.
Klingt heute fast rührend. Die Face-API gibt's in der damaligen Form
nicht mehr,
das Cognitive-Services-Portfolio ist 2023 in Azure AI Foundry aufgegangen, und
"Gesichtserkennung via Cloud-API" ist heute aus EU-AI-Act-Gründen eine
juristisch komplizierte Übung. Der konkrete Use-Case ist auf zwei Achsen
gleichzeitig veraltet: technisch und regulatorisch.
Das Bild von der KI-Historie
Im Artikel gibt es einen zweiten Klassiker — die Venn-Diagramm-Zwiebel:
| Schicht | Jahr im Artikel |
|---|---|
| Künstliche Intelligenz | 1950 |
| Maschinelles Lernen | 1980 |
| Deep Learning | 2010 |
Das wars. Punkt. 2020 hat man Deep Learning als die letzte Welle gezeichnet.
Wenn ich das Diagramm heute zeichne, gehört da noch eine vierte Schicht rein,
und sie heißt "Foundation Models / LLMs / 2022". Die ist nicht nur eine
weitere Spielart von Deep Learning. Sie hat die ganze
Pipeline-Diskussion, die der Artikel führt, kassiert.
Aus dem Artikel:
Im Gegensatz zu den einfachen erfordern die komplexen KI-Algorithmen den
Aufbau einer langen Verarbeitungspipeline, die Datenvorverarbeitung,
Trainieren, Parameteroptimierung und Bewertung umfasst.
Korrekt für 2020. Heute baut ein Team unter 5 Leuten genau null dieser
Pipelines selbst. Die meisten Use-Cases lösen sich mit:
1. Foundation-Model-API aufrufen
2. Im Prompt den Kontext mitliefern
3. Antwort parsen
Das war's. Die Schritte "Daten labeln, Modell trainieren,
Hyperparameter-Tuning" sind aus dem Standard-Workflow von Anwendungs-Entwicklung
fast vollständig verschwunden. Es gibt sie noch — aber in der Forschung und
bei den drei großen Foundation-Model-Anbietern. Nicht beim KMU-Berater.
Was tatsächlich gehalten hat
Drei Aussagen aus dem Artikel sind 2026 sogar wahrer als 2020:
1. Vendor Lock-in als Hauptrisiko
Neben der Abhängigkeit vom Dienstanbieter und der Beschränkung auf
Standardlösungen ist die Sicherheit der Daten und Transaktionen nicht
ohne Weiteres gewährleistet.
Damals dachte man dabei an Azure-vs-AWS. Heute heißt das Lock-in
OpenAI-vs-Anthropic-vs-Google-Gemini, der Switch ist gleichzeitig einfacher
(API-Wrapper austauschbar) und gefährlicher (Prompt-Verhalten
unterscheidet sich subtil). Wer 2025 alles auf GPT-4 gebaut hat, durfte 2026
auf GPT-5 prompt-engineering-mässig neu lernen. Die Sicherheitsfrage —
"verlassen meine Kundendaten das Unternehmen?" — ist mit
Trainings-Daten-Skandalen seit 2024 massiv schärfer geworden.
2. Schwarze Box
Manchmal enthält die Dokumentation Formeln oder Links zu einer
Veröffentlichung, auf der die Implementierung basiert. Meistens werden
jedoch nur der Name und das API des Algorithmus dokumentiert. Hier muss
der Kunde auf die Genauigkeit und Effizienz des implementierten
Algorithmus vertrauen.
Wenn man "Algorithmus" durch "LLM" ersetzt, ist der Absatz wortwörtlich heute
gültig. Niemand weiß genau, was im Modell-Inneren passiert. Halluzinationen,
Bias, gelegentliche logische Aussetzer — der einzige Weg, das in den Griff zu
bekommen, sind systematische Tests gegen Erwartungswerte. Der Artikel-Satz
"Daher werden systematische Tests empfohlen" gilt 2026 mehr denn je. Trotzdem
machen ihn die meisten KMUs nicht.
3. Klein anfangen, dann skalieren
Mit dem AIaaS-Ansatz können Unternehmen mit kleineren Projekten beginnen,
um festzustellen, ob der Ansatz für das Unternehmen geeignet ist.
Das ist der Satz, den ich in jedem Mittelstands-Erstgespräch zitiere. Wer
2026 mit einem 6-Monats-KI-Konzept-Projekt startet, hat verloren. Wer einen
echten Workflow nimmt — "drei Vertriebsmitarbeiter verbringen 12 Stunden pro
Woche damit, Anfragen aus Outlook zu klassifizieren" — und in zwei Wochen
einen API-gestützten Prototypen daneben stellt, hat eine Datengrundlage für
die nächste Entscheidung.
Was 2026 für den Mittelstand wirklich gilt
Wenn ich den Artikel zu meinen aktuellen Mandaten halte und die Punkte
übersetze:
Das alte AIaaS-Versprechen — "Kosten sparen, kein KI-Know-how nötig" — ist
2026 sogar einlösbarer als 2020. Damals brauchte man einen Backend-Entwickler,
der das HTTPS-API von Cognitive Services aufrufen konnte. Heute reicht
weitgehend ein Workflow-Tool wie n8n oder Zapier, das den LLM-Endpunkt
einbindet und die Ausgabe in eine bestehende Anwendung schreibt.
Die alte AIaaS-Warnung — "Vendor Lock-in, Algorithmen-Updates,
Datenschutz" — ist 2026 ebenfalls schärfer. Die DSGVO-konforme Nutzung von
OpenAI ist ein technisch lösbares aber operativ ungeklärtes Thema, an dem die
meisten Mittelständler immer noch zögern (zu Recht). Wer EU-konform bleiben
will, schaut sich Anthropic-EU-Region oder Mistral oder lokal gehostete Modelle
an. Das war 2020 noch keine Option.
Was 2020 niemand auf dem Schirm hatte: Die Total Cost of Ownership einer
KI-Integration ist heute weniger durch Infrastruktur als durch das Maintenance
des Prompts und das Testing der Modellantworten dominiert. Das ist
schlechte Nachricht für klassische SaaS-Vertriebs-Stories ("kein Know-how
nötig"), aber gute Nachricht für meine Zunft: das ist genau die Arbeit, die
ein Berater im Mittelstand absorbieren kann.
Die ehrliche Empfehlung an einen KMU-Entscheider im Sommer 2026
- Pick einen konkreten Workflow, der heute Zeit kostet. Keine
strategische "KI-Roadmap". Ein Workflow. - Frag dich: Würde ein gut prompts-trainierter Werkstudent diesen
Workflow erledigen? Wenn ja, ist's ein KI-Kandidat. Wenn nein
(Schadenregulierung, Bonitätsprüfung, alles mit rechtlich-relevanter
Begründungspflicht), Finger weg. - Baue einen Prototyp in 2 Wochen mit einer Foundation-Model-API. Nicht
in 6 Monaten mit einem Trainings-Pipeline. - Schreibe von Tag 1 Tests gegen Erwartungswerte. Wenn das Modell für
100 historische Eingaben das gleiche oder besseres Ergebnis liefert als
der menschliche Bearbeiter, ist's tragfähig. Wenn nicht, weißt du warum
nicht. - Ignoriere alles, was nach "AIaaS-Plattform" oder "KI-Strategie-Beratung"
klingt. Das ist 2020-er Sprache für 2026-er Probleme.
Der Adesso-Artikel von 2020 hat ein robustes Mental-Model gezeichnet, das die
LLM-Welle in der Mitte gespalten hat — aber an den Rändern erstaunlich stabil
geblieben ist. Vendor-Risiko, Black-Box-Problem, Klein-anfangen-und-skalieren
sind die Konstanten. Was sich geändert hat, ist die Reichweite dessen, was eine
einzelne API tatsächlich leistet — und damit, wie schnell der Schritt von
"Idee" zu "Prototyp" sein darf.
Wenn du gerade an deinem ersten KI-Projekt im Mittelstand sitzt und unsicher
bist welcher Workflow sich lohnt: das ist genau der Gesprächsanlass für
30 Min Klartext-Sparring. Kostenfrei,
kein Verkaufsdruck, ich sage dir ehrlich ob ich helfen kann oder nicht.
— Bernhard