The EU AI Act applies differently by role and use case. Providers of high-risk systems and providers of general-purpose AI models can face extensive obligations, while deployers and other actors have different duties.
But SMEs still need a working governance model. If your company uses AI in hiring, customer service, document processing, sales, support, marketing, software development, or internal decision support, the question is not “are we a regulated AI company?” The question is “which AI systems do we use, what risk do they create, and who is responsible for using them safely?”
This is a practical preparation plan for SMEs. It helps organize the facts counsel and accountable owners need; it does not replace classification or advice.
Treat AI Act readiness as an operational inventory problem first. If you cannot list your AI systems, vendors, users, data categories, decision impact, and human oversight rules, you are not ready to classify risk or prove responsible use.
The timeline that matters
The EU AI Act (Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744) applies in phases; the dates below were re-verified 2026-08-04 against the Commission’s AI Act page and AI Act Service Desk timeline. The Act entered into force on 1 August 2024. Prohibitions, definitions, and the then-applicable AI-literacy provisions started applying from 2 February 2025; governance and general-purpose AI model obligations became applicable on 2 August 2025. The AI Omnibus entered into force on 27 July 2026 and amended parts of the timetable and literacy framework. Article 50 transparency rules apply from 2 August 2026.
The final AI Omnibus timeline has rules for systems used in certain high-risk areas such as biometrics, critical infrastructure, education, employment, migration, asylum, and border control applying from 2 December 2027, while high-risk systems embedded into regulated products apply from 2 August 2028. Because these dates have already shifted once, check the Commission page before committing budget to a compliance deadline.
What non-compliance actually costs
The penalty framework is one input, not a substitute for determining scope. The tiers below are based on Article 99 and require counsel to confirm how the amended framework and national rules apply:
- Prohibited practices under Article 5: up to €35 million or 7% of worldwide annual turnover, whichever is higher. The definitions and exceptions are detailed; labels such as “manipulation” or “biometrics” are not a complete legal classification.
- Most other obligations, including the high-risk requirements and transparency duties: up to €15 million or 3% of turnover.
- Supplying incorrect or misleading information to authorities: up to €7.5 million or 1% of turnover.
Two SME-relevant provisions affect the framework: for SMEs and startups each cap applies as the lower of the fixed amount and the percentage, and authorities must apply the Regulation’s penalty factors and proportionality rules. Do not treat an informal label as proof that a practice is prohibited or permitted: stop any possible Article 5 use and obtain qualified classification. An inventory helps identify scope; it does not keep an organization out of it.
Who supervises this in Estonia
The Consumer Protection and Technical Regulatory Authority (TTJA) says it will serve as Estonia’s competent authority for AI-system supervision. The detailed institutional setup and local enforcement practice are still developing (verified 2026-07-28). What that means practically for an Estonian SME right now: build to the Regulation’s text rather than waiting for case history, keep your inventory and vendor evidence ready, and prepare now for the Article 50 transparency duties that apply from 2 August 2026.
Use those dates as planning inputs, not as a substitute for legal confirmation. The practical point for SMEs is simpler: start now, because inventory, ownership, documentation, and human oversight take time to build.
Provider, deployer, or buyer?
“Buyer” is a useful procurement label but not a substitute for an AI Act role. An SME can be a provider, deployer, importer, distributor, product manufacturer, authorized representative, or affected person depending on the facts. The simplified table below is triage only:
| Role | What it means | SME example | Practical duty |
|---|---|---|---|
| Buyer (informal) | You procure a tool with AI features | CRM assistant, meeting summarizer, coding assistant | Determine the actual legal role; perform vendor due diligence and set internal use rules |
| Deployer | You put an AI system into use in your business | Support triage, lead scoring, HR screening workflow | Oversight, monitoring, disclosure, records |
| Provider | You place an AI system on the market under your name | AI chatbot product, scoring API, industry tool | Product compliance, technical documentation, risk management |
An organization can hold more than one role. A company that buys a model API, wraps it in an industry-specific product, and sells it to customers may have provider and other operator roles. A company that uses a SaaS chatbot internally may be a deployer. Counsel must classify the actual system, substantial modifications, name/brand, purpose, and supply chain.
Do not guess this in a meeting. Put every AI system in an inventory and classify the role.
Build the AI inventory
Start with a spreadsheet. Every AI system gets one row:
| Field | Why it matters |
|---|---|
| System name | People need a shared label |
| Vendor or owner | Someone must answer questions |
| Business purpose | Risk depends on intended use |
| Users | Internal staff, customers, applicants, public |
| Data categories | Public, internal, personal, confidential, restricted |
| Output use | Draft, recommendation, automated decision, customer-facing answer |
| Human oversight | Who checks it and when |
| Disclosure | Whether people are told they are interacting with AI |
| Logs | What evidence exists after use |
| Risk rating | Low, limited, possible high-risk, prohibited/not allowed |
This inventory is more valuable than a policy document nobody reads. It shows where AI actually exists in the company.
Classify practical risk
Do not start by asking “is this high-risk under Annex III?” Start with operational impact:
Low-risk assistance. Drafting emails, summarizing internal meetings, brainstorming, editing text. Human uses output as a draft. Normal privacy rules apply.
Limited-risk interaction. Chatbots, voice agents, AI-generated media, public text or support responses. Disclosure and user clarity matter.
Decision-support workflows. Lead scoring, support routing, invoice handling, quality review, fraud flags. Human oversight, monitoring, and appeal paths matter.
Potential high-risk areas. Employment, education, credit, essential services, healthcare, law enforcement, migration, critical infrastructure, biometric categorization. Legal review required before deployment.
Possible prohibited practice: stop and escalate. Do not deploy a use that may fall within Article 5 while waiting for an internal “approval.” Qualified counsel must determine scope; an internal approval cannot make a prohibited practice lawful.
This is not a final legal classification. It is the triage that tells you where expert review is needed.
Minimum SME governance controls
For each non-trivial AI system, require six controls:
- Owner. One named person or team accountable for the system.
- Use boundary. What the system may and may not be used for.
- Data rule. What data can enter the system.
- Human oversight. Which outputs need review before action.
- Monitoring. How errors, complaints, drift, and vendor changes are noticed.
- Record. What evidence is kept: vendor docs, prompts, settings, approvals, logs, test results.
These controls address concrete failure modes: missing ownership, unknown data flows, ineffective oversight, and inability to reconstruct why an output was used. Their presence does not itself establish compliance or effectiveness; test and audit them.
Vendor due diligence
For vendor tools, ask for evidence rather than promises:
- Is customer data used for training by default?
- Where is data processed and stored?
- What retention controls exist?
- Are enterprise settings available for training opt-out, logging, SSO, and access control?
- Does the vendor provide AI Act, GDPR, security, and subprocessors documentation?
- Can the AI feature be disabled or scoped?
- Does the vendor disclose model providers and major architecture changes?
- What happens if the vendor changes model, prompt, or retrieval behavior?
If a vendor cannot answer these questions for a tool that will process customer, employee, or confidential data, keep the use case low-risk or choose another tool.
Disclosure and human oversight
For customer-facing AI, disclosure should be simple and visible. If a customer is talking to an AI chatbot or voice agent, say so. If AI-generated text is sent by a person after review, internal policy should decide whether disclosure is needed for that channel.
Human oversight must be specific. “A human is in the loop” is not enough. Define:
- What output the human sees.
- What source evidence they can inspect.
- Whether they can override or reject.
- How much time they have.
- Whether approval is logged.
- What happens when the human disagrees with the system.
Oversight without authority is theatre. If the human cannot stop the action, they are not meaningful oversight.
A 30-day SME rollout
Week 1: Inventory. List every AI tool and workflow. Include unsanctioned tools people actually use.
Week 2: Risk triage. Classify low, limited, decision-support, possible high-risk, or not allowed. Escalate possible high-risk.
Week 3: Controls. Add owner, data rule, oversight rule, disclosure rule, logging rule, and vendor evidence for each active system.
Week 4: Policy and training. Draft a short internal AI-use policy and deliver role-appropriate training. Duration and content should follow the systems, users, risks, and current legal requirements—not a universal session length.
This can create a governance baseline and a list of unresolved gaps. It is not enough by itself to establish AI Act or GDPR compliance.
Do not do this yet
Do not let a compliance-platform purchase substitute for an inventory and requirements. If tooling is evaluated earlier, test it against a representative inventory and required evidence.
Do not allow department policies to conflict silently. Establish an accountable organizational baseline and reconcile necessary department-specific rules with it.
Do not treat vendor terms as governance. A vendor contract does not tell your sales team what they may paste into a model.
Do not wait for perfect regulatory certainty. Timelines and guidance can move, but inventory, ownership, data rules, oversight, and logging will still be needed.
A governance habit, not a panic project
AI Act readiness for SMEs is not a panic project. It is a governance habit.
Start with the inventory. Classify risk by use case. Keep humans responsible for meaningful decisions. Require vendor evidence. Document the controls. Escalate employment, credit, health, education, essential services, biometric, and rights-impacting uses before launch.
These steps create evidence and ownership for qualified legal, security, privacy, and domain review. They do not by themselves establish compliance.
