The problem is that pilots are designed to demonstrate capability, while production systems in regulated environments must demonstrate accountability. Those are different engineering targets, and retrofitting the second onto the first is where programmes stall.

What GxP delivery teaches about AI

In GxP environments — the good-practice regulations covering pharmaceutical and life-sciences work — no system touches production without answering a standard set of questions. Who owns it? What is it validated to do? What evidence shows it does that? What happens when it fails, and who is notified? How is change controlled?

These questions were written for lab systems and data platforms, but they map almost perfectly onto AI. An AI system that can answer them is deployable; one that can't is a demo, however impressive its output.

Design for the approval gate from day one

The practical shift is to treat the eventual approval gate as a design input, not a hurdle at the end:

• Name an accountable owner before writing a prompt. If no business function will own the system's outcomes, that is a signal about its real value.
• Define acceptance criteria the way you would for validation. Not "the summaries look good", but measurable thresholds a reviewer can test against.
• Log everything from the start. Inputs, outputs, model versions, prompt versions. Retrofitting an audit trail onto a pilot is far more expensive than including one.
• Decide the human-oversight points explicitly. Which outputs ship without review, which need a human, and who that human is.
• Write the rollback procedure before launch. A system you cannot pause is a system you cannot govern.

The payoff

Teams that work this way ship AI faster, not slower. Nothing gets pulled back at the audit stage, approval conversations become evidence reviews rather than negotiations, and the second and third use cases inherit the governance scaffolding of the first.

That is the premise behind our TRUST-AI assessments: governance is not the brake on AI adoption in regulated organisations. It is the mechanism that lets adoption survive contact with scrutiny.

For a group running continuous operations across finance, manufacturing, and supply chain, that clause is not a detail. It is an operational risk with a real revenue cost, and it deserves to be challenged.

Why the freeze exists

Freezes exist because point-to-point integration makes systems brittle. When every system talks directly to every other system, changing one mid-migration means re-testing the web around it. The freeze is not a methodology choice; it is a symptom of coupling.

Decouple first, migrate second

The alternative is to attack the coupling before the migration. Introducing an event-driven integration layer — in our recent work, Azure Service Bus — changes the bargain:

• Systems publish events instead of calling each other. The ERP core, manufacturing systems, and finance tools subscribe to the events they need.
• Each area migrates on its own timeline. Because consumers are decoupled from producers, cutting one system over does not destabilise the rest.
• The business keeps moving. Changes elsewhere in the estate ride through the same event contracts rather than breaking hidden dependencies.

Sequence by dependency, not by vendor playbook

The second half of the approach is analytical rather than technical: map the real process dependencies before any design decision, and let that map — not the implementation partner's standard sequence — set the migration order. When every design decision traces to a documented business requirement, stakeholders know what is changing, when, and why. That transparency is what makes a freeze unnecessary.

We delivered a group-wide consolidation this way — finance, manufacturing, and supply chain — with no programme-wide freeze at any point. The pattern is repeatable, and it starts with refusing the default clause.

The shape of the Act

The Act classifies AI systems by risk. A small set of practices is prohibited outright. High-risk systems — those used in areas like employment decisions, credit, critical infrastructure, and medical contexts — carry the heaviest obligations: risk management, data governance, technical documentation, logging, human oversight, and conformity assessment. General-purpose AI models have their own transparency obligations, and even limited-risk systems face disclosure duties, such as telling users they are interacting with AI.

Obligations phase in over several years, but the direction is fixed, and enterprise customers are already writing the Act's requirements into procurement questionnaires — which means the commercial deadline is arriving before the legal one.

A pragmatic starting sequence for UK organisations

1. Inventory. You cannot classify what you have not catalogued. Include embedded AI features, copilots arriving through office suites, and shadow tools teams adopted independently.
2. Screen for EU exposure. For each system, ask whether its outputs reach EU users or markets. This shortlist is where obligations may attach.
3. Risk-classify the shortlist. Map each system against the Act's categories. Most will land in minimal or limited risk — the point is to identify the exceptions deliberately rather than discover them in a customer audit.
4. Close the evidence gap. For anything approaching high-risk, start the documentation, logging, and oversight work now. These take quarters, not weeks.
5. Align with what you already do. GDPR data mapping, DPIAs, and — for regulated sectors — GxP validation discipline cover real ground. The Act rewards organisations that already treat evidence as a first-class deliverable.

The strategic view

Treating the Act as a compliance chore misses the commercial point: the organisations that can evidence their AI governance will win the enterprise deals that demand it. Our TRUST-AI Compliance & Governance Assessment maps an AI estate against the EU AI Act, GDPR, and NIST AI RMF for exactly this reason — the gap register it produces is as much a sales asset as a risk document.