Last verified 23 September 2026. The EU AI Act's AI-literacy duty has applied since February 2025; the 2026 amendment kept it but mandates no specific level, and no certificate is needed. Rules for high-risk uses such as hiring apply from 2 December 2027. Details for experts at the end of this book.

The idea in one page

An AI inventory is one current list of every AI system a team runs. It isn't a policy. It's the thing you open when someone asks "what do we have, and who answers for it?"

List by effect, not by product. A row belongs in the inventory whenever software does or supports a task with AI: a chat assistant, an unattended workflow, an AI feature inside software you already use, a tool an employee connected to their mailbox. Include what's being tried, running, paused or retired this year. One row per purpose: two workflows with different data and different people responsible are two rows, even if they call the same model.

Every row has the same fields.

Tier by consequence, not by model. A tier tells you how much care a system needs. It doesn't decide what the law says; that stays with the DPO and legal advice, and the row records their answer.

Take the highest tier any part triggers. Running a model locally doesn't lower a tier; neither does a vendor calling it "low risk".

Proof is a chain of dated links. An auditor doesn't want your assurance. They want to follow one row to the decision that allowed it, the test that checked it and the review that confirmed it's still true. Link each; don't paste it. Personal data, prompts and raw logs stay where they are, and the inventory points at them.

Training is per role, with a date. The AI Act asks organisations using AI to take measures for their staff's AI literacy. There's no certificate; an internal record is enough. So each row names its user roles and when each was trained: "Sales staff: 45-minute session with the operating rule, 3 June."

It must work without you. The final test is the author has left test: your stand-in answers an auditor's questions and handles a practice incident from the inventory alone.

Worked example: two inventories, four quadrants

The method comes from T01-L01 · From Idea to Working Result: The Four-Quadrant Method. Here it is in a research department, then in a company.

Lab: five research groups, one list

Structure it. Katrin: "By the DPO's review in three weeks, the department has one list of every AI system its five groups run, each with a responsible person, a stand-in, a tier and the data it touches, and the list keeps working when I'm on leave. A useful result: the DPO accepts it, and my stand-in can answer her questions without me."

Understand it. She starts by asking, and asks differently than before. Instead of "Which AI systems do you use?" she sends every group the same five questions: What helps you write, read, sort, transcribe, translate, code or analyse? Which of those runs by itself? What did you connect to a mailbox, drive or notebook? What do you pay for with a card or through procurement? What are you planning?

The answers give eleven candidates. Two surprise her. The transcription app that two PhD students use for patient interviews in a clinic collaboration runs in a US cloud under personal accounts. And one group leader plans to have an assistant pre-rank PhD applicants by their CVs before the selection meeting.

She checks two sources that don't depend on memory: the department's procurement records, which show one AI subscription nobody mentioned (a writing tool, since cancelled), and a search of the group repositories on GitLab for the web addresses of AI providers' APIs, such as api.openai.com or api.anthropic.com, which any code that calls those services must contain. GitLab's search box finds them across all the department's repositories. It finds the literature workflow and one student's analysis script.

The transcription app and the applicant plan change the job. Katrin had pictured an inventory as a list to fill in. It's also a list of questions only other people can answer: the DPO for the patient recordings, and the staff council and legal office for the applicants. Back to Structure it: "The inventory records what we run and what we decided not to run. Where the answer isn't mine, the row names the question, who has it, and the date I asked."

Choose tools.

• A table on the department share, one row per system with the fields above, because it's where the DPO and the stand-in already look. A form in the institute's wiki would also work; what matters is one place.
• The DPO's record of processing activities, the list of personal-data processing every organisation must keep under the GDPR (Article 30). Each inventory row that touches personal data links to its entry there, so the two lists don't drift apart.
• Existing proof, linked: the audit sheet from T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In, the operations log and capacity table from T11-L05 · Keep a Shared Model Server Fast, Affordable and Running, the group registers from T15-L05 · Keep Your Group's AI Use Compliant and Running After You Leave.

Build it. Her inventory ends with nine rows. Three of them:

The applicant row matters most. The group leader's idea would have let a model shape a hiring decision, with no candidate knowing. The legal office points out that AI for selecting job applicants is one of the high-risk areas in the AI Act, and the staff council would have a say in any such system. The department head decides against it and signs the row. The need behind it, too many applications for one person to read, goes to a human route: two readers per application.

The transcription row is paused, not deleted. The students switch to typing notes by hand while the DPO decides. When the answer comes (a transcription model run on the institute's GPU server, as a new row), the paused row is retired with a link to the decision.

Build it: review and incidents. Two more lines make the inventory live. Every Tier 2 and 3 row gets a quarterly review in the department's calendar: is the purpose still the same, is the responsible person still here, has anything changed. And a short incident routine at the top of the table: if an AI system shows data to the wrong person, gives an answer someone acted on and it was wrong in a way that matters, or runs when it shouldn't, tell the responsible person, the stand-in and the DPO the same day, and add a line to the row's log.

Build it: the author has left. Katrin's stand-in is Emre, the department's IT administrator, who built none of the systems. Katrin plays the DPO and asks five questions from the inventory alone: Which systems touch health data? Who's trained on the assistant, and when? Which system was decided against, and why? Who stops the literature workflow? What happened on 20 November? He answers four without help. For the fifth he needs the transcription app's pause email, which was in Katrin's inbox. She moves it to the department share, links it, and the row is complete.

Then a practice incident: Katrin tells Emre that a user reports seeing someone else's chat. He opens the row, finds the responsible person and stand-in, sees the incident routine, and calls Tom. It takes eight minutes. (Tom checks: the user shares an account with a colleague. That goes in the log too, and shared accounts go into the next audit.)

The DPO accepts the inventory at the review and asks for it again in a year.

What it taught her: asking "which AI do you use?" found five systems. Asking what helps you write, read and sort found eleven. The most important row was one that will never run.

Company: a customer's audit question

Structure it. Stefan: "Answer question 14 of the hospital's audit truthfully within two weeks, and keep a list that answers the next audit without a scramble. A useful result: an inventory the managing director signs, and a stand-in who can answer the customer's follow-up questions."

Understand it. He asks every team lead the same five questions Katrin used, and adds one source only IT has: the list of enterprise applications in Microsoft Entra, the company's account directory. Every app that someone has allowed to read their mailbox or calendar shows up there, with the permissions they granted.

That list has a surprise. Four sales staff have connected a meeting-notes service to their calendars and mailboxes. It joins their customer calls, records them and writes summaries, and it has read access to their entire mailboxes, including the hospital's order correspondence. None of them thought of it as an AI system; it was a free trial someone recommended.

HR adds another: they'd like an AI tool to score incoming applications, "just to sort the pile".

Back to Structure it: "The answer to the customer isn't just what IT runs. It's everything that touches their data, including what staff connected themselves. And the inventory has to stop new connections from appearing unnoticed."

Choose tools.

• A list in the company's SharePoint, with the inventory fields as columns, because the managing director and the external DPO already have access, and it keeps a version history. A spreadsheet in the quality system is the alternative.
• Entra's user-consent setting, changed so that staff can no longer connect new apps to company mail without an admin's approval. In the Entra admin center it sits under Enterprise apps, Consent and permissions, User consent settings, where he picks Do not allow user consent. He also switches on the admin consent workflow, so a blocked employee can send a request instead of hitting a wall. New tools then arrive as requests Stefan sees, and each approved one becomes a row.
• Linked proof: the audit sheet for the quotes workflow from T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In, the provider contract for Microsoft Copilot, training dates from the HR system.

Build it. The inventory has nine rows. Three need decisions before the customer gets an answer.

The meeting-notes service: Stefan removes its access the same day. He opens the service under Enterprise apps in Entra, blocks its sign-in, and revokes the four staff's grants with PowerShell, since the portal can't. The external DPO confirms that recording customer calls needs the customer's consent, and the hospital's data went to a service with no processing agreement. The DPO decides, with the managing director, whether the hospital must be told; the row records the decision and the date. The row stays in the inventory as retired, with the incident linked.

The HR application scoring: tier 0 for now. The row notes that AI to select applicants is a high-risk area under the AI Act from December 2027, and that in Germany the works council has a say in technical systems that can monitor employees and in guidelines for selecting staff. HR takes the idea to the works council before anyone tries a tool.

The quotes workflow: tier 2, with its service account scoped to one mailbox, its audit, its stop, Lea as responsible person and Murat as stand-in. This is the row the customer cares about, and its proof is complete.

Stefan's answer to question 14 lists every row that touches the hospital's data, with purpose, responsible person, where it runs and a line on controls, and says plainly that one tool had been connected without approval, was removed on 3 October, and that connections now need approval. The managing director signs it.

Build it: the author has left. His stand-in is Mia from quality. The customer's follow-up call comes while Stefan is on holiday, and Mia answers from the SharePoint list: which rows touch customer data, who owns the quotes workflow, what happened with the meeting-notes tool, and when sales staff were trained. She needs Stefan once, for the Copilot contract, which was linked to a folder she couldn't open. The fix is one permission, recorded in the list's review notes.

What it taught him: the systems IT ran were easy to describe. The ones that mattered were connected by staff in two clicks, and the inventory only became true once it could see those clicks.

In both places the rows that mattered weren't the tidy ones. It was the rows that recorded a pause, a removal or a no.

What an auditor asks, and where the answer is

Most audits, customer questionnaires and DPO reviews come down to five questions. Each should take you, or your stand-in, less than a minute:

If a question takes longer, the row is missing something. Fix the row, not the answer.

What goes wrong

The inventory written once. Symptom: it was accurate in March; by September three rows are wrong. Fix: a review date on every row, reviews after every incident, and an approval step for new tools that adds a row.

"The team" as the responsible person. Symptom: when something breaks, everyone assumes someone else is on it. Fix: two names per row. If nobody will take it on, it pauses.

A tier used as a legal verdict. Symptom: "It's tier 1, so the AI Act doesn't apply." Fix: the tier decides how much care you give. Legal questions go to the DPO or legal office, and the row records their answer with a date.

Proof pasted instead of linked. Symptom: screenshots of chats with customer names in the inventory itself. Fix: link to where the proof lives, under its own access rules. The inventory holds no personal data.

The tools nobody thinks of as AI. Symptom: a transcription app or meeting recorder is missing because "it's just an app". Fix: ask what helps people write, read, sort and transcribe, and check the directory for apps connected to mail and calendars.

A human who only clicks OK. Symptom: a row says "human in the loop", and the person approves hundreds of AI decisions a day without looking. Fix: write down what the person checks and how long it takes. If they can't really decide, tier it as if nobody does.

The inventory only its author can read. Symptom: on your holiday, a question comes and nobody can answer it. Fix: the author has left test, twice a year and whenever the stand-in changes.

Do it yourself (3 hours, over two to three weeks)

1. Structure it (15 min). Write one sentence: which team, who needs the inventory and by when, and what a useful result looks like. Get the mandate in writing and name your stand-in.
2. Understand it (60 min, plus answers). Send every group or team the five questions. Check two sources that don't depend on memory: purchases, and apps connected to mail, drives or repositories. Ask the DPO for the record of processing activities. Rewrite your sentence if the answers change the job.
3. Choose tools (15 min). Pick the one place the inventory lives, and how new tools get added (an approval step or a request form).
4. Build it: rows (60 min). Fill one row per system. Give each a tier. Send each open legal question to the person who answers it, with the date. Record proposals you decide against as tier 0 rows.
5. Build it: proof and training (15 min). Link existing audits, tests, contracts and training dates. Note every gap as a task with a name and date.
6. Build it: without you (15 min, plus the test). Add the review dates and the incident routine. Run the author has left test: five auditor questions and one practice incident, answered by your stand-in from the inventory alone. Fix what they couldn't find.

Exit check

Written finding: an AI inventory for one department or team, and the record of one author has left test.

• Every system has a purpose, status, responsible person and stand-in, data touched, where it runs, risk tier, open legal questions with dates, training per role, proof links and a next review date.
• At least one row records a use you decided against or paused, with the reason and who decided.
• The test record lists the five questions, the stand-in's answers, the practice incident and what you fixed afterwards.

It passes when a stand-in who didn't build any of the systems answers the five auditor questions and handles the practice incident from the inventory alone, every open legal question has a named person and a date, and the department head or manager has signed.

Rule to remember

If it isn't on the list with two names, nobody is running it.

Details for experts

Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague. It isn't legal advice.

Further reading and tools

Next books

• T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In: the audit sheet you link as proof.
• T15-L05 · Keep Your Group's AI Use Compliant and Running After You Leave: a research group's register, archiving and retention.
• T13-L05 · Keep Everyone's AI Skills Current, and Show It When Asked: training records and AI literacy across an organisation.
• T11-L05 · Keep a Shared Model Server Fast, Affordable and Running: runbook and operations log for a shared server.
• T16-L05 · Keep Your Toolset Useful: consolidating and retiring tools.

Tools

• Microsoft Copilot: Catalogued. An AI feature inside software you already use; it still gets a row.
• n8n: Catalogued. The workflow tool behind the company's tier 2 row.
• Open WebUI: Catalogued. The department assistant in the lab's inventory.