EU AI Act for SMEs: What to Settle Before 2 August 2026

Introduction

On 2 August 2026, the heaviest part of the EU AI Act becomes enforceable. That is roughly ten weeks away from writing this post. For Dutch and European SMEs using AI in their product, customer service or internal software, this is no longer an abstract Brussels topic. It is a concrete deadline with concrete obligations and concrete fines.

In conversations with our clients we see two extremes. On one side, business owners who assume the Act only applies to Big Tech. On the other, owners panicking because they heard somewhere that all AI is being banned. Neither is true. The Act is nuanced, and most SME use cases fall into a light category. But those that fall under the stricter rules have serious work to do before August.

What the AI Act actually regulates

"The AI Act does not regulate technology. It regulates use cases. The same model can fall under minimal risk in one context and under high risk in another."

— Summary of Article 6 and Annex III, EU AI Act

The AI Act is a European regulation that classifies AI systems by risk and attaches different obligations to each tier. Four categories: unacceptable risk (banned), high risk (heavily regulated), limited risk (transparency obligations) and minimal risk (no obligations). The Act looks at the purpose and impact of the system, not at the underlying technology. A simple rule-based scoring system deciding on mortgage applications falls into the same category as a sophisticated neural network doing the same thing.

For SMEs that distinction is crucial. A chatbot answering FAQ questions falls under limited risk: you must make clear to the user that they are talking to an AI. A recommendation engine in your webshop typically falls under minimal risk: in principle no obligations. An algorithm screening job applicants or scoring customer credit falls under high risk: that is where the heaviest obligations begin.

When the Act really affects your SME

The Act defines two main roles: provider and deployer. A provider develops an AI system or has it developed and places it on the market under their own name or brand. A deployer uses an existing system within their own operations. Most European SMEs are deployers. They use Microsoft Copilot, ChatGPT Enterprise, Salesforce Einstein or a regional SaaS with AI features. For deployers of low-risk systems, the Act is mainly a transparency and governance exercise.

It changes the moment you commission custom software in which AI plays a role. Then your builder potentially becomes a provider, and you potentially become a deployer of a high-risk system. It also changes if you substantially modify an existing tool or deploy it for a new purpose. A company using a customer service chatbot to screen job applicants changes role under Article 25. You then become a provider yourself, with all the associated obligations. This is exactly the kind of transition SMEs slip into without a legal review.

For MG Software clients: if we build an AI feature where decisions about end users are made or materially influenced, we design the system from sprint one with provider obligations in mind. That saves hundreds of hours of documentation retrofitting later.

Annex III: when your system is high-risk

Annex III lists eight categories where AI systems automatically count as high-risk once they make or materially influence decisions about people. The most relevant for SMEs are: employment and HR, access to essential services such as credit and insurance, biometric identification and, in some cases, education. Logistics optimization, inventory management, marketing segmentation and internal productivity tools usually fall outside Annex III.

A few concrete examples from our client base. A SaaS scoring CVs for recruiters: high-risk under Annex III section 4 (employment). A platform that uses machine learning to decide which customer qualifies for instalment payment: high-risk under Annex III section 5 (essential services, credit scoring). A dashboard that uses AI for sales forecasting for the buyer: not high-risk, because it influences no decision about a person. A customer service chatbot: limited risk, transparency obligation only.

The dangerous grey area sits in tools that hover at the edge. A personalised insurance quote computed by AI can fall under Annex III. A dynamic price calculator for a webshop does not. The difference is whether the outcome materially affects an individual in a domain the Act protects. When in doubt, document the reasoning and have it reviewed by a lawyer.

The seven documentation requirements you need by August

For each high-risk system the Act prescribes seven concrete obligations, set out in Articles 9 through 15. They are not optional and they are interconnected. Building them in during construction is a workable amount of effort. Bolting them on after the fact often takes weeks.

One: a risk management system that runs across the entire lifecycle (Article 9). The system must identify known and reasonably foreseeable risks and reconsider them periodically. Two: data governance (Article 10). You must be able to demonstrate where training, validation and test data come from, whether bias exists, how representativeness is ensured and how personal data has been handled. Three: technical documentation (Article 11). Annex IV provides a detailed table of contents: system architecture, design choices, hardware requirements, monitoring and evaluation metrics.

Four: automatic logging (Article 12). The system must record operational behaviour in a way that is traceable for regulators. Five: transparency to deployers (Article 13). The user manual must make clear what the system can and cannot do, what the known limitations are and how to use it correctly. Six: human oversight (Article 14). The architecture must make human intervention practically possible, including a kill switch. Seven: accuracy, robustness and cybersecurity (Article 15). The system must perform measurably, be resilient against errors and protected from attempts to manipulate its outputs.

For our clients we now deliver these seven blocks as a standard pack. Risk register in Markdown inside the repo, datasheets per dataset, a Notion or Confluence template for Annex IV, structured audit logs in a separate database, a user manual generated from code and docs, a human-in-the-loop interface where required, and automated tests for accuracy drift. Not sexy, but defensible in front of enterprise buyers and in front of regulators.

Five typical SME scenarios and what to do

Scenario one: you use ChatGPT Enterprise for internal productivity. Limited risk. Arrange transparency for employees, set up an internal AI policy. No high-risk obligations. Time investment: a few days.

Scenario two: you commission an AI chatbot for customer service. Limited risk, provided it does not decide on essential services. Show on the first interaction that it is AI. Log conversations for quality. Define an escalation path to a human. Time investment: a few weeks during design.

Scenario three: you build a SaaS where an AI component screens job applicants. High-risk. All seven obligations apply. Obtain CE marking through a notified body or internal control. Register in the EU database for high-risk systems. Time investment: months, ideally built in from the start.

Scenario four: you sell insurance and use machine learning for per-customer premium calculation. High-risk. Document historical training data, monitor sensitive attributes, make premium decisions explainable to the customer. Work with the actuarial team on data quality. Time investment: substantial, particularly data governance.

Scenario five: you commission a logistics dashboard with AI for route optimization. Minimal risk, provided it does not evaluate individual workers. No obligations under the AI Act. Still wise to arrange explainability and monitoring, because client trust and auditability remain important.

Fines and what enforcement looks like in practice

The Act has a three-tier fine structure set out in Article 99. Up to 35 million euros or 7 percent of global annual turnover for prohibited practices such as social scoring or manipulative techniques. Up to 15 million euros or 3 percent for failing to comply with high-risk obligations. Up to 7.5 million euros or 1 percent for providing incorrect information to regulators. Member states may apply reduced caps for SMEs, but the concept is clear: serious violations are treated seriously.

More important than the theoretical maxima is what enforcement looks like in practice. Investigations rarely start on the regulator's own initiative. They almost always begin with a complaint: from a rejected job applicant, an unhappy customer, a former employee, a journalist or a competitor. On top of that, enterprise buyers increasingly demand AI Act compliance as a procurement requirement. A software vendor without credible documentation will lose tenders to larger clients well before any fine appears.

In the Netherlands the Autoriteit Persoonsgegevens is the designated coordinating authority for algorithms and AI. Sector regulators such as the AFM (financial) and NZa (healthcare) cover their own domain. In practice that means requests for documentation and proactive audits can arrive via different routes.

Practical checklist for 2 August 2026

Start with an AI inventory. Which AI systems do you use, in which processes, and what is the outcome per user? Without that overview no risk assessment is possible. We do this for clients in half a day with a structured interview and a code review. Then classify the risk level per system: prohibited, high, limited or minimal. Document the reasoning, even when the outcome is minimal risk.

For each high-risk system, start the seven Article 9-15 tracks in parallel. Appoint an internal owner: not IT, not legal, but someone who can translate between both. Plan time for CE conformity assessment. Register in the EU database once the system goes live. Define and rehearse an incident response procedure. Train your staff, both the builders and the users.

Do not forget external contracts. If you procure AI from a vendor, your contract should clearly allocate liability and documentation duties. Many existing SaaS contracts are silent on this. Amending them takes time and vendor goodwill. Start with that before you discover in July that your supplier cannot deliver what you need.

How we build AI Act compliant systems

At MG Software we start every AI project with a risk classification during the discovery phase. It typically takes two to four hours and determines whether we design for light compliance (transparency, logging) or heavy compliance (all seven obligations). Architecture, model selection and the data layer are tuned to that outcome. We do not build high-risk systems on a black-box API without logging capabilities. We choose models where we can record the inputs and outputs.

Documentation is not something we write at the end of a project. Annex IV fields are filled in during sprints, at the same moment the feature is built. The risk analysis sits in the same repo as the code. Datasheets sit next to the migrations. The user guide sits in the docs folder. At delivery, clients have both a working system and a compliance pack that survives an audit.

Do you have an existing AI system without clear documentation? Then we run a compliance audit with a concrete remediation plan and a timeline towards 2 August 2026. We map what is missing, estimate the effort and often implement the fixes. For a quick indication of scope and cost, use our project calculator or book a conversation directly.

Conclusion

The EU AI Act is not a reason to remove AI from your business. It is a reason to handle AI more maturely. For most SME use cases the burden is limited and the workload reasonable. For high-risk systems it is serious work, but work that pays back in more reliable systems and in credibility towards customers and partners.

The 2 August 2026 deadline is hard. Those who start now have time to do it right. Those who wait until July will end up with rushed documentation, last-minute architecture choices and the real risk that an important client or regulator intervenes earlier than expected. Compliance is not a cost if you build it in early. It is then simply part of good engineering.