Unternehmens-KI: Ebenen, Reifegrade und der Weg zur Einführung

Aus welchen Ebenen besteht Unternehmens-KI?

Ein wiederkehrendes Muster bei stecken gebliebenen KI-Vorhaben ist eine Verwechslung von Ebenen: Es wird ein Werkzeug eingeführt und eine Prozessveränderung erwartet. Hilfreicher ist ein Schichtenmodell. Jede Ebene hat eigene Leitfragen, eigene Verantwortliche und eigene Fehlermodi — und Probleme einer Ebene lassen sich auf einer anderen nicht lösen.

Die oberste Ebene ist die Anwendung: Menschen arbeiten direkt mit einem Modell, über eine Chat-Oberfläche, über Assistenzfunktionen in Office-, CRM- oder Ticketsystemen oder über Code-Assistenten. Der Nutzen entsteht sofort, bleibt aber an einzelne Personen gebunden. Darunter liegt die Ebene Wissen und Daten: Das Modell bekommt Zugriff auf unternehmenseigene Inhalte — Handbücher, Verträge, Tickets, Produktdaten. Hier entscheidet sich, ob Antworten belegbar werden oder plausibel klingende Vermutungen bleiben. Wie diese Schicht aufgebaut wird, behandelt der Bereich Wissensmanagement mit KI.

Auf der dritten Ebene führen Systeme Schritte selbst aus, statt nur zu antworten: Vorgänge klassifizieren, Daten in Fachsysteme schreiben, mehrstufige Abläufe abarbeiten. Das ist das Feld der KI-Agenten — und die erste Ebene, auf der ein Fehler nicht nur ein schlechter Textvorschlag ist, sondern ein falscher Datensatz. Darunter liegt die KI-Infrastruktur: Modellzugänge, Gateways, Vektorspeicher, Schlüsselverwaltung, Protokollierung, gegebenenfalls eigene Hardware. Und quer über allem liegt KI-Governance — Richtlinien, Rechtsgrundlagen, Freigabewege, Risikoeinstufung, Nachweise.

Die oberen drei Ebenen erzeugen den sichtbaren Nutzen, die unteren beiden entscheiden, ob er dauerhaft ist. Beobachtbar ist, dass Organisationen von oben nach unten wachsen und Infrastruktur und Governance eine Stufe zu spät nachziehen. Das ist nicht grundsätzlich falsch, solange die entstandene Schuld bewusst ist und abgetragen wird, bevor Systeme anfangen, selbstständig zu schreiben.

• Anwendung — Menschen arbeiten mit dem Modell. Leitfrage: Wer darf was womit tun?
• Wissen und Daten — das Modell greift auf eigene Inhalte zu. Leitfrage: Welche Quelle gilt, und wer pflegt sie?
• Automatisierung und Agenten — Systeme handeln selbst. Leitfrage: Was passiert bei einem Fehler, und wer merkt es?
• Infrastruktur — Modelle, Schnittstellen, Speicher, Protokolle. Leitfrage: Wo laufen die Daten durch, und wer betreibt das?
• Governance — Regeln, Recht, Rollen, Nachweise. Leitfrage: Wer verantwortet das Ergebnis nach außen?

Welche Reifegrade gibt es — und wo steht man selbst?

Reifegrade sind keine Auszeichnung, sondern ein Diagnosewerkzeug. Sie beschreiben, was in einer Organisation tatsächlich vorhanden ist — nicht, was geplant oder in einer Präsentation angekündigt ist. Häufig befinden sich Unternehmen gleichzeitig auf mehreren Stufen: die Rechtsabteilung auf Stufe 1, das Marketing auf Stufe 3, ein einzelnes Fachteam bereits auf Stufe 4.

Viele Organisationen starten auf Stufe 1, ob geplant oder nicht. Mitarbeiter nutzen KI bereits, häufig über private Zugänge, weil der Nutzen offensichtlich und die Hürde niedrig ist. Diese Ausgangslage lässt sich nicht durch ein Verbot beenden, sondern nur durch ein besseres Angebot. Der erste sinnvolle Schritt ist deshalb selten ein Werkzeugkauf, sondern eine ehrliche Bestandsaufnahme: Wer nutzt was, wofür, mit welchen Daten.

Stufen lassen sich abkürzen, aber nicht überspringen. Wer Automatisierung anstrebt, ohne die Wissens- und Datenebene sauber zu haben, automatisiert auf ungeprüfter Grundlage — das Ergebnis ist ein System, das schnell falsche Daten produziert. Und Stufe 5 ist kein Pflichtziel: Sie lohnt sich erst, wenn die Zahl der Anwendungsfälle so groß wird, dass jedes neue Vorhaben sonst wieder ein eigenes Projekt-Setup braucht.

Welche Prozesse eignen sich für KI — und welche nicht?

Die Eignungsfrage lässt sich auf drei Kriterien reduzieren. Erstens: Ist der Soll-Zustand definiert — kann jemand im Unternehmen sagen, wann ein Ergebnis richtig ist? Zweitens: Ist ein Fehler erkennbar und bezahlbar? Drittens: Gibt es genug Vorgänge, damit Aufbau, Betrieb und Kontrolle sich lohnen? Fällt eines dieser Kriterien aus, hilft auch das beste Modell nicht weiter.

Sprachmodelle sind Wahrscheinlichkeitssysteme. Sie eignen sich dort, wo Varianz akzeptabel ist und Prüfung billig — und sie eignen sich schlecht dort, wo Exaktheit gefordert ist. Ein Modell, das eine Rechnung zusammenfasst und die Positionen strukturiert extrahiert, ist nützlich. Ein Modell, das den Rechnungsendbetrag selbst ausrechnet, ist ein Konstruktionsfehler: Die Rechnung gehört in eine deterministische Komponente, die immer dasselbe Ergebnis liefert — das Modell darf sie aufrufen und das Ergebnis einordnen.

Eine praktische Vorabprüfung, die sich vor jedem Vorhaben lohnt: genug echte Vorgänge aus der Vergangenheit als Testmenge beiseitelegen, um die typische Varianz des Prozesses abzudecken, samt der Ergebnisse, die damals als korrekt galten. Lässt sich diese Menge nicht zusammenstellen, ist der Prozess noch nicht reif für KI — nicht aus technischen Gründen, sondern weil niemand definieren kann, was richtig ist. Diese Testmenge ist später die einzige belastbare Grundlage, um Modelle, Prompts und Anbieter zu vergleichen.

Build oder Buy: selbst bauen oder Standardlösung kaufen?

Die Frage lautet selten Build oder Buy, sondern: Auf welcher Ebene kaufen wir, und wo bauen wir? Die Modelle selbst werden in aller Regel eingekauft — eigene Modelle von Grund auf zu trainieren ist außerhalb sehr spezieller Fälle nicht sinnvoll. Häufig gekauft wird auch die Anwendungsschicht für allgemeine Aufgaben. Gebaut wird dort, wo der eigene Prozess das Unterscheidungsmerkmal ist und kein Standardprodukt ihn abbildet.

Ein brauchbarer Filter: Was Wettbewerber genauso machen, kauft man. Was das eigene Geschäft ausmacht, baut man — oder man baut es zumindest so, dass man die darunterliegenden Bausteine wechseln kann. Wie eine unternehmenseigene Modellschicht aussieht, welche Betriebsformen es gibt und wann sich der Aufwand lohnt, behandelt die Seite zum Corporate LLM.

Modelle, Anbieter und Preise ändern sich derzeit in kurzen Abständen, Unternehmensprozesse deutlich seltener. Teuer wird deshalb weniger die falsche Entscheidung als eine Entscheidung ohne Ausstiegspfad. Wer seine Prompts, Auswertungsmengen und Datenzugriffe so organisiert, dass ein Modellwechsel eine Konfigurationsänderung ist und kein Projekt, hält sich die Option offen, ohne heute mehr investieren zu müssen.

Welche rechtlichen Rahmenbedingungen gelten?

Sobald personenbezogene Daten verarbeitet werden, gilt die DSGVO — unabhängig davon, ob die Verarbeitung durch ein Sprachmodell oder eine klassische Anwendung erfolgt. Zu klären sind dieselben Punkte wie beim Einsatz jedes externen Dienstleisters: eine tragfähige Rechtsgrundlage, ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO, soweit der Anbieter als Auftragsverarbeiter tätig wird — bei manchen Diensten verarbeitet der Anbieter Teile der Daten, etwa zur Missbrauchserkennung oder Produktverbesserung, als eigener Verantwortlicher, was gesondert zu bewerten ist —, dazu Zweckbindung, Umgang mit Drittlandtransfers, Löschfristen, Betroffenenrechte und technisch-organisatorische Maßnahmen. Bei Verarbeitungen mit voraussichtlich hohem Risiko kommt eine Datenschutz-Folgenabschätzung hinzu.

Ein oft unterschätzter Punkt ist die Weiterverwendung der Eingaben. Geschäftskunden-Angebote schließen ein Training auf Kundeninhalten häufig vertraglich aus, kostenlose Verbraucherversionen oft nicht oder nur per Opt-out. Genau das macht private Accounts im Unternehmenskontext zum Problem — nicht die Technik, sondern der Vertrag, der dahinter fehlt. In vielen kostenlosen Angeboten fehlen Auftragsverarbeitungsvertrag, Kontrolle über die Weiterverwendung der Eingaben und Nachvollziehbarkeit; "Wir nutzen nur die kostenlose Version" ist deshalb keine Risikominderung. Maßgeblich ist immer das konkrete Vertragswerk des Anbieters, nicht die Marketingaussage. Die operativen Details behandelt der Artikel DSGVO und KI — was du wissen musst.

Der EU AI Act kommt als zweite Ebene hinzu und arbeitet risikobasiert: Einige Praktiken sind verboten, bestimmte Anwendungen gelten als Hochrisiko und lösen umfangreiche Pflichten aus, für andere Systeme gelten Transparenzpflichten, und für Allzweck-KI-Modelle bestehen eigene Anforderungen an die Anbieter. Für Unternehmen als Betreiber ist vor allem relevant: Interne Anwendungsfälle wie Textentwürfe oder interne Suche fallen in der Regel nicht in die Hochrisiko-Kategorie. Systeme für Personalauswahl und -bewertung — also Auswahl, Beförderung, Aufgabenzuweisung sowie Überwachung und Bewertung von Beschäftigten — sowie die Bewertung der Kreditwürdigkeit natürlicher Personen sind dagegen im Hochrisiko-Anhang (Anhang III) aufgeführt; die Erkennung von Finanzbetrug ist davon ausgenommen, und die Bonitätsprüfung von Firmenkunden ist damit nicht gemeint. Ob ein konkretes System tatsächlich als Hochrisiko gilt, ist im Einzelfall zu prüfen — Art. 6 Abs. 3 AI Act sieht dafür eine Ausnahmeprüfung vor.

Unabhängig von der Risikoklasse greift die KI-Kompetenz-Pflicht nach Art. 4 AI Act: Anbieter und Betreiber müssen dafür sorgen, dass ihr Personal und die Personen, die die Systeme in ihrem Auftrag bedienen, über ausreichende KI-Kompetenz verfügen. Das betrifft also auch einfache interne Anwendungen, nicht nur Hochrisiko-Systeme.

In Deutschland kommt die Mitbestimmung dazu. Wo ein Betriebsrat besteht, unterliegen Systeme, die objektiv geeignet sind, Verhalten oder Leistung von Beschäftigten zu überwachen, nach § 87 Abs. 1 Nr. 6 BetrVG seiner Mitbestimmung — auf eine Überwachungsabsicht kommt es dabei nicht an. Und Protokollierung, die man aus Governance-Gründen einführt, kann genau diese Eignung erzeugen. Den Betriebsrat früh einzubinden ist deshalb kein Höflichkeitsakt, sondern verkürzt die Einführung.

In welcher Reihenfolge führt man KI im Unternehmen ein?

Die Reihenfolge ist wichtiger als das Tempo. Wer mit der Plattform beginnt, baut Infrastruktur für Anwendungsfälle, die es noch nicht gibt. Wer mit dem Pilotprojekt beginnt, ohne den Rahmen gesetzt zu haben, produziert ein Ergebnis, das aus Compliance-Gründen nicht in Betrieb gehen darf. Die folgende Abfolge berücksichtigt die typischen Abhängigkeiten zwischen den Schritten — sie ist ein Vorschlag, kein Standard.

Der wichtigste und am häufigsten ausgelassene Schritt ist der Ausgangswert. Bevor irgendetwas umgestellt wird, sollten Durchlaufzeit, Fallzahl, Nacharbeitsquote und Aufwand pro Vorgang für den betroffenen Prozess bekannt sein. Ohne diese Zahlen gibt es später keine Diskussion über Nutzen, sondern nur über Eindrücke — und Eindrücke verlieren gegen Budgets.

Genauso wichtig: Datenordnung kommt vor Datenanbindung. Wenn drei Versionen einer Preisliste im Umlauf sind, wird ein Retrieval-System zuverlässig alle drei finden und die Verwirrung beschleunigen. Welche Quelle gilt, wer sie pflegt und wie veraltete Inhalte aus dem Index verschwinden, klärt man vorher — die technischen Grundlagen dazu stehen im Bereich RAG. Für den Schritt "Rahmen setzen" gibt es eine ausformulierte KI-Richtlinie zum Anpassen.

• Bestandsaufnahme: Wer nutzt heute welche KI-Werkzeuge, mit welchen Daten, in welchem Prozess?
• Rahmen setzen: Nutzungsrichtlinie, freigegebene Werkzeuge, Verträge, Rechtsgrundlagen, Ansprechpartner.
• Anwendungsfälle sammeln und nach den drei Eignungskriterien filtern — nicht nach Begeisterung.
• Ausgangswert messen: Durchlaufzeit, Volumen, Fehler- und Nacharbeitsquote des gewählten Prozesses.
• Testmenge bauen: echte Altfälle mit dem Ergebnis, das damals als richtig galt.
• Pilot mit menschlicher Freigabe: begrenzter Umfang, definierter Eskalationsweg, vollständige Protokollierung.
• Auswerten und entscheiden: gegen die Testmenge und den Ausgangswert, nicht gegen das Bauchgefühl.
• Rollout mit Schulung und Betriebsverantwortung — erst danach über Plattform und Konsolidierung nachdenken.

Wer ist im Unternehmen wofür verantwortlich?

Ein wiederkehrendes Muster bei KI-Vorhaben: Nicht die Technik fehlt, sondern die Zuständigkeit. Typisch ist die Konstellation, in der die IT ein System betreibt, dessen fachliche Qualität niemand verantwortet — und in dem Moment, in dem ein Ergebnis falsch ist, hat der Prozess keinen Eigentümer. Deshalb gilt: Die fachliche Verantwortung für ein KI-gestütztes Ergebnis bleibt beim Prozessverantwortlichen im Fachbereich. Die IT verantwortet Betrieb, Zugänge und Sicherheit, nicht die Richtigkeit des Outputs.

In kleineren Organisationen sind das keine Stellen, sondern Rollen — eine Person kann mehrere tragen. Entscheidend ist nicht die Anzahl der Beteiligten, sondern dass jede Rolle einen Namen hat. Eine unbesetzte Rolle fällt im Betrieb immer auf denjenigen zurück, der zufällig da ist.

Dazu kommt der Kompetenzaufbau — der nach Art. 4 AI Act ohnehin eine Pflicht ist: Wer Ergebnisse prüfen soll, muss wissen, wie diese Systeme typischerweise falsch liegen, und wer sie freigibt, muss die rechtliche Einordnung kennen. Welche Gruppe welches Wissen braucht, ist im Bereich KI-Kompetenz nach Rollen aufgeschlüsselt.

• Geschäftsführung: Zielsetzung, Budget, Risikoakzeptanz, Freigabe der Richtlinie — nicht delegierbar.
• KI-Verantwortliche oder Koordination: Anwendungsfall-Portfolio, Priorisierung, Standards, Ansprechpartner für Fachbereiche.
• Fachbereich beziehungsweise Prozessverantwortliche: fachlicher Soll-Zustand, Testmenge, Abnahme, Qualität im laufenden Betrieb.
• IT und Plattform: Zugänge, Identitäten und Rechte, Integration, Protokollierung, Verfügbarkeit, Kosten.
• Datenschutz und Informationssicherheit: Rechtsgrundlage, Auftragsverarbeitung, Folgenabschätzung, Schutzmaßnahmen, Löschkonzepte.
• Betriebsrat: Mitbestimmung bei Systemen mit objektiver Überwachungseignung, Beteiligung ab der Konzeptphase — sofern ein Betriebsrat besteht.
• Recht und Compliance: Risikoeinstufung nach EU AI Act, Vertragsgestaltung, Dokumentations- und Nachweispflichten.

Wie belegt man den Nutzen von Unternehmens-KI?

Nutzen entsteht auf drei Wegen: Ein Vorgang dauert kürzer, ein Vorgang wird seltener nachgearbeitet, oder es wird etwas möglich, das vorher unwirtschaftlich war — etwa jede eingehende Anfrage vollständig zu lesen statt stichprobenartig. Der dritte Weg wird in Wirtschaftlichkeitsrechnungen oft übersehen, der erste dagegen leicht zu optimistisch angesetzt.

Auf der Kostenseite stehen vier Posten: der Modellzugang selbst (bei Standardprodukten meist als Lizenz pro Nutzer, bei eigenen Anwendungen nutzungsbasiert), die einmalige Integration, der laufende Betrieb — und der Kontrollaufwand. Dieser Posten fehlt in Kalkulationen häufig, obwohl er der einzige ist, der mit der Fallzahl mitwächst. Ein System, dessen Ausgaben vollständig geprüft werden müssen, spart nur dann Zeit, wenn Prüfen deutlich schneller geht als Erstellen.

Die ehrlichste Kennzahl ist ein Vorher-Nachher-Vergleich auf demselben Prozess mit denselben Fällen. Eine hochgerechnete Zeitersparnis pro Mitarbeiter ist dagegen keine Einsparung, solange nicht benannt ist, wofür die frei werdende Zeit verwendet wird. Plausibler als eine Zeitersparnis pro Kopf ist ohnehin ein Effekt an anderer Stelle: bessere Vorarbeit und weniger Wartezeit zwischen Prozessschritten — nicht höhere Tippgeschwindigkeit. Wie sich die Kostenseite eines konkreten Aufbaus aufschlüsselt, ist in der Kostenaufstellung einer Multi-Agent-Pipeline dokumentiert.

Lohnt sich der Aufbau von Unternehmens-KI für einen konkreten Prozess — und wenn ja, auf welcher Ebene?

Häufige Fehler

1. Werkzeug vor Anwendungsfall Eine Plattform wird lizenziert, danach wird gesucht, wofür man sie einsetzen könnte. Die Reihenfolge dreht die Verantwortung um: Statt eines Fachbereichs mit einem Problem gibt es ein Projekt mit Rechtfertigungsdruck. Erst der Prozess, dann das Werkzeug.
2. Kein Ausgangswert vor dem Start Ohne gemessene Durchlaufzeit, Fallzahl und Nacharbeitsquote gibt es später keine Bewertung, sondern nur konkurrierende Eindrücke. Diese Zahlen lassen sich nachträglich nicht mehr erheben — die Messung gehört vor die erste Umstellung.
3. Pilot ohne Betriebsplan Der Pilot funktioniert, danach ist unklar, wer das System betreibt, wer Fehler entgegennimmt und wer die Kosten trägt. Ergebnisse, die niemand übernimmt, verschwinden. Betriebsverantwortung und Budget gehören in die Pilotplanung, nicht dahinter.
4. Datenchaos an das Modell delegieren Widersprüchliche Dokumentversionen, unklare Zuständigkeiten und veraltete Ablagen werden nicht durch Retrieval geheilt, sondern schneller sichtbar und breiter verteilt. Welche Quelle gilt und wer sie pflegt, klärt man vor der Anbindung.
5. Governance als Projektabschluss Rechtsgrundlage, Auftragsverarbeitung, Risikoeinstufung und Mitbestimmung erst nach dem fertigen Prototyp zu klären, führt dazu, dass ein funktionierendes System am Ende nicht in Betrieb gehen darf. Diese Fragen sind Eingangsbedingungen, keine Abnahmekriterien.
6. Schreibrechte zu früh Ein System, das direkt in Fachsysteme schreibt, bevor seine Trefferquote gegen eine Testmenge belegt ist, produziert Fehler schneller, als sie auffallen. Erst Vorschlagen mit Freigabe, dann Ausführen mit Stichprobe, dann größere Autonomie — in dieser Reihenfolge.

Weiterlesen

Verwandte Themen

• KI-Governance: der Rahmen, der KI-Nutzung nicht ausbremst
• KI-Infrastruktur: die technische Basis für KI im Unternehmen
• Corporate LLM: Was es ist, welche Bauformen es gibt und wann sich welche lohnt