Ein On-Premise-LLM DSG-konform betreiben: wo anfangen
Ihre Daten und Ihre KI in den eigenen Räumlichkeiten zu behalten, ist realistisch geworden. So gehen wir solche Projekte an, welche Entscheide wirklich zählen, und welche Fallstricke wir am häufigsten sehen.
Warum sich die Frage jetzt stellt
Vor zwei Jahren setzte der Betrieb eines brauchbaren Sprachmodells im eigenen Haus eine Hardwareinvestition voraus, die sich kaum rechtfertigen liess. Das ist vorbei. Open-Weights-Modelle haben an Qualität gewonnen, während ihre nutzbare Grösse sank, und ein Server mit einer einzigen professionellen GPU deckt heute die Mehrheit der Unternehmensanwendungen ab.
Drei Beweggründe nennen unsere Kundinnen und Kunden immer wieder: Compliance, Geschäftsgeheimnisse und Kontrolle. Sie wiegen je nach Branche unterschiedlich schwer, und es lohnt sich, sie zu trennen statt sie in einem einzigen Argument zu vermengen.
Was das DSG tatsächlich verlangt
Räumen wir zuerst eine verbreitete Verkürzung aus dem Weg: Das DSG verbietet nicht, Personendaten ins Ausland zu übermitteln, es regelt diese Bekanntgabe. Zulässig ist sie in Staaten, deren Gesetzgebung nach Einschätzung des Bundesrates einen angemessenen Schutz gewährleistet; diese Staaten stehen auf einer offiziellen Liste. Andernfalls braucht es Garantien: Standardvertragsklauseln, verbindliche unternehmensinterne Datenschutzvorschriften oder eine der gesetzlichen Ausnahmen.
Für die Vereinigten Staaten anerkennt die Schweiz seit 2024 das Swiss-U.S. Data Privacy Framework: Ein unter diesem Rahmen zertifiziertes US-Unternehmen gilt als angemessen schützend. Der KI-Anbieter, den Sie erwägen, ist vielleicht zertifiziert. Das will allerdings geprüft, dokumentiert und über die Zeit verfolgt sein, denn die jüngere Geschichte solcher Rahmenwerke zeigt, dass sie nicht ewig halten.
Genau hier gewinnt das Selbst-Hosting. Es macht das Problem nicht leichter lösbar, es lässt es verschwinden. Keine Bekanntgabe ins Ausland, also keine laufend zu pflegende Übermittlungsanalyse und keine Abhängigkeit von der Gültigkeit eines Angemessenheitsrahmens, den Sie nicht kontrollieren.
Was bleibt, sind die Pflichten, die nicht verschwinden: die Bearbeitung im Verzeichnis der Bearbeitungstätigkeiten eintragen, die betroffenen Personen informieren, Aufbewahrungsdauern festlegen und bei hohem Risiko eine Datenschutz-Folgenabschätzung durchführen. Ein Modell im eigenen Haus entbindet von nichts davon.
Das Vorstehende beschreibt unsere Ingenieurspraxis und ersetzt keine Rechtsberatung.
Das Modell wählen: das kleinste, das die Aufgabe löst
Die richtige Frage lautet nicht «welches ist das beste Modell», sondern «welches ist das kleinste Modell, das meine Aufgabe löst». Der Kostenunterschied zwischen beiden Antworten ist erheblich, der von den Nutzenden wahrgenommene Qualitätsunterschied oft gleich null.
Ein Modell mit 8 bis 30 Milliarden Parametern, allenfalls auf 8 oder 4 Bit quantisiert, deckt Extraktion, Klassifikation, Zusammenfassung und Fragen-Antworten auf einem Dokumentenbestand ab. Die gängigen Open-Weights-Familien sind allesamt vertretbare Ausgangspunkte.
Entschieden wird durch Messung auf der eigenen Aufgabe, nie durch die Lektüre einer öffentlichen Rangliste. Ein Modell, das einen allgemeinen Benchmark anführt, kann an Ihrem Fachvokabular scheitern, und der umgekehrte Fall kommt genauso vor.
Die Hardware dimensionieren
Drei Grössen bestimmen die Dimensionierung: die Modellgrösse im Speicher, die Kontextlänge und die Zahl gleichzeitiger Anfragen.
Der benötigte Grafikspeicher entspricht näherungsweise der Parameterzahl multipliziert mit der gewählten Genauigkeit. Ein Modell mit vierzehn Milliarden Parametern in 8 Bit verlangt rund vierzehn Gigabyte, in 4 Bit etwa sieben, hinzu kommt der Attention-Cache, der mit Kontextlänge und Zahl gleichzeitiger Nutzender wächst.
In der Praxis verkraftet ein Server mit einer professionellen GPU mit achtundvierzig Gigabyte ein Modell dieser Klasse für einige Dutzend interne Nutzende problemlos. Klein anfangen, messen, dann wachsen. Umgekehrt kostet es viel und bringt nichts: Eine überdimensionierte GPU macht die Antworten nicht besser.
RAG vor Fine-Tuning
Der Reflex «wir müssen das Modell auf unseren Daten trainieren» ist fast immer verfrüht. Retrieval-Augmented Generation bringt das Fachwissen zum Zeitpunkt der Abfrage ein, statt es in den Gewichten des Modells zu vergraben.
Drei Gründe, damit zu beginnen. Fachwissen ändert sich, und ein Index ist in Minuten aktualisiert, wo ein Nachtraining Tage braucht. Fine-Tuning lernt Fakten nicht zuverlässig, es justiert Stil und Format. Und vor allem erlaubt nur RAG die Quellenangabe, die Voraussetzung für jeden Einsatz in einem regulierten Umfeld.
Behalten Sie Fine-Tuning also den Fällen vor, in denen die Ausgabe ein striktes Format oder einen sehr eigenen Ton einhalten muss, und nie dem Einbringen von Wissen.
Evaluieren vor dem Ausrollen
Das ist der Punkt, an dem KI-Projekte mit Abstand am häufigsten scheitern. Ohne fachlichen Testdatensatz lässt sich nicht feststellen, ob das System schlechter wird, sobald Modell, Prompt, Zerlegung oder Dokumentenbasis wechseln. Und all das wechselt laufend.
Ein brauchbarer Evaluationsdatensatz ist kurz und echt: dreissig bis hundert Fragen der künftigen Nutzenden, die erwartete Antwort und die Stelle im Korpus, die sie belegt. Dazu kommen Fragen, deren Antwort nicht im Korpus steht, um zu prüfen, ob das System zu schweigen weiss.
Die Abnahmekriterien werden vor Projektbeginn beziffert: Anteil korrekter Antworten, Anteil Antworten ohne Quelle, Anteil Enthaltungen bei Fragen ausserhalb des Korpus. Erst dieses Dokument erlaubt die Aussage, das System sei bereit, auf anderer Grundlage als dem Bauchgefühl.
Isolation, Zugriff, Protokollierung
Ein internes Modell ist eine Infrastrukturkomponente wie jede andere und wird auch so behandelt: isoliertes Netz oder Hosting im eigenen Haus, Sicherungen, Überwachung, Versionsverwaltung.
Besondere Aufmerksamkeit verdient die Zugriffskontrolle. Sie muss den Rechten entsprechen, die die Nutzenden auf den Dokumenten ohnehin schon haben. Ein Dokumentenassistent, der Berechtigungen ignoriert, wird zum internen Datenleck, und das ist der häufigste Fehler, den wir in bereits begonnenen Projekten antreffen.
Schliesslich die Protokollierung der Abfragen, mit einer festgelegten und nicht bloss hingenommenen Aufbewahrungsdauer. Abfragen enthalten oft mehr Personendaten als der Korpus selbst.
Validierte Umgebungen und EU AI Act
Für validierte Umgebungen, insbesondere in der Pharma, erfolgt die Qualifizierung im Rahmen von GAMP 5 und Annex 11: Softwarekategorisierung, Spezifikationen, reproduzierbare Tests, Änderungsmanagement. Die nicht deterministische Natur eines Sprachmodells verhindert die Validierung nicht, sie verschiebt den Gegenstand des Nachweises von der Komponente auf das Gesamtsystem und seinen Evaluationsdatensatz.
Sind Ihre Nutzenden oder Kunden in der Europäischen Union, muss das System nach dem EU AI Act klassifiziert werden. Die Mehrheit interner Dokumentenassistenten fällt unter begrenztes Risiko mit Transparenzpflichten. Ein System, das in Rekrutierung, Kreditvergabe oder Bildung eingreift, wechselt in die Kategorie hohes Risiko, mit deutlich umfangreicherer Dokumentation. Diese Einstufung erfolgt am Anfang des Projekts, nicht am Ende.
Die häufigsten Fallstricke
Fünf Fehler wiederholen sich oft genug, um sie aufzuzählen.
- Die Evaluation unterschätzen: ohne fachlichen Testdatensatz lässt sich nicht feststellen, ob das System bei jeder Änderung schlechter wird.
- Die GPU überdimensionieren: klein anfangen, messen, dann wachsen; umgekehrt kostet es viel und bringt nichts.
- Berechtigungen ignorieren: ein Assistent, der aus Dokumenten antwortet, die die Person nicht lesen darf, ist ein Leck und keine Funktion.
- Die Korpusqualität vernachlässigen: RAG auf schlecht erkannten, doppelten oder veralteten Dokumenten liefert falsche und belegte Antworten, was schlimmer ist als gar keine Antwort.
- Den Lebenszyklus vergessen: ein Modell wird aktualisiert, neu bewertet und ersetzt; planen Sie das ab der Architektur ein.
Wo anfangen
Ein Anwendungsfall, ein abgegrenzter Korpus, ein Evaluationsdatensatz, sechs bis zwölf Wochen. Dieses Format erlaubt die Entscheidung, ohne das Unternehmen festzulegen. Überzeugt das Ergebnis, ist die Ausweitung auf weitere Korpora anschliessend weit mehr Datenarbeit als Architektur.
Und der zeitaufwendigste Posten ist nie der vermutete: Es sind Aufbau und Bereinigung des Korpus, nicht die technische Integration.