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. The European Commission's own impact assessment expects only 5–15 percent of all AI systems to land in high risk, which the CEPS analysis of the regulation's costs sums up as around a tenth of systems. For the vast majority of companies, the documentation is therefore light: prove you have an overview, not that you built a certified system.

The weight of that gap makes it worth seeing how the requirements actually scale with risk before you open the template:

Risk class	What it is	Documentation requirement
Prohibited	Banned practices under Article 5 (social scoring, manipulative AI)	Nothing to document — the system may not be used at all
High	Annex III applications, e.g. recruitment or credit scoring	Full technical documentation (provider) or named oversight, monitoring and logs for at least 6 months (deployer)
Limited	Chatbots and AI agents that face users	Transparency under Article 50: tell users it is AI
Minimal	Internal productivity AI such as ChatGPT and Copilot	No formal requirement; a register and literacy log are good practice

This escalation is the through-line of the whole article. The rest of the guide shows exactly what each level means for you specifically.

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 between deployer and provider

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. If you are a provider but also a smaller company, you may file the technical documentation in simplified form, and any fines are weighed against your size — we cover the sanctions and the relief for smaller companies separately.

The dominance of the deployer role is no accident. According to Eurostat, 99 percent of EU enterprises are micro and small enterprises, and the vast majority buy finished AI rather than build their own. That is why the lighter documentation is the norm and the provider requirements the exception.

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.

The two roles carry two completely different documentation burdens:

Role	You are this if...	Documentation required	Example
Deployer	you use a finished AI tool as it is	Register, literacy log and transparency record	ChatGPT, customer-service chatbot, AI embedded in your CRM
Provider	you build or put your name on a high-risk system	All of the above plus full technical documentation under Annex IV (simplified form for smaller companies)	Own recruitment or credit-scoring system, white-label system you resell

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.

The fields the register needs

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.

A worked example: e-commerce with three systems

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.

Filled in, the e-commerce company's register becomes a single, scannable table — exactly the format you should copy:

System and provider	Purpose	Role	Risk class	Action
Customer-service chatbot, external provider	Answer common customer questions on the site	Deployer	Limited	Transparency disclaimer under Article 50 on the first reply
ChatGPT	Product copy and email drafts	Deployer	Minimal	Recorded in the literacy log and the approved-tools policy
Installment-payment risk tool at checkout	Assesses credit risk for individuals	Deployer	Potentially high	Review the provider's documentation, named oversight, keep logs for at least 6 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 the literacy log should contain

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.

When a fundamental rights assessment is added

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?

Providers of high-risk systems keep the technical documentation for ten years after the system is placed on the market (Article 18). Deployers of high-risk systems 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.

Taken together, the retention periods look like this:

Document type	Retention period	Source
Technical documentation, high-risk provider	10 years after placing on the market	Article 18
Logs, deployer of high-risk system	At least 6 months	Article 26.6
Minimal-risk system	No formal requirement, annual review as good practice	–

What the Annex IV documentation covers

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 three mistakes broken down

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.

How do you get started in an afternoon?

Set aside four hours and work in four steps: classify your systems by role and risk, fill in the AI system register, document staff AI literacy in the log, and note where your AI touchpoints inform users. Book a yearly review date at the same time, and the base documentation is in place.

The four-hour breakdown

Hour 1: inventory and classify. Gather whoever owns IT and one person who uses the tools daily. List everything with AI in it: chatbots, productivity tools, embedded SaaS features. Determine role and risk class per system following the steps earlier in this guide.

Hour 2: fill in the register. Five columns per system, no more. Keep it short and concrete: "customer service chatbot, external vendor, deployer, limited risk, disclaimer added". A row that can be read in five seconds is the goal.

Hour 3: the literacy log. Note what training staff have already received, even if it is just an internal walkthrough. If nothing exists: book a one-hour internal training within a month and write down the date now. The log is better showing a plan than being empty.

Hour 4: transparency and review. Check that the chatbot introduces itself as AI at first contact, note where the text is shown, and add the next review as a recurring calendar date. Done.

The result is not perfect documentation, but sufficient and provable. That is exactly what the law requires at your level, and it can be improved step by step at every review.

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.