KI-Plattform Unternehmen 2026: erst Zugang, dann Oberfläche

Constantin Budin, Principal Data & AI bei Pexon Consulting | 11 Min. Lesezeit | 21.09.2026

Stand: September 2026

TL;DR: KI-Plattform im Unternehmen in fünf Sätzen

Wer eine KI-Plattform im Unternehmen auswählt, vergleicht meist Kandidaten auf verschiedenen Schichten. Copilot, Langdock und Claude sind Oberflächen oder Modelle, Open Source ist ein Bausatz. Nur die Zugangsschicht mit Gateway, Policy, Protokoll und Budget ist eine echte Einmalentscheidung. Spitzenmodelle halten rund zwölf Monate. Pexon Consulting baut diese Schicht zuerst, die Oberflächen danach.

Seit neun Monaten liegt im Lenkungskreis dieselbe Folie. Vier Spalten: Microsoft 365 Copilot, weil Microsoft ohnehin im Haus ist. Langdock, weil der Datenschutz eine deutsche Oberfläche vorgeschlagen hat. Claude, weil die Entwickler danach fragen. Und „selbst bauen“, weil jemand ein Wochenende mit Open WebUI verbracht hat und begeistert zurückkam. Am Ende jeder Sitzung steht derselbe Beschluss: noch einmal genauer anschauen.

Wir hören diese Szene in Erstgesprächen fast wörtlich. Ein Haus mit Microsoft-Stack hatte gleichzeitig Azure AI Foundry, LiteLLM, Claude und OpenRouter auf dem Tisch. Ein anderes verglich Copilot gegen Claude gegen Private AI und nannte „Token-Preise und Zukunftsstabilität“ als offene Frage. Dreimal derselbe Befund: viele Kandidaten, kein Raster.

Das Problem: Die Auswahl ist nicht Ihr Engpass

Die Entscheidung fällt schwer, weil sie falsch gestellt ist. Sie lautet nicht „welche Plattform“, sondern „welche Schicht entscheide ich jetzt und welche später“. Solange die vier Kandidaten nebeneinander auf einer Folie stehen, bleibt jede Diskussion ein Vergleich von Dingen, die nicht dasselbe tun.

Die Zahlen zeigen, wo es tatsächlich klemmt. Der Bitkom hat am 14.09.2026 eine repräsentative Befragung von 603 Unternehmen ab 20 Beschäftigten veröffentlicht (Feldzeit Kalenderwoche 28 bis 33). Erstmals setzt die Mehrheit KI ein: 57 Prozent, nach 36 Prozent 2025 und 20 Prozent 2024. Weitere 38 Prozent planen oder diskutieren, nur noch 4 Prozent sagen „kein Thema“ (Bitkom-Presseinformation).

Der zweite Teil derselben Studie ist unbequemer. Kein einziges der KI-nutzenden Unternehmen sagt, es schöpfe das Potenzial vollständig aus. 59 Prozent sagen: überhaupt nicht.

Noch aufschlussreicher sind die Hemmnisse, weil der Bitkom sie nach Nutzern und Nicht-Nutzern trennt:

Wer noch nicht nutzt, hat ein Know-how-Problem. Wer nutzt, hat ein Governance- und Kostenproblem. Die Produktauswahl löst keines von beiden. Datenschutz, Rechtssicherheit und Kostenkontrolle sind Eigenschaften der Schicht unter den Werkzeugen, nicht der Werkzeuge selbst. Genau diese Schicht steht auf keiner der vier Spalten.

Vier Kandidaten, drei verschiedene Schichten

Sie vergleichen eine Bohrmaschine mit einem Werkzeugkasten und einem Handwerker. Copilot ist ein Produktivitäts-Add-on mit Sitzlizenz. Langdock ist eine Chat-Oberfläche mit Modellauswahl. Claude ist ein Modell, das über mehrere Wege bezogen werden kann. Open Source ist kein Produkt, sondern ein Bausatz.

Warum der Chat allein noch keine Plattform ist, haben wir in Warum der Chat nicht die KI-Plattform ist an Nachtprozessen beschrieben. Dort ging es um das Was. Hier geht es um die Reihenfolge.

Drei der vier Kandidaten entscheiden die Oberfläche. Keiner entscheidet den Zugang. Und der Zugang ist die einzige Schicht, die Sie nur einmal bauen.

Das ist ausdrücklich keine Abwertung. Copilot ist gut für das, wofür es gebaut ist, und in Word, Excel und Teams schwer zu schlagen. Die Lücke beginnt dort, wo Fachdaten, Modellwahl, Nachweis und Kosten anfangen.

Das Schichtenmodell einer KI-Plattform im Unternehmen

Eine KI-Plattform im Unternehmen besteht aus vier Schichten: Modell und Betriebsort, Zugang mit Policy und Protokoll, Oberfläche, Anwendungsfall. Nur die Zugangsschicht ist eine Einmalentscheidung. Die anderen drei dürfen sich drehen, solange die Zugangsschicht steht.

Die Wechselfrequenz der untersten Schicht ist keine Schätzung. Anthropic veröffentlicht die komplette Abkündigungshistorie seiner Modelle (Model deprecations, abgerufen 21.09.2026). Weil die Modell-ID das Erscheinungsdatum trägt, lässt sich die Lebensdauer direkt ablesen:

Nach der Abschaltung gibt es keinen Gnadenmodus. Die Doku sagt es ohne Umschweife: „Requests to retired models will fail.“ Die Vorwarnzeit beträgt mindestens 60 Tage. Auf Amazon Bedrock und Google Cloud gelten zudem eigene Abschaltpläne, dasselbe Modell kann dort andere Termine haben.

Ein Modellwechsel ist auch selten nur ein anderer String in der Konfiguration. Ab Claude Opus 4.7 sind temperature, top_p und top_k abgekündigt. Wer einen Nicht-Standardwert setzt, bekommt HTTP 400, im Python-SDK ab v1.0 wirft der Aufruf einen TypeError. Funktionierender Code bricht also beim Upgrade.

Unsere Konsequenz daraus ist klar: Binden Sie keine Architekturentscheidung mit fünf Jahren Laufzeit an eine Schicht, die sich jährlich dreht. Welches Gateway-Produkt dann konkret in Schicht 2 sitzt, ist eine eigene Frage, die der Produktvergleich von vier LLM-Gateways behandelt. Dieser Artikel klärt nur, dass die Schicht zuerst kommt.

„Wir sind ja OpenAI-kompatibel“ ist kein Ausweg

Die häufigste Antwort auf das Lock-in-Argument lautet: Alle sprechen doch die OpenAI-API, also wechseln wir einfach die Basis-URL. Das stimmt für den Aufruf, nicht für das Ergebnis. Kompatibilität heißt, dass der Aufruf nicht abstürzt. Sie heißt nicht, dass jedes Feld ausgewertet wird.

Anthropic selbst beschreibt den eigenen OpenAI-kompatiblen Endpunkt als Test- und Vergleichswerkzeug: „not considered a long-term or production-ready solution for most use cases“ (OpenAI SDK compatibility, abgerufen 21.09.2026). Die Doku listet 15 Anfragefelder auf oberster Ebene, die ignoriert werden, darunter response_format, seed, logprobs und reasoning_effort, dazu weitere Felder in Tools und Nachrichten. Der entscheidende Satz: „Most unsupported fields are silently ignored rather than producing errors.“

Noch härter trifft es Tool-Aufrufe. Das Feld strict bei Function Calling wird verworfen, die Ausgabe folgt dem Schema also nicht garantiert. Prompt Caching läuft über diesen Weg gar nicht, und mehrere System-Nachrichten werden zu einer zusammengezogen.

So sieht das in der Praxis aus. Der folgende Aufruf läuft ohne Fehler durch:

# Prüft, ob ein "OpenAI-kompatibler" Endpunkt Ihre Felder wirklich auswertet
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ANTHROPIC_API_KEY"],
    base_url="https://api.anthropic.com/v1/",
)

antwort = client.chat.completions.create(
    model="claude-sonnet-4-6",
    messages=[{"role": "user", "content": "Nenne drei Risiken beim Modellwechsel als JSON."}],
    # Beide Felder werden am Kompatibilitäts-Endpunkt stillschweigend ignoriert
    response_format={"type": "json_object"},
    seed=42,
)

# Kein Fehler, aber auch keine JSON-Garantie und keine Reproduzierbarkeit
print(antwort.choices[0].message.content)

Das Problem fällt erst im Output auf, oft Wochen später in einer nachgelagerten Verarbeitung. Dazu kommt die Cloud-Ebene: Derselbe Anbieter hat auf Bedrock das ID-Präfix anthropic., dort fehlen laut Anthropic-Doku unter anderem Structured Outputs, der MCP-Connector und Agent Skills. Portabilität entsteht also nicht durch ein Protokoll, sondern durch eine Schicht, die diese Unterschiede kennt und kapselt. Wie abhängig Ihr heutiger Stack ist, misst der Unabhängigkeits-Score von 0 bis 10.

Sechs Fragen, die die Entscheidung beenden

Die folgende Matrix ist der Teil, den Sie in den nächsten Lenkungskreis mitnehmen können. Sie darf ausdrücklich bei „Copilot genügt“ enden. Ein Raster, das immer beim eigenen Angebot landet, wäre kein Raster.

Lauten die Antworten auf 1 bis 5 fünfmal „nein“, bleiben Sie bei Copilot und sparen sich das Projekt. Ab zwei „ja“ lohnt es sich, die Zugangsschicht vor jeder weiteren Oberfläche zu entscheiden. Frage 6 entscheidet nicht über das Ob, sondern nur darüber, wer betreibt.

Ein Einwand kommt an dieser Stelle fast immer: „Unsere IT hat Vorbehalte gegen Open Source.“ Der ist berechtigt, und er betrifft Lieferkette und Updates, nicht die Architektur. Auch eine Zugangsschicht aus Open-Source-Bausteinen braucht Versionspflege, Lizenzprüfung und jemanden, der bei einer Sicherheitsmeldung reagiert. Kostenfrei ist nur die Lizenz, nicht der Betrieb.

Wo LibreChat, Open WebUI und OpenRouter hingehören

Die Suchanfragen, die uns zu diesem Thema erreichen, tragen selten den Begriff „KI-Plattform“. Sie tragen Werkzeugnamen: librechat, open webui, openrouter. Sortiert nach Schichten wird schnell klar, warum sich diese Werkzeuge nicht gegenseitig ersetzen.

Open WebUI ist eine Oberfläche, Schicht 3. Das Projekt steht bei 152.671 GitHub-Sternen, aktuelle Version v0.11.3 vom 31.08.2026 (GitHub, abgerufen 21.09.2026). Die Oberfläche ist aber kein Ersatz für eine zentrale Policy, sobald neben dem Chat auch Anwendungen und Agenten auf Modelle zugreifen.

LibreChat liegt auf derselben Schicht, mit 44.524 Sternen (abgerufen 21.09.2026). Die letzte stabile Version ist v0.8.7, der Kandidat v0.8.8-rc3 erschien am 15.09.2026. Welche der beiden Oberflächen zu Ihnen passt, klärt unser Vergleich zwischen LibreChat und Open WebUI. Die Wahl ist korrigierbar, wenn Schicht 2 steht.

OpenRouter ist etwas anderes: ein gehosteter Dienst, der viele Modelle hinter einem Endpunkt bündelt. Das gehört zu Schicht 2, allerdings als Dienst eines Dritten. Für eine Unternehmensplattform stellen Sie dieselben Fragen wie an jeden Anbieter der Zugangsschicht: Wo laufen die Anfragen, wer hält die Keys, wo liegt das Protokoll, wie kommen Sie wieder heraus.

Unsere Empfehlung: Wählen Sie Oberflächen nach Zielgruppe und erlauben Sie mehrere. Copilot für Office, eine offene Oberfläche für Fachbereiche, die IDE für Entwickler. Bei der Zugangsschicht erlauben Sie genau eine.

Drei Wege, die in der Praxis funktionieren

Nicht jedes Haus startet am selben Punkt. Wir sehen drei Muster, die sich wiederholen, jeweils mit einer klaren Reihenfolge.

Microsoft-Haus mit Fachdaten-Bedarf. Copilot bleibt für Office, kein Cutover. Daneben entsteht die Zugangsschicht für alles, was aus Microsoft 365 herausführt: Dokumentverarbeitung, Fachanwendungen, eigene Assistenten. Zuerst Gateway und Anmeldung über Entra ID, danach eine erste Oberfläche, bewusst später weitere Modelle. Den Schnitt zwischen beiden Welten beschreibt die Seite Copilot und eigene Plattform nebeneinander.

Reguliertes Haus mit EU-Pflicht. Hier kommt die Zugangsschicht zuerst, weil Datenklassen und Protokoll Voraussetzung jeder Freigabe sind. Das Modell läuft über einen EU-fähigen Bezugsweg, etwa Claude über AWS Bedrock mit regionalem Endpunkt. Das kostet belegt 10 Prozent Aufschlag gegenüber dem globalen Endpunkt („Regional endpoints carry a 10% pricing premium over global endpoints“, Anthropic-Doku zu Bedrock, abgerufen 21.09.2026). Wie Sie Claude über die eigene Cloud beziehen und welche Funktionen dabei fehlen, steht unter Claude über Drittplattformen betreiben. EU-Region und AVV klären die Datenverarbeitung, nicht die Frage nach dem Mutterkonzern des Anbieters. Wo auch das nicht reicht, bleibt der Betrieb offener Modelle auf eigener Hardware, mit dem Nachteil, dass geschlossene Modelle wie Claude oder GPT dort nicht laufen.

Entwicklerhaus. Die Oberfläche ist nachrangig, weil die Hauptnutzer in der IDE arbeiten. Zuerst Zugangsschicht mit Keys je Team und Budget, dann die Werkzeuge der Entwickler dagegen konfigurieren, erst zuletzt ein Chat für die übrigen Abteilungen.

Die Reihenfolge ist in allen drei Wegen dieselbe:

1. Zugangsschicht: Gateway, Anmeldung, Datenklassen, Protokoll, Budget.
2. Erste Oberfläche für die größte Zielgruppe.
3. Modelle je Aufgabe und Datenklasse, austauschbar.
4. Weitere Oberflächen und Anwendungsfälle.

Wer die Zugangsschicht zuerst baut, darf sich bei Oberflächen und Modellen irren. Wer andersherum startet, entscheidet dreimal. Das ist der Kern der offenen KI-Plattform, wie wir sie bei Pexon Consulting aufbauen: Microsoft Partner, ISO 27001 zertifiziert, 80 Mitarbeitende in Deutschland. Wir verkaufen Ihnen keine Plattform. Wir bauen die Schicht, auf der Ihre Plattformen laufen, und die gehört Ihnen: Code im eigenen Repository, Betrieb wahlweise bei uns.

Häufig gestellte Fragen

Reicht Microsoft 365 Copilot als KI-Plattform für ein Unternehmen?

Für Aufgaben innerhalb von Microsoft 365 oft ja. Sobald Fachdaten außerhalb von M365 verarbeitet werden, mehrere Modelle nötig sind oder ein Nachweis verlangt wird, fehlt eine Schicht darunter. Die sechs Fragen in diesem Artikel klären das in wenigen Minuten, und fünfmal „nein“ heißt: Copilot genügt.

Ist Langdock eine Alternative zu Copilot?

Nur teilweise. Beide sind Oberflächen, aber für unterschiedliche Zielgruppen. „Copilot oder Langdock“ ist eine Oberflächenfrage, keine Plattformfrage, und sie lässt sich später korrigieren, wenn die Zugangsschicht steht.

Wie oft muss man das KI-Modell wechseln?

Nach der öffentlichen Abkündigungshistorie von Anthropic lebten die Spitzenmodelle der letzten Generationen 12 bis 13 Monate, etwa claude-opus-4-1-20250805 vom 05.08.2025 bis 05.08.2026. Die Vorwarnzeit beträgt mindestens 60 Tage, danach schlagen Anfragen hart fehl (Stand September 2026).

Kann ich später den Anbieter wechseln, wenn die API OpenAI-kompatibel ist?

Nur eingeschränkt. Anthropic bezeichnet den eigenen OpenAI-kompatiblen Endpunkt ausdrücklich nicht als Produktionsweg, 15 Anfragefelder auf oberster Ebene werden ignoriert, und strict bei Tool-Schemata wird verworfen. Portabilität liefert erst eine Zugangsschicht, die diese Unterschiede kapselt.

Was kostet EU-Datenresidenz bei einer KI-Plattform zusätzlich?

Belegt sind 10 Prozent Aufschlag für regionale gegenüber globalen Endpunkten bei Claude auf AWS Bedrock (Anthropic-Doku, Stand September 2026). Der größere Kostenblock liegt selten im Aufschlag, sondern im Unterschied zwischen Sitzlizenz und Verbrauch.

Nächster Schritt

Wenn die Zugangsschicht steht und die erste Oberfläche für Ihre Fachbereiche sauber angebunden werden soll, mit SSO, Protokoll und mehreren Modellen:

Verwandte Themen