KI im Unternehmen: extern, On-Premise oder beides

1. Die Entscheidung ist nicht binär — und die Rahmung, die sie binär macht, ist das Problem

Die erste ernsthafte Frage, auf die ein Unternehmens-KI-Programm nach der anfänglichen Begeisterung stößt, lautet: Wo sollen die Modelle eigentlich laufen? Die Diskussion polarisiert sich schnell. Das Sicherheitsteam plädiert für On-Premise: Daten intern halten, die Frage grenzüberschreitender Übertragung eliminieren. Das Produktteam plädiert für externe Modelle: Die Frontier-Modelle leisten, was interne nicht können, und der technologische Rückstand ist gefährlicher als das kontrollierte Risiko. Das Plattformteam plädiert für das, was am schnellsten betriebsbereit ist. In den meisten Unternehmen dreht sich die Diskussion monatelang um dieses Dreieck, bis jemand bemerkt, dass die drei Positionen verschiedene Workflows beschreiben — und die richtige Antwort wahrscheinlich eine Kombination aus allen dreien ist.

Die meisten Gespräche über KI-Deployment beginnen mit einer einzigen Frage: Sollen wir externe LLMs nutzen oder eigene betreiben? Die Rahmung setzt voraus, dass die Antwort einheitlich für das gesamte Unternehmen gilt. Das tut sie nicht.

Ein typisches Unternehmen hat Dutzende von Workflows, bei denen KI nützlich wäre. Einige davon — Marketingtexte verfassen, öffentliche Dokumente zusammenfassen, interne Schulungsinhalte erstellen — unterliegen keiner nennenswerten Datensensibilitätsbeschränkung. Die Daten dürfen überallhin gesendet werden. Die leistungsfähigsten Modelle, unabhängig vom Hosting-Ort, sind die richtige Wahl. Es gibt keinen betrieblichen Grund, interne Infrastruktur dafür zu betreiben.

Andere Workflows desselben Unternehmens — Verarbeitung von Kundenservice-Tickets, Analyse von Betriebsprotokollen, Erstellung klinischer Notizen, Prüfung von Kreditanträgen — unterliegen Restriktionen, die von vertraglichen Datenlokalisierungsverpflichtungen über sektorspezifische Datenhaltungsanforderungen bis hin zu internen Governance-Regeln reichen. Dasselbe Modell, das für Marketingtexte geeignet ist, ist für diese Workflows nicht geeignet. Die Wahl für diese Workflows ist real.

Eine dritte Kategorie — klassifizierte Verteidigungsoperationen, rechtmäßige Abhördaten, bestimmte Szenarien im Gesundheitswesen — unterliegt Restriktionen, die schlicht keinen externen Endpunkt zulassen, unabhängig von Sicherheitsvorkehrungen. Die Wahl für diese Workflows ist ebenfalls real, aber eine andere.

Alle drei Kategorien als eine einzige Entscheidung zu behandeln führt zu schlechter Architektur. Entweder werden einfache Workflows übermäßig geschützt (betrieben auf interner Infrastruktur, die Betriebsaufwand kostet, ohne proportionalen Wert zu liefern), oder die schwierigen werden unzureichend geschützt (an externe Endpunkte gesendet, weil das die „KI-Strategie" des Unternehmens ist). Die realistische Antwort ist, für unterschiedliche Workflow-Kategorien unterschiedliche Entscheidungen zu treffen — und die Infrastruktur zu betreiben, die diese Entscheidungen nebeneinander ermöglicht.

2. Externe LLMs — Stärken und Grenzen

Das Argument für externe LLMs ist einfach und sollte präzise formuliert werden. Die Frontier-Modelle — GPT-5-Klasse, Claude Opus-Klasse, Gemini Ultra-Klasse — operieren auf einem Leistungsniveau, das kein Unternehmen mit eigener Infrastruktur erreichen wird. Sie verfügen über Kontextfenster, die vollständige Dokumentenportfolios verarbeiten. Sie schlussfolgern über komplexe Strukturen mit einer Qualität, die kleinere Modelle nicht annähernd erreichen. Sie verbessern sich alle paar Monate, ohne dass das Unternehmen Kosten für Nachtraining trägt. Für Workflows, bei denen Leistungsfähigkeit zählt, ist das kein marginaler Vorteil. Es ist eine andere Kategorie von System.

Die Kostenstruktur verdient ebenfalls Ehrlichkeit. Externe LLMs werden über APIs der Anbieter zugänglich gemacht, wobei das Modell auf der Infrastruktur des Anbieters, in dessen Rechenzentren, unter dessen Betriebskontrolle läuft. Das Unternehmen sendet Daten an diese Endpunkte und empfängt Antworten. Die vertraglichen Zusicherungen des Anbieters — Datenverarbeitungsverträge, regionale Endpunkte, Löschrichtlinien — beschreiben, was der Anbieter mit den Daten tun und nicht tun wird. Sie beschreiben nicht, was das Recht des Gastgeberlandes anderen Parteien gegebenenfalls erlaubt.

Für Workflows, bei denen die Daten nicht sensibel sind, ist das kein Problem. Für Workflows, bei denen die Daten sensibel sind, der Datenlokalisierungskontext aber durch architektonische Maßnahmen erfüllbar ist (regionale Endpunkte, Transformation vor der Übertragung, unternehmenskontrolliertes Mapping), ist das lösbar.

Für Workflows, bei denen die Daten sensibel sind und die Restriktion darin besteht, dass keine Version der Daten — wie auch immer transformiert — an einen externen Endpunkt gesendet werden darf, sind externe LLMs keine Option. Einige Workflows fallen tatsächlich in diese Kategorie. Der Fehler liegt darin anzunehmen, dass alle sensiblen Workflows das tun.

3. On-Premise-LLMs — Stärken und Schwachstellen

Das Argument für den Betrieb von Modellen auf interner Infrastruktur ist auf den ersten Blick ebenfalls einfach. Die Daten verlassen das Unternehmen nicht. Die vertraglichen Fragen zur grenzüberschreitenden Übertragung stellen sich schlicht nicht. Für Workflows unter absoluten Datenlokalisierungsrestriktionen — Verteidigung, bestimmte regulierte Bereiche im Gesundheitswesen, bestimmte Finanztransaktionssegmente — ist dies die einzige Option, und sie verdient ernsthafte Betrachtung.

Die Stärken sind real:

• Datenlokalisierung ist per Definition gelöst. Das Modell läuft dort, wo die Daten sind; die Frage der Übertragung stellt sich nicht. Für Workflows unter sektorspezifischen Verpflichtungen, die das Unternehmen an definierte Grenzen binden, passt dies sauber auf die Restriktion.
• Betriebskontrolle ist vollständig. Das Modell kann unter den eigenen Change-Management-Prozessen des Unternehmens feinabgestimmt, evaluiert, überwacht und zurückgerollt werden. Es gibt keinen Anbieter auf der anderen Seite, der Modell-Updates durchführt, die das Unternehmen nicht genehmigt hat.
• Latenz kann vorhersagbar gestaltet werden. Ein Modell, das im unternehmenseigenen Netzwerk läuft, vermeidet den Roundtrip zu einem externen Endpunkt — relevant für bestimmte Echtzeit-Workflows.

Die Kosten sind ebenfalls real und werden von Teams, die noch keine KI-Infrastruktur in Produktion betrieben haben, häufig unterschätzt:

• Modellleistung bleibt zurück. Die Open-Source-Modelle, die ein Unternehmen praktikabel hosten kann — Llama, Mistral, Qwen und deren Nachfolger — sind gute Modelle. Sie sind zu keinem Zeitpunkt so leistungsfähig wie die externen Frontier-Modelle in den Dimensionen, die Unternehmen tatsächlich interessieren: Schlussfolgern über komplexe Dokumente, Umgang mit unbekannten Formaten, Langkontext-Analyse. Der Rückstand beträgt typischerweise zwölf bis achtzehn Monate und mag sich im Laufe der Zeit verringern, schließt sich aber nicht.
• Die Betriebskosten sind hoch und kontinuierlich. Ein ernsthaftes Modell in Produktion zu betreiben bedeutet GPU-Infrastruktur, Model-Serving-Infrastruktur (vLLM, TGI oder Ähnliches), Evaluierungspipelines, Monitoring und das Team, das das alles am Laufen hält. Die Kosten werden nicht durch die GPUs dominiert, sondern durch das Team. Ein kleines KI-Infrastrukturteam für Enterprise-Serving umfasst fünf bis zehn Engineers; ein ernsthaftes Team ist doppelt so groß. Das Modell selbst ist der günstige Teil.
• Die Schwachstelle zeigt sich bei Updates. Alle paar Monate machen die externen Frontier-Modelle Sprünge, die verändern, was Geschäftsbereiche erwarten. Das interne Modell, wie gut auch immer abgestimmt, macht diese Sprünge nicht. Die Lücke zwischen dem, was KI im öffentlichen Diskurs leisten kann, und dem, was die interne KI des Unternehmens leisten kann, wächst — und der Druck, etwas daran zu ändern, wächst mit ihr.

Für Workflows, bei denen die Restriktion absolut ist — und bei denen der Workflow überschaubar genug ist, dass ein leistungsfähiges kleineres Modell ausreicht — ist On-Premise die richtige Antwort. Für Workflows, bei denen die Restriktion real, aber nicht absolut ist und die KI-Leistungsfähigkeit zählt, erzeugt allein On-Premise ein System, das funktioniert, aber zu wenig leistet.

4. Hybrid — Kein Kompromiss, sondern die architektonisch ehrliche Antwort

Die dritte Option — eine hybride Topologie zu betreiben, bei der einige Workflows zu externen Endpunkten gehen und andere auf interner Infrastruktur laufen — wird in Unternehmensgesprächen zu schnell abgetan. Die Ablehnung nimmt meist eine von zwei Formen an.

Die erste ist operativ: „Beides zu betreiben ist komplexer als eines zu wählen, also sollten wir eines wählen." Das stimmt, verfehlt aber den Punkt. Beides zu betreiben ist nicht komplexer, wenn die Workflows, die jeweils eines benötigen, verschiedene Workflows sind. Die Komplexität einer hybriden Topologie liegt in der Routing-Schicht, die entscheidet, welches Modell welchen Workflow erhält. Diese Routing-Schicht ist nicht optional — selbst ein rein externes oder rein On-Premise-Unternehmen hat eine, sie ist nur trivial — und sobald die Routing-Schicht existiert, ist die Unterstützung zweier Backends inkrementelle Komplexität, keine kategorische.

Die zweite ist Governance: „Wir sollten eine einheitliche KI-Richtlinie haben." Das stimmt ebenfalls und verfehlt ebenfalls den Punkt. Die einheitliche Richtlinie lautet nicht „Alle KI läuft extern" oder „Alle KI läuft On-Premise." Die einheitliche Richtlinie lautet: „Workflows der Klasse X laufen extern mit diesen Sicherheitsvorkehrungen; Workflows der Klasse Y laufen On-Premise; das Routing wird erzwungen und auditiert." Das ist eine kohärente Governance-Haltung — und die, zu der die meisten großen Unternehmen gelangen, ob sie dafür geplant haben oder nicht.

Was Hybrid zur architektonisch ehrlichen Antwort macht, ist, dass es der tatsächlichen Struktur unternehmerischer KI-Workloads entspricht. Einige Workflows profitieren massiv von Frontier-Leistungsfähigkeit und vertragen transformationsbasierte Sicherheitsvorkehrungen. Einige Workflows haben Restriktionen, die externe Endpunkte ausschließen — unabhängig von etwaigen Sicherheitsvorkehrungen. Alle Workflows in einen der Eimer zu zwingen erzeugt ein System, das für einige davon falsch ist. Hybrid gibt jedem Workflow das Deployment, das er benötigt.

Das Schwierige an Hybrid ist nicht, zwei Backends zu betreiben. Es ist, die Routing-Entscheidung präzise genug zu gestalten, dass Workflows dorthin gelangen, wo sie hingehören — mit durchgesetzter Richtlinie und einem klaren Audit-Trail, der es dem Team ermöglicht, die Entscheidungen später zu verteidigen. Das ist ein Designproblem, kein Infrastrukturproblem.

5. Ein Entscheidungsrahmen für Workflows

Ein hilfreicher Weg, die Entscheidung konkret zu machen, ist die Bewertung jedes Workflows anhand von vier Fragen:

1. Wie sensibel sind die Daten, mit denen der Workflow operiert? Nicht die maximale Sensibilität irgendeiner Daten irgendwo im Unternehmen — die Sensibilität der spezifischen Daten, die dieser Workflow benötigt. Marketingtexte und Kundendatensätze sind verschiedene Workflows, auch wenn dieselbe Geschäftseinheit beide verantwortet.
2. Wie hoch ist der Leistungsanspruch der KI-Aufgabe? Einige Aufgaben — Klassifikation eingehender Tickets in zehn Kategorien, einfache Entitätsextraktion, Formatkonvertierung — funktionieren gut auf kleineren Modellen. Andere Aufgaben — Schlussfolgern über einen hundert Seiten langen Vertrag, Synthese von Ursachen aus heterogenen Protokollen, Erstellung klinischer Narrative — erfordern Frontier-Leistungsfähigkeit.
3. Wie ist die Restriktionsstruktur? Ist die Restriktion absolut (keine Version der Daten darf das Unternehmen verlassen) oder konditional (die Daten dürfen das Unternehmen verlassen, wenn sie entsprechend transformiert wurden)? Wird sie durch externe Verpflichtungen (Kundenvereinbarungen, DSGVO-konforme Sektorverpflichtungen) oder interne Governance (die eigene Datenhaltungsstrategie des Unternehmens) angetrieben?
4. Wie tolerant ist der Workflow gegenüber Leistungseinbußen? Einige Workflows liefern Wert mit einem Modell, das zwölf Monate hinter dem Frontier zurückliegt. Andere Workflows sind selbst die differenzierende Leistungsfähigkeit, die das Unternehmen aufzubauen versucht — und die Modelllücke ist die Lücke.

Die Antworten gruppieren sich in grobe Kategorien:

Die meisten Unternehmen stellen fest, dass ihr Workflow-Bestand alle vier Kategorien umfasst. Die Deployment-Architektur muss alle vier abdecken — was standardmäßig Hybrid bedeutet.

6. Wie Hybrid in der Praxis aussieht

Ein Hybrid-Deployment ist nicht „Wir haben ein Modell hier und ein Modell dort." Es ist eine Integrationsarchitektur, bei der die Routing-Entscheidung — welches Backend welche Anfrage bearbeitet — richtliniengesteuert, auditierbar und konsistent ist.

Die Komponenten, die das ermöglichen:

6.1 Eine einheitliche Integrationsschicht

Workflows rufen nicht direkt den externen Endpunkt oder das On-Premise-Modell auf. Sie rufen eine Integrationsschicht auf, die das Routing übernimmt. Das bedeutet, dass Workflows gegenüber Änderungen in der Backend-Auswahl abgeschirmt sind. Wenn ein Workflow von extern auf On-Premise wechseln muss (aufgrund einer neuen Restriktion, eines Anbieterwechsels oder einer Richtlinienaktualisierung), ändert sich der Workflow nicht — die Routing-Regel tut es.

6.2 Richtliniengesteuertes Routing

Die Entscheidung, wo ein Workflow läuft, ist in einer Richtlinie kodiert, nicht im Code des Workflows selbst. „Workflows, die als Kundenservice in der EU-Region gekennzeichnet sind, gehen zum externen Endpunkt mit der Transformationsschicht. Workflows, die als klassifiziert gekennzeichnet sind, gehen zum On-Premise-Modell. Workflows, die als Marketinginhalt gekennzeichnet sind, gehen ohne Transformation zum externen Endpunkt." Die Richtlinie ist versioniert und auditierbar.

6.3 Eine Transformationsschicht für den externen Pfad

Wenn Workflows zum externen Endpunkt geroutet werden, werden sensible Elemente vor der Übertragung transformiert und bei der Antwort wiederhergestellt. Dieselbe Transformationsinfrastruktur funktioniert unabhängig davon, welcher externe Endpunkt das Routing-Ziel ist — die Abstraktion liegt über dem Backend, nicht über einem spezifischen Anbieter.

6.4 Gemeinsame Governance

Die Audit-Protokolle, das Richtlinienmanagement, die Zugriffskontrollen decken beide Pfade einheitlich ab. Das Team hat nicht zwei Governance-Frameworks — eines für extern und eines für On-Premise. Es hat eines, mit dem Pfad jeder Anfrage aufgezeichnet.

Wenn diese vier Komponenten vorhanden sind, wird die Frage „Wo soll dieser Workflow laufen?" zu einer Richtlinienentscheidung statt zu einer Architekturverpflichtung. Der Workflow kann zwischen Pfaden wechseln, wenn sich Anforderungen ändern, ohne Integrationen neu schreiben zu müssen.

7. Was schiefläuft, wenn ein Pfad als die gesamte Antwort behandelt wird

Zwei Fehlermodi treten konsistent in Unternehmen auf, die sich auf einen einzigen Deployment-Pfad festlegen.

• Das rein externe Unternehmen. Ein Unternehmen, das entscheidet, externe LLMs seien die gesamte KI-Strategie, wird auf Workflows stoßen, die die Richtlinie nicht erlaubt — und eines von zwei Dingen passiert. Entweder erhalten diese Workflows keine KI (und das Unternehmen fällt bei den Aufgaben zurück, bei denen KI am meisten zählt), oder die Workflows erhalten KI über inoffizielle Kanäle — Mitarbeiter kopieren sensible Daten in Consumer-Chatbots, Geschäftsbereiche beschaffen KI-Tools außerhalb des zentralen Prozesses, Anbieter werden ohne das zentrale Sicherheitsreview integriert. Shadow-KI ist die vorhersehbare Konsequenz einer KI-Strategie, die Workflows nicht berücksichtigt, für die sie nicht passt.
• Das rein On-Premise-Unternehmen. Ein Unternehmen, das entscheidet, externe LLMs seien generell inakzeptabel, wird auf die Leistungslücke stoßen. Interne Modelle sind für einige Workflows gut genug und für andere nicht. Die Workflows, für die sie nicht gut genug sind, werden entweder zu wenig leisten (und die Wettbewerber des Unternehmens werden bei diesen Aufgaben vorausziehen), oder Geschäftsbereiche werden die Richtlinie über dieselben Shadow-Kanäle umgehen. Die Disziplin einer reinen On-Premise-Haltung ist schwerer aufrechtzuerhalten als sie aussieht — insbesondere wenn die externen Frontier-Modelle weiter voranschreiten.

Beide Fehlermodi teilen eine Struktur: Eine Richtlinie, die die Heterogenität unternehmerischer Workflows nicht berücksichtigt, wird in den Workflows umgangen, für die sie nicht passt — und der Umweg ist schwerer zu steuern, als der explizite Pfad gewesen wäre.

8. Die Architektur, zu der das führt

Für die meisten regulierten Unternehmen hat das Deployment, das sich aus der Durcharbeitung dieser Fragen ergibt, einige konsistente Eigenschaften.

Es gibt ein Backend für externe LLMs, zugänglich über eine Transformationsschicht, die die Fälle behandelt, bei denen Datensensibilität es erfordert. Es gibt ein On-Premise-Modell — üblicherweise ein kleineres, gut gewähltes Open-Source-Modell — das Workflows behandelt, bei denen externe Endpunkte nicht infrage kommen. Es gibt eine Routing-Schicht, die richtlinienbasiert entscheidet, welcher Workflow wohin geht. Es gibt ein einheitliches Governance- und Audit-Framework, das beide Pfade abdeckt. Und es gibt die Erkenntnis, dass dies kein abgeschlossener Zustand ist — Workflows wechseln zwischen Pfaden, wenn sich Restriktionen ändern, neue externe Modelle verfügbar werden, neue On-Premise-Leistungsfähigkeiten reifen und sich die eigene Datenstrategie des Unternehmens weiterentwickelt.

LLM Capsule unterstützt beide Pfade als Teil einer einzigen Architektur: Path A routet Workflows über die Transformationsschicht zu einem zugelassenen externen LLM, die Tokenisierung, Strukturerhalt und Wiederherstellung innerhalb der Unternehmensumgebung übernimmt; Path B routet Workflows zu einem lokalen On-Premise-Modell, wenn externe Endpunkte nicht infrage kommen. Dieselbe Transformationsschicht, dasselbe Richtlinien-Framework und dieselbe Governance decken beide Pfade ab. Die Deployment-Entscheidung wird zur Richtlinienwahl pro Workflow — nicht zur Architekturverpflichtung für das gesamte Unternehmen.

Häufig gestellte Fragen

Warum ist die Deployment-Entscheidung nicht einfach extern oder On-Premise?

Weil ein typisches Unternehmen Dutzende von Workflows mit unterschiedlicher Datensensibilität, unterschiedlichen Leistungsanforderungen und unterschiedlichen Restriktionen hat. Marketingtexte und Kundenservice-Tickets sind verschiedene Workflows, auch wenn dieselbe Geschäftseinheit beide verantwortet. Alle als eine Entscheidung zu behandeln führt entweder zur Überabsicherung einfacher Workflows (Betrieb auf interner Infrastruktur, die Aufwand kostet, ohne proportionalen Wert zu liefern) oder zur Unterabsicherung schwieriger Workflows (Senden an externe Endpunkte, weil das die „KI-Strategie" des Unternehmens ist). Die realistische Antwort sind unterschiedliche Entscheidungen für unterschiedliche Workflow-Kategorien.

Worin liegen Stärken und Grenzen externer LLMs?

Externe Frontier-Modelle (GPT-5-Klasse, Claude Opus-Klasse, Gemini Ultra-Klasse) operieren auf einem Leistungsniveau, das kein Unternehmen intern erreichen wird — lange Kontextfenster, komplexes Dokumenten-Schlussfolgern, kontinuierliche Verbesserung ohne Nachtraining. Für Workflows, bei denen Leistungsfähigkeit zählt, ist das eine andere Systemkategorie. Die Grenze liegt darin, dass das Modell auf der Infrastruktur des Anbieters unter dessen vertraglichen Zusicherungen — nicht architektonischen Garantien — läuft. Für Workflows, bei denen Datensensibilität jeden externen Endpunkt unabhängig von Sicherheitsvorkehrungen ausschließt, sind externe LLMs keine Option.

Wann ist On-Premise die richtige Antwort?

Wenn die Restriktion absolut ist — Verteidigung, bestimmte klassifizierte Kategorien, Workflows, bei denen keine Version der Daten das Unternehmen verlassen darf — und der Workflow überschaubar genug ist, dass ein leistungsfähiges kleineres Modell ausreicht. Die Stärken sind real: Datenlokalisierung per Definition gelöst, vollständige Betriebskontrolle, vorhersagbare Latenz. Die Kosten sind ebenfalls real und werden häufig unterschätzt: Leistungsrückstand von zwölf bis achtzehn Monaten gegenüber Frontier-Modellen, kontinuierliche Betriebskosten dominiert durch das Team (mindestens fünf bis zehn Engineers) und Anfälligkeit, wenn externe Frontier-Modelle vorausspringen.

Ist eine hybride Topologie nicht komplexer als die Wahl eines einzigen Pfades?

Nur oberflächlich. Beides zu betreiben ist nicht komplexer, wenn die Workflows, die jeweils eines benötigen, verschiedene Workflows sind — und das sind sie. Die Komplexität des Hybrid-Betriebs liegt in der Routing-Schicht, die entscheidet, welches Modell welchen Workflow erhält. Diese Routing-Schicht ist nicht optional; selbst rein externe oder rein On-Premise-Unternehmen haben eine, sie ist nur trivial. Sobald die Routing-Schicht existiert, ist die Unterstützung zweier Backends inkrementelle Komplexität, keine kategorische. Das Schwierige ist, die Routing-Entscheidung präzise genug zu gestalten, dass Workflows dorthin gelangen, wo sie hingehören — mit durchgesetzter Richtlinie und klarem Audit-Trail.

Wie entscheidet man, welcher Workflow wohin geht?

Jeden Workflow gegen vier Fragen evaluieren. Datensensibilität (der spezifischen Daten, die dieser Workflow benötigt — nicht des Maximums irgendwo im Unternehmen). Leistungsanforderung (erfordert die Aufgabe Frontier-Schlussfolgern, oder reicht ein kleineres Modell aus). Restriktionsstruktur (absolut oder konditional; durch externe Verpflichtungen oder interne Governance getrieben). Toleranz für Leistungseinbußen. Die Antworten gruppieren sich: geringe Sensibilität geht extern, transformierbar mit hohem Leistungsanspruch geht extern mit Transformation, absolute Restriktion mit überschaubarem Workflow geht On-Premise, absolute Restriktion mit hohem Leistungsanspruch ist die schwierigste — heute manchmal nicht vollständig lösbar.

Was läuft bei einem rein externen oder rein On-Premise-Ansatz schief?

Rein externe Unternehmen stoßen auf Workflows, die die Richtlinie nicht erlaubt — entweder erhalten diese Workflows keine KI (und das Unternehmen fällt bei den Aufgaben zurück, bei denen KI am meisten zählt) oder sie erhalten KI über inoffizielle Kanäle. Shadow-KI ist die vorhersehbare Konsequenz. Rein On-Premise-Unternehmen stoßen auf die Leistungslücke; interne Modelle sind für einige Workflows gut genug und für andere nicht — und Geschäftsbereiche umgehen die Richtlinie über dieselben Shadow-Kanäle. Beide Fehlermodi teilen eine Struktur: Eine Richtlinie, die Workflow-Heterogenität nicht berücksichtigt, wird in den nicht passenden Workflows umgangen.

Wie sieht eine funktionierende Hybridarchitektur tatsächlich aus?

Vier Komponenten. Eine einheitliche Integrationsschicht (Workflows rufen diese Schicht auf, nicht die Backends direkt, sodass sie gegenüber Routing-Änderungen abgeschirmt sind). Richtliniengesteuertes Routing (die Entscheidung, wo ein Workflow läuft, ist in einer Richtlinie kodiert — versioniert und auditierbar, nicht im Workflow hart kodiert). Eine Transformationsschicht für den externen Pfad (sensible Elemente werden vor der Übertragung transformiert und bei der Antwort wiederhergestellt, abstrahiert über dem jeweiligen externen Anbieter). Gemeinsame Governance (ein Audit-Protokoll, ein Richtlinien-Framework, ein Zugriffskontrollmodell für beide Pfade einheitlich). Wenn alle vier vorhanden sind, wird der Betriebsort eines Workflows zur Richtlinienentscheidung statt zur Architekturverpflichtung.