An engagement pattern, not a named client. The sequence, the constraints and the decisions below are how these programmes actually run. No client is identified, and no outcome figures are claimed.
The trigger
An enterprise prospect sent a procurement questionnaire with a section nobody in the company could answer: "Describe your obligations under Regulation (EU) 2024/1689 and your timeline for meeting them."
The company is UK-registered, UK-staffed, with no EU entity and no EU office. The working assumption internally had been that the AI Act was somebody else's problem. That assumption was wrong, and the reason it was wrong is the single most common misunderstanding of this regulation.
The constraint
The Act does not follow your registered address. It reaches providers who place an AI system on the EU market, deployers established in the EU, and providers or deployers located anywhere in the world where the output of the system is used in the EU. A UK company with EU customers is in scope through the third route, with no EU presence of any kind.
The second constraint was harder. The team believed they had no high-risk system. What they had was a feature that ranked and shortlisted job applicants for their customers - which is squarely inside Annex III. It had been built as a small convenience feature and had never been reviewed as anything else.
The third constraint was time. Procurement wanted an answer in two weeks, and the honest answer required knowing which of several dates applied.
What was delivered
Week 1: establishing reach, not reading the law. The first question is not "what does the Act say" but "which of its routes touches us". Mapping where system output actually lands - by customer, by region, by feature - answered that in three days and produced something the procurement team could quote.
Week 1: an inventory that included the things nobody called AI. The shortlisting feature was found this way. So was a support-triage classifier and a document summariser that had been added by a product team without a review, because neither was thought of as AI. This is the step that changes the answer most often, and it is the step most frequently skipped.
Week 2: obligations separated by role. The company was a provider of one system and a deployer of three others bought in from vendors. Those carry different duties, and the deployer duties were the surprise: buying a compliant system does not make the buyer compliant, and substantially modifying one - or putting your own name on it - can turn a deployer into a provider of it.
Week 2: a dated plan rather than a list. Each obligation was paired with the date it takes effect, taken from the Official Journal text rather than from secondary commentary, and with the internal owner who would have to do the work.
What made the difference
The finding that mattered was not a legal one. It was that a feature built in a fortnight, by a team acting entirely reasonably, had moved the whole company into a regulatory tier it did not know existed.
That is not a governance failure in the usual sense. Nobody was careless. The feature simply crossed a line that had not been drawn anywhere the team could see it. Which is the argument for an AI inventory that is maintained rather than compiled once: the classification does not change when you review it, it changes when someone ships.
Where this usually goes next
Scoping tells you which obligations apply. It does not tell you how far from them you are, and the gap is almost never where teams expect. In the two engagements that most resembled this one, the technical controls were in reasonable shape and the missing pieces were documentary - the risk management file, the logging, and evidence that human oversight was real rather than nominal.
You can run the first part of this yourself. The EU AI Act scope checker works through the same six questions and returns a dated obligation list with the source behind every date.