Open Weights an der Edge: Wie offene Modelle Datenschutz und CRA schon auf dem Gerät lösen

Der Open-Weights-Brief von 25 US-Konzernen führt zur Gründung der Open Secure AI Alliance, die offene KI-Sicherheitstechnik auf Basis von Open-Weight-Modellen verwirklichen will. Für Embedded-Entwickler ist das ein Architektur-Argument: Wer offene, herunterladbare Modelle direkt auf eigener Hardware betreibt, holt Inferenz an die Edge — ohne dass sensible Daten je in eine fremde Cloud wandern.

von Otmar Weber, Founder Markt&Technik · KI-unterstützt

Sinnbild des Themas: Inferenz wandert vom Rechenzentrum zurück auf das Zielsystem.

01Was passiert ist

25 KI-Unternehmen — darunter Nvidia, Microsoft, Meta und Palantir — warnen Washington vor voreiligen Beschränkungen offener KI-Modelle. Die daraus entstandene Open Secure AI Alliance nennt Souveränität ausdrücklich als Vorteil offener Gewichte — und genau die entsteht an der Edge, wenn das Modell auf dem Zielsystem statt in der Cloud läuft. Auslöser der Debatte sind leistungsstarke chinesische Open-Weight-Modelle wie Kimi K3.

02Was das an der Edge bedeutet

Quantisierte offene Modelle (4- bis 8-Bit) laufen heute auf modernen Embedded-SoCs mit NPU oder dedizierten Edge-Beschleunigern. Als Laufzeit haben sich llama.cpp/GGUF und ONNX Runtime etabliert; kleine Mistral-, Llama- oder Qwen-Varianten decken viele Klassifikations-, Extraktions- und Assistenzaufgaben lokal ab. Der entscheidende Nebeneffekt: Verlässt kein Datum das Gerät, entfällt der gesamte Cloud-Datenpfad — und damit ein Großteil der DSGVO- und Angriffsflächen-Diskussion.

Wichtig bleibt: Die konkrete Machbarkeit ist immer am Zielsystem zu messen, nicht aus Benchmarks abzuleiten.

03CRA-Winkel für Entwickler

Der Cyber Resilience Act (Regulation (EU) 2024/2847) macht daraus einen handfesten Entwicklungs-Parameter.

Zwei CRA-Fristen im Blick

Meldepflichten nach Art. 14Greifen bereits ab dem 11. September 2026.
Volle AnforderungenSecurity-by-Design, Schwachstellenmanagement, SBOM, technische Dokumentation, CE — ab dem 11. Dezember 2027.

Eine cloudbasierte KI-Abhängigkeit ist eine Komponente, die man nur bedingt auditieren kann; ein self-hosted oder on-device betriebenes Modell mit bekannter Herkunft der Gewichte lässt sich sauber in die technische Dokumentation und das Schwachstellen-Handling einordnen. Die EU-Kommission hat am 27. Juli 2026 dazu praktische Leitlinien veröffentlicht.

04Praktischer Stack

In der Praxis bewährt sich eine zweistufige Architektur: ein quantisiertes offenes Modell on-device für latenzkritische und datensensible Aufgaben, dazu eine EU-API (z. B. Mistral) oder ein self-hosted Server-Tier auf deutscher Infrastruktur (Hetzner, IONOS, Open Telekom Cloud, STACKIT) für die schweren Fälle. Ein Router entscheidet pro Anfrage, was lokal bleibt und was hochskaliert.

On-DeviceQuantisiertes offenes Modell (4–8-Bit)

llama.cpp/GGUF oder ONNX Runtime auf dem Ziel-SoC. Keine Grenzkosten pro Anfrage, kein Cloud-Datenpfad — aber Machbarkeit ist am Gerät zu verifizieren.

EU-APIManaged API, z. B. Mistral

Für die schweren Fälle, die on-device nicht laufen. EU-Datenresidenz als Ausgangspunkt für die DSGVO-Prüfung.

Self-HostingServer-Tier auf DE-Infrastruktur

Hetzner, IONOS, Open Telekom Cloud, STACKIT. Wandelt variable Token- in fixe Infrastrukturkosten um.

05Kosten

Auch hier gilt: „open" ist nicht automatisch „billig" — chinesische Spitzenmodelle wie Kimi K3 liegen preislich auf Sonnet-Niveau. Der Embedded-Vorteil ist struktureller Natur: On-Device-Inferenz hat praktisch keine Grenzkosten pro Anfrage, und der Server-Tier lässt sich über Self-Hosting von variablen Token- auf fixe Infrastrukturkosten umstellen.

Takeaway für Embedded-Teams: Der Open-Weights-Trend ist keine Cloud-Randnotiz, sondern ein Architektur-Argument. Wer Inferenz ans Gerät oder auf EU-Infrastruktur holt, senkt Datenschutz- und CRA-Risiko an der Wurzel — und macht sich unabhängiger von einzelnen US-Anbietern.

🛠️ Ihre KI-Toolbox für diese Nachricht

🔴 Quick-Check-Prompt für Embedded & Entwicklung: „Der On-Device-Machbarkeits-Check"

Anwendungsfall: Vorab prüfen, ob ein Embedded-Use-Case lokal auf dem Zielsystem laufen kann — und wie sich das auf Datenschutz- und CRA-Risiko auswirkt.

Schritt-für-Schritt-Anleitung für den Leser:

Kopieren Sie den untenstehenden Prompt in ein DSGVO-konformes KI-Modell Ihrer Wahl.
Füllen Sie im Abschnitt MEIN USE-CASE die mit […] markierten Felder aus (Aufgabe, Zielhardware, Datenart, Latenz, Offline-Pflicht, aktueller Ansatz).
Behandeln Sie jede Machbarkeitsaussage als Richtwert — die reale Machbarkeit wird am Zielsystem gemessen, nicht aus Benchmarks abgeleitet.

Der Prompt zum Kopieren:

Du bist Embedded-KI-Architekt sowie CRA-/DSGVO-Analyst. Deine Aufgabe ist ausschließlich Analyse und Einordnung, KEINE Rechtsberatung. MEIN USE-CASE (ausfüllen): - Aufgabe ...............: [Klassifikation/Extraktion/Assistenz/...] - Zielhardware .........: [SoC/NPU, RAM, Beschleuniger?] - Datenart .............: [personenbezogen? sicherheitskritisch?] - Latenzbudget .........: [ms, Echtzeit nötig?] - Offline-Pflicht ......: [muss ohne Netz laufen? Ja/Nein] - Aktueller Ansatz .....: [Cloud-API / lokal / keiner] REGELN: - Nutze ausschließlich meine Angaben. Erfinde keine Benchmarks. - On-Device-Machbarkeit IMMER als "auf Zielhardware zu verifizieren" kennzeichnen — keine belastbare Aussage ohne Messung am Gerät. - Juristische Punkte (CRA-Nachweis, AVV, DSFA) als "durch Fachjurist:in zu verifizieren" markieren. GIB AUS: 1) On-Device machbar? [ja / bedingt / nein] + kurze Begründung, inkl. grober Modellgrößen-/Quantisierungs-Bandbreite (z. B. 3–8B, 4-Bit) — als Richtwert, nicht als Zusage. 2) Datenschutz-Ampel (rot/gelb/grün). 3) CRA-Einordnung: Modell als Komponente in der technischen Doku, Relevanz Art. 14 (Meldepflicht ab 11.09.2026), Update-/Supportdauer. 4) Empfohlener Stack, je 1 Satz Pro/Contra: A) On-Device (quantisiertes offenes Modell, llama.cpp / ONNX) B) EU-API (z. B. Mistral) für schwere Fälle C) Self-hosted Server-Tier auf DE-Infrastruktur 5) Drei Prüfpunkte: Herkunft/Lizenz der Gewichte, deklarierter Support-Zeitraum, SBOM für die KI-Komponente.

Nutzen: Eine schnelle Einordnung, ob sich der Aufwand für ein On-Device-Setup lohnt, bevor Hardware beschafft oder ein Cloud-Vertrag verlängert wird.

Der KI-Soforttest (ca. 15 Minuten): Prompt einfügen, Zielhardware und Use-Case eintragen, Empfehlung lesen.

Zu erwartendes Ergebnis: Eine Machbarkeits-Ampel (ja/bedingt/nein) mit grobem Modellgrößen-Richtwert, eine Datenschutz-Ampel, die CRA-Einordnung, ein empfohlener Stack (on-device / EU-API / self-hosted) und drei Prüfpunkte: Herkunft und Lizenz der Gewichte, deklarierter Support-Zeitraum, SBOM für die KI-Komponente.

Quelle: Offener Brief der Open-Weights-Koalition, 25. Juli 2026; NVIDIA, EU-Kommission, Umsetzungsleitlinien CRA, 27. Juli 2026 — KI-unterstützte Analyse, keine Rechtsberatung.

Ihr Otee