A Practical Framework to Govern AI with Confidence

Most AI governance programmes fail for the same reason: they are written by compliance teams and ignored by the people actually using the tools. The result is a policy document that sits in SharePoint while employees paste customer data into unapproved LLMs, developers wire AI agents directly into production systems, and nobody can say with certainty where company data is ending up.

If you are a CISO, this is not a governance problem. It is a control problem. And it is your control problem, because when an AI-generated decision goes wrong, a data breach originates from an AI tool, or a regulator asks for evidence of AI risk management, the policy document will not protect you.

Six-pillar AI governance framework with maturity pathway and quick wins.

This article translates high-level AI governance into specific, actionable controls across six pillars. It is built from work we have done with organisations moving from ad hoc AI use to managed, auditable, and eventually optimised AI operations. The goal is not perfect governance on day one. The goal is to know where you are, block the worst risks immediately, and build operational maturity over 90 days.

Know Where You Are on the Maturity Curve

Before you write a single policy or deploy a technical control, you need an honest assessment of your current state. Most organisations fall into one of four maturity levels:

Level	Characteristics	Typical Evidence
Ad Hoc	No policy, no inventory, no visibility	Employees using ChatGPT with corporate data; no one can name the AI tools in use
Defined	Policies drafted, inventory started, pilots controlled	An AI use policy exists but is not enforced; approved tool list covers 60% of actual usage
Managed	Controls enforced, logging active, board visibility	All AI traffic routes through approved gateways; monthly AI risk reports to leadership
Optimised	Continuous improvement, regulatory-ready, trusted AI ops	Automated risk scoring; red-teaming programme; AI incidents treated like security incidents

Be honest. If you are at Ad Hoc, which describes roughly 60% of organisations, your first job is not to build a perfect framework. It is to stop the bleeding: discover what AI tools are in use, block the highest-risk ones, and establish basic data boundaries. That's significant progress, everything else can and will come after.

If you are at Defined, your challenge is enforcement. You probably have good documents and a partial inventory. The gap is between what the policy says and what actually happens when a developer wants to use a new AI coding assistant or a marketing team experiments with image generation.

Pillar 01: AI Risk Classification

Not all AI use is equally dangerous. A marketing team using an approved LLM to rewrite email subject lines carries different risk from an AI agent with write access to your CRM, which carries different risk again from AI-generated medical or legal advice. Your first operational task is to classify use cases by tier.

Build a Tiered Risk Taxonomy

Use three tiers at minimum. Complexity kills adoption, so keep it simple:

Tier 1 - Prohibited: AI use cases that are banned outright. Examples: uploading customer PII to public LLMs; using AI for automated credit decisions without human review; deploying AI agents with uncontrolled write access to production systems.

Tier 2 - Permitted with Controls: Approved use cases that require specific safeguards. Examples: code generation with approved tools; internal document summarisation; customer-facing chatbots with defined escalation paths.

Tier 3 - Low Risk / Self-Service: Use cases with minimal risk that can proceed with standard terms. Examples: grammar checking; internal meeting transcription with approved vendors; image generation for marketing collateral using public data.

Create a Prohibited vs. Permitted Use Registry

This is a living document, not a one-time exercise. It should be accessible to every employee and referenced in your Acceptable Use Policy. For each permitted use case, define:

Which tool(s) are approved

What data classifications can be used (public, internal, confidential, restricted)

Who can approve exceptions

What logging is required

Score Third-Party AI Vendors

Most organisations use AI through vendors rather than building models themselves. Each vendor should receive a basic risk score based on:

Data handling: Do they train on your inputs? Where is data processed and stored?

Security posture: Do they have SOC 2 Type II, ISO 27001, or equivalent?

Model provenance: Can they explain what the model was trained on and how it is updated?

Exit provisions: Can you extract your data and configuration if the relationship ends?

A practical shortcut: require the same due diligence for AI vendors that you require for any other critical SaaS supplier, with one addition - a specific review of how they handle model inputs and whether those inputs are used for training.

Pillar 02: Data Governance and Privacy

Data is where AI governance becomes concrete. An AI tool without data is just an interface. The risk emerges when sensitive data flows into models, training datasets, or prompts that the organisation does not control.

Map Training Data Lineage

If your organisation is training or fine-tuning models, you need to know what data went in. This sounds obvious, but in practice, data scientists often assemble training sets from multiple sources - internal databases, purchased datasets, scraped web content - without documenting provenance.

Your minimum viable controls:

Maintain an inventory of all training datasets with source, licence terms, and data classification

Document consent status for any data containing personal information

Review synthetic data generation - data created by AI to train other AI - because it can amplify bias or hallucinations

Establish PII and PHI Exposure Boundaries

The most common AI data breach is not sophisticated. It is an employee pasting a customer support ticket, a medical record, or a financial statement into a public LLM to "get a quick summary." The model provider now has that data, and depending on their terms, may use it to improve their model.

Your technical controls should enforce:

Automatic detection of sensitive data in prompts using DLP-style scanning at the point of AI tool access

Blocking or alerting on classified data before it reaches external models

Approved internal-only tools for sensitive data, such as self-hosted or private-cloud deployments

Defend Against Prompt Injection and Data Leakage

Prompt injection is an attack where malicious input causes an AI system to ignore its instructions and reveal data or execute unintended actions. If you have AI systems processing untrusted input - customer emails, web content, user-generated data - this is a real and present risk.

Practical mitigations:

Input validation and sanitisation on all data fed to AI systems, treating it like any untrusted input

Output filtering to prevent AI systems from revealing system prompts, internal instructions, or sensitive data

Strict separation between the context window (what the model knows) and any actions it can take (API calls, database queries)

Human-in-the-loop for high-risk actions - never let an AI agent execute financial transactions, send emails externally, or modify customer records without approval

Define Retention Policies for AI Interactions

AI conversations often contain sensitive business information, yet they are rarely covered by standard data retention policies. Decide:

How long are AI interaction logs retained?

Who can access them?

Are they subject to the same e-discovery and legal hold processes as email?

If you do not answer these questions, a future legal case or regulatory inquiry will answer them for you, and you may not like the result.

Pillar 03: Identity and Access Control

AI tools need the same identity discipline as any other system, with one crucial difference: they are often adopted outside of IT procurement, meaning they bypass your standard identity and access management controls.

Enforce Role-Based AI Tool Entitlements

Not everyone needs access to every AI capability. Define entitlements based on role:

Role	Typical AI Access
Software Engineer	Approved coding assistants; documentation tools; no customer data
Marketing	Content generation; image creation; public data only
Customer Support	Approved internal knowledge base AI; no direct customer PII in external LLMs
Finance	None without specific approval; high risk of regulated data exposure
Executive	Broad access but with enhanced logging and review

Implement Agent Identity and Least-Privilege Design

If you deploy AI agents - autonomous systems that can take actions - treat them as users. Each agent should have:

A distinct identity in your identity provider

Least-privilege access scoped to exactly what it needs to do its job

Audit logging of every action it takes

A defined owner who is accountable for its behaviour

An AI agent with administrator credentials is not a productivity tool. It is an unmonitored insider threat.

Require MFA and Session Controls for AI Platforms

Any AI platform handling corporate data should require multi-factor authentication. Session timeouts should be shorter than standard business applications, because AI tools often have access to or process sensitive information in real time.

Shadow AI Discovery and Enforcement

This is where most governance programmes fail in practice. You cannot govern what you cannot see. Shadow AI - employees using unapproved AI tools without IT or security knowledge - is endemic in most organisations.

Discovery methods that actually work:

Network traffic analysis: Look for DNS queries and HTTPS traffic to known AI services (OpenAI, Anthropic, Google AI, Perplexity, Cursor, and dozens of others). This will not catch everything, but it catches the bulk of usage.

Proxy and firewall logs: If traffic routes through your corporate proxy, you can identify AI service access by URL patterns and TLS inspection where permitted.

Browser extension and endpoint agents: Some endpoint detection tools can identify browser access to AI services, even without full proxy coverage.

Financial audit: Review expense reports and corporate card transactions for AI tool subscriptions. You will be surprised what you find.

Survey and self-reporting: Ask teams what they are using. Frame it as "help us support you better" rather than "confess your sins" to get honest answers.

Once discovered, you have three options for each tool:

Block - for high-risk tools that violate policy

Approve and onboard - for tools that serve a legitimate purpose and can meet your security requirements

Replace with an approved alternative - for tools that serve a real need but do not meet your risk threshold

The key is speed. If it takes three months to approve a tool, employees will route around you. Aim for a two-week approval process for low-risk tools, with a clear escalation path for edge cases.

Pillar 04: Observability and Audit

If you cannot observe it, you cannot govern it. AI systems need the same audit discipline as financial systems, medical devices, or safety-critical infrastructure - because for many organisations, they are becoming equally consequential.

Centralise AI Activity Logging

Every interaction with an approved AI tool should generate a log entry containing:

User identity

Timestamp

Tool used

Input classification (if DLP scanning is in place)

Action taken (prompt submitted, response received, API call made)

This does not mean logging the full text of every prompt, which creates its own privacy and storage issues. It means logging enough metadata to answer questions like: "Who in the finance team has been using AI tools this month?" and "Did anyone attempt to process restricted data through an unapproved model?"

Monitor for Model Drift and Anomaly

If you run your own models or rely on model APIs for production decisions, you need to detect when model behaviour changes:

Output quality monitoring: Track accuracy, hallucination rates, or error rates against a held-out validation set

Input anomaly detection: Flag unusual patterns in prompts that might indicate probing, injection attempts, or misuse

Latency and availability monitoring: AI services fail like any other infrastructure

Meet Explainability Requirements Per Use Case

Regulators and auditors increasingly ask: "How did the AI reach this decision?" Your explainability requirements should scale with risk:

High-risk decisions (hiring, lending, medical recommendations): Full explainability required, with human review mandatory

Medium-risk decisions (customer routing, content moderation): Summary explanations with sampling-based human review

Low-risk decisions (email prioritisation, spell checking): No specific explainability requirement beyond standard logging

Build Regulatory Evidence Collection

When the EU AI Act, sector regulators, or your audit committee asks for evidence, you need to produce it quickly. Maintain:

A risk register of all AI use cases with their classification tier

Evidence of controls - logs, access reviews, penetration test results

Incident records - any AI-related errors, breaches, or near-misses

Training records - who has received AI security and governance training

Pillar 05: Culture and Accountability

Technology controls are necessary but not sufficient. If your culture treats AI as a free-for-all productivity hack, controls will be bypassed. If it treats AI as forbidden magic that only special teams can touch, you will drive usage underground and lose the benefits.

Publish an AI Acceptable Use Policy

This should be a short, practical document - not a 40-page legal contract. It needs to answer three questions that employees actually have:

What can I use? - The approved tool list and how to request additions

What can I put into it? - Clear data classification guidance (e.g., "public and internal data only in approved external tools; confidential data only in on-premise tools")

What happens if I get it wrong? - Consequences for intentional misuse, and a safe reporting path for mistakes

Publish it where people will find it. Your intranet security page is not where people will find it. Link it from the AI tools themselves, from Slack channels, and from onboarding materials.

Run Mandatory Security Awareness Training

AI-specific training should cover:

Data exposure risks - real examples of organisations that leaked sensitive data through AI tools

Prompt injection basics - what it is and why untrusted input to AI systems is dangerous

Hallucination awareness - AI generates confident nonsense; never treat AI output as fact without verification

Approval processes - how to request new tools and why the process exists

Training should be refreshed at least annually, or quarterly if AI use is expanding rapidly.

Assign Clear Ownership

Every AI system needs an owner. For each approved tool or use case, define:

CAIO or AI Risk Owner: The executive accountable for AI governance overall

System Owner: The person accountable for a specific AI system or tool

Technical Owner: The person responsible for implementation, security, and maintenance

Business Owner: The person who requested the capability and defines success criteria

If you cannot name these four people for an AI system, it should not be in production.

Prepare Incident Response for AI Failures

AI failures are security incidents. A model that starts generating harmful content, an AI agent that takes unauthorised actions, or a data leak through an AI tool should trigger your incident response process.

Add AI-specific playbooks:

Model compromise or manipulation: How to isolate, roll back, and investigate

Data leakage via AI tool: Notification, containment, and vendor escalation procedures

Hallucination in customer-facing systems: How to identify affected users and correct misinformation

Regulatory inquiry: Who responds, what evidence to prepare, and legal escalation paths

Pillar 06: Regulation and Standards

Compliance is not the goal, but it is a constraint you must operate within. The good news is that most AI regulations map cleanly onto the controls described above.

Map EU AI Act Obligations

If the EU AI Act applies to you, your risk classification work directly feeds compliance:

Prohibited AI practices: Your Tier 1 list should include the Act's prohibited uses

High-risk systems: Your Tier 2 systems need the full conformity assessment, risk management system, data governance, and human oversight requirements

Transparency obligations: Your logging and explainability controls provide the evidence

Align with NIST AI RMF

The NIST AI Risk Management Framework provides a useful structure for organisations not directly subject to the EU AI Act. Its four functions - Govern, Map, Measure, Manage - map closely to the pillars described here.

Address ISO/IEC 42001 Readiness

ISO/IEC 42001 is the emerging standard for AI management systems. If your organisation is already ISO 27001 certified, the gap to 42001 is manageable but not trivial. Key additions include:

AI-specific risk assessment processes

Impact assessments for AI systems

Lifecycle management of AI models, including retirement and data deletion

Stakeholder communication about AI use and risk

Track Sector-Specific Rules

Finance, healthcare, and critical infrastructure each have sector-specific AI guidance emerging. Do not wait for final regulations. Map your current AI use against draft guidance and industry body recommendations, and address the gaps proactively.

The 90-Day Fast Start

If you are starting from ad hoc or defined maturity, here is a concrete 90-day plan:

Days 1-30: Stop the Bleeding

Publish an AI Acceptable Use Policy - even if it is imperfect; you can refine it later

Inventory all AI tools in use - network scan, financial audit, and employee survey

Block unapproved LLM endpoints at the proxy or firewall - this is the single highest-impact technical control

Define a data classification baseline - what can and cannot go into external AI tools

Assign an AI Risk Owner - one person accountable for the programme

Days 31-60: Build the Foundation

Onboard approved tools with centralised logging - route all AI access through a gateway or proxy

Implement DLP scanning at AI tool boundaries - block sensitive data before it reaches external models

Run a tabletop exercise - simulate an AI incident (data leak, model failure, regulatory inquiry) and identify gaps

Begin vendor risk scoring - assess your top five AI suppliers

Deliver initial AI security training - focus on data exposure and approval processes

Days 61-90: Operationalise

Enforce role-based access - not everyone gets everything

Establish monthly AI risk reporting - to security leadership and, where appropriate, the board

Create the risk classification registry - document every AI use case and its tier

Draft incident response playbooks - for AI-specific failure modes

Begin regulatory mapping - identify which frameworks apply and where your gaps are

What Boards Should Ask

If you are presenting AI governance to your board or audit committee, anticipate these questions:

Do we know what AI tools are in use across the organisation? If the answer is "we have a list of approved tools," push further. Do you know what is actually being used?

What data is being processed by AI systems, and where does it go? This is the question that separates governance theatre from real control.

Who is accountable when an AI system causes harm? If the answer is a shrug or a committee name, you have a problem.

Are we ready for regulatory examination of our AI practices? The EU AI Act and emerging UK requirements are not abstract future concerns. They have enforcement timelines.

What is our incident response plan for AI failures? Most organisations have a data breach playbook. Few have one for model manipulation, hallucination at scale, or autonomous agent misbehaviour.

The Bottom Line

AI governance is not a special, mystical discipline. It is security governance applied to a new class of tools that process information and take actions at scale. The same principles apply: know your assets, classify your risks, enforce your boundaries, log what happens, and hold people accountable.

The organisations that get this right will treat AI governance as an operational programme, not a compliance exercise. They will discover their shadow AI, block the dangerous paths, approve the useful tools, and build continuous visibility. They will be able to tell their boards, regulators, and customers exactly how AI is used, what the risks are, and how they are managed.

The organisations that get it wrong will discover their AI risks through incident, regulatory action, or reputational damage. The difference is not budget or technology. It is whether the CISO treats AI governance as a priority now, or waits until the problem arrives uninvited.

Our AI Governance Setup package delivers a working programme in 3-4 weeks →