Wir haben in den letzten Wochen getestet, wie weit man mit lokal betriebenen AI-Models wirklich kommt. Eine Schweizer Plattform mit über 100'000 sensiblen Anfragen pro Monat als Testfeld. Vergleich gegen die führenden Cloud-Modelle, die erste produktive Umsetzung mit einem Kunden läuft.

In diesem Beitrag steht, welche Modelle wir verglichen haben, was wir aussortiert haben und wann lokale AI keine gute Idee ist.

ai-in-der-schweiz-nutzen

"Eigenes KI-Modell" ist nicht gleich "eigenes KI-Modell". Vier Stufen, vier Welten.

Wenn ein Kunde sagt "wir wollen unser eigenes AI-Model", lohnt es sich, kurz zu klären, was er meint. Es gibt vier Stufen, und sie unterscheiden sich erheblich in Aufwand, Datenschutz und Kontrolle.

Stufe 1: Custom GPT. Ein gut konfigurierter Assistent auf einem fremden Modell wie GPT-4, Claude oder Gemini, mit System-Prompt und Wissensbasis. Schnell aufgesetzt, oft genau richtig für interne Use Cases. Aber: die Daten gehen bei jeder Anfrage an den Anbieter. "Eigenes Modell" stimmt nur in einem sehr weichen Sinn.

Stufe 2: Open-Weight-Modell, gehostet bei einem Cloud-Anbieter. Du wählst Llama, Mistral, Gemma ... und lässt es auf AWS Bedrock, Azure ML oder Vertex AI laufen. EU-Locations sind möglich, alle drei bleiben aber US-Anbieter mit CLOUD-Act-Reichweite. In der Schweiz ohne US-Mutter betreibt Infomaniak diverse Modells. 
Mehr Kontrolle als Stufe 1, aber die Daten verlassen dein Umfeld weiterhin.

Stufe 3: Open-Weight-Modell, selbst betrieben. Das gleiche Modell, aber in einem Rechenzentrum deiner Wahl. On-Premise oder bei einem Schweizer RZ-Partner. Die Daten bleiben dort, wo du sie haben willst. Das meinen wir, wenn wir bei ongoing von "lokalen Modellen" sprechen.

Stufe 4: Fine-Tuning oder Pre-Training. Du nimmst ein bestehendes Modell und trainierst es auf deinen Daten weiter. Im Extremfall trainierst du from scratch. Aufwendig, oft unnötig. Im Mittelstand fast nie der richtige Hebel – es sei denn, du hast einen klar abgegrenzten Fach-Use-Case mit eigenem Vokabular und genug gelabelten Daten, etwa in Medizin, Recht oder technischer Dokumentation. Dann kann Fine-Tuning ein kleineres Modell auf das Niveau eines grösseren heben, bei einem Bruchteil der Inferenzkosten.

Die meisten Anfragen, die wir hören, meinen Stufe 1. Wenn sensible Daten im Spiel sind, empfehlen wir fast immer Stufe 3. Genau zwischen Stufe 1 und Stufe 3 liegt der Punkt, an dem über physische Datenkontrolle entschieden wird.

Warum Datenschutz die eigentliche Frage ist

Bei AI redet die halbe Branche über Performance, Kosten, Modellgrössen, Token-Limits. Bei einem grossen Teil unserer Kunden ist das nicht die erste Frage. Die erste Frage lautet: dürfen meine Daten überhaupt zu einem amerikanischen Cloud-Anbieter?

Wer mit Personendaten, Geschäftsgeheimnissen oder regulierten Daten arbeitet, hat darauf oft eine kurze Antwort. DSG, Branchenregulatorik, interne Compliance, eigene Kundenverträge mit Datenstandort-Klausel. Egal wie sauber der Vertrag mit einem US-Hyperscaler ist, du verlierst die physische Kontrolle. In vielen Fällen ist das schlicht nicht zulässig.

Das ist nicht juristisches Klein-Klein. Das ist die Differenz zwischen "wir können AI einsetzen" und "wir dürfen nicht". Genau hier wird die Diskussion über lokale Modelle ernst.

Der Test: über 100'000 Inserate pro Monat, vier Modelle, ein Ergebnis

Wir haben eine Schweizer Plattform mit über 100'000 Inseraten pro Monat als Testfeld genommen. Im Durchschnitt mehr als zwei Inserate pro Minute, in Peak-Zeiten ein Vielfaches davon, rund um die Uhr. Use Case: automatische Compliance-Prüfung gegen Plattform-Regeln, an einer Stelle, an der Cloud-AI aus Datenschutzgründen nicht in Frage kam.

Die Frage war nicht "wird's günstiger". Die Frage war: liefern lokal betreibbare Modelle die Qualität, die für eine geschäftskritische Anwendung mit sensiblen Daten reicht?

Bewertungskriterien. Output-Qualität, Reasoning-Tiefe, Confidence-Score, Anzahl Anläufe bis sauberes JSON, Latenz und Kosten pro Anfrage. Wenn eines davon nicht stimmt, ist die Pipeline produktionsuntauglich.

Kandidaten. Open-Weight-Seite: Gemma, Llama und Mistral in mehreren Varianten und Grössen. Als Benchmark liessen wir bei jeder Anfrage Haiku und Sonnet mitlaufen. Ein lokales Modell muss sich an den Top-Modellen messen, sonst hat das Setup kein Existenzrecht.

Ergebnis. Im Compliance-Case hat Gemma am robustesten geliefert. Stabilster JSON-Output, konsistente Bewertung, brauchbares Reasoning. Die anderen Open-Weight-Modelle hatten in unserem Setup mehr False Positives oder lieferten Output, der nicht ohne Reparaturen weiterverwendbar war.

Wichtige Einschränkung. Das gilt für diesen Use Case und unser Setup. Für Code-Generierung, lange Kontexte oder mehrsprachige Extraktion können andere Modelle führen. Wer dir sagt, dass ein bestimmtes Modell "das beste" ist, hat seine Hausaufgaben nicht gemacht.

Spannender als der Sieger waren die Records, bei denen die Modelle uneinig waren. Genau diese Fälle führen zur eigentlichen Pointe.

Der eigentliche Hebel: Hybrid statt Modellwahl

Cloud oder lokal ist eine falsche Frage. Die richtige: welche Daten landen wo, und in welchem Zustand verlassen sie überhaupt das Rechenzentrum?

Unser Setup. Jeder eingehende Datensatz wird zuerst vom lokalen Modell geprüft, vollständig im Schweizer Rechenzentrum. Bei klarer Bewertung ist die Sache erledigt. Nur bei niedrigem Confidence-Score wandert der Datensatz weiter an ein grösseres Modell zur Zweitprüfung – aber nicht direkt. Vorher läuft er durch den ongoing Anonymizer, einen lokal betriebenen PII-Filter: er erkennt und ersetzt Personendaten (Namen, Adressen, Kontakte, strukturierte IDs, Geo-Bezüge), bevor der bereinigte Kontext das Schweizer RZ verlässt. Der Filter selbst läuft vollständig lokal, ruft keine externen Services und protokolliert nichts ausser Haus.

Resultat in unserem Compliance-Test: weniger als 5 Prozent der Inserate brauchten den Eskalationsschritt. 95 Prozent der Daten verlassen das Schweizer RZ gar nie. Die restlichen 5 Prozent verlassen es nur anonymisiert. Personendaten bleiben zu jedem Zeitpunkt im eigenen Rechenzentrum.

Wer noch strikter sein will, baut auch den Zweitprüfer lokal. Damit verlassen die Daten das RZ nie – auch nicht anonymisiert. Technisch machbar, aber mit Betriebsaufwand: ein grösseres Modell will gemanagt werden – Hardware-Auslastung, GPU-Scaling, Modell-Updates, Monitoring. Wer mit Ollama oder LM Studio anfängt, merkt schnell, dass produktiver Betrieb mehr ist als ein Container-Start. In diesem Case haben sich die zusätzlichen Kosten nicht gelohnt, weil der Anonymizer den Datenschutz sauber abdeckt. Bei strengeren Compliance-Profilen oder höherem Volumen sieht die Rechnung anders aus.

Das ist der Punkt, an dem die Diskussion aufhört, ein Glaubenskrieg zu sein. AI lässt sich datenschutzkonform einsetzen, wenn die Architektur stimmt.

Hosting: was wir ausprobiert haben, was übrig blieb

Bis zur produktiven Architektur lagen ein paar Versuche dazwischen. Drei Lessons, falls du gerade selbst evaluierst.

1. MacBook Pro mit 32 GB Memory ist genial fürs Prototyping, nicht für Volumen. Lokales Setup in Minuten, schnelle Iteration, keine Cloud-Komplexität. Bei Tests mit tausenden Records ist die Grenze schnell erreicht – die GPU ist der Flaschenhals. Für hunderttausend Anfragen pro Monat reicht ein einzelner Mac nicht. Da geht's an dedizierte Hardware.

2. Cloudflare Tunnel ist ein guter Test-Hack, kein produktives Setup. Den Zugriff von aussen ohne Port-Forwarding zu lösen, ist sauber – kein Aufwand mit klassischer Port-Weiterleitung, keine Sicherheitslücken im eigenen Netz. Aber: Cloudflare ist US-Infrastruktur. Bye bye lokal, bye bye Schweiz, hallo USA. Für Testsetups ohne Echtdaten OK, für produktive Pipelines mit sensiblen Daten ein Widerspruch zum eigenen Anspruch. Beim ersten echten Kunden raus.

3. Eigene Server im eigenen Büro: vergiss es. Strom, Kühlung, Redundanz, Netzwerk, physische Sicherheit. Das gehört in ein Rechenzentrum, betreut von Menschen, die genau das den ganzen Tag machen. Schweizer Anbieter wie Nine haben dafür spezialisierte Angebote, On-Premise beim Kunden ist eine Option, wenn die Vorgaben das verlangen.

Was funktioniert für produktive Setups. MacMini-Stacks für mittlere Workloads. Dedizierte GPU-Hosts in Schweizer Rechenzentren für ernsthaftes Volumen. Welche Variante passt, hängt von Datenmenge, Latenzanforderung, Budget und Compliance ab. Eine Universalantwort gibt es nicht, und wer dir eine verkauft, hat einen Verkaufsdruck und kein Architekturproblem gelöst.

Was wir konstant mitbringen. Datenstandort Schweiz, dreifache ISO-Zertifizierung und Erfahrung mit On-Premise- und Hybrid-Setups, die nach Jahren noch laufen.

Wann lokale Modelle sich nicht lohnen

Wir reden gerne darüber, was funktioniert. Genauso wichtig: wann es nicht passt.

Wenn keine sensiblen Daten im Spiel sind. Marketing-Texte, öffentliche Inhalte, generische Auswertungen. Wenn DSG, Branchenregulatorik oder eigene Kundenverträge keinen Datenstandort verlangen, ist die Diskussion akademisch. Nimm Cloud, fertig. Ausser du hast extreme Mengen an Daten zu verarbeiten.

Wenn Frontier-Reasoning gefragt ist. Komplexe Argumentationsketten, sehr lange Kontexte, hochwertige multimodale Verarbeitung. Da sind die führenden Cloud-Modelle aktuell voraus.

Wenn die Anforderungen unklar sind. Wer ein lokales Setup baut, ohne den Use Case sauber zu kennen, hat am Ende eine teure Hardware-Investition, die das falsche Problem löst. Vorher Discovery, dann Architektur.

Wenn dagegen sensible Daten im Spiel sind und du AI ernsthaft einsetzen willst, dreht sich das Bild. Dann ist “lokal” keine Bastellösung, sondern die Architektur, die das überhaupt erst möglich macht.

Status: vom PoC zum ersten Kunden

Der Proof of Concept steht. Die erste produktive Umsetzung mit einem Kunden ist gestartet. Damit haben wir eine Architektur, die wir für ähnliche Anforderungen reproduzieren können: Unternehmen, die AI einsetzen wollen, und bei denen der Datenschutz nicht verhandelbar ist.

Was offen ist. Bei sehr grossen Datenmengen über lange Zeiträume messen wir noch, wie sich lokale Verarbeitung gegen reine Cloud-Setups schlägt. Das hängt an Hardware-Auslastung, Personalaufwand und Rechenzentrumskosten. Wir messen weiter und zeigen die Ergebnisse in einem späteren Beitrag.

Wenn du AI einsetzen willst, deine Daten aber die Schweiz nicht verlassen dürfen, lass uns reden. Wir machen keine Standardsoftware. Wir bauen Architekturen, die zur Frage passen.

Paavo Schmid
Der Autor /

Paavo Schmid

"Du willst AI einsetzen, aber deine Daten dürfen die Schweiz nicht verlassen? Lass uns Reden!"

✉️ E-Mail schreiben: paavo.schmid@ongoing.ch
🤙 Ruf mich an: +41 41 552 13 53
📝 Schreib mir eine Nachricht:

Im nächsten Schritt fragen wir dich noch nach deiner E-Mail Adresse.

Senden
👋 Hast du Fragen?DSC00547-1723x1724
ongoing Logo
swiss made software
Adresse
ongoing GmbH

Wir schaffen technisch hochstehende digitale Lösungen auf Basis von tiefem User-Verständnis – damit du in der digitalen Welt erfolgreich bist.

Hinterbergstrasse 28
6312 Steinhausen
🤙 +41 41 783 12 70
✉️ info@ongoing.ch
Zertifiziert
ISO 27001ISO 9001ISO 14001