Wie ich LLMs in der Compliance-PM-Arbeit einsetze

Ich arbeite lange genug im Bereich Content-Policy und regulatorische Compliance, um Behauptungen wie „KI wird X automatisieren" skeptisch gegenüberzustehen. Was ich festgestellt habe, ist konkreter: Es gibt bestimmte Aufgaben in der Compliance-PM-Arbeit, bei denen LLMs den Zeitaufwand erheblich verkürzen, und bestimmte Aufgaben, bei denen sie nicht helfen und denen man nicht vertrauen sollte. Diese Unterscheidung ist entscheidend.

Anforderungsextraktion

Der zuverlässigste Anwendungsfall ist das Parsen von Gesetzestexten. Wenn ein neues Gesetz oder eine neue regulatorische Leitlinie erscheint, besteht die erste PM-Aufgabe darin, zu verstehen, was tatsächlich gefordert wird — konkret: welche Daten erfasst werden müssen, welche Kategorien geführt werden müssen und in welchem Format die Ausgabe erfolgen muss.

Der Ablauf: den vollständigen Text des Gesetzes oder Leitliniendokuments in das Modell einfügen und es bitten, jedes berichtspflichtige Datenelement aufzulisten. Für jedes Element wird gefragt, ob die Beschreibung etwas entspricht, das die aktuelle Dateninfrastruktur bereits erzeugt. Anschließend wird diese Ausgabe mit dem verglichen, was die Datensysteme der Plattform tatsächlich generieren — gemeinsam mit einem Fachexperten, der weiß, was diese Systeme produzieren.

Das funktioniert gut, weil Gesetzestexte präzise sind und ihr Parsen kein tiefes kontextuelles Urteilsvermögen erfordert. Das Modell führt eine strukturierte Informationsextraktion durch — es zieht Listen von Anforderungen heraus und ordnet sie — und das erledigt es zuverlässig. Wo es an seine Grenzen stößt, ist die Auslegung mehrdeutiger Definitionen, die nach wie vor juristisches Urteilsvermögen erfordert. Das Modell gibt Ihnen eine selbstbewusste Antwort darauf, was eine mehrdeutige Anforderung bedeutet; diese Antwort mag widerspiegeln, wie die Regulierungsbehörde denselben Wortlaut liest — oder auch nicht.

Der wahre Nutzen zeigt sich, wenn sich ein neues Gesetz mit einem bestehenden überschneidet. Als der kalifornische AB 587 erschien, berichteten wir bereits nach Artikel 15 der EU-DSA. Die Kategorierahmen überschneiden sich teilweise, lassen sich aber nicht sauber zuordnen — für AB 587s „disinformation or misinformation" gibt es kein direktes DSA-Äquivalent, und für den Meldemechanismus nach Artikel 16 der DSA gibt es kein kalifornisches Pendant. Beide Gesetzestexte durch diesen Extraktionsprozess laufen zu lassen und dann einen strukturierten Abgleich mit der bestehenden Dateninfrastruktur durchzuführen, hat die Lücken präzise aufgezeigt: welche Daten wir bereits hatten, was ergänzt werden musste und wofür definitorische Entscheidungen nötig waren, bevor wir überhaupt mit der Datenarbeit beginnen konnten.

Jurisdiktionsübergreifende Lückenanalyse

Ein verwandter Anwendungsfall ist die Pflege einer jurisdiktionsübergreifenden Anforderungstabelle, während sich die regulatorischen Leitlinien weiterentwickeln. Die DSA-Kommission veröffentlichte 2024 eine harmonisierte Berichtsvorlage; als sie in der Version für H2 2025 die Präzisions- und Recall-Anforderungen für automatisierte Erkennungswerkzeuge aktualisierte, musste ich genau verstehen, was sich gegenüber der H1-Vorlage geändert hatte und ob es etwas betraf, das wir bereits erzeugten.

Der Workflow: eine strukturierte Anforderungstabelle nach Jurisdiktion führen — DSA Artikel 15, DSA Artikel 42, AB 587, S895 und so weiter — mit Spalten für die konkret geforderten Daten und den aktuellen Infrastrukturstatus. Wenn neue Leitlinien veröffentlicht werden, wird der neue Text gegen die bestehende Tabelle laufen gelassen, um zu markieren, was sich geändert hat. Das Modell übernimmt den Vergleich; das PM-Urteil liegt in der Bewertung, ob markierte Änderungen technische Arbeit, definitorische Entscheidungen oder gar nichts erfordern.

Das ist schneller, als ein vollständig aktualisiertes Leitliniendokument gegen die Erinnerung an die frühere Version zu lesen, und zuverlässiger — das Modell erfasst Dinge, die in dichten regulatorischen Texten leicht übersehen werden, insbesondere Änderungen der Messmethodik oder des Berichtsrhythmus, die in einer Fußnote versteckt sind.

Entwurfsprüfung anhand einer gesetzlichen Checkliste

Bevor ein regulatorischer Bericht zur Prüfung an die Rechtsabteilung geht, prüfe ich einen nahezu finalen Entwurf gegen die einschlägige gesetzliche Checkliste. Der Prompt ist unkompliziert: Hier ist der Berichtsentwurf, hier ist das einschlägige Gesetz, identifiziere alles im Gesetz, das im Bericht nicht behandelt wird, und markiere alles im Bericht, das den Anforderungen des Gesetzes zu widersprechen scheint.

Das fängt Auslassungen ab, die in langen Dokumenten leicht übersehen werden — eine nach einem Unterabschnitt vorgeschriebene Offenlegung, die in einem Überarbeitungszyklus wegfiel, oder eine Kategorie, die im Gesetz auftaucht, im Bericht aber versehentlich mit einer anderen zusammengefasst wurde. Das sind die Fehler, die in der juristischen Prüfung auftauchen und eine vollständige Überarbeitung erfordern, was Zeit kostet, wenn man kurz vor einer Einreichungsfrist steht.

Es ersetzt die juristische Prüfung nicht. Das Modell übersieht kontextabhängige Auslegungen und fängt substanzielle Genauigkeitsprobleme nicht ab — es kann Ihnen nicht sagen, dass die berichtete Zahl der Beschwerden falsch ist, sondern nur, dass der Bericht einen Abschnitt zu Beschwerden enthält. Aber es ist eine nützliche Vorabprüfung, die die Wahrscheinlichkeit verringert, dass die juristische Prüfung strukturelle Auslassungen statt inhaltlicher Fragen zutage fördert.

Was nicht funktioniert

Alles, was ein Urteil über die regulatorische Absicht erfordert — was eine Regulierungsbehörde tatsächlich durchsetzen wird, ob eine bestimmte Offenlegung eine Anforderung erfüllt, deren Wortlaut mehrdeutig ist — funktioniert nicht gut. Das Modell erzeugt eine selbstbewusst klingende Antwort. Diese Antwort mag widerspiegeln, wie die Regulierungsbehörde denselben Wortlaut liest — oder auch nicht — und in der Compliance-Arbeit macht dieser Unterschied den Unterschied.

Ebenso ist alles unzuverlässig, was Kenntnis konkreter Durchsetzungshistorie, jüngster Kommissionsleitlinien oder laufender Rechtsetzung erfordert, die nach dem Trainingsdatenstichtag liegt. Das Modell weiß nicht, was es nicht weiß, und regulatorische Compliance ist ein Bereich, in dem das Handeln auf Grundlage veralteter Informationen ein reales Risiko schafft.

Das Muster, das sich bewährt hat: LLMs für strukturierte Textaufgaben einsetzen — Extraktion, Vergleich, Checklistenprüfung — bei denen Ein- und Ausgaben klar definiert sind und ein Fachexperte die Ausgabe verifizieren kann. Sie nicht dafür nutzen, Fragen dazu zu beantworten, was eine Anforderung in einem Durchsetzungskontext bedeutet oder wie eine Regulierungsbehörde auf einen bestimmten Offenlegungsansatz reagieren wird. Das erfordert Fachwissen, das das Modell nicht besitzt und nicht zuverlässig simulieren kann.