KI-Datenhoheit LogoKI-DatenhoheitRedaktion
Souveränität & lokale KI

Lokale KI im Unternehmen: Referenzarchitektur für souveränen Betrieb

Souveräner KI-Betrieb ist keine Hardwarefrage, sondern eine Nachweisfrage. Diese Referenzarchitektur zeigt, welche Schichten getrennt geprüft werden, wie groß ein Modell wirklich sein muss und welche neun Artefakte eine Prüfung erwartet.

Fryderyk Pryjma11 Min. Lesezeit
Abstrakte Illustration eines abgeschirmten lokalen Rechenzentrums mit geschützten Datenflüssen

Das Wichtigste auf einen Blick

  • Der Betriebsort entscheidet nicht über die Pflichten, sondern über den Aufwand, sie nachzuweisen.
  • Fünf getrennt prüfbare Schichten — Netz, Modell, Wissen, Anwendung, Beobachtbarkeit — verhindern Lock-in und vereinfachen Audits.
  • Für die meisten internen Anwendungsfälle genügen quantisierte Modelle mit 7 bis 14 Milliarden Parametern.
  • Neun dokumentierte Artefakte decken den Kern einer Prüfung nach NIS2UmsuCG und DSGVO ab.
  • Der häufigste Architekturfehler ist ein Vektorindex ohne Berechtigungsprüfung zur Abfragezeit.

01Warum lokale KI 2026 zur Compliance-Frage wird

Die Debatte über lokale KI wurde lange als Kostenfrage geführt: Cloud-Token gegen eigene GPUs. Mit dem NIS2UmsuCG, der KI-VO und den Nachweispflichten gegenüber dem BSI verschiebt sich die Begründung. Entscheidend ist nicht mehr, wo ein Modell günstiger rechnet, sondern welche Verarbeitung ein Unternehmen im Prüfungsfall lückenlos belegen kann: welche Daten das Netz verlassen haben, wer sie verarbeitet hat, wie lange sie gespeichert wurden und welches Modell in welcher Version eine Ausgabe erzeugt hat.

Eine lokale oder hybride Architektur ist deshalb kein Selbstzweck. Sie ist die einfachste Antwort auf drei Fragen, die in Lieferantenprüfungen, Datenschutz-Folgenabschätzungen und Sicherheitsaudits regelmäßig gestellt werden: Wo liegen die Daten? Wer könnte darauf zugreifen? Und was passiert, wenn der Anbieter morgen nicht mehr verfügbar ist?

02Vier Betriebsmodelle im Vergleich

Zwischen reiner Public-Cloud-API und vollständig getrenntem Air-Gap-Betrieb liegen zwei praxisrelevante Zwischenstufen. Die folgende Gegenüberstellung bewertet sie nach Datenabfluss, Nachweisaufwand und typischer Eignung.

Betriebsmodelle für KI-Workloads aus Compliance-Sicht
ModellDatenabflussNachweisaufwandTypische Eignung
Public-Cloud-APIPrompt und Kontext verlassen das UnternehmenHoch: AVV, Drittlandtransfer, Subprozessorliste, LöschkonzeptNicht-personenbezogene, unkritische Inhalte
Dedizierte Cloud-Instanz (EU)Bleibt beim Anbieter, aber isoliertMittel: Mandantentrennung und Zugriffsprotokolle müssen belegt werdenFachanwendungen ohne besondere Kategorien
On-Premises im eigenen RechenzentrumKein AbflussMittel: eigene Betriebsnachweise, Patch- und ModellversionierungPersonenbezogene Daten, Geschäftsgeheimnisse
Air-Gap / getrenntes SegmentKein Abfluss, kein InternetpfadNiedrig extern, hoch intern: Update-Prozess muss dokumentiert seinKRITIS, Forschung, Produktionsnetze

Die meisten Mittelständler landen bei einer Mischung: ein lokales Modell für alles, was Personenbezug oder Geschäftsgeheimnisse berührt, und eine EU-Instanz für Aufgaben ohne Schutzbedarf. Entscheidend ist, dass die Zuordnung dokumentiert ist und technisch erzwungen wird, nicht nur in einer Richtlinie steht.

03Referenzarchitektur: fünf Schichten, die getrennt geprüft werden

Eine belastbare lokale KI-Architektur lässt sich in fünf Schichten zerlegen. Jede Schicht erzeugt eigene Nachweise und kann unabhängig ausgetauscht werden — das ist zugleich die wirksamste Maßnahme gegen Lock-in.

Schichten einer lokalen KI-Architektur und ihre Nachweise
SchichtFunktionNachweis im Audit
Netz und SegmentierungEigenes VLAN, kein ausgehender Internetpfad für InferenzknotenFirewall-Regelwerk, Netzplan, Segmentierungsnachweis
ModellbetriebInferenz-Server mit versionierten ModellgewichtenModellregister mit Version, Herkunft und Lizenz
Wissensschicht (RAG)Indizierung interner Dokumente mit BerechtigungsfilterBerechtigungsmodell, Indexprotokoll, Löschnachweis
AnwendungsschichtChat, Assistenz, FachintegrationenRollenkonzept, Freigabeprozess, Kennzeichnung nach KI-VO
BeobachtbarkeitProtokollierung von Prompts, Ausgaben und ZugriffenRevisionssichere Logs, Aufbewahrungsfrist, Auswertungsberichte

Der häufigste Fehler liegt in der Wissensschicht: Ein Vektorindex, der ohne Berechtigungsfilter über alle Laufwerke gezogen wird, hebelt jedes Rollenkonzept aus. Die Berechtigung muss zur Abfragezeit ausgewertet werden, nicht nur beim Import.

04Dimensionierung ohne Überinvestition

GPU-Kapazität wird regelmäßig zu großzügig geplant. Für die meisten internen Assistenz- und Dokumentenfälle genügt ein Modell mittlerer Größe mit quantisierten Gewichten; die Last entsteht selten durch Rechenbedarf, sondern durch parallele Sitzungen zur Mittagszeit.

Orientierungswerte für interne Assistenzszenarien
NutzerzahlTypische ModellklasseSpeicherbedarf GPUAnmerkung
bis 507–8 B, quantisiert16–24 GBEin Knoten genügt, Warmhaltung wichtiger als Spitzenleistung
50–2508–14 B48 GB oder zwei KnotenLastverteilung und Warteschlange einplanen
250–100014–32 B2–4 KnotenGetrennte Knoten für Inferenz und Indizierung
über 100032 B und mehrClusterKapazitätsplanung mit gemessenen Spitzenlasten statt Schätzung

05Welche Artefakte eine Prüfung erwartet

Lokaler Betrieb entbindet nicht von Dokumentation — er verlagert sie nach innen. Statt Verträgen mit einem Anbieter müssen eigene Betriebsnachweise vorliegen. Die folgende Liste deckt den Kern dessen ab, was in Prüfungen nach NIS2UmsuCG und in Datenschutz-Folgenabschätzungen verlangt wird.

Mindestdokumentation für den lokalen KI-Betrieb

  • Netzplan mit dem KI-Segment und allen zugelassenen Verbindungen
  • Modellregister: Name, Version, Herkunft, Lizenz, Datum der Inbetriebnahme
  • Berechtigungsmodell der Wissensschicht inklusive Prüfung zur Abfragezeit
  • Protokollierungskonzept mit Aufbewahrungsfrist und Zugriffsbeschränkung
  • Verfahren für Modell- und Sicherheitsupdates inklusive Rückfallweg
  • Kennzeichnung KI-erzeugter Ausgaben gegenüber Beschäftigten und Kunden
  • Rollen- und Freigabeprozess für neue Anwendungsfälle
  • Löschkonzept für Prompts, Ausgaben und Indexdaten
  • Notfallplan bei Ausfall oder Kompromittierung des Inferenzknotens

Wer diese neun Punkte belegen kann, besteht den überwiegenden Teil einer Prüfung — unabhängig davon, welches Modell im Hintergrund läuft.

06Der Weg dorthin: sechs Monate in vier Schritten

Ein Wechsel von Cloud-Diensten zu lokalem Betrieb scheitert selten an der Technik, sondern an der Reihenfolge. Bewährt hat sich ein Vorgehen, das mit der Datenklassifizierung beginnt und die Anwendungsfälle erst danach zuordnet.

Vorgehen in vier Schritten

  • Monat 1: Anwendungsfälle erheben und nach Schutzbedarf klassifizieren
  • Monat 2: Zielarchitektur festlegen, Segment und Hardware beschaffen
  • Monat 3–4: Pilotbetrieb mit einer Fachabteilung, Lastdaten erheben
  • Monat 5–6: Rollout, Dokumentation abschließen, Cloud-Verträge anpassen

Parallel gehört die Anbieterfrage geklärt: Auch lokale Lösungen bringen Zulieferer mit — Hardware, Modellanbieter, Integrationspartner. Für sie gilt dieselbe Lieferantenprüfung wie für jeden Cloud-Dienst.

Häufige Fragen

Ist lokale KI automatisch DSGVO-konform?

Nein. Lokaler Betrieb beseitigt die Fragen des Drittlandtransfers und der Auftragsverarbeitung, ersetzt aber weder Rechtsgrundlage, Zweckbindung, Löschkonzept noch Transparenzpflichten. Er vereinfacht den Nachweis, er ersetzt ihn nicht.

Welche Modellgröße reicht für interne Anwendungsfälle?

Für Dokumentenrecherche, Zusammenfassungen und Entwurfstexte genügen in der Praxis Modelle mit 7 bis 14 Milliarden Parametern in quantisierter Form. Größere Modelle lohnen sich vor allem bei komplexer Argumentation oder mehrsprachigen Fachtexten.

Wie verhält sich lokale KI zu den Pflichten aus der KI-VO?

Die Pflichten richten sich nach dem Anwendungsfall und der Risikoklasse, nicht nach dem Betriebsort. Kennzeichnungs- und Transparenzpflichten gelten für lokal betriebene Systeme genauso. Beim Eigenbetrieb kann das Unternehmen jedoch zusätzlich in die Rolle des Anbieters rutschen.

Was kostet ein lokaler Betrieb im Vergleich zur Cloud?

Bei konstanter Nutzung amortisiert sich eigene Hardware häufig innerhalb von 18 bis 30 Monaten. Bei stark schwankender oder geringer Nutzung bleibt eine EU-Instanz wirtschaftlicher. Entscheidend ist die gemessene Auslastung, nicht der Listenpreis pro Token.

Wie oft müssen lokale Modelle aktualisiert werden?

Sicherheitsupdates der Laufzeitumgebung folgen dem regulären Patch-Prozess. Modellwechsel sollten geplant und dokumentiert erfolgen, mit einem Rückfallweg auf die vorherige Version und einer erneuten Abnahme der betroffenen Anwendungsfälle.

Primärquellen

Weiterführende Artikel