Jedes Mal, wenn Sie eine Eingabe in eine zentrale KI tippen, wandert dieser Text zu einem Server, wird verarbeitet – und protokolliert.
Das Unternehmen, das diesen Server betreibt, kann Ihre Eingabe lesen. Es kann sie speichern, für das Training künftiger Modelle verwenden und bei einer Anfrage von Aufsichtsbehörden herausgeben.
Die meisten Nutzer akzeptieren diesen Deal, ohne darüber nachzudenken.
Doch ein wachsendes Cluster von Blockchain‑Projekten – aktuell ragt Venice besonders heraus – arbeitet an einer anderen Architektur: einem System, in dem weder Netzbetreiber noch Dritte sehen können, was Sie gefragt haben.
Um zu verstehen, wie das funktioniert, muss man zwei Probleme trennen. Erstens: Wohin Ihre Daten wandern, wenn Sie eine KI abfragen. Zweitens: Welche kryptografischen Werkzeuge verhindern können, dass diese Daten nach außen dringen.
Die Antworten sind greifbarer, als viele erwarten.
TL;DR
- Zentrale KI‑Anbieter wie OpenAI protokollieren Prompts standardmäßig – und erhalten so vollen Einblick in Ihre Anfragen.
- On‑Chain‑Inference für private KI leitet Requests über dezentrale Node‑Netzwerke und nutzt Confidential‑Computing‑Hardware, um Daten selbst vor dem Node‑Betreiber zu verbergen.
- Venice Token (VVV) ist derzeit die meistbeachtete Umsetzung dieses Modells: Inference läuft auf Base mit Privacy‑First‑Ansatz auf Anwendungsebene.
- Die Kehrseite sind Geschwindigkeit, Kosten und Modellgröße: Private Inference ist heute langsamer und teurer als ein normaler API‑Call.
- Diese Architektur ist vor allem relevant für medizinische, juristische, finanzielle und unternehmenskritische Anfragen, bei denen Vertraulichkeit der Prompts unverhandelbar ist.
Warum „Inference“ der Flaschenhals für Privatsphäre ist
KI‑Modelle haben zwei Lebensphasen. In der ersten, dem Training, lernt ein Modell aus großen Datensätzen. In der zweiten, der Inference, verarbeitet das trainierte Modell neue Eingaben – Ihre Frage – und generiert eine Antwort. Inference ist das, was passiert, wenn Sie ChatGPT, Claude oder Gemini nutzen.
An genau dieser Stelle bricht die Privatsphäre. Im Training sind Ihre aktuellen Daten nicht im Spiel. Bei der Inference dagegen muss Ihr Prompt dem System, das ihn verarbeitet, im Moment der Berechnung im Klartext vorliegen. Man kann ein Modell nicht in einer Blackbox befragen, ohne dass es die Frage in irgendeiner Form „liest“.
In zentralen Systemen ist dieses Problem zweitrangig.
OpenAIs Usage Policies erlauben es dem Unternehmen, API‑Eingaben für Sicherheitsprüfungen zu nutzen; zudem können sie – sofern nicht explizit über Enterprise‑Verträge abgewählt – zur Modellverbesserung herangezogen werden. Die meisten Privatnutzer optieren nie aus. Ergebnis: Ein riesiger Korpus hochsensibler Gedanken liegt in Unternehmensdatenbanken.
Das Privacy‑Problem bei KI‑Inference ist kein Randfall, sondern der Default aller großen zentralen KI‑Plattformen.
Dezentrale KI‑Inference kehrt diese Grundannahme um. Statt einem zentralen Server zu vertrauen, stellt sich die Frage, ob man jeden einzelnen Node in einem verteilten Netzwerk so absichern kann, dass er Ihre Eingabe nicht lesen kann – selbst während er das Modell ausführt, das Ihre Antwort berechnet.
Auch lesenswert: Iran War Price Tag Reaches $37.5B As Senators Turn On Hegseth
Wie zentrales KI‑Logging technisch funktioniert
Wenn Sie einen Prompt an eine zentrale KI‑API senden, reist die Anfrage per HTTPS zur Infrastruktur des Anbieters. Diese Verschlüsselung schützt die Daten auf dem Transportweg; ein Dritter im Netzwerk kann sie nicht einfach mitlesen. Trifft sie jedoch am Server ein, wird die HTTPS‑Schicht entfernt.
Die Software des Anbieters sieht Klartext. Von diesem Moment an bestimmt der Anbieter, was mit dem Text geschieht.
Viele Enterprise‑Produkte bieten Zero‑Retention‑Modi, in denen Prompts nach Ende der Session nicht gespeichert werden. Der Microsoft Azure OpenAI Service etwa erlaubt Unternehmenskunden, Endpunkte so zu konfigurieren, dass Eingaben nicht auf Datenträger geloggt werden.
Solche Einstellungen setzen aber einen bezahlten Enterprise‑Vertrag und aktive Konfiguration voraus. Die Voreinstellung für Konsumenten lautet: Speicherung.
Das Logging passiert auf mehreren Ebenen. Applikationslogs zeichnen die Roh‑Requests auf. Serving‑Infrastruktur kann Prompts für bessere Performance zwischenspeichern. Safety‑Filter scannen Inhalte vor und nach der Generierung. Jede dieser Schichten ist ein System, in dem Ihre Daten im Klartext existieren. Selbst bei strikten Löschfristen gab es einen Zeitpunkt, an dem diese Daten auf Systemen lagen, die geprüft, gehackt oder mit Beschluss durchsucht werden könnten.
Hinzu kommt der kommerzielle Anreiz: Modelle, die auf echten Nutzerfragen trainiert werden, sind besser. Wer Prompts sammelt, hat strukturelle Vorteile bei der Produktverbesserung. Die Folge ist ein dauerhafter Zielkonflikt zwischen Privatsphäre und Optimierung, den zentrale Anbieter aus Designgründen nie ganz auflösen können.
Auch lesenswert: Solana And Hyperliquid Capture 80% Of Altcoin ETF Trading Volume
Zwei kryptografische Werkzeuge, die private Inference ermöglichen
Zwei Haupttechniken erlauben es, Inference durchzuführen, ohne dass die rechnende Partei den Input im Klartext sieht. Sie schließen sich nicht aus; in der Praxis werden sie oft kombiniert.
Trusted Execution Environments (TEEs) sind hardwarebasierte Sicherheitszonen in modernen Prozessoren. Intels SGX und AMDs SEV‑SNP sind die prominentesten Beispiele. Ein TEE schafft einen isolierten Speicherbereich, auf den weder Betriebssystem noch Node‑Betreiber noch der Chiphersteller zugreifen können. Code im TEE ist attestiert: Eine Gegenpartei kann kryptografisch verifizieren, dass ein bestimmtes, unverändertes Programm in einer echten Enklave läuft. Ihr Prompt gelangt verschlüsselt in die Enklave, das Modell läuft dort, und die Ausgabe verlässt sie wieder verschlüsselt. Der Node‑Betreiber, dem die Maschine gehört, sieht davon nichts.
Fully Homomorphic Encryption (FHE) wählt einen anderen Ansatz. FHE erlaubt es, Berechnungen direkt auf verschlüsselten Daten auszuführen, ohne sie zu entschlüsseln. Das Modell operiert effektiv auf Ciphertext und erzeugt ein verschlüsseltes Ergebnis, das nur der ursprüngliche Absender entschlüsseln kann. Theoretisch ist das elegant, praktisch aber extrem rechenintensiv. Eine LLM‑Inference komplett unter FHE ist heute um Größenordnungen langsamer als Standard‑Inference. Praktische Einsätze nutzen FHE deshalb meist für kleinere Modelle oder Teilrechnungen, nicht für komplette LLM‑Antworten.
TEEs ermöglichen heute praktikable private Inference mit nahezu normaler Geschwindigkeit. FHE bietet stärkere Garantien, ist aber Stand Mitte 2026 für die meisten LLM‑Use‑Cases zu langsam.
Eine dritte, aufkommende Technik ist Secure Multi‑Party Computation (MPC). Dabei werden Modellgewichte und Nutzereingaben auf mehrere Parteien verteilt, die gemeinsam ein Ergebnis berechnen, ohne dass eine Partei das Gesamtbild sieht. MPC ist flexibel, erkauft diese Flexibilität aber mit erheblichem Koordinationsaufwand.
Auch lesenswert: Google's Secret AI Chip Bakes Gemini Into Hardware For 10X Gains
Wie Venice private Inference auf der Blockchain aufbaut
Venice läuft auf der Base‑Blockchain, einem Ethereum‑(ETH) Layer‑2‑Netzwerk. Die Architektur von Venice trennt drei Funktionen, die zentrale Anbieter typischerweise bündeln: Modell‑Hosting, Inference‑Berechnung und Zahlungsabwicklung.
Node‑Betreiber im Venice‑Netzwerk stellen GPU‑Rechenleistung bereit.
Sie laden Open‑Source‑Modelle wie Llama, Mistral und ähnliche offen verfügbare Gewichte und bedienen Inference‑Anfragen darauf. Da die Modelle offen sind, gibt es kein proprietäres Modell zu schützen. Die Privacy‑Frage dreht sich ausschließlich um Ein‑ und Ausgaben der Nutzer.
Venice setzt auf TEE‑basierte Abschottung auf teilnehmenden Nodes. Wenn ein Nutzer eine Anfrage über das Venice‑Interface stellt, wird sie an einen Node mit TEE‑Umgebung geroutet, der sie verarbeitet. Das Host‑System des Betreibers kann die Inhalte der Enklave nicht einsehen. Attestierungsnachweise erlauben es dem Client, vor dem Absenden des Prompts zu prüfen, ob die korrekte, unveränderte Inference‑Software in einer echten Enklave läuft.
Venice Token (VVV) ist der Utility‑Token des Netzwerks. Er verschafft Zugang zu Inference‑Kapazitäten; Staker erhalten priorisierte Durchsatzkontingente. Der Token legt damit eine ökonomische Schicht über die Privacy‑Infrastruktur: Compute‑Provider verdienen Gebühren, Nutzer zahlen oder staken VVV, um private Inference zu nutzen. Privacy ist hier nicht nur ein Marketingversprechen – die TEE‑Architektur erzwingt sie auf Hardwareebene, unabhängig davon, was Venice oder einzelne Betreiber wollen.
Im weiteren Sinne spricht man von dezentraler KI‑Inference, und Venice ist nur eines von mehreren Projekten. Gensyn, io.net und Akash Network adressieren ebenfalls verteiltes GPU‑Compute – mit teils unterschiedlichen Privacy‑Garantien. Venice positioniert sich mit einem klaren Fokus auf Prompt‑Privatsphäre als oberste Design‑Maxime, nicht als Zusatzfeature.
Also lesenswert: Warren Buffett Calls Markets A Gambling Den, Then Bets Big On AI
Was Node‑Betreiber sehen – und was nicht
Hier lohnt Genauigkeit, denn „privat“ kann irreführend sein. In einer Venice‑artigen TEE‑Architektur wird die Sicht des Node‑Betreibers strikt durch die Hardware‑Grenze limitiert.
Was der Node‑Betreiber nicht sieht: den Klartext Ihres Prompts, alle Zwischenberechnungen im Modell sowie den Klartext der Antwort, bevor sie zur Rückgabe verschlüsselt wird.
Was der Node‑Betreiber sehen kann: dass seine Maschine gerade einen Job verarbeitet, die Größe von Anfrage und Antwort in Bytes, das Timing der Transaktion sowie die Wallet‑Adresse oder sonstige Kennung, sofern diese nicht zusätzlich anonymisiert wird.
Das bedeutet: Das System ist in Bezug auf Inhalte blind, nicht aber in Bezug auf Metadaten wie Traffic‑Muster und Zahlungsflüsse. Im strengsten Wortsinn ist nur der Inhalt privat – niemand kann sehen, was Sie abgefragt haben oder was das Modell geantwortet hat. Vollständig anonym sind Sie auf der Metadaten-Ebene jedoch nicht. Ein Betreiber kann erkennen, dass Adresse X um 14:22 UTC eine Eingabe mit 340 Token geschickt und eine Antwort mit 1.200 Token erhalten hat. Über längere Zeiträume lassen sich aus solchen Nutzungsmustern potenziell sensible Rückschlüsse ziehen – ganz ohne Zugriff auf den eigentlichen Inhalt.
Für die meisten praktischen Anwendungen – eine Kanzlei mit vertraulichen Mandatsanfragen, ein Arzt mit Differentialdiagnosen, ein Unternehmen mit proprietären Finanzdaten – ist genau diese Inhaltsvertraulichkeit der entscheidende Punkt. Metadaten-Risiken sind zweitrangig und lassen sich mit zusätzlichen Netzwerk-Layern wie VPN-Routing oder Zero-Knowledge-Identitäten abfedern.
TEE-basierte Systeme sichern die Inhaltsvertraulichkeit hardwareseitig ab. Metadaten-Schutz erfordert zusätzliche, anwendungsseitige Anonymisierung – und genau hier lassen aktuelle Implementierungen den Nutzer weitgehend allein.
Mehr dazu: Nvidia Details An 88-Core CPU Built To Undercut Intel And AMD
Die echten Trade-offs bei Geschwindigkeit, Kosten und Modellgröße
Private Inferenz gibt es nicht zum Nulltarif. Die Mehrkosten kommen aus mehreren Quellen – wer sie versteht, kann besser beurteilen, ob sich der Aufwand für den eigenen Use Case lohnt.
Geschwindigkeit. TEE-Enklaven bringen einen Overhead durch Speicherisolation mit sich. Verschlüsselte Speicherzugriffe und Attestierungs-Handshakes sorgen für zusätzliche Latenz gegenüber einem Bare-Metal-GPU-Setup mit klassischem Inferenz-Server.
In der Praxis läuft TEE-basierte Inferenz auf modernen AMD-EPYC-Systemen mit SEV-SNP laut Benchmarks des SUAVE-Teams von Flashbots und der AMD-Entwicklerdokumentation rund 10 bis 30 Prozent langsamer als vergleichbare Non-TEE-Setups. Spürbar, aber für die meisten dialogorientierten Anwendungen kein Showstopper.
Kosten. Dezentralisierte Compute-Netzwerke können die Stückkosten von Hyperscaler-GPU-Clustern derzeit nicht erreichen. Amazon, Google und Microsoft fahren derart große Volumina, dass die Grenzkosten pro tausend Tokens auf Bruchteile eines Cents sinken. Dezentralnetze haben diese Auslastungsdichte nicht. Venice und ähnliche Protokolle liegen mit ihren Inferenzpreisen deshalb typischerweise über klassischen Cloud-APIs. Dieser Aufschlag ist der explizite Preis für Privatsphäre.
Modellgröße. TEE-Enklaven verfügen nur über begrenzten geschützten Speicher. Ein 70-Milliarden-Parameter-Modell komplett innerhalb einer Enklave zu halten, ist auf heutiger Standard-Hardware faktisch nicht machbar.
In der Praxis gibt es drei Ansätze: kleinere Modelle (7 bis 13 Milliarden Parameter), Hybrid-Architekturen, bei denen nur die sensiblen Ein- und Ausgabeschichten in der TEE laufen, während die massenhaften Matrixmultiplikationen im ungeschützten Speicher stattfinden, oder der Einsatz verschlüsselter Modellgewichte statt eines Voll-Loads in die Enklave. Relevanz hat das, weil die leistungsstärksten Frontier-Modelle der GPT‑4-Klasse mit hunderten Milliarden Parametern unter den heutigen TEE-Beschränkungen nicht wirklich „privat“ betrieben werden können.
Die ehrliche Bilanz: Heute bekommen Sie starke Vertraulichkeit bei offenen Modellen im Bereich 7 bis 13 Milliarden Parameter – zu Kosten, die etwa beim Zwei- bis Fünffachen zentraler APIs liegen. Wenn Ihr Use Case in dieses Raster passt, ist die Architektur bereits heute produktionsreif.
Mehr dazu: Claude Fable 5 Just Ended An 87-Year Math Standoff, And Bitcoin Cares
Wer wirklich On-Chain-Private-AI-Inferenz braucht
Nicht jeder KI-Nutzer benötigt diesen Schutzgrad. Aber bestimmte Gruppen laufen sehr reale, unmittelbare Risiken durch Prompt-Logging – genau dort greift private Inferenz.
Juristen und Compliance-Profis nutzen KI für Dokumentenanalysen, Vertragsprüfungen und Recherche. Wer Mandantenkommunikation an einen zentralen KI-Dienst sendet, der Eingaben speichert, riskiert eine Aushöhlung des Anwaltsgeheimnisses und potenzielle Verstöße gegen Standesregeln, etwa in einigen US-Bundesstaaten. Private Inferenz eliminiert das Problem des Drittanbieter-Loggings.
Beschäftigte im Gesundheitswesen und Forscher unterliegen HIPAA-Vorgaben, die den Transfer und die Speicherung geschützter Gesundheitsdaten strikt regeln. Standard-ChatGPT für klinische Dokumentationen zu verwenden, erzeugt Compliance-Risiken. Ein TEE-basiertes System, das nachweislich keine Patientendaten persistiert, verschiebt das Risikoprofil fundamental.
Finanzanalysten und Trader, die mit kursrelevanten, nicht öffentlichen Informationen arbeiten, dürfen diese Daten nicht in Systeme einspeisen, in denen sie geloggt, durchsucht oder geleakt werden könnten. Private Inferenz erlaubt die Nutzung von KI-Tools auf sensiblen Deal-Daten, ohne eine regulatorisch verwertbare Datenspur zu hinterlassen.
Personen in Hochüberwachungsumgebungen – Journalistinnen, Aktivisten, Oppositionelle – benötigen unter Umständen KI-Hilfe für heikle Recherchen, ohne ein Suchprotokoll zu erzeugen. Standard-Tools werden hier zum Risiko. Private Inferenz nicht.
Unternehmen mit Schutzinteresse an Geschäftsgeheimnissen können F&E-Fragen, Wettbewerbsanalysen und Anfragen zu proprietären Formeln durch KI laufen lassen, ohne dass diese Informationen auf Drittservern landen, die gehackt, per Gerichtsbeschluss geöffnet oder einfach abgekratzt werden könnten.
Für Alltagsnutzer – E-Mails formulieren, kreative Texte generieren, Trivia beantworten – ist der Overhead privater Inferenz die Mehrkosten derzeit meist nicht wert. Mit sinkenden Kosten wird die Architektur auch für dieses Segment attraktiv. Momentan ist der Nutzen jedoch vor allem in den oben skizzierten Hochrisiko-Szenarien offensichtlich.
Mehr dazu: Telegram Will Put A Non-Custodial Gram Wallet In Every App, Durov Says
Fazit
On-Chain-Private-AI-Inferenz adressiert ein Problem, das vielen Nutzern bislang gar nicht bewusst war.
Zentralisierte KI-Anbieter loggen Prompts standardmäßig. Damit erhalten Konzerne – und potenziell auch Behörden – Einblick in einige der sensibelsten Denkprozesse ihrer Nutzer.
Die Antwort ist nicht, auf KI zu verzichten, sondern den Ort der Inferenz zu verlagern.
Trusted Execution Environments ermöglichen es schon heute, dass ein dezentraler Node-Betreiber Ihr Sprachmodell auf Ihrem Prompt ausführt, ohne diesen je im Klartext sehen zu können.
Die Hardware erzwingt diese Vertraulichkeitsgarantie auf einer Ebene, mit der keine Policy und keine AGB mithalten kann.
Venice Token ist derzeit die sichtbarste Implementierung dieser Architektur. Aber es steht für ein größeres Designmuster – eines, das sich im dezentralen KI-Sektor verbreiten dürfte, sobald GPU-Kosten weiter fallen und TEE-Hardware reifer wird.
Weiterlesen: Wawrinka's Last Clay Match Arrives Inside A 3M-User Prediction Market Boom