AI Readiness — a data governance outcome, not a separate programme

The pilot that never became a rollout

A pilot on a foundation model works in four weeks. It summarises claims, or triages support tickets, or scores leads, and the demo is good enough that someone asks how soon it can go live. Then the rollout meets legal review and the questions arrive: which records does it read, on what basis, who approved that, and could we show a supervisory authority next year. Nobody can answer from anything that already exists, so a workstream is opened to produce the answers, and six months later the pilot is still a pilot.

More often than not, a stall like this comes from one of two causes, and frequently from both.

Capability before permission. The model is chosen and integrated before anyone can say what data it may use and on what legal basis, so the answer has to be reconstructed backwards from a working integration — the most expensive direction to travel, because the question stops being what the system should be allowed to read and becomes how to describe what it already reads.

The parallel regime. AI governance is set up as a new programme with its own committee, register and definitions of purpose and legal basis, placed beside the data governance the organisation already owes under the GDPR — the DSGVO in German-speaking markets — rather than built as an application of it.

The usual explanations — the wrong model, immature vendors, no AI talent in house — are real and sit downstream of those two. A team with all three solved still stalls at the same review if it cannot say what the model may read.

Why this costs more in the EU, and why now

In the EU, three sets of rules apply to the same AI use case at once, and each asks a version of the question the legal review in the pilot asked — what does this system read, and on what basis. The AI Act asks it of the system itself, with duties that grow with the system's risk tier. The GDPR asks it of every processing activity, and the organisation already owes the answer in writing, in the record described below. And in Germany and Austria, co-determination gives the works council a right to be consulted on new technology and to agree before anything able to monitor employees is introduced, so a workplace AI tool needs the same answer a third time.

The Art. 30 record is what the rest of this pillar builds on. Art. 30 GDPR requires every organisation that decides how personal data is processed — the controller, in the regulation's terms — to keep a record of its processing activities, the RoPA, called the Art. 30 record or simply the processing record from here on. For each activity it lists the purposes, the categories of people and data involved, the recipients, transfers abroad, erasure periods and security measures. Organisations under 250 employees are exempt only if their processing is occasional, is not likely to result in a risk to the people concerned, and involves no special-category or criminal-offence data, so in practice almost every organisation owes one. A Commission proposal of May 2025 would widen that exemption to organisations under 750 employees and narrow its condition to processing likely to result in a high risk; it had not been adopted by October 2026, and the AI use cases the Act treats as high-risk are mostly the kind of processing that would stay on the record either way. The legal basis is not on the article's own list, but supervisory authorities' templates ask for it next to the purposes — the Thuringian authority's guidance among them — and that is where this pillar assumes it is kept.

An organisation with a dedicated AI compliance function can absorb a parallel regime, however wasteful; one without such a function cannot, and for it deriving the AI records from the governance record is the only version anyone maintains past the first quarter.

The nearest AI Act deadline is not the argument for acting now. The Digital Omnibus — Regulation (EU) 2026/1744, in force since 27 July 2026 — moved the deployer duties in Art. 26 and 27 to 2 December 2027 for Annex III systems, a little over a year away. What binds already is the processing record, co-determination, the Art. 50 transparency duties since August 2026, and a national enforcement structure that now exists in Germany. The deferral is an argument for building the record once rather than for waiting: a year is enough to do that, and not enough to run a parallel programme and then reconcile it with the record it was meant to extend.

The specifics of each pressure — which duties depend on the risk tier, where co-determination reaches and where it stops, and how Switzerland answers the same question from outside the Act — are set out in the sidebar further down.

The parallel regime is what the first failure produces

The two causes are not independent. An organisation that cannot say what a model may read reaches for a framework whose purpose is to manufacture an answer, and a framework produces artefacts rather than evidence, because the lineage and purpose record it would need to cite was never built in the first place.

The register is typed by hand because there is no record to generate it from, and within two quarters its definitions of purpose and legal basis have drifted from the ones in the Art. 30 record it was meant to extend, leaving two answers to the same question and an auditor free to test whichever one it chooses.

The market sells the two halves separately, readiness assessments against the first and AI governance programmes against the second, and neither works without the record that sits underneath both.

What readiness means on the data plane

Readiness, seen from the data plane, is the ability to answer four questions about a proposed use case from records that already exist: what data it reads, for what purpose and on what legal basis, who owns the decision to use it, and whether all of that can be shown to somebody else a year from now.

Two readiness frameworks are worth naming, because this pillar covers what they leave unasked rather than disputing what they say. Straive's What Is AI Readiness? sets out five organisational pillars, one of them data, and argues explicitly for a sequenced roadmap rather than a scorecard. Microsoft's AI Readiness Assessment asks 72 self-rated questions across seven pillars and averages them into a Critical, Moderate or Excellent result, with Data Foundations among the largest pillars and lineage, privacy, minimisation and retention named inside it.

What the two share is the gap. In both, data is rated or described rather than evidenced — neither asks for a record, a lineage graph or any other artefact — and neither asks on what legal basis the data may be processed at all. Neither mentions the AI Act or the GDPR.

Three things readiness is commonly mistaken for, each producing a different wrong engagement:

• Not a self-rating. An answer assembled from what people say about their data is not evidence about the data, whether it ends in a score or a roadmap.
• Not model selection. Which model to use is a procurement decision, and it can be made well only once the four questions have answers.
• Not an AI strategy. A strategy names ambitions; readiness is a property of records.

Put positively, and in a form worth repeating back: readiness is evidence about data, applied to one more kind of processing.

The AI Act, as a deployer actually meets it

Most use cases are not high-risk, and saying so first matters, because a pillar that opens with the heaviest obligations reads as an argument from fear. The Act sorts systems into prohibited practices under Art. 5, high-risk systems listed in Annex III — employment, creditworthiness, life and health insurance pricing, access to essential services, and the rest — systems carrying transparency duties under Art. 50, and everything else.

What reaches any deployer, whatever the tier, is short. The prohibitions in Art. 5 bind everyone. Art. 4 asks for AI literacy, and the Digital Omnibus weakened it to taking measures that support the development of AI literacy rather than guaranteeing any particular level of it, so it is not a duty to ensure competence. Art. 50(3) and (4) reach deployers of emotion recognition and biometric categorisation, and deployers publishing deep fakes or AI-generated text on matters of public interest; the rest of Art. 50 binds providers. Outside the Act and regardless of its tiers, the GDPR applies wherever personal data is involved, co-determination applies to workplace tools, and DORA applies to financial entities.

What a deployer of a high-risk system owes in addition is the minority case, and most of it is data governance with an AI-specific trigger. Beyond following the provider's instructions and reporting incidents, Art. 26 asks for human oversight by people with the competence and authority to exercise it (26(2)), input data that is relevant and sufficiently representative where the deployer controls it (26(4)), logs kept for at least six months where they are under the deployer's control (26(6)), and the workers' representatives and the people subject to its decisions told that a high-risk system is in use (26(7), 26(11)). For Annex III systems all of it applies from 2 December 2027.

The fundamental-rights impact assessment in Art. 27 is narrower still: high-risk systems only, and within those only public bodies and private deployers doing credit scoring or life and health insurance pricing. As the Omnibus rewrote it, Art. 27(4) lets a deployer cross-reference or incorporate the relevant parts of an existing data protection impact assessment (DPIA), the risk assessment the GDPR already requires under Art. 35 before any processing likely to put people at high risk — which is this pillar's argument written into the Act itself.

Read as a deployer, then, the Act asks little of most use cases — literacy measures, the prohibitions, and disclosure in a few listed cases — and where it asks more, for the high-risk minority, most of what it adds are questions about data rather than about models: whether the input is relevant and representative, who oversees the output, what was logged, and who was told. A maintained processing record already answers questions of that kind for every other processing activity, which is why the next section treats the AI obligations as one more reading of that record rather than as a register of their own.

The same record, projected once more

The records an AI deployer needs are projections of the processing record the organisation already owes, generated from the same events rather than maintained beside them.

Two shapes make the difference concrete, and the names given to them here are this pillar's own labels rather than established terms. Programme-first sets up an AI committee, an AI register in a spreadsheet, an AI policy and a separate approval workflow, and every use case is described by hand. The register and the Art. 30 record then describe the same processing in different words, and nobody reconciles them because reconciling them is nobody's job.

Record-first has each pipeline declare its purpose and legal basis once, in its descriptor — the configuration file that says what a pipeline reads, what it writes and what it is for, and from which the platform runs it — and every run emits them on its lineage event beside the model version and the inputs it read. The events follow OpenLineage, an open standard for recording which job read and wrote which datasets, and the extra fields travel in its facets, the standard's own extension mechanism, rather than in a shape invented for this argument. The Art. 30 record, the inputs to a DPIA, the AI use-case register and the evidence for Art. 26(6), which requires a high-risk system's logs to be kept for at least six months, are then four views over one stream of events. A single reader over that stream produces all four. In Cordata's reference implementation that reader is qedro, an open-source tool, published on PyPI, that reads OpenLineage events and generates the Art. 30 record and the other views from them; What the pipeline actually emits further down shows its output from a real run.

Four documents that cannot disagree with one another, because none of them is typed: each is a projection of the same events, and a question about any of them is answered by asking the stream rather than by asking whoever maintains the spreadsheet.

That is the Data Governance pillar's argument carried one obligation further, and the Data Contracts pillar's carried one layer up: a record generated from behaviour is only as good as what the behaviour was allowed to read.

Diagram read-out. The bottom tier is one pipeline run: the descriptor declares what the processing is for and on what basis, and the run emits both on a single lineage event, together with the model version it used and the datasets it read. The middle tier is one reader over that stream. The top tier is the four records that reader produces, which cannot contradict each other because each is a projection of the same events rather than a document somebody maintains. The dotted edge is the limit: processing that emits nothing enters the same records as a declared activity, and stays marked as declared so that nothing counting evidenced processing mistakes it for evidence.

The limit is worth stating here rather than leaving to the closing section. Record-first reaches only processing that runs through a pipeline and emits lineage. A chatbot used in a vendor's web interface, with staff pasting data into it, runs no pipeline and emits no event, so that use never reaches the record on its own. That is plausibly where most AI use outside engineering teams happens today, which is an observation rather than a measured share. The answer for that case is a declared activity — the use case written down where the generated record can carry it, marked as declared rather than evidenced, so that nothing counting evidenced processing mistakes it for evidence.

What each side owes the AI use case

Record-first readiness works only if three parties meet obligations small enough to hold them to.

• The platform owes emission. Every run carries purpose, legal basis, the inputs it read and the model version on the event, and access to the model goes through a boundary that records it. The catalog over MCP post is the worked shape for an agent reading governed data, where authorization rather than the tool list is the governance plane.
• The domain owes declaration. Purpose and legal basis are written once, in the descriptor, by the people who own the data — and a use case the domain has not declared is one the platform refuses rather than one it quietly serves.
• The use-case owner owes accountability. One specific person, not a committee, answers for the decision to put the system into service, for human oversight under Art. 26(2) where it is high-risk, and for the works-council conversation before it goes live wherever co-determination applies.

Evidence before models

Cordata's position is one sentence, and it is the sentence to take into the next meeting where a model has already been chosen:

The question of what data a system may lawfully read is answered before the model is selected, and it is answered from the governance record rather than from a new one built beside it.

The order is the whole of it. Answering backwards from a working integration is what turns four weeks of pilot into six months of workstream, because the organisation is then documenting what it already does rather than deciding what it should.

This is not an argument against moving quickly. A use case whose inputs are already declared can go from pilot to production as fast as its co-determination process allows, and that is usually faster than the programme-first route reaches its first committee meeting.

What Cordata refuses to sell

Cordata refuses to sell (a) AI readiness assessments that produce a maturity score without answering what data a model may lawfully use, or (b) AI governance programmes run alongside data governance rather than out of it. Both refusals come from experience.

A maturity score is a number. It rates an organisation on axes it did not choose, against peers it cannot see, and the recommendation at the end is to raise the score. The question that actually blocks the production rollout — which records may this model read, on what legal basis, and who can evidence that a year from now — is not on the scorecard, because scoring it would mean reading the organisation's processing record, and engagements of this shape rarely do.

A parallel AI governance programme is a second rulebook. It arrives with a committee, a register, and its own definitions of purpose and legal basis, and within two quarters those definitions have drifted from the ones in the Art. 30 record they were meant to extend. Now there are two answers to what the model may use, and an auditor gets to choose which one to test. That drift is an argument from experience; what a reader can check for themselves is the disagreement, because comparing a hand-maintained register against the generated record is one command in the tooling below.

What Cordata sells instead: engagements that answer the data-permission question first and treat AI Act obligations as a projection of the governance record rather than a new one. Where the record cannot be produced, that is the finding, and the AI work waits behind it. We are willing to lose the deal when a client wants the readiness score without the record underneath — a model whose inputs cannot be evidenced cannot go to production, and a score does not change that.

Which rules reach every deployer, and which reach only high-risk systems

The three DACH jurisdictions answer the same question differently, and the split that matters is not between them but between the two columns below. The left column is where most readers live; the right applies if a use case lands in Annex III, which most do not.

Where the AI Act and the GDPR ask the same question

Most of what the Act asks a deployer is a question data protection law already asks: what the processing is for, whether the input is fit for that purpose, and what the risk to people is. That overlap is the legislator's rather than a reading of ours — Art. 26(9) sends the deployer to the provider's Art. 13 information when preparing the data protection impact assessment, and Art. 27(4) as amended lets the fundamental-rights assessment cross-reference the parts of that assessment it needs.

Where they genuinely differ

The overlap stops in four places, and naming them is what keeps the previous claim from overreaching. A system can process no personal data at all and still be in scope of the Act. The operational logs Art. 26(6) expects are not something data protection law asks for, and storage limitation pulls against keeping them. Whether input data is sufficiently representative is a question about fitness that the GDPR's accuracy principle only partly reaches. And staff AI literacy has no counterpart in data protection law. Record-first readiness gives each of these somewhere to live; it does not make them disappear.

What the pipeline actually emits

The claim that these records are projections of one event stream is running code rather than a diagram, and both halves are public. The stream is OpenLineage, which matters mainly because it means the events are readable by tools nobody here wrote. pipeline-runtime emits the events; qedro projects them. The descriptor below is pipeline-runtime's fraud example; the event and the deployer output are committed in qedro's docs/evidence/, captured from a real run.

The declaration is three lines in a descriptor, written once by the domain that owns the data, beside the pipeline's inputs and steps:

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

The run carries them outward, together with the model version the scoring step used and the datasets it read. Three fields of one COMPLETE event, the one OpenLineage sends when a run finishes, trimmed from the committed capture:

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

Trimmed from fraud-event.trimmed.json; the inputs the run read are in the same event, and the .validate job emits a second event that carries the assertions and none of these fields.

The deployer view is the Art. 30 record read for a different obligation — the same command, the same objects, one 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

Abridged from deployer-view.md by leaving lines out, never by rewording them. The scope statement printed with every run says what the view does not decide: whether any use case here is high-risk. To print the full view yourself, run pipx install qedro, then qedro demo in an empty directory, then the command above.

Three things in that output are the argument rather than decoration. Purpose and legal basis are marked (mapping) rather than presented as evidence, because they came from configuration rather than from an emitted event. The Art. 26 references are labelled as context, not as compliance findings — the tool reports what the runs show and leaves the judgement to a person. And a use case declared without lineage appears in the same record marked as declared, so that a reader can see which entries rest on evidence and which on assertion.

The second refusal above is checkable the same way: given an organisation's own AI register and the generated record, qedro diff reports the fields that disagree, with the owner of each row.

When this is the wrong answer

Record-first AI readiness is the wrong engagement for at least three shapes, and a pillar about AI that never says no is the hype it is positioned against.

No regulated data and no Annex III use case. An internal coding assistant, or drafts of marketing copy. A short list of use cases, the Art. 4 literacy measures and an acceptable-use policy are the right size; building projections would cost more than the risk they cover.

No record to project from. Where there is no lineage and no maintained Art. 30 record, the engagement is data governance first, and selling that as AI readiness would be the renaming this pillar refuses.

Providers rather than deployers. A company that develops a model, or substantially modifies one and places it on the market under its own name under Art. 25, owes the training-data governance of Art. 10 and the technical documentation of Art. 11 and Annex IV. That is product compliance, and a different engagement from this one.

How Cordata engages

Engagements start from one use case the client already has queued, not from a framework. Two weeks, four questions: can the inputs be named, are the purpose and the legal basis on record, who owns the decision to put it into service, and can all of that be shown a year from now.

The answer decides the scope. Where it is yes, the work is wiring the projection and taking that one use case end to end, which runs four to six weeks. Where it is partly, the work is closing the specific gaps, with declared activities covering whatever emits no lineage. Where it is no, the finding is that the engagement is data governance, and the AI work waits behind it.

Deliverables are organisational as much as technical — one person accountable for the use case and its oversight, the works-council path where co-determination applies, and the decision record for the use case, alongside the declarations in the descriptors and the projection running. Handover-first, as in the other pillars: the measure is whether the client's teams add the second use case without us.

If you have taken an AI use case through a legal review and found the data questions unanswerable from what existed — or answered them from a record you already had — I would like to hear which part held. The door is open at cordata.tech/contact.

Companion and further reading: qedro projects the records quoted above and is installable from PyPI with pipx install qedro, and its pilot guide covers running it against your own lineage; pipeline-runtime emits the events they rest on. The Data Governance pillar argues that governance artefacts should be generated from behaviour; the Data Contracts pillar covers what happens when the data underneath changes shape without telling anyone.