- Two obligations already apply to almost every business using AI: staff AI literacy since 2 February 2025, and transparency since 2 August 2026.
- The high risk duties moved. The AI Omnibus that entered into force on 27 July 2026 pushed standalone high risk systems to 2 December 2027 and AI embedded in regulated products to 2 August 2028.
- Most small businesses are deployers rather than providers, and the duty list is much shorter on that side. Getting this one question wrong is the most expensive mistake in the whole exercise.
- Every obligation discharges through an artefact. If a duty does not produce a document or a change you can point at, you have not done it.
- Fines are capped for small and medium enterprises at the lower of the euro amount and the turnover percentage, which inverts the usual headline reading.
- Several widely shared timeline pages still show the pre Omnibus dates, so verify against the Commission before you plan a quarter around them.
You have established that you are in scope. Now somebody wants a plan, and every summary you find restates the same four risk tiers without telling you what to build. AI Act compliance is not a reading exercise, it is a build list. This piece maps the duties onto artefacts: for each obligation, the document or system change that discharges it, who owns it, and roughly how long it takes.
Start with a warning about dates, because it is the thing most likely to waste your quarter. The schedule changed in 2026. The Commission's own page on the regulatory framework for AI now gives 2 December 2027 for high risk systems in sensitive areas and 2 August 2028 for high risk AI inside regulated products, and notes that the AI Omnibus entered into force on 27 July 2026. Plenty of timeline summaries still carry the original 2 August 2026 date for high risk obligations. Checked on 13 August 2026, the widely linked AI Act implementation timeline still lists the pre Omnibus schedule. Treat any date you did not read on an official page as suspect.
Which two questions actually decide your scope?
Are you a provider or a deployer, and does your output reach people in the EU. Everything else follows from those, and both get answered wrong routinely.
A provider develops an AI system or has one developed and puts it on the market under its own name. A deployer uses one under its own authority. A shop that runs a chatbot built by a vendor is a deployer. The same shop becomes a provider if it puts its name on that system and offers it to others, or if it substantially modifies a high risk system. The duty lists differ enormously, and a small business that assumes it is a provider will spend months building documentation nobody asked it for.
The second question catches non EU companies who assume distance protects them. If the output of your system is used in the EU, you can be pulled in even with no European entity. For most online sellers that is not a hypothetical, it is Tuesday.
What applies to you right now
Two things, regardless of risk tier, and both are already live.
AI literacy. Article 4 requires providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and of others operating systems on their behalf, taking account of their technical knowledge, experience, training and the context of use. It has applied since 2 February 2025. For a ten person business this is not a training budget, it is a written record that the people using these tools were told what the tools do and where they fail.
Transparency. Article 50 requires that people be informed they are interacting with an AI system unless that is obvious to a reasonably well informed person, and requires deployers of systems that generate or manipulate image, audio or video content to disclose that the material is artificially created or altered. Those obligations apply from 2 August 2026, which has passed.
If you run a support chatbot and publish AI generated product imagery, both of those land on you today. Neither requires a compliance department. Both require a decision written down.
The obligation to artefact map
This is the table to work from. The left column is the duty, the middle is the thing that proves you did it, and the right is a realistic build time for a small team rather than for an enterprise programme.
| Obligation | The artefact that discharges it | Owner | Realistic build |
|---|---|---|---|
| AI literacy (applies now) | A one page briefing per tool plus a dated attendance or acknowledgement record | Whoever runs the team using it | A day, then an hour per new tool |
| Interaction disclosure (applies now) | The disclosure line itself, in the first turn of the chat or call, plus a screenshot in your records | Whoever owns the channel | An afternoon |
| Synthetic content marking (applies now) | A labelling rule in your content process, applied to generated images, audio and video | Marketing | A week to apply to existing assets |
| System inventory (prerequisite for everything) | A list of every AI system in use, with purpose, vendor, data touched and provider or deployer status | Operations | Two days, and it will surprise you |
| Risk management system (high risk, from Dec 2027) | A documented, iterative process identifying foreseeable risks and the mitigations chosen | Product | Weeks, not days |
| Data governance (high risk, from Dec 2027) | Written provenance, coverage and bias examination of training and input data | Whoever supplies the data | Weeks, longer if the data is inherited |
| Technical documentation (high risk, from Dec 2027) | A single document describing the system, its purpose, its limits and its testing | Engineering | Weeks, and it is mostly writing down what exists |
| Record keeping (high risk, from Dec 2027) | Automatic logging over the system's lifetime, retained and readable | Engineering | Days to build, ongoing to keep |
| Human oversight (high risk, from Dec 2027) | A named role, a documented intervention path, and evidence it was used | Operations | Days to design, months to make real |
| Post market monitoring (high risk, from Dec 2027) | A plan for collecting and reviewing performance in the field, with a trigger for action | Product | A week to write, permanent to run |
Read the middle column as the test. If a duty on your list does not produce a document, a log or a visible product change, you have written an intention rather than discharged an obligation. That is the same trap we described in the piece on governance without an inventory being theatre, and the row to notice here is the fourth one. The inventory is not a legal requirement in itself. It is the prerequisite that makes every other row answerable.
Do the inventory before you decide you are out of scope. The systems that surprise people are never the obvious ones. They are the CV screening filter inside the hiring tool, which is a named high risk use with its own audit expectations, the scoring in the credit or fraud check, the repricing rule that turned into a pricing decision made about a person rather than a product, and the assistant somebody in marketing connected to the customer database without telling anyone.
How large are the fines, really?
Smaller than the headlines for a small business, and the reason is a provision most summaries skip. Article 99 sets administrative fines of up to 35 000 000 EUR or 7% of total worldwide annual turnover for prohibited practices, up to 15 000 000 EUR or 3% for non compliance with most other obligations, and up to 7 500 000 EUR or 1% for supplying incorrect or misleading information, in each case whichever is higher for an undertaking.
Then comes the part that matters to you. For small and medium enterprises, including start ups, each fine is capped at whichever of the percentage or the fixed amount is lower. The word flips from higher to lower. A large company faces the bigger of the two numbers; a small one faces the smaller. That does not make non compliance cheap, and it does change whether this is an existential risk or a manageable one.
Where do you get an authoritative answer?
The Commission now runs one, which is worth knowing because the secondary commentary on this regulation is enormous and frequently out of date. The AI Act Service Desk and Single Information Platform hosts a Compliance Checker that helps evaluate whether a system meets the Act's requirements, an Explorer for browsing chapters, annexes and recitals, and a contact route for questions, in your own language. The platform says explicitly that it exists to serve the needs of startups and small businesses across the AI value chain.
Use the Compliance Checker before you pay anybody for a scoping exercise. It will not give you a legal opinion and it will tell you, in about fifteen minutes, whether the systems you listed in your inventory are anywhere near the high risk tier. For a large number of small businesses the honest answer will be no, and knowing that changes the size of the project by an order of magnitude.
The backlog, in the order to build it
Six items. The first four apply to everybody in scope and the last two only if the checker sends you into the high risk tier.
One, the inventory. Every AI system in the business, with purpose, vendor, the data it touches and whether you are provider or deployer for it. Nothing else can be answered without this.
Two, the disclosures. Chat and voice channels get a line in the first turn. Generated media gets a label. Both go live before anything else, because they are already required and they take an afternoon.
Three, the literacy record. One page per tool, dated, acknowledged by the people using it. This is the cheapest row on the table and the easiest to forget, because nothing visible happens when you skip it.
Four, the policy. A short written rule about which categories of data may go into which category of tool, and who approves an exception. We published a one page AI policy built around data classes rather than tool names for exactly this, and our own published AI policy shows the same structure applied to a real business, because a policy written around brands is obsolete the week a team switches vendor.
Five and six are the high risk rows: the risk management system and the technical documentation, with data governance, logging, human oversight and post market monitoring hanging off them. If you are here, you have until 2 December 2027 for a standalone system, or 2 August 2028 if the AI sits inside a product already regulated under EU product law. Those look distant. They are two and three budget cycles away, and the data governance row in particular is not something you can start six weeks before a deadline, because it depends on records you either kept or did not.
What deployers owe that providers do not
The asymmetry is worth stating plainly, because it is where a small business saves months. A provider carries the heavy build: the risk management system, the technical documentation, the conformity assessment, the declaration. A deployer's duties are mostly about use. Use the system according to its instructions. Assign human oversight to somebody competent, with the authority to stop it. Keep the logs the system generates, to the extent they are under your control. Watch for problems and tell the provider when you find them. And where the system makes decisions about people, inform them.
Notice what is not on the deployer list. You are not asked to prove how the model was built. You are asked to prove you used it responsibly and could show what happened. Those are records rather than research, which is a completely different order of work, and it is why the provider or deployer question sits at the top of this article rather than in the middle.
The place this breaks down is where a small company quietly becomes a provider without noticing. Rebranding a vendor's system as your own product does it. Substantially modifying a high risk system does it. If either sounds like your roadmap, resolve that question before you build, not after.
What should you ask a vendor before signing?
Most of your exposure arrives through somebody else's software, so the cheapest control you own is a purchase question. Four of them, and any vendor selling into Europe should have the answers ready.
Ask which role they take for the system, provider or deployer, and get it in writing. Ask whether they classify the system as high risk under Annex III for the use case you intend, which is a different answer from how they classify it in general. Ask what documentation they will give you to support your own oversight duty, since a deployer who cannot explain how a system behaves cannot supervise it. And ask what they will tell you, and how fast, when the system's classification or behaviour changes.
A vendor who answers all four has done the work. A vendor who says the product is fully compliant has answered none of them, because compliance is a property of a deployment rather than of a product sitting on a shelf. The distinction sounds pedantic until an authority asks you, rather than them, what oversight you applied.
Where does this sit against the risk tiers?
Underneath them. The tiers tell you which regime applies; this map tells you what to build once you know. If you have not settled the tier question yet, start with our explainer on the AI Act's risk tiers and the timeline they run on and come back here, because working the obligation list without a tier produces a backlog three times longer than the one you need.
The relationship between the two is worth stating once. Almost every business using AI has transparency and literacy duties. A much smaller set has high risk duties. A very small set does something prohibited, and the prohibitions have applied since February 2025 rather than being a future problem. Those three populations are wildly different in size, and the commentary flattens them because the high risk tier is where the interesting writing is. Your job is to establish which population you are in and then ignore the other two entirely.
What to check again in six months
This regulation has already been amended once, and the amendment moved the dates that most compliance plans were built around. That is the durable lesson rather than a complaint: build your programme so that a date change costs you a spreadsheet edit rather than a replan.
Three things to re verify each quarter, on official pages only. The application dates for your tier. Whether any guidance or harmonised standard has landed for your use case, because standards are what turn a written requirement into a testable one. And whether anything in your inventory changed category, which usually happens because a vendor shipped a feature rather than because you decided anything.
Then keep the evidence somewhere a stranger could read. That is also what an auditor will ask for, and the request list is remarkably consistent across frameworks, which we set out separately in the piece on the first ninety days of AI governance. Most of what the AI Act asks a deployer for is what any reasonable review would have asked for anyway. The regulation just gave it a deadline.