Sensible Daten für KI verschlüsseln: Was Googles HEIR wirklich verändert – und wo die Grenzen liegen

Wenn ein KI-Dienst sensible Daten verarbeiten soll, entsteht ein Zielkonflikt: Das Modell braucht Informationen, der Betreiber soll den Klartext aber möglichst nicht lesen können. Homomorphe Verschlüsselung setzt genau dort an. Googles HEIR soll die dafür nötige Compiler- und Toolchain-Arbeit leichter zugänglich machen – es ist aber weder ein fertiger Cloud-Dienst noch ein Schalter für vollständige Privatsphäre.

Die Daten werden auf der Seite des Clients verschlüsselt. Ein Dienst kann die Chiffretexte anschließend mit einem passend übersetzten Modell verarbeiten. Das Ergebnis bleibt ebenfalls verschlüsselt, bis es beim berechtigten Empfänger wieder entschlüsselt wird. Für den Betreiber sinkt damit der direkte Zugriff auf den Inhalt der Eingabe.

Der Server rechnet, ohne den Klartext zu sehen

Das ist der Kern der Fully Homomorphic Encryption (FHE). Sie ist keine Anonymisierung und kein Ersatz für Zugriffskontrollen. Sie verändert vielmehr den Ort, an dem der Klartext auftaucht. Aus einer Anfrage, die bisher offen an einen Dienst ging, wird eine Berechnung, bei der der Server mathematisch mit verschlüsselten Werten arbeitet.

HEIR verschiebt die Hürde in den Compiler

Google stellte HEIR am 14. August 2026 in einem Security-Blogpost vor. Das Projekt ist als Open-Source-Compiler und Toolchain für homomorphe Verschlüsselung angelegt. Google beschreibt dabei eine Übersetzung von vortrainierten Modellen, die mit unverschlüsselten Daten arbeiten, hin zu Modellen für verschlüsselte Eingaben.

Der praktische Punkt liegt weniger in einer neuen Verschlüsselungsformel als in der Entwicklungsarbeit dazwischen. Ein Modell muss in Operationen zerlegt werden, die unter einem passenden Verschlüsselungsschema funktionieren. Datenlayouts, Zwischenrepräsentationen, Parameter und Backend-Anbindung müssen zusammenpassen. HEIR bündelt dafür Compiler-Pässe und Schnittstellen zu FHE-Bibliotheken und möglichen Beschleunigern.

Die offizielle Dokumentation nennt Anwendungsentwickler, Compilerbauer, Hardwaredesigner und Kryptografie-Forschende als Zielgruppen. Das öffentliche Repository beschreibt eine MLIR-basierte Toolchain und nennt unter anderem OpenFHE- und Lattigo-Pfade. Diese Angaben zeigen den technischen Umfang des Projekts. Sie beweisen nicht, dass jedes Modell, jedes Backend oder jede Produktionsumgebung bereits unterstützt wird.

Warum das Modell nicht einfach austauschbar ist

Verschlüsselte Inferenz ist nicht normale KI mit einem zusätzlichen Häkchen. FHE-Schemes haben eigene Eigenschaften und Parameter. Multiplikationen, Rauschen, Näherungen und die Darstellung von Zahlen beeinflussen, welche Modelloperationen möglich sind und wie viel Rechenarbeit entsteht.

Das HEIR-Paper beschreibt deshalb mehrere Zielkonflikte: Latenz und Speicherbedarf, die Größe der Chiffretexte, Schlüsselmaterial und Bandbreite sowie Sicherheitsparameter. Auch die Approximation bestimmter Funktionen und das Layout der verschlüsselten Daten können entscheidend sein. Ein Compiler kann diese Arbeit strukturieren und automatisieren. Er hebt die mathematischen Kosten der verschlüsselten Berechnung aber nicht auf.

Was HEIR adressiert

Compiler- und Toolchain-Arbeit, Zwischenrepräsentationen, Modellübersetzung sowie Backend- und mögliche Hardware-Anbindung.

Was separat geprüft werden muss

Passendes Scheme, Modellgenauigkeit, Parameter, Schlüsselverwaltung, Laufzeit, Speicherbedarf und der konkrete Schutzbedarf.

Was daraus nicht folgt

Eine universelle Produktionsplattform, automatische Privatsphäre oder eine rechtliche Freigabe.

Die Rechenlast bleibt der harte Prüfpunkt

Google nennt in seinem Beitrag mehrere Demonstrationsanwendungen und verweist auf Latenzwerte für eine Single-Thread-CPU. Im sichtbaren Text steht jedoch keine vollständige Vergleichstabelle mit Modell, Scheme, Sicherheitsparametern und Hardware. Diese Werte lassen sich deshalb nicht als allgemeine HEIR-Leistung lesen.

Ein separates Beispiel von AWS macht die Größenordnung des Problems greifbar, ohne ein HEIR-Benchmark zu sein. Für eine konkrete-ml-/SageMaker-Implementierung nennt AWS je nach Aufbau einen Overhead von bis zu 100.000 gegenüber Klartext-Inferenz. Nach Quantisierung werden 2.800 und mit einem größeren Instanztyp 500 genannt. AWS beschreibt interaktive, latenzkritische Anwendungen in diesem Beispiel als noch nicht geeignet.

Die Zahlen gehören zu AWS und zu dessen konkretem Setup. Sie sind keine Konstante für FHE und schon gar kein Messwert für HEIR. Die belastbare Schlussfolgerung ist kleiner, aber wichtiger: Modell, Präzision, Hardware und Auslastung entscheiden darüber, ob verschlüsselte Inferenz für eine Aufgabe tragfähig ist. Batch- oder asynchrone Prozesse können dabei besser passen als eine zeitkritische Live-Antwort.

Private Eingaben sind nicht automatisch ein privater Dienst

Wer HEIR oder eine andere FHE-Lösung bewertet, sollte den gesamten Datenfluss betrachten. Die Verschlüsselung des Inputs beantwortet nur einen Teil der Frage. Für eine belastbare Architekturprüfung gehören mindestens diese Punkte auf die Liste:

Damit wird auch der Begriff „private KI“ präziser. Er kann bedeuten, dass der Betreiber den Klartext nicht erhält. Er kann aber nicht ohne weitere Angaben garantieren, dass niemand aus Metadaten, Zugriffsmustern oder Ergebnissen Rückschlüsse zieht.

Die Deutschland-/EU-Frage ist eine Architekturfrage

Für Organisationen in Deutschland und der EU liegt der mögliche Nutzen in einem veränderten Datenverarbeitungsrisiko. Kliniken, Versicherer, Forschungseinrichtungen, öffentliche Stellen oder Unternehmen mit Kundendaten könnten prüfen, ob sich bestimmte Inferenzaufgaben verschlüsselt auslagern lassen, ohne dem Dienstbetreiber den Klartext zu geben.

Das ersetzt keine Rechtsprüfung. Es gibt aus den vorliegenden Quellen weder eine deutsche oder europäische Freigabe noch einen Nachweis für automatische DSGVO- oder AI-Act-Konformität. Auch Auftragsverarbeitung, Speicher- und Löschkonzepte, Zugriffskontrollen, Sicherheitsprüfungen und die Behandlung von Berufsgeheimnissen bleiben relevant. HEIR kann die technische Architektur verändern; die Verantwortung für den gesamten Prozess bleibt bei der Organisation.

Meine Einschätzung: ein wichtiger Entwicklungsbaustein, kein Abkürzungsversprechen

HEIR verdient Aufmerksamkeit, weil homomorphe Verschlüsselung lange an einer sehr spezialisierten Übersetzungs- und Optimierungsarbeit gescheitert ist. Eine offene Compiler-Infrastruktur kann diese Arbeit besser zugänglich machen und verschiedene Schemes, Bibliotheken und Hardwarepfade zusammenführen.

Der realistische erste Einsatz liegt eher bei begrenzten, planbaren oder batchartigen Aufgaben als bei beliebiger Echtzeit-KI. Ob der Ansatz trägt, zeigt sich nicht an der Ankündigung, sondern an reproduzierbaren End-to-End-Tests für ein konkretes Modell: mit festgelegten Sicherheitsparametern, Daten, Hardware, Latenzziel und Genauigkeitsprüfung.

Fazit: HEIR macht die Frage prüfbarer

Googles HEIR verändert vor allem die Entwicklungsseite privater KI-Inferenz. FHE kann Berechnungen auf Chiffretexten ermöglichen, und ein Compiler kann die dafür nötige Modell- und Backend-Arbeit ordnen. Der Schutzgewinn bleibt dennoch abhängig von Schlüsselverwaltung, Metadaten, Infrastruktur, Ausgabe und organisatorischem Rahmen.

Wer sensible KI-Anwendungen plant, sollte deshalb nicht mit der Frage beginnen, ob HEIR „private KI“ verspricht. Sinnvoller ist ein konkreter Test: Welche Daten müssen geschützt werden, wer darf was sehen, welche Verzögerung ist akzeptabel und welche Kosten entstehen für genau dieses Modell? Erst daraus lässt sich ableiten, ob verschlüsselte Inferenz mehr ist als eine interessante Forschungsoption.

Hinweis: Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft. Stand: 2026-08-16