Lokale Anonymisierung. Lokales Modell. Nur anonymisierte Daten gehen raus – oder gar keine.
Die anymize-Anonymisierung und unser kleines Modell anymize Spring laufen in deiner eigenen Infrastruktur. Personenbezogene Daten verlassen deinen Standort nie – alle Cloud-spezifischen Compliance-Anforderungen (BSI C5, KRITIS-Cloud-Regelungen, DORA-Drittanbieter-Klauseln) entfallen für den sensiblen Teil, weil anymize in diesem Setup schlicht kein Cloud-Anbieter für personenbezogene Daten ist. Für Banken, Krankenhäuser, Behörden und jede Organisation mit KRITIS-Status oder Cloud-Verbot der maximale Compliance-Standard, den wir anbieten.
Warum On-Premise
Cloud-Hosting bei einem deutschen Anbieter wie Hetzner reicht für 95 % der KI-Anwendungen. Aber es gibt drei Konstellationen, in denen dieser Weg nicht ausreicht:
01 — Gesetzlich
Bestimmte Datenarten dürfen die eigene Infrastruktur per Gesetz oder Berufsrecht nicht in Fremd-Hände – auch nicht bei einem DSGVO-konformen Anbieter. Beispiele: bestimmte Patientendaten in Kliniken mit KRITIS-Einstufung, klassifizierte Behörden-Daten, Finanzdaten unter strengen DORA-Auslegungen.
02 — Vertrauen
Anwaltskanzleien mit besonders sensiblen Mandaten (Wirtschaftsstrafsachen, M&A-Beratung) oder Beratungen mit Staats-Nähe sehen sich zunehmend mit Kunden konfrontiert, die „keine Cloud, auch keine deutsche“ verlangen. On-Premise ist hier keine technische Notwendigkeit, sondern ein Vertrauens-Argument.
03 — Ökonomie
Jede Cloud-Nutzung für personenbezogene Daten zieht Audit-Ketten nach sich: AVV, TOM-Prüfung, C5-Questionnaire, DORA-Drittanbieter-Bewertung. Bei größeren Organisationen kostet das intern Wochen an Arbeit pro Auditzyklus. Eine On-Premise-Lösung hebt diese Anforderungen schlicht auf – nicht weil sie kompensiert werden, sondern weil der Anwendungsbereich wegfällt.
BSI C5 und der Cloud-Rahmen
Der Kern
Regulierungen wie BSI C5 (Cloud Computing Compliance Criteria Catalogue) gelten für Cloud-Anbieter, die personenbezogene Daten verarbeiten. Der Anwendungsbereich ist scharf umrissen: Wer kein Cloud-Anbieter ist oder keine personenbezogenen Daten verarbeitet, fällt aus dem Anwendungsbereich.
Wie anymize das On-Premise auflöst
In deinem Rechenzentrum, deiner eigenen Hardware, deinem Netzwerk.
Unser kleines Sprach-Modell sitzt neben der Anonymisierung und arbeitet auf den anonymisierten Inhalten.
Kein Transfer, kein Export, keine Übermittlung. Die Daten bleiben, wo sie hingehören.
Optional an externe Modelle – mit vollem Kontext dank intelligenter Platzhalter. Oder gar nichts, im reinen Compliance-Modus.
Die Konsequenz ist regulatorisch präzise: anymize ist in diesem Setup kein externer Cloud-Anbieter für personenbezogene Daten. Die entsprechenden Cloud-spezifischen Anforderungen (BSI C5, KRITIS-Cloud-Regelungen, DORA-Drittanbieter-Klauseln) greifen nicht, weil der Anwendungsbereich schlicht nicht erfüllt ist.
Fünf Punkte, die jeder Compliance-Verantwortliche sofort versteht:
Keine BSI-C5-Attestierung nötig, um anymize einzusetzen (wenn On-Premise).
Keine KRITIS-Anzeigepflicht für externe Cloud-Nutzung für die KI-Komponente.
Vereinfachte DORA-Drittanbieter-Bewertung – anymize ist kein kritischer IT-Drittanbieter, weil nicht extern gehostet.
Keine Schrems-II-Transfer-Frage – keine Übermittlung, keine Frage.
Keine Cloud-Folgen-Abschätzung, wie sie die DSK-Orientierungshilfe für Cloud-Nutzung vorsieht.
Wer heute die Compliance-Arbeit eines KI-Projekts vor sich hat, weiß, wie viel das erspart.
Transparenz-Note
„Kein Cloud-Anbieter“ gilt für die Komponente, die bei dir läuft. Support-Zugriff durch anymize (nur auf Anfrage, dokumentiert, auditierbar) ist vertraglich geregelt und zählt nicht als fortlaufende Cloud-Verarbeitung.
Die drei Varianten
Nicht jede Organisation braucht ein eigenes Rechenzentrum. Wir bieten drei Deployment-Varianten, skalierbar vom einzelnen Praxis-Server bis zum großen Behörden-Cluster:
Variante 1
Für kleinere Einheiten: Einzelpraxen, kleine Kanzleien, mittelständische Unternehmen mit spezifischen Anforderungen.
Ein einzelner Server mit ausreichend GPU-Leistung für die Anonymisierungs-Pipeline und optional das Spring-Modell.
Umfang
Anonymisierung + Spring-Modell, geringe Parallelität (typisch bis ~20 gleichzeitige Nutzer), lokale Web-Oberfläche oder API-Zugang für interne Anwendungen.
Variante 2
Für Krankenhäuser, Behörden, Banken, große Kanzleien: Dedizierte Server-Infrastruktur in der eigenen Rechenzentrums-Umgebung.
Hohe Parallelität, Hochverfügbarkeit mit Failover-Knoten, Integration in bestehende Identity-Management-Systeme (Active Directory, LDAP, SAML/OIDC).
Umfang
Vollständiger anymize-Stack on-premise (Anonymisierung, Spring, Chat-Interface, Wissensdatenbanken, Projekte, Artefakt-Management, Audit-Logs), skalierbar, mit SLA-gestütztem Support.
Variante 3
Die interessanteste Variante für viele mittelgroße Organisationen: Anonymisierung und Spring-Modell lokal – aber optional Zugriff auf externe Frontier-Modelle über die anymize-Cloud mit anonymisierten Inhalten.
Sensible Dokumente werden lokal anonymisiert. Für einfache Aufgaben übernimmt Spring vor Ort. Für komplexe Analysen, die absolute Frontier-Qualität verlangen, gehen nur die anonymisierten Platzhalter-Varianten an GPT/Claude/Gemini – zurück in deine lokale Umgebung, de-anonymisiert, mit Originaldaten.
Warum das stark ist
Du bekommst die Qualität internationaler Frontier-Modelle, ohne dass ein einziges personenbezogenes Datum deinen Standort verlässt. Der Cloud-Anbieter-Status greift trotzdem nicht, weil die anonymisierte Pipeline nicht mehr unter „Verarbeitung personenbezogener Daten“ fällt.
Komponenten-Abgrenzung
Anonymisierungs-Pipeline
Alle drei Stufen: Algorithmik, Fine-Tuning-Modell, Prompt-Verifikation.
anymize Spring
Unser kleines Sprach-Modell, explizit on-prem-fähig konzipiert.
Web-Interface
Für Chat-Bedienung, Wissensdatenbanken, Projekte und Artefakte.
REST-API
Für Integration in interne Anwendungen und Workflows.
Audit-Logs und Konfiguration
Admin-Panel mit vollem Zugriff auf Protokolle.
anymize Waterfall und Fountain
Unsere größeren Modelle werden nur in unserer eigenen Inferenz-Infrastruktur betrieben. Sie laufen bei uns in Deutschland; du kannst sie im Hybrid-Setup mit anonymisierten Inhalten nutzen.
Internationale Frontier-Modelle
GPT, Claude, Gemini, Mistral, Perplexity, Kimi – werden von ihren Anbietern betrieben und sind naturgemäß nicht on-prem installierbar. Zugriff erfolgt im Hybrid-Setup über anonymisierte Anfragen.
Was das in der Praxis bedeutet
Reines Compliance-Setup
„Nichts verlässt den Standort“: Anonymisierung + Spring-Modell lokal, keine externen Anfragen.
Hybrid-Setup
„Compliance vorn, Qualität hinten“: Anonymisierung lokal, anonymisierte Anfragen optional an Waterfall/Fountain bei uns oder an internationale Frontier-Modelle.
Beide Pfade sind unter dem gleichen Vertrag möglich – du konfigurierst pro Workspace, welche Modelle freigeschaltet sind.
Anforderungen
Die exakten Hardware-Anforderungen variieren mit Variante und erwarteter Last; hier die typischen Dimensionen als Orientierung:
Kompakt-Deployment
CPU
Moderner Server-Prozessor (z. B. AMD EPYC der aktuellen Generation, 32+ Cores)
RAM
Ab 128 GB
GPU
1× aktuelle Enterprise-GPU für die Anonymisierungs-Modelle und Spring (konkrete Empfehlungen im Sales-Gespräch)
Speicher
2–4 TB NVMe SSD für Modelle und Daten
Netzwerk
Gigabit intern, ausgehend nur falls Hybrid-Setup gewünscht
Enterprise-Deployment
Individuelle Dimensionierung nach parallelen Nutzern, Dokumentvolumen und Hochverfügbarkeits-Anforderungen. Wir begleiten die Kapazitätsplanung im Sales-Zyklus.
Betriebsmodell
Container-basiert
Docker / Kubernetes – integriert in eure bestehende Orchestrierungs-Landschaft.
Identitäts-Integration
Via SAML, OIDC, LDAP, Active Directory.
Updates
Regelmäßig, kontrolliert ausgerollt – kein Auto-Update ohne deine Zustimmung.
Support-Zugriff
Nur auf Anfrage, dokumentiert, auditierbar – kein Remote-Access standardmäßig aktiv.
Für wen
Auch: Arztpraxen mit besonders sensibler Klientel (Suchtmedizin, Psychiatrie, HIV-Spezialisierung) entscheiden sich zunehmend für Kompakt-Deployments – nicht weil sie KRITIS sind, sondern weil ihre Patienten maximale Diskretion erwarten.
Sales-Kontakt
On-Premise-Deployments sind individuelle Projekte – es gibt keinen „Online-Kauf“-Button. Jede Installation wird dimensioniert, geplant und begleitet. Das beginnt mit einem Gespräch, in dem wir die drei entscheidenden Fragen klären:
Welches Datenvolumen und welche Nutzerzahl erwartet ihr?
Welche Infrastruktur steht bereits bereit – und was muss ergänzt werden?
Reicht Kompakt, braucht ihr Enterprise, oder ist Hybrid der richtige Weg?
Danach erstellen wir ein verbindliches Angebot mit Hardware-Empfehlungen, Lizenz-Modell, Support-Paket und Timeline. Typische Projekt-Dauer von Kick-off bis Produktiv-Start: 4–12 Wochen, abhängig von Variante und eurer internen Geschwindigkeit.
Schon im ersten Gespräch bekommt ihr:
TOM-Dokumentation
Vollständiger Security-Questionnaire
Sub-Unternehmer-Liste für den on-prem-Rahmen (deutlich kürzer als im Cloud-Setup)
Häufige Fragen
Anonymisierungs-Pipeline (dreistufig), anymize Spring (unser kleines Sprach-Modell), das Web-Interface für Chat, Wissensdatenbanken, Projekte und Artefakte, sowie die REST-API für eigene Integrationen. Unsere größeren Modelle (Waterfall, Fountain) laufen nicht on-premise – sie sind im Hybrid-Setup über anonymisierte Anfragen erreichbar.
Alle Modelle. Alle Features. Keine Kreditkarte.
Wir sind überzeugt von anymize. Und wir wissen: Bei einem KI-Werkzeug, das Mandanten-, Patienten- oder Mitarbeiter-Daten berührt, reicht ein Demo-Video nicht. Deshalb 14 Tage voller Zugang – alle Modelle, alle Features, keine Kreditkarte. Genug Zeit, um sicher zu sein, bevor du uns vertraust.
Dein KI-Arbeitsplatz wartet.