Build on your existing GRC foundation. Start AI governance with an inventory, named owners and a practical risk assessment. Check the data each tool can reach, the actions it can take and the people it affects. Identify the relevant EU rules, then put controls and review dates around the highest priority use cases.
AI governance depends on a working foundation in governance, risk and compliance (GRC). Clear roles, risk management, policies, controls and reporting need to be in place. Without that baseline, you risk adding another layer to unresolved governance problems.
Building that GRC baseline is outside the scope of this article. If you need a hand with that, I know a few good people in Easi’s GRC team 😉. The five steps below focus on integrating AI into your existing GRC approach, with clear ownership, practical risk decisions and evidence that controls work.
Your marketing team uses a chatbot. HR is testing an AI assistant. Someone has connected an agent to customer records. Where should AI governance start?
1. Start AI governance with an inventory
Build a simple AI inventory covering approved tools, experiments, AI features inside existing software and tools people use without formal approval.
Record the purpose, business owner, supplier, users, data sources and connected systems. Also note whether the tool only makes suggestions or can send messages, change records or trigger transactions.
Ask business teams, IT and procurement together. A subscription list alone will miss AI features and locally built agents.
Your first deliverable: one shared register, with an owner and review date for each use case.
Map AI capabilities in your inventory
Add a capability field to each use case in your AI inventory. The ITIL AI Capability Model, also known as PeopleCert’s 6C model, helps describe what AI does. Select every category that applies to the use case.
| Capability | Example use case | Governance question |
|---|---|---|
| Creation | Drafting a customer reply or generating code | Who checks the output before it is used? |
| Curation | Flagging duplicate or outdated knowledge articles | Who approves changes to trusted content? |
| Clarification | Summarising a contract or translating a report | Could missing detail or changed wording alter the meaning? |
| Cognition | Detecting unusual payments or predicting service incidents | How are findings validated before someone acts on them? |
| Communication | Answering service desk questions through a chatbot | What information can it disclose, and when should it involve a person? |
| Coordination | Updating customer records or issuing refunds automatically | Which actions need approval, and how can execution be stopped? |
A customer support assistant may combine Communication, Clarification and Creation. If it can also update records or issue refunds, include Coordination.
Map the actual use case, since the same tool can support different activities with different permissions.
These categories describe functions, rather than risk levels. Use them to inform the assessment of data, autonomy and impact in step 2, alongside any applicable AI Act classification. They do not replace an AI Act assessment.
Capability names follow PeopleCert’s 6C model in the linked ITIL AI Governance white paper, section 3.5. Examples and governance questions are Interian’s practical illustrations.
2. Assess data, autonomy and impact
Two useful starting questions are:
- Data sensitivity: can it access public information, internal documents, personal data or confidential records?
- Autonomy: does a person approve each action, or can the system act across tools and workflows?
Consider a refund assistant. Drafting a reply from a public FAQ is one use case. Reading customer records and issuing refunds without approval is another. The second needs stronger access limits, transaction checks and recovery arrangements.
Include familiar threats such as phishing, ransomware, stolen identities and supplier compromise alongside prompt injection, agent hijacking and data leakage. OWASP’s agentic application guidance is a useful reference for assessing agent security.
Then assess the business impact: could an error affect safety, employment, payments or access to services? Review bias, accuracy, misuse and supplier failure too. A system with little autonomy can still seriously affect people.
The matrix is a discussion aid, not a complete risk assessment or an AI Act classification. Prioritise according to your actual use case, likelihood, impact and existing controls.
3. Check which EU rules apply
The AI Act is part of a wider legal landscape. Your activity, data, sector and role determine which rules matter. Using an AI service, developing a system and placing a product on the market can create different responsibilities.
| Framework | What to check |
|---|---|
| AI Act | The system’s intended use and your role. Check for prohibited uses, AI literacy and transparency duties, and obligations for systems classified as high risk. |
| GDPR | The lawful use of personal data, data minimisation, individual rights, security and the need for a data protection impact assessment. |
| ePrivacy Directive | Communications confidentiality, device access and electronic marketing under the relevant national rules. |
| NIS2 Directive | For entities within scope: cybersecurity risk, suppliers, continuity and incident reporting, including AI dependencies. |
| DORA | ICT risk in the financial sector, operational resilience, incident handling and dependencies on third parties that support AI use. |
| Cyber Resilience Act | Security and vulnerability handling for qualifying products with digital elements. AI use alone does not establish scope. |
| Data Act | Connected product data access and sharing, plus switching between covered data processing services. |
| Data Governance Act | The reuse of protected public sector data, data intermediaries and data altruism where relevant. |
| Digital Services Act | Duties for intermediary services and online platforms using AI. It is not a general law for all agents. |
| Product safety and liability | Consumer product safety under GPSR and liability for defective products, including software and AI under the revised Product Liability Directive. |
| Sector legislation | Additional rules for uses such as medical devices, machinery, aviation and financial services. |
Check applicability and application dates separately, including national implementation where relevant. Link each applicable requirement to an owner, a control and evidence.
4. Give controls an owner
AI governance needs clear decision rights. Agree who can approve new uses, accept residual risk and suspend a system. The business owner should work with security, privacy, legal and the technical team.
For each priority use case, define permitted data and actions, minimum access rights, supplier requirements and human approval points. Test whether the controls work, including when the system receives misleading or malicious input.
Train users to recognise the system’s limitations and report problems. Decide what to log, who reviews the logs and how long to keep them. Avoid collecting sensitive content that you do not need.
Before an agent acts: name the person who can stop it, test how to revoke its access and agree how to correct affected records. Turning it off does not undo completed actions.
A sandbox can help you test an agent in isolation. Before connecting it to live systems, restrict its permissions, data access and outbound connections. Require approval for sensitive actions, monitor its activity and test the stop procedure.
5. Make the first month count
Your first month of AI governance can produce a small set of practical deliverables:
- Week 1: establish the inventory, owners and immediate restrictions.
- Week 2: assess the highest priority use cases and relevant obligations.
- Week 3: implement access limits, approval points and supplier actions.
- Week 4: test incident handling and recovery, record decisions and schedule reviews.
Reuse your risk register, supplier reviews and incident process. Review again when data access, models, integrations or the purpose changes. ISO/IEC 42001 can structure the management system as the programme develops; it is a standard, not an EU law.
Reviewed on 5 October 2026. The framework links above lead to official EU guidance. The two Interian infographics are discussion aids.
