AI governance: why AI transformation is a problem of governance

“AI transformation is a problem of governance” has become a slogan, and like most slogans it is half right. The software is easy to buy; deciding who owns it, what data goes into it, who checks what comes out and who answers when it goes wrong is the hard part. This guide turns AI governance into something a small or mid-sized company can actually run: owners, a policy, an inventory, model and data risk, the main frameworks at a glance — and AI risks written as entries in your risk register.

By Alex Martyushin, founder & risk consultant · Updated 30 October 2026 · 14 min read

Why AI transformation is a problem of governance

The phrase went viral on social media because it named something many teams had felt: the pilot worked, the demo impressed the board, and then nothing scaled — or, worse, it scaled quietly without anyone deciding it should. The technology was rarely the blocker. The blockers were questions nobody had been asked to answer.

• Who owns it? A chatbot on the website belongs to marketing, uses customer data owned by operations, runs on a supplier contract signed by IT, and produces answers that legal will have to defend.
• What may go into it? Staff paste contracts, customer emails and spreadsheets into public AI tools because it saves time and no one told them not to.
• Who checks what comes out? An AI-written summary, quote or code change looks finished. Without a defined review step, it is shipped as it is.
• Who is accountable when it is wrong? “The AI said so” is not a defence a regulator, customer or court will accept.
• Is it allowed? Data protection law, sector rules, contracts with customers and, increasingly, AI-specific law all apply.

These are governance questions in the plain sense of risk management: decisions about authority, accountability, appetite and control. That is good news for a small company, because it means you do not need a data science team to govern AI well. You need the same discipline you already apply to money, data and health and safety.

What AI governance covers

Definitions vary, but every serious framework covers roughly the same ground. The table translates it into the minimum a smaller organisation should have.

AI governance sits inside your wider data governance framework and your risk framework, not beside them. A separate “AI committee” with its own spreadsheet is usually the first sign the programme will not last.

Ownership: who does what

Most AI failures in smaller companies trace back to diffuse ownership. A simple split that works:

Write your appetite down. A line in your risk appetite statement such as “we use AI to improve productivity and service, but we do not allow AI to make final decisions about customers, staff or payments without human review” gives every manager a test to apply.

An AI use policy people will read

Long policies are ignored. A useful AI use policy fits on two pages and answers six questions:

1. Which tools are approved? Name them, and say how to request a new one. Business accounts with data protection terms beat free personal accounts.
2. What data must never be entered? For example: customer personal data in unapproved tools, payment card data, passwords and keys, health data, unpublished financial results, confidential client documents.
3. What needs human review? Anything sent to a customer, published, used in a contract, used in a decision about a person, or deployed as code.
4. When must AI use be disclosed? To customers interacting with a chatbot, in content where it matters, and internally on work products.
5. Who approves new uses? Low-impact internal uses can be self-service; anything touching customers, staff decisions or regulated activity goes to the governance owner.
6. How are problems reported? A single route for errors, data leaks and suspected misuse, treated like any other incident.

The AI inventory

You cannot govern AI you do not know about. AI now arrives inside software you already pay for — CRM, helpdesk, office suites, accounting packages — often switched on by default. For each use case, record:

• The tool and supplier, and whether the AI feature is built in or separate.
• The business purpose and the use-case owner.
• What data goes in, including whether it contains personal or confidential data.
• Who or what is affected by the output: staff only, customers, the public.
• Whether a human reviews the output before it is used, and who.
• The supplier’s terms on data retention and use of your data for training.
• An impact rating (low, medium, high) and the next review date.

The impact rating drives everything else. An internal tool that summarises meeting notes is low impact. A model that screens job applicants, sets prices for individual customers or decides on credit is high impact — and may also fall into a regulated category.

Model risk: what can go wrong with the AI itself

Model risk is the risk that a model’s output is wrong or misused in a way that causes harm. It is not new — banks have managed it for credit models for years — but generative AI widens it to every department.

AI also changes your external threat picture: attackers use it to write convincing lures and clone voices. That belongs in your phishing risk and cybersecurity risk assessment, not only in AI governance.

Data: the part regulators already enforce

Before any AI-specific law, data protection law already applies to AI that uses personal data. Under UK GDPR and EU GDPR you need a lawful basis, transparency about how personal data is used, data minimisation, security, and a data protection impact assessment where processing is likely to result in a high risk to individuals. Article 22 restricts decisions based solely on automated processing that have legal or similarly significant effects on people. The UK Information Commissioner’s Office publishes guidance on AI and data protection, and in Australia the Privacy Act 1988 and the Australian Privacy Principles apply to personal information used in AI systems.

Three practical checks cover most of the exposure for a smaller company:

• Supplier terms. Does the provider use your inputs to train its models? How long does it keep prompts and outputs? Where is data processed? Business tiers usually offer better terms than free ones.
• Data rules in the policy. Map your existing data classification to AI: what may go into which tool.
• Impact assessments for high-impact uses. Anything that profiles customers or makes decisions about people needs a documented assessment before launch — the GDPR compliance checklist covers the mechanics.

EU AI Act, NIST AI RMF and other frameworks at a glance

You do not need to adopt every framework. Know which apply to you by law, and borrow structure from the voluntary ones.

The EU AI Act in brief

The EU AI Act entered into force on 1 August 2024 and applies in stages. It sorts AI uses by risk:

• Prohibited practices — such as social scoring, certain manipulative techniques and untargeted scraping of facial images — have been banned since 2 February 2025. The AI literacy duty in Article 4 has applied since the same date; amendments adopted in 2026 softened it to a duty to take measures that support AI literacy among staff.
• General-purpose AI model obligations for model providers have applied since 2 August 2025.
• Transparency duties under Article 50 — for example telling people they are interacting with an AI system, and marking certain AI-generated content — began to apply in August 2026; check the current text for any transitional periods on content marking.
• High-risk systems — uses listed in Annex III such as recruitment, credit scoring, education and access to essential services — face the heaviest obligations. Amendments to the Act adopted in 2026 moved the application date for Annex III systems from 2 August 2026 to 2 December 2027, and for AI embedded in regulated products (Annex I) to 2 August 2028.

Most SMEs are deployers (users) rather than providers. The deployer duties for high-risk systems include using them in line with the provider’s instructions, assigning competent human oversight, monitoring operation and keeping logs. Fines for prohibited practices can reach €35 million or 7% of worldwide annual turnover, whichever is higher, with lower caps for other breaches and adjusted rules for SMEs. Because the timetable has already changed once, check the current dates before you plan around them.

The NIST AI RMF in brief

NIST published the AI Risk Management Framework 1.0 in January 2023. It is voluntary and free, and its four functions map neatly onto an ISO 31000-style process: Govern (culture, roles, policies), Map (context and intended use), Measure (analysis and testing) and Manage (prioritise and treat). The US AI Action Plan of July 2025 directed NIST to revise the framework; as of October 2026 version 1.0 remains the current published version. For how it compares with ISO 31000, COSO and other frameworks, see risk management frameworks compared.

AI risks as risk register entries

The single most useful step is to stop treating AI as a separate world. Write AI risks as cause–event–consequence statements and score them on the same risk matrix as your other risks, so the board can see whether an AI risk is bigger or smaller than, say, a supplier failure.

Scores are illustrative residual scores on a 5×5 matrix. AI vendors also belong in your third-party risk assessment: ask where data is processed, whether inputs are used for training, what security certifications cover the service and how model changes are communicated.

A few key risk indicators keep it visible: AI use cases without a named owner, high-impact uses overdue for review, AI-related incidents in the quarter, and the share of staff who have completed the AI policy briefing.

A 90-day AI governance plan

Common mistakes

• Banning AI outright. It pushes use underground, where it cannot be governed. Approve good tools instead.
• A policy without an inventory. Rules for tools you have not found yet protect nothing.
• Treating all uses the same. Meeting summaries and hiring decisions need very different levels of control.
• Separating AI from the risk register. AI risks compete for the same budget and attention as every other risk; put them in the same place.
• Trusting the vendor’s marketing. Read the data terms and ask how model changes are communicated.
• “Human in the loop” on paper only. If the reviewer approves hundreds of outputs an hour, there is no real review.
• Waiting for regulation to settle. Data protection, consumer and employment law already apply today.