Vier Betriebsmodelle statt Cloud-oder-lokal

Die Frage «Cloud oder On-Premise?» ist zu grob. Ein Schweizer KMU kann KI mindestens in vier Formen betreiben: als öffentlichen SaaS-Dienst, in einer vertraglich kontrollierten Cloud-Umgebung, bei einem Schweizer Hosting-Anbieter oder auf eigener Infrastruktur. Dazu kommt der Hybridansatz, bei dem Datenklassifizierung und Aufgabe den Ausführungsort bestimmen.

ModellKontrolleBetriebsaufwandTypischer Einsatz
Öffentliche KI-SaaSNiedriger bis mittelNiedrigAllgemeine Texte, Recherche, nicht vertrauliche Inhalte
Verwaltete Private CloudMittel bis hochMittelUnternehmensdaten mit Vertrag, Rollen und Protokollen
Schweizer HostingStandortbezogen hochMittelDatenresidenz und lokaler Vertragspartner sind wichtig
On-PremiseTechnisch hochHochStrenge Vertraulichkeit, Offline-Betrieb, konstante Spezialaufgabe
HybridAufgabenabhängigMittel bis hochSensible Verarbeitung lokal, leistungsintensive Allgemeinaufgaben in der Cloud
Kernaussage: Datenstandort ist nur ein Kontrollpunkt. Ebenso wichtig sind Zugriffsrechte, Protokollierung, Verschlüsselung, Unterauftragsbearbeiter, Modelltraining, Löschung und der Betrieb Ihrer eigenen Systeme.

Was das Schweizer DSG tatsächlich verlangt

Der EDÖB stellt klar: Wer Personendaten an einen Cloud- oder anderen Auftragsbearbeiter auslagert, bleibt verantwortlich. Das Unternehmen muss den Anbieter sorgfältig auswählen, instruieren und soweit nötig überwachen. Bei Bearbeitung im Ausland kommen zusätzliche Prüfungen hinzu.

Das bedeutet nicht, dass Personendaten generell nicht in eine Cloud dürfen. Es bedeutet, dass Zweck, Datenkategorie, Vertrag, Bearbeitungsorte, Unterauftragsbearbeiter und technische Massnahmen vorab geklärt werden müssen. Für besonders schützenswerte Daten oder Berufsgeheimnisse kann die Schwelle deutlich höher liegen. Eine lokale Installation löst diese Fragen nicht automatisch: Sie verschiebt die Verantwortung vollständig zu Ihnen.

Auch «Hosting in der Schweiz» beantwortet nicht jede Frage. Entscheidend ist, welche juristische Person den Dienst betreibt, von wo Administration und Support erfolgen, welche Unterauftragnehmer beteiligt sind und ob der Anbieter die Daten für eigene Zwecke nutzt. Datenresidenz ist wertvoll, aber kein Ersatz für Vertrags- und Berechtigungsprüfung.

Der EDÖB verlangt zudem Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Praktisch heisst das: nur nötige Daten übergeben, sensible Angaben anonymisieren oder pseudonymisieren, Zugriffe begrenzen und Löschfristen durchsetzen. Weitere Grundlagen finden Sie in unserem Beitrag zur KI-Governance nach Schweizer DSG.

Keine Rechtsberatung: Bei Berufsgeheimnissen, besonders schützenswerten Personendaten oder automatisierten Einzelentscheiden sollte die konkrete Architektur rechtlich und datenschutzfachlich geprüft werden.

Die fünf Kriterien für die Architekturentscheidung

1. Datenklasse

Trennen Sie öffentliche Inhalte, interne Betriebsdaten, vertrauliche Kundendaten und besonders schützenswerte Personendaten. Nicht jedes Dokument braucht denselben Schutz. Ohne diese Klassifizierung wird entweder zu viel gesperrt oder zu viel freigegeben.

2. Qualitätsbedarf

Lokale Modelle können Zusammenfassungen, Extraktion, Klassifikation und RAG-Aufgaben gut abdecken. Bei komplexem Schlussfolgern, breiter Mehrsprachigkeit, Bild- und Audioverarbeitung oder sehr langen Kontexten können leistungsfähige Cloud-Modelle überlegen sein. Vergleichen Sie am eigenen Testset, nicht anhand einer Rangliste.

3. Latenz und Verfügbarkeit

Lokale Inferenz kann kurze Wege und Offline-Fähigkeit bieten. Gleichzeitig tragen Sie Strom, Hardwareausfälle, Ersatzteile und Kapazitätsplanung selbst. Ein Cloud-Dienst skaliert einfacher, bleibt aber von Internet, Anbieter und Vertrag abhängig.

4. Betriebsfähigkeit

Ein lokales Modell braucht mehr als eine GPU: Betriebssystem, Modellserver, Authentifizierung, Monitoring, Updates, Backup, Protokollierung und ein Verfahren für Sicherheitslücken. Wenn diese Aufgaben niemandem gehören, ist On-Premise keine Kontrolle, sondern eine unbemerkte Baustelle.

5. Gesamtwirtschaftlichkeit

Vergleichen Sie nicht API-Rechnung gegen Grafikkarte. Rechnen Sie Hardware, Strom, Kühlung, Rack- oder Arbeitsplatz, Ersatz, Administration, Modelltests und Opportunitätskosten. Bei schwankender Nutzung ist Cloud oft günstiger; bei hoher, stabiler Last und strengen Datenanforderungen kann lokal sinnvoll werden.

Was lokale Modelle heute realistisch leisten

Open-Weight-Modelle wie das Schweizer Apertus können lokal oder bei einem kontrollierten Hosting-Partner betrieben werden. Die ursprünglichen Apertus-Modelle wurden unter Apache 2.0 veröffentlicht; neuere Versionen können zusätzliche Nutzungsbedingungen besitzen, die vor dem Einsatz geprüft werden müssen. «Offene Gewichte» bedeutet zudem nicht, dass Trainingsdaten, jede Abhängigkeit oder jedes Einsatzszenario automatisch frei von Pflichten sind.

Der Speicherbedarf wächst mit Modellgrösse, Quantisierung und Kontext. Als Orientierung reicht eine einzelne professionelle GPU von 16 bis 24 GB für kleinere quantisierte Modelle und fokussierte Aufgaben; grössere Modelle oder hohe Parallelität verlangen mehr Speicher oder mehrere Beschleuniger. Diese Aussage ist eine Planungsheuristik, kein Leistungsversprechen. Testen Sie Antwortqualität und Durchsatz auf Ihrer Zielhardware.

Lokale KI eignet sich besonders für:

  • strukturierte Extraktion aus wiederkehrenden Dokumenttypen,
  • semantische Suche und RAG über interne Dokumente,
  • Klassifikation und Vorverarbeitung sensibler Inhalte,
  • Textentwürfe in einer klar begrenzten Fachdomäne,
  • Offline- oder abgeschottete Arbeitsplätze.

Sie eignet sich weniger, wenn seltene Spitzenlasten, ständig wechselnde Spitzenmodelle oder breite multimodale Fähigkeiten benötigt werden und kein Betriebsteam vorhanden ist.

Make-or-buy in CHF

Die folgenden Beträge sind CuonzTech-Planungsschätzungen, keine Marktpreise oder Offerten. Sie dienen dazu, die Kostenträger sichtbar zu machen und müssen für Ihr Projekt mit aktuellen Schweizer Angeboten ersetzt werden.

KostenblockKleiner lokaler PilotProduktiver Betrieb
Hardware einmaligca. CHF 3'000–7'000ca. CHF 10'000–35'000+
Aufbau und Integrationca. 3–8 Personentageca. 10–30 Personentage
Betriebca. 2–6 Stunden/Monatca. 1–4 Personentage/Monat
Cloud-Alternativeverbrauchsabhängigvertraglich oder verbrauchsabhängig

Die Spannweite ist absichtlich gross. Ein einzelner interner Suchassistent ist etwas anderes als ein hochverfügbarer Dienst für hundert Mitarbeitende. Für die Entscheidung sollten Sie Kosten je erfolgreicher Aufgabe messen – inklusive menschlicher Nacharbeit. Die Methode dazu erläutert unser Artikel zur Token-Ökonomie.

Der pragmatische Hybridansatz

Für viele KMU ist eine hybride Architektur die vernünftigste Lösung. Eine lokale Komponente entfernt oder ersetzt Identifikatoren, durchsucht sensible Dokumente oder erzeugt einen sachlichen Auszug. Nur der minimierte, freigegebene Kontext geht an ein leistungsfähiges Cloud-Modell. Die Antwort wird anschliessend wieder im kontrollierten System gespeichert.

Ein mögliches Muster:

  1. Dokument lokal klassifizieren.
  2. Personen- und Mandatsangaben entfernen oder ersetzen.
  3. Nur relevante Textstellen über RAG auswählen.
  4. Minimierten Kontext an das freigegebene Modell senden.
  5. Ausgabe prüfen, protokollieren und im eigenen System ablegen.

Dieser Ansatz reduziert übertragene Daten, ohne bei jeder Aufgabe auf Modellqualität und Skalierbarkeit der Cloud zu verzichten. Er braucht jedoch eine klare Regel, welche Datenklasse welchen Pfad nehmen darf.

Technisch sollte diese Regel nicht nur in einer Richtlinie stehen. Sie gehört in die Anwendung: erlaubte Datenquellen, Filter, Protokolle und Freigabeschritte müssen den vorgesehenen Pfad erzwingen. Sonst entscheidet am Ende jede Person spontan, welche Datei «wohl schon gehen wird» – ein erstaunlich zuverlässiger Weg zu inkonsistenter Governance.

Proof of Concept in sechs Schritten

  1. Einen Fall wählen: klarer Nutzen, begrenzte Dokumentarten, keine automatische Aussenwirkung.
  2. Daten klassifizieren: Eigentümer, Schutzbedarf, Aufbewahrung und zulässige Bearbeitungsorte festhalten.
  3. Testset bauen: 20–50 typische und schwierige Fälle mit erwarteten Ergebnissen.
  4. Drei Varianten testen: freigegebene Cloud, lokales Modell und Hybridfluss.
  5. Messen: Qualität, Latenz, Kosten, Nacharbeit und Betriebsaufwand.
  6. Abbruchkriterien setzen: Mindestqualität, maximales Budget und verbotene Fehler definieren.

Erst wenn der PoC reproduzierbar funktioniert, folgt die Produktionsarchitektur. Ein Notebook mit einer Weboberfläche ist ein Experiment, kein Dienst. Für eine saubere Priorisierung hilft das CuonzTech-Modell der vier Hebel; Architektur- und Governance-Unterstützung finden Sie unter Angebote.

Fazit: Kontrolle muss betrieben werden

Lokale KI ist sinnvoll, wenn Datenanforderungen hoch, Aufgaben stabil und Betriebskompetenz vorhanden sind. Öffentliche oder verwaltete Cloud ist sinnvoll, wenn Modellqualität, Skalierung und geringe Betriebsbelastung überwiegen und die rechtlichen sowie vertraglichen Voraussetzungen stimmen. In vielen Fällen gewinnt der Hybridansatz.

Die beste Architektur ist nicht die mit dem höchsten Datenschutzversprechen, sondern die, deren Datenflüsse erklärt, geprüft und dauerhaft betrieben werden können.

Quellen und Stand