Privacy & DSGVO by Design am Edge

Die meisten KI-Projekte scheitern nicht an der Modellqualität, sondern an der Frage, wohin die Daten fließen. Ein Sensorwert, ein Maschinenprotokoll, ein Belegungsmuster in einem Gebäude. Sobald diese Daten zur Auswertung an eine Cloud gehen, beginnt eine lange Kette aus Auftragsverarbeitung, Drittlandtransfer und Zweckbindung. Datenschutz wird dann zur nachgelagerten Vertragsarbeit. Beim Edge Agent ist das umgekehrt. Datensouveränität ist keine Richtlinie, die man darüber legt, sondern eine Eigenschaft der Architektur. Die KI läuft dort, wo die Daten entstehen.

Datensouveränität als Architektureigenschaft

Ein KI-Agent auf der Maschine verarbeitet seine Eingaben lokal. Der Graph, der den Agenten beschreibt, läuft als ein einziges Binary direkt auf dem Gerät, vom kleinen Einplatinenrechner bis zum Industrie-PC. Die Intelligenz steckt in einem Knoten dieses Graphen, und dieser Knoten kann ein kleines Sprachmodell sein, das lokal neben der Engine läuft, über einen lokalen, OpenAI-kompatiblen Inferenz-Server. Für die meisten industriellen Aufgaben reicht ein On-Device-Modell mit ein bis drei Milliarden Parametern aus.

Der entscheidende Punkt ist, dass es bei lokaler Verarbeitung keinen Transfer in eine Drittland-Cloud gibt, der überhaupt rechtlich abgesichert werden müsste. Daten, die das Gerät nie verlassen, erzeugen keinen Verarbeitungsvertrag mit einem US-Anbieter. Das ist der Unterschied zwischen “wir haben den Datenschutz geregelt” und “es gibt nichts zu regeln, weil nichts abfließt”.

DSGVO-Prinzipien werden technisch erreichbar

Die DSGVO verlangt Datensparsamkeit und Zweckbindung. Auf dem Papier sind das Grundsätze. In einer Cloud-Pipeline sind sie schwer durchzusetzen, weil Rohdaten zentral landen und dort für alles Mögliche verfügbar werden. Lokale On-Device-KI dreht das um.

• Datensparsamkeit. Der Agent wertet den Rohwert vor Ort aus und gibt nur das Ergebnis weiter, etwa eine Klassifikation oder einen Parameter. Das Rohsignal bleibt auf dem Gerät.
• Zweckbindung. Der Workflow-Graph ist das Programm. Er ist endlich, inspizierbar und beschreibt deterministisch, welcher Knoten welche Daten anfasst. Was der Agent tut, ist nicht in einer Blackbox versteckt, sondern als Graph nachvollziehbar.
• Durable Memory liegt als lokale Datei auf dem Gerät. Eine Wissensbasis mit semantischer Suche läuft am Edge, statt jeden Kontext an einen externen Dienst zu schicken.

Wichtig ist die ehrliche Abgrenzung. “Lokal” beantwortet die Frage, wo die Daten verarbeitet werden. Es beantwortet nicht automatisch jede Sicherheitsfrage. Sobald ein Cloud-LLM, eine Websuche oder ein externer Retriever in den Graphen kommt, entstehen ausgehende Verbindungen. Vollständig abgeschottet läuft ein Edge Agent nur mit einem lokalen Modell. Diese Wahl trifft man bewusst pro Knoten, nicht implizit.

Open-Source-Kern statt Blackbox

Datenschutz, den man nicht prüfen kann, ist ein Versprechen, kein Nachweis. Der Kern des Systems, Engine, LLM-Proxy und der visuelle Builder, ist quelloffen und vollständig ohne Account nutzbar. Man kann den Code lesen, das System selbst hosten und nachvollziehen, was tatsächlich passiert. Es gibt keinen Vendor-Lock-in, der den Betrieb an eine fremde Cloud kettet. Das Backend ist eine Komfort- und Verwaltungsschicht für Flotten, kein Pflichtbestandteil. Wer maximale Kontrolle will, betreibt die Engine standalone und offline-by-default.

Sicherheitsarchitektur, die zur Datenhaltung passt

Lokale Verarbeitung ist die Basis, aber sie steht nicht allein. Die Sicherheitsarchitektur eines Edge Agent ruht auf drei realen Eigenschaften, nämlich lokaler Ausführung, Container-Isolation und signierter Image-Verteilung. Updates kommen als signierte Images, und der Deploy-Lifecycle umfasst Bootstrap-Bundle, Preflight, Heartbeat und Status. Der bounded Graph selbst ist ein Sicherheitsmerkmal. Weil er endlich und auditierbar ist, gibt es keine offene Agenten-Schleife, die unkontrolliert Aktionen auslöst.

An dieser Stelle gehört die CRA Readiness hin, und zwar nüchtern. Diese Architektur ist auf den EU Cyber Resilience Act ausgelegt, über lokale Ausführung, Container-Isolation, signierte Verteilung sowie geplante SBOM- und Signierungsschritte. CRA Readiness ist hier eine Architektureigenschaft, kein Zertifikat. Wir sagen bewusst nicht “CRA-konform” oder “CRA-zertifiziert” und nicht “auditiert”. Was wir sagen, ist, dass das Fundament so gebaut ist, dass die Anforderungen des CRA erreichbar werden, statt nachträglich aufgesetzt zu werden.

Ein Szenario im Gebäude mit sensiblen Bereichen

So könnte ein Edge Agent ein Problem lösen. In einem Wohn- oder Pflege-nahen Gebäude soll die Haustechnik auf Belegung reagieren. Lüftung, Heizung, Beleuchtung sollen sich an tatsächliche Nutzung anpassen, ohne dass Bewegungs- und Aufenthaltsdaten der Bewohner an einen externen Dienst gehen. Genau diese Daten sind besonders schützenswert.

Ein KI-Agent auf der Maschine wertet die Sensorsignale lokal aus. Über einen MQTT-Trigger kommt ein Belegungssignal herein, der Agent klassifiziert das Muster mit einem On-Device-Modell und schreibt nur das Ergebnis, etwa “Bereich aktiv”, in die Steuerung. Der Rohwert verlässt das Gerät nie. Es gibt keinen Cloud-Aufruf, der ein Belegungsprofil exportiert, und damit keinen Drittlandtransfer.

So läuft das am Edge

Technisch sitzt der Agent neben dem Regelkreis, nie darin. Das Muster heißt “agent-as-a-tool”. Der deterministische Controller läuft ununterbrochen weiter, der Agent schreibt nur Parameter, gepuffert. Konkret im Szenario.

• Trigger. Ein mqtt-message-Trigger reagiert auf ein eingehendes Belegungs-Topic, und ergänzend lässt sich ein Schwellwert-Trigger mit Deadband nutzen, um Rauschen zu dämpfen.
• Verarbeitung. Der Graph führt den Rohwert an einen Knoten mit lokalem SLM (1 bis 3 Milliarden Parameter) über den lokalen Inferenz-Server. Reicht eine Regel, greift die Intelligenz-Kaskade vorher, also Regeln vor klassischem ML vor On-Device-SLM. Frontier-Cloud ist die Ausnahme, nicht der Normalfall.
• Aktion. Das Ergebnis geht über einen MQTT-Publish- oder GPIO-Knoten an die Gebäudesteuerung. Echte Linux-Treiber, gepufferter Parameter, kein Eingriff in den Echtzeit-Loop.
• Verteilung. Dasselbe Binary läuft auf der Zielhardware ohne Neuschreiben, Updates kommen als signiertes Image.

Daten, die für eine Entscheidung gebraucht werden, werden dort verarbeitet, wo sie entstehen, und nur das Ergebnis wandert weiter. Eine ehrliche Einschränkung bleibt. Auch ein vollständig lokal rechnendes Gerät braucht eine physische Schnittstelle zur Anlage. “Lokal” löst die Frage der Datenhaltung, nicht die der physischen Integration.

Key Takeaways

• Datensouveränität ist beim Edge Agent eine Architektureigenschaft. Die KI läuft dort, wo die Daten entstehen, statt sie in eine Cloud zu schicken.
• Lokale Verarbeitung macht DSGVO-Datensparsamkeit und Zweckbindung technisch erreichbar und vermeidet Drittland-Transfers, weil nichts abfließt.
• Der quelloffene Kern ist ohne Account nutzbar und selbst hostbar, inspizierbar statt Blackbox, ohne Vendor-Lock-in.
• Die Sicherheitsarchitektur (lokale Ausführung, Container-Isolation, signierte Images, bounded Graph) ist auf den EU Cyber Resilience Act ausgelegt, mit CRA Readiness als Architektureigenschaft, nicht als Zertifikat.
• “Lokal” beantwortet das Wo der Datenverarbeitung. Vollständig abgeschottet läuft ein Edge Agent nur mit lokalem Modell, und die physische Integration bleibt eine eigene Frage.