AI Act readiness for SMEs: what consultants need to ask

Provider, deployer, importer, distributor

The first question in an AI Act engagement is not "is this high risk". It is "what is my client, in relation to this particular system". Get the role wrong and every document downstream is addressed to the wrong obligations.

The instrument is Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744, the Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and in force since 27 July 2026. The amendment moved dates and softened one obligation. It did not reduce the substance of what a provider of a high-risk system has to produce.

Role attaches per system, not per company, and this is where most SME interviews go wrong. A forty-person recruitment agency can be a deployer of an off-the-shelf scheduling assistant, a provider of the scoring model it built in-house, and both at once for a vendor model it fine-tuned on its own data. One answer to "are you a provider or a deployer?" at company level is not an answer at all.

The provision worth memorising is Article 25(1). An organisation that substantially modifies a system, or puts an existing system to a high-risk purpose under its own name, becomes its provider. The provider's obligations follow: technical documentation, risk management, conformity assessment. Most SME clients have no idea this rule exists, and the moment you find one that fine-tuned a third-party model for CV screening is the moment the engagement justifies itself.

Importer and distributor roles come up less often, but they come up. Ask when the client resells someone else's system, puts its own name or trademark on it, or brings a system from outside the Union onto the EU market. Note also that the regulation reaches clients not established in the EEA at all: it covers systems whose output is used in the Union, so a UK or US client serving EEA users is in scope for the same conversation.

Questions that settle the role

• For each system, separately: did you build it, buy it, or buy it and change it?
• Did you fine-tune, retrain, or adapt a vendor model on your own data?
• Do you put your own name or trademark on the system when you offer it to others?
• Has the intended purpose changed from what the vendor documented?
• Does the system reach users, or produce output used, in the EEA?

Record the answer per system with the reasoning, and confirm the role yourself. A tool can suggest a role and show the trigger; the qualification is a legal judgement, and it belongs to the person who signs the file.

Building the system inventory

Nothing else in the file works without the register. Classification keys off it, the document set keys off the classification, and the deadline that matters to a given client depends on which categories they actually have confirmed. Build it first, and build it from records rather than recollection.

Eight fields carry the weight:

• Name as the business uses it, not the vendor's product family.
• Intended purpose, in one sentence, in the client's own words.
• Vendor, as a legal entity, not a brand. "Copilot" is not a counterparty.
• Role per Article 25 reasoning above.
• Use cases selected from a fixed list, not free text.
• Substantially modified: yes or no, with what was done.
• Risk category, stored only once you have confirmed it.
• Who confirmed it and when.

That last pair is not bureaucracy. If the use cases, the role or the modification flag change later, the confirmation is stale and has to be taken again — a register that silently keeps a category confirmed against facts that have moved is worse than no register.

The hard part of inventory work at SMEs is not the systems the client tells you about. It is the ones nobody thinks of as systems: a summarisation feature switched on inside an existing SaaS subscription, a browser extension a team installed itself, a scoring feature inside the applicant tracking system. Three sources beat asking the founder: the expense and card statements, the identity provider's app list, and the vendor register you already maintain for the GDPR file. Run those three and the interview becomes a confirmation exercise instead of a memory test.

Two discipline points. First, the register is compiled from confirmed records, never drafted by a language model — vendor lists, URLs and system names are exactly the facts a model will invent, and one invented subprocessor in a pack sent to a client's enterprise customer costs you the relationship. Second, a system whose category you have not confirmed yet is a gap in the document, an explicit "risk category of the AI system, confirmed by the consultant", not a guess dressed as a finding.

While you are in the register, capture logging. Deployers of high-risk systems keep logs, and six months is the floor to plan around. Capture the incident path too, because the reporting clock under Article 73 is short: fifteen days to the market surveillance authority of the Member State where the incident occurred for a serious incident involving a high-risk system, two days for a widespread infringement or a serious and irreversible disruption of critical infrastructure, and ten days where a person has died. For a client who is also in scope for GDPR and NIS2, those sit alongside a 72-hour and a 24-hour duty to different authorities, and what is said in the first day is available to all three investigations. That single table — three regimes, three clocks, three recipients — is worth building once per client and keeping in the incident response policy.

Annex III use cases in practice

Annex III is a list of uses, not a list of technologies, which is why the interview has to be about what the system decides rather than what model sits underneath it. The points that actually appear in an SME portfolio:

• Point 3 — admission, assessment and proctoring in education.
• Point 4(a) — recruitment and selection, including screening applications.
• Point 4(b) — decisions on promotion and termination, task allocation and monitoring of workers.
• Point 5(a) — eligibility for public assistance benefits and services.
• Point 5(b) — creditworthiness assessment and credit scoring of natural persons.
• Point 5(c) — risk assessment and pricing for life and health insurance.
• Point 5(d) — evaluating and classifying emergency calls, and dispatch.

The rest of the Annex — biometric identification at point 1(a), emotion recognition outside work and education at point 1(c), safety components in critical infrastructure at point 2, law enforcement at point 6, migration, asylum and border control at point 7, administration of justice and influencing elections at point 8 — matters when it matters, and it is worth reading the list aloud in the interview rather than assuming a small business is nowhere near it. Separately, Article 6(1) makes an AI safety component of a product covered by Annex I legislation high risk: medical devices, machinery, toys, vehicles, aviation. A twelve-person manufacturer with a vision system on the line is in that branch, not the Annex III one, and the branches have different dates.

Two follow-ups do most of the work once a point matches.

The first is Article 6(3). A system that falls within an Annex III area is not high risk if it performs a narrow procedural task or does not materially influence the outcome of decision-making — unless it profiles natural persons, which removes the exemption. This is a real off-ramp for things like a CV parser that only extracts fields into a form. It is also the provision most likely to be leaned on wishfully. If you rely on it, the reasoning has to be written down and dated before the system is placed on the market, not reconstructed afterwards, and it should name the human decision the system does not materially influence.

The second is Article 27. A fundamental rights impact assessment falls on deployers, not only providers, and in the SME book it lands specifically on deployers of Annex III credit scoring and of life and health insurance pricing. Deployers providing public services are also caught, and whether your client is one of those depends on what it is and who it acts for — that is a call you make, not one a questionnaire makes for you.

Where a system is high risk, the document set splits by role. Annex IV technical documentation and the Article 9 risk assessment are the provider's, so they appear when your client is the provider — including where it became one under Article 25(1). The Article 14 human oversight procedure and the logging policy attach to any high-risk system in the file, provider or deployer. The system register, the literacy policy and the supply-chain contract clauses apply to every client that uses AI at all.

Prohibited practices checklist

Short list, absolute consequences. Run it on every client with AI in the register, including the ones you are confident about.

• Social scoring of people — Article 5(1)(c).
• Emotion recognition in the workplace or in education — Article 5(1)(f), with a narrow exception for medical or safety reasons.
• Biometric categorisation to infer race, political opinions, religion, sex life or sexual orientation — Article 5(1)(g).
• Real-time remote biometric identification for law enforcement in public spaces — restricted by Article 5(1)(h), and the underlying use is in any case listed at Annex III point 1(a).
• From 2 December 2026, as amended by Regulation (EU) 2026/1744: generating or manipulating intimate imagery of real people without their consent, and child sexual abuse material.

Two traps recur in ordinary businesses that would never describe themselves as doing anything exotic. Meeting and sales tools increasingly ship sentiment, attention or engagement scoring; pointed at employees or students, that is Article 5(1)(f) territory, and the fact that it arrived as a feature update to a tool bought for something else is not a defence. Pointed at customers in a contact centre instead, it is not prohibited but lands at Annex III point 1(c) as high risk — a different answer, so the question has to be who is being scored. The other trap is ad-tech and analytics features that infer demographics from images or voice, which can reach Article 5(1)(g) without anybody in the business ever using the word biometric.

Say the consequence plainly to the client, because it is unlike everything else in the file: a prohibited practice cannot be documented into acceptability. The remedy is to stop the use or change the purpose. There is no version of the paperwork that fixes it.

Transparency obligations for chatbots and generated content

The limited-risk tier is where most SME systems land, and it has been in application since 2 August 2026, so for a client with a chatbot this is not a future deadline — it is a current gap.

Article 50(1) requires that people be informed they are interacting with an AI system. Article 50(2) and 50(4) require generated content to be marked as artificially generated and deepfakes to be disclosed. In practice the question to ask is where the disclosure lives: a sentence in the terms of service is not the same as a notice in the interface at the point of interaction, and the second is what the obligation is about. Ask to see the widget, the first message, the export, the social post.

The date to put in front of clients now is 2 December 2026, when machine-readable marking of generated content applies to systems already on the market. This is the one that catches the SME that shipped an image or copy generator before the rule bit and assumed it had been grandfathered. Marking that a human can see is not marking a machine can read, and retrofitting it into an existing pipeline is engineering work with a lead time, which means the conversation has to happen well before the date rather than after it.

One more obligation belongs in this section because it applies to every client with AI regardless of category. Article 4 covers AI literacy, and the Digital Omnibus softened it: the duty is to support AI literacy among staff, rather than to secure a particular level of it. Softened is not removed. A short literacy policy, naming who is trained on what and when, is a cheap document and the one most likely to be asked for first by a client's own enterprise customer.

Timeline by obligation

Dates as confirmed against the post-omnibus text on 17 September 2026. Earlier published timelines for high-risk obligations circulate widely and are out of date; check any date you are about to put in a client letter against the amended regulation rather than against a slide deck.

Date	What applies	Lands on
2 August 2026	Transparency obligations under Article 50	Providers and deployers of chatbots and content-generating systems
2 December 2026	New prohibited practices: intimate imagery without consent, child sexual abuse material	Any client, checked against the whole register
2 December 2026	Machine-readable marking of generated content applies to systems already on the market	Limited-risk systems shipped before the rule
2 December 2027	High-risk obligations apply to Annex III systems	Clients with a confirmed Annex III system
2 August 2028	High-risk obligations apply to Annex I systems, safety components of regulated products	Clients with a confirmed Annex I system

Two practical notes on working this table across a portfolio. First, a date is only a date for a client who actually has a system in that category confirmed, which is another reason the register has to be real before the calendar is useful. Second, six, three and one month before each date is the sensible reminder cadence, because the Annex III work — technical documentation, risk management, oversight design — is measured in months, not in an afternoon.

Keep the dates as data with a source and a checked-on date next to them, not as prose scattered through templates. The regulation has already moved once, some of what follows is political until it is formally adopted, and the cost of a stale date in a client letter is borne by your name, not the regulator's. That is also how clausebench holds them: the deadline list is a file with its source recorded, so when the text moves again, one edit moves every client's calendar.

None of this is a verdict you can hand a client. The regulation rewards a consultant who asks precise questions per system, writes down the reasoning for each answer, and keeps the register honest about what is still unknown. The documents required by the regulation can be drafted from that record quickly, which speeds up your work — but the classification, the role and the judgement underneath them stay yours.