Vom AI-Pilot zum AI Operating System: Wie ein KMU seine AI-Transformation systematisch strukturiert

In vielen Gesprächen mit Unternehmern erlebe ich dieselbe Ausgangslage: Im Unternehmen wird bereits mit AI gearbeitet. Marketing nutzt ChatGPT. Der Vertrieb testet automatische Recherche. Im Kundenservice existiert ein erster Assistent. Einzelne Mitarbeitende bauen eigene Workflows. Auf den ersten Blick wirkt das nach Fortschritt.

Sobald ich genauer nachfrage, entsteht jedoch ein anderes Bild. Niemand kann verbindlich sagen, welche Anwendungen produktiv betrieben werden, welche Daten sie verwenden, wer für ihre Ergebnisse verantwortlich ist und welchen messbaren Beitrag sie leisten. Aus mehreren guten Initiativen ist noch kein belastbares System geworden.

Genau diese Lücke möchte ich in diesem Beitrag anhand eines konkreten Szenarios sichtbar machen. Das folgende Unternehmen ist ein illustrativer Modellfall. Es handelt sich weder um eine reale Kundenreferenz noch um zusammengeführte Kundendaten. Größen, Prozesse und Engpässe sind bewusst realistisch gewählt, um zu zeigen, wie ich eine typische Situation analysieren und strukturieren würde. Die dargestellten Wirkungen sind keine Ergebnisversprechen. Sie zeigen, welche Baselines und Entscheidungskriterien ein Management benötigt.

Mein Grundsatz ist einfach: Ein Unternehmen braucht nicht zuerst mehr AI-Tools. Es braucht Klarheit darüber, wo AI Wert schaffen soll, wie sie in Prozesse eingebettet wird und wer das entstehende System verantwortet.

Unser Modellunternehmen ist ein international tätiges B2B-KMU aus technischer Distribution und Service. Rund 250 Mitarbeitende arbeiten an mehreren Standorten in der DACH-Region und in Grossbritannien. Das Unternehmen ist profitabel, spürt aber Margendruck. Gleichzeitig soll das Geschäft wachsen, ohne dass Verwaltung und operative Teams proportional mitwachsen.

Die Geschäftsleitung hat AI zu einer strategischen Priorität erklärt. Trotzdem werden Kundenanfragen weiterhin manuell verteilt. Informationen liegen in E-Mails, CRM-Feldern, Dokumenten und persönlichen Ablagen. Angebote benötigen Rückfragen, weil Kontext fehlt. Der Kundenservice sucht in verschiedenen Quellen nach Produkt- und Vertragsinformationen. Berichte werden monatlich aus mehreren Systemen zusammengetragen.

Das Unternehmen hat also kein Ideenproblem. Es hat ein Strukturproblem.

Auf Managementebene erscheinen die Symptome zunächst unabhängig voneinander. Der Vertrieb wünscht bessere Lead-Qualifizierung. Operations möchte manuelle Übergaben reduzieren. Der Service fordert einen Wissensassistenten. IT warnt vor Schatten-AI. Finance fragt nach Kosten und ROI. HR sieht wachsenden Schulungsbedarf.

Wenn jede Abteilung für sich optimiert, entstehen neue Insellösungen. Deshalb beginne ich nicht mit der Frage, welches Tool eingeführt werden soll. Ich beginne mit der Frage, welche Fähigkeiten das Unternehmen als Gesamtsystem benötigt.

Das NIST AI Risk Management Framework beschreibt AI-Risikomanagement als organisationsweite Aufgabe und strukturiert sie entlang der Funktionen Govern, Map, Measure und Manage.1 ISO/IEC 42001 verfolgt einen vergleichbaren Managementsystem-Gedanken: Richtlinien, Ziele und Prozesse sollen nicht einmalig dokumentiert, sondern kontinuierlich betrieben und verbessert werden.2 Für mich bestätigt das einen praktischen Punkt: AI wird nicht durch eine Toolentscheidung beherrschbar, sondern durch ein Operating Model.

Der erste Schritt ist keine Technologieauswahl, sondern eine belastbare Bestandsaufnahme. In einem AI Readiness Assessment untersuche ich sechs Dimensionen, die gemeinsam über Skalierbarkeit entscheiden.

Im Modellfall wäre die Experimentierbereitschaft relativ hoch. Prozess-, Daten- und Governance-Reife lägen jedoch deutlich darunter. Diese Asymmetrie ist entscheidend. Sie erklärt, warum Piloten schnell entstehen, aber selten in den stabilen Betrieb gelangen.

Ein professionelles Assessment produziert deshalb nicht nur einen Reifegradwert. Es liefert eine Executive Diagnosis: Wo liegt das grösste Wertpotenzial? Welche Abhängigkeiten blockieren die Umsetzung? Welche Risiken müssen vor einem produktiven Einsatz gelöst werden? Und welche Initiativen sollten bewusst gestoppt werden?

Das Ergebnis ist ein AI Readiness Report mit priorisierten Handlungsfeldern, Risiko- und Opportunity-Map sowie einer klaren Go-/No-Go-Entscheidung für die nächste Stufe. Typischerweise benötigt diese Analyse zwei bis drei Wochen. Entscheidend ist nicht die Seitenzahl des Reports. Entscheidend ist, dass Geschäftsleitung, Fachbereiche und Technologie erstmals auf derselben Entscheidungsgrundlage arbeiten.

Im Modellunternehmen entstehen schnell zehn oder mehr mögliche AI-Anwendungen: Angebotsunterstützung, Lead Research, Service-Assistent, Forecasting, automatisierte Dokumentation, Wissenssuche oder Management Reporting.

Eine lange Use-Case-Liste ist jedoch noch keine Strategie. Ich bewerte Initiativen mindestens entlang von fünf Kriterien.

Für den Modellfall würde ich nicht mit einem umfassenden autonomen Agentensystem starten. Ich würde einen klar begrenzten Ende-zu-Ende-Prozess priorisieren: von der eingehenden Kundenanfrage bis zur qualifizierten Übergabe und vollständigen CRM-Dokumentation.

Dieser Prozess ist geschäftlich relevant, wiederholt sich häufig und berührt mehrere Systemebenen. Gleichzeitig bleibt der Mensch an kritischen Entscheidungspunkten verantwortlich. Damit eignet er sich, um nicht nur ein Tool, sondern die Funktionsweise des späteren AI Operating Systems zu erproben.

Nach dem Assessment weiss das Management, wo das Unternehmen steht. Der AI Transformation Blueprint beantwortet die nächste Frage: Was bauen wir in welcher Reihenfolge und unter welchen Bedingungen darf es produktiv werden?

Für unseren Modellprozess könnte das Zielbild so aussehen:

Der Blueprint beschreibt aber nicht nur diesen Ablauf. Er verbindet Prozessdesign, Datenquellen, Integrationen, AI-Komponenten, Rollen, Kontrollen, KPI-Baselines und eine realistische Implementierungssequenz. Er legt auch fest, was nicht automatisiert wird.

Der EU AI Act folgt einem risikobasierten Ansatz und verlangt je nach Anwendung unter anderem angemessene Risikobewertung, Datenqualität, Dokumentation, menschliche Aufsicht, Robustheit und Genauigkeit.3 Auch wenn nicht jeder KMU-Use-Case als Hochrisiko-System einzustufen ist, sind diese Prinzipien gute Architekturregeln: Je grösser die mögliche Auswirkung einer AI-Entscheidung, desto klarer müssen Kontrolle, Nachvollziehbarkeit und Eskalation sein.

Ein belastbarer Blueprint benötigt in diesem Szenario vier bis sechs Wochen. Danach besitzt das Management keine unverbindliche AI-Roadmap, sondern eine Investitions- und Umsetzungsgrundlage.

Ein AI Operating System ist keine einzelne Plattform. Ich verstehe darunter eine steuerbare Architektur aus sechs Schichten.

Diese Schichten müssen nicht von einem Anbieter stammen. Entscheidend ist, dass Schnittstellen, Verantwortlichkeiten und Austauschbarkeit bewusst gestaltet werden. So kann ein Unternehmen Modelle oder Tools wechseln, ohne den gesamten Prozess neu aufzubauen.