EU AI Act Readiness Assessment

An organization cannot assess EU AI Act readiness from a policy library alone. It needs a dependable view of the AI systems and use cases connected to its operations. That population may include internally developed applications, third-party services, models accessed through APIs, AI features embedded in ordinary software, decision-support tools, customer-facing functions, and general-purpose assistants used by employees. Each route into the organization can create different facts and responsibilities.

Discovery should therefore reach beyond projects formally labelled as AI. Procurement records may show suppliers but not optional features. Application inventories may omit employee tools. Product documentation may describe capabilities without showing how teams use them. A readiness assessment tests whether discovery methods cover business-led adoption, embedded vendor AI, experiments that became routine, and systems operated on the organization's behalf by third parties.

The inventory should connect every relevant entry to an intended purpose, business process, users, owner, provider, deployment context, data categories, outputs, affected people, geographic reach, and review status. These fields do not determine legal classification by themselves. They create the factual foundation needed to discuss scope, role, risk, transparency, oversight, and evidence without relying on broad assumptions about a product or vendor.

Organizations often ask whether they are a provider or a deployer as though one label applies to the whole enterprise. In practice, the answer can differ by system and activity. An organization may deploy a third-party tool for an internal process, provide an AI-enabled product under its own name, substantially modify a system, import a product into the Union, or distribute it through a commercial channel. The operational facts matter more than the organization's preferred description.

A readiness assessment should map the relevant actors for each system: who develops it, who places it on the market or puts it into service, whose name or trademark is used, who deploys it under their authority, who imports or distributes it, and which suppliers support the chain. Contracts and product documentation should be compared with actual configuration and use. A supplier's assurance does not automatically resolve the organization's own responsibilities.

Role analysis should be recorded with its supporting facts, owner, date, and unresolved questions. Changes in branding, integration, intended purpose, model selection, fine-tuning, or system use may alter the analysis. The assessment does not replace legal interpretation; it organizes the evidence counsel and accountable leaders need to make a reasoned determination and revisit it when the system or relationship changes.

Readiness requires a consistent process for screening systems against the Act's risk structure and other relevant categories. The first task is to understand what the system is intended to do, who is affected, and how its output influences a decision or process. Marketing terms such as assistant, recommendation engine, or automation are not enough. Teams need a plain account of functionality, context, users, consequences, and safeguards.

The assessment should identify uses that may require closer analysis because they interact with regulated domains, important decisions, safety functions, employment, education, essential services, law enforcement, migration, justice, biometric processing, or other sensitive contexts. It should also identify practices that warrant immediate legal attention and systems for which transparency duties or general-purpose AI dependencies may be relevant. This is a triage process, not a substitute for final legal classification.

Classification evidence should be traceable to source material: system descriptions, intended-purpose statements, process maps, user instructions, contracts, technical documentation, impact assessments, and interviews with people who operate the system. Where facts are missing, the record should say so. A readiness baseline is stronger when it exposes an unresolved classification question than when it creates false certainty from an incomplete questionnaire.

The EU AI Act creates system-specific questions, but readiness also depends on the enterprise operating model around those systems. Someone must own discovery, role analysis, classification, supplier evidence, deployment decisions, human oversight, monitoring, incident escalation, and record retention. If responsibilities are spread across legal, technology, security, privacy, procurement, risk, and business teams without clear decision rights, important evidence will remain fragmented.

The assessment should test how a system enters governance and what events trigger review. New procurement, an AI feature activation, a material configuration change, a revised intended purpose, a new data category, expansion to another user group, or a supplier model change may all require attention. Review criteria should be understandable to business teams and integrated into workflows they already use rather than dependent on informal knowledge of a specialist committee.

Escalation and exception processes are equally important. Teams need a route for uncertain classifications, incomplete supplier information, urgent deployments, and uses that fall outside approved patterns. Exceptions should identify the decision owner, rationale, duration, compensating measures, and evidence required before closure. Without that discipline, readiness work becomes a one-time documentation exercise while operational decisions continue through separate channels.

AI literacy is not satisfied by a generic awareness message sent to every employee. Organizations need measures suited to the knowledge, experience, role, and context of the people who develop, deploy, operate, oversee, procure, or are otherwise involved with AI systems. A readiness assessment should identify which groups need which capabilities and how the organization demonstrates that the measures are current, relevant, and connected to actual use.

Useful literacy evidence may include role-based learning objectives, training materials, attendance or completion records, practical guidance, assessments, communications about approved use, and updates following system or regulatory change. The assessment should also look beyond course completion. Managers and operators should understand system limitations, appropriate reliance, data restrictions, escalation paths, and the consequences of using outputs outside the intended context.

Human oversight needs the same operational treatment. Naming a reviewer is not enough if that person lacks time, authority, information, or a meaningful ability to intervene. The assessment should examine what the reviewer sees, which signals trigger challenge, how overrides are handled, whether automation bias is addressed, and what evidence shows that oversight occurred. Oversight should be designed around the decision process rather than added as a label after deployment.

Readiness evidence is usually distributed across contracts, technical files, risk records, privacy assessments, security reviews, approval tools, training platforms, monitoring systems, and business procedures. The challenge is not merely to collect documents. It is to connect each record to the correct system, version, role, purpose, owner, decision, and review date so the organization can explain why it reached a conclusion and whether that conclusion remains current.

A practical evidence register can identify the expected artifacts for each system and show whether they are available, complete, approved, and current. Depending on the facts and role, relevant evidence may include system descriptions, instructions for use, role assessments, classifications, risk and impact records, data information, oversight procedures, logging arrangements, monitoring results, incident records, supplier documentation, literacy measures, and decisions about corrective action.

The assessment should test retrieval as well as existence. If a client, auditor, regulator, or board committee asks about a specific system, can the accountable owner assemble a coherent record without weeks of reconstruction? Conflicting versions, expired reviews, missing links to decisions, and supplier documents stored outside governance workflows are readiness gaps even when individual files exist somewhere in the organization.

Many organizations will depend on providers for technical information, instructions, model documentation, logging capabilities, change notices, and contractual commitments. Readiness therefore depends on what the supplier provides and what the organization can verify about its own deployment. A standard procurement approval completed before an AI feature existed may not address the system now in use. The assessment should identify where supplier evidence is missing or too general for the intended context.

Contracts and operating processes should address material changes, access to relevant information, support for incident response, data handling, model or feature updates, subcontracting, monitoring, and termination. The organization should also understand where it configures, combines, fine-tunes, or repurposes a supplier capability. Those activities can affect risk, evidence needs, and potentially the role analysis. Legal, procurement, technical, and business views need to describe the same relationship.

General-purpose AI can create layered dependencies between model providers, system providers, integrators, and deployers. A readiness assessment should map that chain rather than treating the user-facing application as the only relevant component. The aim is to identify which evidence can be obtained upstream, which controls remain the organization's responsibility, and where contractual or technical limitations prevent a confident readiness position.

The output of an assessment should distinguish urgent system-level questions from enterprise capability improvements. Urgent work may include investigating a potentially prohibited use, resolving a role or classification question, documenting a high-impact deployment, clarifying human oversight, or obtaining missing supplier evidence. Capability work may include completing the inventory, defining review triggers, improving literacy, establishing an evidence register, or integrating AI checks into procurement and change management.

Each action should have an accountable owner, target outcome, due date, dependencies, and evidence of completion. Prioritization should reflect potential consequence, legal uncertainty, system scale, affected people, data sensitivity, supplier dependency, and the weakness of current controls. A long checklist ordered by document type is less useful than a roadmap that tells leadership which decisions cannot safely wait and what information is needed to resolve them.

Readiness should be reviewed as systems and obligations evolve. The assessment establishes a baseline and a repeatable way to update it; it does not freeze the organization in a permanent status. Final compliance conclusions may require qualified legal advice and system-specific analysis. The practical objective is to make the organization capable of identifying change, assigning responsibility, producing evidence, and taking timely corrective action.