Wie baut man Privacy-first-KI für sensible Daten?

Die meisten KI-Demos nutzen Daten, die niemandem schaden können: öffentliche Texte, Marketingtexte, Code. Doch sobald die Eingabe persönlich wird — medizinische Beschwerden, juristische Akten, ein Tagebuch, ein Traum — ändert sich die Frage. Es geht nicht mehr um „was kann KI", sondern um „was darf KI, und was soll sie bewusst nicht tun".

Ich habe ein Produkt gebaut, das genau auf dieser Grenze sitzt: Dreamalizing, eine KI, mit der Menschen ihre Träume erkunden. Trauminhalte sind ungefähr die persönlichste Eingabe, die es gibt. Genau deshalb sind sie ein scharfer Testfall für eine Frage, der jede Organisation begegnet, die KI auf sensible Daten ansetzt: Wie hält man KI nützlich und zugleich sicher?

Das Problem

Bei sensiblen Daten stehen zwei Anforderungen gegeneinander:

• KI muss nützlich sein — sonst ist es nur ein leeres Textfeld
• KI darf nie so tun, als kenne sie die Wahrheit — keine falsche Gewissheit, keine Diagnose, keine Aussagen, die sie nicht belegen kann

Ein naives Produkt wählt eine Seite: entweder ein bestimmtes „Orakel", das Gewissheit vortäuscht, oder ein harmloses Speicherfeld ohne Wert. Beides ist falsch. Und dann gibt es die härteste Anforderung: Die Daten selbst dürfen nicht abfließen — nicht zu Dritten, nicht zu einer großen KI-Plattform, nicht in ein Audit-Log, in das sie nicht gehören.

Die Lösung: KI als System behandeln, nicht als Funktion

Privacy-first-KI entsteht nicht durch eine Einstellung, sondern durch eine Reihe bewusster Entscheidungen. Dies sind die sechs, die ich in Dreamalizing getroffen habe — und sie gelten genauso für einen Gesundheits-, Rechts- oder HR-Kontext:

1. Guided Exploration statt Blackbox-Output. Die KI interpretiert nicht, sondern stellt gezielte Fragen. Der Nutzer bleibt die Autorität. Das ist keine UX-Entscheidung, sondern eine Sicherheitsentscheidung: Ein Modell, das Fragen stellt, kann weniger Unsinn als Wahrheit präsentieren.

2. Bounded AI mit Grenzen im System. Keine Therapie, keine Diagnose, keine medizinischen Aussagen. Diese Grenzen stecken nicht in einem Disclaimer am Ende, sondern in den Prompts, den Guardrails und der Evaluierung — durchsetzbar, nicht kosmetisch.

3. Verschlüsselte Speicherung auf eigener Infrastruktur. Sensible Eingaben werden verschlüsselt gespeichert (AES-256-GCM, Schlüssel pro Nutzer) auf eigener Infrastruktur — nicht standardmäßig bei einem großen Cloud-Anbieter.

4. Lokale Inferenz. Die Sprachmodelle laufen lokal, per Konfiguration erzwungen. Sensible Eingaben gehen also nicht standardmäßig an einen externen KI-Dienst. Das ist der Unterschied zwischen „wir versprechen Datenschutz" und „technisch geht es gar nicht anders".

5. Opt-in, kein Opt-out. Mustererkennung über mehrere Eingaben hinweg passiert nur, wenn der Nutzer das bewusst wählt. Die Voreinstellung lautet: so wenig wie möglich.

6. Löschbar und nachvollziehbar. Eine Löschanfrage entfernt die Daten wirklich vollständig (DSGVO), und die Kette ist auditierbar — man kann im Nachhinein zeigen, was mit den Daten geschehen ist.

Warum das über eine Traum-App hinausgeht

Der Traum ist hier das extreme Beispiel, aber die Prinzipien sind generisch. Kontext als Wahrheit (RAG auf eigenen Quellen), Messbarkeit (Qualität, Kosten, Latenz als Kennzahlen), Governance (Rollen, Logging, Policies) und klare Grenzen — genau dieser Ansatz bringt KI in Kundenprojekten rund um KI in der Produktion in Produktion.

Der Unterschied zwischen einem KI-Piloten, der stecken bleibt, und einem KI-System, das läuft, liegt selten im Modell. Er liegt darin, ob man die sensiblen Daten, die Grenzen und die Nachvollziehbarkeit so ernst nimmt wie die smarte Antwort.

Wollen Sie KI auf Daten ansetzen, die wirklich zählen?