AI Act Readiness Blueprint for 2025-2026

AI Act readiness is not the production of a single AI policy. Duties depend on the system, its intended purpose, the organization's role in the value chain, and the way it is used in the EU market. The same underlying model may be a component of a low-risk tool, part of a high-risk system, or a general-purpose AI model subject to a distinct regime. A workable program therefore starts with inventory and classification rather than a universal checklist.

The timeline also needs a current reading. The AI Act entered into force on August 1, 2024. Prohibitions and AI literacy duties have applied since February 2, 2025; governance and GPAI provisions since August 2, 2025. General application, enforcement, and specified transparency requirements began on August 2, 2026. Amended dates for parts of the high-risk regime fall later, but controls already in application cannot wait for them.

Inventory systems and determine the organization's role

The register should include internally developed systems, purchased products, AI features inside SaaS, models offered to customers, and components embedded in larger services. Record intended purpose, users, business process, data, model and supplier, countries of use, product owner, and people affected by the output.

Then determine whether the organization acts as provider, deployer, importer, distributor, or GPAI model provider. A role can change when a company substantially modifies a system, places its own name on it, or changes its intended purpose. The classification record should preserve rationale, system version, author, approval, and review date. “We call a vendor API” is not sufficient reasoning for having no obligations.

Connect duplicate uses of the same component. One foundation model may support several products with different purposes and risk classifications; component-level inventory should not erase use-case-level accountability.

Remove prohibited practices and make AI literacy role-specific

Article 5 should be the first filter for any proposed use. Prohibited behavior needs to be excluded from requirements, data practices, product mechanisms, and procurement before implementation. An uncertain case calls for documented legal analysis and an accountable decision before testing with real people—not a post-launch note.

AI literacy is not one generic course. A buyer selecting a tool, an operator acting on output, an engineer monitoring a model, and a support team handling complaints require different knowledge. Training should cover system limitations, proper use, likely errors, escalation, and data handling for the role. Evidence includes scope, audience, material, a check of understanding, and refresh when the system or role changes.

Product design should reinforce literacy. Operators need visible limitations and escalation routes at the point of use, not only a certificate showing they attended training.

Separate transparency duties from high-risk classification

A system subject to transparency obligations is not automatically high-risk. From August 2, 2026, specified systems must disclose AI interaction and generated or manipulated content must carry the required transparency mechanisms. The Commission's July 31, 2026 announcement confirms the start of enforcement and the new transparency rules on August 2.

Product assurance should verify that a notice is perceptible in the real interface, appears at the appropriate point in the interaction, and survives a channel change. Content workflows need provenance, a marking mechanism, and tests after export, transformation, or platform distribution. A clause in terms of service may not match the way a person actually experiences the system.

Document exceptions and rationale. Transparency controls should be versioned alongside the product so a redesign cannot remove them without review.

Manage GPAI and downstream supplier dependencies

An organization integrating a general-purpose model needs enough supplier information to design its own controls. It should understand limitations, permitted uses, incident channels, version changes, data policy, and documentation available to downstream providers. An organization that provides a GPAI model must assess Article 53 duties and, where relevant, the additional obligations for models with systemic risk.

The General-Purpose AI Code of Practice, published on July 10, 2025, is a voluntary compliance tool covering transparency, copyright, and safety and security. Signing or relying on the Code does not replace product-scope analysis. Procurement terms should secure information rights, change notices, relevant logs, and test evidence rather than relying on a model's marketing category.

Maintain a contingency for supplier change. A new model version can alter performance, safeguards, documentation, and the organization's risk classification even when the API remains stable.

Prepare systems that may be high-risk

Classification requires reviewing Article 6 and Annexes I and III, including intended uses in biometrics, critical infrastructure, education, employment, essential services, law enforcement, and migration. Do not assume every AI use in a regulated industry is high-risk, or that a low-risk classification remains valid after intended purpose changes.

Regulation (EU) 2026/1744 moved application of Chapter III, Sections 1–3 to December 2, 2027 for Article 6(2) and Annex III systems, and to August 2, 2028 for Article 6(1) and Annex I systems. Use that period to implement risk management, data governance, technical documentation, logging, human oversight, post-market monitoring, and conformity-assessment readiness. It is not a reason to leave technical dependencies untested until the final quarter.

Maintain the evidence now because design decisions are expensive to reconstruct. Data lineage, logging coverage, operator authority, and rollback capability should be architecture inputs.

Put controls inside the product lifecycle

Classification and the appropriate evidence pack should be entry and release conditions. A change to model, data, interface, user population, automated process, or supplier may alter the assessment. The release workflow should preserve version, tests, accepted limitations, owner, and monitoring plan.

A strong benchmark result is not sufficient. Test under conditions resembling deployment, include cases affecting different groups, verify human oversight, allow outcomes to be challenged, and monitor for misuse or degraded performance. The incident runbook should cover harmful output, leakage, drift, bypass of oversight, and supplier failure, with authority to pause or withdraw the system.

Keep legal interpretation connected to technical configuration. If a safeguard exists only in documentation and cannot be observed in the running product, it will be difficult to demonstrate.

Measure readiness through complete decisions and evidence

Useful measures include the share of systems with named owners and intended purposes, time from material change to reclassification, role-based AI literacy coverage, releases with complete evidence packs, age of control findings, AI incident response time, and supplier dependencies without contractual access to required information. Every gap should lead to remediation, accountable risk acceptance, or restricted use.

An AI committee should not approve every minor change. It should define thresholds, decide high-impact cases, and govern exceptions. Product teams execute repeatable controls in ordinary delivery. This creates a traceable chain from classification through release to monitoring and response—the evidence an authority or customer will need, rather than another standalone policy.