AI_ACT_READINESS_MAP

The next AI Act date product teams should feel is 2 August 2026, when transparency obligations apply. As of the 16 June review, that is 47 days away. Organizations that cannot produce a credible inventory of where AI appears in their products, what role they play in the regulatory chain, and which use cases might qualify as high risk are already behind on the work they need to do.

THE_INVENTORY_PROBLEM

Most product organizations do not have a reliable list of where AI appears in their systems. They have teams that know about the features they built, procurement records that mention "AI" in varying degrees of specificity, and a general awareness that machine learning runs somewhere in the stack. That is not a sufficient compliance posture under the Act.

The inventory problem is also a role problem. The Act distinguishes between providers (who place an AI system on the market), deployers (who put it into use), importers, and distributors. Most product teams are deployers — they integrate models built by others — but many have not yet asked their suppliers the questions that determine whether those systems were built to Act requirements.

"You cannot prepare for the AI Act if the organisation cannot first find its own AI."

THE_HIGH_RISK_CATEGORY_QUESTION

Annex III of the Act lists the use cases that qualify as high risk, including AI systems used in: education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, administration of justice, and certain safety-critical components. The definition catches more products than teams typically assume at first read — particularly in HR tooling, customer service automation, and financial decision-making products.

High-risk systems carry the heaviest obligations: conformity assessments, technical documentation, human oversight mechanisms, logging capabilities, and registration in the EU database before deployment. The Commission's current timeline now separates those high-risk obligations from the August 2026 transparency date: certain high-risk areas move to 2 December 2027, while systems integrated into regulated products move to 2 August 2028. The practical lesson is not to wait. Classification evidence, supplier documentation, and intended-purpose records are the long-lead work.

WHAT_TO_DO_BEFORE_AUGUST

The GPAI Code of Practice is now a published voluntary compliance tool for providers, the Commission has published guidance for GPAI model providers, and the AI Office has moved forward with transparency support for AI-generated content. That is useful context, but it does not change the three things product teams should be doing in parallel right now:

• Complete the AI use-case inventory: list every AI-enabled feature, internal tool, and third-party dependency with the model source, intended use, user population, and a failure-impact assessment.
• Classify by role for each use case — provider, deployer, importer, or distributor. The answer determines which obligations attach and which pass through to your upstream supplier.
• Review supplier contracts for AI Act compliance commitments. If a model provider cannot demonstrate compliance for GPAI, disclosure, or high-risk support obligations, that needs to change before the next release gate, not at the next routine renewal.

Forty-seven days sounds like enough time only if the inventory already exists. In practice, the inventory alone takes longer than expected, because AI appears in features and tools that are not labeled as AI anywhere in the internal product taxonomy.

READING_ANNEX_III_CAREFULLY

The high-risk classification under Annex III is where most product teams underestimate their exposure. The list is narrower than a broad reading of "AI in important domains" — it is specific about the type of decision the AI system is involved in, not just the sector. Employment and worker management catches automated screening, performance monitoring, and task allocation tools. Access to essential services catches credit scoring, insurance underwriting, and public benefit eligibility. Education covers automated assessment and personalized learning systems.

The nuance that matters operationally is that the classification depends on the use of the system in context, not just the system's technical capability. The same model used for internal knowledge search is not high risk. The same model used to filter job applications against a candidate database probably is. Whether a specific deployment qualifies requires mapping the use case against the Annex III categories with some precision — not a quick read of the category headings.

The Commission has sought feedback on draft guidelines for high-risk classification, with consultation open until 23 June 2026. That makes classification work live, not settled. Getting a borderline classification wrong in either direction creates regulatory risk: missing a high-risk classification means skipping the conformity work, while incorrectly self-classifying a system as high risk generates compliance overhead without regulatory benefit.

• Map each AI use case against the specific Annex III categories, not just the sector headings — the categories are narrower than the headings suggest.
• Document the classification rationale, not just the conclusion. If an authority questions the classification, you need to show the reasoning, not just assert the outcome.
• For borderline cases, consult the Commission's draft high-risk classification guidance and, where relevant, sector-specific supervisory guidance from the relevant national authority.
• Re-run the classification exercise when a system's intended purpose or user population changes — a deployment shift can move a system across the high-risk boundary.

SUPPLIER_QUESTIONS_THAT_CHANGE_YOUR_OBLIGATIONS

Most product teams deploying third-party AI models are in the deployer role, not the provider role. That distinction matters: deployer obligations are real but narrower than provider obligations, and some provider obligations pass through contractually. What you need to know from each AI supplier is: whether the model they supply was developed and placed on the market in conformity with the Act, whether they can provide the technical documentation required for high-risk system oversight, and what their obligations are with respect to post-market monitoring and serious incident reporting.

Many suppliers cannot answer these questions clearly yet. That is useful information. It means the contractual language in your supplier agreements needs to be updated before the next release gate, not at the next routine contract renewal. The sooner that conversation starts, the more options you have. Suppliers that cannot provide reasonable compliance commitments before the relevant application date represent a real procurement risk that needs to be escalated to procurement and legal, not managed entirely within the product team.

PRIMARY_REFERENCES

• Regulation (EU) 2024/1689, the AI Act
• European Commission: AI Act overview
• European Commission: GPAI obligations under the AI Act
• European Commission: AI Act standardisation
• European Commission: GPAI Code of Practice
• European Commission: draft guidelines for high-risk AI classification
• European Commission: Code of Practice on marking and labelling AI-generated content
• EUR-Lex summary of the AI Act