AI governance checklist: 12 steps for enterprise AI teams

A model breaks in production and nobody can say who owns it, where the training data came from, or who has the authority to pull it offline. That's the moment most enterprises discover their AI governance gap: during an incident, when fixing it is expensive, rather than before the damage, when it would have been cheap. A working AI governance checklist closes that gap ahead of time. It gives your team a concrete list of ownership, controls and review points to work through before a regulator, an auditor or an angry customer forces the conversation.

An AI governance checklist provides enterprise teams with a specific list of ownership details, controls, and review items to address before a regulator or an incident requires discussion of these topics. It includes risk and compliance, data management, model accountability, operational controls, and stakeholder transparency, and is structured as 12 steps from initial scoping through the ongoing review process.

At Shipshape Data, we build data and AI systems for enterprise clients. We frequently see the same pattern in these projects. A team deploys a model quickly and it functions correctly. The team then moves to other tasks. Six months later, no one can identify the owner of the model, the data used to train it, or the procedure for handling incorrect outputs. Governance is often treated as a task to complete after receiving an audit request rather than a feature included from the beginning. Repairing these issues after dozens of systems are already active is much more expensive than implementing proper governance at the start.

Regulatory pressure is increasing and will continue to do so. The EU AI Act is changing how organisations develop and use AI systems. This law imposes obligations based on the specific risk level of each system. Internal stakeholders also require assurance that models are auditable, that outputs are explainable, and that specific individuals are accountable for errors. Without a formal structure, governance becomes a collection of inconsistent practices that are difficult to verify. Managing these systems becomes more difficult as an organisation adds more models to its infrastructure.

This guide details 12 practical steps for building AI governance that works. It covers defining the scope of your governance, creating a system inventory, and establishing data lineage. It also addresses bias testing, incident response, and a review cycle to ensure ongoing accountability. Each step is designed to be actionable immediately, rather than being a purely theoretical concept.

What an AI governance checklist covers

A well-designed checklist does more than confirm compliance. It provides a common reference for every team involved with AI-including data science, legal, and the business unit using the results-throughout a system's entire lifecycle, from initial proposal to model retirement. Without this common structure, teams may apply different standards independently, and it can become difficult to determine who is responsible. This lack of clarity is not intentional. It happens when multiple people assume others are handling a particular task.

The five areas it needs to cover

AI governance consists of five overlapping areas that each involve specific obligations. Risk and compliance involves classifying AI systems based on their potential impact. This is necessary because regulations like the EU AI Act establish requirements that increase as risk levels rise. Data management requires tracing the origin and processing of data. You must ensure that data meets privacy and quality standards throughout the entire pipeline, starting from the moment it enters a warehouse.

Model accountability covers how you document decisions, track performance over time, and handle drift or bias once a system is live. Operational controls define who has the authority to deploy a system, pause it, or roll it back, which sounds obvious until an incident happens at 2am and three people are all waiting for someone else to make the call. Stakeholder transparency is the last piece: being able to explain what your AI does, in plain terms, to an auditor, a customer or your own board, without reconstructing the whole picture from scratch under time pressure.

How it fits into your wider AI programme

Your team should use this checklist at every major milestone rather than filing it away after one use. You should refer to it when you onboard a new model, expand a model into a new use case, or respond to an incident. The 12 steps listed below correspond to the five areas previously mentioned. Scope, inventory, and risk classification address risk and compliance. Data lineage and quality controls address data management. Model documentation, bias testing, and ownership assignment address model accountability. Monitoring and incident response address operational controls. Finally, the annual review addresses stakeholder transparency by providing evidence that the system is functioning as intended.

Governance is most effective when you integrate it into the development and deployment process instead of adding it later.

Steps 1 to 3. Define scope and take stock of what you have

You cannot govern what you cannot see.

These first three steps are the foundation for all subsequent work. Skipping them is the most common reason governance programmes stop progressing after six months. Teams often begin writing policy documents before they have counted the AI systems currently running across the business. This results in policies that govern an inventory that does not exist yet.

Step 1: Define the scope of your governance programme

Create a written document that specifies which AI systems, tools, and automated decision processes are subject to your governance framework. You must include third-party models and vendor tools used by your team. A biased output from a purchased tool is as damaging as an output from a model trained by your own data scientists. Record this scope in a single policy statement and require every relevant stakeholder to review and sign it. Do not assume that everyone agrees on which systems are included. Stakeholders often have different interpretations, and these disagreements typically cause problems later if they are not addressed now.

Narrow scope creates blind spots. Vague scope causes paralysis. You should be specific about what is included and what is excluded.

Step 2: Build a full inventory of every AI system in use

List every AI system currently in use throughout the organisation. You should be thorough, as most teams underestimate their total number of systems by half. For each entry, record the system name, the designated owner, the business function, the data it uses, and the current deployment status. A spreadsheet is a sufficient tool for this task. An example of a necessary entry is a customer churn predictor owned by the head of data science that uses CRM and transaction history data and is currently live for the retention marketing team. The objective of this step is to gain visibility rather than to create a polished document. You can improve the formatting after you have identified all the systems.

Step 3: Classify each system by risk level

Give each system in your inventory a risk tier of high, medium, or low. Base the tier on how sensitive the data the system handles is and the possible damage from wrong or biased results. Take into account if the system directly impacts people, such as a hiring tool or a credit decision system, or if it is merely an internal reporting dashboard without external effect. Systems classified as high risk need tighter controls and more regular reviews. Completing this classification correctly from the beginning stops you from imposing too much oversight on harmless tools or too little oversight on systems that need close scrutiny.

Steps 4 to 6. Assign ownership and build a repeatable risk process

Once you have created an inventory and assigned risk tiers, you need to identify who is accountable for the risks and how the organisation will manage them. The success or failure of most governance programmes depends on clear ownership and defined processes. Programs typically do not fail due to the policy document itself. They fail when no designated individual is tasked with acting on the policy.

Step 4: Assign an owner to every AI system

Each system in the inventory must have a designated accountable owner. The owner should be a senior stakeholder in the business unit that uses the system, not an IT staff member who does not rely on the output. Ownership must be recorded in the inventory register. These assignments should be reviewed at least annually, or immediately when a system's scope changes. Each owner is tasked with:

• Approving changes to the system before they ship
• Signing off on risk reviews for that system
• Escalating incidents to the governance team without delay

Step 5: Define your risk assessment process

Set the criteria and the review frequency for each risk tier. Record these standards so they stay consistent no matter who conducts the review. High-risk systems need a formal assessment prior to deployment and then every six months. Medium and low-risk systems call for a less intensive review each year. Apply one standard template across the whole organisation. When teams develop their own assessment formats, comparing risks across the company becomes difficult. Such comparisons are often needed during audits.

Step 6: Build a risk register

Maintain one central risk register that records each identified risk, its severity, its owner, and the agreed mitigation, and refresh it after each assessment cycle to prevent it from becoming stale. An entry such as a biased training dataset, rated high severity, owned by the head of data, with a re-sample of the dataset in progress, is typical. Likewise, an undetected model drift risk, rated medium, owned by the ML engineer, with monthly drift checks now active as mitigation, is a common entry. The register remains useful only if people access it between audits, so design the format to be simple enough that updates take minutes rather than an afternoon.

Steps 7 to 9. Put technical controls around your data and models

Once ownership and a risk process are in place, you can tackle the technical layer. This includes controls that govern data flow through your systems and model behaviour in production. These three steps give auditors, engineers, and business owners a clear trail to follow when questions appear. This ensures staff can supply specific information rather than promising to investigate later.

Step 7: Document your data lineage

Your team must know the origin of each dataset, what occurred to it before reaching a model, and its final destination. Data lineage documentation should be placed directly next to your model files so both are reviewed together, not stored in separate systems that no one cross-references. Capture at least:

• The source system and the named data owner
• The processing steps applied and the tools used to apply them
• The date of the most recent validation and the name of the reviewer who approved it.

If that trail is missing, you cannot use a structured process to diagnose a model failure. Instead, you must rely on guesswork. This frequently occurs under time pressure when a senior colleague requests an answer that should be available within five minutes.

Step 8: Apply data quality and privacy controls

Carry out data quality checks during ingestion before the data reaches a model. These checks must detect missing values, schema changes, and anomalies. Configure automatic flags for failures and route them to the assigned data owner for correction. If bad data is not addressed promptly, it will flow through the system and cause unexplained model issues later. For personal data, record the legal reason for processing. Make sure that rules for data minimisation and retention periods are followed in every pipeline, including secondary pipelines. Review these controls each time you add a new data source to prevent oversight gaps.

Step 9: Record model decisions and test for bias

Produce a model card for each system. Include training data sources, performance metrics, known limitations, the date and outcome of the last bias evaluation, and the name of the person who approved the review. For example, a model card might state that a churn model was trained on CRM exports from three quarters of 2025, has 91 per cent accuracy with an F1 score of 0.88, underperforms on new customers with limited history, passed its last bias test in February 2026, and was reviewed by the head of data science. Conduct bias evaluations before each deployment and after any significant retraining. Log these results in the risk register to ensure the model card and the register hold the same information and do not contradict each other.

Steps 10 to 12. Monitor, respond, and keep improving

A governance checklist works only if you maintain it after launch. These last three steps turn governance from a one-time setup into a continuous process for your team. This approach ensures you identify problems while they remain minor and inexpensive to fix.

Step 10: Set up ongoing model monitoring

Track model performance metrics in production on a consistent schedule. Run automated checks weekly for high-risk systems and monthly for lower-risk systems. Log these results against the baselines in the model card. This enables you to spot accuracy drift, shifting data distributions, or unusual output patterns before they affect decisions or customers. The system must automatically alert the designated model owner when a metric exceeds a predefined threshold. Relying on manual observation is not an effective monitoring strategy.

Step 11: Define an incident response process

Establish a clear escalation path before you need to use it. Do not wait until you are in the middle of an incident to develop these steps for the first time. Your response process should include:

• How to classify incident severity, critical, moderate or low
• Who gets notified, and within what timeframe
• The steps to pause or revert the system if needed.
• A post-incident review template that captures root cause and remediation

Step 12: Run a regular governance review cycle

Schedule a full governance review at least once a year. The review must cover the inventory, the risk register, ownership assignments, and control documentation, and it should be carried out as one process instead of four separate tasks spread over the year. Assign a review lead and choose a specific date. Record any policy changes or corrective actions that arise from the review as a formal entry, making sure the review produces concrete results and does not become a forgotten meeting.

Where to start

Twelve steps may appear many to review at once, and you do not have to implement every one at the same time. Start with steps 1 and 2: define the scope and build the inventory. These two steps form the foundation for all subsequent work, because you cannot classify risk, assign owners, or document lineage for systems that are not listed. Most teams we work with devote more time to these initial steps than to any other checklist portion. This is not due to difficulty of the inventory work, but because people often hesitate to ask each team for information to include in the spreadsheet.

Prioritise the steps that impact your highest-risk systems rather than following the list's numerical order. Adopt a phased approach that starts with ownership, risk classification, and data lineage for systems that could cause harm. This method sets up a governance programme rapidly and stops your team from being overwhelmed by documentation for low-priority tools.

You do not need to build this alone. We help enterprises place governance around AI systems that must withstand real operational and regulatory pressure, from the data foundation up. Talk to us if you want a clear picture of where your own AI programme stands.

When the reading becomes a roadmap question, our AI strategy consultants will honestly tell you what the work requires and what it depends on.

Frequently asked questions