Ich bin zwar nur Entwickler und kein DSGVO-Experte... aber

TL;DR: Ich habe mir einen Custom Skill für Claude Code geschrieben, der meinen Flutter-Code vor jedem Merge auf DSGVO-Konformität prüft. Er hat echte Probleme gefunden: Sentry hat PII an US-Server geschickt, Consent lief nur auf iOS, der Consent-State hing in einer globalen Variable, und Apples ATT war komplett überflüssig, weil kein SDK die IDFA nutzt. Hier zeige ich den Skill, die Findings und den Code, den ich daraufhin geschrieben habe.

Der Post setzt Flutter-Kenntnisse voraus (BLoC, freezed) und ein grobes Verständnis der DSGVO (EU-Verordnung 2016/679). Jura-Wissen braucht ihr nicht. Das ist ja genau der Punkt.

Das Problem

Ich arbeite als Freelancer an einer Health-App für einen deutschen Kunden. Flutter, B2C, noch vor dem Go-Live. Gesundheitsdaten, deutsche Nutzer. DSGVO auf Schwierigkeitsstufe: hoch.

Die Consent-Implementierung in der Codebase bestand aus einem einzigen Aufruf: Apples ATT-Prompt auf iOS. Fertig. Android-Nutzer? Kein Consent. Gar keiner. Das ATT-Ergebnis wurde nicht mal richtig persistiert, sondern lebte in einer globalen Variable in globals.dart. Und Sentry lief mit sendDefaultPii: true und attachScreenshot: true, hat also fleißig Nutzerdaten und Screenshots von Gesundheits-Screens an US-Server geschickt.

Absicht war das nicht. Es ist über Sprints reingewachsen, wie das halt passiert. Tracking-SDK hier, Debug-Flag dort vergessen.

Ich bin kein Anwalt. Kein Datenschutzbeauftragter. Aber ich bin der Entwickler, der diesen Code ausliefert. Und mir war klar: Ich brauche eine systematische Methode, um Privacy-Probleme zu finden. Nicht einmal, sondern bei jedem Branch.

Der Ansatz: ein DSGVO-Audit-Skill für Claude Code

Die Idee: eine strukturierte Prompt-Datei, die Claude Code beibringt, meinen Quellcode gegen die DSGVO (EU-Verordnung 2016/679) zu prüfen. Statt dass ich bei jedem Branch manuell nach PII-Feldern, Consent-Lücken und SDK-Konfigurationen suche, macht das die KI und referenziert dabei konkrete Artikel.

Claude Code hat sogenannte "Skills", also Prompt-Dateien, die der KI spezialisiertes Wissen für bestimmte Aufgaben mitgeben. Ich habe einen geschrieben namens /gdpr-audit. Der macht aus Claude einen systematischen DSGVO-Reviewer.

Der Skill sagt nicht "du solltest mal deinen Consent-Flow checken". Er geht die Codebase systematisch durch.

Er fängt damit an, alle Datenflüsse zu inventarisieren: PII-Felder, Auth-Tokens, Device-IDs, gesundheitsbezogene Begriffe, Analytics-Events, Error-Reporting-Config. pubspec.yaml, Info.plist, AndroidManifest.xml, alles.

Danach gleicht er das mit konkreten DSGVO-Artikeln ab. Nicht irgendwelche "Privacy Best Practices", sondern die Verordnung selbst:

Am Ende spuckt er einen Report aus: Dateipfade, Zeilennummern, DSGVO-Artikel-Referenzen. Severity, Risikobewertung, konkreter Fix-Vorschlag pro Finding.

Die Skill-Definition ist ca. 195 Zeilen Markdown. Im Grunde eine Checkliste. Aber eine, die ich garantiert nicht bei jedem Branch von Hand durchgehen würde.

Was er gefunden hat

Ich habe /gdpr-audit auf meinem Feature-Branch laufen lassen. Hier die Findings, auf die es ankam:

Sentry als PII-Schleuder

// Vorher - lib/main.dart
options.sendDefaultPii = true;
options.attachScreenshot = true;
options.screenshotQuality = SentryScreenshotQuality.low;
options.attachViewHierarchy = true;
options.maxRequestBodySize = MaxRequestBodySize.always;

// Vorher - lib/main.dart
options.sendDefaultPii = true;
options.attachScreenshot = true;
options.screenshotQuality = SentryScreenshotQuality.low;
options.attachViewHierarchy = true;
options.maxRequestBodySize = MaxRequestBodySize.always;

// Vorher - lib/main.dart
options.sendDefaultPii = true;
options.attachScreenshot = true;
options.screenshotQuality = SentryScreenshotQuality.low;
options.attachViewHierarchy = true;
options.maxRequestBodySize = MaxRequestBodySize.always;

Der Audit hat das unter Art. 32 (Sicherheit der Verarbeitung) und Art. 9 (besondere Kategorien) geflaggt. Screenshots von Screens, die Gesundheitsinteressen zeigen, wurden an Sentrys US-Infrastruktur gesendet. Request Bodies mit Auth-Tokens gingen mit. Die View Hierarchy hat Widget-Trees mit Nutzerdaten exponiert.

Der Fix:

// Nachher - lib/main.dart
options.sendDefaultPii = false;
options.attachScreenshot = false;
options.maxRequestBodySize = MaxRequestBodySize.never;
options.beforeSend = _stripSensitiveData;

// Nachher - lib/main.dart
options.sendDefaultPii = false;
options.attachScreenshot = false;
options.maxRequestBodySize = MaxRequestBodySize.never;
options.beforeSend = _stripSensitiveData;

// Nachher - lib/main.dart
options.sendDefaultPii = false;
options.attachScreenshot = false;
options.maxRequestBodySize = MaxRequestBodySize.never;
options.beforeSend = _stripSensitiveData;

Dazu ein beforeSend-Callback, der URLs mit Consent-Parametern, Subscription-Keys oder Access-Tokens aus den Breadcrumbs schwärzt:

SentryEvent? _stripSensitiveData(SentryEvent event, Hint hint) {
  final breadcrumbs = event.breadcrumbs?.map((b) {
    if (b.data != null && b.data!.containsKey('url')) {
      final url = b.data!['url']?.toString() ?? '';
      if (url.contains('b2c_cmp_') ||
          url.contains('Subscription-Key') ||
          url.contains('access_token')) {
        final sanitized = Map<String, dynamic>.from(b.data!);
        final uri = Uri.tryParse(url);
        sanitized['url'] = uri != null
            ? '${uri.scheme}://${uri.host}${uri.path}?[REDACTED]'
            : '[REDACTED]';
        return Breadcrumb(
          message: b.message,
          category: b.category,
          type: b.type,
          data: sanitized,
          level: b.level,
          timestamp: b.timestamp,
        );
      }
    }
    return b;
  }).toList();

  event.breadcrumbs = breadcrumbs;
  return event;
}

SentryEvent? _stripSensitiveData(SentryEvent event, Hint hint) {
  final breadcrumbs = event.breadcrumbs?.map((b) {
    if (b.data != null && b.data!.containsKey('url')) {
      final url = b.data!['url']?.toString() ?? '';
      if (url.contains('b2c_cmp_') ||
          url.contains('Subscription-Key') ||
          url.contains('access_token')) {
        final sanitized = Map<String, dynamic>.from(b.data!);
        final uri = Uri.tryParse(url);
        sanitized['url'] = uri != null
            ? '${uri.scheme}://${uri.host}${uri.path}?[REDACTED]'
            : '[REDACTED]';
        return Breadcrumb(
          message: b.message,
          category: b.category,
          type: b.type,
          data: sanitized,
          level: b.level,
          timestamp: b.timestamp,
        );
      }
    }
    return b;
  }).toList();

  event.breadcrumbs = breadcrumbs;
  return event;
}

SentryEvent? _stripSensitiveData(SentryEvent event, Hint hint) {
  final breadcrumbs = event.breadcrumbs?.map((b) {
    if (b.data != null && b.data!.containsKey('url')) {
      final url = b.data!['url']?.toString() ?? '';
      if (url.contains('b2c_cmp_') ||
          url.contains('Subscription-Key') ||
          url.contains('access_token')) {
        final sanitized = Map<String, dynamic>.from(b.data!);
        final uri = Uri.tryParse(url);
        sanitized['url'] = uri != null
            ? '${uri.scheme}://${uri.host}${uri.path}?[REDACTED]'
            : '[REDACTED]';
        return Breadcrumb(
          message: b.message,
          category: b.category,
          type: b.type,
          data: sanitized,
          level: b.level,
          timestamp: b.timestamp,
        );
      }
    }
    return b;
  }).toList();

  event.breadcrumbs = breadcrumbs;
  return event;
}

Consent nur auf iOS, und eine unnötige Abhängigkeit

Die alte Implementierung rief AppTrackingTransparency.requestTrackingAuthorization() direkt in main() auf, bevor die App überhaupt gerendert war. Android-Nutzer bekamen keinen Consent-Dialog.

Das Audit hat Art. 7 zitiert (Bedingungen für die Einwilligung): Einwilligung muss freiwillig, spezifisch, informiert und plattformübergreifend sein. Aber es hat mich auch auf etwas anderes gebracht. Als ich mir die Datenflüsse angeschaut habe, die der Skill inventarisiert hat, fiel mir auf: kein einziges SDK in der App nutzt tatsächlich die IDFA. Kein Ad-Network, kein Attribution-Dienst, nichts. Die ganze ATT-Abfrage war ein Relikt aus einer früheren Planungsphase, das nie aufgeräumt wurde.

Also habe ich ATT komplett entfernt. Nicht nur den Code, sondern auch das Package aus der pubspec.yaml, die NSUserTrackingUsageDescription aus der Info.plist und die iOS-Plattform-Weiche im Cubit. Das ist ein Fall, den ich ohne den Audit wahrscheinlich nicht hinterfragt hätte. ATT war halt da, also haben wir es benutzt. Dass es überflüssig war, hat erst die systematische Frage "welche Daten fließen wohin?" aufgedeckt.

Stattdessen gibt es jetzt einen eigenen Consent-Mechanismus: ein ConsentCubit und ein Bottom Sheet beim ersten Start, auf beiden Plattformen.

@freezed
abstract class ConsentState with _$ConsentState {
  const ConsentState._();

  const factory ConsentState({
    required int prefs,
    required int stats,
    required int market,
    required bool collected,
  }) = _ConsentState;

  bool get isGranted => prefs == 1 && stats == 1 && market == 1;

  factory ConsentState.granted() => const ConsentState(
        prefs: 1, stats: 1, market: 1, collected: true);

  factory ConsentState.denied() => const ConsentState(
        prefs: 0, stats: 0, market: 0, collected: true);
}

@freezed
abstract class ConsentState with _$ConsentState {
  const ConsentState._();

  const factory ConsentState({
    required int prefs,
    required int stats,
    required int market,
    required bool collected,
  }) = _ConsentState;

  bool get isGranted => prefs == 1 && stats == 1 && market == 1;

  factory ConsentState.granted() => const ConsentState(
        prefs: 1, stats: 1, market: 1, collected: true);

  factory ConsentState.denied() => const ConsentState(
        prefs: 0, stats: 0, market: 0, collected: true);
}

@freezed
abstract class ConsentState with _$ConsentState {
  const ConsentState._();

  const factory ConsentState({
    required int prefs,
    required int stats,
    required int market,
    required bool collected,
  }) = _ConsentState;

  bool get isGranted => prefs == 1 && stats == 1 && market == 1;

  factory ConsentState.granted() => const ConsentState(
        prefs: 1, stats: 1, market: 1, collected: true);

  factory ConsentState.denied() => const ConsentState(
        prefs: 0, stats: 0, market: 0, collected: true);
}

Der Consent-State wird in SharedPreferences persistiert, per BlocProvider gescoped und vor dem Login geprüft:

Future<void> _collectConsentIfNeeded() async {
  final consentCubit = context.read<ConsentCubit>();
  if (consentCubit.state.collected) return;

  final choice = await showConsentBottomSheet(context);
  if (!mounted) return;

  if (choice == ConsentChoice.acceptAll) {
    await consentCubit.acceptAll();
  } else {
    await consentCubit.onlyNecessary();
  }
}

Future<void> _collectConsentIfNeeded() async {
  final consentCubit = context.read<ConsentCubit>();
  if (consentCubit.state.collected) return;

  final choice = await showConsentBottomSheet(context);
  if (!mounted) return;

  if (choice == ConsentChoice.acceptAll) {
    await consentCubit.acceptAll();
  } else {
    await consentCubit.onlyNecessary();
  }
}

Future<void> _collectConsentIfNeeded() async {
  final consentCubit = context.read<ConsentCubit>();
  if (consentCubit.state.collected) return;

  final choice = await showConsentBottomSheet(context);
  if (!mounted) return;

  if (choice == ConsentChoice.acceptAll) {
    await consentCubit.acceptAll();
  } else {
    await consentCubit.onlyNecessary();
  }
}

acceptAll setzt den State direkt. Kein if (_isIOS) mehr, kein _requestAttAndEmit(), keine Plattform-Weiche. Die gesamte ATT-Logik ist weg, und der Cubit ist um die Hälfte geschrumpft.

Die globale Variable

Die ursprünglichen Consent-Parameter lebten in einer globalen Variable in globals.dart. Der Audit hat das als Correctness- und Security-Problem markiert: Jeder Code konnte den Consent-State lesen oder ändern, ohne kontrollierten Zugriff.

Jetzt läuft alles über den Cubit. Consent-Parameter werden über explizite Funktionsparameter an WebView-URLs angehängt, nicht über globalen State.

Was der Audit noch gefunden hat, und was ich inzwischen gefixt habe

Das Nützlichste am Audit ist, was er als fehlend markiert. Eins der High-Severity-Findings war: kein Widerrufsmechanismus (Art. 7(3)). Wer einmal zugestimmt hat, konnte das nur ändern, indem er die App neu installiert. Die Verordnung sagt: "Der Widerruf der Einwilligung muss so einfach wie die Erteilung der Einwilligung sein."

Das habe ich inzwischen gefixt. In der Datenschutz-Einstellungen gibt es jetzt einen "Cookies & Tracking"-Switch, der über den bestehenden ConsentCubit läuft:

Future<void> _onConsentToggle(bool value) async {
  final cubit = context.read<ConsentCubit>();
  if (!value) {
    await cubit.onlyNecessary();
    return;
  }
  final choice = await showConsentBottomSheet(context);
  if (!mounted) return;
  if (choice == ConsentChoice.acceptAll) {
    await cubit.acceptAll();
  } else {
    await cubit.onlyNecessary();
  }
}

Future<void> _onConsentToggle(bool value) async {
  final cubit = context.read<ConsentCubit>();
  if (!value) {
    await cubit.onlyNecessary();
    return;
  }
  final choice = await showConsentBottomSheet(context);
  if (!mounted) return;
  if (choice == ConsentChoice.acceptAll) {
    await cubit.acceptAll();
  } else {
    await cubit.onlyNecessary();
  }
}

Future<void> _onConsentToggle(bool value) async {
  final cubit = context.read<ConsentCubit>();
  if (!value) {
    await cubit.onlyNecessary();
    return;
  }
  final choice = await showConsentBottomSheet(context);
  if (!mounted) return;
  if (choice == ConsentChoice.acceptAll) {
    await cubit.acceptAll();
  } else {
    await cubit.onlyNecessary();
  }
}

Ausschalten geht sofort. Wieder einschalten öffnet das Consent-Sheet erneut, damit die Zustimmung bewusst passiert. Gleiche UX wie beim ersten Start.

Ein High-Severity-Finding ist noch offen: Consent ist immer noch gebündelt (Art. 7). Man kann alles akzeptieren oder alles ablehnen. Einzeln steuern, ob Preferences, Statistiken oder Marketing erlaubt sind, geht noch nicht. Das Datenmodell hat die separaten Felder schon (prefs, stats, market), aber die UI bietet noch keine Einzel-Toggles. Steht im Backlog, dokumentiert mit Artikel-Referenz.

Wie ich das im Alltag nutze

1. Feature-Branch, der irgendwas mit Analytics, Nutzerdaten, Third-Party-SDKs oder Consent anfasst

2. /gdpr-audit in Claude Code ausführen, bevor ich den PR öffne

3. Strukturierter Report mit Findings, Severity-Levels und Datei:Zeile-Referenzen

4. Fixen, was in diesen Sprint passt. Den Rest dokumentieren.

Der Skill erkennt auch Dependency-Upgrades als Risiko. Als ich sentry_flutter von 8.x auf 9.x, firebase_analytics von 11.x auf 12.x und flutter_secure_storage von 9.x auf 10.x gehoben habe, hat er alle drei unter Art. 28 (Auftragsverarbeiter-Pflichten) geflaggt und empfohlen, die Changelogs auf Privacy-relevante Änderungen zu prüfen. Solche Sachen gehen unter, wenn man damit beschäftigt ist, den Build grün zu kriegen.

Was das ist und was nicht

Das ersetzt keinen Anwalt. Es schreibt keine AVVs. Es kennt eure vertraglichen Pflichten nicht und weiß nicht, was euer DSB abgenickt hat.

Was es macht: eine 195-Zeilen-Checkliste, abgeleitet aus der tatsächlichen Verordnung, automatisiert gegen euren Diff laufen lassen. Es findet das Mechanische: das Sentry-Flag, das noch auf true steht. Die Plattform, die keinen Consent-Dialog hat. Den Consent-State in einer globalen Variable.

Für mich als Freelancer an einer Gesundheits-App in Deutschland ist das der Unterschied zwischen "ich hab's manuell gecheckt, müsste passen" und einem dokumentierten Audit-Report mit konkreten Findings. Die Consent-Implementierung war ca. 200 Zeilen Dart. Das Sentry-Hardening hat Code entfernt statt hinzugefügt. Und die ATT-Abhängigkeit? Komplett rausgeflogen, mit allem drum und dran: Package, Info.plist-Eintrag, Plattform-Weiche im Cubit. Weniger Code, weniger Abhängigkeiten, weniger Angriffsfläche. Nichts davon war schwer, nachdem mir jemand (oder etwas) auf die konkrete Zeile gezeigt und "Art. 32, Problem" gesagt hat. Das Wissen war nicht das Problem. Das Hinschauen war es.

Häufige Fragen

Ersetzt ein KI-Audit eine rechtliche Prüfung durch einen Anwalt?

Nein. Der Skill findet technische Probleme: falsche Sentry-Flags, fehlende Consent-Dialoge, PII in Logs. Was er nicht kann: Auftragsverarbeitungsverträge bewerten, eure spezifischen rechtlichen Pflichten einordnen oder eine DSFA nach Art. 35 DSGVO durchführen. Er zeigt mir, wo im Code etwas schiefläuft. Ob das rechtlich relevant ist, muss jemand anderes beurteilen.

Warum reicht Apples ATT (App Tracking Transparency) nicht als DSGVO-Consent?

ATT fragt nur die IDFA-Nutzung ab (Identifier for Advertisers). Das ist ein iOS-Framework, auf Android existiert es nicht. Es unterscheidet nicht zwischen Statistik und Marketing. Und es erfüllt nicht das, was Art. 7 DSGVO unter "freiwillig, spezifisch und informiert" versteht. Wer DSGVO-konform sein will, braucht einen eigenen Consent-Mechanismus, der auf beiden Plattformen funktioniert. In unserem Fall hat sich außerdem herausgestellt, dass kein SDK in der App die IDFA überhaupt nutzt. ATT war komplett überflüssig.

Welche DSGVO-Artikel sind für App-Entwickler am relevantesten?

Art. 6 und 7 (Rechtsgrundlage und Einwilligung), Art. 9 (besondere Kategorien wie Gesundheitsdaten), Art. 17 (Recht auf Löschung), Art. 28 (Auftragsverarbeiter, betrifft jedes Third-Party-SDK), und Art. 32 (Sicherheit der Verarbeitung, betrifft Logging, Error-Reporting und Datenspeicherung).

Funktioniert der Audit-Skill nur für Flutter?

Der /gdpr-audit Skill prüft Code-Patterns, nicht Framework-spezifische APIs. Die Checkliste funktioniert für jede mobile oder Web-App. Die Suchbegriffe (PII-Felder, Tokens, Analytics-Events) sind framework-unabhängig. Anpassungen braucht man nur bei den Dateinamen (z.B. pubspec.yaml vs. package.json).

Weiterführende Ressourcen

• DSGVO Volltext auf EUR-Lex - wenn ihr nachschlagen wollt, was in Art. 7 oder 32 wirklich steht

• Art. 7 DSGVO auf dsgvo-gesetz.de - lesbarer als der Originaltext, mit Erwägungsgründen

• Art. 32 DSGVO auf dsgvo-gesetz.de - alles zu technischen und organisatorischen Maßnahmen

• Sentry Privacy & Compliance - was Sentry selbst zu Datenschutz sagt (lest das, bevor ihr sendDefaultPii anschaltet)

• Claude Code - das CLI-Tool, in dem der Audit-Skill läuft

Der /gdpr-audit Skill und die Consent-Implementierung stammen aus einer echten Produktions-App. Audit-Report, Code-Beispiele und offene Findings sind vom tatsächlichen Branch-Diff.