An internal auditor asks for two things: a list of the AI systems the company uses and the name of the person who approved each of them. IT knows the tools bought centrally, marketing pays for a content generator with a personal card, and customer service is trialling a vendor’s chatbot. Collecting the answer takes a week, and it is still unclear whether the list is complete.
This is what a company looks like when it has an AI use policy but no AI governance. The policy says what is allowed. Governance answers the questions of who decides, on the basis of what assessment and what record the decision leaves behind. We show a minimal model you can launch without building a new department: roles, an AI system register, an approval process and metrics.
What is AI governance and how does it differ from an AI policy and a risk framework?
AI governance is the system of decisions and accountability for artificial intelligence in a company: it defines who approves the use of AI, on the basis of what assessment, with what evidence and how the decision is monitored afterwards. It covers roles, an AI system register, an approval process and oversight of systems while they are in use.
An AI policy is one of the documents within that system. It sets rules for users: which tools are allowed, which data must not be entered into prompts, how to verify outputs. The elements of a good policy are covered in the article AI acceptable use policy. Governance ensures that the policy has an owner, is enforced and is kept up to date.
A risk framework, in turn, is an assessment method. It shows which threats to analyse and how to measure them — for language models, for example, this is what the LLM security risk framework does. Governance decides when such an assessment is mandatory, who carries it out and who accepts the residual risk.
It is also worth distinguishing governance from AI safety, which concerns whether the AI system itself operates safely and as intended. Governance is the organisational layer above that assessment. In the nFlo model it is part of the Governance, risk and compliance pillar, alongside governance of cybersecurity and data protection.
Who is accountable for AI in a company?
Accountability for AI in a company rests with the board, which accepts the level of risk, and with the owner of each AI system, who is responsible for its purpose, data and results; the other roles advise and control. The IT department should not own a system just because it set it up.
In the “AI Risk Management Framework (AI RMF 1.0)”, published on 26 January 2023, NIST states that executive leadership “takes responsibility for decisions about risks associated with AI system development and deployment” (category GOVERN 2.3). The same document requires roles and responsibilities to be documented and clear to teams (GOVERN 2.1).
In a typical company the model includes several roles. The board approves the policy and accepts high risk. The AI system owner, usually the manager of a business area, submits the need and is responsible for use. An AI committee or forum reviews requests and settles disputed cases. The CISO assesses security, the data protection officer assesses the processing of personal data, legal and compliance assess regulatory obligations, and procurement looks after contract terms with vendors.
Every activity must have one accountable person. In the “LLM AI Cybersecurity & Governance Checklist” (version 1.1 of 7 May 2024), OWASP explicitly recommends establishing an AI RACI chart — we set it out in a table later in this article.
How do you build an AI system register?
An AI system register is built as a single list of all systems that the company develops, buys and uses, with a minimal set of fields that makes it possible to assess risk and assign obligations. The register is the starting point for every other decision: you cannot classify or secure a system nobody knows about.
The NIST AI RMF lists the inventory of AI systems as a separate outcome of the GOVERN function (GOVERN 1.6), and the OWASP checklist recommends cataloguing AI services, tools and owners as well as data sources and their sensitivity. The register should also include AI features that vendors add to existing SaaS tools. These are the ones most often missed, because they do not go through procurement.
A minimal set of register fields looks like this:
| Field | What it contains | Why it matters |
|---|---|---|
| Purpose and scope of use | What the system is for and who uses it | Checking whether use stays within the approved purpose |
| Vendor and model | Who supplies the system or model, in which version | Vendor assessment, contract terms, version changes |
| Role under the AI Act | Provider, deployer or another role | Assigning the right obligations |
| Risk category | Prohibited practice, high risk, transparency, minimal | Scope of obligations and deadlines |
| Data | Categories of input and output data, personal data | GDPR assessment, information classification |
| Owner | Accountable person from the business area | One person responsible for decisions |
| Security assessment | Date and result of the review or test | Evidence that the risk has been assessed |
| DPIA / FRIA | Whether required and whether completed | Evidence that impact assessment obligations are met |
| Status | Requested, approved, in use, decommissioned | Control of the system’s life cycle |
The register does not have to start with a specialist tool. A spreadsheet with these fields and a clearly named owner works better than a platform nobody updates. The feed matters more: the register should be updated from procurement, the approval process and reviews, not from a one-off survey.
What does the approval process for a new AI system look like?
The approval process for a new AI system has seven stages: request, classification, risk and data assessment, security review, decision, monitoring and decommissioning. Each stage has an owner and leaves a record in the register, so a year later you can reconstruct who agreed to the use of the system and why.
The business owner submits the request, describing the purpose, users, data and vendor. Classification establishes the company’s role and the risk category under the AI Act, and whether the system processes personal data. The depth of further assessment depends on the classification. A tool that summarises public documents does not need the same path as a system that assesses job candidates.
The risk and data assessment covers the impact on people, data protection and contract terms with the vendor: where data is processed, whether it is used for training, how long it is retained. The security review checks accounts and permissions, integrations, logging and — for applications built on language models and agents — exposure to misuse. Technical controls for the whole environment are described in the guide AI security best practices for the enterprise.
The decision is taken at a level appropriate to the risk: the owner and the CISO for low risk, the AI committee for medium risk, the board for high risk. An approved system is monitored, and the review is repeated on a significant change. The last stage, decommissioning, is often skipped — yet the NIST AI RMF lists procedures for safely decommissioning AI systems as a separate element of governance (GOVERN 1.7).
Key takeaways:
- AI governance answers three questions: who decides, on the basis of what assessment and what record the decision leaves.
- The business owns the AI system; IT, security, the DPO and legal advise and control.
- The register also covers AI features that vendors switch on in purchased tools.
- The approval process ends with decommissioning the system, not with the decision to launch it.
How does AI governance connect to AI Act obligations?
AI governance is the mechanism through which a company meets its obligations under Regulation (EU) 2024/1689 (the AI Act): the register shows which systems fall within its scope, and the approval process assigns obligations and deadlines. Without a register, a company does not know whether, under the AI Act, it is a provider or a deployer, or which of its systems are high-risk.
The role matters because obligations depend on it. Under Article 3(4) of the AI Act, a deployer is an entity using an AI system under its authority. Most companies are in exactly this role with respect to the tools they buy. For high-risk systems, Article 26 requires deployers, among other things, to use the system in accordance with its instructions, to assign human oversight to people with the necessary competence and authority, and to monitor the operation of the system.
Some obligations translate directly into register fields. Article 26(6) requires deployers to keep the automatically generated logs that are under their control for at least six months. Article 26(7) requires employers to inform workers and their representatives before a high-risk system is used in the workplace. Article 26(9) links the AI Act to the data protection impact assessment under Article 35 of the GDPR.
Article 27 requires a fundamental rights impact assessment (FRIA) before a high-risk system is used only from specified deployers: bodies governed by public law, private entities providing public services, and those using systems for creditworthiness assessment and for pricing life and health insurance. Article 49(3) requires deployers that are public authorities to register in the EU database. That is why the “DPIA / FRIA” field in the register answers whether an assessment is required, not only whether it has been done.
As of 10 November 2026, obligations for high-risk systems listed in Annex III apply from 2 December 2027, and for systems under Annex I from 2 August 2028 (Article 113 of the AI Act as amended by Regulation (EU) 2026/1744). The full timeline and the Polish Act on artificial intelligence systems are covered in the article EU AI Act timeline. The text of the regulation is available on EUR-Lex.
How can you use the NIST AI RMF and ISO/IEC 42001 in AI governance?
The NIST AI RMF is best used as a map of what governance should cover, and ISO/IEC 42001 as a management system framework if the company wants to formalise or certify it. Both are voluntary and do not replace legal obligations, but they bring order to the work.
The NIST AI RMF divides AI risk management into four functions: GOVERN, MAP, MEASURE and MANAGE. According to the document, GOVERN is a cross-cutting function infused throughout the other three: it establishes culture, roles, policies and processes. MAP establishes the context and risks of a specific system, MEASURE assesses them and MANAGE decides on the response. For a team building governance, the list of GOVERN categories is the most useful part, because it translates into concrete provisions: inventory, roles, leadership accountability, third-party risk.
On 26 July 2024 NIST also published a profile for generative AI (NIST AI 600-1), which helps identify risks specific to these systems. On the framework’s page, NIST states that AI RMF 1.0 is being revised, so when you refer to it in your documentation, state the version.
ISO/IEC 42001 is the management system standard for artificial intelligence. A company that already has an information security management system compliant with ISO/IEC 27001 can reuse existing processes: management reviews, internal audits, document control. The model described in this article — roles, a register and an approval process — is a good starting point regardless of a later decision on certification.
How do you measure the effectiveness of AI governance?
The effectiveness of AI governance is measured by whether the register is complete and current, whether decisions are made within a predictable time and whether every system in use has an assessment appropriate to its risk. The number of policies adopted measures effort, not outcome.
The first metric is the completeness of the register, checked by comparison with other sources: invoices for cloud services, the list of applications with access to the identity directory, the results of detecting unauthorised tools. Every system found outside the register is a signal that the approval process is being bypassed.
The second metric is the time from request to decision. If approval takes too long, employees start using tools without consent and shadow AI emerges. The third is the share of systems in use that have a current risk and security assessment, together with the number of systems whose review is overdue.
It is also worth tracking decommissioning: if no system has been decommissioned for a long time, the register probably contains tools nobody uses that still have access to data. Metrics presented to the board should show a trend rather than a single snapshot.
How do you assign roles in AI governance?
Roles in AI governance are best set out in a RACI matrix in which each activity has exactly one accountable person (A), a person who does the work (R), and roles that are consulted (C) and informed (I). The role names in the matrix below can be adapted to your company, but the rule of one accountable person should stay.
| Activity | Board | System owner | AI committee | CISO | DPO | Legal and compliance | Procurement |
|---|---|---|---|---|---|---|---|
| Adopting the AI policy and risk appetite | A | I | R | C | C | C | I |
| Requesting a new AI system | I | A/R | I | I | I | I | C |
| Classification under the AI Act and company role | I | C | A | C | C | R | I |
| Personal data assessment and DPIA | I | C | I | C | A/R | C | I |
| Security review and testing | I | C | I | A/R | I | I | I |
| Vendor assessment and contract terms | I | C | I | C | C | C | A/R |
| Decision to use a high-risk system | A | R | C | C | C | C | I |
| Maintaining the AI system register | I | R | A | C | C | C | C |
| Periodic review and decommissioning | I | A/R | C | C | C | C | I |
The most common mistake is making the committee accountable for everything. The committee reviews and decides disputes, but the system owner is responsible for the system’s purpose and results, and the board for high risk. The second mistake is leaving procurement out of the matrix, so AI features enter the company with a licence renewal, without any assessment.
How can nFlo help build AI governance?
As part of the AI Act readiness and AI governance service, nFlo helps inventory AI systems, classify them under the AI Act, assign roles and obligations and design the assessment process for new systems. We start with the register, because every later decision depends on it.
The outcome is an AI system register with a risk category and the company’s role for each system, a gap analysis against obligations and deadlines, a responsibility matrix and a description of an approval process that can be sustained. Interpreting the law in a specific case requires legal advice, so we are happy to work with the client’s law firm. You can find more about our approach to this area on the AI security page and in the AI security knowledge base.
If you want to put accountability for AI in your company in order, get in touch.
What else is worth knowing about AI governance?
Does a small company need an AI committee?
It does not have to be a separate committee. In a smaller organisation, a regular meeting of the business owner, the person responsible for security and the data protection officer, which reviews the register and decides on new tools, is enough. What matters is that decisions are recorded.
Do AI features in purchased software also go into the register?
Yes. An AI feature added to a SaaS tool processes company data just like a separate system. The register should cover systems that are developed, bought and used, including AI features that vendors switch on in existing tools.
Does AI governance require ISO/IEC 42001 certification?
No. ISO/IEC 42001 describes a management system for artificial intelligence and can be certified, but the AI Act does not require certification against this standard. Many companies start with a register, roles and an approval process and decide on certification later.
Who should own an AI system?
The owner should be the manager of the business area that uses the system and is responsible for its results, not the IT department. IT and security advise and control, but decisions on purpose, data and risk acceptance belong to the business.
How often should the AI system register be reviewed?
On every significant change to a system and periodically, in line with the company’s risk review cycle. The review checks whether the classification, owner, data and safeguards are up to date and whether the system should be decommissioned.
