Operating Model für AI Native: drei Bausteine, zwei Rollen, ein Freigabe-Pfad.

Die schwierigste Frage in den ersten 90 Tagen einer KI-Transformation lautet selten „Welches Sprachmodell?“. Sie lautet „Wer legt morgen eine neue KI-Funktion an, wer gibt sie frei, wer haftet, und wer protokolliert das?“. Sobald diese Frage steht, reden Sie nicht mehr über ein Tool. Sie reden über ein Operating Model.

AI Native ist ohne Operating Model ein Schreibtisch-Konzept. Mit Operating Model ist es ein Arbeitsablauf, in dem ein Power-User aus Ihrer Buchhaltung morgen eine neue Funktion bereitstellt, ohne dass ein Entwickler-Ticket in eine Warteschlange wandert. Genau dort verkauft die klassische Beratung Folien. Wir bauen Plattform.

Dieser Artikel zeigt, wie ein AI-Native Operating Model konkret aussieht: drei Bausteine, zwei neue Rollen, ein Freigabe-Pfad und ein Audit-Trail. Alle Bausteine sind heute live oder befinden sich in laufender Auslieferung in den 25 Customer-Stacks der sensified Customer-Factory.

Die drei harten Bausteine im Operating Model

Ein AI-Native Operating Model steht auf einem Funktions-Baukasten mit fertigen KI-Funktionen, einem Selbst-Bau-Werkzeug für Ihre Power-User und einer KI-Schaltzentrale, die alle Schritte koordiniert. Ohne diese drei Bausteine bauen Sie eine Tool-Sammlung. Mit ihnen bauen Sie ein Operating Model.

Die drei Bausteine, ohne die kein AI-Native Operating Model trägt

Wir reden mit Mittelstands-Geschäftsführern oft in genau dieser Reihenfolge, weil sie der Realität der Belegschaft folgt.

1. Funktions-Baukasten. Ein Satz fertiger KI-Funktionen, die heute live laufen. In der sensified Foundation sind das aktuell Angebot erstellen, Lebenslauf aufbereiten und Kontakt-Mail dokumentieren. Jede dieser Funktionen folgt einem klaren Regelwerk: feste Geschäftslogik, KI-Vorschlag als Helfer, Freigabe-Schritt am Ende, alles im Audit-Trail.
2. Selbst-Bau-Werkzeug. Eine Maske, in der ein Power-User aus Ihrer Buchhaltung, Ihrem Vertrieb oder Ihrem HR neue Funktionen ohne Programmierer anlegt. Eingaben festlegen, einen KI-Assistenten als Helfer einbinden, einen Test-Lauf machen, einen Freigabe-Schritt setzen, fertig. Pro Mandant 30 eigene Funktionen, damit der Funktions-Baukasten geordnet bleibt.
3. KI-Schaltzentrale. Eine Koordinations-Ebene, die alle KI-Schritte sieht, an Freigaben bindet und im Protokoll mitführt. Wenn drei Mitarbeiter dieselbe Funktion fünfmal pro Stunde aufrufen, sehen Sie das. Wenn eine Funktion zu oft scheitert, sehen Sie das auch.

Ohne einen dieser drei Bausteine kippt das Modell. Funktions-Baukasten ohne Selbst-Bau-Werkzeug bringt Sie in die Tool-Logik zurück. Selbst-Bau-Werkzeug ohne KI-Schaltzentrale baut Schatten-Funktionen, die niemand mehr überblickt. KI-Schaltzentrale ohne fertigen Funktions-Baukasten ist eine Koordinations-Plattform ohne Inhalt.

Funktions-Baukasten: woher Ihre KI-Funktionen 2026 wirklich kommen

Im Mittelstand-Kontext werden KI-Funktionen 2026 aus drei Quellen geliefert, und ein gutes Operating Model bedient alle drei.

• Standard-Funktionen aus der Plattform. Was in jedem Stack gleich aussieht (Angebot, Brief, Mail, Recherche, Wissens-Suche), liefert die Plattform mit jeder Auslieferung mit. Sie zahlen nicht pro Sitz, sondern nutzen den Bestand der Foundation.
• Branchen-Funktionen aus dem Customer-Stack. Was in Ihrer Branche typisch ist (Schadenklassifikation, Service-Disposition, Vertragsfristen-Prüfung, Tarifrechner mit Hinweis), wird in Ihrem Customer-Stack einmal sauber gebaut, mit festen Regeln plus KI-Vorschlag plus Freigabe.
• Eigene Funktionen aus dem Selbst-Bau-Werkzeug. Was in Ihrem Haus einmalig ist, legen Ihre Power-User selbst an. Das ist nicht ein netter Bonus, das ist der eigentliche Hebel des Operating Models.

Wer alle drei Quellen sauber trennt, kommt ohne den klassischen „Wir müssen alles selbst entwickeln“-Aufwand aus. Quelle: sensified Master-PRS §1.6, Foundation-Layer und Customer-Factory-Pattern.

Selbst-Bau-Werkzeug: wie Power-User in unter einer Stunde liefern

Das Selbst-Bau-Werkzeug ist der Bestandteil, an dem Mittelstands-Vorstände am ehesten skeptisch werden: „Soll eine Mitarbeiterin aus der Buchhaltung wirklich KI-Funktionen anlegen, die produktiv in unseren Prozessen landen?“ Die Antwort lautet ja, aber mit Leitplanken.

Wie eine Power-User-Funktion in der Praxis entsteht, in fünf Schritten:

1. Eingabe-Maske festlegen. Welche Felder braucht die Funktion (Kundenname, Vertragsnummer, Datum, Anliegen)? Das geht ohne Code, mit einem Konfigurations-Formular.
2. KI-Assistent als Helfer einbinden. Wo soll die KI vorschlagen oder zusammenfassen? Welche Geschäftsregel bleibt fest und unverhandelbar? Die Trennung ist ausdrücklich, nicht implizit.
3. Test-Lauf gegen zehn Beispiele aus dem echten Datenbestand. Stimmen Format, Tonalität, Vollständigkeit?
4. Freigabe-Schritt setzen. Wer darf das produktive Ergebnis freigeben? Eine Person, zwei im Vier-Augen-Prinzip oder eine ganze Rolle? Diese Entscheidung gehört in die Funktion, nicht in das Bauchgefühl.
5. Funktion freigeben und in den Funktions-Baukasten heben. Ab diesem Moment läuft sie für alle berechtigten Mitarbeiter und wird in der KI-Schaltzentrale mitgeführt.

Wir empfehlen, in den ersten 90 Tagen mit zwei bis drei Power-Usern aus unterschiedlichen Fachbereichen zu starten und jede neue Funktion in einer kurzen wöchentlichen Runde zu sichten. So bauen Sie keine Insel, sondern eine Funktions-Bibliothek mit klarer Linie.

Warum die 30-Funktionen-Grenze pro Mandant kein Limit, sondern ein Schutz ist

Pro Mandant erlauben wir bei sensified 30 eigene Funktionen, nicht weil mehr technisch nicht ginge, sondern weil mehr in der Realität zur Schatten-Werkzeug-Sammlung wird. Wer mehr braucht, hat meist mehrere fast identische Funktionen statt einer sauberen. 30 reicht für die typische Mittelstand-Fach-Tiefe.

KI-Schaltzentrale: die Koordinations-Ebene über allen KI-Schritten

Die KI-Schaltzentrale ist die Stelle, die Sie 2026 brauchen, sobald mehr als drei Funktionen produktiv laufen. Sie macht aus einer wachsenden Funktions-Sammlung ein steuerbares Operating Model.

Was sie konkret leistet:

• Sichtbarkeit über alle aktiven Funktionen, alle Aufrufe, alle Fehler. Wer hat heute welche Funktion wie oft genutzt, mit welchem Ergebnis?
• Verkettung mehrerer Funktionen zu einem längeren Arbeitsablauf. Wenn ein Vorgang aus drei Schritten besteht (Eingabe prüfen, Vorschlag erstellen, Freigabe einholen), läuft das nicht als ein einziger Prompt, sondern als koordinierte Kette.
• Sicherer Anschluss an Geschäfts-Systeme. Wenn eine Funktion etwas aus Ihrem CRM holt oder etwas ins ERP schreibt, läuft das nicht direkt aus der KI heraus, sondern über fest definierte Schnittstellen mit Berechtigungs-Prüfung.
• Lückenloses Protokoll. Jeder Aufruf, jeder Vorschlag, jede Freigabe wird mitgeführt, manipulationssicher und auditpflichtig nachvollziehbar.

Freigabe-Schritte und Audit-Trail: woran ein Operating Model rechtssicher wird

Ein Operating Model ohne saubere Freigabe-Schritte ist ein Risiko-Modell. In Gesprächen mit Versicherungs-Vorständen und Stadtwerk-CFOs kommt die Frage zuverlässig: „Wenn ich KI in unsere Prozesse lasse, wie erklären wir das der Aufsicht?“ Drei Antworten, die in der Praxis tragen:

• Jede Funktion hat einen Freigabe-Schritt, ohne Ausnahme. Auch eine harmlose Mail-Funktion bekommt einen Freigabe-Pfad, weil die Disziplin in der Belegschaft an einzelnen Ausnahmen kippt.
• Freigabe-Rollen sind klar geregelt. Wer darf was freigeben? Ein Sachbearbeiter im Standardfall, ein Teamleiter bei Werten über einer Grenze, ein Vier-Augen-Prinzip bei regulatorisch sensiblen Schritten.
• Audit-Trail in drei parallelen Linien. Bei sensified führen wir das Protokoll in mehreren Linien parallel, damit eine einzelne Manipulation ausgeschlossen ist. Wenn die Wirtschaftsprüfung nach einer Entscheidung von letztem Donnerstag um 14:32 fragt, kommt die Auskunft aus dem Protokoll, nicht aus dem Gedächtnis.

Praktischer Anker: Wenn Ihr Wirtschaftsprüfer 2027 nach Nachweisen fragt, sind die Antworten im Audit-Trail. Wer dieses Modell nicht hat, antwortet mit Folien. Aufsichten akzeptieren keine Folien.

Neue Rollen, die das Operating Model in den ersten 90 Tagen einführt

Ein AI-Native Operating Model braucht keine neue Abteilung, aber drei klar benannte Rollen, oft als Teilzeit-Aufgabe an bestehende Mitarbeiter vergeben.

• Power-User pro Fachbereich. Person aus Buchhaltung, Vertrieb, HR oder Service, die das Selbst-Bau-Werkzeug nutzt und neue Funktionen anlegt. Wichtig: nicht aus der IT, sondern aus dem Fachbereich. Wer den Prozess kennt, baut die bessere Funktion.
• KI-Beauftragter im Haus. Eine Person mit Übersicht über alle Funktionen, alle Freigabe-Regeln, alle laufenden Audit-Vorgaben. Oft eine Teilzeit-Rolle in der Stabsstelle Compliance oder Organisation. Schnittstelle zwischen Fachbereich, IT und Aufsicht.
• Funktions-Owner. Pro produktiver Funktion eine fachliche Verantwortung. Wer ist Ansprechpartner, wenn die Funktion sich verhält, wie sie nicht soll? Diese Rolle verhindert, dass Power-User-Funktionen zu Waisen werden, wenn der Power-User in Urlaub geht.

Diese drei Rollen ersetzen kein klassisches IT-Team. Sie ergänzen es. Die IT bleibt verantwortlich für Hosting, Sicherheit, Anmelde-Logik und Anschluss-Stücke. Das Operating Model entlastet sie davon, jede neue Funktions-Idee selbst zu programmieren.

Drei Stolpersteine, an denen Operating Models in den ersten 90 Tagen kippen

Aus 25 Customer-Stacks und ungezählten Operating-Model-Workshops kennen wir die wiederkehrenden Stolpersteine:

1. Falsche Power-User-Auswahl. Wer einen IT-affinen Mitarbeiter aus der IT als Power-User einsetzt, baut technisch saubere Funktionen, die im Fachbereich nicht angenommen werden. Wer eine Fachkraft mit Prozess-Tiefe aus dem Fachbereich nimmt, baut Funktionen, die ankommen, auch wenn sie technisch weniger elegant sind.
2. Fehlende Freigabe-Disziplin. Wenn Mitarbeiter merken, dass Freigabe-Schritte in der Praxis übersprungen werden, kippt das Modell innerhalb von Wochen. Klare Regel: kein Freigabe-Schritt, keine produktive Funktion. Auch nicht „erstmal“.
3. Schatten-Funktionen außerhalb der Plattform. Wer das Selbst-Bau-Werkzeug zu eng führt, treibt Power-User in frei verfügbare Chat-Werkzeuge zurück. Lieber die Bandbreite klar regeln und im Haus halten, als die Realität verbieten und sie unter dem Tisch wachsen lassen.

Wo Sie aktuell zwischen diesen Mustern stehen, klären Sie am ehrlichsten über den AI-Native Reifegrad im Mittelstand: 12 Felder, 5 Stufen, ein ehrliches Bild.. 30 Minuten, zwölf Felder, eine Selbst-Auswertung über fünf Stufen.

Nächste Schritte: in drei Wochen zum tragfähigen Operating Model

Ein Operating Model wird nicht im Workshop entworfen und dann im Haus eingeführt. Es wird an einer ersten produktiven Funktion gelernt. Wir empfehlen genau drei Schritte:

1. 30-Minuten-Strategiegespräch. Sie schildern uns Ihre Fach-Landschaft und Ihre Compliance-Lage. Wir empfehlen Ihnen eine erste Funktion und ein erstes Rollen-Bild, ohne Verkaufs-Druck. Termin buchen.
2. Erste Power-User-Funktion in der Sandbox. In zwei Wochen läuft eine Funktion aus Ihrem Fachbereich in Ihrer eigenen Sandbox, mit Freigabe-Schritt und Audit-Trail. Sie sehen das Operating Model live am eigenen Datenbestand, nicht im Folien-Deck.
3. Operating-Model-Sprint. Innerhalb der ersten 30 Tage benennen wir gemeinsam Power-User, KI-Beauftragten und Funktions-Owner. Wir richten die KI-Schaltzentrale auf Ihre Prozess-Landschaft aus. Danach wachsen Funktionen aus dem Haus selbst, nicht aus dem Beratungs-Ticket.

Wenn Sie 2026 keinen Mehrjahres-Vertrag unterschreiben wollen, bevor irgendetwas läuft, beginnen Sie mit Schritt eins. In 30 Minuten wissen Sie, ob das Modell zu Ihrem Haus passt. Mehr Hintergrund zu Partner-Modellen finden Sie im Berater oder Plattform-Partner? Was Geschäftsführer beim AI-Native-Sparring brauchen..

Strategiegespräch buchen und in der nächsten Woche das erste Stück Operating Model in Ihrer eigenen Sandbox sehen.