By · Last updated 2026-06-05

Zurück zum BlogTechnisch

Von 6 Wochen DevOps-Hölle zu 3-Tage-Integration...

Healthcare SaaS-Teams verbringen 6 Wochen mit der Bereitstellung von selbstgehostetem Presidio, bevor sie zu einer verwalteten API wechseln.

June 5, 20267 min Lesezeit
managed PII APIPresidio productionPHI anonymizationhealthcare SaaSbuild vs buy

Von sechs Wochen DevOps-Schmerz zur 3-Tage-Integration

Aktualisiert für 2026.

Sechs Wochen. Zwei Ingenieure. Vier gescheiterte Deployments. Ein Healthcare-SaaS-Team investierte all das in eine selbst gehostete Presidio-Umgebung. Dann wechselten sie zu einer verwalteten API. Der Wechsel dauerte 3 Tage.

Das „kostenlos"-Label bei Open-Source-Software ist verlockend. Genauso wie das Versprechen voller Kontrolle. Aber die wahren Kosten zeigen sich in Ingenieurstunden. Nicht in Lizenzgebühren.

Was Presidio-Docs nicht abdecken

Presidio-Docs behandeln das lokale Setup gut. Zwei Docker-Container starten. Den Anonymizer auf den Analyzer zeigen. Auf dem Laptop funktioniert es.

Produktion ist eine andere Geschichte.

Skalierung: Lokales Presidio läuft als einzelne Instanz. Produktion braucht mehrere Instanzen hinter einem Load Balancer, Health Checks und graceful Failure. Die Presidio-Docs geben dazu keine Anleitung. Jedes Team löst es allein.

Speicherverbrauch: spaCy-Modelle werden pro Instanz in den RAM geladen. Das Modell en_core_web_lg allein belegt 741 MB. Unter Speicherdruck fällt die Leistung ab. Dann stürzt der Prozess mit einem Out-of-Memory-Fehler ab. Presidio hat dazu keine eingebaute Anleitung.

Timeouts: Große Dokumente brauchen länger. Produktionscode benötigt konfigurierbare Timeouts, sichere Timeout-Antworten und Retry-Logik. In Presidio ist das nicht dokumentiert.

Modellladen-Fehler: Bei hoher Parallelität versuchen mehrere Worker, dasselbe spaCy-Modell gleichzeitig zu laden. Das ist eine Race Condition. Das Ergebnis sind zufällige 500-Fehler, die schwer zu reproduzieren sind. Presidio-GitHub-Issues dokumentieren das. Die Hauptdokumentation nicht.

Audit-Logs: DSGVO und HIPAA verlangen Audit-Trails für PII-Verarbeitung. Presidio hat kein eingebautes Logging. Jedes Team muss eigene Middleware schreiben.

API-Versionierung: Presidios API hat sich zwischen Versionen geändert. Code für Presidio 2.0 kann Updates für 2.2 und höher benötigen. Version Pinning hilft. Aber es erzeugt seine eigene Wartungslast.

Sechs Wochen eines Healthcare-SaaS-Teams

Dieses Team baute PHI-Anonymisierung in eine Forschungsdatenexport-Pipeline ein.

Woche 1: Sie folgten den Presidio-Docs. Lokale Entwicklung funktionierte. Das Kubernetes-Deployment schlug fehl. Pod-Initialisierung warf Modellladen-Fehler. Das Team jagte Kubernetes-Konfigurationsprobleme.

Woche 2: Kubernetes-Konfiguration war behoben. Modellladen funktionierte manchmal. Unter Lasttests schlugen etwa 15 % der Anfragen mit Modellladen-Timeouts fehl. Sie fügten Retry-Logik hinzu.

Woche 3: Retry-Logik verbarg das Kernproblem, bestand aber Lasttests. Ein Compliance-Review forderte Audit-Logs. Das Team schrieb benutzerdefinierte Logging-Middleware.

Woche 4: Healthcare-Entitätstypen — Patientennummern, Krankenversicherungs-IDs — wurden von Presidio-Defaults nicht erkannt. Das Team schrieb zwei benutzerdefinierte Recognizer.

Woche 5: Sie gingen in Produktion. Ein Speicherleck erschien. spaCy-Modellobjekte sammelten sich anfragenübergreifend an. Das Team führte einen täglichen Pod-Neustart als Workaround ein.

Woche 6: Produktion schlug unter echtem Traffic fehl. Der tägliche Neustart verursachte Servicelücken. Die Ursache war klar: Das Speicherleck erforderte entweder ein größeres App-Redesign oder ein anderes Tool.

Die Überprüfung: Der Engineering-Manager rechnete nach. Sechs Wochen mal zwei Ingenieure ergibt 12 Engineering-Wochen. Das Deployment lief, war aber instabil. Laufende Wartung wurde auf 5 bis 10 Stunden pro Woche geschätzt.

Der Wechsel: Das Team testete die anonym.legal API. PHI-Entitätserkennung funktionierte sofort. Keine benutzerdefinierten Recognizer nötig. SLA-gesicherte Verfügbarkeit. Audit-Logging inklusive. Integration dauerte 3 Tage mit dem bestehenden API-Client-Code.

Der Kostenvergleich:

  • 12 Engineering-Wochen zu US-Marktpreisen: 48.000 bis 72.000 US-Dollar
  • Geschätzte jährliche Wartung für Self-Hosted: 25.000 bis 40.000 US-Dollar
  • anonym.legal Business-Plan: 348 € pro Jahr (ca. 385 US-Dollar)

Die verwaltete API kostet in ihrer ersten Woche weniger, als der Self-Hosted-Aufbau in der ersten Stunde gekostet hat.

Wenn Daten das Netzwerk nicht verlassen dürfen

Manche Healthcare-Teams können keine Daten an externe Dienste senden. Air-Gap-Regeln oder Datensouveränitätsanforderungen blockieren das.

Für diese Fälle bietet die Desktop-Anwendung (anonym.plus) dieselbe Engine in einer lokalen Installation:

  • Gleiche Erkennungs-Engine: Presidio plus XLM-RoBERTa
  • Keine Aufrufe an externe Dienste
  • Batch-Verarbeitung für klinische Notizen und Forschungsdaten
  • Kein Setup außer der Installation
  • Automatisches Modell-Management

Das beseitigt den Haupteinwand gegen verwaltetes SaaS: „Unsere Daten dürfen das Haus nicht verlassen." Und es bewahrt trotzdem die Einfachheit, die verwaltete Tools so wertvoll macht.

Build vs. Buy: Ein einfaches Framework

Wähle eine verwaltete API, wenn:

  • Das Team keine dedizierten Infrastruktur-Ingenieure hat
  • Du in Tagen liefern musst, nicht in Wochen
  • SLA-gesicherte Verfügbarkeit ein Muss ist
  • Der verwaltete Dienst deine Entitätstypen abdeckt
  • Audit-Logs und Compliance-Nachweise inklusive sein sollen

Wähle Self-Hosted, wenn:

  • Vorschriften verbieten, dass Daten das Netzwerk verlassen (prüfe zuerst die Desktop-App)
  • Das Verarbeitungsvolumen Self-Hosted bei Skalierung günstiger macht
  • Du tiefe Anpassungen brauchst, die die API nicht unterstützen kann
  • Du ein Platform-Team hast, das das als einen von vielen verwalteten Diensten behandelt

Wähle die Desktop-Anwendung, wenn:

  • Offline-Verarbeitung erforderlich ist
  • Medizinische Forschungsdaten eine klinische Umgebung nicht verlassen dürfen
  • Finanzdaten geografische Verarbeitungsbeschränkungen haben

Fazit

Sechs Wochen Engineering-Zeit sind kein Presidio-Fehler. Es sind die erwarteten Kosten, jeden produktionsreifen NLP-Dienst selbst zu betreiben. Skalierung, Speicherprobleme, Modellladen-Fehler, Audit-Logs und benutzerdefinierte Entitätsarbeit summieren sich schnell.

Verwaltete APIs tragen diese Kosten. Für PII-Anonymisierung — ein Compliance-Bedarf, kein Produktfeature — gewinnt der verwaltete Weg fast immer beim Gesamtkostenvergleich.

Lies, wie die anonym.legal API PHI-Erkennung handhabt. Sieh vollständige Compliance-Details in unserer Sicherheitsübersicht. Vergleiche Pläne auf unserer Preisseite.

Quellen

  • Ploomber: Presidio Production Deployment Deep Dive — ploomber.io.
  • Microsoft Fabric Community: Presidio mit PySpark — blog.fabric.microsoft.com.
  • Presidio GitHub: Produktions-Deployment-Probleme — github.com/microsoft/presidio/issues.

Bereit, Ihre Daten zu schützen?

Beginnen Sie mit der Anonymisierung von PII mit über 285 Entitätstypen in 48 Sprachen.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.