Eliza framework 2026: KI-Agenten, AI Act und DSGVO

Am 11. September 2026 markierte der ELIZAOS-Token ein neues Allzeittief: rund 0,00015 US-Dollar, umgerechnet etwa 0,00013 Euro, bei einer Marktkapitalisierung von gerade noch gut 1,25 Millionen US-Dollar (etwa 1,08 Millionen Euro), wie CoinGecko ausweist. Für einen Token, dessen Vorgänger ai16z Anfang 2025 auf einen Höchststand von rund 2,4 Milliarden US-Dollar geklettert war (CoinDesk), ist das eine Randnotiz. Gründer Shaw Walters hat den Token im August für tot erklärt und die Stiftung abgewickelt.

Und trotzdem: Das Framework dahinter, das quelloffene elizaOS, läuft weiter. Mit über 19.300 Sternen auf GitHub zählt es zu den meistbeachteten Bausätzen für autonome KI-Agenten überhaupt. Solche Agenten führen Kundengespräche, spielen NPCs in On-Chain-Spielen, verwalten DeFi-Positionen und halten eigene Wallets. Die eigentliche Nachricht im Herbst 2026 ist deshalb nicht der Kurs. Sie lautet: Der Rechtsrahmen, der lange nur angekündigt war, ist da. Seit dem 2. August gelten die Transparenzpflichten des AI Act, seit dem 29. Juli setzt Deutschland sie mit einem eigenen Gesetz durch, und die DSGVO stellt Fragen, auf die bislang niemand eine gute Antwort hat. Wer heute in Deutschland einen Eliza-Agenten produktiv betreibt, steht plötzlich im Schnittpunkt von vier Regelwerken. Dieser Text sortiert, was davon wirklich gilt.

Was ein Eliza-Agent ist, und warum das Juristen angeht

elizaOS ist ein in TypeScript geschriebenes Framework unter MIT-Lizenz. Der Kern ist eine Laufzeitumgebung, die eine sogenannte Character-Datei lädt (Persönlichkeit, Ziele, Wissen eines Agenten) und vier Bausteine orchestriert: Actions (was der Agent tut), Providers (welchen Kontext er heranzieht), Evaluators (was er bewertet und lernt) und Services (Hintergrundprozesse und Anbindungen). Plugins erweitern das Ganze: Ein Wallet-Plugin lässt den Agenten Transaktionen signieren, Konnektoren setzen ihn auf Discord, X oder in ein Spiel. Für Entwickler ist das ein eleganter Baukasten. Für Juristen ist jede dieser Eigenschaften ein Auslöser.

Vier Merkmale eines typischen Eliza-Agenten sind rechtlich heikel. Erstens interagiert er direkt mit Menschen, ob als Chatbot oder als NPC in einem Spiel. Zweitens führt er ein persistentes Gedächtnis, meist eine Vektordatenbank vergangener Gespräche. Drittens kann er eine Wallet halten und Werte bewegen. Viertens handelt er teilautonom, ohne dass für jede Entscheidung ein Mensch am Knopf sitzt. Das Modell, auf dem er denkt, ist austauschbar: mal ein zugekauftes Sprachmodell, mal ein lokal laufendes Open-Weight-Modell, wie es die dezentrale KI-Szene rund um Projekte wie Bittensor propagiert. Jede dieser Eigenschaften fällt unter ein anderes Regime.

Das ist keine akademische Spielerei. Agenten auf solchen Frameworks verwalten längst reale Summen, und je mehr echtes Geld durch sie fließt, desto mehr Aufmerksamkeit ziehen sie von Aufsehern, Datenschützern und Finanzämtern an. Ein Prototyp im Testnetz interessiert niemanden. Ein Agent, der in Deutschland mit Kunden spricht, ihre Daten speichert und Werte bewegt, ist ein reales Produkt mit realen Pflichten. Genau diesen Übergang vom Experiment zum Produkt vollzieht der Sektor gerade, und der Rechtsrahmen wartet am anderen Ende.

2026, das Jahr, in dem der KI-Rechtsrahmen scharf wird

Der AI Act, offiziell die Verordnung (EU) 2024/1689, gilt nicht auf einen Schlag, sondern in Stufen. Verbotene Praktiken wie manipulatives Design oder Social Scoring sind seit dem 2. Februar 2025 untersagt. Die Pflichten für Anbieter von Universalmodellen (General Purpose AI, kurz GPAI) laufen seit dem 2. August 2025. Und seit dem 2. August 2026 greifen die Transparenzpflichten des Artikels 50, wie die Europäische Kommission in ihren Erläuterungen bestätigt. Genau diese Stufe trifft KI-Agenten am unmittelbarsten.

Eine wichtige Verschiebung kam kurz vor der Sommerpause. Die Vorschriften für Hochrisiko-Systeme nach Anhang III sollten eigentlich ebenfalls ab dem 2. August 2026 gelten. Der sogenannte Digital Omnibus, die Verordnung (EU) 2026/1744, die am 27. Juli 2026 in Kraft trat, hat diese Frist um sechzehn Monate auf den 2. Dezember 2027 verschoben; für in regulierte Produkte eingebettete Systeme nach Anhang I sogar auf den 2. August 2028, wie die Kanzlei Gibson Dunn aufgeschlüsselt hat. Für die meisten Eliza-Agenten ist das aber nur ein Aufschub am Rand, denn ein gewöhnlicher Gesprächs- oder Spielagent ist kein Hochrisiko-System. Er lebt in der Transparenzstufe, und die gilt seit August. Wer die Pflichten verletzt, riskiert nach Artikel 99 empfindliche Bußgelder: bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes für die meisten Verstöße, bis zu 35 Millionen Euro oder 7 Prozent bei verbotenen Praktiken.

Artikel 50, der Agent muss sagen, dass er kein Mensch ist

Die für Eliza wichtigste Vorschrift ist Artikel 50 Absatz 1 des AI Act. Er verlangt, dass Anbieter KI-Systeme, die dazu bestimmt sind, direkt mit Menschen zu interagieren, so gestalten, dass die betroffenen Personen erkennen, dass sie es mit einer KI zu tun haben. Für einen Agenten heißt das konkret: Der Chatbot, der im Kundendienst antwortet, der Discord-Bot, der eine Community moderiert, der Handelsassistent, der Fragen zu Positionen beantwortet, jeder von ihnen muss sich offenbaren. Ein anonymer, menschlich wirkender Agent, der sich als Person ausgibt, ist ab August 2026 schlicht rechtswidrig.

Der Artikel kennt eine Ausnahme: Die Offenlegung entfällt, wenn es für eine verständige Person aus den Umständen offensichtlich ist, dass hier eine Maschine spricht. Ein comicartiger Roboter-NPC, der offen als Spielfigur auftritt, dürfte darunter fallen. Ein glaubwürdig menschlich schreibender Support-Agent fällt es nicht. Hinzu kommen die Kennzeichnungspflichten für synthetische Inhalte: Erzeugt ein Agent Texte, Bilder oder Audio, müssen diese als KI-generiert maschinenlesbar markiert werden, wobei für vor dem Stichtag in Verkehr gebrachte Systeme eine Übergangsfrist bis Dezember 2026 gilt. Das deutsche Schwesterstück dieses Textes zu KI-NPCs im Gaming hat den Punkt für Spielwelten schon skizziert: Ein NPC, der mit Spielern verhandelt, muss ehrlich sein, dass er ein Automat ist. Bemerkenswert an Artikel 50 ist, dass er risikounabhängig gilt. Er greift, egal in welcher Risikoklasse das System steckt.

In der Praxis reicht dafür ein sichtbarer Hinweis, eine feste Regel im System-Prompt oder, bei einem On-Chain-NPC, eine als KI erkennbare Kennung. Betreiber trifft zusätzlich Artikel 50 Absatz 4: Wer mit einem Agenten Deepfakes oder Texte zu Fragen von öffentlichem Interesse erzeugt und verbreitet, muss offenlegen, dass der Inhalt künstlich erzeugt ist. Für einen Krypto-Agenten, der Marktkommentare postet oder in sozialen Medien auftritt, ist das keine Randfrage, sondern die Regel, unter der er kommuniziert. Die Offenlegung als lästige Fußnote zu behandeln, wäre der falsche Reflex; sie ist die billigste Compliance-Maßnahme im ganzen Katalog.

Anbieter oder Betreiber? Die Rollenfrage nach dem Ende der Stiftung

Der AI Act verteilt Pflichten zwischen zwei Rollen: dem Anbieter, der ein KI-System entwickelt und unter eigenem Namen in Verkehr bringt, und dem Betreiber, der es unter eigener Verantwortung einsetzt. Der Anbieter trägt die schwereren Lasten. Entscheidend für die Open-Source-Welt ist Artikel 25, der die Verantwortung entlang der Wertschöpfungskette regelt: Wer ein System unter seinem Namen oder seiner Marke bereitstellt, es wesentlich verändert oder seinen Zweck umwidmet, wird selbst zum Anbieter. Übersetzt auf elizaOS bedeutet das: Wer den quelloffenen Baukasten nimmt, daraus einen produktiven Agenten baut und ihn unter eigener Flagge in Betrieb nimmt, trägt sehr wahrscheinlich den Anbieterhut für dieses konkrete System, obwohl er keine Zeile des Frameworks selbst geschrieben hat.

Diese Rollenfrage wird dadurch verschärft, dass es die zentrale Anlaufstelle nicht mehr gibt. Die Eliza Foundation ist abgewickelt. Shaw Walters entwickelt elizaOS weiter und besitzt die Rechte am Namen, hat sich vom Token aber losgesagt. „The token is dead. Completely“, schrieb er im August, und weiter, er fange neu an, da er das geistige Eigentum besitze, und werde nie wieder einen Token in die Nähe von Eliza lassen (dokumentiert bei Decrypt und The Block). Für Betreiber heißt das: Es gibt keinen Anbieter des Frameworks, an den sich Pflichten delegieren ließen. Der AI Act sieht für freie und quelloffene Komponenten zwar Erleichterungen vor, solange sie nicht als Hochrisiko- oder systemisches GPAI-Modell auftreten. Das regulierte Objekt ist deshalb nicht der Bausatz, sondern der ausgelieferte Agent. Die Verantwortung fließt zu dem, der ihn startet.

Diese Erleichterung für Open Source hat allerdings Grenzen. Sie greift nicht, wenn eine Komponente als Hochrisiko-System oder als Universalmodell mit systemischem Risiko eingestuft wird; dann gelten die vollen Anbieterpflichten unabhängig von der Lizenz. Für die meisten Eliza-Agenten ist das kein Thema, weil weder das Framework noch ein typischer Charakteragent diese Schwelle erreicht. Wer aber ein besonders großes Modell selbst betreibt oder den Agenten in einem sensiblen Bereich einsetzt, kann trotz quelloffener Basis in die schärfere Kategorie rutschen. Die Lizenz schützt den Code, nicht den Einsatz.

GPAI, die Pflichten treffen das Modell, nicht das Framework

Ein häufiges Missverständnis: Eliza sei ein KI-Modell. Ist es nicht. Das Framework orchestriert ein Sprachmodell, das man einsteckt, ob ein kommerzielles Modell oder ein lokal laufendes Open-Weight-Modell. Die GPAI-Pflichten des AI Act, die seit August 2025 gelten, richten sich an die Modellanbieter: technische Dokumentation, eine Zusammenfassung der Trainingsdaten, eine Urheberrechts-Policy, für Modelle mit systemischem Risiko zusätzliche Prüfungen. Ein deutscher Betreiber eines Eliza-Agenten schreibt diese Dokumente nicht selbst, muss aber konforme Modelle wählen und die Nachweiskette aufbewahren.

Genau hier wird die Architekturentscheidung zur Rechtsfrage. Wer ein lokales Modell auf eigener Hardware betreibt, verschiebt die Anbieterrolle für das Modell möglicherweise auf sich selbst und erhöht damit die eigene Dokumentationslast. Ethereum-Mitgründer Vitalik Buterin argumentiert seit Monaten für genau diesen lokalen Ansatz: „All LLM inference local first. All files hosted locally. Sandbox everything“, schrieb er in seinem Aufsatz zu sicheren Sprachmodellen, verbunden mit dem Vorschlag, autonome Ausgaben eines Agenten auf etwa 100 Dollar pro Tag zu deckeln und den Menschen als zweiten Bestätigungsfaktor einzubauen. Lokale, überprüfbare Inferenz ist auch der Pitch von Infrastrukturprojekten wie Ritual, die vertrauliche und nachweisbare Modellläufe versprechen. Für die Compliance ist das kein Detail: Wo das Modell läuft, entscheidet mit darüber, wer welche AI-Act-Pflichten trägt.

Das übersehene Gesetz, die DSGVO und das Gedächtnis des Agenten

Die am meisten unterschätzte Ebene ist nicht der AI Act, sondern die DSGVO. Das prägende Merkmal eines Eliza-Agenten ist sein Gedächtnis: Er speichert vergangene Gespräche, Nutzerangaben und Vorlieben in einer Datenbank, um beim nächsten Mal daran anzuknüpfen. Sobald sich diese Einträge auf identifizierbare Menschen beziehen, und das tun sie in der Praxis fast immer, verarbeitet der Agent personenbezogene Daten. Damit ist der Betreiber Verantwortlicher im Sinne der DSGVO, mit allem, was dazugehört: einer Rechtsgrundlage, Datenschutz durch Technikgestaltung (Artikel 25) und Betroffenenrechten.

Als Rechtsgrundlage kommt neben der Einwilligung das berechtigte Interesse nach Artikel 6 Absatz 1 Buchstabe f in Betracht. Der Europäische Datenschutzausschuss hat in seiner Stellungnahme 28/2024 vom 17. Dezember 2024 klargestellt, dass Verantwortliche sich für Entwicklung und Einsatz von KI-Modellen grundsätzlich darauf stützen können, allerdings nur nach einem dreistufigen Abwägungstest, und dass die Frage der Anonymität eines Modells stets im Einzelfall zu prüfen ist. Richtig hart wird das Recht auf Löschung (Artikel 17): Wie entfernt man die Spuren einer einzelnen Person aus dem gelernten Gedächtnis eines Agenten und aus dem Kontext eines Modells? Und die Angriffe, die dieses Gedächtnis manipulieren, sind nicht nur ein Sicherheitsthema. Die Princeton-Studie „Real AI Agents with Fake Memories“ zeigte, dass sich Web3-Agenten, mit elizaOS als Referenzframework, durch vergiftete Speichereinträge gezielt in die Irre führen lassen (Decrypt). Ein manipuliertes Gedächtnis verletzt zugleich die DSGVO-Grundsätze der Richtigkeit und Integrität nach Artikel 5 und kann damit eine meldepflichtige Datenpanne sein.

Zwei weitere Punkte werden gern übersehen. Trifft ein Agent automatisiert Entscheidungen mit rechtlicher Wirkung, etwa über die Ablehnung eines Nutzers, greift Artikel 22 DSGVO mit seinem grundsätzlichen Verbot rein automatisierter Einzelentscheidungen und dem Anspruch auf menschliches Eingreifen. Und weil ein Agent, der Nutzerdaten systematisch auswertet, in der Regel eine risikoreiche Verarbeitung darstellt, ist vorab eine Datenschutz-Folgenabschätzung fällig. Läuft das Sprachmodell zudem auf US-Infrastruktur, verlassen die Gedächtnisinhalte den europäischen Raum, und der Transfer muss über einen zulässigen Mechanismus abgesichert sein, etwa das EU-US Data Privacy Framework oder Standardvertragsklauseln. Wer local-first arbeitet, umgeht dieses Problem elegant, ein weiteres Argument für Buterins Ansatz.

Wenn der Agent eine Wallet hat, MiCA, MiFID II und die BaFin

Die Ebene, die den Token tatsächlich getötet hat, ist die Kryptoregulierung. MiCA, die Verordnung (EU) 2023/1114, reguliert Emittenten und Dienstleister (Crypto-Asset Service Provider, kurz CASP), nicht das Protokoll und nicht das Framework. Die Übergangsphase endete am 1. Juli 2026; ein CASP braucht seither eine Zulassung der BaFin, wie das MiCA-Zulassungsverfahren zeigt, das die BaFin in ihrem Merkblatt zu Kryptowerte-Dienstleistungen beschreibt. Ein Eliza-Agent, der nur seine eigene Wallet verwaltet und für sich selbst tauscht, ist deshalb noch kein CASP.

Anders sieht es aus, sobald der Agent für Dritte handelt. Verwaltet oder handelt er fremdes Vermögen oder gibt er Empfehlungen, kippt die Einordnung schnell in die Welt der Wertpapierdienstleistungen nach MiFID II, die von MiCA getrennt ist und ebenfalls die BaFin beaufsichtigt. Die ESMA hat in ihrer Erklärung zum Einsatz künstlicher Intelligenz in Wertpapierdienstleistungen betont, dass Governance, Transparenz und menschliche Aufsicht auch dann gelten, wenn eine KI berät oder ein Portfolio verwaltet. Der Token-Launch von ai16z war der regulierte, gefährliche Teil des Projekts, und genau er war Gegenstand der Sammelklage von Burwick Law (Justia-Docket), die im August durch Übertragung der Restmittel beigelegt wurde. Das Framework selbst ist kein Finanzinstrument. Gestorben ist der Token, nicht der Code.

Deutschland macht ernst, KI-MIG, Bundesnetzagentur und BaFin

Bis Sommer 2026 war der AI Act für deutsche Betreiber vor allem europäisches Recht ohne sichtbaren Vollzug. Das hat sich geändert. Am 29. Juli 2026 trat das Gesetz zur Marktüberwachung und Innovationsförderung von künstlicher Intelligenz (KI-MIG) in Kraft, dessen Regierungsentwurf im Februar 2026 beschlossen worden war. Es macht die Bundesnetzagentur zur zentralen Marktüberwachungsbehörde, zur einheitlichen Anlaufstelle und zur Beschwerdestelle für Verstöße gegen die KI-Verordnung. Die Behörde betreibt ein Koordinierungs- und Kompetenzzentrum (KoKIVO), einen KI-Service-Desk mit einem Online-Werkzeug zur Risikoeinstufung und ein KI-Reallabor, in dem vor allem KMU neue Systeme in kontrollierter Umgebung testen können. „Die KI-Verordnung ist ein Meilenstein für den verantwortungsvollen Einsatz von Künstlicher Intelligenz in Europa“, erklärte Behördenpräsident Klaus Müller zum Start (Bundesnetzagentur).

Für Finanzanwendungen bleibt die BaFin zuständig. Sie überwacht KI-Systeme, die in direktem Zusammenhang mit einer regulierten Finanztätigkeit stehen, von der Kreditwürdigkeitsprüfung bis zum Kunden-Chatbot einer Bank, und kann bei Verstößen Bußgelder verhängen. „Die Menschen müssen sich darauf verlassen können, dass ihre Grundrechte beim Einsatz von KI geschützt werden“, sagte BaFin-Präsident Mark Branson am selben Tag (BaFin). Ein deutscher Eliza-Betreiber hat es damit im Zweifel mit drei Adressaten zu tun: der Bundesnetzagentur für den AI Act im Allgemeinen, der BaFin, sobald der Agent regulierte Finanzdienste berührt, und der zuständigen Landesdatenschutzbehörde für die DSGVO.

Zwei Pflichten gelten schon länger und werden trotzdem oft vergessen. Seit Februar 2025 verlangt Artikel 4 des AI Act eine ausreichende KI-Kompetenz beim Personal, das solche Systeme betreibt; ein Team, das einen Agenten produktiv fährt, muss also nachweisen können, dass es die Risiken versteht. Und für Hochrisiko-Systeme sieht Artikel 73 eine Meldepflicht für schwerwiegende Vorfälle vor, die neben die DSGVO-Meldung tritt. Für den normalen Transparenz-Agenten ist Letzteres noch nicht Pflicht, doch die Richtung ist klar: Vorfälle sollen künftig gemeldet, nicht verschwiegen werden.

Sicherheit ist jetzt auch Compliance

Bislang galt die Sicherheit autonomer Agenten als technisches Problem: ein Verlust, ärgerlich, aber Sache der Entwickler. Mit dem neuen Rechtsrahmen wird sie zur Compliance-Frage. Der bekannteste Vorfall bleibt der Grok/Bankr-Drain vom 4. Mai 2026, bei dem ein Angreifer über eine in Morsecode versteckte Anweisung und ein Rechte erweiterndes NFT einen Agenten dazu brachte, Token im Wert von rund 175.000 Dollar auf Base zu verschieben (OECD.AI Incident Monitor). Die Ursache ist strukturell: Ein Sprachmodell kann Anweisung und Daten nicht sauber trennen, das klassische Prompt-Injection-Problem (OWASP LLM01). Die bereits erwähnte Memory-Injection geht noch weiter, weil sie den gespeicherten Kontext dauerhaft vergiftet.

Rechtlich hat das Folgen auf mehreren Ebenen zugleich. Für Hochrisiko-Systeme verlangt der AI Act in Artikel 15 ausdrücklich Genauigkeit, Robustheit und Cybersicherheit. Selbst außerhalb der Hochrisikoklasse ist ein Sicherheitsvorfall, der personenbezogene Daten abfließen lässt oder verändert, eine DSGVO-Datenpanne. Und bewegt der Agent Kundengelder, greifen die operativen Anforderungen der Finanzaufsicht bis hin zu DORA, dem EU-Regelwerk für digitale operationale Resilienz. Der alte Zielkonflikt zwischen Autonomie und Sicherheit, jede Ausgabengrenze und jede menschliche Freigabe beschneidet die Selbstständigkeit des Agenten, ist damit auch ein Compliance-Konflikt geworden. Buterins Deckelung auf 100 Dollar pro Tag ist aus dieser Sicht kein Feature, sondern eine Risikominderung, die man im Zweifel dokumentieren will.

Praktisch heißt das: Ein produktiver Eliza-Agent braucht mehr als guten Willen. Sinnvoll sind eng gefasste Berechtigungen für jedes Plugin, Allow-Lists für Adressen und Vertragsaufrufe, signierte und nachvollziehbare Aktionen, ein isolierter Ausführungskontext für nicht vertrauenswürdige Eingaben und eine Freigabe durch einen Menschen oberhalb definierter Schwellen. Das ist genau die Sandbox-Logik, die Buterin meint. Bewegt der Agent Kundengelder, kommt mit DORA eine eigene Schicht an Anforderungen hinzu: Test-, Meldewege- und Auslagerungspflichten, die eigentlich für Finanzunternehmen gedacht sind, aber jeden treffen, der als solches gilt. Sicherheit ist damit nicht mehr die Kür nach dem Launch, sondern die Voraussetzung dafür.

Haftung, ein Agent hat keine Rechtspersönlichkeit

Ein Agent kann nicht verklagt werden. Er hat keine Rechtspersönlichkeit, keine Steuernummer, kein Vermögen. Wenn etwas schiefgeht, trifft die Haftung Menschen: den Betreiber, der ihn in Betrieb genommen hat, den Entwickler, der das Framework verändert hat, den Modellanbieter oder den Nutzer, je nachdem, wer den schadensstiftenden Umstand kontrolliert hat. Diese Zurechnung ist die eigentliche Konsequenz aus der Anbieter-Betreiber-Systematik des AI Act.

Zwei europäische Entwicklungen verschärfen die Lage. Erstens hat die Europäische Kommission die geplante KI-Haftungsrichtlinie im Februar 2025 zurückgezogen, weil sich die Mitgliedstaaten nicht einigen konnten (Bird & Bird). Damit fehlt ein Sonderregime, das Geschädigten den Nachweis erleichtert hätte. Zweitens füllt die reformierte Produkthaftungsrichtlinie (EU) 2024/2853 diese Lücke teilweise: Sie zählt Software und KI-Systeme ausdrücklich zu den Produkten und unterwirft ihre Anbieter einer verschuldensunabhängigen Haftung, ähnlich wie klassische Warenhersteller. Die Richtlinie ist von den Mitgliedstaaten bis zum 9. Dezember 2026 umzusetzen und gilt für Produkte, die danach in Verkehr gebracht werden (Reed Smith). Für einen deutschen Betreiber heißt das nüchtern: Leert ein Agent über eine Injection, die man hätte abwehren müssen, die Wallet eines Kunden, landet die Forderung bei der verantwortlichen Person oder dem Unternehmen, nicht bei der Maschine.

Im deutschen Zivilrecht kommen die üblichen Anspruchsgrundlagen hinzu, von der Haftung aus Vertrag über die deliktische Haftung nach Paragraf 823 BGB bis zur Haftung für Erfüllungs- und Verrichtungsgehilfen, wobei der Agent kein Gehilfe im Rechtssinne ist, sondern ein Werkzeug des Betreibers. Die neue Produkthaftung verschiebt zudem die Beweislast zugunsten Geschädigter, wenn ein System zu komplex ist, um seinen Fehler leicht nachzuweisen. Für Betreiber folgt daraus eine unromantische Konsequenz: Wer autonome Agenten kommerziell einsetzt, braucht klare vertragliche Rollenverteilungen, sauber dokumentierte Sicherheitsmaßnahmen und im Zweifel eine passende Versicherung. Die Haftung verschwindet nicht, nur weil eine Software die Entscheidung getroffen hat.

Die Steuerfrage für den Betreiber

Was ein Agent an Kryptowerten hält, wird steuerlich dem Wallet-Inhaber zugerechnet. In Deutschland gelten Kryptowerte als anderes Wirtschaftsgut im Sinne des Paragrafen 23 EStG. Werden sie innerhalb eines Jahres veräußert, ist der Gewinn mit dem persönlichen Satz steuerpflichtig, der bis über 45 Prozent zuzüglich Solidaritätszuschlag reichen kann; nach Ablauf der einjährigen Haltefrist ist der Verkauf steuerfrei. Es gilt eine Freigrenze von 1.000 Euro pro Jahr, und für die Zuordnung greift die FIFO-Methode. Maßgeblich ist das BMF-Schreiben vom 6. März 2025.

Für einen autonomen Agenten ist das ein Minenfeld. Jede Zahlung in einer Stablecoin ist steuerlich eine Veräußerung, sodass ein Agent, der viele kleine Transaktionen ausführt, tausende steuerlich relevante Vorgänge im Jahr erzeugt, mit Kursdifferenzen zwischen Dollar-Stablecoin und Euro, die kleine Gewinne oder Verluste auslösen können. Noch heikler: Hochfrequenter, rund um die Uhr laufender Handel kann die Grenze zur gewerblichen Tätigkeit überschreiten. Dann fällt Gewerbesteuer an, und das einjährige Haltefristprivileg entfällt. Wer einen handelnden Agenten betreibt, braucht deshalb ein lückenloses Transaktionsprotokoll und sollte die Gewerblichkeitsfrage früh mit einem Steuerberater klären.

Wird der Agent gewerblich betrieben, etwa als Dienstleistung für Kunden, kommt die Umsatzsteuer ins Spiel: Die Leistung selbst kann steuerbar sein, während der reine Tausch von Kryptowerten in der Regel umsatzsteuerfrei bleibt. Wichtiger als jede Feinheit ist am Ende die Buchführung. Ein Agent produziert Belege im Sekundentakt, und ohne saubere, automatisierte Erfassung jeder Transaktion, mit Zeitstempel, Kurs und Zweck, wird die Steuererklärung zur Zumutung und die Betriebsprüfung zum Risiko. Wer die Protokollierung von Anfang an einbaut, spart sich später den teuersten Teil.

Regeln als Auslese, was das für den Sektor heißt

Der Markt für KI-Agenten-Token ist noch da, aber gedämpft. Die Kategorie AI Agents kam Mitte September 2026 auf rund 3,3 Milliarden US-Dollar (etwa 2,84 Milliarden Euro), so CoinGecko, weit entfernt von den überzogenen Bewertungen des Vorjahres. Eliza hat aus dieser Welt einen radikalen Schluss gezogen und den Token gekappt. Das Framework finanziert sich seither über Dienstleistungen, White-Label-Produkte und kommerzielle Infrastrukturpartner statt über Spekulation. Diese tokenlose Wende ist mehr als eine Fußnote, denn sie trifft auf einen Rechtsrahmen, der Kosten verursacht.

Genau darin liegt die eigentliche Dynamik: Die Regeln wirken als Auslese. Anbieterregistrierung, DSGVO-Verantwortlichkeit, Sicherheitsaudits, Transaktionsprotokolle und Haftungsvorsorge kosten Geld und Personal. Das begünstigt gut kapitalisierte, kommerzielle Betreiber gegenüber anonymen Teams, die früher einen Token starteten und weiterzogen. Das Framework überlebt seinen Token, aber die Schwelle, einen Agenten legal in Produktion zu bringen, steigt. Wer sie überspringt, ist nicht mehr der schnellste Launchpad-Held, sondern der sorgfältigste Betreiber.

Man sieht das bereits an den Akteuren, die kommerziell auf elizaOS setzen. Anbieter von White-Label-Automatisierung für kleine und mittlere Unternehmen, Infrastrukturteams, die eigene, geprüfte Plugin-Registries pflegen, und Dienstleister, die Agenten als betreutes Produkt verkaufen, können die Kosten für Audits, Datenschutz und Dokumentation auf viele Kunden verteilen. Ein anonymer Solo-Entwickler, der einen Agenten mit Wallet auf X postet, kann das nicht. Das ist die stille Ironie dieses Jahres: Ausgerechnet der Tod des Tokens, der einst jedem den schnellen Einstieg versprach, macht das Framework reifer, weil nur noch ernsthafte Betreiber die Auflagen tragen.

Was Entwickler und Unternehmen jetzt tun sollten

Die gute Nachricht: Nichts davon macht Eliza-Agenten unmöglich. Es macht sie zu einem Projekt, das man wie ein reguliertes Produkt behandeln muss, nicht wie ein Wochenendexperiment. Eine praktische Reihenfolge für einen Start in Deutschland:

• Einstufen: Prüfen, ob der Agent nur unter Artikel 50 fällt (der Regelfall) oder in eine Hochrisikokategorie rutscht, etwa bei Kreditwürdigkeit oder Beschäftigung.
• Kennzeichnen: Der Agent muss sich sichtbar als KI zu erkennen geben; generierte Inhalte maschinenlesbar markieren.
• Datenschutz: Rechtsgrundlage festlegen, eine Datenschutz-Folgenabschätzung machen und ein echtes Löschkonzept für das Gedächtnis bauen.
• Modell: Nur GPAI-konforme Modelle einsetzen, die Anbieterdokumentation aufbewahren und eine Local-first-Variante ernsthaft prüfen.
• Wallet: Ausgabenlimits setzen, oberhalb von Schwellen einen Menschen freigeben lassen und die MiCA- sowie MiFID-II-Relevanz klären.
• Sicherheit: Gegen Prompt- und Memory-Injection härten, Audits einplanen, Laufzeitüberwachung einrichten.
• Haftung: Rollen als Anbieter oder Betreiber vertraglich sauber verteilen und Versicherungsschutz prüfen.
• Steuer: Jede Transaktion protokollieren, FIFO anwenden und das Gewerblichkeitsrisiko bewerten.

Der rote Faden dieses Jahres ist damit klar. Der Token ist gestorben, weil er der spekulative, regulatorisch angreifbare Teil war. Das Framework lebt, weil Software kein Finanzinstrument ist. Doch mit dem AI Act, der DSGVO, MiCA, MiFID II und der neuen Produkthaftung ist die Zeit vorbei, in der man einen autonomen Agenten mit Wallet einfach ins Netz stellte und hoffte. Die nächste Bewährungsprobe steht schon im Kalender: Ende 2027 werden die Hochrisikoregeln scharf. Gewinnen werden die Betreiber, die Compliance nicht als Bremse begreifen, sondern als Teil des Produkts.

Häufige Fragen (FAQ)

Ist das Eliza-Framework selbst reguliert oder verboten?

Nein. Das quelloffene Framework ist Software und damit kein Finanzinstrument. Reguliert werden der konkrete Agent, den jemand damit in Betrieb nimmt, sowie Token und Wallet-Dienste. Der AI Act erfasst KI-Systeme im Einsatz, nicht den Bausatz.

Muss ein Eliza-Agent offenlegen, dass er eine KI ist?

Ja, seit dem 2. August 2026. Artikel 50 des AI Act verlangt, dass Menschen erkennen können, dass sie mit einer KI interagieren, es sei denn, das ist aus den Umständen ohnehin offensichtlich.

Was passiert mit dem Gedächtnis des Agenten unter der DSGVO?

Das persistente Gedächtnis verarbeitet meist personenbezogene Daten. Der Betreiber ist damit Verantwortlicher, braucht eine Rechtsgrundlage, muss Datenschutz durch Technikgestaltung beachten und ein Löschkonzept vorhalten, denn das Recht auf Löschung nach Artikel 17 gilt auch hier.

Wer haftet, wenn ein autonomer Agent Geld verliert?

Der Agent hat keine Rechtspersönlichkeit, also trifft die Haftung die dahinterstehenden Menschen: Betreiber, Entwickler oder Modellanbieter, je nachdem, wer den Fehler kontrolliert hat. Die reformierte EU-Produkthaftung erfasst Software und KI zusätzlich mit einer verschuldensunabhängigen Haftung.

Welche Behörde ist in Deutschland zuständig?

Seit dem KI-MIG vom 29. Juli 2026 ist die Bundesnetzagentur die zentrale Marktüberwachungsbehörde und Anlaufstelle. Im Finanzsektor überwacht die BaFin, und für den Datenschutz sind die Landesdatenschutzbehörden zuständig.

Von Marcus Okafor, Redakteur bei HOGE Wire mit Schwerpunkt KI, Krypto und Regulierung.