Back to Thoughts

When AI Regulation Turns Into a Procurement Checklist

4 min read · 970 words

AI Summary

The EU AI Act’s staggered deadlines and the rise of management-system standards are pushing AI governance out of legal teams and into procurement. If you can’t produce audit-ready evidence, you’ll lose deals long before a regulator knocks.

Olumide Adewole
Olumide AdewoleAI Engineer MBA, York St John University
Share

Procurement used to care about uptime, price, and whether your SOC 2 report was current.

Now it asks for your model evaluation plan.

That change matters more than most AI policy headlines. The EU’s AI Act has a calendar of obligations that arrive in waves, but companies don’t wait for regulators to show up. They update vendor questionnaires, push requirements into contracts, and make “show me the evidence” a condition of purchase.

Europe’s AI Act (Regulation (EU) 2024/1689) entered into force 20 days after publication in the Official Journal. It becomes fully applicable on 2 August 2026, with earlier dates for specific chapters. In practice, bans and definitions (Chapters I and II) have applied since 2 February 2025, and governance plus general-purpose AI obligations apply from 2 August 2025.

Outside the EU, the pattern is similar even when the law looks different. Regulators describe principles and risk outcomes; buyers translate them into controls. Standards bodies then turn controls into checkable requirements. That’s how “AI governance” becomes a procurement problem.

Core Argument

Most debate about AI compliance still treats the model as the unit of accountability.

Procurement teams treat the organisation as the unit of accountability. They want proof that you can manage risk over time: how you monitor drift, who can stop a deployment, how incidents get handled, what you tell users, what you log, and what you can explain after something goes wrong.

That shift changes who wins in AI.

1) The AI Act’s Timeline Rewards Early Evidence

A staggered law produces a simple business response: build a baseline assurance pack early, then reuse it.

If the law is fully applicable from August 2026, with earlier provisions already live, buyers can justify asking questions now. They are not “doing regulation”. They are protecting themselves from future remediation costs and reputational fallout.

The practical effect: teams that can document controls will sell into cautious sectors first. Teams that can’t will find themselves trapped in pilot purgatory, even if their demos look better.

2) Standards Are Becoming the Default Grammar

Two documents show where this is going.

ISO/IEC 42001:2023 is a management system standard for an Artificial Intelligence Management System (AIMS). It doesn’t tell you how to train a model. It tells you what an organisation needs to run AI responsibly: policies, roles, processes, continual improvement. That maps cleanly onto procurement because it looks like other management-system assurance approaches.

NIST’s AI Risk Management Framework (AI RMF 1.0) is voluntary, but it gives risk language that legal, security, and product teams can share. It’s built around functions such as “Govern” and “Measure,” which also fit procurement because they imply artefacts: ownership, metrics, and action.

In other words, the market is converging on a familiar shape: management controls plus risk documentation, with model testing as one part of the file.

3) “Explainability” Is Showing Up as a Contract Term

The UK Information Commissioner’s Office has guidance and tooling on AI, data protection, and accountability, covering governance, transparency, third parties, and human review.

That’s not abstract ethics. It’s a shopping list buyers can copy into contracts.

If your system touches individuals, the buyer will ask: what explanations exist, when are they given, who can contest, and what logs back it up. If your product can’t answer that, you don’t just have a policy risk; you have a sales risk.

4) The Supply Chain Will Decide Who Carries Liability

General-purpose AI systems changed the compliance story because the vendor might not control the final use case.

Procurement handles that the same way it handles any upstream dependency: it pushes obligations down the chain and demands rights to audit, disclose incidents, and change vendors.

The uncomfortable bit is that “we use a third-party model” is no longer a shield. It’s a prompt for more questions: what data you send, what outputs you store, how you reduce leakage, how you handle safety updates, and what happens when the upstream provider changes terms.

Counterpoint

There’s a real risk of checkbox theatre.

If organisations chase certifications without fixing decision-making, they will produce paperwork that looks clean while the system still fails users. Smaller firms will also struggle if the only acceptable answer becomes paid certification and heavy compliance overhead.

Regulators and buyers can reduce this by asking for a few high-signal artefacts instead of a mountain of PDFs, and by accepting credible equivalents when certification is out of reach.

Implications

For startups: treat assurance as product work. Build an evidence pack that you can hand to procurement without a scramble. That means clear ownership, a simple risk register tied to product changes, and a repeatable evaluation and incident process.

For enterprises: stop buying “magic”. Ask for operational controls, not marketing claims. If a vendor can’t explain how they monitor failures in production, you’re buying future clean-up.

For policymakers: align guidance with the artefacts organisations already use, and publish templates that reduce duplication. Every new reporting format becomes a tax on the teams you want to be safe.

Conclusion

AI governance is drifting away from press releases and into vendor portals.

The fastest enforcement mechanism isn’t a fine. It’s a procurement manager who can’t sign off because the evidence isn’t there. By the time the law bites, the market will already have picked its winners.

References

The writer does not take institutional positions on public policy issues; the views represented herein are those of the author(s) and do not necessarily reflect the views of the writer, its staff, or its trustees.