Publiziert: Zuletzt aktualisiert:

Souveräne KI

Souveräne KI: das Modell kommt zu den Daten, nicht die Daten zum Modell

Souveräne KI heisst, offene Modelle auf der eigenen Infrastruktur in der Schweiz oder on premise zu betreiben, statt Daten an eine fremde Cloud zu geben. Das ist die Architektur, die KI und Datensouveränität vereinbar macht.

Viele gehostete KI-Dienste schicken jede Eingabe an eine API eines externen Anbieters. Für eine harmlose Frage ist das egal. Für einen Vertragsentwurf, eine Patientenakte oder die Kundendaten eines Treuhänders ist es ein Datenabfluss, der sich nicht mehr rückgängig machen lässt. Souveräne KI dreht die Richtung um: Das Modell kommt zu den Daten, nicht die Daten zum Modell. Diese Seite beschreibt das Problem, das diese Architektur löst, wie sie aufgebaut ist, was sie kostet, und wo ihre ehrlichen Grenzen liegen. Sie ist der konzeptionelle Anker des KI-Clusters; die übrigen Seiten, von GenAI und RAG bis zu den einzelnen Werkzeugen, spielen denselben Faden aus ihrem jeweiligen Winkel.

Das Souveränitätsproblem

Wer eine KI-API eines US-Anbieters nutzt, trifft drei Abhängigkeiten gleichzeitig, oft ohne sie zu benennen:

  • Daten. Jede Anfrage verlässt das Haus. Wohin sie fliesst, wie lange sie gespeichert bleibt und ob sie ins Training einfliesst, steht in den Geschäftsbedingungen des Anbieters, nicht in den eigenen.
  • Jurisdiktion. Liegen Daten bei einem US-Anbieter, greift der US Cloud Act unabhängig vom physischen Standort des Servers. Ein Rechenzentrum in Zürich, das einem US-Konzern gehört, schützt davor nicht zuverlässig. Verarbeitet das System Personendaten, greift parallel das revidierte Datenschutzgesetz.
  • Vendor Lock-in. Modell, Schnittstelle und Preise gehören dem Anbieter. Eine abgekündigte Modellversion, eine Preiserhöhung oder ein geänderter Nutzungsvertrag treffen direkt, ohne Ausweichweg.

Diese drei Punkte sind der Kern der digitalen Souveränität, übertragen auf KI. Sie sind kein Argument gegen KI, sondern eines für eine bewusste Architektur-Entscheidung darüber, wo Modell und Daten liegen.

Die Self-Hosting-Architektur

Souveräne KI ruht auf zwei Bausteinen: einem Modell, dessen Gewichte offen verfügbar sind, und einer Infrastruktur, die unter eigener Kontrolle steht.

Ein Open-Weights-Modell ist eines, dessen trainierte Gewichte heruntergeladen und lokal betrieben werden dürfen, oft, aber nicht immer, unter einer offenen Lizenz wie Apache 2.0; die Lizenz ist pro Modell zu prüfen. Damit lässt es sich auf eigener Hardware ausführen, ohne dass eine Anfrage je das Netz verlässt. Das europäische Anbieter-Lager liefert hier eine Reihe offener Modelle unter Apache 2.0 (siehe Mistral); das ist relevant, weil offene Lizenz und EU-Jurisdiktion zwei verschiedene Souveränitätsfragen gleichzeitig adressieren.

Auf der Betriebsseite serviert eine Inferenz-Schicht das Modell als API im eigenen Netz. Eine quelloffene Inferenz-Engine wie vLLM übernimmt das effiziente Ausliefern an mehrere gleichzeitige Anfragen; sie ist das souveräne Pendant zur Cloud-API. Davor sitzt eine Oberfläche wie LibreChat, die denselben Zugang bietet wie ein kommerzielles Chat-Frontend, nur gegen das eigene Modell. Wird Wissen aus eigenen Dokumenten gebraucht, kommt GenAI und RAG hinzu, dessen Vektor-Speicher ebenfalls im Haus bleibt.

architecture-beta
    group boundary(cloud)["Schweiz oder on premise"]
    group outside(cloud)["Externe Cloud"]
    service ui(cloud)["Chat Oberfläche"] in boundary
    service inference(server)["Inferenz Engine"] in boundary
    service model(server)["Open Weights Modell"] in boundary
    service rag(database)["RAG Wissensbasis"] in boundary
    service docs(database)["Dokumente und Daten"] in boundary
    service uscloud(cloud)["US Cloud API"] in outside
    ui:R -- L:inference
    inference:R -- L:model
    ui:B -- T:rag
    rag:B -- T:docs
    ui:R -- L:uscloud

Der Kasten ist die Souveränitätsgrenze: Anfrage, Modell, Wissensbasis und Daten liegen alle innerhalb der eigenen Kontrolle. Die gestrichelte Linie nach aussen ist der Pfad, den souveräne KI bewusst nicht beschreitet. Die laufende Beobachtung, welche offenen Modelle für welchen Zweck reif sind, leistet das Tech-Radar und KI-Governance.

Was es kostet, ehrlich gerechnet

Souveränität ist nicht gratis. Wer die Architektur ernsthaft erwägt, rechnet mit drei Posten:

  • Hardware. Brauchbare Inferenz braucht GPUs. Ein einzelnes, mittelgrosses Open-Weights-Modell läuft auf einer einzelnen leistungsfähigen GPU; grössere Modelle oder hohe Gleichzeitigkeit brauchen mehr. Das ist eine Anschaffung oder eine Miete bei einem Schweizer Anbieter, kein Nullbetrag.
  • Betrieb. Ein selbst betriebenes Modell will aktualisiert, überwacht und abgesichert werden. Das ist eine eigene Betriebsdisziplin, die LLMOps und MLOps beschreiben. Wer den Betrieb unterschätzt, verlagert das Risiko nur vom Datenschutz auf die Verfügbarkeit.
  • Qualitäts-Delta. Das ist der ehrlichste Posten. Die grössten geschlossenen Frontier-Modelle führen bei den schwersten Aufgaben, etwa langem Schlussfolgern oder vielsprachigem Code, weiterhin. Offene Modelle haben den Abstand spürbar verkleinert und sind für viele strukturierte, werkzeuggetriebene Aufgaben gut genug; gleichwertig mit dem jeweils stärksten geschlossenen Modell sind die offen verfügbaren in der Spitze aber nicht. Die Frage ist nicht, ob das offene Modell unter den Sprachmodellen das beste ist, sondern ob es für den konkreten Anwendungsfall gut genug ist.

Diese drei Posten gehören zusammen in eine ehrliche Rechnung. Gegen sie stehen der wegfallende Datenabfluss, der fehlende Vendor Lock-in und planbare Kosten statt eines Preises pro Anfrage.

Wann es sich lohnt

Souveräne KI ist kein Selbstzweck und nicht für jeden Anwendungsfall die richtige Wahl. Sie lohnt sich, wenn mindestens einer dieser Punkte zutrifft:

  • Die verarbeiteten Daten sind besonders schützenswert, etwa Personendaten, Mandatsgeheimnis oder Geschäftsgeheimnisse, sodass ein Abfluss in eine fremde Jurisdiktion ausscheidet.
  • Das Volumen ist hoch genug, dass der Preis pro Anfrage einer Cloud-API die fixen Kosten eigener Hardware übersteigt.
  • Vendor Lock-in ist ein reales Risiko, weil das System langfristig laufen soll und eine Abkündigung teuer wäre.
  • Ein konkreter Anwendungsfall, etwa eine interne Wissensbasis, lässt sich mit einem offenen Modell in ausreichender Qualität lösen.

Wo nur gelegentlich harmlose Texte verarbeitet werden und die höchste Modellqualität zählt, kann eine Cloud-API die pragmatischere Wahl bleiben. Die saubere Entscheidung zwischen beiden Wegen, samt der Frage, wer welches Modell auf welchen Daten nutzen darf, klärt die KI-Governance; sobald Modelle autonom in einer Schleife handeln, verschiebt sich der Wirkungsradius weiter, was die Seite zu den KI-Agenten ausführt. Den belegbaren Aufbau einer souveränen Wissensbasis bündelt die KI-Werkbank; ein abgegrenztes Erstprojekt prüft den ersten Schritt.

Referenzen

Verwandte Themen

KI fragen

Diese Links öffnen externe KI-Dienste, die Unterhaltung und deren Inhalt werden dabei an den jeweiligen Anbieter übertragen.