Compliance-Scan mit KI: DSGVO-Prüfung als operativer Leitfaden statt Case Study

Ein KI-Compliance-Scan ist kein „Dokument zum Abheften“, sondern ein operativer Leitfaden: Er macht KI-Use-Cases sichtbar, klassifiziert Risiken nach EU AI Act, prüft DSGVO-relevante Datenflüsse und übersetzt Pflichten in kontrollierte Workflows mit nachvollziehbaren Freigaben.

Seit der grundlegenden Anwendbarkeit des EU AI Act ab dem Stichtag im August 2026 gilt: Entscheidend ist nicht, ob irgendwo „KI“ draufsteht, sondern ob ein konkreter Anwendungsfall im Unternehmen als KI-System einzuordnen ist, welche Rolle Ihr Unternehmen dabei einnimmt und welche Auswirkungen auf Personen, Entscheidungen und Daten entstehen. Der Blick auf „Toolnamen“ greift zu kurz; regulatorisch zählt der Einsatzkontext, die Zweckbindung, die Entscheidungskette und die tatsächliche Steuerung.

Dieser Artikel ist bewusst keine Fallstudie und auch kein DIY-Tutorial. Ein belastbarer KI-Compliance-Scan erfordert Fachwissen aus Datenschutz, Informationssicherheit, Prozessdesign und Produktbetrieb. Ziel ist ein Ergebnis, das im Alltag funktioniert: klare Verantwortlichkeiten, dokumentierte Entscheidungen, getestete Kontrollen und ein Change-Prozess, der neue Use-Cases oder Modellwechsel sicher auffängt.

Regulatorischer Rahmen: EU AI Act und DSGVO in der Praxis zusammendenken

Der EU AI Act definiert Pflichten entlang von Rollen (z. B. Anbieter, Betreiber/Deployer, Importeur) und Risikostufen. Die EU-Kommission stellt einen Überblick zum Rechtsrahmen bereit (EU-Kommission: Regulatory framework for AI (AI Act)). Die verbindliche Verordnung ist über EUR-Lex abrufbar (Verordnung (EU) 2024/1689).

Parallel bleibt die DSGVO das zentrale Regelwerk, wenn personenbezogene Daten verarbeitet werden (DSGVO (EU) 2016/679). Für KI-Projekte heißt das: Datenminimierung, Zweckbindung, Rechtsgrundlagen, Informationspflichten, Auftragsverarbeitung und technische/organisatorische Maßnahmen müssen entlang des tatsächlichen Datenflusses bewertet werden. Ergänzend helfen aktuelle Leitplanken zur Einordnung KI-spezifischer Datenschutzaspekte, etwa die EDPB Opinion 28/2024 (EDPB Opinion 28/2024).

In vielen Organisationen scheitert Compliance nicht an „fehlendem Willen“, sondern an fehlender Übersetzung: Von abstrakten Pflichten hin zu konkreten Prüf- und Freigabepunkten im Betrieb. Genau hier setzt ein KI-Compliance-Scan an.

Warum „operativ“? Weil KI-Systeme sich verändern

KI-Systeme sind selten statisch. Prompts, Integrationen, Berechtigungen, Datenfelder, Modellversionen und Fachlogik ändern sich. Schon kleine Anpassungen können das Risikoprofil verschieben: Ein zusätzlicher CRM-Feldzugriff kann aus einem harmlosen Assistenzfall einen datenschutzintensiven Prozess machen. Ein neuer Output-Kanal kann Transparenz- und Kennzeichnungspflichten auslösen.

Ein produktionsreifer Scan liefert daher nicht nur eine Momentaufnahme, sondern einen wiederholbaren Workflow: Was wird geprüft, wer genehmigt, wie wird dokumentiert, wie wird getestet, und was passiert bei Änderungen? Das Ziel ist Governance, die den Betrieb nicht bremst, sondern sicher macht.

Schritt 1: KI-Inventar – Use-Case vor Toolname

Der Startpunkt ist ein vollständiges KI-Inventar. „Vollständig“ heißt: nicht nur zentrale Projekte, sondern auch Schattenprozesse in Fachbereichen (z. B. Textgenerierung, Klassifikation, Zusammenfassungen, automatische Entscheidungen, Chatbots, interne Wissenssuche). Erfasst werden Use-Cases als „System im Kontext“:

• Zweck: Wofür wird das System genutzt (z. B. Support-Triage, Lead-Qualifizierung, Vertragsprüfung, HR-Vorselektion)?
• Rolle: Betreiben Sie das System, liefern Sie es aus, oder integrieren Sie Komponenten?
• Entscheidungskette: Was entscheidet die KI, was entscheidet der Mensch, und wie wirken Outputs auf Betroffene?
• Datenarten: Personenbezug, besondere Kategorien, Kommunikationsinhalte, Betriebsgeheimnisse.
• Kanäle/Touchpoints: E-Mail, CRM, ERP, Ticketsystem, Webformular, Telefontranskription, interne Wissensbasis.

Das Inventar ist mehr als eine Liste: Es wird zur Landkarte für Risiko, Transparenz und technische Kontrollen. Ohne Inventar ist jede Aussage zu AI Act oder DSGVO unvollständig, weil sie zwangsläufig Use-Cases übersieht.

Schritt 2: Risikoklassifizierung nach EU AI Act – vier Stufen, viele Pflichten

Der EU AI Act unterscheidet vier Risikostufen (verboten, hoch, begrenzt, minimal). Die genaue Einordnung folgt den Definitionen und Anhängen der Verordnung (Verordnung (EU) 2024/1689). Operativ bedeutet das: Für jeden Use-Case muss eine nachvollziehbare Begründung dokumentiert werden, warum er in eine Kategorie fällt und welche Pflichten daraus abgeleitet werden.

Wichtig ist die Perspektive „Use-Case + Wirkung“. Ein identisches Modell kann in einem Kontext minimal riskant sein (z. B. rein interne Textentwürfe ohne Personenbezug) und in einem anderen Kontext hochriskant werden (z. B. wenn Ergebnisse in Zugangsentscheidungen einfließen). Der Scan prüft daher:

• Ob der Use-Case potenziell als Hochrisiko zu werten ist (z. B. wegen Einsatzbereich, Entscheidungseinfluss, Zielgruppe).
• Ob Transparenzpflichten greifen (z. B. Kennzeichnung bestimmter Inhalte oder Interaktionen).
• Ob Inhalte so gestaltet sind, dass Nutzer nicht in die Irre geführt werden (Dokumentation, Hinweise, UI-Text).
• Welche internen Controls erforderlich sind: Freigaben, Logging, Testdesign, Monitoring.

Risikostufe als Steuerungsinstrument (nicht als Label)

Die Risikostufe ist kein „Sticker“ für die Präsentationsfolie. Sie steuert Kontrollen. Ein operativer Leitfaden formuliert pro Stufe Mindestkontrollen: Was muss vor Go-live passieren, was muss im Betrieb überwacht werden, und wann muss eskaliert werden (z. B. bei neuen Datenquellen, neuen Nutzergruppen, neuen Entscheidungspfaden).

Praxisorientierte Zuordnung: Risikostufe, typische Auslöser und betriebliche Kontrollen

Risikostufe	Typische Auslöser im Use-Case	Operative Mindestkontrollen
Minimal	Unterstützende Funktionen ohne spürbare Auswirkungen auf Personen; keine automatisierten Entscheidungen	Inventar-Eintrag, Rechtekonzept, Logging der Kernaktionen, Change-Check bei Daten-/Modellwechsel
Begrenzt	Interaktion mit Nutzern oder Inhalte, die als KI-generiert erkennbar sein müssen; erhöhte Verwechslungsgefahr	Transparenz-/Kennzeichnungstexte, Review-Workflows, Qualitätstests, klare Grenzen in UI/Prozess
Hoch	Einsatz in sensiblen Bereichen oder mit relevanter Wirkung auf Zugang, Bewertung, Sicherheit oder Rechte	Risikomanagement, Testkatalog, Human Approval an kritischen Punkten, Lieferantenprüfung, Monitoring/Incident-Prozess
Verboten	Use-Case fällt unter verbotene Praktiken nach Verordnung	Stop/Decommission, Management-Eskalation, Dokumentation der Stilllegung, Sperren gegen Reaktivierung

Die Tabelle ersetzt keine Rechtsauslegung, aber sie zeigt den operativen Anspruch: Pflichten werden in überprüfbare Kontrollen übersetzt. Die rechtliche Einordnung muss im Zweifel mit qualifizierter Beratung abgestimmt werden.

Schritt 3: DSGVO-Datenfluss – vom Feld bis zur Ausgabe

Ein KI-Compliance-Scan muss den Datenfluss so konkret beschreiben, dass eine dritte Person nachvollziehen kann, welche Daten wann wo verarbeitet werden. Das ist zentral für DSGVO-Prinzipien und für die Wirksamkeit technischer Schutzmaßnahmen (DSGVO).

In der Praxis reicht „Wir nutzen ein Modell“ nicht. Relevant sind Konfigurationsentscheidungen, die Sie als Kunde steuern:

• Modell/Provider: Sie wählen, welches Modell und welcher Provider genutzt wird; die Inferenz kann je nach Provider auf dessen Infrastruktur erfolgen.
• Freigegebene Felder: Sie definieren, welche Datenfelder aus CRM/ERP/E-Mail überhaupt an den KI-Workflow übergeben werden (z. B. nur Tickettext ohne Kontaktdaten).
• Verarbeitungsregion: Sie legen fest, in welcher Region verarbeitet werden soll – und bewerten, was das für Ihre Compliance bedeutet.
• Retention: Sie bestimmen, wie lange Inhalte, Logs und Zwischenergebnisse aufbewahrt werden und wofür.
• Schreibrechte: Sie entscheiden, ob der KI-Mitarbeiter nur liest, Entwürfe erstellt oder tatsächlich in Systeme schreiben darf (z. B. CRM-Felder ändern, Tickets schließen).
• Freigaben: Sie definieren Human-Approval-Punkte (z. B. vor Versand, vor Statuswechsel, vor Kundennachricht).

agentworx ist eine KI-Agentur aus München. Wir bauen maßgeschneiderte KI-Mitarbeiter mit API-basierten Modellen unter Ihrer Kontrolle und integrieren diese individuell in CRM, ERP und E-Mail. Genau deshalb ist der Scan nicht generisch: Rechte, Felder, Region, Retention und Freigaben sind pro Use-Case unterschiedlich und müssen dokumentiert und getestet werden.

Schritt 4: DSFA-Screening – früh entscheiden, ob eine Folgenabschätzung nötig ist

Viele KI-Use-Cases sind nicht automatisch DSFA-pflichtig, aber oft DSFA-nah: Profiling-Elemente, neue Datenkombinationen, sensible Kontexte, systematische Bewertung oder große Reichweite können eine Datenschutz-Folgenabschätzung auslösen. Ein guter Scan enthält deshalb ein standardisiertes Screening, das die Entscheidung „DSFA ja/nein“ begründet und dokumentiert.

Für die Praxis ist eine klare Orientierung an etablierten Hilfestellungen sinnvoll, etwa den Informationen der Aufsichtsbehörde zur DSFA (BfDI: Datenschutz-Folgenabschätzungen). Zusätzlich sollte die Bewertung KI-spezifische Risiken berücksichtigen, wie sie der EDPB in seiner Opinion 28/2024 adressiert (EDPB Opinion 28/2024).

Operativ ist DSFA nicht „ein großes Word-Dokument“, sondern ein Arbeitsmodus: Stakeholder, technische Beschreibung, Risikoanalyse, Maßnahmen, Restrisiko-Entscheid und ein Prozess, wie Änderungen nachgeführt werden. Das Screening entscheidet, ob dieser Modus verpflichtend wird.

Schritt 5: Transparenz- und Kennzeichnungspflichten – UX ist Teil der Compliance

Transparenz ist im AI Act kein Nice-to-have. Je nach Use-Case können Hinweise erforderlich sein, dass Nutzer mit einem KI-System interagieren oder dass bestimmte Inhalte KI-unterstützt erstellt wurden. Das betrifft nicht nur externe Chatbots, sondern auch interne Systeme, wenn Ergebnisse weitergegeben oder Entscheidungen vorbereitet werden (EU-Kommission: AI Act).

Ein KI-Compliance-Scan prüft daher sehr praktisch:

• Touchpoint-Analyse: Wo sieht ein Mensch den Output (E-Mail-Entwurf, CRM-Notiz, Ticketantwort, Bericht)?
• Hinweise im Prozess: Wird der Output als Vorschlag gekennzeichnet oder als „automatisch entschieden“ missverstanden?
• Dokumentationsspur: Ist nachvollziehbar, dass ein Output KI-unterstützt war (für Audit, Reklamation, interne Aufklärung)?
• Schulung & Rollenverständnis: Wissen Nutzer, wann sie prüfen müssen, und wie sie Abweichungen melden?

Typisch ist der Fehler, Transparenz nur als Banner zu sehen. In der Praxis müssen UI, Prozessschritte und Verantwortlichkeiten zusammenpassen: Wer ist accountable, wer darf überstimmen, wer entscheidet bei Konflikten?

Schritt 6: Berechtigungen, Human Approval und „Write Access“ als Risikohebel

In produktiven Integrationen ist die größte Risikodifferenz selten das Modell, sondern der Zugriff: Was darf das System lesen, und was darf es verändern? Ein KI-Mitarbeiter, der nur Vorschläge macht, ist governance-technisch anders zu behandeln als ein System mit Schreibrechten in CRM oder ERP.

Ein operativer KI-Compliance-Scan legt deshalb ein Berechtigungsmodell fest, das sich an Rollen orientiert und in Stufen abgenommen wird:

• Read: Zugriff auf definierte Datenfelder für Analyse und Vorschläge.
• Draft: Erstellen von Entwürfen/Entscheidungsvorlagen, aber ohne selbständige Ausführung.
• Write (kontrolliert): Schreiben in ausgewählte Felder oder Statusänderungen, gekoppelt an Freigaben.
• Execute (hoch kontrolliert): Auslösen von Aktionen (z. B. Versand, Freigabe, Abschluss), nur bei klarer Regelbasis und Monitoring.

Human Approval ist dabei kein reines „Vier-Augen-Prinzip“. Es muss pro Fallklasse definiert sein: Welche Kriterien lösen eine Pflichtfreigabe aus? Welche Informationen bekommt die freigebende Person (Kontext, Quellen, Warnungen)? Und wie wird die Entscheidung protokolliert?

Schritt 7: Lieferantenprüfung und Modell-/Provider-Entscheidung

Viele Unternehmen unterschätzen, wie sehr Provider- und Modellwahl die Compliance-Arbeit prägen. Ein Scan muss klären, welche Zusicherungen, technischen Eigenschaften und Vertragsgrundlagen vorliegen und wie diese im Betrieb überprüfbar werden. Dabei geht es nicht um Marketingversprechen, sondern um belastbare Kontrollpunkte: Welche Datenkategorien werden verarbeitet? Was wird gespeichert? Welche Optionen gibt es für Region, Aufbewahrung und Zugriffskontrollen?

Für agentworx-Projekte ist zentral: Sie als Kunde wählen Modell/Provider, freigegebene Felder, Verarbeitungsregion, Retention, Schreibrechte und Freigaben. Je nach Provider kann Inferenz auf Provider-Infrastruktur stattfinden. Genau deshalb muss die Lieferantenprüfung zusammen mit dem Datenfluss betrachtet werden: Compliance entsteht aus der Kombination aus Vertrag, Technik und Ihrer Konfiguration.

Schritt 8: Testdesign – Compliance ist ohne Tests nicht nachweisbar

„Es funktioniert im Demo“ ist kein Abnahmekriterium. Ein KI-Compliance-Scan definiert Tests so, dass Pflichten und Kontrollen überprüft werden können: nicht nur Genauigkeit, sondern auch Fehlverhalten, Grenzfälle und Missbrauch. Dazu gehören:

1. Fallklassen: Welche Eingaben sind zulässig, welche verboten, welche müssen eskalieren?
2. Negativtests: Sensible Daten im Prompt, widersprüchliche Identitäten, manipulierte Anweisungen, ungewöhnliche Formate.
3. Freigabe-Tests: Wird bei kritischen Fällen zuverlässig ein Human-Approval erzwungen?
4. Rechte-Tests: Kann das System nur auf freigegebene Felder zugreifen, und bleiben Schreibrechte auf definierte Aktionen begrenzt?
5. Transparenz-Tests: Sind Kennzeichnungen an den richtigen Touchpoints sichtbar und verständlich?

Professionelle Umsetzung ist hier entscheidend, weil Tests nicht nur fachlich, sondern auch technisch robust sein müssen: reproduzierbar, versioniert, mit klaren Abnahmeschwellen und mit Protokollen, die später auditierbar sind.

Schritt 9: Monitoring, Incident-Handling und Change-Prozess

Ein produktionsreifer KI-Compliance-Scan endet nicht mit „Go-live“. Er definiert ein Betriebsmodell: Was wird gemessen, wie werden Abweichungen erkannt, und wer entscheidet über Änderungen? Monitoring umfasst nicht nur technische Stabilität, sondern auch Governance-Signale.

Monitoring-Signale, Prüffragen und typische Reaktionen im Betrieb

Signal	Prüffrage	Typische Reaktion
Mehr Eskalationen an Menschen	Hat sich die Eingangsqualität oder der Use-Case verändert?	Fallklassen nachschärfen, Datenfelder prüfen, Trainings-/Prompt-Änderung nur mit Re-Test
Mehr manuelle Korrekturen	Passt Output noch zur Policy und zum Ton?	Freigabelevel erhöhen, Qualitätsregeln ergänzen, UI-Hinweise präzisieren
Ungewöhnliche Daten im Input	Werden neue Datenarten verarbeitet (z. B. besondere Kategorien)?	DSFA-Screening erneut durchführen, Datenminimierung, Zugriff begrenzen
Änderung an Modell/Provider/Region	Ändert sich die rechtliche/technische Bewertung des Datenflusses?	Re-Approval, Lieferantenprüfung aktualisieren, Tests wiederholen, Dokumentation versionieren

Der Change-Prozess ist der Kern der Operationalisierung: Jede Änderung an Feldern, Schreibrechten, Retention, Modellparametern oder Touchpoints muss als „Compliance-relevant“ klassifiziert werden können. Ohne Versionierung und Freigabepfade entsteht sonst eine Lücke zwischen Papier-Compliance und realem Systemverhalten.

Typische Fehler, die wir in KI-Compliance-Scans sehen

• Inventar-Lücken: Einzelne Teams nutzen KI-Funktionen außerhalb der zentralen Governance; das bricht Konsistenz bei Transparenz und Datenfluss.
• Tool-Fokus statt Rollen-Fokus: Diskussionen drehen sich um Produktnamen, nicht um Betreiberrolle, Entscheidungseinfluss und Betroffenenwirkung.
• Zu breite Datenfreigaben: „Nur für Kontext“ werden ganze Datensätze freigegeben, obwohl wenige Felder reichen würden.
• Write Access ohne Schutzgeländer: Schreibrechte werden früh erteilt, ohne Human Approval, ohne Quotenbegrenzung, ohne Audit-Spur.
• Transparenz nur als Textbaustein: Kennzeichnung wird irgendwo platziert, aber nicht an den Touchpoints, an denen Entscheidungen tatsächlich wirken.
• Kein Re-Test bei Änderungen: Neue Felder oder ein Modellwechsel gehen live, ohne den Testkatalog erneut auszuführen.
• Unklare Ownership: Niemand fühlt sich zuständig für Policies, Ausnahmen, Freigaben und Incident-Entscheide.

Was agentworx konkret liefert (ohne Rechtsversprechen)

agentworx entwickelt als KI-Agentur aus München maßgeschneiderte KI-Mitarbeiter für konkrete Rollen in Ihrem Unternehmen: z. B. „Sales Assistant“ mit CRM-Kontext, „Support Triage“ mit Ticket-Workflows oder „Backoffice Assistant“ für strukturierte Abläufe. Der KI-Compliance-Scan ist dabei ein Produktivitätshebel, weil er Unklarheiten reduziert und Freigaben beschleunigt: Einmal sauber modelliert, können Teams sicherer skalieren.

Wir liefern keine Rechtsberatung und keine Garantie, dass ein System „automatisch compliant“ ist. Was wir liefern, ist ein belastbarer, dokumentierter Umsetzungsrahmen: Inventar, Datenflussbeschreibung, Risikologik, Freigabeprozesse, Testdesign und ein Betriebsmodell. Das Ergebnis ist so gestaltet, dass Ihr Datenschutz, Ihre Informationssicherheit und Ihre Fachbereiche damit arbeiten können.

Im Mittelpunkt steht die Steuerbarkeit durch Sie: Sie wählen Modell/Provider, freigegebene Felder, Verarbeitungsregion, Retention, Schreibrechte und Freigaben. Je nach Provider kann Inferenz auf Provider-Infrastruktur stattfinden. Diese Parameter werden nicht „irgendwie“ gesetzt, sondern als kontrollierte Konfiguration geführt: mit Verantwortlichen, Änderungsnachweisen und Prüfpfaden.

FAQ: Häufige Fragen zum KI-Compliance-Scan

Reicht es, wenn wir ein KI-Tool beschaffen und eine Policy schreiben?

In der Regel nicht. Policies sind wichtig, aber sie ersetzen keine technische und prozessuale Übersetzung: Datenfelder, Rechte, Freigaben, Kennzeichnung, Tests und Monitoring müssen im Systemdesign verankert sein. Ein KI-Compliance-Scan verbindet genau diese Ebenen und macht die Governance im Betrieb überprüfbar.

Wie tief muss das KI-Inventar gehen?

So tief, dass Risiken und Pflichten pro Use-Case beurteilt werden können. Mindestens: Zweck, Rolle, Datenarten, Touchpoints, Entscheidungseinfluss, Berechtigungen und Änderungen über Zeit. Ohne diese Details ist weder die Risikoklassifizierung nach EU AI Act (Verordnung (EU) 2024/1689) noch die DSGVO-Bewertung (DSGVO) belastbar.

Wann brauchen wir Human Approval und wann kann KI automatisiert schreiben?

Das hängt vom Use-Case, der Risikostufe, den Datenarten und der Fehlerfolgenabschätzung ab. In der Praxis setzen viele Teams Human Approval bei extern wirksamen Aktionen (z. B. Versand, Ablehnung, Vertragszusagen), bei sensiblen Daten und bei Unsicherheitssignalen. Schreibrechte werden dann schrittweise erweitert, gekoppelt an Tests, Logs und eine klar definierte Eskalation.

Fazit: KI-Compliance-Scan als Betriebssystem für sichere Skalierung

Ein KI-Compliance-Scan wird nach dem EU-AI-Act-Stichtag zum Standard, wenn KI vom Experiment zur Produktivplattform wird. Der Mehrwert entsteht nicht durch ein einzelnes Dokument, sondern durch ein „Betriebssystem“ aus Inventar, Risikoklassifizierung, DSGVO-Datenfluss, DSFA-Screening, Transparenz, Berechtigungen, Tests und Monitoring. Damit wird Compliance nicht zum Stoppschild, sondern zu einem verlässlichen Rahmen für Wachstum.

Wenn Sie KI-Mitarbeiter in CRM, ERP und E-Mail aufbauen oder bestehende Use-Cases nachziehen wollen, unterstützen wir Sie bei der Operationalisierung: kontrollierte Konfiguration, nachvollziehbare Freigaben und ein Setup, das im Alltag tragfähig ist.