Before assuming an AI solution meets EU AI Act requirements, you need to verify four things: the system’s risk classification, the documentation it carries, your vendor’s compliance claims, and your own organisation’s internal governance obligations. Compliance is not a label a vendor applies once — it is a shared responsibility that requires active, continuous governance from both the supplier and the deploying organisation. The questions below walk through each layer of that verification, so you know exactly what to check and why it matters in 2026.

If you have specific questions about your situation, feel free to reach out and we would be happy to think along with you.

Which risk category does your AI system actually fall under?

Your AI system falls under one of four risk categories defined by the EU AI Act: unacceptable risk (prohibited), high risk, limited risk, or minimal risk. The category is determined by the system’s intended use, the sector it operates in, and the degree of impact it has on people’s rights, safety, or access to services. Most enterprise AI tools that affect hiring, credit, health, education, or critical infrastructure fall into the high-risk category.

Many organisations underestimate this step. Vendors often market their products as “compliant” without specifying which risk tier that compliance addresses. A tool classified as limited risk carries far lighter obligations than a high-risk system, so misclassifying downward creates real legal exposure. The classification must be based on the system’s actual deployment context, not just its general description.

Practically, you should map each AI system against Annex III of the EU AI Act, which lists the high-risk use cases explicitly. If your system supports decisions in recruitment, employee performance monitoring, creditworthiness assessment, or law enforcement, it almost certainly qualifies as high risk regardless of how the vendor positions it. When in doubt, treat the system as high risk until you have documented evidence to support a lower classification.

What documentation must a high-risk AI system have in place?

A high-risk AI system must have technical documentation, a conformity assessment, a declaration of conformity, registration in the EU database, and an active risk management system. It must also include a data governance framework, transparency information for users, and human oversight measures. These are not optional additions — they are legal prerequisites for placing a high-risk system on the EU market or putting it into service.

Technical documentation and risk management

Technical documentation must describe the system’s purpose, architecture, training data, performance metrics, and known limitations. This documentation needs to be kept current throughout the system’s lifecycle, not produced once at launch. The risk management system is equally ongoing: it must identify, evaluate, and mitigate risks continuously, with records showing that mitigation measures were actually applied.

Conformity assessment and registration

For most high-risk systems, the provider must conduct a conformity assessment demonstrating the system meets the Act’s requirements before deployment. Certain categories require third-party assessment. Once the assessment is complete, the system must be registered in the EU’s AI database. Ask your vendor for the registration number and verify it. If they cannot provide one, the system is not lawfully deployed as a high-risk AI system under the Act.

How do you verify that a vendor’s AI Act claims are accurate?

You verify a vendor’s AI Act compliance claims by requesting the technical documentation, the conformity assessment record, and the EU database registration. Cross-check these against the system’s actual use case in your organisation. Vendor claims made in marketing materials or sales conversations carry no legal weight — only the documented evidence matters.

Start with a structured questionnaire. Ask the vendor to confirm the risk classification in writing, provide the conformity assessment or a summary, name the standards they have applied, and describe their post-market monitoring process. A vendor with genuine compliance will answer these questions clearly and quickly. Evasive or vague responses are a strong signal that the documentation does not exist or is incomplete.

You should also review the vendor’s contractual commitments. AI Act obligations include provisions around incident reporting, post-market surveillance, and updates to documentation when the system changes materially. If the contract does not address these, you are carrying risk that the vendor has not formally accepted. Governance across the supply chain is a core principle of the Act, and your organisation is exposed if a vendor’s compliance breaks down after deployment.

What internal governance obligations does your organisation still hold?

Even when deploying a third-party AI system, your organisation retains obligations as a deployer under the EU AI Act. These include conducting a fundamental rights impact assessment where required, ensuring human oversight is operational, monitoring the system’s performance in your specific context, and reporting serious incidents to the relevant authority. Deployer obligations exist independently of what the provider has done.

This is where continuous governance becomes essential. Many organisations assume that once a vendor delivers a compliant product, the compliance obligation transfers entirely. It does not. Your organisation must maintain records of how the system is used, who oversees it, what decisions it informs, and how those decisions are reviewed. These records form the evidence base if a regulator or auditor questions your use of the system.

Internal governance also means assigning clear accountability. Someone in your organisation needs to own the AI system from a governance perspective, not just from an operational one. That person should understand the system’s risk classification, know what documentation exists, and be able to act if the system behaves unexpectedly or if the vendor’s compliance status changes. Role-based accountability, rather than individual dependency, is what makes this sustainable. Our governance services are specifically designed to support organisations in building and maintaining this kind of structured, ongoing accountability.

When should an AI system be re-evaluated for compliance?

An AI system should be re-evaluated for compliance whenever the system itself changes materially, when your use case evolves, when new regulatory guidance is issued, or on a scheduled periodic basis. The EU AI Act is explicit that compliance is not a one-time determination — it is a continuous obligation tied to the system’s actual operation and context.

Triggers that should prompt an immediate re-evaluation include significant updates to the AI model or training data, expansion of the system’s use to new departments or decision types, changes in the regulatory landscape such as updated guidance from the European AI Office, and any incident involving unexpected or harmful outputs. Each of these can alter the risk profile of the system or the adequacy of existing controls.

Beyond reactive triggers, build a scheduled review into your governance calendar. Annual reviews are a reasonable baseline for most high-risk systems, but organisations operating in fast-moving sectors or with AI systems that influence high-stakes decisions should review more frequently. Aligning these reviews with your broader certification cycles, for example ISO 27001 or ISO 42001 surveillance audits, creates efficiency and ensures AI governance does not operate in isolation from your wider compliance programme. Governance drift, the gradual erosion of controls between formal reviews, is one of the most common and least visible compliance risks organisations face in 2026.

Staying on top of AI Act compliance requires more than a one-time check. It demands a structured, living governance system that keeps pace with how your AI tools evolve and how the regulatory framework develops. If you want to build that kind of continuous governance into your organisation without starting from scratch, get in touch with us and we will show you how we can help.

Frequently Asked Questions

What is the difference between a provider and a deployer under the EU AI Act, and how does that affect who is responsible for compliance?

A provider is the entity that develops and places the AI system on the market, while a deployer is the organisation that puts it into use within a specific operational context. Both carry distinct legal obligations — providers are responsible for technical documentation, conformity assessments, and EU database registration, while deployers are responsible for fundamental rights impact assessments, human oversight, incident reporting, and monitoring the system in their specific context. In practice, most enterprise organisations purchasing third-party AI tools are deployers, which means compliance does not end at procurement. You remain legally accountable for how the system is used, regardless of how compliant the vendor's product is.

What should we do if a vendor refuses to share technical documentation or conformity assessment records?

Treat the refusal as a serious red flag and do not proceed with deployment of that system in a high-risk context until the documentation is provided. Under the EU AI Act, deployers have a right to access the information necessary to fulfil their own obligations, and a vendor unwilling to share conformity evidence is either non-compliant or unable to demonstrate compliance. Escalate the request formally in writing, referencing your obligations as a deployer under the Act. If the vendor still cannot or will not provide the documentation, consider whether the risk of deploying an unverified system is one your organisation can legally and operationally justify.

How do we handle AI systems that were already in use before the EU AI Act obligations came into force?

Existing AI systems, often referred to as legacy systems, are subject to transitional provisions under the EU AI Act, but those provisions have expiry dates — high-risk systems already in service must reach full compliance by the applicable deadline, which for many categories falls in 2027. This does not mean you can defer action; it means you should be actively working toward compliance now, not waiting until the deadline approaches. Start by classifying each legacy system under the current framework, identifying the documentation gaps, and engaging your vendor on their compliance roadmap. Organisations that begin this process early are far better positioned than those who treat the transitional period as a pause.

Can a single AI tool fall into different risk categories depending on how it is used?

Yes, and this is one of the most practically important nuances of the EU AI Act. The same underlying AI tool can be minimal risk in one deployment context and high risk in another, because classification is based on the intended use and the impact on people — not the technology itself. For example, a language model used to draft internal communications is likely minimal risk, but the same model integrated into a recruitment screening workflow almost certainly qualifies as high risk. This means you need to classify each use case individually, not just each tool. If your organisation uses one AI platform across multiple departments for different purposes, each distinct use case may require its own compliance assessment.

What does a fundamental rights impact assessment involve, and when does our organisation need to conduct one?

A fundamental rights impact assessment (FRIA) is a structured evaluation of how a high-risk AI system may affect people's rights — including rights related to non-discrimination, privacy, access to services, and due process. Deployers of high-risk AI systems are required to conduct a FRIA before putting the system into service, particularly where the system is used by public bodies or in contexts with significant impact on individuals. The assessment should document the potential risks identified, the measures put in place to mitigate them, and who within your organisation is accountable for those mitigations. It is not a one-off exercise — if the system's use case changes materially, the assessment should be revisited.

What are the most common mistakes organisations make when trying to get compliant with the EU AI Act?

The most common mistake is treating compliance as a vendor responsibility and assuming that a 'compliant' product means the deploying organisation has no further obligations — it does. A close second is classifying AI systems based on how they are marketed rather than how they are actually used, which often results in high-risk systems being treated as limited or minimal risk. Organisations also frequently underestimate the documentation burden: compliance is not just about having the right system in place, but about being able to evidence that it is governed correctly over time. Finally, many organisations assign AI governance to a single individual rather than building role-based accountability into their structure, which creates fragility when that person changes roles or leaves.

How does ISO 42001 relate to EU AI Act compliance, and is certification worth pursuing?

ISO 42001 is an international standard for AI management systems, and while it is not a legal requirement under the EU AI Act, it provides a structured framework for building the kind of continuous governance the Act demands. Achieving ISO 42001 certification demonstrates that your organisation has systematic processes for managing AI risks, which can support — though not substitute for — the specific compliance requirements of the Act. For organisations already operating under ISO 27001, pursuing ISO 42001 alongside it creates meaningful efficiency, since the two standards share structural similarities and can be audited in alignment. Whether certification is worth pursuing depends on your sector, the volume and risk level of your AI deployments, and whether your clients or regulators are beginning to expect it as a baseline.

Related Articles

Share

  • May 17, 2026