Why AI Governance Is an Engineering Problem, Not a Legal One

AI governance is decided by infrastructure, not by policy. A policy states intent; access controls enforced by the platform, lineage from every AI output back to its source data, and an architecture that can be audited and corrected decide whether that intent holds. Those are engineering deliverables, which is why governance led by legal alone stalls.

Walk into most enterprise leadership meetings right now and you will hear the same plan. Draft an AI ethics policy. Hand it to legal. Get it signed off by the board. Done.

Meanwhile, the data pipeline feeding every model the company touches is exactly what it was before anyone wrote a word of that policy: a patchwork of spreadsheets, half-documented databases and systems nobody fully trusts. A PDF does not stop a large language model from hallucinating on sensitive client data. It does not stop an AI agent from acting on a customer record that was wrong six months before anyone noticed. And it does not retroactively build the access controls, lineage tracking or clean architecture that governance depends on.

Policy is a statement of intent. Infrastructure is what determines whether that intent means anything.

The gap is not a hunch, and it is not a minority problem. The research of the last eighteen months points the same way, and it points at the platform rather than the paperwork.

#What AI Governance Actually Means in an Enterprise

What this means for you: if a control cannot be shown working in the system, it is a rule people are trusted to follow, not governance.

AI governance, in the sense that survives an audit, is the set of controls that determine what data an AI system can reach, how its outputs can be traced and corrected, and who can change it — enforced by the platform rather than described in a document. The policy matters: it says what the organisation intends and what it will not do. But the policy is the specification. The controls are the implementation.

The term is often used more loosely, to mean the ethics charter, the review committee or the risk register. Those are inputs to governance. None of them can stop a model reading a field it should not see.

#The Numbers Behind the Gap

What this means for you: the organisations stalling on AI are not short of policy; they are short of the data infrastructure the policy assumes.

Gartner's February 2025 forecast is that through 2026, organisations will abandon 60% of AI projects that are not supported by AI-ready data. The same research, a survey of 1,203 data management leaders, found that 63% of organisations either do not have, or are unsure whether they have, the right data management practices for AI. That is closer to two in three than to a minority.

Redgate's 2026 State of the Database Landscape research found that only 23% of organisations use formal data governance or data quality frameworks to manage their AI-era data. More than a third, 36%, run four or more separate database platforms. Each one is a separate place where lineage has to be tracked and access has to be enforced, and a separate blind spot when it is not.

#Agentic AI hits the same wall, sooner

Agents raise the stakes, because they do not only answer questions — they act on a company's behalf. A Harvard Business Review Analytic Services survey of 603 business and technology leaders, published in December 2025, found that 9% of organisations had fully deployed agentic AI, and only 6% fully trusted AI agents to run core business processes. Readiness was lower than appetite: 20% said their technology infrastructure was fully ready for agentic AI in core processes, 15% said the same of their data and systems, and 12% said their risk and governance controls were fully in place.

Gartner's June 2025 forecast is that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear business value and inadequate risk controls. The third of those is a governance failure by definition, and it is an engineering one: risk controls for an agent are permissions, limits, logs and a way to stop it, not a paragraph in a policy.

#Why Governance Keeps Getting Filed Under Legal

What this means for you: give governance to the function that writes the rules and you have given it to the function least able to make them true.

It is an understandable mistake. Ethics, bias and responsible use genuinely do have legal and regulatory dimensions, and legal teams are right to be in the room. The EU AI Act places duties on deployers, and since 5 February 2026 UK GDPR Articles 22A to 22D permit significant automated decisions only with safeguards. Interpreting those instruments is legal work.

Implementing them is not. A legal team can write a policy stating that customer data must be used responsibly and that AI outputs must be explainable. What a legal team cannot do is restructure how that data is stored, tag who has access to which field, track where a given number in a report actually originated, or rebuild a monolithic legacy system into something that supports clean, auditable access in the first place.

So the work falls into a gap. Legal owns the document and cannot change the platform. Engineering owns the platform and was never told the document created work for it. The policy is signed, the backlog is unchanged, and the first anyone hears of the difference is an incident. The operating model that turns the EU AI Act into named owners and gates exists to close exactly that gap, but it only works if the gates are built, not described.

#What Engineering-First Governance Looks Like

What this means for you: each line of the policy should map to a control you can point at in the platform, with an owner and a test.

In practice, governance has to be designed into the data infrastructure itself, whichever cloud or platform it runs on — GCP, Azure or Palantir Foundry. The platform changes the tooling. It does not change what has to exist. Three things define it in a real engagement.

#Controls that are code, not prose

The most reliable way to make a rule hold is to make breaking it fail a build. Governance as code covers the mechanics: quality rules, access policies and lineage expectations expressed as version-controlled artefacts that pipelines enforce automatically. The point for this argument is simpler. A rule enforced in continuous integration does not depend on anyone remembering it.

#Evidence the platform produces by default

A governed platform produces its own audit evidence as a by-product of running: access logs, lineage graphs, quality results, deployment history. That changes what an audit is. Instead of a quarterly exercise reconstructing what probably happened, it becomes a query against what did. The five disciplines that make a domain AI-ready — ownership, definition, lineage, classification and quality — are what that evidence is built from.

#Why Sequencing Decides Whether Governance Holds

What this means for you: governance added after an AI system is live is a retrofit, and retrofits are where the cost and the gaps come from.

This is the same principle behind why sequencing matters so much in any AI initiative. Deploying an intelligent model or an autonomous agent on top of an ungoverned, poorly understood dataset does not produce a slower version of the right outcome.

It produces a fast, confident way to scale an existing data problem, dressed up as innovation.

The case for repairing the data before layering AI on top is made in full elsewhere. What matters here is the governance consequence. Controls designed in before deployment shape the architecture. Controls bolted on after it have to work around an architecture that was never built to carry them — and every workaround is a place where the policy and the system quietly disagree. Continuous data observability is what tells you, after go-live, that they still agree.

#When Engineering-First Is the Wrong Frame

What this means for you: engineering-first does not mean engineering-only, and treating it that way fails for a different reason.

Gartner's own research cuts the other way on one point, and it deserves a straight answer. A Gartner survey of 223 data and analytics leaders, conducted in March 2026 and published that September, found that 60% cited cultural resistance as a reason governance initiatives fail, against 40% citing funding constraints. Gartner's warning is that many organisations stay focused on policy creation and technology enablement while overlooking culture, and its advice is to treat governance as a responsibility shared between business and technology teams, not an IT-only function.

That is a real limit on this argument. A platform can enforce a control; it cannot make a business team care whether the definition behind a field is right, or make an executive sponsor stay engaged after launch. Engineering builds the controls. Business owners decide what the controls should protect. Legal interprets what the law requires. Remove any one of the three and governance fails, just in a different place.

There are also cases where heavy engineering is premature. A prototype on public or synthetic data, with no route to a customer and no decision attached, does not need a lineage platform. Building one before the use case has proved itself is its own kind of waste. The test is consequence: the moment an AI system touches personal data, a customer or a decision about a person, the controls need to exist in the system, not in the deck.

#Three Questions Before the AI Policy Is Signed Off

What this means for you: these can be answered in an afternoon, and the answers tell you whether the policy is protecting anyone yet.

Before any AI ethics policy is treated as the finish line, ask three questions that have nothing to do with the document itself. Ask the people who run the platform, and ask for a demonstration rather than an assurance.

If the honest answer to any of these is no, the ethics policy is not protecting anyone yet. It is a statement of good intentions sitting on top of infrastructure that was never built to carry it.

#What to do with the answers

1. Turn every "no" into a backlog item with an owner and a date. A governance gap that stays in a risk register is a gap nobody is fixing.
2. Map each policy clause to the control that enforces it. A clause with no control behind it is either a build item or a sentence to remove.
3. Have engineering and legal sign the policy together. Legal confirms it says what the law requires; engineering confirms the platform can do what it says.
4. Re-run the three questions at every major change — a new model, a new data source, a new agent permission. Governance that is checked once a year is described, not enforced.

This is the work at the centre of our data architecture practice and our security and compliance work: turning the controls a policy assumes into ones the platform enforces. It is also the same test of control that decides whether a client still owns an AI system once its builder leaves.

Governance that works is not the policy a legal team signs off once a year. It is the architecture an engineering team builds in from day one, and keeps enforcing every day after.

#Frequently Asked Questions

#Is AI governance a legal responsibility or an engineering one?

Both, but they own different parts. Legal interprets what regulation requires and drafts the policy that states it. Engineering builds the access controls, lineage, quality checks and audit trails that make the policy true in practice. Business owners decide what the controls protect. Governance led only by legal tends to produce a signed policy with no engineering work behind it, so the systems behave as if the policy did not exist.

#What does engineering-first AI governance include?

Three things in most enterprise estates. Access controls tied to identity and enforced where data is queried, so a model or agent only reaches what it should. Data lineage from each AI output back to its source records, so decisions can be traced and challenged. And a modular architecture that can find and reprocess affected records, and absorb a new model or regulation, without being rebuilt from scratch.

#Why do AI projects fail on governance rather than on the model?

Because the data underneath is not ready. Gartner forecast in February 2025 that through 2026 organisations will abandon 60% of AI projects lacking AI-ready data, and found 63% of organisations without, or unsure of, the right data management practices for AI. Redgate's 2026 research found only 23% using formal data governance or quality frameworks for AI-era data.

#How can we test whether our AI governance is real?

Ask three questions of the team that runs the platform, and ask for demonstrations. Can they trace a recent AI output back to its source data? Does an out-of-role query through the AI path fail, and get logged? Can they find and reprocess every record affected by a known-bad input without a months-long project? Any "no" marks a control that exists in the policy but not in the system.

#Does governance have to be built before an AI pilot starts?

Not for every pilot. A prototype on public or synthetic data, with no customer exposure and no decision attached, can run on lighter controls while the use case proves itself. The threshold is consequence. Once a system touches personal data, a customer or a decision about a person, its access controls, lineage and correction path need to exist in the platform before it goes live.

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing where AI governance work should sit before your next deployment, book a discovery call and we will work through it with you.