13 Months Before EU High-Risk Rules Apply: The 6 Evidence Gaps Your GCC Should Close in 2026

Picture a Pune Team Asked for Its Logs

Imagine a GCC team in Pune that built a CV-screening assistant for its German parent in 2025. It works, recruiters like it, and nobody has opened the repository since launch. In early 2028 a works council asks which candidates the system ranked last spring, what it based the ranking on, and who reviewed the output before anyone was rejected. Employment screening sits on the Annex III list. The question is not exotic, and the team has to answer it with records rather than recollection.

The Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and in force from 27 July, gave that team more time. Annex III high-risk systems, which cover areas such as employment, credit, education, and biometrics, now apply from 2 December 2027. Systems embedded in regulated products under Annex I move to 2 August 2028. What the omnibus did not do is relax the content of the obligations: risk management, data governance, technical documentation, human oversight, record-keeping, and conformity assessment are all still there. Some of the Act applies already. Chatbot disclosure and the other Article 50 transparency duties started on 2 August 2026, and the marking rule for generative systems already on the market follows on 2 December 2026.

GCCs feel this more than most organizations because they are often the party that actually builds, tests, and operates the system, while the parent owns the customers and the legal entity. The Act reaches providers and deployers outside the EU when the output of a system is used in the Union, so an Indian center serving an EU-facing parent can be in scope without any EU presence of its own. Whether the GCC counts as provider, deployer, or neither depends on the contracts and on whose name the system is put into service under. That is a question for counsel, and it is the first thing to settle.

"A deadline that moved is still a deadline. The only thing that changed is how much evidence you can build before someone asks for it."

Six Evidence Gaps We See in GCC AI Programs

Each row is a gap between what a regulator or an EU parent's auditor would ask for and what most GCC teams could produce today. Severity reflects how hard the gap is to close once a request arrives.

Evidence Is an Engineering Artifact, Not a Legal One

Lawyers can interpret the Act, but they cannot produce a six-month log of model inputs and outputs. That has to come from the platform. Deployers of high-risk systems are expected to keep the logs the system generates for at least six months, and providers have to design systems so that logging is possible in the first place. If your agent platform discards traces after a week to save storage, the legal position is weak before anyone has argued about it.

Oversight works the same way. A named reviewer is a policy. A review queue that records who saw which output, how long they looked, what they changed, and how often they disagreed with the system is evidence. Teams that already run agents in production often have most of this data in their observability tools, just not in a form anyone has reviewed. A quarterly look at override rates and review times will show whether oversight is real. An override rate near zero is not good news. It usually means reviewers have stopped checking.

Intended use is the cheapest document and the most useful one. One page per system stating who uses it, for what decision, on whom, and what it must not be used for gives you the basis for classification, for the risk file, and for contract language with the parent. It also gives product owners something to point to when a requester asks to extend a tool to a new use, which is how many systems drift into high-risk territory without anyone deciding they should.

Checklist: Could Your GCC Produce an Evidence Pack Today?

Pick one customer-facing or people-affecting system and test it against these. Anything you cannot show is a gap to close before December 2027.

"If you could not hand an auditor one system's full evidence pack by Friday, you have your answer about where to start."

What to Do This Week

01 Build the register from what you can already see

Start with sources that cannot lie: the API gateway, cloud billing for model endpoints, procurement records for AI tools, and the repositories that call a model SDK. Merge them into one sheet with an owner, a purpose, the data used, and a yes or no on whether output reaches EU employees, customers, or applicants. Expect to find systems nobody on the leadership team knew about. That is the point of the exercise.

02 Classify your five most people-affecting systems

Rank the register by how directly a system influences a decision about a person: hiring, pay, credit, insurance, access to services, or education. Write the one-page intended use for the top five and compare each against the Annex III categories with your legal team. Record the outcome even when the answer is not high-risk, with the reason. A documented no is useful evidence later.

03 Settle roles with the parent in writing

Put one question to the parent's legal and procurement teams: for each system in the top five, who is the provider, who is the deployer, and who holds the logs? Draft a short annex to the services agreement that states the answer and names a contact on each side. Differences of opinion are far cheaper to resolve now than during an inquiry.

04 Run an evidence drill on one system

Choose a system and pick a decision it supported thirty days ago. Ask the team to produce the inputs, the model version, the output, the reviewer, and any override within two working days. Time it and list everything that was missing. Repeat the drill after each fix until the pack takes hours, not days, and then add the next system.