AI Act Readiness Assessment

Classification: prohibited, high-risk, or neither

The EU AI Act (Regulation (EU) 2024/1689) regulates AI by risk, not by sector. The first question for any system is which risk bucket it sits in, because the bucket decides the whole obligation set. We work that question against the legislation, not against a generic checklist.

Article 5 lists the practices that are banned outright — among them untargeted scraping of facial images, social scoring by public authorities, and certain biometric categorisation. If any system you run touches a prohibited practice, no amount of documentation makes it compliant; it has to stop. We flag these first.

Article 6 sets the rules for high-risk classification. A system is high-risk on one of two routes: it is a safety component of a product already covered by EU harmonisation law (the Annex I route), or it falls under one of the use cases in Annex III — areas such as creditworthiness scoring of natural persons, recruitment and worker management, access to essential services, and biometric identification. Annex III is where most enterprise AI lands. We triage every system against the actual Annex III list and record why it is in or out.

Systems that are neither prohibited nor high-risk still carry transparency duties — users have to be told when they are interacting with AI or seeing AI-generated content. We capture those too, so nothing is mislabelled as out of scope.

Obligations by role: provider, deployer, importer, distributor

The same AI system imposes different duties depending on what you do with it. The Act draws a hard line between the provider that develops or brands a system and the deployer that uses one under its own authority, with separate, lighter duties for importers and distributors. Most organisations are deployers of vendor AI and providers of the systems they build in-house — often both at once, for different systems.

Providers of high-risk systems carry the heavy obligations: a risk-management system, data governance, technical documentation, record-keeping that lets a decision be traced back to its input under Article 12, human oversight, accuracy and robustness, conformity assessment under Article 43, and registration in the EU database under Article 49.

Deployers have their own duties — operating the system within the provider's instructions, assigning human oversight, monitoring, and, where a deployment falls within scope, completing a fundamental rights impact assessment under Article 27. A common and expensive mistake is assuming that buying AI from a vendor moves all the obligations onto the vendor. It does not.

General-purpose AI models carry a distinct obligation track of their own. Where you build on a foundation model, or provide one, we note the GPAI duties separately so they are not lost between the provider and deployer columns.

The gap register: per-obligation status, evidence, owner

Classification tells you which obligations apply. The gap register tells you where you stand against each one. For every applicable obligation we record the current status, the evidence that supports it, and the owner who has to close it — the same structure an auditor or a market-surveillance authority will expect to see.

Each row cites the provision it answers to. A finding against record-keeping points at Article 12; a finding against conformity assessment points at Article 43. Where the gateway returns only weak or unscoped sources for a requirement, we mark the regulatory basis unresolved rather than dress a training-data guess up as a citation. No uncited findings ship.

What you receive

Two artefacts. A board-ready readout that states, in plain terms, which of your systems are in scope, what risk tier each one sits in, and where the material exposure is — the document you put in front of a risk committee. And a remediation plan that turns the gap register into sequenced, owned work, with the highest-exposure gaps first.

Both are delivered as a structured, cited report. Every regulatory claim traces to Regulation (EU) 2024/1689 at article level, so your own counsel or auditor can check our work against the source rather than taking it on trust.

Timeline and the regulatory clock

The AI Act applies in stages rather than all at once. The prohibitions in Article 5 came into application first, ahead of the rest of the regime. The obligations for high-risk systems phase in later — the risk-management requirements for high-risk systems under Article 9 apply from 2 August 2026. That staged structure is why classification is urgent now: the systems most likely to need work are the ones whose deadline is still ahead, and the remediation runway is finite.

We verify the application-date framing against the legislation through the gateway as part of the engagement. Where a date claim cannot be grounded to the source, we say so rather than commit you to a deadline we cannot cite.