Warum On-Premise-KI zum sichereren Standard für Enterprise-KI wird

Kostenlose KI ist niemals wirklich kostenlos

Anfang 2026 listete OpenRouter die kostenlose Variante des Step 3.5 Flash von StepFun als Mixture-of-Experts-Modell mit 196 Milliarden Parametern, 11 Milliarden aktiven Parametern, einem Kontextfenster von 256K und kostenloser Preisgestaltung auf. (OpenRouter)

Fu00fcr Entwickler sieht das attraktiv aus. Fu00fcr Unternehmen sollte es eine viel dru00e4ngendere Frage aufwerfen: Wer bezahlt fu00fcr das Inference?

Kostenloses Inference wird mu00f6glicherweise aus Gru00fcnden des Wachstums, der Forschung, des Vertriebs oder des u00d6kosystems subventioniert. Aber das Sicherheitsproblem ist nicht nur das Geschu00e4ftsmodell. Das Problem ist, dass jeder externe KI-Dienst den Vertrauenskreis um Ihre Daten erweitert.

Ein Prompt, der an ein Drittanbietermodell gesendet wird, ist nicht nur u201eTextu201c. Er kann wirtschaftliche Absichten, vertrauliche Kontexte, interne Namenskonventionen, Kundenmetadaten, rechtliche Strategien, Codestrukturen oder betriebliche Details enthalten. Selbst wenn keine offensichtlichen personenbezogenen Daten auftauchen, kann der Prompt dennoch vertrauliche Informationen preisgeben.

Aus diesem Grund kann die Steuerung von Unternehmens-KI nicht nur durch Mitarbeiterschulungen oder Richtlinien zur akzeptablen Nutzung erfolgen. Die Architektur ist entscheidend. Wenn sensible Arbeit von externen KI-Diensten abhu00e4ngt, mu00fcssen die Sicherheitsteams verstehen, wohin Anfragen weitergeleitet werden, wie Daten gespeichert werden, wer Protokolle einsehen kann, welche Unterauftragsverarbeiter beteiligt sind und welche Rechtsordnungen anwendbar sein ku00f6nnen.

Mit privater KI u00e4ndert sich die Pru00e4misse. Das Modell lu00e4uft innerhalb einer Infrastruktur, die das Unternehmen kontrolliert. Der Prompt muss nicht u00fcber eine Inference-Ebene von Drittanbietern gesendet werden. Die Organisation kann das Zugriffsmodell, die Protokollierungsrichtlinie, die Aufbewahrungsrichtlinie und die Netzwerkgrenze selbst definieren.

Das ist das Fundament von Zylon AI Core: lokale LLMs, Dokumentenverarbeitung, Retrieval und GPU-Orchestrierung, die innerhalb der kundenegienen Infrastruktur laufen, ohne dass externe Abhu00e4ngigkeiten erforderlich sind.

Exponierte KI-Systeme sind kein hypothetisches Risiko mehr

Das Risiko beschru00e4nkt sich nicht auf kostenlose Modell-APIs. Das gru00f6u00dfere betriebliche Problem besteht darin, dass KI-Systeme zunehmend wie gewu00f6hnliche Websoftware implementiert werden, oft mit auu00dfergewu00f6hnlichen Privilegien.

Das OpenClaw Exposure Watchboard, das u00f6ffentlich erreichbare, aktive OpenClaw-Instanzen zur defensiven Sensibilisierung auflistet, verzeichnete im Mai 2026 mehr als 800.000 exponierte Instanzen, wobei viele Eintru00e4ge bei grou00dfen Cloud- und Infrastrukturanbietern gehostet wurden. (OpenClaw Exposure Watchboard)

Dies ist von Bedeutung, da KI-Systeme selten leere Hu00fcllen sind. Sie sind oft mit E-Mails, Dateien, Datenbanken, Ticketsystemen, internen Wissensdatenbanken, CRM-Daten und Workflow-Tools verbunden. Wenn ein KI-Agent exponiert ist, sieht ein Angreifer mu00f6glicherweise nicht nur einen Chatbot. Er findet unter Umstu00e4nden ein Einfallstor in den operativen Kontext des Unternehmens.

Der Fall McKinsey Lilli hat dieses Risiko sehr viel konkreter gemacht. The Stack berichtete, dass Forscher exponierte, nicht authentifizierte Endpunkte und eine SQL-Injection-Schwachstelle identifizierten, die McKinseys internes KI-Tool Lilli betrafen. Dies soll zur Offenlegung grou00dfer Mengen an Chat-Protokollen, privaten Dateien und RAG-Dokumentationen gefu00fchrt haben. (The Stack) McKinsey bestu00e4tigte, dass das Unternehmen auf eine Schwachstelle im Zusammenhang mit Lilli aufmerksam gemacht worden war, gab an, dass das Problem innerhalb weniger Stunden behoben wurde, und erklu00e4rte, dass die Untersuchung keine Beweise dafu00fcr erbracht habe, dass der Forscher oder unbefugte Dritte auf Kundendaten oder vertrauliche Kundeninformationen zugegriffen hu00e4tten. (McKinsey & Company)

Die Lehre daraus ist nicht, dass u201eCloud-KI immer unsicher istu201c oder dass u201eKI-Systeme grundlegend fehlerhaft sindu201c. Die Lehre ist praktischer Natur: KI-Anwendungen erben alle klassischen Risiken der Softwaresicherheit und fu00fcgen neue hinzu. Fehlende Authentifizierung, exponierte Endpunkte, mangelhafte Zugriffskontrolle, SQL-Injection, unzureichende Protokollierung und u00fcbermu00e4u00dfig autorisierte Tools werden gefu00e4hrlicher, wenn sie neben internem Wissen und Workflows von Sprachmodellen existieren.

On-Premise-KI beseitigt nicht wie von Zauberhand jedes Sicherheitsrisiko. Sie erfordert immer noch Authentifizierung, Segmentierung, Patching, u00dcberwachung, Zugriffskontrollen und solides Engineering. Aber sie veru00e4ndert das standardmu00e4u00dfige Expositionsmodell.

Eine ordnungsgemu00e4u00df isolierte On-Premise-Bereitstellung muss nicht u00f6ffentlich erreichbar sein. Sie muss keine Inference-Endpunkte fu00fcr das offene Internet exponieren. Sie muss keine Prompts, Embeddings oder abgerufenen Dokumente an einen externen Modellanbieter senden. Die Angriffsflu00e4che wird kleiner, weil die Vertrauensgrenze kleiner ist.

Regulierung dru00e4ngt KI in Richtung Kontrolle, nicht Bequemlichkeit

Der regulatorische Trend ist ebenfalls klar: Von Organisationen wird verlangt, mehr u00fcber ihre Systeme zu wissen, nicht weniger.

Das EU-KI-Gesetz trat im August 2024 in Kraft und fu00fchrt einen risikobasierten Rahmen fu00fcr KI-Systeme ein, einschlieu00dfatlich Verpflichtungen zu Transparenz, Dokumentation, Risikomanagement, Cybersicherheit und menschlicher Aufsicht fu00fcr Hochrisiko-Anwendungsfu00e4lle. Die Vorschriften fu00fcr KI-Modelle mit allgemeinem Verwendungszweck traten im August 2025 in Kraft, wu00e4hrend die breitere Anwendung im Jahr 2026 und daru00fcber hinaus fortgesetzt wird. (Digital Strategy)

NIS2 dru00e4ngt kritische und wichtige Einrichtungen zu einem stu00e4rkeren Risikomanagement im Bereich der Cybersicherheit, zu Kontrollen in der Lieferkette und zur Meldung von Vorfu00e4llen. In der Schweiz mu00fcssen Betreiber kritischer Infrastrukturen Cyberangriffe seit dem 1. April 2025 innerhalb von 24 Stunden nach ihrer Entdeckung dem Bundesamt fu00fcr Cybersicherheit melden. (ncsc.admin.ch) Ab dem 1. Oktober 2025 ku00f6nnen Verstu00f6u00dfe gegen die Meldepflicht mit Geldstrafe von bis zu 100.000 CHF geahndet werden. (ncsc.admin.ch)

Fu00fcr Fu00fchrungskru00e4fte im KI-Bereich ist die Richtung offensichtlich. Compliance lu00e4sst sich immer weniger mit vagen Antworten wie u201eder Anbieter ku00fcmmert sich darumu201c oder u201edas Modell wird irgendwo in der EU gehostetu201c vereinbaren.

Datenresidenz hilft, ist aber nicht dasselbe wie vollstu00e4ndige Kontrolle. Eine Cloud-Region kann einige Bedenken zerstreuen, aber sie entfernt nicht automatisch Unterauftragsverarbeiter, Supportzugriffe, Telemetriepipelines, mandantenfu00e4hige Infrastrukturen, betriebliche Abhu00e4ngigkeiten oder grenzu00fcberschreitende rechtliche Komplexitu00e4t.

On-Premise-KI vereinfacht die Frage. Die Daten bleiben in der Umgebung der Organisation. Die Inference-Ebene bleibt in der Umgebung der Organisation. Die Protokolle, Embeddings, Dateien und Modellinteraktionen ku00f6nnen unter demselben Sicherheits- und Compliance-Modell verwaltet werden wie der Rest des IT-Stacks im Unternehmen.

Aus diesem Grund ist die Plattform von Zylon als kompletter On-Premise-KI-Stack konzipiert: AI Core fu00fcr die Infrastruktur, Workspace fu00fcr Endbenutzer und API Gateway fu00fcr die gesteuerte Integration in Unternehmenssysteme.

Anonymisierung reicht nicht aus

Eine hu00e4ufige Reaktion auf KI-Datenschutzrisiken ist die Anonymisierung. Namen entfernen. E-Mail-Adressen maskieren. Identifikatoren entfernen. Dann den Prompt an ein Cloud-Modell senden.

Das kann in einigen wenigen Fu00e4llen helfen, lu00f6st aber das Problem des Unternehmens nicht.

Man kann die Bedeutung nicht vu00f6llig anonymisieren.

Betrachten Sie Prompts wie:

u201eDer Kunde in Zu00fcrich hat eine Steuernachzahlung von 2,3 Millionen.u201c
u201eDer Patient in Zimmer 412 zeigt Symptome einer seltenen Autoimmunerkrankung.u201c
u201eWir planen, den Konkurrenten bis zum dritten Quartal zu übernehmen.u201c

In diesen Beispielen taucht kein Name auf. Aber in einem realen organisatorischen Kontext kann die Bedeutung dennoch offensichtlich sein. Die Kombination aus Rolle, Standort, Zeitpunkt, geschu00e4ftlichem Ereignis und Domu00e4nendetails kann ausreichen, um die Person, den Kunden, den Patienten, das Geschu00e4ft oder das Projekt zu identifizieren.

Die Stellungnahme 28/2024 des EDSA zu KI-Modellen untermauert das allgemeinere Argument, dass bei KI-Modellen, die mit personenbezogenen Daten trainiert wurden, nicht automatisch in jedem Fall von einer Anonymisierung ausgegangen werden kann. (European Data Protection Board) Sensible Informationen ku00f6nnen auch in Prompts, Ausgaben, abgerufenen Dokumenten, Protokollen und Tool-Aufrufen vorkommen.

Aus diesem Grund sollte Anonymisierung als eine zusu00e4tzliche Ebene und nicht als Fundament betrachtet werden. Sie kann die Gefu00e4hrdung verringern. Sie kann jedoch die architektonische Kontrolle nicht ersetzen.

Die bessere Sicherheitsstrategie besteht darin, unnu00f6tige Exposition von vornherein zu vermeiden. Wenn Prompts und Dokumente die Unternehmensumgebung nie verlassen, mu00fcssen sich die Teams nicht auf eine perfekte Anonymisierung verlassen, um KI nutzbar zu machen.

Das eigentliche Problem ist die vertrauenswu00fcrdige Systembasis (Trusted Computing Base)

In der Sicherheitsarchitektur ist die Trusted Computing Base die Gesamtheit der Komponenten, denen vertraut werden muss, damit ein System sicher bleibt.

Bei Unternehmens-KI umfasst dies mehr als nur das Modell. Es umfasst die Anwendungsebene, den Identity Provider, die Vektordatenbank, den Dateispeicher, die Inference-Laufzeitumgebung, die GPU-Infrastruktur, das Protokollierungssystem, die Observability-Ebene, die Orchestrierungs-Tools, den Cloud-Anbieter, den Modellanbieter, Unterauftragsverarbeiter, Administratoren und Support-Prozesse.

Je gru00f6u00dfer diese vertrauenswu00fcrdige Basis wird, desto schwieriger ist es, Risiken einzuschu00e4tzen.

In einer Cloud-KI-Umgebung muss das Unternehmen seinen eigenen Administratoren, dem Anwendungshersteller, dem Modellanbieter, dem Cloud-Anbieter, den Administratoren des Anbieters, den Betriebswerkzeugen, den Unterauftragsverarbeitern und den fu00fcr sie geltenden Rechtsordnungen vertrauen.

In einer On-Premise-KI-Umgebung kann die vertrauenswu00fcrdige Basis verkleinert werden. Die Organisation benu00f6tigt weiterhin strenge Kontrollen, aber die Ausfu00fchrungsumgebung wird nicht mehr mit einem Drittanbieter fu00fcr Inference geteilt. Daten in Verwendung befinden sich wu00e4hrend der Verarbeitung immer noch im Arbeitsspeicher, wie in jedem KI-System, aber die Umgebung, in der diese Verarbeitung stattfindet, bleibt unter der Kontrolle der Organisation.

Das ist der praktische Sicherheitsvorteil privater KI. Keine Perfektion. Reduzierung.

Weniger externe Abhu00e4ngigkeiten. Weniger Datenpfade. Weniger Parteien mit potenziellem Zugriff. Weniger Orte, an denen Protokolle, Prompts, Embeddings oder abgerufene Dokumente landen ku00f6nnen. Weniger Annahmen, die zutreffen mu00fcssen, damit das System vertrauenswu00fcrdig ist.

Der alte Sicherheitsgrundsatz von Bruce Schneier gilt nach wie vor: Sicherheit ist ein Prozess, kein Produkt. (Schneier on Security) On-Premise-KI eru00fcbrigt den Prozess nicht. Sie erleichtert die Durchsetzung des Prozesses, da die Organisation mehr Kontrolle u00fcber den Stack hat.

Governance muss in der Infrastruktur angesiedelt sein

Viele Unternehmen beginnen mit einer einfachen KI-Richtlinie: Fu00fcgen Sie keine sensiblen Daten in u00f6ffentliche Tools ein.

Das ist ein guter erster Schritt. Fu00fcr die produktive KI im Unternehmen reicht das jedoch nicht aus.

Sobald Teams mit dem Aufbau von KI-Workflows beginnen, muss die Governance technisch durchgesetzt werden. Welche Modelle du00fcrfen verwendet werden? Welche Wissensdatenbanken du00fcrfen abgerufen werden? Welche Teams du00fcrfen auf welche Dokumente zugreifen? Welche Anwendungen du00fcrfen das Modell aufrufen? Welche Prompts und Ausgaben werden protokolliert? Welche Anfragen werden blockiert? Welche Workflows erfordern eine Auditierbarkeit?

Diese Kontrollen ku00f6nnen nicht nur in einem Richtliniendokument existieren. Sie mu00fcssen in der Infrastruktur verankert sein.

Hier kommt es auf die KI-Architektur des Unternehmens an. Ein privates Modell, das auf einem Server lu00e4uft, ist nu00fctzlich, aber kein vollstu00e4ndiges Unternehmenssystem. Teams benu00f6tigen auu00dferdem Identitu00e4ten, Berechtigungen, Audit-Protokolle, Governance fu00fcr das Retrieval, API-Kontrollen, Ratenbegrenzungen, Observability und Integrationsgrenzen.

Das ist die Rolle von Zylon API Gateway. Es bietet Entwicklern einen standardkompatiblen Zugriff auf private KI, wu00e4hrend es Sicherheitsteams Richtlinienkontrollen, Authentifizierung, Autorisierung, Modellzugriffsregeln, Guardrails, Ratenbegrenzungen und Audit-Protokollierung fu00fcr alle Anfragen an die Hand gibt.

Mit anderen Worten: Entwickler erhalten eine nutzbare KI-Infrastruktur, aber keine unkontrollierte Hintertu00fcr am Sicherheitssystem vorbei.

Air-Gapped-KI ist die klarste Version dieses Arguments

Fu00fcr einige Organisationen ist selbst eine private Cloud zu viel Risiko.

Verteidigung, Regierung, kritische Infrastrukturen, Finanzdienstleistungen, das Gesundheitswesen und die hochentwickelte Fertigungsindustrie verfu00fcgen hu00e4ufig u00fcber Umgebungen, in denen externe Abhu00e4ngigkeiten inakzeptabel sind. In diesen Bereichen ist das sicherste KI-System eines, das ohne Internet betrieben werden kann.

Kein u00f6ffentlicher Endpunkt.
Keine Inference-API von Drittanbietern.
Keine externe Telemetrie.
Keine Modellaufrufe, die das Netzwerk verlassen.
Keine Kette von Unterauftragsverarbeitern.
Keine Cloud-Abhu00e4ngigkeit.

Nur die Infrastruktur der Organisation, Daten, Modelle, Benutzer, Kontrollen und ein Audit-Trail.

Das ist nicht fu00fcr jedes Unternehmen die richtige Konfiguration. Aber es ist der klarste Ausdruck des Prinzips der privaten KI: Je sensibler die Arbeit ist, desto mehr Kontrolle benu00f6tigt das Unternehmen u00fcber die KI-Infrastruktur.

Quellen

• OpenRouter: StepFun Step 3.5 Flash Modellseite. (OpenRouter)

• OpenClaw Exposure Watchboard. (OpenClaw Exposure Watchboard)

• The Stack: Bericht zur McKinsey Lilli-Schwachstelle. (The Stack)

• McKinsey-Erklu00e4rung zur Stu00e4rkung der Schutzmau00dfnahmen innerhalb des Lilli-Tools. (McKinsey & Company)

• Europu00e4ische Kommission: u00dcbersicht und Zeitplan zum KI-Gesetz. (Digital Strategy)

• AI Act Service Desk: Pflichten gemu00e4u00df Artikel 53 fu00fcr Anbieter von KI-Modellen mit allgemeinem Verwendungszweck. (AI Act Service Desk)

• Schweizerisches Bundesamt fu00fcr Cybersicherheit: Meldepflicht fu00fcr Cyberangriffe auf kritische Infrastrukturen. (ncsc.admin.ch)

• Schweizerisches Bundesamt fu00fcr Cybersicherheit: Sanktionen bei Verletzung der Meldepflicht. (ncsc.admin.ch)

• Europu00e4ischer Datenschutzausschuss: Stellungnahme 28/2024 zu KI-Modellen und Datenschutz. (European Data Protection Board)

• The Register: Samsung hat Berichten zufolge vertrauliche Informationen u00fcber ChatGPT durchsickern lassen. (theregister)

• Bruce Schneier: Der Prozess der Sicherheit. (Schneier on Security)

Autor: Daniel Gallego Vico, PhD, Mitgru00fcnder & Co-CEO bei Zylon
Veru00f6ffentlicht: 25. Mai 2026
Daniel ist spezialisiert auf sichere KI-Architekturen fu00fcr Unternehmen und verantwortet On-Premise-LLM-Infrastrukturen, Data Governance und skalierbare KI-Systeme fu00fcl regulierte Sektoren wie Finanzen, Gesundheitswesen und Verteidigung.