Egon Expert Ltd is a UK company. Some of our clients are in the EU. That makes us a useful worked example for a question a lot of consultancies, agencies and software houses are currently getting wrong in both directions - some assuming the AI Act lands on them when it does not, others assuming it cannot reach them when it can.
I will use our own position throughout, because vague hypotheticals are how this subject gets muddled.
The four situations, and only one of them is complicated
Situation one: we advise, the client builds. A fractional CTO engagement where we shape architecture, review decisions and challenge a roadmap. We are not developing an AI system. We are not placing anything on the EU market. The AI Act does not apply to us at all. It may apply intensely to the client, and part of our job is telling them so, but the obligation is theirs.
Situation two: we use AI tools while delivering. Our engineers use coding assistants. That makes us a deployer of a minimal-risk system, which carries essentially no obligation under the Act. What it does carry is contractual exposure: an EU client may well have terms about what may be sent to third-party AI services, and their terms are the binding constraint, not the Act. This is why we keep a written AI governance policy and can hand it over on request. It is asked for more often than it used to be.
Situation three: we build something the client ships under their name. We write an AI-enabled feature; the client places it on the EU market as their product. The client is the provider. We are a third party in the value chain. The Act does not make us the provider - but it does reach us, and this is the part most suppliers have not noticed.
Situation four: we build and operate something under our own name for EU users. Then we are the provider, we carry the provider obligations, and if the system were high-risk we would need an authorised representative established in the EU. We do not currently do this. If we did, the analysis would change completely.
Situation three is where the real work is.
Article 25: the clause that catches suppliers
Where a third party supplies tools, services, components or processes that are used in or integrated into a high-risk AI system, that third party and the provider must, by written agreement, specify the information, capabilities, technical access and other assistance needed to let the provider comply with the Regulation.1
Read that again from a supplier’s chair. If our client is building something high-risk and our code is inside it, we are contractually obliged to give them what they need to satisfy Articles 9 to 15. That is not a light commitment. It includes the documentation behind design decisions, the provenance of any data we handled, the logging we built or failed to build, and continued access to us after the engagement ends.
There is a carve-out for tools released publicly under a free and open-source licence, other than general-purpose AI models. There is also an express protection for intellectual property, confidential business information and trade secrets - you are not required to hand over your source code because a client invoked Article 25.
What each side actually owes the other
The EU client owes the supplier a classification. Before work starts, they should say whether the system is high-risk and why. Suppliers cannot price or design correctly without it, and clients frequently do not know. If nobody has done this analysis, that is the first deliverable, not an afterthought.
The supplier owes the client documentation as a work product, not as a favour. Under the old model you delivered working software and a README. Under this one, if the system is high-risk, technical documentation is part of the definition of done. Deciding that at handover is how projects go over budget.
The client owes the supplier honesty about intended purpose. A system’s risk tier is set by what it is for. If the client changes the intended purpose after delivery - repurposing a scoring tool for employment decisions, say - the classification changes and the supplier’s original work may no longer support compliance. That is a change of scope, and it should be contractually treated as one.
The supplier owes the client a straight answer about AI in the delivery process. If AI tools were used to produce the code, say so, say where, and say what review it went through. This is fast becoming a standard procurement question, and the honest answer is a competitive advantage rather than a confession. We publish how we handle it in reviewing AI-generated code.
What belongs in the contract now
Six clauses that were not in our contracts two years ago and are in them now.
Role allocation. Name who is provider and who is deployer for each system in scope, in writing. Ambiguity here is the single most expensive thing in this whole area.
Intended purpose, stated. Write down what the system is for. Make changes to it a formal variation.
Article 25 cooperation. What information and technical access the supplier will provide, in what format, within what timescale, and for how long after the engagement ends. Put a boundary on it, or you have signed an open-ended obligation.
Documentation as deliverable. If the system is or may become high-risk, list the technical documentation among the deliverables with acceptance criteria, so it is scoped and priced.
AI use in delivery. Whether the supplier may use AI tools, on what material, and what disclosure is required. Both directions - clients also need to know whether their own staff may paste supplier material into tools.
Change of law. Who bears the cost when the timetable moves. It moved in July 2026, three months before the deadline everyone was working to. It may move again.
The honest commercial picture for UK suppliers
The UK has no AI Act and no AI bill before Parliament. Domestically, a UK consultancy is regulated through existing law - the ICO where personal data is involved, sector regulators elsewhere.2 Nothing about the EU regime changes that.
What has changed is procurement. European clients are adding AI questions to supplier questionnaires: what tools do you use, what happens to our data, do you have a written policy, can you support our Article 25 obligations. A supplier who answers those in a day wins work from suppliers who need three weeks and a lawyer.
That is the real effect on a business like ours. Not enforcement risk - we are advisers and, in most engagements, not in scope at all. Commercial risk, arriving through client contracts long before any regulator would.
The counterpart, which I think is under-appreciated: this is a genuine advantage for small suppliers who get organised. A dated, versioned AI policy and a clear position on provider-versus-deployer costs a couple of days to produce. It is exactly the kind of thing large competitors are slow at, and clients notice.
If you are the EU client reading this
Your supplier is probably not in scope and probably cannot tell you whether you are. Do the classification yourself, or get it done independently, before you brief anyone. Then flow the consequences into the contract rather than discovering them at acceptance.
And be specific about what you are asking for. “Are you AI Act compliant?” is not a question a supplier can answer, because compliance attaches to systems and roles rather than to companies. “Are you the provider of this system, and if we are, will you support our Article 25 obligations” is a question with an answer.
We do this analysis as a fixed piece of work - typically two to three weeks alongside the technology review, ending with a written position for both sides of the contract. If that would be useful, book a free half-hour and we will tell you whether you need it.
References
- Regulation (EU) 2024⁄1689, Article 25 (responsibilities along the AI value chain), on EUR-Lex. See also the European Commission’s regulatory framework overview.
- Information Commissioner’s Office - Guidance on AI and data protection.