Which of your AI the law touches
Most companies have more AI in the building than they think, and less of it inside this regulation than they fear. Both halves of that cost money. The first costs you an obligation you did not know you had. The second costs you three months of work on something nobody was ever going to ask about.
So the first job is a list. Not a policy, not a committee, not a workshop. A list of what is actually running, who runs it, and what happens to what comes out.
About the companies in this book
Before any of them appears, what they are. The companies in these pages are composites. The sensor maker with twenty-six people, the design studio with eleven, the reseller who found a feature nobody had chosen: none of them is a report of a particular business, and the figures beside them are not measurements.
They are assembled from how these obligations fall on a company of that size, to show the shape of the work. Where a number appears, it is there to give a sense of scale, and your own company may sit some way from it for reasons the example cannot know.
What is not invented is the law. Where this book tells you what the regulation requires, it says so in its own words, with the article beside it. The article governs, not the sentence here. So when something matters you can go to the consolidated text and read it yourself, rather than take this book's word for it.
How big this job actually is
It helps to know the size of the thing before starting it.
For the companies described in this chapter, with twenty or thirty people and a handful of bought tools, the list took an afternoon to draft and a week of background noise to finish, because two or three of the answers had to come back from someone who was on holiday. It ran to one page, and most of the rows on it needed nothing at all.
Your own company may be further from that than it looks. More sites, more systems built in-house, anything regulated, anything where software reaches a customer directly, and the afternoon becomes several. The figures through this book are what the work took in the cases described, offered as a sense of scale rather than as an estimate for your situation.
The afternoon is not spent writing. It is spent asking four or five people what their week looks like, and writing down what they say. The week of background noise is spent waiting for the one supplier who takes a while to answer a simple question.
That is the whole shape of it. Companies that end up spending a month have usually started by reading the regulation from the beginning, which is a reasonable instinct and the wrong order. The regulation is written for a reader who already knows which systems they have.
What the law means by an AI system
The definition is one sentence and it repays reading slowly. This is the regulation's wording, not a summary of it: a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environmentsThe EU AI Act defines an AI system as a machine-based system designed to operate with varying levels of autonomy, which may show adaptiveness after deployment and which, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments.verified, checked 2026-10-12How this was checked.
The word doing the work is infers.
A system that only runs simple rules somebody wrote is not inferring anything. Your invoice template calculates VAT at twenty per cent because somebody typed twenty per cent. The spreadsheet that flags any payment over five thousand euro is doing what it was told, in the order it was told. Neither one is in scope, however automated the process around it feels.
Simple is doing the work there. You can check either of those by reading it. A rule base can grow into an expert system, which the regulation itself names among the kinds of AI system it covers, and then the fact that a person once wrote the rules settles nothing.
A system that was shown ten thousand past invoices and now decides which ones look wrong is inferring. Nobody wrote the rule it uses. It derived one, and it may derive a slightly different one next month after it sees another thousand.
That is the line. It has nothing to do with how clever the thing is, or whether the vendor's website says AI. Plenty of software sold as AI is a decision tree somebody drew on a whiteboard in 2019. Plenty of software sold as "smart matching" or "automatic categorisation", with no mention of AI anywhere, is a model.
One way to settle it in your own head: ask whether a person could sit down with a document and follow the same logic by hand. If they could, even slowly, somebody wrote that logic. If the honest answer is that nobody in the building could reproduce the decision from a written rule, because the rule was learnt rather than written, you are looking at a model.
When you cannot tell, ask the supplier one question. Does it learn from data, or does it follow rules a person can read? The answer comes back quickly and it is usually candid, because whichever one it is, somebody on that team is proud of it.
A few cases that come up constantly, and where the answer surprises people:
Optical character recognition, the thing that turns a scanned invoice into text, is almost always a model. It has been one for years. Nobody thinks of the scanner as AI.
Spam filtering is a model, has been since before anyone used the term, and sits so far outside anything the regulation worries about that it will never appear on your list for any reason other than completeness.
Machine translation is a model. Whether it matters depends entirely on what you are translating and what happens next. Translating your website is nothing. Translating a safety instruction that someone then follows is a different conversation.
Forecasting in a spreadsheet is usually arithmetic, even when the add-in is called something ambitious. Ask which one it is.
Route planning for a delivery van is usually arithmetic too, and a very old kind. It became interesting only in the versions that started predicting how long each stop would take.
Grammar and style checking has gone both ways over the years. The underlining of a misspelt word is a dictionary. The suggestion that rewrites your sentence is a model. The same product often does both, which is a fair picture of how most software looks now.
When the supplier will not answer
Sometimes the one question comes back as marketing, or does not come back at all.
This happens more with small suppliers than large ones, and more with resellers than with the company that actually built the thing. It is rarely evasion. It is usually that the question reached someone whose job is renewals.
Two things to try, in this order. Ask again in writing, naming the feature rather than the product: not whether the platform uses AI, but whether the thing that sorts incoming tickets into categories learns from past tickets. A specific question reaches a specific person. Then look at the product documentation, which often answers it plainly in a section written for a technical reader who was never worried about the regulation.
If neither works, write down what you asked, when, and what came back. An unanswered question that you recorded is a different position from an unanswered question you never asked. You can treat the feature as in scope in the meantime and revisit it, which costs you one row on a list rather than a project.
The AI you did not buy
Here is the part that catches people, and it catches them in the year after they finished their inventory.
Software you already own grows AI features. The office suite gains a drafting assistant. The CRM starts scoring leads. The helpdesk begins suggesting replies. The payroll system offers to flag anomalies. In almost every case this arrives switched on, in a release note nobody read, in a product you have been paying for since 2022.
None of that appears on an invoice as a new line. None of it goes through procurement. It will not be found by the pass through your subscriptions, because the subscription was already there.
The only way to catch it is to ask the people using the software what changed. Which is why one of the three passes below is a question about work rather than a question about technology.
There is also the AI nobody told you about at all. Somebody in the team has a personal account and uses it for work because it is faster. That is not a compliance question first. It is a question about where your client's information went. But it belongs on the list, because a use you do not know about is a use you cannot document, and the fact that it was unofficial will not be interesting to anyone later.
The useful response to finding one of these is not a reprimand. The person was trying to get their work done and found something that helped. If the reaction is punishment, the next one stays hidden, and hidden is the state you are trying to get out of. Ask what it does for them, and whether there is a version of it the company can run openly.
Count uses, not tools
This is where most inventories go wrong, and the mistake is expensive to repair afterwards.
You have one chat assistant. Marketing drafts social posts with it. HR uses it for a first pass of interview questions. Someone in finance pastes supplier emails in and asks for a summary. That is one subscription and three uses, and the law has three different things to say about them.
Drafting a social post is nothing. Writing interview questions starts to touch recruitment, which is one of the areas the regulation watches closely. Pasting supplier emails means somebody else's commercial terms are now inside a system you do not control, which is a different law but the same afternoon's work.
If your list has one row that says "ChatGPT", you have not made a list. You have made a note of a bill you pay.
A row that is worth having answers five things:
what the system does, in the words someone outside the company would use
who uses it, by role rather than by name
what goes in
what comes out
what happens to the output
That last one carries more weight than people expect. A model that suggests something to a person who then decides sits in a completely different place from a model whose output goes straight into a letter that gets sent, an invoice that gets paid, or a candidate who gets rejected. Same model, same vendor, same monthly fee, different obligations entirely.
Keep the list in something dull. A spreadsheet is fine. A page in whatever wiki you already use is fine. The format matters far less than the habit of adding a row when something new arrives, and that habit is the only part of this that ever actually breaks.
What one of these lists looks like
A company that makes industrial sensors, twenty-six people, one office. Their first list had nine rows. It is worth walking through, because the shape of it is more useful than any example invented to make a point.
Three rows were the same chat assistant, used three ways: drafting product copy, summarising long supplier emails, and helping one engineer write small scripts. All three turned out to need nothing beyond a note about what staff may paste into it.
One row was the optical character recognition inside their accounting software, which had been reading supplier invoices for four years. Nobody had thought of it as anything. It stayed on the list and needed nothing, because a person checks every invoice before it is paid.
One row was a lead scoring feature their CRM had switched on in an update. It ranked inbound enquiries. Sales had noticed it and liked it. This one needed a short answer about what the ranking was used for, and the answer was comfortable: it changed the order of a call list, and every enquiry got called.
One row was a tool used in hiring, to sort applications for a production role. That one needed a real answer, and most of what the rest of this handbook describes applies to it.
One row was machine translation of their technical datasheets into three languages. Those datasheets tell an installer how to mount a sensor. That one needed a real answer too, for a different reason: the translation goes to someone who then does something physical.
Two rows were scripts an engineer had written. One was arithmetic and came straight off the list. The other predicted which units were likely to fail based on readings, and nobody could say what it had been fitted on, because the engineer who wrote it had left.
Nine rows, two of them real work, one of them an awkward discovery. That ratio is typical.
What is out of scope entirely
Several things sit outside the regulation no matter how much inference is involved.
Research and development, before a system is placed on the market or put into service. Personal, non-professional use, which covers your own evening experiments and not your employee's Tuesday afternoon. Military, defence and national security, which will not concern anyone reading this.
Free and open-source components get a narrower exemption than people hope for. It does not survive the component being put to a high-risk use, and it does not survive you placing a product on the market under your own name with that component inside. If a developer pulled a model off a public repository and built it into something your customers touch, you are not in the exempt category, and the assumption that you are is one of the more common ways a company arrives at this subject late.
There is a boundary people trip over from the other direction too. The regulation does not care whether you built the thing or bought it. Buying it does not make it the vendor's problem. It changes which obligations are yours, and the chapter after this one is about that, because the answer is less comfortable than most buyers assume when they sign.
Three passes
None of this needs a consultant and none of it takes a week.
The invoices. Every software subscription the company pays for, including the ones a department bought on a card without telling anyone. This finds tools, and it finds them quickly, but it misses everything described two sections ago.
The question that is not about AI. Ask each team: what in your week is now done by software that used to be done by a person reading something? People who would answer "we don't use AI" will answer this one fully, because it is about their work rather than about a category they have opinions on. This is the pass that finds the features that arrived in an update.
What was built here. Including the thing somebody wrote over a weekend that now runs every Monday morning. These have no vendor, no documentation and no contract. They are the systems most likely to be invisible until the morning they produce something wrong, and the ones where nobody can tell you what they were trained on.
The second pass is the one worth doing properly. Fifteen minutes with each team, in a room, with somebody writing. Not a form sent round, because a form gets answered by the person who answers forms, and the useful answer lives with the person who does the work.
Who holds the list
Somebody has to, by name, or it stops being updated in about four months.
It does not have to be a senior person and it should not be a committee. In most companies this sits well with whoever already keeps track of software and accounts, because the list is closer to an asset register than to a legal document. They are not being asked to judge anything. They are being asked to notice when a row should be added and to send the hard ones to whoever decides.
The one arrangement that reliably fails is making it nobody's, on the grounds that everyone is responsible. A list owned by everyone is a list that was accurate on the day it was written.
The row that is hardest to write
One kind of entry defeats companies more than any other: the thing somebody built here, which still runs, and whose author has left.
They turn up in most companies of any age. A script that scores something. A spreadsheet with a model behind it. A small service that nobody has touched in two years because it works.
What makes the row hard is that the usual questions have no answers. Nobody can say what it was built from. There is no supplier to ask, no instructions for use, no release notes. The person who would know is not here.
The useful move is to write the row anyway, with the gaps marked as gaps.
What it does, in operational terms, which is usually discoverable by watching it. What goes in and what comes out. What the output is used for, which is the question that decides whether any of this matters. And then, plainly: we do not know what this was fitted on, the author has left, and the documentation is a comment in the code.
That entry is worth far more than its absence, for two reasons. It is the only honest description of the company's position. And it converts an invisible system into a decision somebody has to make: keep it and accept what you do not know, replace it, or stop using it.
Most of those decisions come out as keeping it, because the use is harmless. A few of them turn out to matter a great deal, and finding out which is the entire purpose of the list.
What you end up holding
A list where most rows are nothing. That is the normal outcome and it is worth saying plainly, because a good deal of what has been written about this regulation leaves owners believing that every use of a model drags a filing cabinet behind it.
Some rows will be in scope and low stakes. A sentence somewhere telling people they are dealing with a machine, and nothing else.
A few rows, usually one or two in a company of thirty people, will need a real answer. Those are the ones where the output touches somebody's money, their job, their access to something they need, or their safety. The rest of this handbook is about those rows, and about keeping the paperwork around them true while the systems underneath keep moving.
What you should not do is start writing documentation before the list exists. Companies that work in the other order produce a thick file about the wrong system. It satisfies nobody, and it goes out of date on the same schedule as everything else.
Revisit the list when something enters the company and when something changes under you. Not quarterly, because a calendar review finds what was already there and misses what arrived last Tuesday. The events that matter are a new tool, a new use of an old tool, a vendor release note, and a person joining who brings their own habits with them.
The form for this
Open: AI inventory, one sheet per use.
The fields that take the thinking: what happens to the output, and whether the regulation reaches it at all. The rest is description and comes quickly.
A filled line: Use: ranking applications for the production role. Who: the office manager, during hiring rounds. In: CV and covering letter as uploaded. Out: a score from one to five. What happens to it: the top of the list gets read first and the bottom is rejected on the score.
Read again when: a new tool arrives, an old tool gains a feature, a team starts using something for a new job, a supplier sends a release note, somebody joins who brings their own habits.