Googles HEIR-Compiler bringt homomorphe Verschlüsselung in private KI-Inferenz

Rechnen ohne den Klartext zu öffnen

Google hat am 14. August 2026 in einem Blogbeitrag ein neues Werkzeug für sein Private Computing Toolkit vorgestellt: HEIR, einen Open-Source-Compiler, der KI-Modelle direkt auf verschlüsselten Daten rechnen lässt. Das Unternehmen selbst nennt HEIR den jüngsten Baustein seines Datenschutz-Werkzeugkastens und verspricht mit HEIR homomorphe Verschlüsselung als kryptografisch abgesicherte private KI-Inferenz – eine Ansage, die sich von der üblichen Datenschutzrhetorik der Branche zumindest durch die technische Tiefe unterscheidet.

Der Kern ist homomorphe Verschlüsselung, ein Verfahren, das Google selbst als schnell reifend beschreibt. Server verarbeiten dabei ausschließlich Chiffretexte und liefern verschlüsselte Ergebnisse zurück, ohne die zugrunde liegenden Informationen einzusehen. Google führt als Beispiel einen Cloud-Dienst an, der Empfehlungen ausspielt, ohne die Nutzerdaten dafür im Klartext zu lesen – laut eigener Aussage sogar Teil einer Demonstration, die im selben Beitrag vorgestellt wird.

Das eigentliche Problem, das Google adressiert, ist ein alter Zielkonflikt: Ende-zu-Ende-Verschlüsselung schützt Daten zuverlässig vor Diebstahl, verhindert aber gleichzeitig Funktionen, die auf diesen Daten aufbauen – etwa Spam- oder Virenerkennung. Wer beides will, brauchte bislang einen Kompromiss zwischen Vertraulichkeit und Funktionsumfang. HEIR soll genau diesen Kompromiss verschieben, indem Berechnung und Verschlüsselung gleichzeitig möglich werden.

Wie ernst es Google meint, zeigt der Kontext: Das Unternehmen reiht HEIR in eine Historie von Datenschutztechnologien ein – von differenzieller Privatsphäre über private Mengenmitgliedschaft bis zu privater Informationsbeschaffung und sicheren Enklaven in der Google Cloud. Homomorphe Verschlüsselung ist damit kein Ausreißer-Experiment, sondern die konsequente Fortsetzung eines längeren Investitionswegs, den das Unternehmen seit Jahren verfolgt und mit HEIR nun um ein praxisnahes Compiler-Werkzeug ergänzt.

Welche Rolle der HEIR-Compiler übernimmt

Technisch betrachtet ist HEIR kein Verschlüsselungsverfahren selbst, sondern ein Compiler – ein Werkzeug, das Standardcode automatisch in homomorph verschlüsselte Operationen übersetzt. Für Entwicklerteams bedeutet das: Sie müssen keine eigene Kryptografie entwerfen, um ihre Modelle verschlüsselungsfähig zu machen. HEIR übernimmt diese Übersetzung, ähnlich wie ein klassischer Compiler lesbaren Quellcode in maschinennahe Anweisungen überführt – nur dass am Ende verschlüsselte Rechenoperationen stehen.

Google begründet den Schritt mit einem Abwägungsproblem, das mit wachsender KI-Nutzung dringlicher wird: Je mehr Nutzen KI-Systeme stiften, desto drängender wird die Frage, wie Datenschutz und Sicherheit gleichzeitig gewährleistet werden können. Ein Compiler, der diese Abwägung technisch entschärft, ist damit weniger Kür als Antwort auf ein strukturelles Problem, das mit jedem neuen KI-Feature größer wird.

Bemerkenswert ist, dass Google die Alternative explizit mitdenkt: lokale Verarbeitung auf dem Endgerät. Dort limitieren jedoch Rechenleistung und die Schutzbedürftigkeit des geistigen Eigentums des Anbieters die Möglichkeiten – schickt ein Unternehmen sein proprietäres Modell auf ein Gerät, riskiert es, dass das Modell selbst kopiert oder extrahiert wird. HEIR verspricht, dieses Dilemma zu umgehen, indem das Modell dort bleibt, wo es kontrolliert werden kann, während die Daten verschlüsselt bleiben.

Für Redaktionen wie für IT-Abteilungen heißt das in der Praxis: Ein Compiler ersetzt keine Sicherheitsarchitektur, er ist nur ein Baustein davon. Wer HEIR einsetzen will, braucht weiterhin ein Konzept dafür, welche Modelle, welche Datenflüsse und welche Nutzergruppen überhaupt von homomorpher Verschlüsselung profitieren – der Compiler liefert das Werkzeug, nicht die Entscheidung, und ersetzt auch keine unternehmensinterne Risikoabschätzung.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptA researcher hand guides an encrypted frosted glass bead through a clear sequence of mathematical prism shapes without opening the bead, ending in a differently colored sealed capsule. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Verschlüsselte Inferenz bleibt ein Systemproblem

Wer nach dem eigentlichen Zielpublikum von HEIR fragt, landet schnell bei regulierten Branchen. Google benennt Gesundheitswesen und Finanzwesen ausdrücklich als besonders risikoscheu, weil strenge Regulierung den Datenaustausch zwischen Institutionen ohnehin einschränkt. Genau dort, wo Datenschutzauflagen Kooperationen bislang blockieren, könnte ein Verfahren wie homomorphe Verschlüsselung neue Kooperationsmodelle ermöglichen, ohne die Auflagen zu verletzen.

Das ist kein rein technisches Versprechen, sondern eines mit regulatorischer Schlagseite. Wie stark Aufsichtsbehörden mittlerweile auch technische Details von KI-Systemen adressieren, zeigte zuletzt die Debatte um verbindliche Vorgaben für KI-generierten Code – ein Beschluss, der KI-Entwicklern klare Nachweispflichten auferlegt. Verschlüsselte Inferenz könnte solchen Nachweispflichten künftig entgegenkommen, weil sie Kontrolle über Daten technisch statt nur vertraglich absichert.

Trotzdem bleibt verschlüsselte Inferenz ein Systemproblem, kein reines Kryptografie-Feature. Ein Modell, das auf Chiffretexten rechnet, muss weiterhin korrekt trainiert, validiert und überwacht werden. Fehler in der Eingabepipeline werden durch Verschlüsselung nicht sichtbarer, sondern eher unsichtbarer – wer die Daten nicht lesen kann, erkennt Anomalien auch schwerer. Wer HEIR einführt, braucht also zusätzliche Kontrollen, nicht weniger.

Genau an dieser Stelle liegt die eigentliche Verkaufsargumentation von Google: nicht Verschlüsselung ersetzt Kontrolle, sondern Verschlüsselung erweitert den Raum, in dem Kontrolle überhaupt möglich ist – etwa in Kooperationen zwischen Kliniken oder Banken, die bislang aus Datenschutzgründen gar nicht miteinander rechnen durften. Ob diese Erweiterung in der Praxis trägt, entscheidet sich erst, wenn erste Pilotprojekte in solchen Branchen tatsächlich live gehen.

Open Source schafft Prüfbarkeit, nicht automatisch Tempo

Dass Google HEIR als Open Source veröffentlicht, ist mehr als eine Marketingfloskel. Kryptografie-Verfahren gelten in der Fachwelt erst dann als vertrauenswürdig, wenn unabhängige Teams den Code lesen, testen und angreifen können – Security-by-obscurity hat sich bei Verschlüsselungssystemen historisch fast nie ausgezahlt. Mit einem offenen Compiler lässt sich zumindest prüfen, ob die Übersetzung von Klartext-Operationen in verschlüsselte Rechenschritte tatsächlich das tut, was Google behauptet.

Das ändert allerdings nichts an einem harten technischen Fakt, den Google selbst einräumt: Homomorphe Verschlüsselung hat einen nicht trivialen Rechenaufwand und verschiebt den Zielkonflikt zwischen Funktionsumfang und Datenschutz lediglich auf eine Kostenfrage. Verschlüsselte Berechnung ist also grundsätzlich teurer als Klartext-Berechnung – Open Source macht diesen Aufwand transparent, aber nicht kleiner.

Immerhin sinkt dieser Aufwand laut Google kontinuierlich, weil sowohl Hardware als auch Kompilertechnik sich weiterentwickeln. Für Teams, die HEIR homomorphe Verschlüsselung heute evaluieren, bedeutet das: Wer jetzt Prototypen baut, testet nicht nur ein Sicherheitskonzept, sondern auch, wie sich Rechenkosten in den kommenden Produktzyklen entwickeln – eine Wette auf sinkende Kosten ist Teil der Kalkulation, nicht nur ein Detail am Rand.

Offenheit schafft also Prüfbarkeit und langfristig Vertrauen, aber keine Abkürzung. Wer glaubt, ein offener Compiler löse automatisch das Performance-Problem homomorpher Verschlüsselung, verwechselt Transparenz mit Optimierung. Beides ist nötig, aber es sind zwei unterschiedliche Baustellen, die getrennt bearbeitet und getrennt bewertet werden müssen.

Wo Googles Leistungsversprechen Grenzen hat

So überzeugend die Idee klingt, so wichtig ist die Frage nach den Grenzen. Google selbst deutet an, wo diese liegen: Der Rechenaufwand für homomorphe Verschlüsselung ist nicht trivial, also keineswegs vernachlässigbar. Wer verschlüsselte Inferenz produktiv einsetzen will, muss also mit spürbar höheren Rechenkosten planen als bei klassischer, unverschlüsselter Inferenz – ein Faktor, den Google in seiner Ankündigung nicht verschweigt, aber auch nicht quantifiziert.

Das passt zu einem Muster, das bei Google in den vergangenen Jahren wiederholt zu beobachten war: Ambitionierte Datenschutzversprechen treffen auf ein Unternehmen, das gleichzeitig unter wachsendem regulatorischem Druck steht. Erst musste der Konzern in Europa Android für konkurrierende Sprachassistenten öffnen – ein Beleg dafür, dass Google zunehmend gezwungen wird, Kontrolle über eigene Systeme abzugeben, während es gleichzeitig neue Kontrollmechanismen wie HEIR anbietet, um Vertrauen in genau diese Systeme zurückzugewinnen.

Diese Doppelbewegung ist kein Widerspruch, sondern Kalkül: Wo Google Marktmacht abgeben muss, versucht der Konzern, technisches Vertrauen als Differenzierungsmerkmal aufzubauen. Ob homomorphe Verschlüsselung dafür reicht, hängt davon ab, ob externe Prüfungen die Kostenrechnung und die Sicherheitsgarantien bestätigen – Ankündigungen allein schaffen noch keine geprüfte Infrastruktur, egal wie ausgereift die zugrunde liegende Kryptografie bereits ist.

Für Unternehmen, die heute über den Einsatz nachdenken, bleibt deshalb eine nüchterne Doppelfrage: Rechnet sich der Mehraufwand für den eigenen Anwendungsfall, und lässt sich die Sicherheitsgarantie unabhängig überprüfen? Beide Antworten liefert eine Produktankündigung naturgemäß nicht, sie liefert lediglich den Anlass, beide Fragen überhaupt zu stellen.

Ein belastbarer Test für private KI

Google selbst nennt eine Demonstration als Beleg dafür, dass die Technik über Theorie hinausgeht: ein Dienst, der Empfehlungen ausspielt, ohne die zugrunde liegenden Nutzerdaten zu sehen. Das Unternehmen betont ausdrücklich, dass dies keine Übertreibung sei, sondern exakt das, was eine der im Beitrag vorgestellten Demonstrationen zeigt – eine Formulierung, die auffällig defensiv klingt für eine Ankündigung, die eigentlich Aufbruchstimmung verbreiten soll.

Genau diese Defensivität ist aufschlussreich. Sie zeigt, dass Google mit Skepsis rechnet – zu Recht, denn homomorphe Verschlüsselung wird seit Jahren als bald praxisreif gehandelt, ohne dass viele Unternehmen sie produktiv einsetzen. Ein funktionierender Demo-Fall ändert daran wenig, solange unabhängige Audits, Lasttests unter Produktionsbedingungen und belastbare Kostenvergleiche fehlen.

Für Leserinnen und Leser, die selbst über den Einsatz nachdenken, lohnt sich deshalb ein zweistufiger Blick: zunächst die technischen Zusicherungen aus Googles eigener Darstellung, dann der eigene Blick auf Systemlandschaft, Kostenmodell und regulatorischen Kontext – denn keiner dieser Faktoren wird durch eine einzelne Produktankündigung ersetzt.

Am Ende bleibt HEIR homomorphe Verschlüsselung ein ernstzunehmender Testfall dafür, ob private KI-Inferenz aus dem Forschungslabor in den Produktionsbetrieb wechseln kann. Die Bausteine – offener Compiler, sinkende Kosten, ein belegter Anwendungsfall – sind vorhanden. Ob sie zusammen reichen, um aus einer Ankündigung ein Standardverfahren zu machen, entscheidet sich nicht in Mountain View, sondern in den IT-Abteilungen, die HEIR als erste ernsthaft ausprobieren.

Was Unternehmen jetzt konkret prüfen sollten

Wer HEIR homomorphe Verschlüsselung nicht nur als Nachrichtenmeldung, sondern als mögliche Beschaffungsentscheidung liest, sollte drei Dinge trennen: die kryptografische Zusicherung, den tatsächlichen Rechenmehraufwand für das eigene Modell und die organisatorische Frage, wer im Unternehmen die Verantwortung für verschlüsselte Datenflüsse übernimmt. Alle drei Punkte lassen sich anhand des offenen Compiler-Codes zumindest teilweise selbst nachvollziehen, statt Google beim Wort nehmen zu müssen.

Ein einfacher erster Test ist ein kleines, klar begrenztes Pilotprojekt: ein einzelnes Modell, ein einzelner Datenfluss, ein messbarer Kostenvergleich zwischen verschlüsselter und unverschlüsselter Inferenz. Erst wenn dieser Vergleich vorliegt, lässt sich seriös einschätzen, ob der von Google versprochene sinkende Kostenpfad für den eigenen Anwendungsfall bereits greift oder noch Jahre entfernt ist.

Für regulierte Branchen kommt eine zusätzliche Prüfung hinzu: Ob eine Aufsichtsbehörde HEIR homomorphe Verschlüsselung tatsächlich als ausreichenden technischen Schutz für sensible Datenverarbeitung akzeptiert, ist bislang keine ausgemachte Sache. Wer im Gesundheits- oder Finanzwesen plant, sollte diese Frage frühzeitig mit der eigenen Rechtsabteilung klären, statt sie erst nach der technischen Integration zu stellen.

Kurz gesagt: HEIR liefert das Werkzeug, aber die Sorgfaltspflicht bleibt bei denen, die es einsetzen. Genau darin liegt der eigentliche Unterschied zwischen einer beeindruckenden Compiler-Demo und einem Verfahren, dem man sensible Produktionsdaten tatsächlich anvertraut.