AI governance in practice: inventory, policy and control

In most companies AI arrived bottom-up: an employee started summarising meetings with a chatbot, the marketing team adopted an image generator, and a software vendor quietly switched on AI features in a product you already pay for. Management is often the last to know.

AI governance means knowing which systems you use, for what purpose, with which data and who is accountable for their output. A signed policy filed away answers none of these questions. The answer comes from a small set of processes that run every month: inventory, classification, usage rules, vendor assessment, oversight and incident handling.

The pressure comes from three directions. The AI Act already requires AI literacy and bans certain practices. The GDPR applies to any personal data typed into a prompt. And for NIS2 entities, AI tools are one more part of the supply chain to manage.

You cannot govern what you cannot see. The inventory is the foundation of any programme and must include shadow AI — tools employees use without formal approval, often with personal accounts.

• A short questionnaire to team leads: which AI tools do you use, and for what?
• Proxy and DNS logs: which domains of popular AI services show up in traffic?
• Invoices and corporate cards: monthly subscriptions to AI services.
• Existing SaaS contracts: which vendors have added AI features, and on what terms?

For each system record at least: name and vendor, purpose, department, internal owner, categories of data processed, whether personal data is involved, your role (provider or deployer) and the risk tier. A well-maintained spreadsheet is worth more than a sophisticated platform nobody updates.

Once inventoried, systems are classified using the AI Act logic: prohibited, high risk, limited risk (transparency) and minimal risk. The classification decides the effort.

Classification is not final. The same tool can move between tiers if you use it for a different purpose: a language model used for summaries is minimal risk, but used to rank job candidates it usually becomes high risk.

The usage policy is the document employees actually read, so it must be short and concrete. The most important part is the list of data that is banned from public or unapproved tools:

• personal data of customers and employees, especially special categories (health, biometric data);
• passwords, API keys, tokens, configuration files;
• proprietary source code and internal architecture documentation;
• unpublished financial information, contracts, negotiated prices;
• details of ongoing security incidents.

The policy should also state which tools are approved and with which type of account, that a person reviews output before it is used in decisions or published, how AI-generated content is labelled and who to report problems to. Tie it to the AI literacy training required by Art. 4, or it stays a piece of paper.

An AI vendor receives, by definition, whatever data you send it. Assess it as seriously as any critical supplier:

1. Data residency: where are prompts and responses processed and stored?
2. Training: does the vendor use your data to train its models? Is there an opt-out, and is it on by default for your plan?
3. Retention: how long are conversations kept and who can access them?
4. GDPR: is there a data processing agreement, and which sub-processors are used?
5. Security: which certifications does it hold, how does it handle incidents, which logs does it give you?
6. Exit: how do you get your data back, and how is deletion confirmed when the contract ends?

For high-risk systems, also ask for the instructions for use and the information the provider must give deployers under the AI Act.

Do not forget existing vendors. Many SaaS applications you already pay for — CRM, office suite, helpdesk — have gained AI features through updates. Review updated terms periodically, because a new feature can change where and how your data is processed without anyone in the company signing anything new.

Human oversight means a named, competent person who understands the system's limits and has the authority to override or stop its output. An “approve” button clicked mechanically is not oversight.

Logging lets you reconstruct what happened: which system, which version, which input, which output, who decided. For high-risk systems the AI Act requires deployers to keep the logs under their control for at least six months. For prompts that may contain personal data, balance this with GDPR data minimisation — for example by keeping a hash and metadata instead of the full text.

AI incidents — a discriminatory output, a data leak through a prompt, a wrong decision based on a “hallucination” — should go into your existing incident process, not a separate one. If you are a NIS2 entity, check whether the incident also has a security impact that must be reported to the national authority.

ISO/IEC 42001:2023 is the international standard for artificial intelligence management systems. It follows the familiar structure of ISO management standards — context, leadership, planning, support, operation, evaluation, improvement — and integrates naturally with ISO/IEC 27001. Certification is voluntary and does not equal AI Act compliance, but it provides an auditable framework for the processes described above.

The GDPR does not disappear when AI shows up. Personal data in a prompt is processing: you need a legal basis, transparency towards data subjects and, for high-risk processing, a data protection impact assessment (DPIA). It is worth adding AI tools to your record of processing activities.