The AI Act’s Implementation Phase: What AI Teams Should Document in Late 2026

The EU AI Act has moved from a distant policy debate into the operating calendar of companies that build or deploy AI in Europe. The regulation entered into force on 1 August 2024, with obligations phased in over several years. Prohibitions applied from 2 February 2025. General-purpose AI obligations applied from 2 August 2025. High-risk obligations for Annex III systems are scheduled from 2 August 2026, with Annex I product rules following on 2 August 2027.

That timetable means late 2026 is not a planning exercise for many teams. It is the first year in which they may need to show how a system was assessed, how it is monitored, and who is responsible when it fails. The exact scope depends on the system and the organization’s role, so legal review is essential. The engineering work, however, is increasingly clear.

First, build an inventory that reflects reality

You cannot classify what you cannot see. A useful AI inventory goes beyond a list of vendors. It records each use case, the business owner, the model and provider, the data sources, the people affected, the decisions supported, and whether the system is built internally or purchased.

Include shadow AI: browser extensions, embedded features in SaaS tools, and experimental projects that never went through procurement. An inventory that only covers officially approved systems will miss the places where risk actually lives.

For each entry, record the system’s intended purpose. A model used to summarize documents is not the same as a model used to decide whether someone gets a loan, even if both use similar language-model technology. Intended purpose drives risk classification, documentation depth, and the evidence an auditor will expect.

Classify by role and risk

The Act distinguishes between providers, deployers, importers, and distributors, and it treats general-purpose AI models separately from high-risk systems. A company may be a deployer for one tool and a provider for another. The same model can be used in a low-risk workflow and a high-risk one.

Document the classification rationale, not just the label. Explain which annex or article was considered, what the system does, who it affects, and why the chosen category applies. Record any assumptions and the date they were reviewed. If the use case changes—new data, new audience, new decision authority—revisit the classification.

For high-risk systems, the evidence burden is broader: risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness, and cybersecurity. The point is not to produce a paperwork pile. It is to show that the system was designed and operated with those controls in mind.

Data and model provenance

Regulators and customers increasingly ask where training and input data came from, whether it was lawfully obtained, and how bias and quality were assessed. Teams should maintain data lineage for the relevant datasets, document labeling and cleaning decisions, and record known limitations.

For third-party models, collect the provider’s model documentation, usage restrictions, evaluation results, and change history. Ask how model updates are communicated and whether the provider offers version pinning. A silent model upgrade can invalidate an evaluation that was used to approve a workflow.

Do not confuse a vendor’s compliance statement with your own obligations. If you deploy a high-risk system, you still need to understand its intended purpose, monitor it in your context, and provide the required human oversight.

Human oversight must be designed, not declared

“A human reviews the output” is not enough. Specify who reviews what, with which information, at what point, and with what authority to stop or override the system. Record the training those reviewers receive and the escalation path when they disagree with the model.

For higher-risk decisions, avoid automation bias. A reviewer who sees a confident recommendation may approve it without independent evidence. Good oversight interfaces show uncertainty, source material, alternative options, and the consequences of a wrong decision. They also capture the reviewer’s rationale.

Logs, monitoring, and incidents

Keep logs long enough to investigate incidents and demonstrate ongoing conformity, while respecting privacy and data-minimization rules. Log model version, input category, output, decision, reviewer action, and timestamps. Avoid storing unnecessary personal data.

Define what counts as a serious incident and who reports it internally. Run post-market monitoring rather than waiting for a complaint. Track drift, error rates, override rates, and disparate outcomes across groups. A dashboard that nobody reviews is not monitoring.

A practical 90-day plan

Start with a workshop that maps every AI use case to an owner and a risk category. Then choose the highest-risk workflow and build an evidence pack for it: intended purpose, data sources, model documentation, evaluation results, oversight procedure, logging, and incident response.

Review vendor contracts for audit rights, change notification, data processing, and security commitments. Fill the gaps you can fill now; flag the ones that require legal or procurement work. Assign a named owner for each system and schedule a review before the next major model or product change.

Finally, train the teams closest to the system. Engineers need to know how to preserve evidence and escalate failures. Product managers need to recognize scope changes that trigger a reassessment. Support teams need a clear path for user questions and complaints.

Beyond the EU

The EU AI Act is not the only framework that matters. Indonesia’s personal data protection law, sector-specific rules, and customer contracts may impose separate obligations. Global teams should look for a common evidence base—inventory, classification, data lineage, testing, oversight, and incident records—that can be adapted to multiple regimes rather than building a separate compliance program for every jurisdiction.

This article is general information, not legal advice. The scope and timing of obligations depend on the specific system and role, and official guidance continues to evolve. The safe engineering habit is to document decisions as they are made, not reconstruct them after a regulator asks.

The organizations that handle this well will treat AI governance as part of product quality. The evidence they produce will help them ship faster, because they will know which systems are ready, which need controls, and which should not be deployed at all.