EU AI Act deployer duties start before the AI tool goes live
If an SME uses an AI system in its business, it may be a deployer under the EU AI Act even when the software was bought from a vendor. The EAB Compliance guide makes the practical point clearly: the provider may have built the system, but the organisation using it still governs how it is used in its own process.
That means the SME should avoid treating EU AI Act readiness as a vendor questionnaire exercise. Before an AI system is launched into day-to-day operations, the firm needs a short, evidence-backed map of the system, its purpose, the people responsible for it, the data it uses, the controls around it and the records that would explain what happened if something went wrong.
The safest approach is to map role, risk, oversight and evidence before deployment
An SME should map at least ten things before deploying an AI system: the system record, actor role, risk classification, intended purpose, provider instructions, authorised users, human oversight owner, input data controls, monitoring process, log retention and transparency or incident routes. For high-risk systems, those records become the difference between using the tool under control and hoping the vendor file is enough.
The first question is role. Are you the deployer, provider, importer, distributor or another actor? Most SMEs using third-party AI in client service, HR, finance, operations or compliance will at least need to test whether they are a deployer. If the firm modifies the system, markets it under its own name or changes its intended purpose, the role analysis may become more complex.
Map AI use cases and evidence gaps before launch
Start with an AI system register, not a policy document
The source guide is right to put visibility first. You cannot govern AI systems that nobody has registered. A useful SME register does not need to be elaborate, but it should capture the system name, vendor, business owner, purpose, process, user group, data categories, affected customers or staff, deployment date, risk classification, approval status and review date.
This is where many smaller firms discover their real exposure. A team may be using a public AI tool for first-draft emails, another may be testing an embedded assistant in a case management product, and another may be using automated scoring in a workflow platform. Those are different risk profiles. They need different evidence. A single policy cannot substitute for a live inventory.
For high-risk systems, turn provider instructions into operating controls
Where a system is high-risk, the deployer must use it in line with the provider's instructions for use. In practice, that means someone inside the SME has read the instructions, extracted the limits that matter and translated them into operating controls. The record should show who reviewed the instructions, which users are authorised, what input data requirements apply, when human review is required and what outputs must never be accepted automatically.
This is also where procurement and operations need to meet. If the provider documentation is vague, the SME should ask for clarification before launch. If the provider says a human must review outputs, the SME should define the reviewer, the review standard, the escalation route and the evidence kept after review.
Assign human oversight to named people with authority
Human oversight is not a slogan. The deployer needs to name the people who can review, challenge, override, pause or escalate the AI system's output. Those people need enough competence and authority to act. A junior user who is told to click through a recommendation without time, training or permission to challenge it is weak oversight.
For an SME, the oversight map can be simple: business owner, day-to-day user, reviewer, approver, incident contact and accountable senior lead. The key is to make the control real. If the AI system influences a client file, employment decision, credit decision, compliance workflow or regulated advice process, the oversight record should explain who made the final call and what they reviewed.
Put named AI ownership and review routines in place
Document input data, monitoring, logs and incident routes
The EAB guide highlights several operational duties that SMEs often miss. If the deployer controls input data, it should check whether the data is relevant, sufficiently representative and suitable for the intended purpose. Poor input data can make a compliant-looking system unsafe in practice.
The SME should also monitor operation. That does not mean building a large model-risk function on day one. It means recording errors, unexpected outputs, user complaints, performance concerns, override patterns, data quality issues and any circumstances where the system appears to operate outside the provider's limits. Those signals should feed a review meeting with a named owner.
Logs matter because they support audit and incident reconstruction. Before launch, the firm should know whether logs are created automatically, who controls them, where they are stored, how long they are retained and whether they can show the inputs, output, user, timestamp, model or system version, review decision and override reason. If the logs are controlled by the vendor, the contract should say how the SME can access them when needed.
Check transparency and data protection duties together
Some deployer duties are about transparency to affected people, especially where AI is used in sensitive or customer-facing contexts. SMEs should map whether customers, employees or other people need to be told that AI is being used, what the system is doing and who to contact if they want to challenge an outcome.
That review should sit alongside UK GDPR or EU GDPR accountability. If the AI use case processes personal data, the firm may need a DPIA, a lawful basis check, retention rules, access controls, processor terms and a way to explain decisions. EU AI Act mapping and data protection mapping should use the same facts, rather than creating two inconsistent records.
A practical pre-launch checklist for SMEs
- System: What AI system is being used, who provides it and where does it sit in the workflow?
- Purpose: What is the intended use, and what uses are out of scope?
- Role: Is the firm acting as deployer, or has customisation changed the role?
- Risk: Is the use prohibited, high-risk, limited-risk or lower-risk under the EU AI Act?
- Instructions: Which provider instructions apply, and how have they been turned into internal controls?
- People: Who owns the system, who reviews outputs and who can stop use?
- Data: What input data is used, who controls it and what quality checks apply?
- Monitoring: What issues, complaints, overrides and incidents are tracked?
- Logs: What records prove how the system was used and reviewed?
- Transparency: Who must be told about AI use, and how can they challenge an outcome?
Build an approval-ready AI deployment checklist
Conclusion
For SMEs, EU AI Act deployer compliance is mainly an operating discipline. The work is to know which systems are in use, classify the risk, follow provider instructions, assign human oversight, control input data, monitor operation, preserve useful logs and connect the record to data protection and incident handling. If those basics are mapped before launch, approval becomes faster and future audits become less painful.
Want to find the practical AI opportunity?
If this topic is part of a real workflow decision, we can help you identify where AI will save time, where it creates risk, and what needs governance before rollout.
