Wo liegen Ihre Daten – und wo Ihre KI-Modelle? Betriebsmodelle für ein Corporate LLM

Sobald ein Unternehmen ein eigenes KI-System plant, fällt schnell der Satz: „Hauptsache, es läuft nicht in der Cloud." Der Reflex ist verständlich – aber er greift zu kurz. Denn ein Corporate LLM ist kein monolithischer Block, sondern besteht aus zwei Teilen, die sich unabhängig voneinander platzieren lassen: der Wissensbasis (Ihre Dateien und die daraus aufgebaute Vektordatenbank) und den KI-Modellen, die damit arbeiten. „Cloud oder lokal" ist damit nicht falsch – nur nicht genau genug: Entscheidend ist, wo jeder einzelne dieser Teile liegt.

Aus „Cloud oder nicht" wird damit eine präzisere Datenschutz-Frage: An welchen Stellen werden Ihre Daten an KI-Modelle übergeben – und wo stehen diese Modelle? In einem RAG-System geschieht das an zwei klar getrennten Stellen. Erstens beim Aufbau der Wissensbasis – der sogenannten Ingestion-Pipeline, die einmalig (oder laufend) sämtliche Dokumente einliest, in Ausschnitte zerteilt und in die Vektordatenbank überführt. Zweitens bei jeder einzelnen Anfrage – der Query-Pipeline, die eine Frage entgegennimmt, das passende Wissen heraussucht und beantwortet. Jede dieser beiden Pipelines nutzt KI-Modelle, und an jeder kann die Grenze Ihrer Kontrolle verlaufen.

Mit „Grenze Ihrer Kontrolle" ist eine konkrete Linie gemeint: Alles, was auf Infrastruktur läuft, die Sie besitzen oder anmieten und rechtlich verantworten – Ihre Server, Ihre Geräte, Ihr Netz –, liegt innerhalb Ihrer Kontrolle. Sobald Daten diese Linie überschreiten und an einen fremden Dienst übergeben werden (die Server eines Anbieters, oft im Ausland, unter fremder Rechtsordnung), liegen sie außerhalb: Sie können dann technisch nicht mehr erzwingen und rechtlich nicht mehr garantieren, was mit ihnen geschieht – ob sie protokolliert, gespeichert, zum Training genutzt oder von Behörden angefordert werden. Genau diesen Grenzübertritt machen wir in jedem der folgenden Betriebsmodelle sichtbar.

Fachbegriffe wie RAG, Embedding, Datenresidenz, Zero Retention oder AV-Vertrag sind am Ende des Artikels im Glossar kurz erklärt.

1. Die Prämisse: ein Corporate LLM = RAG-System + KI-Modelle

Damit wir über dasselbe reden: Ein Corporate LLM ist kein Sprachmodell, in das man einfach alle Firmendokumente „hineinkippt". Ein unternehmensweites KI-System kann technisch aus vielen Bausteinen bestehen – strukturierten Datenbankabfragen, Agenten und Tools, Workflows, Wissensgraphen, OCR- und Dokumentenparsern, Fine-Tuning, Berechtigungssystemen, Guardrails und Evaluationsmechanismen. In diesem Artikel betrachten wir die derzeit wichtigste Ausprägung: eine RAG-Architektur (Retrieval-Augmented Generation), die kontrolliertes Unternehmenswissen über eine Vektordatenbank mit Embedding- und Generierungsmodellen verbindet. Warum dieser Umweg – warum die Dokumente nicht direkt ins Modell geben? Weil ein Sprachmodell das gesamte Unternehmenswissen aufgrund seiner Menge und Größe gar nicht auf einmal aufnehmen kann.

Warum ein Sprachmodell nicht das ganze Wissen überblickt

Ein Sprachmodell kann pro Anfrage nur eine begrenzte Menge Text gleichzeitig verarbeiten – sein Kontextfenster. Je nach Modell sind das einige tausend bis einige hunderttausend Token (Textbausteine, grob: Wortteile). Das klingt viel, ist aber winzig gegenüber dem Wissen eines Unternehmens, das schnell viele Gigabyte an Dokumenten umfasst. Man kann also unmöglich „alle Handbücher, Verträge, E-Mails, Arbeitsanweisungen, Verordnungen, Betriebshandbücher, Prozessbeschreibungen und normativen Vorgaben" gemeinsam in eine Anfrage packen. Und im trainierten Modell selbst stecken Ihre internen, aktuellen Dokumente ohnehin nicht: Es wurde auf öffentlich verfügbaren Texten trainiert, nicht auf Ihrem Intranet – und sein Wissensstand endet zum Trainingszeitpunkt.

Daraus folgt der Schlüsselloch-Effekt: Das Modell blickt auf Ihr gesamtes Wissen nur durch die schmale Öffnung seines Kontextfensters – so, als schaue es durch ein Schlüsselloch in einen großen Raum – etwa eine ganze Bibliothek. Es sieht ausschließlich das, was ihm für diese eine Anfrage mitgegeben wird; alles andere existiert für das Modell in diesem Moment schlicht nicht.

Und genau hier entsteht das Halluzinieren. Fragt man das Modell nach etwas, dessen Antwort außerhalb des Schlüssellochs liegt (und auch nicht in seinen Trainingsdaten steckte), dann „weiß" es nicht, dass es die Antwort nicht kennt. Ein Sprachmodell ist im Kern darauf gebaut, den wahrscheinlichsten nächsten Text zu erzeugen – nicht, etwas nachzuschlagen. Fehlt die Information, bleibt die Ausgabe deshalb nicht leer: Das Modell füllt die Lücke mit einer statistisch plausibel klingenden, aber womöglich frei erfundenen Antwort. Das Ergebnis wirkt souverän formuliert und ist trotzdem falsch – das ist die eigentliche Gefahr.

Genau hier setzt RAG an. Statt zu hoffen, dass die Antwort „im Modell steckt", oder zu versuchen, alles ins Kontextfenster zu zwängen, sucht ein RAG-System zu jeder einzelnen Frage gezielt die passenden Wissens-Ausschnitte aus der Vektordatenbank heraus und legt nur diese dem Modell als Kontext vor. Das Modell antwortet dann nicht aus vagem „Gedächtnis", sondern auf Basis konkret vorgelegter Fakten – nachvollziehbar und belegbar. Das Schlüsselloch wird also nicht vergrößert, sondern bei jeder Frage mit genau dem richtigen Ausschnitt gefüllt.

Wichtig ist dabei die richtige Erwartung: RAG reduziert Halluzinationen erheblich und ermöglicht nachvollziehbare, quellenbasierte Antworten – es beseitigt sie aber nicht vollständig. Die Qualität hängt weiterhin von der Wissensbasis und der Verarbeitung ab: veraltete oder widersprüchliche Dokumente, fehlerhafte Texterkennung (OCR), ungeeignetes Chunking, unpassende Embeddings, schwaches Retrieval, fehlendes Re-Ranking, falsche Berechtigungen oder eine Fehlinterpretation des gefundenen Kontexts können weiterhin zu falschen Antworten führen. Ein produktives Corporate LLM steht und fällt deshalb mit der Dokumentenaufbereitung, dem Retrieval und einer systematischen Evaluation der Antwortqualität.

Ein solches RAG-System hat zwei Pipelines. Die erste läuft einmalig bzw. laufend im Hintergrund, die zweite bei jeder Anfrage:

Merken Sie sich diese beiden Spuren – Indexierung (Ingestion-Pipeline) und Ausführung (Query-Pipeline). Jede Datenschutz-Betrachtung weiter unten prüft beide Pipelines.

2. Der entscheidende Blick: Wo laufen Ihre KI-Modelle?

In einem Satz: Ein Corporate LLM nutzt nicht ein, sondern zwei KI-Modelle – und beide können an unterschiedlichen Orten laufen. Wer nur das „große" Sprachmodell im Blick hat, übersieht das erste Modell.

Die beiden Modelle sind das Embedding-Modell und das Generierungs-Modell (das eigentliche Sprachmodell). Das Generierungs-Modell kennt jeder – es formuliert die Antwort. Das Embedding-Modell dagegen geht in der Diskussion um „lokale KI" fast immer unter, obwohl es datenschutzrechtlich oft zuerst relevant wird. Es ist selbst ein KI-Modell und wandelt Text in Vektoren (lange Zahlenlisten) um, damit die Vektordatenbank nach Bedeutung statt nach Stichworten suchen kann. Das Embedding-Modell ist an zwei Stellen aktiv:

• Bei der Indexierung: Alle Ihre Dokumente werden in Ausschnitte (Chunks) zerlegt und vollständig durch das Embedding-Modell geschickt. So lässt sich später zu jeder Frage der semantisch ähnlichste Inhalt – das passendste Wissen – gezielt abrufen.
• Bei jeder Ausführung: Auch die Frage, die der Nutzer an die Wissensbasis stellt, muss erst durch dasselbe Embedding-Modell: Sie wird ebenfalls in Vektoren übersetzt, um ihre semantische Ähnlichkeit zu den Inhalten der Wissensbasis zu bestimmen, bevor die Datenbank durchsucht werden kann.

Ein verbreiteter Irrtum ist übrigens, in der Vektordatenbank lägen „nur abstrakte Zahlen". Tatsächlich enthält sie in einer produktiven RAG-Architektur meist deutlich mehr: Originaldokumente oder extrahierte Texte, Textabschnitte (Chunks), Embeddings, Metadaten, Dokument- und Seitenverweise, Berechtigungsinformationen und teils Zusammenfassungen. Und selbst das Embedding schützt nicht: Ein Vektor ist keine sichere Anonymisierung des Originaltexts – aus Embeddings lassen sich Inhalte in relevantem Umfang rekonstruieren. Wer das Embedding an eine fremde Cloud gibt, gibt also faktisch den Inhalt preis, nicht bloß eine harmlose Zahlenliste.

Der entscheidende Punkt gilt für beide Modelle gleichermaßen – jedes lässt sich auf zwei grundsätzlich verschiedene Arten betreiben:

1. Als selbst kontrolliertes Modell: ein Modell, das Sie verantworten – on-premise auf eigener Hardware, self-hosted auf gemieteter Infrastruktur oder als souveräner Managed-Service bzw. Serverless-API in der EU. Entscheidend ist nicht „läuft auf meinem eigenen Server", sondern: Der Betrieb liegt innerhalb Ihrer Kontrolle – und damit bleibt dieser Schritt in Ihrem Kontrollbereich.
2. Als fremde Cloud-API eines Anbieters (etwa die Embedding- oder GPT-Modelle von OpenAI) – dann verlässt schon die Frage, und bei der Indexierung der gesamte Dokumentenbestand, Ihren Kontrollbereich.

Der Clou daran: Beim Embedding geschieht dieser Grenzübertritt bereits, lange bevor das „große" Sprachmodell zur Antwortgenerierung überhaupt ins Spiel kommt – das übersehene erste Datenschutz-Risiko.

Nicht ein Entweder-oder: mehrere Betriebsmodelle

Eigener Betrieb oder externe Cloud klingt zunächst nach einer einfachen Entweder-oder-Entscheidung. Tatsächlich existieren mehrere klar voneinander unterscheidbare Betriebsmodelle, die sich in Kontrolle, Betriebsverantwortung, Kosten und Rechtsordnung unterscheiden. Entscheidend ist letztlich die Frage: Wo endet der eigene Kontrollbereich?

Denn Souveränität entscheidet sich nicht daran, ob Sie eigene Hardware besitzen, sondern daran, wer das Modell betreibt und unter welcher Rechtsordnung. Eine EU-Serverless-API ist insofern wie Strom aus der Steckdose eines deutschen Versorgers: Sie zahlen nach Verbrauch und betreiben kein eigenes Kraftwerk – aber der Anbieter sitzt in Deutschland und unterliegt deutschem Recht. „Pro Nutzung bezahlen" heißt also gerade nicht „Kontrolle abgeben". Erst wenn die API auf einen Server unter fremder Rechtsordnung zeigt – z. B. ein US-Anbieter unter dem US CLOUD Act – überschreiten Ihre Daten die Grenze.

Zwei Arten von Modellen: proprietär oder open-weight

Die Einordnung oben beantwortet, wo ein Modell laufen kann. Aber nicht jedes Modell kann überall laufen – das hängt von einem zweiten Merkmal ab: Sind die Gewichte des Modells (seine trainierten Parameter) geheim oder frei verfügbar?

• Proprietäre Frontier-Modelle – GPT (OpenAI), Claude (Anthropic), Gemini (Google): Die Gewichte sind Betriebsgeheimnis. Diese Modelle lassen sich ausschließlich über die API ihres Herstellers (oder eines lizenzierten Hyperscalers) nutzen – nie selbst betreiben. Sie leben damit zwangsläufig auf fremder Infrastruktur.
• Open-weight Modelle – Llama (Meta), Mistral, Qwen (Alibaba), DeepSeek, Gemma: Die Gewichte sind herunterladbar. Diese Modelle lassen sich überall betreiben, wo Sie Rechenleistung kontrollieren – auf eigener Hardware, gemietet, dediziert beim EU-Anbieter oder als EU-Serverless-API. (Feinheit: „open-weight" heißt frei verfügbare Gewichte – nicht zwingend „open source" mit offengelegten Trainingsdaten.)

Damit wird auch der Begriff „lokal" präzise: Ein lokales Modell ist ein open-weight Modell, das auf Ihrer eigenen Hardware läuft. Jedes lokale Modell ist open-weight – aber nicht jedes open-weight Modell läuft lokal; es kann genauso gut bei einem EU-Anbieter laufen.

Eine Ausnahme gibt es: Die Hyperscaler-Enterprise-Angebote (etwa Azure OpenAI) lassen ein proprietäres Frontier-Modell wählbar in einer EU-Region laufen – allerdings unter US-Betreiber und damit dem US CLOUD Act. Es ist der einzige Weg, ein Frontier-Modell mit EU-Serverstandort zu verbinden, und der Grund, warum diese Kombination orange ist, nicht grün (mehr dazu in Kategorie 3).

Damit ist der Rahmen gesteckt: Ein Corporate LLM nutzt an zwei Stellen KI-Modelle – Embedding und Generierung –, und jedes lässt sich unabhängig platzieren: nach Standort und nach Modelltyp. Die folgenden Abschnitte ordnen die Betriebsmodelle in vier Kategorien ein.

3. Die vier Kategorien der Betriebsmodelle

Bisher ging es nur um den Standort des Modells. Für den Datenschutz zählt aber ein zweiter Ort gleichermaßen – der Standort der Daten (Dokumente und Vektor-DB). Daraus ergeben sich drei zentrale Fragen:

1. Wo liegen die Daten? (Dokumente und Vektor-DB)
2. Wo laufen die KI-Modelle? (Embedding und Generierung)
3. Wer betreibt es – und unter welcher Rechtsordnung? Ein EU-Server eines US-Konzerns unterliegt dem US CLOUD Act, ein EU-Server eines EU-Unternehmens nicht.

Genau genommen sind es zwei Dimensionen – der Standort der Daten und der Standort des Modells. Die dritte Frage, die Rechtsordnung, ist keine eigene Achse, sondern die Bewertung, die für beide gilt und jedem Feld seine Farbe gibt. Beide Achsen tragen dabei dieselbe Skala: im Kontrollbereich (EU-souverän), in einer EU-Region unter einem Betreiber außerhalb der EU oder ganz außerhalb der EU. Denn nicht nur US-Anbieter unterliegen einer anderen Rechtsordnung; Gleiches gilt grundsätzlich für alle Anbieter außerhalb der Europäischen Union.

Trägt man den Standort der Daten gegen den des Modells auf, entsteht eine Matrix. In der Praxis sind nur wenige Felder besetzt – und genau diese besetzten Felder sind die vier Kategorien, in denen sich jedes reale Betriebsmodell wiederfindet:

Die folgenden vier Unterabschnitte gehen die Kategorien der Reihe nach durch – von der geringsten zur höchsten Souveränität – und benennen in jeder die konkreten Betriebsmodelle. In allen Diagrammen gilt dieselbe Bildsprache: eine gestrichelte Grenzlinie trennt „in Ihrer Kontrolle" von „außerhalb"; der Kontext-Pfeil ist grün, solange er im Kontrollbereich bleibt, und wird rot, sobald er die Grenze überschreitet.

3.1 · Kategorie 1 – Öffentliche Chat-KI rot

Der Ausgangspunkt vieler Firmen – und für echte Firmendaten der ungeeignetste. Wichtig zum Verständnis: Hier gibt es in der Regel gar kein aufgebautes RAG-System mit eigener Vektordatenbank. Man lädt Dokumente direkt in ChatGPT, Claude oder Gemini hoch oder kopiert Textpassagen in den Chat. Es existiert keine „Wissensbasis", die Sie kontrollieren – die Datei landet unmittelbar beim Anbieter, wird dort verarbeitet und je nach Tarif fürs Modelltraining verwendet. Daten und Modell liegen komplett beim US-Anbieter.

• Betriebsmodell: direkter Dokumenten-Upload in einen Consumer-Chatdienst (ChatGPT, Claude, Gemini).
• Leistung: maximal – sofortiger Zugriff auf die jeweils stärksten Frontier-Modelle, ohne jeden Einrichtungsaufwand.
• Kosten & Limit: kostenlos oder ca. 20–30 € pro Nutzer und Monat, mit Fair-Use-/Nachrichtenlimits; keine garantierte Kapazität.
• Datenschutz: außerhalb des Souveränitätsstandards für Firmendaten – kein Kontrollbereich; je nach Tarif zusätzlich Training auf Ihren Eingaben. Zu unterscheiden ist zwischen kostenlosen Consumer-Angeboten (oft Training) und bezahlten Business-/Enterprise-Tarifen (meist ohne Training) – Letztere lösen aber weder Datenresidenz noch Behördenzugriff.

3.2 · Kategorie 2 – Daten in der EU, Modell außerhalb der EU rot

Die verbreitetste Profi-Lösung – und ein echter Grenzgänger. Hier halten Sie Vektor-DB und Dokumente self-hosted in der EU, aber das Generierungs-Modell läuft bei einem US-Anbieter. Bei jeder Anfrage wandern Frage und abgerufener Kontext – also genau die relevanten, oft sensiblen Wissens-Ausschnitte – über die Grenze. Im Standardfall stammen Embedding- und Generierungs-Modell vom selben US-Anbieter – dann verlassen Ihre Daten den Kontrollbereich schon beim Embedding: beim Aufbau der Wissensbasis quert der gesamte Dokumentenbestand die Grenze, bei jeder Anfrage die Frage. Datenschutzrechtlich ist das eindeutig rot: Chunks, Frage und Kontext durchlaufen in jedem Fall US-Modelle.

Zwei Betriebsmodelle fallen in diese Kategorie – sie unterscheiden sich nur im Modelltyp, nicht im Datenfluss:

• Proprietäre Frontier-API (OpenAI, Anthropic, Google direkt): Zugriff auf die stärksten Modelle per API, Abrechnung pro Token. Frontier-Qualität, aber der Kontext reist in die USA.
• Managed-Open-Cloud (Groq, Together, Fireworks, OpenRouter, Ollama Cloud): dieselbe Topologie, nur mit offenen Modellen auf fremder – meist US-amerikanischer – GPU. Teils extrem schnell (Groq) und günstiger; datenschutzrechtlich dieselbe rote Zone, da Inferenz und Kontext beim US-Betreiber liegen. Standort und Zero-Retention-Zusagen vorher prüfen.
• Kosten & Limit: reine Nutzungskosten pro Token, elastisch nach oben; die RAG-Infrastruktur (Vektor-DB, Pipeline) betreiben Sie selbst.
• Datenschutz: Grenzübertritt bei jeder Anfrage – außerhalb des Souveränitätsstandards; auch die Zusage, dass Ihre Daten nicht zum Training verwendet werden, ändert nichts daran, dass die Verarbeitung außerhalb der europäischen Rechtsordnung bzw. des europäischen Kontrollbereichs stattfindet.

3.3 · Kategorie 3 – EU-Region, Betreiber außerhalb der EU orange

Die Ausnahme, in der ein proprietäres Frontier-Modell (GPT, Claude, Gemini) auf einem EU-Server läuft. Bei den Hyperscaler-Enterprise-Angeboten – Azure OpenAI, AWS Bedrock, Google Vertex – liegen Modell und Daten in einer EU-Region, ohne Training auf Ihren Daten. Der entscheidende Unterschied zu Kategorie 2: Nicht nur die Daten, auch das Modell bleibt physisch in der EU. Das ist der einzige Weg, ein proprietäres Spitzenmodell mit EU-Serverstandort zu verbinden. Das Restrisiko: Betreiber ist ein US-Konzern (Microsoft, Amazon, Google) – über den US CLOUD Act bleibt ein Zugriff denkbar, auch wenn die Server in der EU stehen. Der CLOUD Act ist dabei nur einer von mehreren rechtlichen Aspekten; daneben zählen ebenso Datenresidenz, Unterauftragnehmer, Logging und Telemetrie, Löschkonzepte und die konkreten vertraglichen Vereinbarungen (siehe Glossar).

• Betriebsmodell: Hyperscaler-Enterprise mit EU-Region (Azure OpenAI, Bedrock, Vertex).
• Leistung: dieselben Frontier-Modelle wie in Kategorie 2 – lediglich in einer anderen Betriebsumgebung (EU-Region), nicht bloß „nahe dran".
• Kosten & Limit: Abrechnung pro Token, Enterprise-Kontingente mit SLA; optional reservierter Durchsatz. Cloud-Enterprise-Vertrag und Governance-Aufwand.
• Datenschutz: Restrisiko CLOUD Act – für gewöhnliche Unternehmensdaten meist gut machbar; bei echtem Berufsgeheimnis die kritische Grenze.

3.4 · Kategorie 4 – Vollständig souverän grün

Die eigentlich interessante Kategorie – und der Grund, warum „souverän" heute kein Verzicht mehr sein muss. Hier liegen Daten und Modell durchgehend im eigenen Kontrollbereich oder bei einem EU-Betreiber unter EU-Recht. Kein Grenzübertritt, an keiner Stelle. Der Preis ist der Verzicht auf die absoluten US-Frontier-Modelle – dafür kommen leistungsstarke open-weight Modelle (Llama, Mistral, Qwen) zum Einsatz.

Innerhalb dieser grünen Zone gibt es vier Betriebsmodelle. Sie erfüllen alle den Souveränitätsstandard, unterscheiden sich aber deutlich in Betriebsaufwand, Kontrolltiefe und Kostenmodell – von „gar keine eigene Hardware" bis „alles im eigenen Serverraum". Eine EU-Serverless-API und ein selbst betriebener Server sind eben nicht dasselbe an Kontrolle, auch wenn beide souverän sind. Es lohnt daher, drei Kontroll-Ebenen zu unterscheiden:

Die folgenden vier Modelle bewegen sich also alle in Ebene 1 oder 2 – nicht jedes Unternehmen braucht eigene GPUs, aber die Kontrolltiefe steigt von der Serverless-API zum eigenen Serverraum:

EU-Serverless-API (Abrechnung pro Token)

Die schlankste Form: Sie schicken Anfragen an eine fertige API und zahlen pro Token – keine reservierte Hardware, kein Mindestvolumen, keine Einrichtung. Beispiele sind Scaleway Generative APIs, der IONOS AI Model Hub und OVHcloud AI Endpoints – allesamt EU-Unternehmen mit Rechenzentren in der EU. Konkret: Über den IONOS AI Model Hub nutzen Sie etwa Llama 3.3 70B per OpenAI-kompatibler API aus einem deutschen Rechenzentrum, mit AV-Vertrag – in der Größenordnung von rund 0,65 € pro Million Token. „Pro Token bezahlen" sagt dabei nichts über die Souveränität: Zeigt die API auf einen EU-Anbieter in einem EU-Rechenzentrum, bleiben Ihre Daten vollständig im Kontrollbereich. Für die meisten Unternehmen – auch Berufsgeheimnisträger – ist das der einfachste zulässige Weg.

EU-Managed, dediziert (reservierte GPU zum Festpreis)

Der EU-Anbieter reserviert eine eigene GPU-Instanz für Sie und betreibt sie – feste, planbare Kapazität statt geteilter Kontingente. Beispiel: Scaleway Managed Inference. Abrechnung nicht pro Token, sondern als Festpreis für die reservierte Hardware; der Betrieb (Einrichtung, Patching, Skalierung) bleibt beim Anbieter. Lohnt sich gegenüber der Serverless-Variante bei hoher, gleichmäßiger Last.

Self-hosted (eigener / gemieteter EU-Server)

Volle Kontrolle durch Eigenbetrieb: Daten, Embedding und Generierungs-Modell laufen auf einer gemieteten GPU-Maschine in einem EU-Rechenzentrum, etwa bei Hetzner. Sie mieten die nackte Maschine und richten alles selbst ein – Betriebssystem, Modell-Server (vLLM, Ollama, TGI), Vektor-DB und RAG-Pipeline. Kein Dritter verarbeitet Ihre Daten. Planbare Fixkosten (GPU-Miete ab einigen hundert Euro/Monat) plus Einrichtungs- und Betriebsaufwand.

On-Premise (offline-fähig)

Die höchste Souveränitätsstufe: alles auf eigener Hardware in den eigenen Räumen, offline und sogar per Air-Gap (physisch vom Internet getrennt) möglich – die Daten verlassen nie Ihr Netz. Ideal für besonders sensible Daten und maximale Kontrolle. Einmalige Anschaffung (von einigen Tausend Euro bis in den sechsstelligen Bereich, siehe Kostenbox), danach nur Strom, Kühlung und Wartung. Die Grenze bildet die Leistung der eigenen Hardware.

Eigene Hardware, dediziert oder serverless – die kaufmännische Entscheidung

Diese drei sind nicht bloß technische Varianten derselben Lösung. Sie unterscheiden sich grundlegend in Eigentum der Hardware, Betriebsverantwortung, Skalierbarkeit, Mindestkosten, Auslastungsrisiko, nötigem Know-how und Abrechnungsmodell. Kurzgefasst:

• Eigene Hardware / selbst betriebener Server: Sie beschaffen oder mieten die GPU-Infrastruktur und betreiben das Modell selbst (Hardware-Dimensionierung, Treiber/CUDA, Inference-Engine wie vLLM, API-Absicherung, Monitoring, Skalierung, Hochverfügbarkeit, Backups, Modellwechsel). Höchste Kontrolle und freie Modellwahl, keine Übermittlung von Prompts an einen Model-as-a-Service-Anbieter – aber hohe Anfangsinvestition, laufender Betrieb und spezialisiertes Know-how.
• Dedizierter Managed-Betrieb: Der Anbieter stellt eine GPU bzw. Modellinstanz exklusiv für Sie bereit (nicht flexibel mit anderen geteilt) und übernimmt Bereitstellung, Inference-Engine, Skalierung innerhalb der gebuchten Kapazität, Monitoring und Updates. Sie erhalten reservierte, planbare Leistung und eine abgegrenzte Kundenumgebung – bei weniger Eigenbetrieb als beim Self-Hosting.
• Serverless API: „Serverless" heißt nicht „ohne Server", sondern nur, dass Sie keinen Server auswählen, reservieren oder betreiben müssen. Sie erhalten einen API-Endpunkt, einen Schlüssel, eine Modellauswahl und eine verbrauchsabhängige Abrechnung (Input-/Output-Token, ggf. Embedding-Token). Der Anbieter übernimmt Infrastruktur, Skalierung, Verfügbarkeit und Betrieb im Hintergrund.

Der entscheidende Unterschied ist die Kostenlogik:

4. Schutzmaßnahmen: kein Betriebsmodell, sondern Technik und Maßnahmen obendrauf

Die folgenden drei Muster sind keine eigenen Betriebsmodelle, sondern technische und organisatorische Maßnahmen, die man über die Kategorien 2 und 3 legt. Ihr Zweck ist nicht, den Standort zu ändern, sondern den Grenzübertritt zu steuern oder datenschutzrechtlich zu entschärfen – nützlich, wenn ein Frontier-Modell fachlich nötig ist, die Daten aber nicht unkontrolliert die Grenze überschreiten sollen. Wichtig: Keine dieser Maßnahmen macht aus einem roten oder orangen Modell ein grünes. Sie senken das Risiko, beseitigen es aber nicht.

Routing nach Sensibilität

Ein vorgeschalteter Klassifizierer bewertet jede Anfrage nach ihrer Sensibilität und leitet sie entsprechend weiter: Enthält die Frage – oder der dazu abgerufene Kontext – personenbezogene oder geschäftskritische Daten, geht sie an ein souveränes Modell aus Kategorie 4; unkritische, allgemeine Anfragen dürfen an ein leistungsstärkeres Cloud-Frontier-Modell. So erhält man Frontier-Qualität für den Alltag und Souveränität dort, wo sie zählt.

Der Preis ist doppelt: mehr technische Komplexität – der Klassifizierer ist selbst eine Fehlerquelle – und eine belastbare Governance-Regel, was überhaupt als „sensibel" gilt. Denn nicht die Technik, sondern die Einstufung entscheidet über jeden einzelnen Grenzübertritt. Eine zu lasche Regel führt sensible Daten unbemerkt hinaus; eine zu strenge verschenkt die Frontier-Qualität. Das Routing ist deshalb die Grundlage für die beiden folgenden Maßnahmen.

Cloud-Burst

Der Normalbetrieb läuft souverän in Kategorie 4; nur rechenintensive Lastspitzen werden vorübergehend in die Cloud ausgelagert, um teure GPU-Dauervorhaltung zu sparen. Der Haken ist derselbe wie bei jeder Cloud-Nutzung: Bei jedem Burst quert die ausgelagerte Anfrage die Grenze.

Deshalb ist Cloud-Burst nur sinnvoll in Verbindung mit dem Routing von oben: Ausgelagert werden dürfen ausschließlich als unkritisch eingestufte Anfragen – sensible Last bleibt auch in der Spitze im Kontrollbereich, notfalls mit etwas längerer Wartezeit. Es geht also nicht um reinen Kapazitätsausgleich, sondern um einen Spitzenausgleich unter Beachtung der Sensibilität: Der Burst steht immer unter dem Vorbehalt der Datenklassifizierung. Unkontrolliert in eine Cloud außerhalb der EU auszulagern wäre genau der Fehler, den die Maßnahme verhindern soll.

Anonymisierungs-/Pseudonymisierungs-Gateway

Ein vorgeschalteter Proxy entfernt oder ersetzt personenbezogene Daten, bevor die Anfrage die Grenze überschreitet – und setzt sie in der Antwort wieder ein. Entscheidend ist dabei der Unterschied zwischen den beiden Verfahren, die oft in einem Atemzug genannt werden:

• Pseudonymisierung ersetzt Klarnamen durch Platzhalter (z. B. „Herr Müller" → „Person A"), die der Proxy in einer Zuordnungstabelle behält. Der Personenbezug ist mit diesem Schlüssel wiederherstellbar – deshalb bleiben pseudonymisierte Daten datenschutzrechtlich weiterhin personenbezogen (die DSGVO gilt vollständig). Der Vorteil: Die Antwort lässt sich korrekt zurückübersetzen („Person A" → „Herr Müller"). Das Risiko wird verlagert, nicht aufgehoben.
• Anonymisierung entfernt den Personenbezug unwiderruflich – es gibt keine Zuordnungstabelle, eine Re-Identifizierung ist ausgeschlossen. Damit fallen die Daten aus der DSGVO heraus, aber die Rückübersetzung der Antwort ist nicht mehr möglich, und häufig leidet die inhaltliche Qualität.

In der Praxis arbeiten diese Gateways fast immer mit Pseudonymisierung, weil nur sie eine brauchbare, personalisierte Antwort zurückliefern kann. So lässt sich ein Frontier-Cloud-Modell nutzen, während die Exposition sensibler Klartext-Daten sinkt. Ein Restrisiko bleibt in jedem Fall: Die Erkennung ist nie perfekt (übersehene Namen, Re-Identifizierung über den Kontext), und der Grenzübertritt wird nur gemildert, nicht beseitigt.

5. Vom Betriebsmodell zum produktiven System

Der Speicherort von Daten und Modellen ist ein wichtiger Baustein – für eine produktiv einsetzbare Unternehmenslösung reicht er allein jedoch nicht aus. Drei weitere Felder, die der Serverstandort nicht abdeckt, entscheiden über die Praxistauglichkeit: Berechtigungen, Protokollierung und Evaluation.

Berechtigungen und Mandantentrennung

Für Unternehmen ist nicht nur relevant, wo die Daten liegen, sondern auch, wer welche Inhalte abrufen darf. Vier Punkte sind entscheidend:

• Bestehende Berechtigungen aus SharePoint, DMS oder Dateiservern müssen übernommen werden – ein RAG-System darf sie nicht aushebeln.
• Die Berechtigungsprüfung muss vor der Übergabe der Textausschnitte an das Sprachmodell erfolgen.
• Ein Nutzer darf dem Modell keinen Kontext zuführen können, auf den er im Ursprungssystem keinen Zugriff besitzt.
• Bei mehreren Kunden müssen Daten, Indizes, Schlüssel, Protokolle und Administrationszugriffe konsequent getrennt werden (Mandantentrennung).

Das ist einer der wichtigsten Qualitätsunterschiede zwischen einem schnellen Prototyp und einer produktiv einsetzbaren Lösung.

Logging, Telemetrie und Aufbewahrung

Der Serverstandort allein beantwortet nicht alle Fragen. Zusätzlich sollte geprüft werden:

• Werden Prompts und Antworten gespeichert – und wie lange?
• Werden Inhalte für Monitoring, Telemetrie oder Missbrauchserkennung protokolliert? Gibt es eine Zero-Retention-Option, bei der Prompts und Antworten nicht gespeichert werden? (Beide Begriffe im Glossar.)
• Wo liegen Protokolle und Backups, und wie werden gelöschte Inhalte aus Backups entfernt?
• Wer kann im Supportfall auf Daten zugreifen, und wer verwaltet die Verschlüsselungsschlüssel?

Evaluation und Modellwahl

Die Gegenüberstellung „stärkstes Frontier-Modell gegen souveränes lokales Modell" greift zu kurz. Für ein Unternehmen zählt nicht das allgemein stärkste, sondern das für den konkreten Prozess am besten geeignete Modell. Bei Aufgaben wie Klassifikation, Extraktion, semantischer Suche, Dokumentenvergleich, Vertragsanalyse oder standardisierter Kommunikation kann ein souverän betriebenes open-weight Modell vollkommen ausreichen – und ist häufig besser kontrollierbar. Entscheidend ist, die Modelle an realen Unternehmensdokumenten und konkreten Aufgaben zu evaluieren.

6. Alle Betriebsmodelle im direkten Vergleich

Die folgende Tabelle stellt die acht Betriebsmodelle nebeneinander, nach Kategorien geordnet. Beim US-Zugriff steht nein für souverän, Restrisiko für einen theoretischen Zugriff (CLOUD Act) und ja für einen realen Grenzübertritt.

↔ Auf schmalen Displays lässt sich die Tabelle horizontal scrollen.

* Alle Preisangaben in dieser Tabelle sind indikative Beispielwerte (Stand 2026) und dienen nur der Größenordnung. Konkrete Kosten hängen von Anbieter, Modell, Konfiguration, Auslastung und Tarif ab und sind im Einzelfall zu prüfen.

Von oben nach unten ergibt sich das eigentliche Ergebnis dieses Artikels – eine Einordnung nach dem Philumio-Souveränitätsstandard. Er beschreibt, in welchem Umfang ein Betriebsmodell die von Philumio definierten Anforderungen an Datenhoheit, europäische Verarbeitung und technische Kontrollierbarkeit erfüllt. Er ist bewusst kein abschließendes Rechtsurteil: Ob ein Einsatz tatsächlich DSGVO-konform ist, hängt immer von der gesamten Verarbeitung ab – Rechtsgrundlage, Zweckbindung und Datenminimierung, Rollenverteilung, Unterauftragnehmer, technische und organisatorische Maßnahmen, Lösch- und Protokollierungskonzepte, bei Berufsgeheimnisträgern zusätzlich berufsrechtliche Anforderungen. Diese Einordnung ersetzt daher keine Prüfung des konkreten Anwendungsfalls.

• grün Erfüllt den Souveränitätsstandard vollständig – grundsätzlich für jede Branche geeignet, auch für Berufsgeheimnisträger (Kategorie 4: On-Premise, Self-hosted, EU-Managed dediziert, EU-Serverless-API). Daten und KI-Modelle bleiben im eigenen Kontrollbereich oder bei einem EU-Betreiber unter EU-Recht. Der entscheidende Punkt: Diese Grenze verläuft nicht erst bei eigener Hardware. Auch die token-basierte EU-Serverless-API (IONOS, Scaleway) gehört vollständig hierher. Für Kanzlei, Steuerberatung oder Arztpraxis ist damit keine eigene GPU zwingend – ein europäischer Anbieter mit AV-Vertrag und Verarbeitung ausschließlich in der EU kann bereits ausreichen. Bis zu dieser Stufe bleibt die Verarbeitung im europäischen Kontrollraum; die konkrete DSGVO-Konformität ist im Einzelfall zu prüfen.
• orange Restrisiko – für viele Unternehmen vertretbar, für Berufsgeheimnisträger die kritische Grenze (Kategorie 3: Hyperscaler-EU, z. B. Azure OpenAI). Daten und Modell liegen in einer EU-Region, der Betreiber ist aber ein US-Konzern: Aufgrund der extraterritorialen Wirkung amerikanischer Herausgabevorschriften (US CLOUD Act) kann ein zusätzliches rechtliches Zugriffsrisiko bestehen – auch dann, wenn die technische Infrastruktur innerhalb der EU liegt. Ein automatischer Behördenzugriff ist damit nicht unterstellt, wohl aber ein Risiko, das in der Bewertung berücksichtigt werden muss. Für gewöhnliche Unternehmensdaten in der Praxis oft vertretbar; bei echtem Berufsgeheimnis ist hier die Linie, an der es im Zweifel nicht mehr trägt.
• rot Außerhalb des Philumio-Souveränitätsstandards (Kategorien 1 und 2: öffentliche Chat-KI, proprietäre Frontier-API, Managed-Open-Cloud): Ihre Daten – zumindest die abgerufenen Wissensausschnitte – werden außerhalb der EU bzw. bei einem Anbieter unter außereuropäischer Rechtsordnung verarbeitet. Philumio setzt für sensible Unternehmensinformationen grundsätzlich keine Modelle ein, bei denen Dokumente, Prompts oder abgerufene Wissensausschnitte außerhalb der EU verarbeitet werden oder der Anbieter einer außereuropäischen Rechtsordnung unterliegt. Und: Die Zusicherung „keine Nutzung fürs Training" (üblich in Enterprise-Verträgen) ist wichtig, reicht für sich allein aber nicht aus, um Souveränität oder Datenschutzkonformität zu beurteilen – Speicherung, Protokollierung, Missbrauchserkennung, Supportzugriffe, Unterauftragnehmer, Datenresidenz und Behördenzugriff bleiben offen. Schutzmaßnahmen wie Pseudonymisierung (Abschnitt 4) mildern das, beseitigen es aber nicht.

Zwei Linien ziehen sich zusätzlich durch die Tabelle. Erstens der Zielkonflikt Souveränität ↔ Spitzenleistung: Absolute Frontier-Qualität sitzt heute noch überwiegend bei US-Anbietern – wer sie zwingend braucht, bezahlt sie mit einem Grenzübertritt (Kategorie 2) oder dem Restrisiko eines US-Betreibers (Kategorie 3). Zweitens das Kostenmodell: Cloud-Varianten rechnen pro Token ab (kein Fixum, aber mitwachsende Kosten), Self-hosting und On-Premise bedeuten Fixkosten (GPU-Miete oder -Kauf plus Betrieb). Ab einer gewissen Nutzungsmenge kippt die Wirtschaftlichkeit zugunsten des Eigenbetriebs.

7. Welches Betriebsmodell passt zu welchem Unternehmen?

Dieser Abschnitt führt von der Technik zur Entscheidung. Wichtig vorab: Die Unternehmensgröße ist selten das zentrale Kriterium – ein kleines Unternehmen kann hochsensible Mandantendaten verarbeiten, ein großes nur öffentlich verfügbare Informationen. Entscheidend sind vielmehr:

• Sensibilität der verarbeiteten Daten,
• regulatorische und berufsrechtliche Anforderungen,
• gewünschte technische Kontrolltiefe,
• Anzahl der Nutzer und erwartete Auslastung,
• Integrationsgrad in bestehende Systeme,
• internes IT- und Security-Know-how,
• Anforderungen an Verfügbarkeit und Reaktionszeit,
• notwendige Modellleistung,
• Wirtschaftlichkeit und Skalierbarkeit,
• Anforderungen an Mandantentrennung und Berechtigungen.

Statt nach Unternehmenstypen ordnen wir daher nach konkreten Ausgangslagen – und benennen in jeder, welche Betriebsmodelle und welche europäischen Anbieter (Hetzner, IONOS, Scaleway, OVHcloud) grundsätzlich infrage kommen. Welche Rolle sie jeweils übernehmen, richtet sich nach der Architektur.

Ausgangslage 1: Schneller, risikoarmer Einstieg

Für Unternehmen, die erste produktive Anwendungsfälle umsetzen, aber keine eigene KI-Infrastruktur betreiben wollen. Passend: eine europäische Serverless-API oder ein europäischer Managed-Service – Verarbeitung ausschließlich in der EU, klarer AV-Vertrag, keine Trainingsnutzung, definierte Speicher- und Löschfristen. Konkret etwa IONOS AI Model Hub, Scaleway Generative APIs oder OVHcloud AI Endpoints, soweit das jeweilige Angebot die Anforderungen erfüllt. Geringer Betriebsaufwand, nutzungsabhängige Kosten, keine GPU-Investition.

Ausgangslage 2: Sensible Daten bei begrenzten IT-Ressourcen

Für Mittelständler mit vertraulichen Dokumenten, Personal-, Vertrags- oder Geschäftsgeheimnissen, die keine eigene GPU-Infrastruktur betreiben können oder wollen. Eine typische Architektur: Dokumente, Vektordatenbank und RAG-Anwendung in einer kundeneigenen Hetzner-, IONOS- oder OVHcloud-Umgebung (getrennte Kundenumgebung, eigene Datenbank, klar geregelte Zugriffe, optional kundeneigene Schlüssel), der Modellzugriff über eine EU-Serverless-API (IONOS, Scaleway, OVHcloud) oder einen dedizierten europäischen Managed-Betrieb. Für viele Philumio-Kunden ist das das realistischste Zielmodell.

Ausgangslage 3: Hohe regulatorische Anforderungen

Für Finanz, Versicherung, Kanzlei, Steuerberatung, Gesundheit oder Unternehmen mit besonders kritischem geistigem Eigentum. Je nach Schutzbedarf reichen die Optionen von der EU-Serverless-API mit verbindlicher EU-Verarbeitung über dedizierten europäischen Managed-Betrieb und isolierte Kundenumgebungen bis zu Self-Hosting oder Betrieb in der kundeneigenen IT. Wichtig: Die EU-Serverless-API ist hier nicht grundsätzlich ausgeschlossen – auch bei hohen Anforderungen kann sie geeignet sein, sofern das konkrete Angebot Datenresidenz, Vertragspartner, Unterauftragnehmer, Protokollierung, Löschung, Zugriffsschutz und Mandantentrennung erfüllt. Erforderlich sind in jedem Fall umfassende Protokollierung, differenzierte Berechtigungen, kontrollierte Unterauftragnehmer, klare Schlüssel- und Löschkonzepte, saubere Mandantentrennung und eine rechtliche wie sicherheitstechnische Einzelfallprüfung. Entscheidend ist also nicht, ob ein Modell serverless bereitgestellt wird, sondern unter welchen technischen, vertraglichen und rechtlichen Bedingungen.

Ausgangslage 4: Maximale technische Kontrolle

Für Unternehmen mit eigener IT-, Security- und Infrastrukturkompetenz und höchsten Anforderungen an Datenhoheit und Unabhängigkeit. Auch hier verschwindet die EU-Serverless-API nicht völlig aus dem Bild – es gibt mehrere Abstufungen:

• Variante A – kontrollierte hybride Architektur: Dokumente, Datenbanken, Vektordatenbank und RAG-Anwendung vollständig in der kundeneigenen Umgebung (z. B. Hetzner, IONOS, OVHcloud); Modellzugriff über eine sorgfältig gewählte EU-Serverless-API, wobei ausschließlich die für die konkrete Anfrage nötigen Kontextausschnitte übertragen werden – optional mit vorgeschalteter Klassifikation, Pseudonymisierung oder Filterung.
• Variante B – dedizierter europäischer Modellbetrieb: kundeneigene Daten- und Anwendungsebene, dedizierte GPU- oder Modellumgebung bei einem europäischen Provider, keine geteilte Serverless-Inferenz, feste Monatskosten.
• Variante C – vollständiges Self-Hosting / On-Premise: eigener dedizierter GPU-Server (z. B. bei Hetzner, IONOS, OVHcloud) oder Betrieb im eigenen Rechenzentrum. Maximale Kontrolle, freie Modellwahl – dafür hohe Investitions- oder Mietkosten, Verantwortung für Updates/Skalierung/Verfügbarkeit und spezialisiertes Personal.

Die Kernaussage: Maximale Kontrolle bedeutet nicht zwingend On-Premise. Auch eine hybride Architektur erreicht ein sehr hohes Kontrollniveau, wenn die zentralen Daten- und Steuerungskomponenten im eigenen Verantwortungsbereich bleiben und nur ein klar begrenzter Modellaufruf über eine europäische Serverless-API erfolgt.

Ausgangslage 5: Unterschiedliche Schutzklassen in einem Unternehmen

Viele Unternehmen brauchen nicht ein Betriebsmodell, sondern eine hybride Architektur, die mehrere souveräne Betriebsformen kombiniert. Wichtig: Auch eine europäische Serverless-API erfüllt den Souveränitätsstandard und ist keineswegs auf unkritische Daten beschränkt – bei EU-Betreiber und Verarbeitung ausschließlich in der EU kann sie dieselben Anforderungen an Datenresidenz und EU-Verarbeitung erfüllen wie eine dedizierte Umgebung. Ob im Einzelfall eine Serverless-API, ein dedizierter Managed-Betrieb oder Self-Hosting bzw. On-Premise zum Einsatz kommt, entscheidet sich daher nach mehreren Faktoren – Wirtschaftlichkeit, Kontrolltiefe, Performance, Integrationsgrad, regulatorische Anforderungen und Governance; der reine Schutzbedarf ist nur einer davon. Eine solche Architektur setzt Datenklassifizierung, policy-basiertes Routing (Abschnitt 4) und klare technische Regeln voraus – und verbindet oft mehrere Infrastrukturen: Hetzner, IONOS oder OVHcloud für Daten-, Vektor- und Anwendungsebene; IONOS AI Model Hub, Scaleway Generative APIs oder OVHcloud AI Endpoints für serverlose Modellaufrufe; dedizierte GPU-Instanzen oder eigene Server für besonders kontroll- oder leistungsintensive Fälle.

Die europäischen Anbieter und ihre Rollen

Dass europäische KI-Infrastruktur kein Zukunftskonzept, sondern heute verfügbar ist, zeigen Anbieter wie Hetzner, IONOS, Scaleway und OVHcloud* – jeweils in unterschiedlicher Rolle. Sie sind nicht pauschal gleichwertig; entscheidend ist, welche Funktion sie in einer Architektur übernehmen:

• Hetzner – Infrastruktur für Anwendung, Datenbank, Dokumentenspeicher, Vektordatenbank sowie eigene oder gemietete GPU-Systeme.
• IONOS – Infrastruktur- und GPU-Anbieter und über den AI Model Hub tokenbasierter Zugriff auf Modelle.
• Scaleway – europäischer Cloud- und KI-Infrastrukturprovider mit serverlosen Generative APIs und dedizierten Modellbereitstellungen.
• OVHcloud – europäische Cloud- und KI-Plattform mit Storage, Compute, GPU-Infrastruktur, AI Deploy und serverlosen AI Endpoints (u. a. Llama, Qwen, DeepSeek).

Bei jedem Angebot gilt: konkrete Produkteigenschaften, verfügbare Modelle, Vertragsbedingungen, Datenstandorte, Speicherregelungen und Preise sind im Einzelfall zu prüfen – sie ändern sich und unterscheiden sich je Tarif.

* Diese Übersicht ist nicht abschließend. Es gibt weitere europäische Infrastruktur- und KI-Anbieter, und das Angebot entwickelt sich laufend weiter – neue Anbieter, Modelle und Produkte kommen hinzu, bestehende ändern sich. Die genannten Namen sind Beispiele für heute verfügbare, in der EU betriebene Optionen, keine Wertung und keine vollständige Marktübersicht.

Zwölf Fragen, die Sie jedem KI-Anbieter stellen sollten

1. Wo werden Dokumente, Prompts und Antworten verarbeitet?
2. Wo laufen Embedding- und Generierungsmodelle?
3. Welches Unternehmen ist der Vertragspartner?
4. Welcher Rechtsordnung unterliegt der Anbieter?
5. Welche Unterauftragnehmer werden eingesetzt?
6. Werden Eingaben, Ausgaben oder Metadaten gespeichert?
7. Werden Kundendaten zu Trainings- oder Verbesserungszwecken verwendet?
8. Welche Lösch-, Backup- und Aufbewahrungsfristen gelten?
9. Wie werden Berechtigungen, Verschlüsselung und Mandantentrennung umgesetzt?
10. Handelt es sich um Serverless, eine dedizierte Kundeninstanz oder selbst betriebene Hardware?
11. Erfolgt die Abrechnung nach Token, nach reservierter Kapazität oder über eine eigene Investition?
12. Können Modelle, Anbieter und Infrastruktur später ohne vollständige Neuentwicklung ausgetauscht werden?

Philumio entwickelt KI-Lösungen für den deutschen Mittelstand, bei denen sensible Unternehmensinformationen innerhalb eines klar definierten europäischen Kontrollraums verbleiben. Wir kombinieren leistungsfähige Modelle mit europäischer Infrastruktur, konsequenter Data Governance, qualifiziertem Unternehmenswissen und einer systematischen Evaluation. Dabei wählen wir nicht das allgemein größte Modell, sondern die für den jeweiligen Anwendungsfall sicherste, leistungsfähigste und wirtschaftlich sinnvollste Architektur.

Je nach Schutzbedarf, Auslastung und gewünschter Kontrolltiefe kann diese Architektur auf einer europäischen Serverless-API, einer dedizierten europäischen Modellumgebung, einer kundeneigenen Cloud oder einem vollständig selbst betriebenen GPU-System basieren. Entscheidend ist nicht ein bestimmter Anbieter, sondern die kontrollierte Kombination aus Datenhaltung, Modellbetrieb, Berechtigungen, Governance und Wirtschaftlichkeit.

Glossar

Die wichtigsten Begriffe aus diesem Artikel, kurz erklärt.

Datenresidenz

Der geografische Ort, an dem Daten physisch gespeichert und verarbeitet werden (z. B. „ausschließlich in Rechenzentren innerhalb der EU"). Sagt für sich allein noch nichts darüber, welcher Rechtsordnung der Betreiber unterliegt.

Datenhoheit (Datensouveränität)

Die tatsächliche Kontrolle darüber, wer unter welchem Recht auf Daten zugreifen kann. Umfasst Datenresidenz, aber auch Betreiber, Rechtsordnung, Unterauftragnehmer und Zugriffsmöglichkeiten – der weitergehende Begriff.

AV-Vertrag (Auftragsverarbeitungsvertrag)

Nach Art. 28 DSGVO vorgeschriebener Vertrag zwischen Verantwortlichem und einem Dienstleister, der in dessen Auftrag personenbezogene Daten verarbeitet. Regelt Zweck, Umfang, Speicherung, Löschung, Unterauftragnehmer und Zugriffe.

Zero Retention (Zero Data Retention)

Zusage eines Anbieters, dass Prompts und Antworten nicht gespeichert werden – weder für Training noch für Monitoring. Reduziert das Risiko, ersetzt aber keine Prüfung von Standort, Betreiber und Rechtsordnung.

Telemetrie

Automatisch erhobene Nutzungs- und Betriebsdaten (Metriken, Logs, Fehlerberichte). Kann – je nach Ausgestaltung – auch Inhalte umfassen; deshalb bei sensiblen Daten explizit zu prüfen.

RAG (Retrieval-Augmented Generation)

Verfahren, bei dem ein Sprachmodell vor der Antwort passende Ausschnitte aus einer eigenen Wissensbasis heraussucht und in den Kontext lädt. Reduziert Halluzinationen und ermöglicht quellenbasierte Antworten.

Embedding / Embedding-Modell

Ein Modell, das Text in Zahlenvektoren übersetzt, die seine Bedeutung abbilden. Grundlage für die semantische Suche in der Vektordatenbank – sowohl beim Indexieren der Dokumente als auch bei jeder Frage.

Vektordatenbank

Spezialisierte Datenbank, die Embedding-Vektoren speichert und nach semantischer Ähnlichkeit durchsuchbar macht. Das „Gedächtnis" eines RAG-Systems.

Frontier-Modell

Ein Sprachmodell an der aktuellen Leistungsspitze (z. B. GPT, Claude, Gemini). Meist proprietär und nur über die API des Herstellers nutzbar.

Proprietär vs. open-weight

Proprietär: Gewichte geheim, nur über die Anbieter-API nutzbar. Open-weight: Gewichte frei herunterladbar (z. B. Llama, Mistral, Qwen), damit auf eigener oder gemieteter Hardware betreibbar – Voraussetzung für vollständige Souveränität.

Serverless API

Modellzugriff über einen fertigen API-Endpunkt mit Abrechnung pro Token, ohne eigene Hardware oder reservierte Kapazität. „Serverless" heißt nicht „ohne Server", sondern nur, dass der Anbieter Infrastruktur und Betrieb übernimmt.

Dedizierter Managed-Betrieb

Der Anbieter reserviert eine Modell- bzw. Hardware-Instanz exklusiv für einen Kunden (nicht mit anderen geteilt) und betreibt sie zum Festpreis. Zwischen Serverless und Self-Hosting.

Self-hosted

Betrieb des Modells auf einer selbst gemieteten oder beschafften Maschine (z. B. Hetzner-GPU-Server), die der Kunde vollständig selbst einrichtet und verwaltet.

On-Premise

Betrieb im eigenen Rechenzentrum bzw. eigenen Netz, offline- und Air-Gap-fähig. Höchste Kontrolltiefe, höchster Eigenaufwand.

Quantisierung

Verfahren, das die Zahlengenauigkeit der Modellgewichte reduziert (z. B. von 16 auf 4 Bit), um Speicherbedarf und Hardware-Anforderungen zu senken – bei meist geringem Qualitätsverlust.

H100 / H200 / B200

Rechenzentrums-Beschleuniger (GPUs) von NVIDIA für KI-Inferenz und -Training. H100 (80 GB) ist der aktuelle Standard, H200 (141 GB) hat mehr Speicher, B200 ist die neuere Spitzengeneration.

vLLM / TGI / Ollama

Software zum Betreiben („Serven") von Sprachmodellen auf eigener Hardware. vLLM und TGI (Text Generation Inference) sind auf hohen Durchsatz ausgelegte Inference-Engines; Ollama ist ein einfach zu bedienender lokaler Modell-Runner.

US CLOUD Act

US-Gesetz (2018), das US-Anbieter verpflichten kann, Daten herauszugeben – auch wenn diese auf Servern außerhalb der USA (etwa in der EU) liegen. Einer von mehreren Gründen, warum EU-Serverstandort und EU-Betreiber nicht dasselbe sind.