Was macht ein KI-System für Ihr Unternehmen spezifisch?
Von Evren BalVeröffentlicht · 6 Min. Lesezeit

Seite kopieren
💡 Kurz gesagt:
- KI für das eigene Unternehmen spezifisch zu machen heißt nicht, dem Modell alles über das Unternehmen beizubringen. Aktuelle Informationen müssen aus maßgeblichen Systemen kommen, explizite Regeln in Software bleiben und Berechtigungen über Identitäts- und Zugriffskontrollen gelten.
- Das System um das Modell herum kann dasselbe Modell zu einer völlig anderen Geschäftsfähigkeit machen. Daten, Werkzeuge, Arbeitsablauf, Freigaben und Messung schaffen einen großen Teil dieses Unterschieds.
- Manche Aufgaben rechtfertigen ein spezialisiertes Modell. Entscheidend sind ein zu lernendes Muster und eine gemessene Leistungslücke, nicht der vage Wunsch, die KI „zu unserer“ zu machen.
Stellen Sie sich ein Einkaufsteam vor, das Angebote dreier Lieferanten vergleicht. Es lädt die Dateien in ein Sprachmodell und bittet um Vergleich von Preisen, Lieferterminen und Gewährleistung. Das Modell liefert eine klare Tabelle und empfiehlt einen Lieferanten.
Das kann nützliche Dokumentenanalyse sein. Es zeigt nicht, dass das System die richtige Einkaufsentscheidung für dieses Unternehmen getroffen hat. Ist der Lieferant zugelassen? Ist der Artikel schon auf Lager? Bietet ein bestehender Vertrag einen besseren Preis? Darf die anfragende Person diese Summe ausgeben? Welche Freigaben müssen vor einer Bestellung erfolgen?
Die Angebote beantworten das nicht. Ein Teil steht in aktuellen Unternehmensdaten, ein Teil in Geschäftsregeln und anderes im Autorisierungssystem. Das Modell kann Angebote verstehen. Die Geschäftsfähigkeit entsteht erst, wenn das übrige System damit arbeitet.
Unternehmenswissen ist nicht dasselbe wie ein unternehmensspezifisches System
Mit „unternehmensspezifischer KI“ ist oft ein auf Unternehmensdaten trainiertes Modell gemeint. Das kann für manche Aufgaben nützen, aber nicht jede spezifische Anforderung gehört in das Modell.
Produktkataloge, Verfahren und Verträge können direkt bereitgestellt oder bei Bedarf abgerufen werden. Lagerbestand, Bestellstatus und Salden sollten aus der zuständigen API oder Datenbank gelesen werden. Ausgabenlimits und Freigabefolgen gehören in Software. Das Zugriffskontrollsystem entscheidet, welche Datensätze ein Nutzer sehen darf.
Im Artikel über Fine-Tuning habe ich Information, explizite Regeln und aus Beispielen zu lernende Muster getrennt. Auf Systemebene folgt daraus: Nicht alle für Ihr Unternehmen spezifischen Anforderungen leben in Modellgewichten.
| Spezifische Anforderung | Richtiger Ort | Einfaches Beispiel |
|---|---|---|
| Sich ändernde schriftliche Information | Dokumente, Suche oder RAG | aktuelle Einkaufsrichtlinie |
| Aktueller operativer Zustand | autorisierte API oder Datenbank | Lagerbestand und offene Bestellungen |
| Explizite Geschäftsregel | Software oder definierter Arbeitsablauf | Freigabe durch Führungskraft über einer Ausgabengrenze |
| In historischen Daten verborgenes Muster | Prognose-, Klassifikations- oder anderes Modell | Nachfrageprognose für nächsten Monat |
| Reale Transaktion | eng begrenztes Werkzeug oder API | Kaufanforderung erstellen |
| Berechtigung zum Sehen oder Handeln | Identität, Rolle und Zugriffskontrolle | Verträge nur für die eigene Geschäftseinheit zeigen |
| Ausnahmeentscheidung | befugter Mitarbeitender oder klare Übergaberegel | widersprüchliche Angebote an Einkaufsexperten eskalieren |
| Erfolgsnachweis | Ergebnis im führenden System und Geschäftskennzahl | freigegebene Bestellung, Lieferzeit oder Einsparung |
Ein Modell kann mehrere Komponenten nutzen, wird aber nicht ihr Eigentümer. Einen Lagerdatensatz zu lesen macht es nicht zur Quelle der Wahrheit für Inventar. Ein Ausgabenlimit zu erklären, gibt ihm nicht die Befugnis, eine Bestellung aufzugeben.
Dasselbe Modell kann zwei sehr unterschiedliche Systeme unterstützen
Berkeley AI Research nennt Systeme, die Modellaufrufe mit Retrieval, Software-Werkzeugen und weiteren Komponenten verbinden, Compound AI Systems. Der Name ist weniger wichtig als die Unterscheidung: Das Ergebnis entsteht aus dem Zusammenspiel der Komponenten, nicht aus dem Modell allein.
Auch Microsofts aktuelle Hinweise zum Entwurf von KI-Anwendungen trennen Modellinferenz, Wissensquellen, Orchestrierung, Werkzeuge und Client-Schicht. Sie empfehlen zudem, Nutzerrechte in der Wissensschicht durchzusetzen und Werkzeuge mit eigenen Sicherheitskontrollen zu versehen.
Dasselbe Modell kann in einem Unternehmen Angebote zusammenfassen. In einem anderen kann es Teil eines größeren Systems sein, das aktuellen Bestand liest, Vertragsbedingungen vergleicht und eine Kaufanforderung vorbereitet. Der Unterschied liegt nicht nur in der Anweisung, sondern darin, welche Quelle maßgeblich ist, welche Aktion unter welcher Identität laufen darf, welche Ausnahme an einen Menschen geht und wo das Ergebnis geprüft wird.
Machen stärkere General-Purpose-Modelle diese Architektur überflüssig?
Das ist ein ernsthafter Einwand. Wenn General-Purpose-Modelle jährlich mehr Arbeit leisten können, brauchen Unternehmen dann noch so viele getrennte Komponenten?
Es wird möglich, Text, Bild und Audio mit einem Modell zu verarbeiten, lange Dokumente direkt bereitzustellen und Software-Werkzeuge durch das Modell aufrufen zu lassen. Pipelines, die früher mehrere Spezialmodelle brauchten, können tatsächlich einfacher werden. Google DeepMind beschrieb im Gemini-2.5-Technical-Report von 2025 eine Modellfamilie mit Text-, Bild- und Audioeingaben, langem Kontext, Reasoning und Werkzeugnutzung.
Modellfähigkeit und Systemverantwortung bleiben aber verschieden. Selbst ein Modell, das einen Produktkatalog mit Millionen Zeilen lesen kann, weiß nicht unabhängig, welcher Preis heute gilt, ob ein Nutzer einen bestimmten Vertrag sehen darf oder ob die Bestellung wirklich erstellt wurde. Das sind Fragen des aktuellen Zustands, der Befugnis und der abgeschlossenen Handlung.
Mit besseren Generalmodellen verschwinden einige Spezialkomponenten. Quellen, Regeln und Verantwortlichkeiten eines Unternehmens werden dadurch nicht zu Modellfähigkeiten.
Manche Muster müssen tatsächlich gelernt werden
Umgekehrt löst das Einbinden einiger Dokumente oder einer API nicht jedes Problem. Ein Unternehmen kann täglich Tausende Anfragen in eigene stabile Kategorien einordnen müssen. Macht ein Generalmodell bei realen Nachrichten wiederholt dieselben Fehler, kann ein kleineres Modell mit gelabelten Beispielen genauer, schneller oder günstiger sein.
Eine EMNLP-Studie von 2025 zur Textklassifikation fragte, wie viele gelabelte Beispiele ein kleines aufgabenbezogenes Modell braucht, um mit einem großen Generalmodell zu konkurrieren. Über acht Aufgaben hinweg konnten Spezialmodelle die Generalmodelle im Durchschnitt mit etwa hundert gelabelten Beispielen erreichen oder übertreffen; manche Aufgaben brauchten deutlich mehr Daten.
Wenn Ihr Unternehmen ähnliche Anfragen wiederholt festen Kategorien zuordnet und korrekt gelabelte Beispiele besitzt, kann ein allein auf diese Aufgabe trainiertes kleines Modell einen Test verdienen. Hundert Beispiele sind keine allgemeine Schwelle; Aufgabe und Daten ändern die Anforderung. Das praktische Ergebnis lautet: Das größte Generalmodell ist nicht automatisch die beste Wahl für enge, wiederkehrende Arbeit.
Hier hat das Modell eine klar definierte Aufgabe. Wenn die Antwort weder in einem Dokument steht noch aus einer expliziten Regel berechnet werden kann und von einem Muster in historischen Beispielen abhängt, kann Spezialisierung gerechtfertigt sein. Auf der echten Arbeitslast muss sie sich dennoch beweisen.
Die Geschäftsfähigkeit sollte einen Modellwechsel überstehen
Je mehr Unternehmenswissen, Regeln und Berechtigungen in unkontrolliertem Modellverhalten vergraben sind, desto schwerer lässt sich das System verstehen und ändern. Ein neues Modell kann dieselben Anweisungen anders auslegen; womöglich weiß das Team nicht, welche Beispiele oder stillen Annahmen das alte Verhalten ermöglichten.
Quellen, Geschäftsregeln, Werkzeugverträge, Zugriffsgrenzen und Evaluierungsbeispiele getrennt zu halten, macht einen Modellwechsel besser testbar. Ein Ersatzmodell kann mit denselben Quellen, Berechtigungen und repräsentativen Aufgaben bewertet werden. Das macht das Modell weder unwichtig noch mühelos ersetzbar: Die Wahl wirkt direkt auf Qualität, Kosten, Geschwindigkeit und leistbare Arbeit. Sie verhindert aber, dass die gesamte Geschäftsfähigkeit vom Verhalten eines Anbietermodells abhängt.
Zurück zum Einkauf: Das Modell kann Angebote lesen und Unterschiede erklären. Das Unternehmenssystem ruft den richtigen Lagerdatensatz ab, öffnet den Vertrag entsprechend den Nutzerrechten, wendet die Ausgabenregel an, verlangt die passende Freigabe und prüft die Bestellung im führenden System.
Manchmal macht ein feinabgestimmtes oder spezialisiertes Modell ein KI-System unternehmensspezifisch. Häufiger entsteht der Unterschied durch das System, das festlegt, welche Information das Modell nutzen darf, welche Werkzeuge es aufrufen kann, welche Befugnis es hat und welches Geschäftsergebnis es liefern muss.
Auf die Frage „Wie passen wir das Modell unserem Unternehmen an?“ folgen daher zwei weitere: Was muss das Modell wirklich lernen? Was muss das System liefern, begrenzen und prüfen?
Der vorherige Artikel erklärt, wann Anfragen über mehrere KI-Modelle geroutet werden sollten.
Weitere Entscheidungen zu Modellen, Information, Befugnissen und Evaluierung finden Sie im Leitfaden zum Entwurf eines KI-Systems für Ihr Unternehmen.
Wenn dieser Artikel hilfreich war
Ein Link von einer passenden Seite Ihrer Website oder das Teilen in sozialen Medien hilft diesem Artikel, mehr Menschen zu erreichen. Vielen Dank.
Hinweise zu Links und Marke →Über diesen Artikel
Dieser Beitrag wurde auf Grundlage der englischen Fassung redaktionell für die deutsche Ausgabe lokalisiert.
