EU AI Act readiness assessment: what it involves

How do you run an EU AI Act readiness assessment?

A readiness assessment compares your AI systems, your roles under the AI Act and the evidence you hold against the Act's obligations and dates. The organization owns the result. An assessment starts when a customer, contract or regulator asks whether you comply, and the plan depends on two questions: which systems fall in scope, and which dates apply to each of them. The Act's phases are already in force in part. Chapters I and II (definitions, AI literacy and prohibitions) have applied since 2 February 2025, and the general-purpose AI, governance, notified body and penalty chapters have applied since 2 August 2025. The high-risk rules in Chapter III Sections 1 to 3 now apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, as amended in 2026. Confirm the date for each system against its Annex, because the two groups do not share one deadline.

Start by listing every system that might be an AI system, then record the role you hold for each (provider, deployer or another operator) and the risk tier you believe applies. Check the prohibited practices first, since those apply already. For each system you consider high-risk, compare the evidence you hold with the Chapter III requirements on risk management, data governance, technical documentation, record-keeping, human oversight and quality management. Note which items exist as current records, which exist only in people's heads, and which are missing. Your assessor or internal team should also check whether the system needs a notified body or can rely on internal control under Annex VI, since that choice drives much of the effort.

Cost and effort depend on the number of systems, the number of roles you hold, and how mature your evidence already is. A small set of deployer-only tools with existing logs costs far less to review than several provider-side high-risk systems with no technical documentation. Ask any consultant or implementation partner for a written scope that names the systems, roles, evidence sources and deliverables, and state whether each cost is one-time or recurring, such as log retention or periodic reviews. An independent auditor, assessor or notified body issues any formal outcome. DeployOpen prepares systems, logs and evidence for that review, and the organization decides what it accepts as its position.

What are the phases of an AI Act readiness assessment?

The sequence moves from a complete inventory to a role and risk classification, then to gap reviews against the high-risk requirements and deployer duties, and ends with a prioritized plan and a readiness report that the organization owns. Each phase produces a named output that the next phase depends on.

Scope the assessment and build the AI inventory
Confirm which business units, vendors and AI features fall inside the assessment, then list every system that may meet the definition of an AI system under the Act. For each entry, record the owner, the intended purpose, whether the organization built it, bought it or uses a general-purpose model, and where its output is used in the EU. The output is a scoped inventory signed off by the accountable executive. Ask the sponsor to confirm the scope in writing before classification starts, because systems missing from the inventory cannot be classified.
Classify roles and risk for each system
For each inventory entry, decide whether the organization is a provider, deployer, importer, distributor or authorised representative, since the duties differ by role. Screen every system against the nine prohibited practices in Article 5 first, because a prohibited practice has no compliance route. Then test whether the system falls under Annex I or Annex III, and where it does, check whether the Article 6(3) exemption applies and how that decision is documented. Legal and compliance staff review the result. The output is a classification record per system with the reasoning, including the not-high-risk decisions that must also be kept.
Review gaps against Articles 9, 11 and 12
For each system classified as high risk, compare current practice with the risk management process in Article 9, which expects a documented, continuous process across the lifecycle. Check the technical documentation against Article 11 and the Annex IV elements, and check whether the system technically allows automatic recording of events under Article 12. Interview engineering and product owners and inspect real artifacts such as risk registers, model cards and log configurations. The output is a gap register listing each missing or weak item with the artifact that would close it.
Review human oversight and the QMS against Articles 14 and 17
Check whether the design lets overseers understand the system's capacities and limitations, recognize automation bias, interpret outputs, override them and halt the system through a stop function, as Article 14 describes. Then assess the quality management system against the 13 aspects that Article 17 lists, using the policies, procedures and instructions the organization already has. Where a harmonised standard applies, note its status, since EN 18286:2026 was cited in the Official Journal on 14 October 2026 and gives a presumption of conformity for quality management. The output is a second set of gap entries covering oversight design and QMS coverage.
Review deployer duties under Article 26
Where the organization deploys a high-risk system built by someone else, review its duties under Article 26: using the system according to the provider's instructions, assigning competent human oversight, keeping input data under its control where relevant, monitoring operation, and keeping logs. Confirm whether the provider has supplied the instructions for use and whether the deployer's contracts require the information needed to meet these duties. The output is a deployer gap list, plus a list of contract and vendor questions that the procurement team must send to providers.
Prioritize remediation and set owners
Rank the gap entries from all earlier phases by the risk they carry to people's health, safety or fundamental rights, by the regulatory date that applies to each system, and by the effort each fix needs. Assign a named owner to each item and record the dependencies, such as a logging change that must precede a documentation update. Have the accountable executive approve the plan. Ask any implementation partner to quote fixed scope against this plan rather than a generic program. The output is a prioritized remediation plan with owners, dependencies and approval recorded.
Issue the readiness report and plan independent review
Write a readiness report that states, for each system, its role, risk classification, the gaps found, the remediation status and the open decisions. The organization owns this report and signs it. Keep the report and the evidence behind it in a controlled location, and note that it is an internal assessment, not a conformity assessment or certificate. Where an independent review is needed, the organization decides with its counsel and any notified body or auditor whether one is required for its systems. The output is the signed readiness report and a schedule for updating it as the Act's dates approach.

Which gaps show up first against the high-risk requirements?

Most gaps in a high-risk readiness review appear in the same handful of places: risk management, technical documentation, logs, oversight, the quality management system and deployer duties. Each card below names the evidence an assessor expects and the check a readiness team can run now. Harmonised standards are still arriving, so teams should measure against the Act text first and treat standards as a route to presumption of conformity.

Documented risk management

Article 9 requires a documented risk management system that runs as a continuous, iterative process across the whole lifecycle. Assessors look for a risk register tied to each known and reasonably foreseeable risk to health, safety or fundamental rights, estimates made under intended use and foreseeable misuse, and records showing post-market data feeds back into the assessment. Check whether the risk file has dated revisions and named owners, not a single pre-launch snapshot. A static risk assessment is the most common first gap.

Technical documentation completeness

Article 11 requires technical documentation drawn up before the system is placed on the market or put into service, kept up to date, and containing at least the elements listed in Annex IV. Assessors check that each Annex IV element exists, matches the system as deployed, and is versioned against the release it describes. Ask for a cross-reference table from each Annex IV element to its source document, and confirm that documentation changes are tied to change control.

Automatic event logs

Article 12 requires high-risk systems to technically allow automatic recording of events over the system's lifetime. The gap is usually technical rather than documentary: logging may be switched off, sampled, or stored where no one can retrieve it. Check that logs capture the events needed to trace the system's operation, that retention is set and documented, and that a test extract can be produced on request. Confirm the log scope with the provider or deployer, because the two roles share log duties.

Human oversight and stop procedure

Article 14(4) asks that overseers can understand the system's capacities and limitations, stay alert to automation bias, interpret output correctly, decide not to use or override it, and interrupt it through a stop button or similar procedure that halts it safely. Assessors look for oversight role descriptions, training records, and a tested stop procedure with a timed run. A stop function that exists in code but has never been exercised by the people named to use it is a common finding.

QMS aspects under Article 17

Article 17(1) requires a quality management system documented as written policies, procedures and instructions covering at least 13 aspects, including compliance strategy, design control, testing, standards applied, data management, post-market monitoring, incident reporting, record-keeping and an accountability framework. Map each of the 13 aspects to a named document and an owner, then check that the documents are approved and in use. EN 18286:2026 was cited in the Official Journal on 14 October 2026 as the first harmonised standard for the QMS, which gives a presumption of conformity for the matching requirements.

Deployer duties under Article 26

Article 26 sets out what deployers of high-risk systems must do, including using the system according to the provider's instructions, assigning competent human oversight, monitoring operation, and keeping logs under their control for an appropriate period. Assessors look for the deployer's own register of systems, instructions for use on file, a named oversight owner, and a monitoring routine that reports incidents back to the provider. Confirm which duties apply to your organization, since a deployer that changes a system's purpose can take on provider duties.

Which parts of the AI Act already apply and which dates are still ahead?

Some AI Act duties already apply, so a readiness assessment has to test them today rather than schedule them for later. Chapters I and II, which cover definitions, AI literacy and the prohibited practices, have applied since 2 February 2025. The general-purpose AI rules, the governance provisions and the penalty chapter have applied since 2 August 2025, except Article 101. In practice, the first questions for any assessor are whether the organization has screened its AI uses against the Article 5 prohibitions and whether staff who operate AI systems have adequate AI literacy. Both checks can be run now and documented now.

The high-risk rules are the largest remaining workload, and the 2026 Digital Omnibus moved their dates. Under Regulation (EU) 2026/1744, the Chapter III Sections 1 to 3 requirements apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, instead of 2 August 2026 and 2 August 2027. The rest of the Act, including the transparency duties, applies on the general date set in Article 113 as amended. A readiness plan should name which of your systems fall under each annex, since the two dates produce two separate programs of work and the Annex I date depends on the timing of product conformity assessment.

Confirm every date against the consolidated text of the AI Act on EUR-Lex before you fix a project plan or a board commitment, because the amended text is the reference an assessor will use. Check the entry into force date of the Digital Omnibus, the application dates in Article 113 and any transitional provisions that apply to systems placed on the market before the high-risk dates. Record the source and the date you checked it, and repeat the check whenever the Commission publishes guidance or the harmonised standards are cited, since those events can change what evidence is expected.

Who owns the controls and who prepares the evidence?

Your organization remains the provider or deployer under the Act, so it owns the decisions that make the system compliant. That includes the role determination, the risk classification under Article 6 and Annex III, the design choices, the risk management process under Article 9, and the quality management system required by Article 17. Leadership also owns the sign-off that a system may be placed on the market or put into service, and the EU declaration of conformity where one applies.

Role and classification: Decide whether you are a provider, deployer, importer or distributor for each system, and record the high-risk determination and any Article 6(3) reasoning.
Controls and QMS: Own the written policies, procedures and instructions, and assign named accountable people for each one.
Risk and oversight decisions: Set the acceptable risk thresholds, the human oversight design and who is allowed to override or stop the system.
Sign-off: Approve the technical documentation and the go-live decision, and keep the accountable record of who approved it.

Ask your advisers to show you which of these decisions they drafted, and confirm that your own accountable owner has reviewed and accepted each one.

Should you assess readiness in-house or with an outside partner?

This table compares three ways to run an AI Act readiness assessment: in-house, a consultant-led gap review, and a partner-led assessment followed by implementation. Read each row to see who does the work, which organizations each route suits, and what your organization must still keep and approve itself.

Route	Who does the work	What it suits and what you still keep
In-house assessment	Your legal, compliance and engineering staff classify systems, map gaps against Articles 9 to 15 and 17, and write the findings.	Suits a few systems with strong internal legal and engineering staff. You keep the inventory, risk classification, gap register, owner sign-off and the record of every decision.
Consultant-led gap review	An outside consultant reviews your inventory and documents, interviews owners and reports gaps. Your team fixes the gaps.	Suits a limited number of systems where you need an independent view of classification and documentation. You keep remediation ownership, the accountability framework and the evidence trail that follows the review.
Partner-led assessment, then implementation	An implementation partner assesses systems, then prepares logging, oversight, QMS records and technical documentation in your own infrastructure. Independent assessors or notified bodies handle any formal conformity step that applies.	Suits many systems, heavy logging needs or self-hosted models. You keep the scope in writing, the approval of each high-risk decision, and the records the provider or deployer must hold, because a partner prepares evidence but does not issue certification.

What makes an assessment larger or longer?

Most of the effort in an AI Act readiness assessment comes from how many AI systems are in play, which legal route makes them high-risk, and how much evidence already exists. The cards below cover the factors that move an assessment up or down, and the scoping decisions you can make in writing before any work starts.

Number of AI systems and roles

Each AI system needs its own role decision: provider, deployer, importer, distributor or other operator. A system you build and sell is assessed differently from one you buy and configure, even when both run in the same workflow. Start with a complete inventory, then triage by likely risk tier so high-risk candidates get full review first. Confirm in writing which systems are in scope and which are documented as not high-risk.

Annex I or Annex III routing

A system becomes high-risk either because it is a safety component of a product covered by Annex I legislation, or because it falls within an Annex III use case. The two routes lead to different conformity assessment paths and different application dates, so the assessor needs to know which route applies before estimating effort. Ask the assessor to record the route for each system and to check the Article 6(3) exemption where it is claimed.

Third-party or self-hosted general-purpose models

Systems built on a general-purpose model you do not control need vendor evidence about that model before you can document your own system. Systems built on a model you host yourself add duties for the model itself, including its training data summary and technical documentation. The assessment grows with each layer you fine-tune, retrain or redeploy. Ask the model provider which documentation they supply, and confirm whether your use changes your role.

Data and logging maturity

Article 12 requires high-risk systems to allow automatic recording of events over their lifetime, and Article 11 requires technical documentation that stays up to date. If logs are incomplete, unlinked to model versions or held in tools nobody reviews, the assessor spends time reconstructing history. Check whether training, validation and test data sets are documented, whether log fields identify the system version, and how long records are kept. Mature logging shortens the review considerably.

Business units and locations

Each business unit that buys, configures or uses AI may run its own systems, approvals and records. Several legal entities or EU member states add interviews, local deployer duties and sometimes different national market surveillance contacts. Work out the number of owners and sites before quoting, and agree which units are covered by one governance policy and which need separate review. A single accountable owner for the inventory reduces repeated questioning across units.

Vendor documentation and contracts

Third-party AI products often bring documentation you must collect, check and rely on, including instructions for use, conformity statements and incident contacts. Where a vendor cannot supply evidence, you may need to document the gap, add contract terms or change the system. Each vendor that cannot answer adds a round of follow-up. Ask for vendor documentation requests and contract clauses before the assessment starts, and confirm which vendor claims you will verify independently.

What should a written scope and quote for an assessment include?

DeployOpen does not publish a price list. A quote follows from a written scope, and most engagements are fixed-scope, so the scope document is the thing to get right before any money changes hands. A useful scope names the AI systems and the roles the organization holds for each (provider, deployer, importer, distributor or a general-purpose model provider), the articles and annexes the assessment will test against, and the date the assessment is measured against. Ask for the systems to be listed by name and intended purpose, not by vendor category, because the same product can be high-risk in one deployment and outside Annex III in another. The scope should also say which Article 16 obligations and which Article 17 QMS aspects are in or out, and whether the work is measured against the dates in the 2026 amendment: 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product systems.

The deliverables should be concrete enough to check at the end. Ask for a gap register that maps each requirement to the current state, an owner, a severity and a remediation item; documentation templates for technical documentation under Annex IV and the risk management record under Article 9; an evidence list that names the artifact, the system that produces it and the retention period; and a log and human oversight review covering Articles 12 and 14. The quote should state what the organization must supply: named system owners, access to repositories and logging platforms, existing policies, vendor contracts and staff time for interviews. Exclusions belong in writing too: legal opinions on classification, notified body fees where a notified body is required, and the conformity assessment itself, which only an independent body can issue.

Remediation is priced separately from the assessment. A readiness assessment finds gaps; building the controls, documentation or tooling to close them is a second scope with its own deliverables and acceptance criteria. Ask the quote to show the two as separate line items, to state which recurring items (such as log retention, monitoring or periodic reassessment) continue after handover, and to name the change control that applies if the regulatory dates or harmonised standards move. Confirm the harmonised standard position with the relevant CEN-CENELEC documents before the scope is signed, since EN 18286:2026 is the first cited standard and others were still in drafting in mid-2026.

What do buyers ask before running an AI Act readiness assessment?

How long does an AI Act readiness assessment take?

The length depends mainly on how many AI systems you have, how many of them could be high-risk, and how much documentation already exists. A readiness assessment for a small inventory with clear roles will take far less time than one covering dozens of systems that touch hiring, lending, insurance or medical decisions. The dates that set the deadline are fixed in the law: the rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, as amended in 2026. Ask any provider for a written scope, a list of systems in that scope, and a schedule tied to those dates before you compare timelines.

Can we run an AI Act readiness assessment ourselves?

Yes, an organization can run its own readiness assessment, and many do the first pass internally. The work is mostly structured: inventory your AI systems, classify each by role and risk, and compare what you have against the high-risk requirements in Articles 9, 11, 12, 14 and 17. The harder parts are reading the classification rules correctly, deciding whether a use falls under Article 6(3), and judging whether your evidence would satisfy an assessor. Internal teams often benefit from an outside review of the classification and the gap list, which keeps the conclusions defensible.

What skills and staff time does an assessment need?

A useful assessment needs people who know where AI is used and people who can judge the evidence. In practice this means a legal or compliance lead who can read the Act, a product or business owner for each AI use, an engineering lead who knows how the system is built and logged, a data owner, and someone who runs the quality management process. Expect each owner to spend time answering questions about purpose, data, users and human oversight. Ask any partner which roles they expect you to staff, how many hours they assume from each, and which decisions remain with your own staff.

Does an AI Act readiness assessment certify compliance?

No. A readiness assessment shows where your organization stands against the Act and gives you a prioritized list of gaps, but it does not certify anything. Only you can decide how you classify your systems and what you conclude about compliance, and that conclusion stays with your organization. For high-risk systems, conformity assessment is carried out under the Act's procedures, and certificates or reports come only from independent bodies such as notified bodies or other certification bodies where the Act requires one. Any provider offering a readiness assessment should state this in its written scope.

Does the AI Act require a notified body for every system?

No. Most Annex III high-risk systems use internal-control conformity assessment under Annex VI, which means the provider carries out the assessment itself and does not need a notified body. Notified bodies are involved for some biometric systems and for certain Annex I products, as set out in Article 43. Your readiness assessment should confirm, system by system, which conformity route applies, because the answer changes the evidence you must prepare and whether an external body is part of the path.

What are the fines under Article 99 of the AI Act?

Article 99 sets three maximum fine levels, and the higher of the two amounts applies in each case. For prohibited practices, the maximum is EUR 35 million or 7% of worldwide annual turnover. For most operator obligations, the maximum is EUR 15 million or 3%. For supplying incorrect, incomplete or misleading information to authorities, the maximum is EUR 7.5 million or 1%. National market surveillance authorities enforce the Act for AI systems, so the exposure depends on where you place systems and where your outputs are used. Check the exact wording of Article 99 in the consolidated text before you rely on these figures in an internal decision.

How do we choose a partner for an AI Act readiness assessment?

Start by asking what the partner will and will not do. A credible partner separates its role from the auditor's: it prepares systems, controls and evidence, while independent auditors and certification bodies issue reports or certificates. Ask for a fixed written scope that lists the AI systems, deliverables, dates and the people who will do the work. Ask how they classify systems, which standards they measure against, and what evidence they will produce. DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure and prepares compliance evidence, and it does not issue audit reports or certifications. It does not publish a price list, so request a quote tied to your written scope.

How do you choose a readiness partner for the AI Act?

Start with named experience on both sides of the problem: the AI Act itself, and self-hosted AI platforms running inside your own infrastructure. Ask the candidate to show how it has classified AI systems against Annex III, how it handled the Article 6(3) exemption, and how it treated the 2026 changes to the high-risk dates. Then ask how it has built logging, human oversight and documentation into a platform it deployed, not just into a slide deck. A partner that can describe the technical work in its own words, including what it configured and what it left to you, is worth more than one that quotes the regulation back to you.

Insist on clear role boundaries in writing. Your organization owns the risk classification, the sign-off on each high-risk determination and the decision to place a system on the market or put it into service. The partner prepares the inventory, the technical documentation drafts, the QMS records and the evidence packs. Any proposal that implies the partner will certify, declare conformity or approve classifications on your behalf should be rejected. Also ask for a fixed-scope written proposal that lists the systems in scope, the deliverables per system, the evidence each deliverable will contain and the points where your staff must act. Scope changes should be priced as written amendments.

Confirm three more things before signing. First, that the documentation and evidence will be handed over and stored in your environment, in your repositories and under your access controls, so you keep the record after the engagement ends. Second, that the partner will tell you which source each requirement comes from and will confirm when a harmonised standard or Commission guidance is still in draft, such as the standards still in development in mid-2026. Third, that the partner will state plainly that no vendor can guarantee a regulator's or auditor's conclusion. Independent assessors and notified bodies reach their own findings, and a readiness partner's job is to make those findings easier to reach, not to promise them.

How DeployOpen scopes and prepares AI Act readiness evidence

DeployOpen works on EU AI Act readiness as a fixed-scope engagement inside your own infrastructure. We prepare the systems, records and evidence that a readiness review or an independent assessor will examine, while your organization keeps ownership of its classification decisions and controls.

How we scope

Written scope names the AI systems, roles (provider, deployer or both) and environments covered by the readiness review.
Scope records which systems are treated as not high-risk and the reasoning behind each decision for your file.
Deliverables, exclusions and timelines are agreed in writing before any work starts, and changes go through a written scope update.

How we build

We map existing logging, access, change and monitoring data to the high-risk requirements to identify concrete gaps.
We help set up automatic event logging, technical documentation templates and human oversight procedures on your own platforms.
We run gap tests on the prepared evidence, such as log sampling and stop-procedure walkthroughs, and document the results.

How we hand over

You receive the readiness gap register, evidence index and configuration records, with each item linked to the article it supports.
Documentation is delivered in your repositories and document systems so your teams can keep it current after handover.
Assessor-facing material is labeled as prepared by DeployOpen, and any report or certificate must come from an independent auditor or certification body.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
Retainer scope, response expectations and review cadence are agreed in writing, so you know what is covered before you sign.
Ask us to confirm which standards and guidance apply at the time of your review, since harmonised standards are still being published.

EU AI Act readiness assessment