When I first wrote about the EU AI Act in plain language for data teams, it was still mostly a future to prepare for — a law in force but with its sharpest obligations phasing in over a runway that felt comfortably long. The runway is no longer comfortable. The high-risk obligations are the ones with teeth, and for organisations whose AI touches things like credit, employment, essential services, or other regulated territory, "we'll deal with it later" has become "we're dealing with it now." So let me do the practical thing and translate the high-risk requirements into what they actually mean for the people who own the data and the systems — because that, it turns out, is who most of the work lands on.

The single most useful reframe I can offer is this: most of the high-risk obligations are data-governance obligations in a compliance costume. If you've done the unglamorous governance work, you're most of the way there. If you haven't, the Act is about to make you, and you'll discover the bill all at once. Let me walk the main obligations and show you why.

Risk management, as an ongoing system

The Act expects a risk-management process around a high-risk system — not a one-time sign-off but a living thing that identifies foreseeable risks, mitigates them, and gets revisited as the system and its data change. In practice this is the discipline of knowing what your model can do, where it can go wrong, who it can harm, and having a documented, repeatable way of checking. It's less a document than a habit, and the organisations that already run model reviews are adapting an existing muscle rather than growing a new one.

Data governance, said out loud

Here the Act is almost blunt about it: high-risk systems must be built on training, validation, and test data that is relevant, sufficiently representative, and appropriately examined for errors and bias. Read that again with a data engineer's ear. It is asking for data quality, lineage, and an understanding of representativeness — the exact governance work that makes any data trustworthy, now legally required for the data underneath a high-risk model. If you can't say where your training data came from, what's in it, and whether it skews, you cannot meet this obligation. A catalogue and real lineage — the kind Microsoft Purview or an equivalent gives you — stop being maturity nice-to-haves and become evidence.

Technical documentation and record-keeping

You must be able to show your work: documentation describing what the system is, how it was built, what data it used, how it performs, and what its limitations are — kept current, and detailed enough that a regulator (or your own auditor) can understand it. Alongside that, high-risk systems need logging — automatic records of the system's operation, so that events can be traced after the fact. For a data team, this is lineage and observability by another name: the ability to answer "where did this decision's inputs come from, and what happened when it ran." If you built logging and lineage for your own debugging sanity, you built a chunk of your compliance for free.

Human oversight and transparency

The Act requires that high-risk systems be designed so a human can meaningfully oversee them — understand the output, catch when it's going wrong, and intervene. And it requires transparency: the people affected, and the people operating the system, need appropriate information about what it does. Practically, this pushes against the fully-automated, black-box deployment. You need an off-ramp for human judgement and an explanation a person can act on. This is as much a design and product obligation as a data one, but the data team owns the part where "explain this output" requires lineage back to the inputs.

Accuracy, robustness, and security

Finally, high-risk systems must perform accurately enough for their purpose, behave robustly when conditions shift, and resist tampering. This is the obligation that most resembles ordinary good engineering — testing, monitoring for drift, securing the pipeline — but the Act makes it non-optional and asks you to evidence it, not just intend it.

What I'd actually do first

If you own data for a system that might be high-risk, here's the pragmatic order:

  1. Classify honestly. Is this system actually high-risk under the Act, or are you gold-plating? Get that judgement made properly — the obligations are heavy enough that you don't want to carry them for a system that doesn't need them, or skip them for one that does.
  2. Inventory the data. For any genuinely high-risk system, know your training and input data: source, meaning, quality, representativeness. This is the load-bearing wall, and it's plain data governance.
  3. Turn on the record-keeping. Lineage, logging, documentation — build the evidence trail as part of the system, not as a scramble before an audit.
  4. Design the human in. Make sure there's a real oversight point and a real explanation, not a rubber stamp on an opaque output.

The quiet part

Here's what I keep telling boards, and it's the counter to the doom framing: the AI Act is not, mostly, asking you to do exotic new things. It's asking you to do the governance you should have been doing, and to be able to prove it. That's a genuine cost, and I won't pretend the documentation burden is nothing. But the organisations treating it purely as a compliance tax are missing the trade: the same lineage, quality, and oversight that satisfy the regulator are what make your AI actually trustworthy and deployable. You can build this grudgingly, to avoid a fine, or deliberately, because a system you can explain and defend is a better system. Either way you end up in the same place — which is the most reassuring thing about the whole law, if you let it be.