Ehrlicher Vergleich

Warum nicht einfach X nutzen?

Zehn ehrliche Fragen, die ein sicherheitsbewusster Entwickler vor der Einführung von Lucairn stellt. Jede Antwort gibt zu, wann die Alternative die richtige Wahl ist.

Wir konkurrieren nicht über Feature-Checklisten — die altern in Wochen. Wir konkurrieren über eine strukturelle Eigenschaft: Identitätsdaten und KI-Inferenz leben in netzwerkisolierten Sandboxes, und der Pfad zwischen ihnen ist kontrolliert. Wenn Ihr Anwendungsfall diese Eigenschaft nicht braucht, ist die leichtere Option die richtige Antwort. Die folgenden Fragen sagen das aus.

Zuletzt aktualisiert: Mai 2026

01.Warum nicht einfach Microsoft Presidio direkt nutzen?

Ehrliche AntwortWenn Ihr einziger Bedarf Textredaktion auf Anwendungsebene ist, ist Presidio direkt völlig in Ordnung.

Presidio ist genau das, was wir für L2 nutzen — die Named-Entity-Recognition-Schicht des Sanitizers. Die Begründung für Lucairn liegt nicht in der Redaktionsschicht allein. Sie liegt in der architektonischen Trennung zwischen Sandbox A (Identität) und Sandbox B (Inferenz), in der ID Bridge mit auditierter Re-Linkage-Governance und in der signierten Zertifikatskette, die jeden Aufruf unabhängig verifizierbar macht. Presidio liefert Redaktion; Lucairn liefert Redaktion plus eine infrastrukturelle Garantie, dass selbst wenn eine Redaktions-Regex ein Muster verfehlt, die KI-Sandbox den Identitätsspeicher nicht über das Netzwerk erreichen kann.

02.Warum nicht OpenAIs Content-Filterung plus einen System-Prompt?

Ehrliche AntwortWenn Sie der Policy-Umsetzung des LLM-Anbieters gegenüber Ihrem DSB und Ihrem Prüfer vertrauen, sind System-Prompts einfacher und günstiger.

Content-Filterung und System-Prompts sind Richtlinien, die das LLM befolgen soll. Das Modell sieht weiterhin die Identitätsdaten und entscheidet — zur Inferenzzeit —, ob es die Richtlinie einhält. Lucairn erzwingt auf Infrastrukturebene: Das LLM sieht die Identitätsdaten nicht, Punkt. Die Pseudonymisierung passiert, bevor die Anfrage das Gateway verlässt — Policy-Konformität ist also keine Verhaltenseigenschaft des Modells; sie ist eine strukturelle Eigenschaft des Netzwerks. Dieser Unterschied zählt, wenn ein Prüfer Nachweis verlangt, dass PII nie überquert hat — nicht nur Nachweis, dass Sie es zu verhindern versucht haben.

03.Warum nicht Nightfall, BigID oder kommerzielle DLP-Anbieter?

Ehrliche AntwortWenn Sie Netzwerk-Egress-DLP über Ihre SaaS-Apps und Endpunkte brauchen, nutzen Sie diese — sie sind komplementär, keine Konkurrenz.

Diese Anbieter operieren an einem anderen Punkt der Architektur: DLP an Endpunkten, in SaaS-Apps, am Netzwerk-Egress oder beim Daten-at-Rest-Scanning. Lucairn operiert an der Grenze des LLM-Aufrufs — in dem Moment, in dem ein Prompt an einen Inferenz-Anbieter gesendet werden soll. Die beiden lassen sich sauber stapeln: DLP fängt PII ab, die aus Laptops und SaaS-Tools fliesst; Lucairn fängt PII ab, die in den KI-Hop fliesst, und erzeugt einen signierten Nachweis für genau diesen Aufruf. Wenn Ihr Compliance-Programm beide Oberflächen abdecken muss, betreiben Sie beides.

04.Warum nicht Skyflow?

Ehrliche AntwortWenn Ihr Problem strukturierter PII-Speicher ist, nutzen Sie Skyflow. Beide lassen sich kombinieren: Skyflow für Speicherung, Lucairn für den LLM-Hop.

Skyflow ist ein Tresor für strukturierte PII — Datenbanken, Kundenprofile, Zahlungsdaten. Skyflow exzelliert beim Tokenisieren strukturierter Datensätze, die Sie ohnehin speichern, und beim Vermitteln des Zugriffs über eine datenschutzbewusste API. Lucairn fokussiert auf die Grenze des LLM-Aufrufs: Bereinigung von Prompts im Flug und Erzeugung eines pro-Aufruf-Zertifikats, das ein Prüfer gegenüber dem Witness verifizieren kann. Beide lösen unterschiedliche Probleme und können nebeneinander laufen — Skyflow hält den kanonischen Identitätsdatensatz; Lucairn stellt sicher, dass kein identitätsverknüpfter Inhalt das Modell erreicht, wenn Ihr KI-Workflow über einen Datensatz schliessen muss.

05.Warum nicht einfach Ollama, Llama 3 oder ein selbst gehostetes Open-Weight-Modell nutzen?

Ehrliche AntwortEin Open-Weight-Modell selbst zu hosten entfernt den Drittanbieter-LLM-Anbieter als Auftragsverarbeiter — das ist allein eine valide Datenschutzposition.

Ein Modell auf Ihrer Hardware zu betreiben schliesst tatsächlich eine Bedrohung (den LLM-Anbieter als Auftragsverarbeiter). Es schliesst nicht die anderen: Ein Open-Weight-Modell auf Ihrer Hardware kann weiterhin PII in Prompt-Logs, Retrieval-Indizes, Embedding-Datenbanken, Fine-Tuning-Korpora und Operator-Dashboards lecken. Diese Lecks passieren in Ihrer Infrastruktur, aber sie passieren. Lucairn liefert die architektonische Identitäts-/Inferenz-Trennung unabhängig davon, wo das Modell läuft — BYOK unterstützt selbst gehostete Endpunkte, sodass Sandbox B Ihr eigenes Ollama-, vLLM- oder TGI-Deployment aufrufen kann und dennoch ein signiertes Zertifikat erzeugt, das beweist, dass keine Identitätsdaten überquert haben.

06.Funktioniert Streaming?

Ehrliche AntwortNoch nicht.

Pro-Chunk-DLP ist ein hartes Problem: Sie können kein PII-Muster redigieren, das Sie noch nicht gesehen haben, und sobald ein Token an den Client gestreamt wurde, können Sie es nicht zurücknehmen. Heute gated das Gateway Streaming bei services/gateway/internal/api/proxy.go:266-275 (Standard aus über die STREAMING_ENABLED-Umgebungsvariable, geschaltet bei services/gateway/cmd/server/main.go:405) und der OpenAI-Chat-Completions-Adapter lehnt stream:true mit HTTP 400 ab bei services/gateway/internal/api/openai_handler.go:30-32 + :103-104. Wir haben uns für eine harte Ablehnung entschieden, statt einer fragilen Halblösung, die Tokens ausliefert, bevor der Sanitizer fertig ist. Streaming mit einer nachweis-erhaltenden Chunking-Strategie ist auf der Roadmap. Die Capability-Matrix auf /integration verfolgt das ehrlich und kippt, sobald es ausgeliefert ist.

07.Funktionieren Tool-Calls / Function-Calling?

Ehrliche AntwortNoch nicht — das Gateway leitet `tools` und `tool_choice` heute überhaupt nicht weiter, und wir machen das auf jeder Entwicklerseite sichtbar.

Tool-Inputs brauchen einen eigenen Sanitization-Durchgang, und die Lücke zwischen Bereinigen von Tool-Call-Definitionen versus Bereinigen von Tool-Call-Argumenten hat subtile Korrektheitsfallen, die leicht falsch ausgeliefert werden. Heute leiten die Gateway-Handler die Felder `tools` und `tool_choice` überhaupt nicht weiter. Nachrichten mit role:"tool" gehen durch den Freitext-Sanitizer bei services/gateway/internal/api/anthropic_handler.go:230 und services/gateway/internal/api/openai_handler.go:309, aber das Tool-Definitions-Array und die Call-Argument-Payloads selbst werden nicht bereinigt. Wir haben das Feld lieber deaktiviert als halbfertig ausgeliefert. Wenn Sie heute PII-bewusste Tool-Inputs brauchen, nutzen Sie die DSA Proxy API mit explizitem Field-Routing — Sie klassifizieren jeden Input als Identität, Freitext oder Passthrough, und die Bridge bedient jeden Pfad explizit. Die Tool-Call-Abdeckungslücke ist auf der Roadmap und auf der Capability-Matrix unter /integration verzeichnet.

08.Ist DSGVO- oder KI-Verordnung-Konformität „by default“?

Ehrliche AntwortArchitektur-by-default hilft. Compliance-by-default kann Ihnen kein Anbieter verkaufen — das ist Ihr Programm.

Lucairn liefert die architektonischen Bausteine: Artikel 25 Datenschutz durch Technikgestaltung über die Dual-Sandbox-Trennung, Artikel 32 Sicherheit der Verarbeitung über signierte Zertifikate und NetworkPolicy-Isolation, KI-Verordnung Artikel 10 + 12 + 14 + 15-Mappings über die Sanitizer-Pipeline und die Append-only-Audit-Kette. Das Compliance-Programm um diese Bausteine herum ist Ihre Verantwortung: Sie brauchen weiterhin eine DSFA für Ihren KI-Anwendungsfall, Auftragsverarbeiter-Offenlegungen (Lucairn wird einer davon), einen Auftragsverarbeitungsvertrag mit uns, eine KI-Verordnung-Risikoklassifizierung Ihrer Anwendung, Aufbewahrungsrichtlinien und Operator-Schulungen. Wir liefern Vorlagen; wir stellen — und können — Ihre DSFA nicht in Ihrem Namen aus.

09.Wie hoch ist der Latenz-Overhead?

Ehrliche AntwortEin einzelner Proxy-Hop fügt typischerweise 200–1500 ms zum reinen LLM-Aufruf hinzu. Wenn unter 200 ms nicht verhandelbar sind, ist Lucairn nicht der richtige Hop.

Die Varianz kommt aus der Anzahl der Sanitizer-Schichten und der Prompt-Grösse. Ein kurzes deutsches Support-Ticket durch L1 + L2 liegt am unteren Ende; eine lange mehrabsatz-Anfrage durch alle drei Sanitizer-Schichten (L1 Known-Entity-Matching, L2 Presidio NER, L3 LLM PII Shield) liegt am oberen Ende. Verankerte Attestierung — Time-Stamp-Authority-Signatur und Sigstore-Rekor-Inklusion — ist asynchron und fügt keine vom Nutzer wahrnehmbare Latenz hinzu; die Zertifikats-URL kommt sofort zurück und die Anker füllen sich innerhalb weniger Sekunden. Streaming würde die wahrgenommene Latenz für lange Antworten verringern, ist aber noch nicht unterstützt (siehe oben).

10.Was passiert, wenn der Sanitizer ein PII-Muster verpasst?

Ehrliche AntwortSanitizer-Misses können passieren. Die architektonische Trennung ist das, was sie überlebbar macht.

Der Sanitizer ist mehrschichtig — L1 Known-Entity-Matching gegen Ihre kunden-bereitgestellten Recognizer, L2 Presidio NER für generische Identifier, L3 LLM PII Shield für kontextabhängige und domänenspezifische Muster. Keine dieser Schichten ist allein perfekt; gemeinsam decken sie den Grossteil des Produktionsverkehrs ab. Der Grund, warum das akzeptabel statt alarmierend ist, ist strukturell: Selbst wenn ein PII-String an jeder Sanitizer-Schicht vorbeirutscht, ist Sandbox B (KI-Verarbeitung) netzwerkisoliert von Sandbox A (Identitätsspeicher). Das Leck ist begrenzt — es kann die Grenze nicht zurück in einen wiederverwendbaren identitätsverknüpften Datensatz überqueren, und die Audit-Kette erfasst den Request trotzdem. Kunden-bereitgestellte Recognizer und ein kundenspezifisch trainierter Level-3-PII-Shield (ein Enterprise-Add-on, preislich nach Scope) schliessen die meisten domänenspezifischen Lücken für Teams, die das brauchen.

Weiterführend

Möchten Sie das in Aktion sehen?

Vereinbaren Sie einen Termin — wir gehen gemeinsam durch Ihren Anwendungsfall.