AI Governance Best Practices: Checking Whether the Controls Work

An organisation has an AI policy, an inventory, and a release checklist. A review finds that one assistant has no current owner, another is using a model different from the version recorded at approval, and staff cannot explain how to report a harmful answer. The governance documents exist, but several controls are no longer connected to the services they describe.

Useful AI governance practices make that gap visible and help people correct it. They examine whether ownership, access restrictions, evaluation, oversight, and incident response function under the conditions of real work. The aim is to support decisions with evidence that remains relevant as systems change.

This article focuses on improving an established or emerging programme. The governance framework describes the lifecycle structure, while the operating model assigns responsibilities. Here, the question is how to find out whether those arrangements are doing what the organisation expects.

Turn the Core Principles Into Testable Controls

Effective governance translates ethical principles into repeatable safeguards throughout selection, development, procurement, deployment, operation, and retirement. The OECD AI Principles provide a reference for trustworthy AI; the practical task is to connect those principles to evidence from the actual service.

An explanation generated by a model is not proof of how a decision was reached. Preserve source evidence, configuration, observable actions, and the human decision record needed for the use. Where a supplier limits access to internal model details, record that limitation and assess whether the available evidence is sufficient for approval.

Keep a Comprehensive Inventory and Apply Proportionate Review

Catalogue internally developed systems, third-party APIs, agents, purchased AI features, and embedded capabilities in existing software. Record purpose, users, affected people, data sources, supplier, version, integrations, owners, and approval status. Include unapproved or shadow AI discovered through staff reporting, procurement and software records, and proportionate technical discovery. An inventory should reflect actual use, rather than only projects that passed through the formal intake process.

Use defined risk tiers to set the depth of review. The following is an illustrative internal scheme, not a legal classification:

Classify the deployment by its consequences, data sensitivity, scale, autonomy, and reversibility. A familiar chatbot can become a higher-risk use when connected to sensitive records or action-taking tools. Check applicable legal classifications separately, and reassess when the purpose or configuration changes.

Give Cross-Functional Oversight Clear Decision Rights

Bring legal, risk, privacy, security, IT, data science, business leadership, and relevant process owners into a shared review process. A governance board can resolve cross-team issues and approve defined exceptions, while routine decisions follow delegated authority. Specify who advises, who decides, and who can stop a release or restrict a live service.

Keep a named accountable owner even when a committee reviews the use. Give business and technical owners explicit responsibilities for outcomes and operation, and identify owners for shared models or platforms where several deployments depend on them. A team name or generic mailbox alone does not establish who must act when a control fails.

Check a Live Service Before Adding Another Policy

Choose a representative AI service and follow a recent task through it. Ask the business owner what the system is approved to do, the technical owner which configuration is running, and a user how they check an uncertain output. Compare those answers with the recorded approval.

Differences are useful findings. An outdated inventory may indicate that supplier changes do not reach the service owner. A user who treats suggestions as instructions may reveal a mismatch between training, interface design, and workload. Investigate the mechanism before assuming another policy statement will resolve it.

Sample services with different consequences and deployment patterns. Include purchased features as well as internally developed applications. A small review can identify recurring weaknesses without claiming to provide assurance over the entire estate.

Record the scope and limits of the exercise. If only an internal drafting tool was examined, the findings do not establish the condition of applications involved in consequential decisions. Use the result to choose further checks and corrections proportionate to what was found.

Make Approval Conditions Specific Enough to Revisit

An approval that says a system is acceptable leaves later reviewers with little basis for assessing change. Record the permitted purpose, users, data sources, integrations, configuration, restrictions, and evidence supporting the decision.

For example, an assistant may be approved to prepare internal summaries from selected documents, with staff checking sources before external use. Connecting it to customer records or enabling automatic publication changes the conditions. A specific approval helps teams recognise that a further decision is needed.

Give unresolved actions owners and dates. Distinguish conditions that must be completed before release from follow-up improvements permitted during limited operation. Otherwise a conditional approval can become an indefinite permission with no reliable account of what remains incomplete.

Revisit approvals when material assumptions change. A scheduled review can help, but a significant supplier update or new use should not wait for the calendar. The service team needs a practical trigger for bringing the change back to the right decision-maker.

Ask for Evidence That Challenges Important Assumptions

Evaluation should include cases capable of revealing a meaningful failure. If an assistant is expected to respect team-based access, test a user requesting another team’s records. If it should decline questions unsupported by its sources, include plausible questions whose answers are absent.

Examine critical errors separately from average performance. A high overall score can conceal a small number of errors with serious consequences. Define which mistakes require restriction or correction before reviewing the results, using the business process and affected people as context.

Preserve the relationship between the evidence and the release. Record versions, settings, sources, test cases, and criteria. When results are summarised for approval, include limitations and unresolved differences rather than presenting a pass rate without its conditions.

Give a finding a route to closure. If an access test fails, identify the affected boundary, restrict the deployment where needed, and assign the correction. Repeat the relevant test after the change and check related paths that could share the defect. A finding marked complete because a ticket was created provides a different level of assurance from evidence that the control now works.

The voluntary NIST AI RMF provides a risk-management reference. Its existence does not determine the evidence needed for a specific release. Teams still need tests and review criteria that address the actual application’s consequences.

Examine Fairness and Data Quality Directly

Choose fairness checks that reflect the people and decisions affected. Where relevant and lawful, compare error rates, missed opportunities, or other consequential outcomes across groups rather than relying only on aggregate accuracy. Examine whether the available data represents the intended population and whether labels or historical decisions encode disadvantage. Where a purchased model’s training data is unavailable, record the evidence gap and test the configured application with representative cases.

Tie these checks to data governance. Classify source information, set quality and freshness requirements, record provenance and permitted uses, and name owners able to correct defects. Trace a disputed output back to its source and transformation steps. Stale policies, incorrect records, or missing access restrictions require different corrections; documenting lineage helps the team identify which one is needed.

Fairness cannot be established by a single score. Record the rationale for the measures chosen, relevant trade-offs, gaps in the evidence, and the process for investigating complaints. Repeat the important checks when data, users, or decision criteria change.

Observe Human Review Under Realistic Workload

A person can be present in a workflow without exercising effective control. Find out what reviewers see, how much time they have, what they can change, and where they send a disputed case. These conditions determine whether the expected review is practical.

Use representative examples to observe the task. For a generated report, can the reviewer locate the source of a claim and identify a missing qualification? Can they reject the output without losing work or missing an unrealistic throughput target?

Compare the required review with the staffing model. If the business case assumes rapid acceptance while the governance assessment assumes detailed verification, the organisation has incompatible expectations. Resolve that conflict through scope, interface design, evaluation, or resources before relying on the control.

Training should address the failures users actually encounter. Demonstrating how to obtain an answer is insufficient where staff also need to detect unsupported statements, protect information, and escalate uncertainty. Review feedback should reach the team able to change the service.

Test the Paths Around the Model

Important controls often sit in identity services, retrieval, caches, tool interfaces, and logs. Test those paths directly instead of treating an acceptable answer as evidence that the entire application behaved correctly.

For a document assistant, inspect which passages reached the model and which identity authorised retrieval. Check whether a cached answer can be shown to someone without access to its sources. Exercise access revocation and deletion as well as ordinary successful requests.

The OWASP RAG Security Cheat Sheet provides technical guidance across retrieval pipelines. Use such resources to inform checks, then verify the relevant behaviour in the deployed configuration.

If the system can take actions, examine failed and uncertain executions. A timeout may leave the application unsure whether a transaction completed. Test whether retries create duplicates and whether a revoked permission prevents a queued action. The agent governance article develops those controls beyond content review.

Treat Exceptions as Information About the Programme

An exception record should identify the control, reason, affected service, accountable decision-maker, compensating measures, and review point. The organisation needs to know what it has accepted and whether the conditions still hold.

Examine repeated exceptions together. Several teams requesting the same alternative may indicate that a shared platform or review process does not meet a legitimate need. It may also reveal a risk being accepted repeatedly without a wider decision. The pattern deserves investigation rather than automatic renewal.

Do not let an exception record become a route around an applicable legal requirement. Establish which decisions the organisation can make internally and which obligations remain binding. The compliance article explains why legal applicability needs separate analysis.

Review waiting time and rework alongside exceptions. If teams repeatedly submit incomplete assessments, improve the intake and guidance. If complete submissions wait because nobody has decision authority, changing the form will not solve the underlying problem.

Exercise Incidents Through Containment and Restoration

Choose a plausible scenario: a supplier update produces misleading advice that reaches customers, or an assistant retrieves restricted information. Follow the response from detection to containment, investigation, communication, and restoration.

Check who can restrict the feature, revoke access, preserve evidence, and activate a manual process. Include unavailable staff and supplier dependencies. A response that relies on a single expert being present may need deputies or a simpler containment mechanism.

Continue beyond switching the system off. Determine how the business identifies affected outputs, corrects records, supports people, and decides whether the service can return. A technical fix may be necessary without resolving the consequences of earlier use.

Record the gaps and test the important corrections. An updated contact list helps only if the relevant team can reach someone able to act. A revised fallback helps only if users can complete the work under expected volumes and time constraints.

Measure Whether Governance Improves Decisions

Monitor production behaviour against the approved baseline. Depending on the system, track changes in input data or case mix, model performance, output quality, prompt behaviour, access denials, and tool-call patterns. These can reveal drift, performance degradation, or a workflow being used beyond its tested scope. Supplier model updates also need review even when the application code is unchanged.

Set thresholds or other triggers for investigation, identify who receives alerts, and define the response: sample outputs, restrict scope, re-evaluate, revert a change, or suspend the feature. Review incidents and user feedback alongside automated measures. Monitoring should lead to a decision and a responsible person, rather than end with a dashboard.

Use measures that reveal the quality and timeliness of governance work. Examples include unresolved critical findings, changes deployed outside approved scope, repeated incidents, time to contain a problem, and the age of overdue actions. Interpret them in context rather than treating a lower incident count as automatic evidence of improvement.

Better reporting can initially increase recorded issues. Faster reviews can reflect a useful reusable pattern or a superficial check. Examine samples of the underlying decisions so the measure does not become detached from the outcome it is intended to represent.

ISO/IEC 42001 frames AI management as a system that is established, maintained, and continually improved. A business can apply that management principle by giving findings an owner, funding corrections, and checking their effect in subsequent work.

Map Practices to Relevant Frameworks and Guidance

Use recognised references to check for missing responsibilities and evidence. Maintain a mapping from each relevant requirement or principle to an internal control, owner, and review record. This can reduce repeated documentation while preserving the distinctions between the sources.

Applying voluntary guidance or obtaining management-system certification does not establish that every deployment complies with applicable law. Use the compliance assessment to identify binding duties, then verify the controls that address them.

Start with a manageable set of live services and the controls whose failure would matter most. Close the important gaps before expanding the review mechanically. Over time, the programme should produce clearer approvals, more dependable handoffs, and a better ability to detect when an AI service has moved beyond the conditions the organisation understood and accepted.