EU AI Act documentation: template for SMBs

Most Swedish SMBs assume EU AI Act documentation means hundreds of pages of technical text. That is true only for a small group. For everyone else it comes down to three simple records that take an afternoon to fill in. This guide shows exactly what you must document based on your role, and gives you a free template to start from.

What does the EU AI Act require Swedish SMBs to document?

For most Swedish SMBs, EU AI Act documentation means three things: a register of your AI systems, a log of staff AI literacy, and a note of where you tell users they are dealing with AI. The full technical documentation applies only to high-risk providers.

The law is Regulation (EU) 2024/1689 and entered into force on 1 August 2024. It classifies AI systems into four risk categories, and the documentation burden grows with the risk. Since roughly 95 percent of Swedish SMBs use AI in the minimal or limited risk band, their documentation is light: prove you have an overview, not that you built a certified system.

The mistake we see most often is that companies either ignore documentation entirely, or launch a huge project as if they were a MedTech firm. Both are wrong. The right level of EU AI Act documentation is decided by two questions: what is your role, and what risk class is the system?

Which documentation do you need based on your role?

Your role decides everything. If you are a deployer (you use a finished AI tool), a register, literacy log and transparency record are enough. If you are a provider (you build or put your name on a high-risk system) full technical documentation under Annex IV is added.

The difference is large and often misunderstood. Using ChatGPT, a customer-service chatbot or AI embedded in your CRM makes you a deployer, not a provider. Then you have no obligation to produce technical product documentation. If you instead build your own recruitment or credit-scoring system, or buy a white-label system you resell under your own name, you become a provider with considerably heavier requirements.

Using an AI tool and building one are two completely different legal roles. Confuse them and you either under-document or document fully for no reason.

A quick test: do you put your own brand on the AI system, or materially change how it works? Then you are likely a provider. If you buy a finished service and use it as is, you are a deployer, no matter how advanced the technology behind it. Borderline cases, such as fine-tuning your own model on your data, should be checked with a lawyer before you decide the documentation level.

Before documenting anything you therefore need to classify your systems. We have a separate walkthrough of how to risk-classify your AI systems step by step, which is the natural first step before this template.

What should an AI system register contain?

An AI system register is a simple table listing every AI system you use or provide, its purpose, your role, its risk class and the action required. It is the foundation of all EU AI Act documentation and should exist even if no system is high risk.

The register is not a formal legal requirement for minimal-risk systems, but it is the documentation that ties everything else together and the first thing an auditor or authority will ask to see. List broadly: AI agents, chatbots, customer-service automation, internal productivity AI such as ChatGPT and Copilot, predictive analytics, marketing AI and AI embedded in SaaS tools you already pay for.

For each system you note:

1. System and provider: what it is called and who supplies it
2. Purpose: what you use it for, concretely
3. Your role: deployer or provider
4. Risk class: prohibited, high, limited or minimal
5. Action: what is done or needs doing

Keeping the register updated as new tools come into use matters more than how polished it looks. A spreadsheet that is actually maintained beats a perfect PDF nobody touches.

How does a typical SMB fill in the register?

Most SMBs land on three to five systems in their register, usually a customer-service chatbot, internal productivity AI and something embedded in a SaaS tool. A concrete example makes clear how simple EU AI Act documentation actually becomes in practice.

Take a Swedish e-commerce company with ten employees and three AI systems. System one is a customer-service chatbot from an external provider. Role: deployer. Risk: limited, because it interacts directly with customers. Action: add a transparency disclaimer under Article 50 on the first reply.

System two is ChatGPT, which the team uses for product copy and email drafts. Role: deployer. Risk: minimal. Action: record the tool in the AI literacy log and in the internal policy on approved tools. No further requirements apply.

System three is a tool that assesses installment-payment risk at checkout. Role: deployer. Risk: potentially high, because credit scoring of individuals sits in Annex III. Action: check the provider's documentation, assign a named human oversight and ensure the logs are kept for at least six months.

The whole exercise takes an afternoon, and the result answers the three questions an authority, customer or investor will ask: which AI systems do you have, what risk do they carry, and what have you done about it. Note that only one of three systems, the credit tool, triggers heavier requirements. That is typical. Most rows in an SMB register land in minimal or limited risk, which is exactly why the documentation stays manageable once you have classified correctly.

Must you document staff AI literacy?

Yes. Article 4 on AI literacy applies to everyone who uses or provides AI and has been in force since 2 February 2025. You must ensure staff have sufficient AI literacy, and without documented training you cannot prove the requirement is met.

This is the part most companies miss, precisely because it already applies and is not waiting for some future deadline. The requirement is deliberately flexible: the level should be proportionate to how you use AI and who is affected. For a small company using ChatGPT internally, a short internal training plus a simple policy on which tools are approved is enough.

What you need is a log: who was trained, when, and what the training covered. One row per staff group is enough. The point is not bureaucracy but provability. If asked, you should be able to point to a date and a scope, not say "we talked about it in a meeting".

When is transparency documentation required?

Article 50 requires you to inform users when they interact with AI or consume AI-generated content. It covers chatbots and AI agents, deepfakes, and AI-generated text published to inform the public. Document where and how you inform them.

For most SMBs this means one thing in practice: the chatbot or AI agent on your site must state that it is AI on first contact. One sentence is enough, for example "You are chatting with an AI assistant. Type 'human agent' to reach a person." The transparency record simply notes which system it concerns, what type of disclosure is required, and where the text appears.

If you generate images, audio or video that are deepfakes, or AI text about news and public-interest matters, labelling requirements are added. That is unusual for ordinary SMBs but worth knowing if you work with marketing content. This kind of transparency follows the same principle we built into Eteya's guide to the EU AI Act for Swedish companies.

What applies to deployers of high-risk systems?

If you are a deployer of a high-risk system (Annex III, such as recruitment or credit-scoring AI) obligations under Article 26 are added: named human oversight, monitoring of operation, and keeping the system's automatic logs for at least six months.

This is a smaller group of SMBs, but the requirements are concrete and provable. You must be able to name a person with the right competence and authority to intervene, describe how you monitor the system, and show the logs are kept. According to analysis from IAPP, it is exactly this evidence, named oversight and stored logs, that most deployers lack as the requirements approach.

A small subset must also carry out a fundamental rights impact assessment, FRIA, under Article 27. It applies to public bodies, private actors providing public services, and deployers of AI for credit scoring or life and health insurance. If none of that applies to you, you can skip the FRIA entirely.

How long must the documentation be kept?

If you build high-risk systems as a provider, the technical documentation must be kept for ten years after the system is placed on the market (Article 18). As a deployer of high-risk systems you keep the system's logs for at least six months (Article 26.6). For minimal-risk systems there is no formal requirement, but a living register is good practice.

The technical documentation for high-risk providers follows Annex IV and covers system description, data governance, performance, risk management and logging under Article 12. SMEs and startups may supply it in simplified form, and the European Commission is to produce a simplified template. Until it is published, covering the Annex IV headings proportionately to your size is enough.

Set a recurring review date, at least once a year and at every change in the law. EU AI Act documentation is not a one-off task but a living record that should reflect the systems you actually run.

What are the most common EU AI Act documentation mistakes?

The three most common mistakes are over-documenting as an ordinary deployer, forgetting the AI literacy log even though Article 4 already applies, and treating documentation as a one-off task instead of a living register that follows the business.

The first and most expensive mistake is documenting as if you were a provider. A company that only uses finished AI tools sometimes launches a full Annex IV project it does not need, with weeks of wasted work. Classify the role first, document accordingly.

The second mistake is skipping the AI literacy log. Because Article 4 is not waiting for any future deadline, it is easily forgotten in the rush toward high-risk requirements. It is at the same time the easiest part to fix, and often the first a counterparty asks for because it already applies.

The third mistake is seeing documentation as finished. A register that reflects last year's tools is worthless. New AI features appear in SaaS tools you already pay for, often without anyone actively choosing them. Without a recurring review date the register stops being accurate within months, and the whole point is lost.

Do you need an AI policy beyond the register?

Yes, for most SMBs a short internal AI policy is a natural complement to the documentation. The register describes what you have, while the policy governs how staff may use AI. Together they cover both EU AI Act documentation and practical governance.

The EU AI Act does not require a formal policy as such, but Article 4 on AI literacy is hard to meet without one. A one-page policy goes a long way: which tools are approved, which data must never be entered into public AI services, and who to ask when in doubt. It is the same principle as an information-security policy, but for AI.

The policy also solves the most common practical problem, shadow AI. When staff use tools nobody approved, they fall outside the register and outside your control. A clear policy with a simple route to propose new tools keeps the register current and reduces the risk that an unknown system breaches transparency or data-protection rules. The policy and the register should therefore be reviewed together.

When do the requirements start to apply?

Prohibited practices, GPAI rules and AI literacy (Article 4) already apply today. The high-risk requirements were set for 2 August 2026, but under the provisional Digital Omnibus agreement standalone Annex III systems are to be deferred to 2 December 2027. It is not yet formally adopted.

The practical advice is therefore simple: plan for 2 August 2026 until the postponement is published in the EU Official Journal. The Council and Parliament agreed on the proposal during spring 2026, but a proposal is not binding law until formally adopted. Starting documentation six months before the deadline is the minimum to make it in time without stress.

Postponing the high-risk requirements changes nothing for the parts that already apply. AI literacy, transparency and the ban on certain practices are unaffected by the Omnibus. For the majority of SMBs, who are mostly touched by exactly those parts, the delay is not a reason to delay the documentation.

Frequently asked questions

Getting started with EU AI Act documentation is easier than most expect, as long as you begin at the right end: classify the systems, fill in the register, log the literacy. The template above gives you the structure. If you need help classifying your systems correctly or building AI that is documented from the start, we are here.