The European Commission identifies 2 August 2026 as a major application milestone for the EU AI Act, with exceptions and later dates for some provisions and systems.
The exact obligations depend on role, system, sector, and current law. This article is an operational readiness guide, not legal advice. The practical point is simpler: evidence assembled only when a regulator, auditor, or customer asks for it will be incomplete and expensive.
Build the evidence path while the AI system is operating.
Start with scope and role
Identify the AI systems in use, the legal entities and regions involved, and the organization's role for each system. A company may be a provider in one workflow and a deployer in another.
Record the business purpose, affected people, owner, vendor dependencies, data sources, decision impact, and current risk assessment. Include internal agents, vendor features, embedded models, and systems purchased by individual departments.
Where classification or applicability is uncertain, record the question, responsible counsel or owner, decision date, and evidence used. An explicit unresolved issue is safer than an undocumented assumption.
Organize evidence around the lifecycle
A useful pack connects five layers:
1. Inventory and accountability
System description, intended purpose, owner, technical operator, affected teams, vendor chain, version, and current status.
2. Risk and control decisions
Risk tier, impact assessment, applicable policies, exceptions, approvals, data boundaries, access model, and reasons for deploying or limiting the system.
3. Technical and operational evidence
Evaluation results, change history, run records, monitoring, incidents, corrective actions, security tests, provider and model changes, and decommissioning controls.
4. Human oversight
Where review occurs, who is qualified and authorized to perform it, what evidence they receive, how they can interrupt or reverse the system, and how their decisions are recorded.
5. Transparency and communication
User notices, internal instructions, limitations, escalation routes, training, and records of material changes communicated to affected teams.
Make evidence traceable
A folder of policies is not enough. Link each control to the systems it covers and each consequential run to the policy, approval, and version active at that moment.
Use stable identifiers for systems, versions, runs, controls, evidence items, incidents, and reviewers. Keep timestamps and provenance. Preserve superseded records rather than overwriting history.
This lets a reviewer move in both directions: from a requirement to evidence, and from a specific agent action back to the control that allowed it.
Assign an owner and refresh trigger
Every evidence domain needs a responsible owner and update rule. Revisit the pack when the purpose, model, provider, tool access, data source, risk tier, operating region, or approval design changes.
Schedule a periodic completeness review, but do not rely on the calendar alone. Material system changes are when evidence drifts fastest.
Test the pack with a real run
Select one consequential agent action and conduct a tabletop review. Ask legal, risk, security, engineering, and the business owner to reconstruct what happened and why it was allowed.
List every missing field, unclear owner, inaccessible log, and unsupported claim. That gap list is the real readiness plan.
The deadline matters. The stronger outcome is an operating system that can produce defensible evidence on any ordinary day, not just during an audit.