How to build an AI system register for your business

A practical business AI register: which tools to include, the 15 fields to document, who owns each record and when an assessment must be repeated.

Publicat 30 iulie 20266 minute

AI ACT · INVENTORY AND GOVERNANCE

You cannot assess a system the organisation does not know exists. An AI register brings centrally purchased accounts, team-installed extensions, product APIs and vendor-built automations into one place.

Why compliance starts with inventory

Obligations depend on the system, role, purpose and risk. Without an inventory, a company cannot say whether it is a deployer or provider, where customers interact with AI, which data enters a model and who checks the outputs. A good register does not prove compliance by itself, but it makes every subsequent assessment possible. ^[EU-REG] ^[EU-DESK]

The Commission provides a Compliance Checker and AI Act Explorer for orientation, but their answers are useful only when the use information is accurate. “We use ChatGPT” is not an adequate description. The product and plan, users, input data, purpose, integration, audience and actions the system can execute all matter. ^[EU-DESK] ^[EU-A50]

What belongs in the register

Include systems purchased by the company, AI features inside existing products, individual accounts used professionally, plugins, browser extensions, API integrations and automations built by agencies or freelancers. Include pilots using real data even when they are not yet available to customers. ^[EU-LIT] ^[EU-A50]

Not every statistical formula or simple automation is necessarily an AI system under the Regulation. The register may include an “AI Act in scope?” field with assessment status and reasoning. It is healthier to record an uncertain tool and exclude it with documented reasoning than to ignore it because its commercial name does not contain the word AI. ^[EU-REG] ^[EU-NAV]

The 15 useful fields

The register should be short enough to remain current and precise enough to support a decision. Fields may live in a spreadsheet, internal tool or GRC system. What matters is having an owner, history and links to relevant documents. ^[EU-DESK]

System name, product, plan and version in use.
Internal owner and teams operating it.
Contractual vendor and important technical providers in the chain.
Stated purpose and workflow in which it is used.
Organisation role: provider, deployer or another actor, with reasoning.
Internal users and affected people or groups.
Input data, including personal or confidential data.
Outputs produced and who receives them.
Actions the system can execute and its level of autonomy.
Risk classification and reasoning, including prohibited-practice screening.
Transparency measures and content marking.
Human control, approval, override and stop criteria.
Logging, retention, security and incident handling.
AI-literacy measures for the roles involved.
Approval date, last review, next review and status.

How to handle shadow AI

Shadow AI appears when people use tools without central approval: a personal translation account, an extension reading the open page, a meeting bot invited into a conversation or a generative feature activated in an existing product. A total ban rarely solves the problem; a realistic policy provides approved alternatives and a simple disclosure path. ^[EU-LIT]

Inventory should not be framed as a disciplinary operation. Useful questions are: which problem does the tool solve, which data does it receive and which alternative could be approved? A sanction-free discovery period can reveal valuable workflows as well as risks management could not see. ^[EU-LIT-REP]

Statuses and reassessment triggers

Use explicit statuses: discovered, under assessment, approved pilot, production, suspended and retired. A suspended system should not disappear from the register; history explains why it was stopped and prevents uncontrolled reinstallation. Every status should have a person authorised to approve transition.

Reassessment should not wait for an annual date when purpose, model, version, vendor, data, autonomy, integration or affected audience changes. A feature that only suggested text yesterday may publish automatically or take an action through an agent tomorrow. A capability change can alter the required controls and sometimes the role or risk. ^[EU-RISK] ^[EU-A50]

Who owns the register

There is no requirement to create an “AI officer” role. In an SME, an operational coordinator may maintain the register while every system has a business owner. IT or development validates technical aspects, the DPO checks data issues where relevant and the editorial or product owner approves use in their workflow. ^[EU-LIT]

Important decisions need a named owner and date. A committee without executive responsibility produces meetings, not control. The register should answer a simple question: if this system gives a wrong answer, publishes something unsuitable or exposes data, who can stop the process today?

Examples from SEO, SaaS and operations

At AYSA.RO, a record may describe the research tool: sources entered, prohibited client data, the draft nature of the output and editor approval. For AYSA.AI, the register should connect model and version to agent functions, WordPress permissions, logging, user control and the product release. ^[EU-A50] ^[EU-LIT]

In ProFlorist, stock forecasting may use order history and seasonality, produce a recommendation and require manager override. In CanUHelp APP or AdverLink, recommendations, ranking, moderation and support should be recorded separately when they have different purposes, data and effects. The product name does not replace a functional inventory. ^[EU-RISK]

A first version can be ready in one week

Start with an export of approved applications, a 30-minute conversation with each team and a simple form for undeclared tools. Complete purpose, owner, data, output and human control first; then add role and risk assessment with the competent people. ^[EU-DESK] ^[EU-LIT]

Do not wait for perfection. An incomplete register that is owned and reviewed weekly is more useful than a sophisticated template nobody fills in. The maturity test is whether the organisation can quickly explain which AI it uses, for what purpose, with which data, under whose responsibility and with what ability to stop it.