KI-Infrastruktur: die technische Basis für KI im Unternehmen

Die sieben Schichten einer KI-Infrastruktur

Wer KI über Einzel-Accounts hinaus betreibt, betreibt keine Oberfläche, sondern eine Kette von Systemen: Ein Modell erzeugt Text, ein Retrieval-System liefert den passenden Kontext, eine Orchestrierung entscheidet über Reihenfolge und Werkzeugaufrufe, ein Integrations-Layer verbindet das Ganze mit den Systemen, in denen die Arbeit tatsächlich stattfindet. Darüber liegen Identität, Protokollierung und Governance. Die Einteilung in sieben Schichten ist ein Ordnungsmodell, kein normierter Standard — andere Modelle schneiden anders. Ihr praktischer Wert liegt darin, dass sich jede Schicht getrennt beschaffen, ersetzen und prüfen lässt. Das ist der wesentliche Unterschied zu einer Sammlung von Chat-Zugängen.

Der Modell-Layer ist dabei die Schicht, die sich am schnellsten ändert und am leichtesten austauschen lässt. Genau deshalb sollte keine Anwendung direkt gegen eine Anbieter-API programmiert werden. Zwischen Anwendungen und Modelle gehört ein Gateway, das Schlüssel verwaltet, Anfragen auf Modelle verteilt, Limits durchsetzt und jede Anfrage protokolliert. Welche Modelle dahinter liegen — Anbieter-API, Hosting beim Hyperscaler oder selbst betriebene offene Gewichte — wird damit zu einer Konfigurations- statt einer Architekturentscheidung. Wie ein unternehmensweiter Modellzugang aufgebaut wird, behandelt die Seite zum Corporate LLM.

Die langlebigen Teile einer KI-Infrastruktur sind nicht die Modelle, sondern der saubere Zugang zu Kontext, ein belastbares Berechtigungsmodell und die Nachvollziehbarkeit der Ergebnisse. Diese Schichten überdauern mehrere Modellgenerationen.

• Zentrale Schlüsselverwaltung statt API-Keys in einzelnen Projekten
• Routing auf verschiedene Modelle je nach Aufgabe, Datenklasse und Kosten
• Durchsetzung von Rate Limits und Budgetgrenzen pro Team und Anwendungsfall
• Einheitliches Protokoll aller Anfragen inklusive Modellversion
• Ausweichpfad, wenn ein Anbieter ausfällt oder ein Modell abgekündigt wird

Daten- und Retrieval-Layer: Woher das Modell sein Wissen bekommt

Ein Sprachmodell kennt keine internen Preislisten, keine Projekthistorie und keine Betriebsvereinbarung. Alles betriebliche Wissen muss zur Laufzeit in den Kontext gelangen. Der übliche Weg dafür ist Retrieval Augmented Generation: Dokumente werden angebunden, geparst, in Abschnitte zerlegt, als Vektoren eingebettet und in einen Index geschrieben; zur Anfragezeit werden die passenden Abschnitte gesucht und dem Modell mitgegeben. Verfahren und Feinheiten sind auf der Seite zu RAG beschrieben.

Die Qualität dieser Schicht entscheidet über die Qualität der Antworten — deutlich stärker als die Wahl des Modells. Ein starkes Modell auf schwachem Kontext liefert flüssig formulierte falsche Antworten. Praktisch heißt das: Parser, die Tabellen und PDF-Layouts nicht zerstören, sinnvolle Abschnittsgrenzen, hybride Suche aus Stichwort- und Vektortreffern, ein Reranking-Schritt vor der Übergabe an das Modell und Metadaten wie Quelle, Stand und Gültigkeit an jedem Abschnitt.

Ebenso wichtig ist der Lebenszyklus: Ein Index ist kein einmaliger Import. Änderungen müssen nachziehen, gelöschte Dokumente müssen verschwinden, veraltete Stände müssen erkennbar sein. Welche Inhalte überhaupt indexiert werden sollten und wie die Quellen vorher geordnet werden, behandelt KI-Wissensmanagement.

• Anbindung: Konnektoren zu Dateiablage, Wiki, Ticketsystem — lesend, mit Rechteinformationen
• Aufbereitung: Parsing, Bereinigung, Zerlegung in sinnvoll abgegrenzte Abschnitte
• Anreicherung: Metadaten zu Quelle, Autor, Datum, Vertraulichkeit und Gültigkeit
• Indexierung: Embeddings plus Volltextindex für hybride Suche
• Abfrage: Suche, Berechtigungsfilter, Reranking, Kontextzusammenbau
• Pflege: Delta-Abgleich, Neuindexierung nach Änderungen, definierter Löschpfad

Orchestrierung: Wie aus Modellaufrufen ein Ablauf wird

Ein einzelner Modellaufruf löst selten eine betriebliche Aufgabe. Zwischen Anfrage und Ergebnis liegen mehrere Schritte: Kontext beschaffen, Zwischenergebnisse prüfen, ein Werkzeug aufrufen, das Resultat bewerten, gegebenenfalls wiederholen. Diese Ablaufsteuerung ist eine eigene Schicht mit eigenen Anforderungen an Fehlerbehandlung, Zeitlimits und Zustandshaltung.

Zwei Bauweisen stehen zur Wahl. Der deterministische Workflow legt die Schritte fest und setzt das Modell nur an definierten Stellen ein — für Klassifikation, Extraktion oder Formulierung. Der agentische Ansatz überlässt dem Modell die Entscheidung, welches Werkzeug als Nächstes sinnvoll ist; Funktionsweise und Grenzen beschreibt der Artikel zu KI-Agenten. In meinen eigenen Multi-Agent-Pipelines hat sich gezeigt: Je mehr Schritte ein Modell frei entscheiden darf, desto schwerer wird der Ablauf reproduzierbar und desto stärker streuen Laufzeit und Kosten — die Zahlen dazu stehen in Multi-Agent-Pipeline: Kosten transparent. Sinnvoll ist so viel fester Ablauf wie möglich und so viel Modellentscheidung wie nötig.

Für den Betrieb braucht diese Schicht dieselben Eigenschaften wie jede andere Ablaufsteuerung: Warteschlangen für lange Läufe, Wiederholungen mit Idempotenz, harte Abbruchbedingungen, ein Kostenlimit pro Lauf und definierte Punkte, an denen ein Mensch bestätigt, bevor etwas geschrieben wird.

Anbindung an bestehende Systeme und die Rolle von MCP

Der Nutzen entsteht dort, wo die Arbeit liegt: Dateiablage, Wiki, CRM, Ticketsystem, ERP, Kalender, Code-Repository. Dabei sind zwei Zugriffsarten zu trennen. Lesend holt das System Kontext — Angebote, Tickethistorie, Stammdaten. Schreibend verändert es Zustände — ein Ticket anlegen, ein Feld aktualisieren, eine Nachricht versenden. Schreibzugriffe brauchen eine andere Sorgfaltsstufe: eng begrenzter Umfang, Bestätigungsschritte, Idempotenz und ein Protokoll, das jede Änderung dem auslösenden Vorgang zuordnet.

Ohne Standard wächst der Integrationsaufwand multiplikativ: Jede Anwendung braucht eine eigene Anbindung an jedes System. Das Model Context Protocol (MCP) adressiert genau das. Es ist ein offenes Protokoll, über das ein Server die Werkzeuge, Ressourcen und Vorlagen eines Systems beschreibt und ein Client — eine Assistenzanwendung, eine Agentenlaufzeit — sie einheitlich nutzt. Ein Server pro System, nutzbar von verschiedenen Clients und Modellen. Wichtig für die Planung: MCP standardisiert die Schnittstelle, liefert aber keine fertigen Server für beliebige CRM-, Ticket- oder ERP-Produkte. Ob für ein konkretes System bereits ein Server existiert oder selbst gebaut werden muss, ist je System zu prüfen — wie ein solcher Server aufgebaut ist, zeigt die Anleitung MCP-Server bauen.

Für die Infrastruktur bedeutet das eine klare Trennung der Zuständigkeiten: Der MCP-Server kapselt Fachlogik, Feldzugriff und Rechteprüfung eines Systems. Die Anwendung darüber muss die Eigenheiten des ERP nicht kennen. Modelle und Oberflächen lassen sich austauschen, ohne die Anbindungen neu zu bauen — vorausgesetzt, die Server sind schmal geschnitten und nicht als Universalzugang gebaut.

• Dateiablage (SharePoint, Nextcloud, Google Drive): Dokumente als Kontextquelle, inklusive Ordner- und Freigabelogik
• Wiki und Intranet (Confluence, Notion): kuratiertes Prozesswissen — meist die beste erste Quelle
• CRM: Kunden-, Angebots- und Kontakthistorie; lesend für Zusammenfassungen, schreibend nur für definierte Felder
• Ticketsystem: Kategorisierung, Priorisierung und Antwortvorschläge mit Bezug auf ähnliche gelöste Fälle
• ERP: Stammdaten und Belege, in der Regel ausschließlich lesend und über eine enge, geprüfte Schnittstelle

Identität und Berechtigungen: KI muss erben, nicht umgehen

Die wichtigste Regel dieser Architektur lautet: Ein KI-System darf einem Nutzer nur zeigen, was dieser Nutzer auch ohne KI sehen dürfte. Die Berechtigungen der Quellsysteme müssen zur Anfragezeit greifen — als Bedingung der Suche selbst, nicht als nachgelagerter Filter auf der Oberfläche.

Was passiert, wenn das fehlt, lässt sich technisch genau beschreiben. Wird der Assistent über ein technisches Konto mit breitem Leserecht angebunden, antwortet er allen Nutzern aus dem gesamten Bestand. Wo Gehaltsdaten, Personalvorgänge, Vertragsentwürfe oder Vorstandsunterlagen in Ablagen liegen, deren Berechtigungen über Jahre gewachsen sind, schützt sie faktisch nur ihre Unauffindbarkeit. Eine semantische Suche hebt genau diese Unauffindbarkeit auf. Der Vorfall ist dann kein KI-Problem, sondern ein Berechtigungsproblem, das die KI sichtbar gemacht hat.

Technisch heißt das: Zugriffsrechte werden beim Indexieren als Metadaten mitgeführt und bei jeder Abfrage gegen die Gruppenzugehörigkeit des anfragenden Nutzers geprüft; Rechteänderungen müssen zeitnah nachziehen. Der Zugang zu den Anwendungen läuft über die vorhandene Identitätsverwaltung statt über separate Nutzerlisten. Agenten und Hintergrundprozesse bekommen eigene, eng geschnittene Dienstidentitäten, deren Aktionen dem auslösenden Nutzer zugeordnet bleiben.

• Anmeldung über den bestehenden Identitätsanbieter (SSO/OIDC), Nutzer- und Gruppenpflege über SCIM
• Berechtigungsfilter zur Abfragezeit, nicht erst bei der Anzeige des Ergebnisses
• Eigene Identität je Agent oder Automatisierung, mit dem minimal nötigen Umfang
• Schreibrechte getrennt von Leserechten vergeben und einzeln freigeben
• Wiederkehrende Prüfung, welche Quellen ein Dienstkonto tatsächlich lesen kann

Cloud, On-Premise oder hybrid?

Die Frage wird oft als Grundsatzentscheidung geführt, ist aber eine Abwägung entlang mehrerer Kriterien: Datenweg, Kostenstruktur, Betriebsaufwand, Modellauswahl, Zeit bis zum ersten produktiven Anwendungsfall und Verhalten bei Lastspitzen. Viele fachliche Anwendungsfälle lassen sich in allen drei Betriebsmodellen umsetzen — sie unterscheiden sich darin, was sie verlangen und was sie garantieren. Die Ausnahme sind Aufgaben, die auf die Leistungsfähigkeit der jeweils größten proprietären Modelle angewiesen sind: Sie sind im reinen Eigenbetrieb nur eingeschränkt abbildbar.

Cloud-APIs geben Zugriff auf die jeweils leistungsfähigsten Modelle ohne eigenen Betrieb, verlagern die Verarbeitung aber nach außen; steuerbar ist das über Vertragsgestaltung, Regionswahl und Zusagen zur Nutzung der Daten. Eigenbetrieb hält Inhalte im eigenen Netz, verlangt aber GPU-Kapazität, Update-Disziplin und Betriebswissen — den technischen Einstieg dazu beschreibt LLM lokal installieren. Wo beide Anforderungen zusammentreffen — schnelle Verfügbarkeit starker Modelle und ein kontrollierter Datenweg für sensible Vorgänge —, ist ein hybrider Aufbau die naheliegende Konsequenz: Eine Datenklassifizierung entscheidet je Vorgang über den Pfad.

Zwei Punkte werden leicht übersehen. Erstens ist der Betriebsaufwand eines hybriden Aufbaus höher als der jedes einzelnen Pfades, weil Prompts, Auswertungen und Berechtigungen doppelt gepflegt werden. Zweitens löst Eigenbetrieb keine Governance-Frage: Auch ein lokal betriebenes Modell braucht Berechtigungen, Protokollierung und einen Freigabeprozess.

Kostenmodelle: Token, Lizenzen, Hardware

KI-Infrastruktur hat keine einheitliche Kostenlogik. Nutzungsbasierte Modellabrechnung, Lizenzen pro Arbeitsplatz und Fixkosten für eigene Hardware verhalten sich unterschiedlich, wenn die Nutzung wächst — und genau diese Unterschiede bestimmen, welches Betriebsmodell bei welcher Auslastung günstiger ist.

Nutzungsbasierte Abrechnung ist am Anfang preiswert, weil nur bezahlt wird, was tatsächlich läuft. Kosten entstehen dabei multiplikativ: Zahl der Nutzer mal Anfragen mal Kontextlänge. Der Hebel mit der größten Spannweite ist selten die Nutzerzahl, sondern die Kontextlänge pro Anfrage und die Zahl der Zwischenschritte in agentischen Abläufen — beide lassen sich um ein Vielfaches verändern, ohne dass ein einziger Nutzer hinzukommt. Wiederkehrende Prompt-Anteile lassen sich über die Caching-Mechanismen der Anbieter günstiger stellen, unkritische Massenaufgaben über Batch-Verarbeitung — praktische Hebel dazu stehen in Tokens sparen.

Eigene Hardware kehrt die Logik um: Die Kosten sind weitgehend unabhängig von der Nutzung und werden erst bei hoher, gleichmäßiger Auslastung attraktiv. Eine Pilotphase mit wenigen Anfragen pro Tag rechnet sich auf eigener GPU praktisch nie. Umgekehrt kann eine dauerhaft laufende Klassifikations- oder Embedding-Last mit kleinen Modellen gut auf eigener Hardware liegen, während Reasoning-Aufgaben weiterhin über eine API laufen.

• Kontextlänge pro Anfrage begrenzen: gezieltes Retrieval statt ganzer Dokumente im Prompt
• Zwischenschritte agentischer Abläufe deckeln — hartes Limit für Iterationen und Kosten pro Lauf
• Modell-Routing nach Aufgabe: kleine Modelle für Klassifikation und Extraktion, große nur für Reasoning
• Caching für wiederkehrende Prompt-Anteile und Batch-Verarbeitung für unkritische Massenaufgaben nutzen
• Kostenmetriken je Team und Anwendungsfall erfassen, bevor die Nutzung breit ausgerollt wird

Beobachtbarkeit, Protokollierung und Auditierbarkeit

Ohne Protokollierung lässt sich weder eine Qualitäts- noch eine Compliance-Frage beantworten: Warum hat das System das geantwortet? Welche Quelle lag zugrunde? Wer hat es ausgelöst? Welche Modellversion war aktiv? Diese Felder müssen ab dem ersten produktiven Tag erfasst werden — vergangene Antworten lassen sich nachträglich nicht rekonstruieren.

Neben dem Protokoll braucht es eine Bewertung der Qualität. Ein fester Satz realer Testfragen mit erwarteten Antworten macht sichtbar, ob ein Modellwechsel, ein geänderter Prompt oder eine neue Indexierung die Ergebnisse verschlechtert hat. Ohne solche Regressionsprüfung ist jede Änderung an der Infrastruktur ein Blindflug. Ergänzend gehört eine niedrigschwellige Rückmeldemöglichkeit in die Oberfläche — mit einem Prozess, der die Meldungen tatsächlich auswertet.

Protokolle können personenbezogene Daten enthalten — Anfragetexte, Dokumentinhalte, Nutzerkennungen. Ob und in welchem Umfang das im konkreten Fall zutrifft, gehört mit dem eigenen Datenschutzbeauftragten geklärt. Als praktische Arbeitsannahme ist es sinnvoll, sie wie andere personenbezogene Bestände zu behandeln: definierter Zweck, begrenzte Aufbewahrung, geregelter Zugriff, Löschkonzept. Das ist eine fachliche Einordnung, keine Rechtsberatung. Wie diese Anforderungen mit Rollen, Freigaben und Nachweispflichten zusammenhängen, behandelt KI-Governance.

• Zeitpunkt, auslösender Nutzer oder Dienst, Anwendungsfall
• verwendetes Modell samt Version und Parametern
• genutzte Kontextquellen mit Dokumentkennung und Stand
• Werkzeugaufrufe mit Parametern und Rückgabestatus
• Token-Verbrauch, Latenz und Fehlerursache bei Abbruch
• Rückmeldung der Nutzenden, sofern erfasst

Ein minimaler Startaufbau, der trägt

Ein typischer Fehlstart ist der Versuch, alle Schichten gleichzeitig auf halber Höhe zu bauen. Tragfähiger ist ein einzelner Anwendungsfall, der senkrecht durch alle Schichten geht: eine Quelle, eine Nutzergruppe, ein klar formuliertes Ergebnis — aber mit ordentlicher Anmeldung, Rechteprüfung und vollständigem Protokoll. Dieser Aufbau ist klein genug für wenige Wochen und vollständig genug, um daraus zu wachsen.

Bewusst nicht Teil eines Startaufbaus sind eigenes Fine-Tuning, mehrere parallele Vektordatenbanken, Multi-Agent-Systeme und ein vollständiger Modellkatalog. Diese Themen binden Aufwand, bevor der erste belastbare Nutzen entsteht. Die organisatorische Einbettung — Verantwortlichkeiten, Freigaben, Nutzungsregeln — behandelt der Überblick zu Unternehmens-KI.

• Einen Anwendungsfall wählen, dessen Nutzen ohne Diskussion messbar ist (Suchzeit, Durchlaufzeit, Zahl der Rückfragen)
• Ein Gateway vor die Modelle setzen, bevor die erste Anwendung entsteht
• Anmeldung an den bestehenden Identitätsanbieter anschließen, keine separaten Nutzerkonten
• Genau eine Wissensquelle anbinden — meist das Wiki oder eine gepflegte Dokumentablage
• Berechtigungen dieser Quelle prüfen und als Filter in die Abfrage einbauen
• Protokollierung und Kostenmetriken von Tag eins aktivieren
• Einen festen Satz realer Testfragen mit erwarteten Antworten pflegen und vor jeder Änderung durchlaufen lassen
• Erst danach die zweite Quelle, den zweiten Anwendungsfall oder Schreibzugriffe ergänzen

Lohnt sich der Aufbau einer eigenen KI-Infrastruktur — oder reichen Einzel-Accounts und fertige Assistenten?

Häufige Fehler

1. Mit dem Modell anfangen statt mit dem Zugang Die Modellwahl ist die am schnellsten revidierbare Entscheidung der gesamten Architektur. Wochenlange Modellvergleiche vor der ersten geklärten Datenquelle verschieben Aufwand an die Stelle, an der er am wenigsten wirkt.
2. Ein technisches Konto für alle Zugriffe Ein Dienstkonto mit breitem Leserecht ist schnell eingerichtet und macht aus jeder unsauberen Freigabe im Dateisystem ein durchsuchbares Ergebnis. Berechtigungen gehören in die Abfrage, nicht in eine Nachbearbeitung der Trefferliste.
3. Indexieren, was gerade da ist Ein Retrieval-Index über eine ungepflegte Ablage liefert souverän formulierte Antworten aus veralteten Dokumenten. Ohne Kuratierung, Stände und Gültigkeitsangaben sinkt das Vertrauen nach den ersten falschen Antworten dauerhaft — und kehrt nur schwer zurück.
4. Protokollierung nachrüsten wollen Fehlt das Protokoll, lässt sich weder eine Beschwerde noch ein Qualitätsproblem aufklären, weil vergangene Antworten nicht rekonstruierbar sind. Logging ist billiger einzubauen als nachzurüsten, da es Datenmodell, Oberfläche und Aufbewahrungsregeln zugleich betrifft.
5. Agenten einsetzen, wo ein Workflow reicht Freie Schrittentscheidung erhöht Kosten, Latenz und Fehlerbandbreite. Viele produktive Anwendungsfälle sind feste Abläufe mit Modellaufrufen an zwei oder drei Stellen — und genau so sollten sie auch gebaut werden.
6. Die Anwendung fest an einen Anbieter koppeln Ohne Gateway und ohne getrennte Prompt-Verwaltung wird jeder Modellwechsel zum Umbau der Anwendung. Modellabhängige Teile gehören an eine Stelle, nicht verteilt über Code, Konfiguration und einzelne Automatisierungen.
7. Eine MCP-Anbindung als vorhanden voraussetzen MCP standardisiert die Schnittstelle, nicht die Verfügbarkeit fertiger Server. Für viele Fachsysteme — besonders ERP und branchenspezifische Anwendungen — muss der Server selbst gebaut und gepflegt werden. Dieser Aufwand gehört in die Planung, bevor die Anbindung im Zeitplan steht.

Weiterlesen

Verwandte Themen

• Corporate LLM: Was es ist, welche Bauformen es gibt und wann sich welche lohnt
• RAG: Retrieval Augmented Generation — die technische Referenz
• KI-Governance: der Rahmen, der KI-Nutzung nicht ausbremst