AI Readiness — ein Ergebnis von Data Governance, kein eigenes Programm

Der Pilot, der nie zum Rollout wurde

Ein Pilot auf einem Foundation Model funktioniert nach vier Wochen. Er fasst Schadensmeldungen zusammen, sortiert Support-Tickets vor oder bewertet Leads, und die Demo überzeugt genug, dass jemand fragt, wie bald das live gehen kann. Dann trifft der Rollout auf die rechtliche Prüfung, und die Fragen kommen: Welche Datensätze liest das System, auf welcher Grundlage, wer hat das freigegeben, und könnten wir es im nächsten Jahr einer Aufsichtsbehörde zeigen? Niemand kann das aus etwas beantworten, das bereits existiert, also wird ein Arbeitsstrang eröffnet, der die Antworten erarbeiten soll, und sechs Monate später ist der Pilot noch immer ein Pilot.

Meist hat ein solcher Stillstand eine von zwei Ursachen, und häufig beide.

Fähigkeit vor Erlaubnis. Das Modell wird ausgewählt und integriert, bevor jemand sagen kann, welche Daten es nutzen darf und auf welcher Rechtsgrundlage. Die Antwort muss deshalb rückwärts aus einer funktionierenden Integration rekonstruiert werden — die teuerste Richtung, weil sich die Frage verschiebt: Es geht nicht mehr darum, was das System lesen dürfen sollte, sondern darum, wie sich beschreiben lässt, was es bereits liest.

Das Parallelregime. KI-Governance wird als neues Programm aufgesetzt, mit eigenem Gremium, eigenem Register und eigenen Definitionen von Zweck und Rechtsgrundlage, und neben die Data Governance gestellt, die das Unternehmen nach der DSGVO ohnehin schuldet, statt als deren Anwendung aufgebaut zu werden.

Die üblichen Erklärungen — das falsche Modell, unreife Anbieter, fehlende KI-Kompetenz im Haus — treffen zu und liegen diesen beiden nachgelagert. Ein Team, das alle drei gelöst hat, bleibt in derselben Prüfung stecken, wenn es nicht sagen kann, was das Modell lesen darf.

Warum das in der EU mehr kostet, und warum jetzt

In der EU gelten für denselben KI-Anwendungsfall drei Regelwerke zugleich, und jedes stellt eine Variante der Frage, die schon die rechtliche Prüfung im Pilot gestellt hat: Was liest dieses System, und auf welcher Grundlage? Die KI-Verordnung — international als AI Act bekannt — stellt sie an das System selbst, mit Pflichten, die mit seiner Risikostufe wachsen. Die DSGVO stellt sie an jede Verarbeitungstätigkeit, und die Antwort schuldet das Unternehmen bereits schriftlich, in dem unten beschriebenen Verzeichnis. Und in Deutschland und Österreich gibt die Mitbestimmung dem Betriebsrat das Recht, zu neuer Technik angehört zu werden und zuzustimmen, bevor etwas eingeführt wird, das Beschäftigte überwachen kann — ein KI-Werkzeug am Arbeitsplatz braucht dieselbe Antwort also ein drittes Mal.

Das Verzeichnis nach Art. 30 ist das, worauf dieser Grundpfeiler aufbaut. Art. 30 DSGVO verpflichtet jede Organisation, die über die Verarbeitung personenbezogener Daten entscheidet — den Verantwortlichen im Sinne der Verordnung —, ein Verzeichnis ihrer Verarbeitungstätigkeiten zu führen, im Folgenden Verarbeitungsverzeichnis; im Englischen heißt es Record of Processing Activities, kurz RoPA, daher der Befehlsname qedro ropa weiter unten. Für jede Tätigkeit nennt es die Zwecke, die Kategorien betroffener Personen und Daten, die Empfänger, Übermittlungen in Drittländer, die Löschfristen und die Sicherheitsmaßnahmen. Organisationen mit weniger als 250 Beschäftigten sind nur befreit, wenn ihre Verarbeitung lediglich gelegentlich erfolgt, kein Risiko für die Rechte und Freiheiten der Betroffenen birgt und weder besondere Kategorien von Daten noch Daten über Straftaten umfasst — in der Praxis schuldet also fast jede Organisation ein solches Verzeichnis. Ein Vorschlag der Kommission vom Mai 2025 würde diese Ausnahme auf Organisationen mit weniger als 750 Beschäftigten ausweiten und ihre Bedingung auf Verarbeitungen beschränken, die voraussichtlich ein hohes Risiko bergen; bis Oktober 2026 war er nicht verabschiedet, und die KI-Anwendungsfälle, die die KI-Verordnung als hochriskant einstuft, sind überwiegend Verarbeitungen, die so oder so im Verzeichnis bleiben müssten. Die Rechtsgrundlage steht nicht auf der Liste des Artikels selbst, doch die Muster der Aufsichtsbehörden fragen sie neben den Zwecken ab — die Hinweise des Thüringer Landesbeauftragten für den Datenschutz etwa —, und dort nimmt dieser Grundpfeiler sie als geführt an.

Ein Unternehmen mit eigener KI-Compliance-Funktion kann ein Parallelregime verkraften, so verschwenderisch es auch ist; eines ohne eine solche Funktion kann es nicht, und für dieses ist die Ableitung der KI-Nachweise aus dem Governance-Verzeichnis die einzige Fassung, die nach dem ersten Quartal noch jemand pflegt.

Die nächste Frist der KI-Verordnung ist nicht das Argument, jetzt zu handeln. Der Digital-Omnibus — Verordnung (EU) 2026/1744, in Kraft seit dem 27. Juli 2026 — hat die Betreiberpflichten aus Art. 26 und 27 für Systeme nach Anhang III auf den 2. Dezember 2027 verschoben, gut ein Jahr entfernt. Bereits bindend sind das Verarbeitungsverzeichnis, die Mitbestimmung, die Transparenzpflichten aus Art. 50 seit August 2026 und eine nationale Durchsetzungsstruktur, die es in Deutschland inzwischen gibt. Der Aufschub spricht dafür, das Verzeichnis einmal aufzubauen, nicht dafür zu warten: Ein Jahr reicht dafür, aber nicht, um ein Parallelprogramm zu betreiben und es anschließend mit dem Verzeichnis abzugleichen, das es ergänzen sollte.

Die Einzelheiten — welche Pflichten von der Risikostufe abhängen, wie weit die Mitbestimmung reicht und wo sie endet, und wie die Schweiz dieselbe Frage von außerhalb der Verordnung beantwortet — stehen in der Übersicht weiter unten.

Das Parallelregime ist das, was der erste Fehler hervorbringt

Die beiden Ursachen sind nicht unabhängig voneinander. Ein Unternehmen, das nicht sagen kann, was ein Modell lesen darf, greift zu einem Framework, dessen Zweck es ist, eine Antwort herzustellen, und ein Framework erzeugt Artefakte statt Nachweise, weil das Verzeichnis aus Lineage und Zwecken, auf das es sich stützen müsste, nie aufgebaut wurde.

Das Register wird von Hand gepflegt, weil es kein Verzeichnis gibt, aus dem es sich erzeugen ließe, und nach zwei Quartalen sind seine Definitionen von Zweck und Rechtsgrundlage von denen im Verarbeitungsverzeichnis abgedriftet, das es ergänzen sollte — mit zwei Antworten auf dieselbe Frage und einem Prüfer, der sich aussuchen kann, welche er prüft.

Der Markt verkauft die beiden Hälften getrennt, Readiness-Assessments gegen die erste und KI-Governance-Programme gegen die zweite, und keines funktioniert ohne das Verzeichnis, das unter beiden liegt.

Was Readiness auf der Datenebene bedeutet

Readiness ist, von der Datenebene aus gesehen, die Fähigkeit, vier Fragen zu einem geplanten Anwendungsfall aus Aufzeichnungen zu beantworten, die bereits existieren: welche Daten er liest, zu welchem Zweck und auf welcher Rechtsgrundlage, wem die Entscheidung über seinen Einsatz gehört, und ob sich all das in einem Jahr jemand anderem zeigen lässt.

Zwei Readiness-Frameworks verdienen es, genannt zu werden, weil dieser Grundpfeiler abdeckt, was sie offenlassen, statt zu bestreiten, was sie sagen. Straives What Is AI Readiness? beschreibt fünf organisatorische Säulen, eine davon Daten, und spricht sich ausdrücklich für eine geordnete Roadmap statt einer Punktwertung aus. Microsofts AI Readiness Assessment stellt 72 Fragen zur Selbsteinschätzung in sieben Säulen und mittelt sie zu einer von drei Reifestufen; die Säule Data Foundations gehört zu den größten und nennt Lineage, Datenschutz, Datenminimierung und Aufbewahrung.

Gemeinsam ist beiden die Lücke. In beiden werden Daten bewertet oder beschrieben statt nachgewiesen — keines verlangt ein Verzeichnis, einen Lineage-Graphen oder ein anderes Artefakt —, und keines fragt, auf welcher Rechtsgrundlage die Daten überhaupt verarbeitet werden dürfen. Keines erwähnt die KI-Verordnung oder die DSGVO.

Drei Dinge, mit denen Readiness häufig verwechselt wird, jedes mit einem anderen falschen Auftrag als Folge:

• Keine Selbsteinschätzung. Eine Antwort, die aus dem zusammengesetzt ist, was Menschen über ihre Daten sagen, ist kein Nachweis über die Daten, ob sie nun in einer Punktzahl endet oder in einer Roadmap.
• Keine Modellauswahl. Welches Modell zum Einsatz kommt, ist eine Beschaffungsentscheidung, und sie lässt sich erst gut treffen, wenn die vier Fragen beantwortet sind.
• Keine KI-Strategie. Eine Strategie benennt Ambitionen; Readiness ist eine Eigenschaft von Aufzeichnungen.

Positiv gewendet, und in einer Form, die sich zurückspielen lässt: Readiness ist ein Nachweis über Daten, angewandt auf eine weitere Art der Verarbeitung.

Die KI-Verordnung, wie ein Betreiber ihr tatsächlich begegnet

Die meisten Anwendungsfälle sind kein Hochrisiko-Fall, und das zuerst zu sagen ist wichtig, weil ein Grundpfeiler, der mit den schwersten Pflichten beginnt, wie ein Argument aus Angst wirkt. Die Verordnung teilt Systeme ein in verbotene Praktiken nach Art. 5, Hochrisiko-Systeme nach Anhang III — Beschäftigung, Kreditwürdigkeit, Preisgestaltung in der Lebens- und Krankenversicherung, Zugang zu wesentlichen Leistungen und weitere —, Systeme mit Transparenzpflichten nach Art. 50 und alles Übrige.

Was jeden Betreiber erreicht, gleich in welcher Stufe, ist überschaubar. Die Verbote in Art. 5 binden alle. Art. 4 verlangt KI-Kompetenz, und der Digital-Omnibus hat das abgeschwächt: Gefordert sind nun Maßnahmen, die den Aufbau von KI-Kompetenz unterstützen, nicht die Gewähr eines bestimmten Niveaus, es ist also keine Pflicht, Kompetenz sicherzustellen. Art. 50 Abs. 3 und 4 erfassen Betreiber von Systemen zur Emotionserkennung und zur biometrischen Kategorisierung sowie Betreiber, die Deepfakes oder KI-generierte Texte zu Angelegenheiten von öffentlichem Interesse veröffentlichen; der Rest von Art. 50 richtet sich an Anbieter. Außerhalb der Verordnung und unabhängig von ihren Stufen gilt die DSGVO, wo immer personenbezogene Daten im Spiel sind, die Mitbestimmung bei Werkzeugen am Arbeitsplatz und DORA für Finanzunternehmen.

Was ein Betreiber eines Hochrisiko-Systems zusätzlich schuldet, ist der Minderheitsfall, und das meiste davon ist Data Governance mit einem KI-spezifischen Auslöser. Neben der Verwendung gemäß der Betriebsanleitung des Anbieters und der Meldung von Vorfällen verlangt Art. 26 eine menschliche Aufsicht durch Personen mit der nötigen Kompetenz und Befugnis (Abs. 2), Eingabedaten, die relevant und ausreichend repräsentativ sind, soweit der Betreiber sie kontrolliert (Abs. 4), Protokolle, die mindestens sechs Monate aufbewahrt werden, soweit sie seiner Kontrolle unterliegen (Abs. 6), und dass die Arbeitnehmervertretungen und die Personen, über die das System entscheidet, über den Einsatz eines Hochrisiko-Systems informiert werden (Abs. 7 und 11). Für Systeme nach Anhang III gilt all das ab dem 2. Dezember 2027.

Die Grundrechte-Folgenabschätzung nach Art. 27 ist noch enger gefasst: nur Hochrisiko-Systeme, und unter diesen nur öffentliche Stellen und private Betreiber, die Kreditwürdigkeit bewerten oder Preise in der Lebens- und Krankenversicherung festlegen. In der Fassung des Omnibus erlaubt Art. 27 Abs. 4 einem Betreiber, auf die einschlägigen Teile einer bestehenden Datenschutz-Folgenabschätzung (DSFA) zu verweisen oder sie zu übernehmen, also der Risikobewertung, die die DSGVO nach Art. 35 bereits vor jeder Verarbeitung verlangt, die voraussichtlich ein hohes Risiko für Menschen mit sich bringt. Damit steht das Argument dieses Grundpfeilers in der Verordnung selbst.

Aus Sicht eines Betreibers verlangt die Verordnung also von den meisten Anwendungsfällen wenig — Maßnahmen zur KI-Kompetenz, die Verbote und Offenlegung in einigen aufgezählten Fällen —, und wo sie mehr verlangt, für die Minderheit der Hochrisiko-Fälle, sind die meisten Zusätze Fragen über Daten statt über Modelle: ob die Eingaben relevant und repräsentativ sind, wer die Ausgaben beaufsichtigt, was protokolliert wurde und wer informiert wurde. Ein gepflegtes Verarbeitungsverzeichnis beantwortet Fragen dieser Art bereits für jede andere Verarbeitungstätigkeit, und deshalb behandelt der nächste Abschnitt die KI-Pflichten als eine weitere Lesart dieses Verzeichnisses, nicht als eigenes Register.

Dasselbe Verzeichnis, noch einmal projiziert

Die Nachweise, die ein KI-Betreiber braucht, sind Projektionen des Verarbeitungsverzeichnisses, das das Unternehmen ohnehin schuldet, erzeugt aus denselben Events, statt daneben gepflegt zu werden.

Zwei Ausprägungen machen den Unterschied greifbar, und ihre Namen sind Bezeichnungen dieses Grundpfeilers, keine etablierten Begriffe. Programme-first richtet ein KI-Gremium ein, ein KI-Register in einer Tabelle, eine KI-Richtlinie und einen eigenen Freigabeprozess, und jeder Anwendungsfall wird von Hand beschrieben. Register und Verarbeitungsverzeichnis beschreiben dieselbe Verarbeitung dann mit unterschiedlichen Worten, und niemand gleicht sie ab, weil der Abgleich niemandes Aufgabe ist.

Record-first lässt jede Pipeline ihren Zweck und ihre Rechtsgrundlage einmal deklarieren, in ihrem Deskriptor — der Konfigurationsdatei, die festlegt, was eine Pipeline liest, was sie schreibt und wozu sie dient, und aus der die Plattform sie ausführt —, und jeder Lauf sendet beides auf seinem Lineage-Event mit, neben der Modellversion und den gelesenen Eingaben. Die Events folgen OpenLineage, einem offenen Standard dafür, welcher Job welche Datensätze gelesen und geschrieben hat, und die zusätzlichen Felder reisen in seinen Facets, dem Erweiterungsmechanismus des Standards, statt in einer Form, die für dieses Argument erfunden wurde. Das Verarbeitungsverzeichnis, die Eingaben für eine DSFA, das KI-Use-Case-Register und der Nachweis für Art. 26 Abs. 6, der verlangt, dass die Protokolle eines Hochrisiko-Systems mindestens sechs Monate aufbewahrt werden, sind dann vier Sichten auf einen einzigen Strom von Events. Ein einziger Leser über diesen Strom erzeugt alle vier. In Cordatas Referenzimplementierung ist dieser Leser qedro, ein Open-Source-Werkzeug, auf PyPI veröffentlicht, das OpenLineage-Events liest und daraus das Verarbeitungsverzeichnis und die übrigen Sichten erzeugt; der Abschnitt Was die Pipeline tatsächlich emittiert weiter unten zeigt seine Ausgabe aus einem echten Lauf.

Vier Dokumente, die einander nicht widersprechen können, weil keines von ihnen getippt wird: Jedes ist eine Projektion derselben Events, und eine Frage zu einem von ihnen beantwortet man, indem man den Strom befragt, nicht denjenigen, der die Tabelle pflegt.

Das ist das Argument des Data-Governance-Grundpfeilers, um eine Pflicht weitergeführt, und das des Data-Contracts-Grundpfeilers, eine Ebene höher: Ein aus Verhalten erzeugtes Verzeichnis ist nur so gut wie das, was das Verhalten lesen durfte.

Diagramm-Erläuterung. Die untere Ebene ist ein einzelner Pipeline-Lauf: Der Deskriptor deklariert, wozu die Verarbeitung dient und auf welcher Grundlage, und der Lauf sendet beides auf einem einzigen Lineage-Event, zusammen mit der verwendeten Modellversion und den gelesenen Datensätzen. Die mittlere Ebene ist ein einziger Leser über diesen Strom. Die obere Ebene sind die vier Verzeichnisse, die dieser Leser erzeugt; sie können einander nicht widersprechen, weil jedes eine Projektion derselben Events ist und kein Dokument, das jemand pflegt. Die gepunktete Kante ist die Grenze: Verarbeitung, die nichts sendet, gelangt als deklarierte Tätigkeit in dieselben Verzeichnisse und bleibt als deklariert markiert, damit nichts, das nachgewiesene Verarbeitung zählt, sie für einen Nachweis hält.

Die Grenze gehört hierher, nicht erst in den Schlussabschnitt. Record-first erreicht nur Verarbeitung, die über eine Pipeline läuft und Lineage sendet. Ein Chatbot in der Weboberfläche eines Anbieters, in den Beschäftigte Daten hineinkopieren, durchläuft keine Pipeline und sendet kein Event, also gelangt diese Nutzung nie von selbst ins Verzeichnis. Dort findet heute vermutlich der größte Teil der KI-Nutzung außerhalb von Engineering-Teams statt, was eine Beobachtung ist und kein gemessener Anteil. Die Antwort für diesen Fall ist eine deklarierte Tätigkeit: der Anwendungsfall dort niedergeschrieben, wo das generierte Verzeichnis ihn aufnehmen kann, markiert als deklariert statt nachgewiesen, damit nichts, das nachgewiesene Verarbeitung zählt, ihn für einen Nachweis hält.

Was jede Seite dem KI-Anwendungsfall schuldet

Record-first-Readiness funktioniert nur, wenn drei Parteien Pflichten erfüllen, die klein genug sind, um sie daran messen zu können.

• Die Plattform schuldet Emission. Jeder Lauf trägt Zweck, Rechtsgrundlage, die gelesenen Eingaben und die Modellversion auf dem Event, und der Zugriff auf das Modell läuft über eine Grenze, die ihn protokolliert. Der Beitrag zum Katalog über MCP zeigt diese Form für einen Agenten, der governte Daten liest, und dort ist die Autorisierung die Governance-Ebene, nicht die Tool-Liste.
• Die Domäne schuldet Deklaration. Zweck und Rechtsgrundlage werden einmal im Deskriptor festgehalten, von den Menschen, denen die Daten gehören — und einen Anwendungsfall, den die Domäne nicht deklariert hat, weist die Plattform ab, statt ihn stillschweigend zu bedienen.
• Der Use-Case-Owner schuldet Verantwortlichkeit. Eine bestimmte Person, kein Gremium, verantwortet die Entscheidung, das System in Betrieb zu nehmen, die menschliche Aufsicht nach Art. 26 Abs. 2, wo es ein Hochrisiko-System ist, und das Gespräch mit dem Betriebsrat vor dem Livegang, wo Mitbestimmung gilt.

Nachweis vor Modell

Cordatas Position ist ein Satz, und es ist der Satz für das nächste Meeting, in dem ein Modell bereits gewählt wurde:

Die Frage, welche Daten ein System rechtmäßig lesen darf, wird beantwortet, bevor das Modell ausgewählt wird, und sie wird aus dem Governance-Verzeichnis beantwortet, nicht aus einem neuen, das daneben aufgebaut wird.

Auf die Reihenfolge kommt es an. Rückwärts aus einer funktionierenden Integration zu antworten ist das, was aus vier Wochen Pilot sechs Monate Arbeitsstrang macht, weil das Unternehmen dann dokumentiert, was es bereits tut, statt zu entscheiden, was es tun sollte.

Das ist kein Argument gegen Tempo. Ein Anwendungsfall, dessen Eingaben bereits deklariert sind, kann so schnell vom Pilot in die Produktion gehen, wie es sein Mitbestimmungsverfahren erlaubt, und das ist meist schneller, als der Programme-first-Weg seine erste Gremiumssitzung erreicht.

Was Cordata nicht verkauft

Cordata verkauft weder (a) AI-Readiness-Assessments, die einen Reifegrad als Punktzahl liefern, ohne zu beantworten, welche Daten ein Modell rechtmäßig nutzen darf, noch (b) KI-Governance-Programme, die neben der Data Governance laufen statt aus ihr heraus. Beide Absagen beruhen auf Erfahrung.

Ein Reifegrad ist eine Zahl. Er bewertet ein Unternehmen auf Achsen, die es nicht gewählt hat, im Vergleich mit Wettbewerbern, die es nicht sieht, und die Empfehlung am Ende lautet, die Zahl zu erhöhen. Die Frage, die den Produktiv-Rollout tatsächlich blockiert — welche Datensätze darf dieses Modell lesen, auf welcher Rechtsgrundlage, und wer kann das in einem Jahr nachweisen —, steht nicht auf der Bewertungsliste, weil ihre Bewertung bedeuten würde, das Verarbeitungsverzeichnis des Unternehmens zu lesen, und Aufträge dieser Art tun das selten.

Ein paralleles KI-Governance-Programm ist ein zweites Regelwerk. Es kommt mit einem Gremium, einem Register und eigenen Definitionen von Zweck und Rechtsgrundlage, und nach zwei Quartalen sind diese Definitionen von denen im Verarbeitungsverzeichnis abgedriftet, das sie ergänzen sollten. Dann gibt es zwei Antworten darauf, was das Modell nutzen darf, und ein Prüfer kann wählen, welche er prüft. Diese Drift ist ein Erfahrungsargument; was ein Leser selbst prüfen kann, ist die Abweichung, denn der Vergleich eines von Hand gepflegten Registers mit dem generierten Verzeichnis ist ein einziger Befehl im Werkzeug weiter unten.

Was Cordata stattdessen verkauft: Aufträge, die zuerst die Frage der Datenerlaubnis beantworten und Pflichten aus der KI-Verordnung als Projektion des Governance-Verzeichnisses behandeln, nicht als neues Verzeichnis. Wo sich das Verzeichnis nicht erstellen lässt, ist genau das der Befund, und die KI-Arbeit wartet dahinter. Wir verzichten lieber auf den Auftrag, wenn ein Kunde die Readiness-Punktzahl ohne das Verzeichnis darunter will — ein Modell, dessen Eingaben sich nicht nachweisen lassen, kann nicht in Produktion gehen, und eine Punktzahl ändert daran nichts.

Welche Regeln jeden Betreiber erreichen und welche nur Hochrisiko-Systeme

Die drei DACH-Rechtsordnungen beantworten dieselbe Frage unterschiedlich, und die Trennlinie, auf die es ankommt, verläuft nicht zwischen ihnen, sondern zwischen den beiden Spalten unten. Die linke Spalte betrifft die meisten Leser; die rechte gilt, wenn ein Anwendungsfall unter Anhang III fällt, was bei den meisten nicht der Fall ist.

Wo KI-Verordnung und DSGVO dieselbe Frage stellen

Das meiste, was die Verordnung von einem Betreiber verlangt, ist eine Frage, die das Datenschutzrecht bereits stellt: wozu die Verarbeitung dient, ob die Eingaben für diesen Zweck taugen und welches Risiko für Menschen besteht. Diese Überschneidung stammt vom Gesetzgeber, nicht aus unserer Lesart — Art. 26 Abs. 9 verweist den Betreiber für die Datenschutz-Folgenabschätzung auf die Informationen des Anbieters nach Art. 13, und Art. 27 Abs. 4 in geänderter Fassung lässt die Grundrechte-Folgenabschätzung auf die Teile dieser Abschätzung verweisen, die sie braucht.

Wo sie sich tatsächlich unterscheiden

Die Überschneidung endet an vier Stellen, und sie zu benennen verhindert, dass die vorige Behauptung zu weit greift. Ein System kann überhaupt keine personenbezogenen Daten verarbeiten und trotzdem unter die Verordnung fallen. Die Betriebsprotokolle, die Art. 26 Abs. 6 erwartet, verlangt das Datenschutzrecht nicht, und der Grundsatz der Speicherbegrenzung spricht gegen ihre Aufbewahrung. Ob Eingabedaten ausreichend repräsentativ sind, ist eine Frage der Eignung, die der Grundsatz der Richtigkeit in der DSGVO nur teilweise erreicht. Und die KI-Kompetenz der Beschäftigten hat im Datenschutzrecht kein Gegenstück. Record-first-Readiness gibt jedem dieser Punkte einen Ort; zum Verschwinden bringt sie keinen.

Was die Pipeline tatsächlich emittiert

Die Behauptung, dass diese Verzeichnisse Projektionen eines einzigen Event-Stroms sind, ist lauffähiger Code und kein Diagramm, und beide Hälften sind öffentlich. Der Strom ist OpenLineage, was vor allem bedeutet, dass die Events von Werkzeugen lesbar sind, die niemand hier geschrieben hat. pipeline-runtime sendet die Events; qedro projiziert sie. Der Deskriptor unten ist das Betrugserkennungsbeispiel aus pipeline-runtime; das Event und die Betreiberansicht liegen in docs/evidence/ von qedro, aufgezeichnet aus einem echten Lauf.

Die Deklaration sind drei Zeilen in einem Deskriptor, einmal von der Domäne geschrieben, der die Daten gehören, neben den Eingaben und Schritten der Pipeline:

processing:                          # flows into the lineage job facet
  purpose: fraud-detection
  legal_basis: legitimate-interest

Der Lauf trägt sie nach außen, zusammen mit der Modellversion, die der Bewertungsschritt verwendet hat, und den gelesenen Datensätzen. Drei Felder eines COMPLETE-Events, also des Events, das OpenLineage beim Abschluss eines Laufs sendet, gekürzt aus der eingecheckten Aufzeichnung:

{
  "job": {
    "facets": {
      "processing": {
        "purpose": "fraud-detection",
        "legal_basis": "legitimate-interest"
      }
    }
  },
  "run": {
    "facets": {
      "cordata_provenance": {
        "step_params": {
          "score": {
            "model_version": "2026-07-fraud-v3"
          }
        }
      }
    }
  }
}

Gekürzt aus fraud-event.trimmed.json; die gelesenen Eingaben stehen im selben Event, und der Job .validate sendet ein zweites Event, das die Prüfungen enthält und keines dieser Felder.

Die Betreiberansicht ist das Verarbeitungsverzeichnis, gelesen für eine andere Pflicht — derselbe Befehl, dieselben Objekte, ein Flag:

$ qedro ropa demo/lineage --config demo/qedro.yaml --view deployer

  acme.fraud/transactions-scored-daily  (fraud)
    purpose                  fraud-detection (mapping)
    legal basis              legitimate-interest (mapping)
    model version            2026-07-fraud-v3    7 runs, 2026-07-20 to 2026-07-26
    inputs read              warehouse/fraud_raw.device_events,
                             warehouse/fraud_raw.transactions
                             context for Art. 26(4), not a check of relevance or
                             representativeness
    run records              21 runs, 2026-07-06 to 2026-07-26 (20 days) — less than six
                             months in view
                             context for Art. 26(6), not a retention policy or a
                             compliance finding

Gekürzt aus deployer-view.md, indem Zeilen ausgelassen, nie umformuliert wurden. Das Werkzeug gibt seine Ausgabe auf Englisch aus. Die Abgrenzung, die bei jedem Lauf mit ausgegeben wird, sagt, was die Ansicht nicht entscheidet: ob ein Anwendungsfall hier ein Hochrisiko-Fall ist. Um die vollständige Ansicht selbst auszugeben: pipx install qedro, dann qedro demo in einem leeren Verzeichnis, dann den Befehl oben.

Drei Dinge in dieser Ausgabe sind das Argument, keine Dekoration. Zweck und Rechtsgrundlage sind mit (mapping) markiert statt als Nachweis dargestellt, weil sie aus der Konfiguration stammen und nicht aus einem gesendeten Event. Die Verweise auf Art. 26 sind als Kontext gekennzeichnet, nicht als Compliance-Befund — das Werkzeug berichtet, was die Läufe zeigen, und überlässt das Urteil einem Menschen. Und ein ohne Lineage deklarierter Anwendungsfall erscheint im selben Verzeichnis als deklariert markiert, sodass ein Leser sieht, welche Einträge auf Nachweisen beruhen und welche auf Behauptungen.

Die zweite Absage oben lässt sich auf dieselbe Weise prüfen: Für das eigene KI-Register eines Unternehmens und das generierte Verzeichnis meldet qedro diff die Felder, die voneinander abweichen, zusammen mit dem Verantwortlichen jeder Zeile.

Wann das die falsche Antwort ist

Record-first-AI-Readiness ist für mindestens drei Konstellationen der falsche Auftrag, und ein Grundpfeiler über KI, der nie Nein sagt, wäre genau der Hype, gegen den er sich positioniert.

Keine regulierten Daten und kein Anwendungsfall nach Anhang III. Ein interner Coding-Assistent oder Entwürfe für Marketingtexte. Eine kurze Liste von Anwendungsfällen, die Maßnahmen zur KI-Kompetenz nach Art. 4 und eine Nutzungsrichtlinie sind die richtige Größe; Projektionen aufzubauen würde mehr kosten als das Risiko, das sie abdecken.

Kein Verzeichnis, aus dem sich projizieren ließe. Wo es weder Lineage noch ein gepflegtes Verarbeitungsverzeichnis gibt, ist der Auftrag zuerst Data Governance, und ihn als AI Readiness zu verkaufen wäre genau die Umbenennung, die dieser Grundpfeiler ablehnt.

Anbieter statt Betreiber. Ein Unternehmen, das ein Modell entwickelt oder eines wesentlich verändert und unter eigenem Namen in Verkehr bringt (Art. 25), schuldet die Trainingsdaten-Governance nach Art. 10 und die technische Dokumentation nach Art. 11 und Anhang IV. Das ist Produkt-Compliance und ein anderer Auftrag als dieser.

Wie Cordata arbeitet

Aufträge beginnen mit einem Anwendungsfall, den der Kunde bereits geplant hat, nicht mit einem Framework. Zwei Wochen, vier Fragen: Lassen sich die Eingaben benennen, sind Zweck und Rechtsgrundlage verzeichnet, wem gehört die Entscheidung über die Inbetriebnahme, und lässt sich all das in einem Jahr zeigen?

Die Antwort bestimmt den Umfang. Lautet sie Ja, besteht die Arbeit darin, die Projektion anzubinden und diesen einen Anwendungsfall von Anfang bis Ende durchzuführen, was vier bis sechs Wochen dauert. Lautet sie „teilweise“, werden die konkreten Lücken geschlossen, und deklarierte Tätigkeiten decken ab, was keine Lineage sendet. Lautet sie Nein, ist der Befund, dass der Auftrag Data Governance ist, und die KI-Arbeit wartet dahinter.

Die Ergebnisse sind ebenso organisatorisch wie technisch — eine Person, die den Anwendungsfall und seine Aufsicht verantwortet, der Weg über den Betriebsrat, wo Mitbestimmung gilt, und das Entscheidungsprotokoll für den Anwendungsfall, neben den Deklarationen in den Deskriptoren und der laufenden Projektion. Übergabe zuerst, wie in den anderen Grundpfeilern: Gemessen wird daran, ob die Teams des Kunden den zweiten Anwendungsfall ohne uns hinzufügen.

Wenn Sie einen KI-Anwendungsfall durch eine rechtliche Prüfung gebracht und die Datenfragen aus dem Vorhandenen nicht beantworten konnten — oder sie aus einem Verzeichnis beantwortet haben, das Sie bereits hatten —, würde ich gern hören, welcher Teil gehalten hat. Die Tür steht offen unter cordata.tech/contact.

Begleitend und zum Weiterlesen: qedro projiziert die oben zitierten Verzeichnisse und lässt sich von PyPI mit pipx install qedro installieren; seine Pilot-Anleitung beschreibt den Einsatz mit der eigenen Lineage. pipeline-runtime sendet die Events, auf denen sie beruhen. Der Data-Governance-Grundpfeiler argumentiert, dass Governance-Artefakte aus Verhalten erzeugt werden sollten; der Data-Contracts-Grundpfeiler behandelt, was passiert, wenn die Daten darunter ihre Form ändern, ohne jemandem Bescheid zu sagen.