Case Study: So habe ich KI-Architektur und EU KI-Verordnung-Compliance für ein Startup abgesichert
April 2026 · Damir Andrijanic · 5 Min. Lesezeit
KI-Coding-Assistenten machen es möglich, dass Gründer heute viel schneller ernsthafte Produkte bauen. Aber funktionierender Code ist noch keine launchfähige Architektur.
Genau diese Lücke wird kritisch, sobald ein Produkt personenbezogene Daten, OAuth-Credentials und kommende Pflichten aus der EU KI-Verordnung berührt.
Vor Kurzem meldete sich eine Gründerin namens Katherine bei mir, nachdem sie ComplianceRadar genutzt hatte. Ihre Node.js- und Cloudflare-Anwendung war funktional stark, aber ihr war klar: Vor dem Launch braucht sie einen echten Architektur-Check.
P0-Sicherheitslücke
Sensible OAuth-Daten lagen unverschlüsselt in der Datenbank und waren damit ein akutes Risiko.
Architektur übersetzen
Datenflüsse mussten sauber auf DSGVO- und EU KI-Verordnung-Pflichten abgebildet werden.
Legal und Technik angleichen
DPA, Terms und tatsächliches Systemverhalten mussten dieselbe Realität beschreiben.
Der Kontext
Wie bei vielen Startups im Frühstadium war das Produkt mit modernen KI-Tools sehr schnell gebaut worden. Diese Geschwindigkeit war ein Vorteil, aber genau dadurch waren manche Architekturentscheidungen noch nicht gegen Compliance- und Enterprise-Anforderungen getestet worden.
Die Gründerin wollte keine abstrakte Juristenantwort. Sie wollte praktisch wissen: Wo ist die Architektur verwundbar, was muss zuerst gefixt werden und wie müssen die Rechtsdokumente zur echten Softwarelogik passen?
Die Herausforderung
Bei der Prüfung sind zwei Punkte sofort herausgestochen:
- Unverschlüsselte sensible Daten at rest: Google-OAuth-Tokens lagen im Klartext vor. Unter DSGVO Artikel 32 ist das ein massives Sicherheitsproblem. Bei einem Datenbankleck könnten Angreifer direkt auf Google-Konten zugreifen.
- Fehlausrichtung zwischen DPA und Terms of Service: Es war unklar, wie sich Datenschutzpflichten aus dem DPA zu den allgemeinen Terms verhalten, vor allem dann, wenn rechtliche Texte und technische Realität nicht sauber zusammenpassen.
Die Lösung
Statt die Kundin mit Legal-Sprech zu erschlagen, habe ich das Ganze in einen Remediation-Plan übersetzt, den Gründerin und Engineering-Team sofort umsetzen konnten.
- Code-nahe Security-Fixes: Ich habe die unverschlüsselte Token-Speicherung als P0 markiert und die konkreten Node.js-Schritte beschrieben, um OAuth-Tokens per AES-256 at rest zu verschlüsseln.
- Architektur-Übersetzung: Ich habe die Datenflüsse auf DSGVO-Sicherheitsanforderungen und auf die Dokumentationslogik der EU KI-Verordnung abgebildet, damit das Backend auch für spätere Prüfungen vorbereitet ist.
- Compliance-Beratung in Klartext: Ich habe erklärt, dass der DPA bei Datenschutzfragen widersprüchliche Regelungen in den Terms übersteuert und dass die Rechtsdokumente exakt zum tatsächlichen Datenverhalten der Software passen müssen.
Das Ergebnis
Der Effekt war direkt spürbar. Die Gründerin konnte die gefährlichste Datenbank-Schwachstelle noch vor dem Launch schließen, Compliance-Risiko senken und mit deutlich mehr Sicherheit weitermachen.
Entscheidend war nicht nur, Probleme zu finden. Entscheidend war, Security, Architektur und rechtliche Anforderungen in einen konkreten Launch-Plan zu übersetzen, der für ein Startup realistisch funktioniert.
"Damir is very professional and knows our pains instantly. He also delivered in a very short amount of time. I would recommend him to anyone who is struggling to be GDPR compliant."
Mein Takeaway
Features bauen ist nur die halbe Arbeit. In der KI-Ära muss Architektur von Anfang an mit Compliance mitgedacht werden.
Ob über automatisiertes Scanning mit ComplianceRadar oder über konkrete Beratung: Sicherheits- und Compliance-Probleme vor dem Scale-up zu lösen ist fast immer die günstigste Engineering-Entscheidung.
Wenn du ein KI-Produkt baust und vor dem Launch Klarheit willst, dann teste zuerst die Architektur und nicht nur das UI.
Der einfachste Startpunkt ist complianceradar.dev ↗