For SMEs, the AI Act starts with a practical question: which AI application are you using, for what purpose and under whose responsibility? That determines the rules you need to assess. A writing assistant, applicant screening and customer chat each need different checks. Start with the task, as described in our AI automation guide, then include the legal assessment in your decision. Our explanation of AI consultancy helps define what needs investigating.
Sources checked on 25-09-2026. This guide covers the EU AI Act for businesses in the Netherlands, not UK law. Assess your particular application against its actual use and the current legislation.
What does the AI Act mean for a small business?
The AI Act sets rules for providing and using AI. Your first assessment concerns your role, the application’s purpose and the people who could be affected by its output. A product name isn’t enough: features within the same package can have different tasks and consequences.
Use this guide to identify the questions you need to resolve. It isn’t a declaration that an application complies. The suggested working file below is our practical approach; every document listed isn’t necessarily a separate legal requirement for every business.
Are you a deployer, a provider or both?
An organisation using an AI system under its authority is a deployer, called a gebruiksverantwoordelijke in Dutch. A provider develops or commissions a system and places it on the market or puts it into service under its own name or trademark. Commissioning development can therefore matter too. These roles are defined in Article 3 of the AI Act.
When buying software, ask who holds each role for the application you’re discussing. “The supplier handles the AI Act” isn’t a division of responsibilities. You need to know who describes the function, which limits apply to its use and who to contact if its behaviour changes.
Consider a fictional installation company. It buys an assistant to draft emails and is also considering a customer portal with AI-generated answers. Those require separate assessments. Using the same underlying model doesn’t give them the same purpose, users or responsibilities.
For custom development, establish whose name the system will operate under before signing the agreement. Source code ownership and your role under the AI Act are different questions. Our guide to code ownership and supplier dependency deals with the former.
How do you identify the relevant risk rules?
Describe the intended use precisely enough for someone else to assess it. “Supports HR” says very little. “Ranks applicants so a recruiter can decide whom to interview” explains what the output does. Recruitment, selection and certain employment decisions appear in Annex III.
| Example function | First assessment question | Practical evidence to gather |
|---|---|---|
| Email draft for an employee | Who reads and sends the text? | Work instructions and an example review |
| Website chat giving product information | Does the visitor understand they’re talking to AI? | Visible notice and conversation test |
| Applicant ranking | Does the score affect who gets selected? | Purpose, criteria and supplier assessment |
| AI feature within a product | Which product legislation and safety function matter? | Product documentation and specialist classification |
These are starting questions, not automatic classifications. Annex III has conditional exceptions, such as certain preparatory tasks without a material influence on decisions. Profiling people within that annex doesn’t qualify for the exception. “A human looks at it” isn’t sufficient reasoning on its own. See Article 6.
Check prohibited uses separately. Inferring emotions at work with an AI system intended for that purpose is prohibited, for example, with exceptions for medical or safety reasons. This concerns emotion recognition as legally defined, based on biometric data, rather than every analysis of written feedback. See the prohibited practices and the definitions in Article 3.
Have uncertain cases assessed before using them with real applicants, employees or customers. Keep a record of the unanswered question. An open item with an owner and next step is more honest than a green status based on a sales conversation.
Which dates apply after the 2026 amendment?
The AI Omnibus is enacted legislation. Regulation (EU) 2026/1744 was published in the Official Journal on 24-07-2026 and entered into force on 27-07-2026. The European Commission confirms its entry into force. Some individual article pages still display older text; read them alongside the amending regulation and the updated official timeline.
| Provision | Relevant date |
|---|---|
| Original prohibitions and AI literacy | Since 02-02-2025; Article 4 has since changed |
| Article 50 transparency | Since 02-08-2026 |
| High-risk requirements, Chapter III Sections 1 to 3, Annex III | 02-12-2027, except Article 6(5) |
| Those same sections for Article 6(1) and Annex I | 02-08-2028 |
Providers of generative systems placed on the market before 02-08-2026 have a transition until 02-12-2026 for Article 50(2). That specific arrangement is in amended Article 111(4). This doesn’t postpone all of Article 50. The Commission confirms that transparency rules have applied since August.
This table selects relevant provisions; it doesn’t cover every rule or transition. For existing systems, have the original introduction and later changes assessed too. Schedule a fresh source check before deployment, so an earlier memo doesn’t silently become permission to use a different version.
When must you make AI use clear?
Providers of systems that interact directly with people must ensure people are informed, unless the use of AI is already obvious to a reasonably informed, observant person in that context. Deployers have disclosure duties for deepfakes. For AI-generated text published to inform the public on matters of public interest, an exception can apply after human review or editorial control, provided a natural or legal person holds editorial responsibility. This isn’t a blanket labelling duty for every AI-assisted text. See Article 50.
Make the assessment tangible. Open the customer chat on a phone and a larger screen. Check whether the notice is visible and understandable at the start of the interaction. An explanation buried in a general privacy statement doesn’t establish what the visitor actually sees.
Distinguish a visible message from technical marking. The Commission separates informing people, machine-readable marking and disclosure. Ask the supplier which function belongs to which party and how you’ll check the result. Don’t assume a line of text under your chatbot also deals with a model or system provider’s obligations.
A useful acceptance test covers the opening greeting, a follow-up message and transfer to an employee. Can the visitor see when a person takes over? Keep the findings with the version tested. After an update, you can then check whether the explanation still appears in the right place.
What does AI literacy require from your team now?
The amended Article 4 requires measures supporting the development of AI literacy. It doesn’t mandate a guaranteed individual knowledge level or a compulsory certificate. The Commission’s updated answers explain the change. Adapt your approach to the tasks, experience and context of the people using the system.
For the fictional installation company, an exercise might use a convincing draft email containing an incorrect product promise. Ask employees which source they would check and when they should change the wording. Give the administrator a different task: identify the instructions, source version and settings associated with that answer.
Keep a short record of what you did and what remained unclear. Include the examples discussed, the roles involved and any follow-up agreed. This helps you support a new employee or introduce a changed feature. An attendance sheet alone says little about the difficulties people encounter at work.
Does every small business need a FRIA?
No. A fundamental rights impact assessment, or FRIA, has a specific scope. It covers, among others, bodies governed by public law and private organisations providing public services that use certain high-risk AI systems, plus certain creditworthiness and life or health insurance applications. Check the precise scope and exceptions in Article 27. In its FRIA announcement of 17-08-2026, the Dutch data protection authority, AP, calls on organisations to start preparing now.
A FRIA and a data protection impact assessment, or DPIA, are different assessments. Record who will determine which assessment is required and what information is missing. This article addresses the AI Act; questions about personal data under the GDPR need their own review alongside it.
Even where a FRIA duty hasn’t been established, you can examine who might suffer from an incorrect output. For the installation company, consider someone receiving unfavourable treatment because an automated assessment is wrong. Write down how the error would be found, who could intervene and how the person could ask for a review. Don’t present this internal exercise as a formal FRIA if it isn’t one.
What working file helps you trace decisions?
Keep a short, useful file for each application. Our suggestion is to store the following items together and assign an owner to each unresolved point. The amount of detail should follow the use. A standard folder full of unused documents doesn’t help whoever manages the system.
- Task and boundary: what does the feature do, for whom, and what mustn’t it decide?
- Role and classification: what assessment was made, by whom, against which version and source?
- Supplier information: contact, operating instructions, limitations and agreements about changes.
- Practical testing: examples of correct, incorrect and unclear outputs, with the agreed response.
- Management: who receives reports, can stop the feature and decides when it may resume?
For answers based on your documents, source management belongs here too. A new manual can invalidate an earlier answer. Our explanation of AI using your data and RAG covers that technical issue. An architecture choice doesn’t replace the legal assessment.
During a supplier demonstration, ask to work through one of your own exceptions. What happens when a source is missing, an output is disputed or an employee rejects a suggestion? Record what you actually observed. A roadmap promise needs a different status from a working feature.
How do you actually get started?
Choose one application already in use or due to be introduced. Describe its purpose, users and the consequences of an error. Gather the supplier documentation and appoint someone to arrange checks of the role, risk assessment and applicable dates.
Then turn open questions into work: test a notice, organise an exercise for employees or request legal advice on a particular classification. Agree which changes trigger a new assessment. That gives the working file a place in day-to-day management.
Want to clarify the technical operation and responsibilities first? Bring an example process and the documentation you have. Book a call.
