AI governance framework: from principles to implementation

An AI governance framework consists of rules that dictate how an organisation develops, deploys, and monitors AI systems. It specifies who holds responsibility for approvals, which standards the organisation adheres to, how risk is evaluated, and which processes stop biased models or insecure RAG pipelines from reaching customers. Most organisations do not have this structure. Instead, they depend on informal communication, for example requesting legal approval through a Slack channel.

An AI governance framework comprises rules that guide how an organisation develops, deploys, and monitors AI systems. It outlines who is accountable for approvals, which standards must be complied with, how risks are evaluated, and which processes block biased models from being released to customers. Most organisations do not have such a framework, and this is a main reason why pilot projects frequently do not advance to production.

At Shipshape Data we observe this gap continuously. A team creates a truly useful pilot, becomes enthusiastic, and deploys it before anyone has decided who owns the model, the source of the training data, or the response when it errs in front of a customer. Approximately seventy per cent of AI projects never transition from pilot to production, and unclear accountability is among the primary causes. This article guides the construction of a usable framework: why it matters, how to design it, the relevant standards, the additional attention required for generative AI and RAG systems, templates you can adapt directly, and how to assess whether the entire process is effective or merely adding paperwork.

Why governance breaks down before it starts

AI initiatives function without clear guidelines when a framework is absent.

A team chooses to release a model because they received no contrary instructions. The compliance department learns of this only at launch, when implementing changes is costly and difficult. Leadership does not have a clear overview of which models process customer or employee data, causing each incident to be unexpected. No one identified the risks before they occurred.

The specific protections a framework provides

Governance preserves existing value by preventing harm to reputation, regulator fines, and operational failures that erode trust.

The framework records data lineage, model logic, and the rationale for a decision. This enables an auditor to verify the process. It also gives a customer disputing an automated outcome the information needed to challenge it.

This process boosts speed, despite the common belief that governance only creates delays. Pre-agreed risk tiers and approved patterns guarantee that low-risk chatbots are not placed in the same queue as credit-scoring models. Teams no longer need to guess whether sign-off is required because the boundaries are documented. This eliminates the need to debate requirements for each new project.

The UK's Department for Business and Trade's internal AI governance process examined 28 submissions. Almost all were returned with required changes, often relating to improperly mapped data flows and missing data protection impact assessments. These assessments ought to have been completed before any code was written. This shows the framework is working as intended, spotting issues when they are cheaper to fix, rather than after a launch that demands incident reports and compliance meetings.

Scope and risk tiers come before roles

Identify the items you are governing before assigning a single owner. Create a list of every AI system you currently use or intend to use. The list must include pilot programmes without formal approval, production tools in active use, and third-party AI services integrated into your existing software that vendors may have marketed as standard features. Record each system's purpose, its data source, the presence of a human in the decision-making process, and the groups of people it impacts. This inventory often uncovers unexpected information. We have worked with operations leads who did not know that their customer service platform had enabled an AI drafting feature six months earlier.

Draw the boundary

Draft a written document that defines which systems require oversight. Most organisations include any technology that handles customer data, influences business outcomes, or makes decisions about individuals. Simple automation, systems that follow fixed rules without learning, and low-risk internal tools typically fall outside this scope. You must document these inclusion and exclusion criteria clearly. Vague definitions lead teams to ignore governance processes. If a team cannot decide within five minutes whether their project needs approval, they are likely to bypass the requirement.

Tier the risk

Not every AI system warrants the same scrutiny, and treating them uniformly is how governance becomes bureaucracy that no one respects. Establish three to five tiers based on data sensitivity, decision reversibility, regulatory exposure, and potential harm. A credit decision engine, a hiring filter, or a medical triage tool sits at the top: executive sign-off, thorough testing, ongoing monitoring. A recommendation widget on your internal wiki sits at the bottom: minimal documentation, a technical lead's nod, and done. Match the effort to the risk, or the framework will collapse under its own weight within a year.

Give governance real names

Governance frameworks fail when ownership is not clearly defined. "The AI team" is not an accountable entity because individual members do not feel responsible for the final outcomes. You must designate a specific owner for every AI system. This person authorises the deployment and remains responsible for the system's performance while it is active. You should also appoint data stewards. These individuals verify the accuracy of source data and ensure that data is deleted according to the retention policy. Finally, assign a single person to manage the framework. This person tracks submissions, follows up on late reviews, and updates the documentation whenever regulations or internal rules change.

Assign specific authority to every role

Assigning ownership without granting authority is ineffective. An AI owner must have the power to approve low-risk changes independently and a defined process to contact a review board for high-stakes decisions. A data steward requires the authority to halt a deployment if they identify a quality issue. Reporting a problem and waiting for others to intervene is insufficient. You must document these escalation paths. Without them, responsibility becomes diffused, leading to audit failures where each participant assumes another person is monitoring the component that eventually fails.

Governance fails when accountability is assigned to a team rather than an individual. You must name a specific person.

Build the operating procedures around it

Begin with a submission process that captures every governance decision point in a single form or workflow: data provenance, model explainability, bias testing, privacy impact, and security controls. Automatically route submissions by risk tier and functional area. Do not leave triage to whoever happens to read the inbox first. The Department for Business and Trade's form also did something useful: it prevented teams from duplicating existing data protection impact assessments and directed them to the correct protocol before they had built anything.

We need to define document approval criteria and timelines so teams know what to expect before they submit work, rather than discovering issues after feedback. We will require two peer reviews for systems we identify as high-risk, and we will issue a public notice to ensure transparency. These systems will also undergo audits every three months. We will set service levels for approvals: low-risk systems will be approved within five working days, and high-risk systems within three weeks. We also need to address ongoing governance. This includes identifying events that require a re-review-such as a significant model update, the introduction of new data, or a change in regulations-and defining the process for managing systems that are no longer in use.

The relevant standards

You do not have to create a new framework. A few existing models will meet most requirements. It is standard practice to combine two or three of these models rather than choosing only one.

Risk-based regulation: the EU AI Act and the UK's approach

The EU AI Act sorts AI systems into four tiers, unacceptable, high, limited and minimal, and bans some outright, including social scoring and real-time biometric surveillance in public places. Run high-risk AI in healthcare, employment or financial services inside the EU and you face binding obligations on transparency, human oversight and formal conformity checks, backed by fines that reach €35 million or 7% of global turnover. This is not guidance you can treat as optional. You need a process that classifies every use case correctly and gets the required controls in place before anything ships, not after a regulator asks.

The UK has gone a different way. Its pro-innovation approach rests on five principles, fairness, transparency, accountability, safety, and contestability, and it deliberately avoids the EU's prescriptive detail, leaving sector regulators to apply the principles to their own patch. That gives you room to move without the EU's compliance load, but you get less concrete guidance on what compliance looks like day to day, which means more of the interpretation lands on you.

NIST, OECD, and FINOS

The NIST AI Risk Management Framework is the practical option: four functions, govern, map, measure, manage, applied to any AI system regardless of sector. It is popular with US enterprises for a good reason. It hands you practical playbooks, so a team can pick it up and use it on an ordinary Tuesday morning without a consultant in the room. The OECD Principles sit at the other end of the spectrum, high-level and human-centric, adopted in some form by more than forty countries. Reach for OECD when you need to show international alignment, and for NIST or a sector standard when you need to show your working. FINOS is narrower again, built for financial services, with deep requirements around visibility into model behaviour, user interactions and security controls. Most organisations we work with layer these: NIST for structure, OECD for the top-line commitments, EU Act compliance bolted on wherever it applies to their business.

Where generative AI and RAG break the old rules

Everything above was written for AI that behaves predictably: same input, same output, testable in the ordinary sense. Generative models and retrieval-augmented systems don't play by that rule, and a framework built for traditional machine learning will miss most of what goes wrong with them.

Non-deterministic outputs and prompt injection

Generative models cannot be tested exhaustively because the same prompt may produce different results at different times. Governance frameworks must establish acceptable operating ranges. These include toxicity thresholds, factual grounding requirements, and bias indicators that initiate human reviews or automatic blocks. System prompts and temperature settings must be managed through version control. This configuration requires formal sign-off, as it directly alters production behaviour.

Prompt injection occurs when a user provides input that causes a model to ignore its instructions or reveal restricted information. You must require input sanitisation, output filtering, and the use of prompt templates that isolate user content from system instructions. Define which individuals have the authority to modify base prompts and establish a process for testing those changes before they are deployed to production. The previous example regarding the Department for Business and Trade is relevant. Most of its generative AI submissions required revisions after reviewers looked for risks specific to large language model failures instead of using traditional model checklists.

Data boundaries in RAG systems

A RAG system answers questions by retrieving information from a knowledge base. The primary governance requirement is to control which sources the system can access. You must define the specific documents, databases, and APIs available to each system. Ensure that the retrieval process follows the access permissions that are already established within the organisation.

A customer support chatbot should not reveal internal financial models because of a poorly written prompt.

Decisions about chunking and embedding are matters of governance rather than just engineering. These choices determine what the system retrieves and how much context remains during the process. You must approve which embedding models may process sensitive content. You also need to decide how to split documents to maintain context while avoiding excessive retrieval. Attach metadata that supports fine-grained access control. Track the lineage from the source document through the embedding to the final answer. This allows you to trace the source if an output is incorrect. Establish a specific trigger for re-indexing when source data changes. Determine who has the authority to add new sources to the retrieval corpus. Periodically verify that retrieved chunks actually support the claims made by the model. Models will generate plausible but incorrect information when the underlying data is insufficient.

Useful policies, templates, and approval workflows

Creating every policy from scratch is an inefficient use of time. You should use existing structures and then modify them to match your specific risk tolerance.

Policy structure

Begin with a model approval policy. This policy should state who reviews submissions, what documentation is required, and the expected approval timeframe. It must cover the policy's purpose and scope, define roles and responsibilities, outline approval criteria based on risk tier, explain the escalation process, and specify how often each decision will be revisited. A high-risk approval generally requires executive sign-off, two separate technical reviews, legal clearance, and a quarterly audit. A minimal-risk system only requires authorisation from a technical lead and an annual review.

Pair that with a data governance policy written specifically for AI: training data quality, retention, access control, lineage. State that training datasets need provenance documentation and bias testing on record before use. Be explicit about which data classifications AI systems are allowed anywhere near, how you handle synthetic data, and who approves a new data source before it feeds a production model.

Approval workflows that do not cause delays

Assign routes based on risk levels. Do not place all requests into a single queue.

A useful shape:

• Low risk: one technical reviewer will check basic security and data compliance within three working days.
• Medium risk: include a legal review and a privacy screening. This process takes ten working days.
• High risk: a complete group including members of the governance board, security, legal, compliance, technical design authority, and business ownership will be needed, for up to three weeks.

Document your decision criteria so that two different reviewers will reach the same conclusion when presented with the same evidence. Specify the explainability requirements for high-risk models and the different bias testing standards for hiring tools compared to content recommenders. Define the specific conditions under which a residual risk is acceptable and when it must prevent a deployment.

The parts people forget

Monitoring continues after deployment. You should establish alert thresholds for accuracy loss, prediction drift, and unusual input patterns. Create an incident response procedure that identifies who to notify if the system generates harmful output, the required response time, and the subsequent steps. Include protocols for version control and change management regarding model updates. Document the decommissioning process, including methods for data deletion, before the procedure is required.

Measuring performance and maintaining the system

A framework that lacks measurement provides only speculation. Track the number of submissions, the time required to approve them at each level, and the rate at which systems are flagged for changes compared with those approved on the first attempt. Also monitor operational signals like bias incidents discovered in production, drift alerts, and audit results. These data points together show whether governance is effectively identifying problems or merely generating documentation after issues occur.

Metrics that provide useful information

Process metrics show whether governance is effective or obstructive. These cover the average time required for approval at each level, the percentage of rejected proposals, and how often teams bypass the official process. The last metric represents the most significant concern. A high rejection rate usually suggests that the instructions are confusing rather than the proposals being poor. Slow approval times generally point to a need for additional reviewers or a more efficient workflow rather than more rigorous rules.

Compliance metrics, audit pass rates, regulatory findings, and the percentage of live systems with complete documentation show whether your records would hold up during an audit. Risk realisation metrics give a more direct assessment: privacy breaches linked to an AI system, bias complaints, and performance failures, together with their associated costs. Compare these outcomes with the predictions made in your pre-launch risk assessments. A significant difference points to an error in your risk tiering. Chance does not sufficiently explain large discrepancies.

Review it on a schedule, or it rots

Schedule a quarterly review: check the metric trends, adjust risk tiers as new threats appear, and tighten or loosen approval criteria based on what actually happened. Bring the AI owners, data stewards, legal, and technical leads together and ask what is creating friction, because the policies teams quietly ignore are telling you something worth hearing. Run a full annual review of the entire structure, incorporating regulatory changes, new capabilities such as agentic systems, and whatever you have learned from other organisations' governance failures, which tend to be more instructive than their successes.

Update the document whenever your processes change. When you deploy your first generative AI application, update the templates to include prompt controls. When pilot programmes move into production, adjust the service tiers to reflect the systems currently in use. Do not rely on theoretical versions written eighteen months ago that remain unreviewed.

How to begin work on Monday morning

None of this is complicated in principle.

This work is not prestigious, and it needs a specific person to take responsibility for it. This step is often ignored in favour of creating policy documents that go unused. You should start by documenting your current active processes. Assign specific individuals to defined roles. Choose the standards that align with your legal requirements rather than those that are marketed most effectively.

We help organisations build governance frameworks that work with their existing data infrastructure. We do not apply generic templates after the fact, particularly when generative AI or RAG systems have introduced new risks. If you need an assessment of your current gaps before writing any policies, talk to us.

If you are figuring out how this applies to your organisation, our AI strategy service can assist you in identifying a profitable initial use case and planning the sequence for later projects.

Frequently asked questions