EU AI Act Readiness Assessment Tools: What They Measure and What They Miss

What a readiness assessment can confirm

A readiness assessment evaluates an organization's posture against the EU AI Act. It asks whether AI systems have been inventoried, whether their risk classification has been reasoned and recorded, whether owners exist, and whether the documents the Act expects are in place. These are legitimate and necessary questions, and several obligations are directly satisfied by producing and keeping the right artefacts.

A provider that concludes an AI system is not high-risk should document that assessment before the system is placed on the market or put into service, and provide it to national competent authorities on request. Providers must subject high-risk systems to a conformity assessment before placing them on the EU market or putting them into service. Certain deployers must perform a fundamental rights impact assessment before deployment. A documentation-oriented tool can track each of these deliverables.

The limit is the nature of the evidence. A questionnaire or checklist can show that a process is documented. It cannot show that the process operates. Many of the Act's high-risk requirements are written as lifecycle or in-use properties, and that is where an assessment stops being sufficient.

Four types of readiness assessment tool and where each stops

Tools in this category generally fall into four types. The grouping below is an analytical framing for evaluation, not a statement about any specific product. Many tools combine more than one type.

• Self-assessment questionnaires: Measure: stated practices, policies and ownership, as reported by the respondent. Stops: answers are self-reported and show that a process is documented, not that it runs in production.
• Risk classification workflows: Measure: whether a system appears to fall within high-risk scope, based on a description of it. Stops: classification depends on the function and the specific purpose and modalities of use, so the output is only as accurate as the input description. The Commission's Compliance Checker serves this applicability question.
• Gap analyses: Measure: differences between current documented controls and the Act's requirements, usually as a remediation list. Stops: gaps are found in documents and processes, and the result is a snapshot that ages as systems change.
• Documentation checklists: Measure: whether artefacts exist, such as technical documentation, classification rationale, impact assessments and conformity assessment records. Stops: confirm presence, not that content matches the live system.

Which obligations need runtime enforcement and evidence

The Act's high-risk requirements cover risk management, data set quality and relevance, technical documentation and record-keeping, transparency and information to deployers, human oversight, and robustness, accuracy and cybersecurity. The wording of several of these points past documentation.

The risk management system must be established, implemented, documented and maintained, and is described as a continuous, iterative process across the lifecycle of the system. Human oversight is a design requirement: systems must be built, including with appropriate human-machine interface tools, so that people can effectively oversee them during the period in which they are in use. Testing must show that systems perform consistently for their intended purpose.

The practical distinction is between artefacts and behaviors. Artefacts can be confirmed by assessment. Behaviors need observation while systems run, and the observation has to be retained to be useful later.

• Classification rationale, impact assessments, conformity records: An assessment can confirm that the artefact exists and is dated. Content accuracy still needs review against the live system.
• Risk management: An assessment can confirm a documented system. It cannot confirm the process is continuous. That needs ongoing monitoring linked to the documentation.
• Human oversight: An assessment can confirm a policy. Evidence depends on whether interfaces and workflows let a person intervene, and on records of when they did.
• Record-keeping: An assessment can confirm that a requirement is acknowledged. Whether records are produced for the system in operation is visible only when it runs.
• Testing and performance: An assessment can confirm a test plan exists. Consistent performance is shown by test results and operating observations.

Regulatory timing and dated outputs

Reporting from a readiness tool should state which dates are in force and which are proposed. On 19 November 2025 the Commission proposed the Digital Omnibus on AI, citing delays in establishing standards for high-risk rules and in designating national competent authorities and conformity assessment bodies. As described, it would set 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk systems embedded in products. As of November 2026, plan against those dates conditionally and confirm them against official publications.

The delay question does not remove the underlying design problem. Whatever the date, a high-risk system will need risk management, oversight and record-keeping that operate in use. Teams that build enforcement and evidence capture now can reuse them across timeline changes. Classification outputs should also be dated and re-checked, because applicability depends on how a system is described and used.

Closing the gap between documented and enforced

Closing the gap requires a control that acts on AI behavior while it happens and leaves a record. Trussed is one way to do this. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions to allow, redact, block, rate limit or escalate for human approval. Enforcement is scoped to individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact.

That enforcement generates continuous, audit-ready evidence, mapped to the EU AI Act and to NIST, among other frameworks. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency. It has run continuously in a regulated enterprise for more than 18 months, with 99.95% uptime on live production traffic.

It does not replace an assessment. The assessment identifies the obligations, owners and classifications. Runtime enforcement and evidence show what the system was allowed to do and what it did.