Data governance and AI readiness

What does data and AI governance actually mean in practice?

Data and AI governance is knowing what you have, who owns it, and what happens when it is wrong. Most governance programmes fail because they produce a policy set nobody reads and a review step teams learn to route around. The version that works puts controls where the data moves and gives every asset a person’s name against it.

Why this is the engagement the German market is buying right now

Three things arrived at once. The EU AI Act put a deadline on questions companies had been deferring. Due diligence in funding rounds and exits started asking data questions that used to be a footnote. And the first generation of production LLM systems reached the point where somebody senior asked what happens when one of them is wrong and nobody could answer.

The specific thing I look for first

An agent you cannot trace is an agent you cannot ship.

The interesting engineering in an AI system is rarely the prompt. It is the context the system can reach, the permissions that have to hold at query time rather than at the interface, and the evaluation harness that tells you when the thing quietly got worse. Governance for AI is mostly those three, made visible.

What eight to twelve weeks buys

Inventory before policy. You cannot govern what you have not listed. This part is unglamorous and it is where the surprises are.

Ownership with names. “The data team owns it” is not ownership. A person is.

Controls in the pipeline. Quality checks that run where the data moves, alerting that goes to an owner rather than to a channel, and contracts on the interfaces that matter.

Risk tiering, not risk theatre. Your model and use-case inventory mapped to EU AI Act categories, so the compliance effort lands on the handful of systems that warrant it.

A policy set people read. Short, specific, and paired with the training that changes behaviour. At HelloFresh the training was the part that moved the numbers, and the case study covers what I got wrong about who to train first.

The sequence I use, and where it came from

Engineers first, then internal users, then customers. Legal in the room from the first design review rather than as an approval gate at the end.

That is not a framework I read. At Babbel I shipped the company’s first AI agent as an internal application and then the customer-facing agents that followed it, and the transformation was kick-started by putting agents in the hands of engineers before anything went near a customer. Engineers find the failure modes fastest, describe them precisely, and tolerate a rough edge while it gets fixed. A customer does none of those three.

Running compliance with Legal as a partner rather than as a gate is the other half. Internal policy, EU AI Act obligations and GDPR posture were worked out alongside the build, which meant the answer to “can we do this” arrived while the design was still cheap to change.

Related work

I built HelloFresh’s data management department and its Data Academy, shipped Babbel’s first AI agents with the compliance position developed alongside them, and I am currently running an AI governance engagement for a Berlin deep-tech manufacturer covering exactly this scope: AI enablement, governance, and the data foundations underneath both. That engagement is published anonymised at the client’s discretion.

I also build in this space. AI Control Plane is a semantic governance layer that makes LLM decisions traceable, reproducible, and policy-enforced through a transparent gateway, with immutable audit trails and a provenance graph. It exists because I kept needing it.