An AI systems register, useful for the AI Act (the EU regulation on artificial intelligence), is a spreadsheet in which every AI tool used in the company is recorded — in a row of its own or, for minor tools, in a shared entry: what it is, what it is for, who is responsible for it, what data goes into it, and who looks at the output. Not to be confused with the record of processing activities under the GDPR, the EU General Data Protection Regulation (the difference is below), or with company registers such as Poland’s KRS and CEIDG.
A list of fields is not enough on its own. To make the sheet fillable, three more things are needed: a row filled in end to end for a specific system, where the value for each column comes from, and a clear line between facts and legal assessment. This piece gives all three — and a file to download.
A shortcut with nine columns and an example for a trading company is in our guide to the AI Act in Poland. Here we describe a more detailed method: we go column by column, and leave the company’s role under the AI Act entirely to the lawyer.
What the register is for — and what it is not
Usually the first question in an AI audit, in a conversation with a lawyer about the AI Act and in a security review is the same: which AI systems do you use? From 28 October 2026 Poland’s Commission for the Development and Security of Artificial Intelligence (KRiBSI) can carry out inspections — what changes then, we describe in our guide to the AI Act in Poland. A company with a register answers that question with one file. A company without one starts by guessing.
What this register is not — because a few mistakes are doing the rounds:
- It is not a duty under one specific article of the AI Act. In the consolidated text of 27 July 2026 we found no provision requiring every company to keep an internal list of AI systems. It is a working document that gathers the facts needed under Articles 4, 26 and 50.
- It is not the technical documentation under Article 11. That is drawn up by the provider of a high-risk system; merely using a system does not create that duty.
- It does not replace registration in the EU database (Articles 49 and 71, Annex VIII). That duty falls mainly on providers of high-risk systems and — in specified cases — on public bodies that use such systems; simply using an ordinary chat tool does not create it. If your lawyer decides that registration applies to you, the facts in this sheet will be the starting point.
- It is not the record of processing activities under Article 30 GDPR, although the two overlap: when a system receives personal data, the systems register records the data categories and the name of the entry in the record of processing.
This piece covers the technical and organisational side. Who is what under the AI Act, and which duties follow, is for a lawyer to establish — why we keep to that line, we explain on the page what we don’t do.
Twelve columns and where each value comes from
Eleven columns are facts that someone who knows the process can fill in. The twelfth belongs to the lawyer. Some columns record the facts the law asks about: columns 7, 8 and 11 — facts about input data, human oversight and keeping records of the system’s activity, which Article 26 asks a deployer about (a company using the system in its own business); column 10 — a pointer to the separate record of measures supporting AI literacy under Article 4, that is, how the company helps people use AI with understanding; column 9 — the fact Article 50 starts from: whether people know they are dealing with AI. Filling in the columns does not mean a duty is met; it gives the lawyer material to assess. Article 26 applies to high-risk systems in Annex III (a list of high-risk uses, such as in recruitment or credit scoring) from 2 December 2027, and to those in Annex I (products covered by separate legislation) from 2 August 2028. For systems put into use earlier, Article 111 sets transitional rules, which the lawyer also assesses. Typical office tools usually fall outside these categories, but that too is for the lawyer to confirm. The columns are cheap to fill in today, and if the lawyer decides otherwise, the facts will already be on record.
| No. | Column | What to enter | Where the value comes from |
|---|---|---|---|
| 1 | System, supplier, plan | The tool’s name, the company that supplies it, the plan or licence | Invoice, contract, admin panel |
| 2 | What we use it for | The process in one sentence: what happens before the system and after it; where the supplier’s instructions are kept | The process owner, supplier documentation |
| 3 | Owner | The role of the person responsible for this row (not their name) | Management decision |
| 4 | Who built it and under whose brand it runs | A supplier’s ready-made product, a feature in a system you bought, or a workflow built for you or by you — and the name it runs under | Contract, supplier’s website, what the user sees |
| 5 | What we have changed in the system | Nothing, or exactly what: our own instructions, a use other than the one the supplier describes, modifications | Whoever configured the system, the configuration notes |
| 6 | Account and contract | Company or personal account; whether there is a data processing agreement (a contract in which the supplier commits to how it processes personal data on your behalf) | Admin panel, the contracts folder |
| 7 | Data that goes in | Categories of data, including whether there is personal data and whose; the name of the entry in the GDPR record of processing | The process owner, sample input documents |
| 8 | Output and who approves it | What the system returns, where it goes, and who checks it before it takes effect | Process description, a conversation with the approver |
| 9 | Who sees the output and whether they know it is AI | Who comes into contact with the system or its output — staff, customers, readers of content — and what they are shown about it | Open the system as a user or customer and read the first sentence; read the instructions staff receive |
| 10 | AI literacy (Article 4): pointer to the record | Where the record is kept of who uses the system and what they received (instructions, training, a page of rules) — you keep that record, with dates, separately, and only point to it here | The separate AI literacy record |
| 11 | Activity records: where and for how long | Where requests to the AI (prompts), outputs and the system’s event log (logs) are recorded, who can access them and how long they are kept | Supplier documentation, admin panel |
| 12 | The lawyer’s column | Role under the AI Act and risk classification — filled in by the lawyer | The lawyer, based on columns 1–11 |
Three notes on the columns that cause the most trouble.
Columns 4 and 5 instead of “our role”. Many templates have a column “role: provider or deployer”. That is a legal question: the AI Act defines a provider partly by who develops the system or has it developed and under whose name or trademark it is placed on the market or put into service (Article 3(3)). Article 25 in turn describes situations in which a company becomes the provider of a high-risk system — for example when it puts its own name on it, substantially modifies it, or changes a system’s intended purpose so that it becomes high-risk. Someone in the accounts department cannot answer that. The same person can easily record who built the system, what name it runs under and what you changed in it. That is how you get the facts from which the lawyer derives the role.
Column 7 holds categories, not content. “Supplier data: name, tax ID, bank account number” — yes. A sample invoice pasted into the sheet — no. Who is the controller and who is the processor we cover in our piece on GDPR when implementing a language model, in the part about roles.
Column 8 says who really looks at the output. “A person approves it” is not enough. Enter the role of the person, the point at which they approve, and what they see before they click. How to tell real checking from clicking “approve” without reading, we cover in our piece on human approval.
One row filled in end to end: reading invoices that come outside KSeF
The example is a workflow of the kind we build in accounting automation projects. Cost invoices from foreign suppliers, which do not arrive through KSeF (Poland’s national e-invoicing system), land in a mailbox. The system reads data from them and proposes account assignments, and an accountant approves or corrects the proposal. Why these documents still need reading, we explain in our piece on KSeF and accounting automation. The row illustrates the method and does not describe a specific client; dates, periods and settings are assumptions of the example.
| No. | Column | Value in the example |
|---|---|---|
| 1 | System, supplier, plan | A workflow in n8n (a process automation tool) on the company’s server; a language model from “Example Supplier A” (a fictional name — in a real sheet you enter the supplier’s name here), pay-as-you-go API plan, called through an API (the interface through which one program connects to a service), on a company account |
| 2 | What we use it for | Reading cost invoices from foreign suppliers from the invoice mailbox and proposing account assignments before posting; the model supplier’s documentation and the workflow description are in the project folder |
| 3 | Owner | Chief accountant |
| 4 | Who built it and under whose brand it runs | Workflow built for the company by an external contractor; runs internally under the name “Foreign invoice reading”; the model comes from “Example Supplier A” under its own brand |
| 5 | What we have changed in the system | We added our own invoice-reading instructions and chart of accounts to a general-purpose model (one that does many different tasks and was not built specifically for invoices) |
| 6 | Account and contract | Company account with the model supplier; data processing agreement with the model supplier accepted when the account was opened, with the contractor — in the implementation contract; both in the contracts folder |
| 7 | Data that goes in | Invoice content: supplier details, including sole traders (which makes it personal data), amounts, bank account numbers; entry in the record of processing: “Posting cost invoices” |
| 8 | Output and who approves it | A proposed posting (account assignment) in the accounting system; an accountant approves every proposal before it is posted and sees a preview of the invoice next to it |
| 9 | Who sees the output and whether they know it is AI | Only the accountants see the output, in the accounting system; the instructions say plainly that the proposals are prepared by AI; the proposals do not reach anyone outside the company, and invoice data is sent to the model supplier through the API (see columns 6 and 11) |
| 10 | AI literacy (Article 4): pointer to the record | AI literacy record, accounts department entries (the “AI literacy” file in the management shared folder) |
| 11 | Activity records: where and for how long | Execution history in n8n on the company’s server, access: IT administrator and chief accountant, kept for 6 months; at the model supplier: requests and responses kept under the account terms (30 days in the example); in the example the company cannot view or export them, and the IT administrator manages only the account and access keys |
| 12 | The lawyer’s column | (blank — filled in by the lawyer) |
This row shows what the lawyer’s column is for. Columns 4 and 5 say the workflow was built to the company’s order and uses a general-purpose model with instructions of its own. Whether that implies any role other than deployer, and whether reading invoices falls into a high-risk category at all, is a question for the lawyer, not for the contractor. We can supply the facts, this row included.
Five typical systems in one table
The sheet has to scale. Below are five tools that often turn up in a small or mid-sized company, with the columns that are easiest to fill in completed. Under the rule in the next section each of them needs a full row; the remaining columns are waiting in the template you can download.
| System, supplier, plan | What we use it for | Who built it and under whose brand it runs | Account and contract | The lawyer’s column |
|---|---|---|---|---|
| ChatGPT Business (formerly Team), OpenAI | proposals, translations, email drafts | supplier’s ready-made product under its brand | company account; terms for business customers | (blank) |
| Microsoft 365 Copilot, Microsoft | summaries of email, meetings and documents | feature in a suite we bought, supplier’s brand | company account in Microsoft 365 | (blank) |
| Website chatbot, supplier subscription | answering questions about orders | supplier’s product, embedded on our site | company account; data processing agreement — to check | (blank) |
| Reading invoices outside KSeF, n8n workflow | proposing account assignments | workflow built to our order | company account with the model supplier | (blank) |
| Enquiry scoring in the CRM (customer management system), CRM feature | order in which enquiries from prospective customers are followed up | feature in the CRM we bought | company account in the CRM | (blank) |
Where we take the values for the two tools from large suppliers (pages checked on 12 October 2026):
- ChatGPT Business. OpenAI’s business data page says that by default data from ChatGPT Business is not used for training or improving models, and that qualifying organisations can configure how long OpenAI retains the data. We found no description of exporting activity records for the Business plan on that page, so column 11 says “retention period and export — to be confirmed with the supplier”, not a guess.
- Microsoft 365 Copilot. Microsoft’s documentation says that prompts, responses and data accessed through Microsoft Graph (the service through which Copilot reaches mail, calendars and files in Microsoft 365) are not used to train foundation language models, and that an administrator can review the history of interactions with Copilot through Content search or Microsoft Purview and set retention policies there. That is the value for column 11.
Who gets a full row and who gets a collective entry
Not every tool needs eleven filled-in fields. A simple three-tier rule: check the tiers in order, starting with the first, and pick the first one whose condition the tool meets.
- Full row — when the system receives personal data or customer data, when it talks to people outside the company or produces content that goes outside, when its output affects a decision about a specific person, or when it was built or configured for you.
- Short row (columns 1–4, 6, 10 and 12) — tools on a company account, used for work on internal content with no personal data and no customer data.
- Collective entry — everything that does not meet the conditions of the first two tiers, for example minor tools with no company account used to read public material for internal use, such as a browser translator for reading a foreign supplier’s public website. One row, “supporting tools”, with a list of names and an owner.
Every tool appears in the register at least once — the tier only decides how many fields you fill in. When a tier-two or tier-three tool starts receiving customer data, it moves to tier one.
Where do you get the list of tools to enter? The most reliable sources are company card statements and invoices, the Microsoft 365 or Google Workspace admin panel, and a short conversation with each department head. We describe seven such sources, and what each one shows, in our piece on shadow AI at work.
When to update the register
The register is updated when something happens, not by the calendar. The row’s owner changes it when:
- a new tool appears, or the plan or licence changes;
- new categories of data start going into the system, especially personal data;
- the system gets a new use, or its output starts reaching new recipients, such as customers;
- the supplier changes its terms, its model or where it stores data, and says so;
- there is an incident or a complaint about the system’s output;
- the row’s owner changes role or leaves the company.
On top of that, a short review of the whole sheet once a quarter: does every row have an owner, has the lawyer’s column been waiting for months, and has anything appeared that nobody reported. The register carries the date of its last review and of the next one at the top.
What not to enter
- Legal conclusions in columns 1–11. “AI Act compliant”, “doesn’t apply to us”, “minimal risk” — those are assessments that belong in column 12 and with the lawyer.
- Passwords, API keys and other credentials. The register is a document you show to people; access credentials belong in a password manager.
- Trade secrets and the content of prompts to AI. A description of the process, not a sample proposal with prices or a prompt containing customer data.
- Employees’ personal data beyond their role. “Chief accountant”, not a name — the role survives a change of person, and the register holds less unnecessary personal data.
- Assessments of people. Who uses a tool well and who uses it badly is a matter for their manager, not for the register.
Template to download
Download the AI systems register template (CSV) — version of 12 October 2026. The file has the twelve columns described above, five sample rows below the header (the invoice-reading row filled in end to end, the others partly, with fields left to complete) and fields for the dates of the last and next review. Columns are separated by semicolons and the encoding is UTF-8 with a byte-order mark (BOM), which helps Excel read accented characters correctly. If everything lands in one column or accented characters look garbled when you open it, use Excel’s import from a text file, choose UTF-8 encoding and the semicolon as the delimiter, or open the file in Google Sheets. Delete the sample rows before entering your own.
What next
The sheet is ready when every row has the fields its tier requires, no “to complete” or “to be confirmed” notes remain, and the lawyer has filled in column 12 wherever their assessment is needed. If there are only a few rows, nothing talks to customers and the lawyer has flagged nothing to do, it is enough to update the sheet when things change and come back to it at the quarterly review. If there are a dozen or more rows, something talks to customers, or column 4 says “built for the company”, it is worth going through the technical side with someone who knows these systems from the inside. We describe it under the AI Act technical compliance sprint; the questions worth asking every supplier about data are on our security and GDPR page. Tell us what you use — we will say where we would start, including when the answer is “this sheet is all you need”.
Sources, as at 12 October 2026
- Regulation (EU) 2024/1689 — consolidated text on EUR-Lex — Article 3(3) and (4) (definitions of provider and deployer), Articles 4, 11, 25, 26, 49, 50, 71, 111 and 113, and Annex VIII.
- Regulation (EU) 2026/1744 (Digital Omnibus on AI) on EUR-Lex — new dates for high-risk systems.
- Act of 3 July 2026 on artificial intelligence systems, Journal of Laws 2026 item 1003 — the act’s record in ISAP (in Polish).
- Regulation (EU) 2016/679 (GDPR) on EUR-Lex — Article 30 (records of processing activities).
- OpenAI: Business data privacy, security, and compliance — page checked on 12 October 2026.
- Microsoft Learn: Data, Privacy, and Security for Microsoft 365 Copilot — page checked on 12 October 2026.