The work includes currently applicable prohibitions, literacy, GPAI and Article 50 duties within their scope, alongside preparation for principal high-risk Chapter III requirements on 2 December 2027 for Annex III and 2 August 2028 for Annex I. Article 6(5), route scope and transitions need separate treatment.
Why policy documents are only one part of readiness
Requirements reach the behavior and design of systems. Article 50 addresses interaction notices, synthetic-output marking and publication disclosure. High-risk requirements address risk processes, data, technical records, logging and oversight. A policy can describe the intention; implementation needs the relevant procedure, configuration, system capability or workflow.
The practical problem is coordination. Legal teams determine scope; engineering teams control technical behavior; business teams decide use; procurement manages supplier dependencies; operators create evidence of real operation. If those decisions remain disconnected, a central policy can look complete while the actual system record remains incomplete.
Consequential scope, classification, exception and transition decisions require qualified review against the actual facts.
1. Inventory systems and distinguish models
Begin with AI systems in use, in development or supplied to others. Identify each system's intended purpose, actual use cases, business owner, operating entity, version and deployment locations. Record the models and important data dependencies separately. The system definition is functional; vendor branding alone is insufficient.
This is our recommended inventory structure, not a prescribed statutory register for all AI. One system may use multiple model versions, and a shared model may serve several systems. A procurement list of AI vendors will not necessarily describe the applications the enterprise has built around their technology. Keep system and model records distinct, and update their relationships when purpose, use, entity, role or version changes.
Useful starting records include system name and version, purpose, use, developer/provider, operating legal entity, model dependencies, audience and deployment context. Add uncertainty instead of substituting assumptions for missing facts. Avoid beginning with an elaborate platform before agreeing what a system record means.
2. Determine role and jurisdiction
For each context, examine development or commissioned development, naming, supply, use authority and modification. Provider, deployer, importer and distributor have different statutory tests. An organization can have different roles for different assets or activities.
Then examine the Article 2 connections. Provider activity in the EU market, an EU deployer's location and third-country system output used in the EU are separate tests. Record the legal entity and evidence for each one. A group headquarters field cannot answer the entire scope question.
Use the roles page and non-EU scope page as prerequisites. For each decision, record the system, legal entity, role, territorial connection, supporting facts, source version and unresolved questions. Do not assign one permanent role or jurisdiction label to the corporate profile. This is our recommended record design.
3. Screen prohibitions and active transparency duties
Screen the purpose and workflow against Article 5's specific conditions. A label such as "emotion recognition" or "social scoring" needs the actual statutory test. New sexual-content points have a separate 2 December 2026 application date and conditions; they should not be merged with the original prohibition chronology.
Assess Article 50 by paragraph and role. Direct-interaction disclosure, provider marking, deepfake disclosure and qualifying public-interest-text disclosure are different duties. Timing and accessibility matter. A visible notice does not prove machine-readable marking, and an editorial exception does not waive provider marking.
The Article 50 page explains each duty. The general date is 2 August 2026. Any reliance on the paragraph 2 transition for an older system must identify the system and its history.
4. Establish evidence for currently applicable obligations
Review literacy measures for relevant staff and people operating or using AI on the organization's behalf. Amended Article 4 requires measures rather than a guaranteed individual attainment level. Commission Q&A allows internal training/guidance records and says a certificate is not needed.
For transparency, examine released interfaces, generation/export pipelines and publication workflows. Collect evidence of the actual version and activity examined. A design document can explain the intended implementation; a released artifact or test addresses a different question. Our evidence approach is to state what each artifact can and cannot demonstrate.
Where the organization is a GPAI provider, examine model-level documentation, downstream information, copyright policy and training-summary obligations, along with applicable exceptions and transitions. Do not impose these model-provider duties on every business user of a third-party application.
5. Classify potential high-risk systems
Examine Annex I's cumulative product/safety-component and third-party-assessment conditions. Then examine Annex III's listed uses, Article 6(3) conditions and profiling rule where relevant. Sector membership alone is insufficient, and human review alone is not an automatic derogation.
Document the factual reasoning for a derogation and retain the relevant registration requirement. Map intended purpose and actual workflow, including influence on decisions and affected people. Use the high-risk page for the screening logic, while leaving final borderline classifications to qualified review.
6. Identify implementation gaps and owners
The following capabilities translate the researched requirements into work. Their names and program structure are our recommendations. Applicability and dates remain specific to each obligation.
| Capability | Applicability | Requirement connection | Implementation question |
|---|---|---|---|
| Risk management | Future high-risk preparation; provider design and applicable deployer operations | Article 9 lifecycle process. | Who maintains risks, mitigations, tests and acceptance decisions? |
| Data governance | Future high-risk preparation; provider design and applicable deployer operations | Article 10 data/testing governance. | Can the team explain provenance, suitability, gaps and preparation? |
| Logging and traceability | Future high-risk preparation; provider design and applicable deployer operations | Article 12 design and Articles 19/26 controlled logs. | Are the relevant events captured and retrievable for the correct scope? |
| Human oversight | Future high-risk preparation; provider design and applicable deployer operations | Provider design and deployer assignment. | Can authorised operators understand, intervene and escalate? |
| Technical documentation | Future high-risk preparation; provider design and applicable deployer operations | Article 11 and Annex IV. | Is documentation tied to the released system and kept current? |
| Transparency controls | Currently applicable provider/deployer duties under the relevant paragraphs, with paragraph 2 transition | Relevant Article 50 paragraphs. | Does the actual interaction, output or publication deliver the required information? |
| Performance and security validation | Future high-risk preparation; provider design and applicable deployer operations | Article 15. | Do tests match intended use, risks and relevant attacks? |
| Monitoring and incident handling | Chapter IX temporal coverage requires legal review | Articles 72/73, with temporal coverage unresolved. | Are awareness, escalation, investigation and reporting responsibilities defined, subject to legal applicability review? |
| Literacy | Currently applicable provider/deployer measures | Amended Article 4. | Do measures address the people and work involved? |
Map owners to concrete implementations. "The AI committee" may approve a policy but not operate a marking pipeline. Shared controls can support several requirements, yet each mapping needs a rationale and coverage limits. Do not turn reuse into an assumption that one control fully satisfies every related obligation.
7. Prepare for future high-risk requirements and standards
The principal dates are 2 December 2027 for Annex III and 2 August 2028 for Annex I Chapter III Sections 1 through 3, subject to exceptions and transitions. Record system placement/first-use history and relevant changes. Do not maintain one compliance date for the entire AI inventory.
Plan supplier information and technical work early. Provider instructions, logging, intervention interfaces and current technical documentation can require coordinated delivery. Separate provider responsibilities from deployer operating arrangements.
Track harmonised-standard publication, OJ citation, scope and restrictions separately. Article 40 presumption is tied to a published OJ reference and covered requirements. Published-standard status or a management-system certificate alone does not establish it.
8. Monitor changes and preserve the decision history
Maintain dependencies between the source version, claim, applicability decision, control and evidence. When a provision, guidance document, use, supplier or system version changes, identify which decisions need review. This is our recommended change-management approach.
We propose linking each AI system, use case, model, dataset, legal role, jurisdiction, obligation, control, owner and item of evidence. Those links can show which decisions need review after a change. The Act does not mandate an ontology, graph database or semantic software. Clear records and consistent references are enough to start; formal schema work is deferred.
Evidence management without invented retention rules
Evidence should carry subject, version, time, source, integrity and access information. A model evaluation report and a system disclosure screenshot address different subjects. Evidence reuse needs explicit scope, not a rule that every artifact proves everything associated with a vendor.
Retention requirements also differ. Article 18 has ten-year provider record retention within its scope; controlled high-risk logs under Articles 19 and 26(6) normally have at least six months unless other law provides otherwise. These are not universal retention periods for every AI artifact. Applicability and the amended timetable still matter.
Open issues and FAQ
Can a readiness review establish legal compliance?
An operational review can identify implementations, evidence and gaps. Its findings must state their scope and limits. Legal determinations require qualified review; this approach provides no score, certification or guaranteed result.
Do we need to wait for final guidance?
Statutory duties remain the starting point. The baseline records unresolved Article 50 formal adoption and draft high-risk classification guidance. Those uncertainties require targeted review, not a blanket conclusion that the law is optional.
Is incident reporting universally active for future high-risk systems?
The research does not settle that conclusion. Chapter IX's formal date and its interaction with postponed classification and transitions remain separately recorded.
What should we do first if the inventory is incomplete?
Start with known systems and consequential uses, record missing facts and assign owners to resolve them. Review active prohibitions, transparency and literacy in parallel. This is our prioritization recommendation, not a legal safe harbor.
Next step
Review the implementation timeline and Article 50 requirements with the relevant system owners.
Primary sources
Use the consolidated text to navigate provisions and the authentic original and amending Official Journal acts for the legislation. Guidance and Q&A retain their separate legal status.
- Consolidated text: Regulation (EU) 2024/1689, 27 July 2026 · legislation.
- Regulation (EU) 2024/1689 of 13 June 2024 · legislation.
- Regulation (EU) 2026/1744 of 8 July 2026 · legislation.
- Guidelines on transparency obligations for providers and deployers of AI systems · official information, nonbinding.
- Approval of the content of the draft Communication : Guidelines under Article 50 · draft guidance.
- Guidelines on transparency obligations for providers and deployers of certain AI systems · official information, nonbinding.
- AI literacy: Questions & Answers · official information, nonbinding.
- Targeted consultation on draft high-risk classification guidelines · official information, nonbinding.
- Understanding standardisation in the AI Act · official information, nonbinding.