The Core Point
In the first four articles in this series, I examined AI governance as a board-level imperative, consequence-led risk tiering, security as a commercial enabler and operational resilience when AI-enabled processes fail.
This fifth instalment addresses a familiar governance problem:
Why do organisations publish sensible policies, yet still struggle to govern AI in practice?
Often, the issue is not that the policy is poorly written. It is that the policy is expected to carry too much of the operational burden.
A policy sets direction, establishes principles and defines boundaries. On its own, however, it will not reliably:
identify every AI use case across the organisation
assign accountable business ownership
determine the appropriate risk tier
integrate governance into procurement or product delivery
test whether controls operate effectively in practice
produce defensible evidence for the board, a regulator or a client
The policy matters. Whether it works depends on the standards, processes and controls beneath it.
The precise governance requirements will depend on the use case, sector, data involved and jurisdictions in which the organisation operates. The standards, tiering and operating model described here are practical governance choices rather than a single statutory template.
Policy Provides Direction, Not Delivery
AI policies frequently state sensible and broadly accepted principles:
use approved tools
protect confidential and personal data
maintain appropriate human oversight
assess higher-risk use cases
comply with legal and regulatory obligations
use AI fairly and responsibly
The difficulty begins when operational teams need to apply them.
What defines an approved tool?
Who decides whether a use case is high risk?
What constitutes effective human oversight?
Which data classifications are permitted with which service?
Who approves an exception?
What evidence must be retained?
When must the use case be reassessed?
Without practical standards, procedures and defined decision rights beneath the policy, teams are left to interpret high-level intent for themselves.
This can result in inconsistent decisions. Some teams become unnecessarily cautious and slow safe adoption. Others proceed without sufficient scrutiny or work around processes they regard as unclear or disproportionate.
The policy may be sound, but the supporting operating model may be incomplete.
The Missing Middle
In many organisations, governance consists of a high-level policy at one end and a collection of technical controls at the other.
The middle layer, which translates intent into repeatable operational decisions, may be incomplete or unclear.
For AI governance, that layer may include:
an AI use case standard
a risk tiering methodology
data classification and usage rules
clear approval thresholds
human oversight requirements
supplier and model provider assessment criteria
logging, monitoring and audit requirements
incident escalation triggers
reassessment thresholds
evidence and record-keeping requirements
This is where technical and operational standards provide value.
A policy may state:
AI must be used responsibly and in accordance with the organisation’s risk appetite.
A supporting standard should explain what that means in practice:
AI use cases that materially influence customer outcomes, regulated processes, financial decisions or important services must undergo a formal multidisciplinary assessment and receive documented approval from the accountable business owner and any required delegated authority before production deployment.
One is a statement of intent.
The other is an actionable and auditable control requirement.
Keep the Policy Short
There is a common temptation to include every operational concern in the core AI policy:
data protection
copyright
bias
explainability
inaccurate or fabricated outputs
model security
third-party risk
resilience
monitoring
record-keeping
human oversight
incident response
The result can become a large document that is difficult to read and maintain.
In practice, an effective policy should do four primary things:
Explain why the organisation governs AI.
Establish core principles and mandatory boundaries.
Define accountability at a high level.
Direct teams to the standards and procedures through which requirements are implemented.
A board-approved policy should be relatively stable.
Supporting standards, control guidance and technical baselines can change more frequently as models, regulations and operating practices develop.
Separating direction from execution reduces the risk that the policy becomes outdated whenever a provider changes a feature, a regulator publishes guidance or the organisation updates its assessment process.
Standards Must Answer Practical Questions
A well-designed governance standard should give business owners, product managers, procurement teams and control functions enough clarity to make defensible decisions.
It should answer questions such as:
Does this use case require formal registration?
Which criteria determine the risk tier?
Which data classifications are permitted?
When is a Data Protection Impact Assessment required?
When must Legal, Privacy, Compliance or Security be involved?
What level of human oversight is required?
What testing is proportionate?
Who holds approval authority?
What evidence must be retained?
What operational or technical changes trigger reassessment?
When must the use case be restricted or stopped?
Where personal data is involved, initial screening should determine whether a DPIA is required. Where it is, the DPIA should be completed before the processing begins.
The objective is not to eliminate human judgement.
It is to make that judgement consistent, proportionate and defensible.
Ownership Must Be Explicit
Unclear ownership remains a common weakness in AI governance.
Because AI crosses multiple disciplines, responsibility can become diluted across:
Technology
Product
Data
Legal
Privacy
Compliance
Security
Risk
Procurement
the business team using the system
Cross-functional input is essential.
Committee oversight is not the same as operational ownership.
The accountable business owner should remain responsible for:
the purpose and intended business outcome
the underlying process being automated or augmented
the effect on customers, employees and third parties
ensuring that residual risk is understood and accepted by the appropriate delegated authority
the continuing suitability and performance of the AI capability
Security, Legal, Privacy, Compliance and Risk provide expertise, challenge and assurance.
They should not become default owners simply because the use case involves AI.
A straightforward test applies:
If this system produces a flawed outcome or causes material harm, which executive is accountable?
If the answer is unclear, the use case should not proceed until accountability has been resolved.
Approvals Should Match the Risk Profile
Subjecting every AI proposal to the same approval process can create unnecessary delay and encourage unmanaged adoption.
A low-risk tool used to draft internal documents does not require the same level of governance as a system influencing recruitment, credit decisions, claims handling or an important operational service.
A proportionate model might establish the following pathways.
Low Risk
Proceed within defined guardrails using approved tools.
The user remains responsible for checking outputs and protecting information.
Moderate Risk
Document the accountable business owner, purpose, data inputs, provider and oversight arrangements.
Complete a proportionate assessment before use.
High Risk
Require formal multidisciplinary review, a named senior accountable owner, appropriate testing, active monitoring, fallback arrangements and approval before production deployment.
Restricted Use
Proceed only where an authorised exception has been granted and the legal, ethical and control basis has been documented.
Prohibited Use
Do not proceed.
The value lies not in the number of categories, but in ensuring that each classification triggers a clear, predictable and proportionate control path.
Embed Governance into Existing Workflows
AI governance is more likely to work when it is integrated into existing decision points rather than positioned as an additional administrative hurdle.
It should connect with:
procurement and supplier onboarding
privacy and data protection assessments
security and architecture reviews
product development lifecycles
secure development
change management and deployment
model validation where applicable
operational resilience
incident management
customer assurance
Procurement should not discover by chance that a proposed supplier uses generative AI.
The intake process should ask.
A product team should not discover shortly before launch that an AI feature requires enhanced review.
The product governance process should identify that requirement during design.
A customer assurance team should not need to reconstruct the organisation’s position when a client asks how AI is controlled.
The approved use case record, assessment and supporting evidence should already exist.
Governance should be part of the operational workflow, not an obstacle discovered at the end.
Make the Entry Point Obvious
When people bypass governance, the entry point may be difficult to find or unnecessarily complex.
The route should be straightforward:
Register the proposed use case through a clear and accessible entry point.
Complete a short screening questionnaire.
Assign a provisional risk tier.
Route the use case to the required reviewers.
Record the decision, operating conditions and accountable business owner.
Monitor performance and reassess when a material change occurs.
The initial intake should be brief and collect enough information to determine the appropriate route.
Useful questions include:
What is the system intended to do?
Who will use it and who may be affected by its outputs?
What data classifications will it process?
Does it automate or materially influence a decision?
Can it take actions in downstream systems?
Is an important business service dependent on it?
Which model and provider are involved?
More detailed scrutiny can then be applied where the initial assessment indicates higher risk.
Controls Require Defined Owners and Parameters
A list of control statements is not an operating model.
To be effective, each control requires:
a named owner
a clear operational purpose
a defined method of operation
verifiable evidence
a review frequency proportionate to the risk
an escalation route when thresholds are breached
Consider the requirement:
AI outputs must be monitored.
On its own, this is a statement of intent rather than an operational control.
The organisation still needs to define:
who monitors the outputs
what errors, variances or behaviours are being monitored
what thresholds trigger investigation
how often the indicators are reviewed
whether previous outputs can be reconstructed
who has authority to restrict or suspend the system
where the evidence is retained
An operational control can be assigned, performed, evidenced and tested.
An unassigned requirement is unlikely to operate consistently.
Human Oversight Must Be Effective
Policies frequently require a human in the loop.
That does not automatically create effective oversight.
Where reviewers process large volumes under significant time pressure, the risk of automation bias increases. Human review can then become a largely confirmatory exercise rather than an effective control.
Where human oversight is required, the reviewer should have:
sufficient contextual information to evaluate the recommendation
adequate time to review the relevant inputs and outputs
appropriate domain knowledge
an understanding of the system’s limitations
authority to challenge, override or halt the outcome
access to relevant source information
a practical mechanism to record overrides for monitoring, review and, where appropriate, model improvement
If the working environment encourages automatic acceptance, the control may exist only on paper.
The standard should define where human review is required and what effective review involves.
It should also recognise that some uses cannot be made acceptable simply by adding an approval step.
Design Evidence Capture into the Process
Demonstrating governance retrospectively is inefficient and unreliable.
When an auditor, regulator, client or board committee asks for assurance, the organisation should not need to reconstruct its history from emails, meeting notes and individual recollection.
Defensible evidence should be captured as part of the normal governance process and automated where practical.
That evidence may include:
initial use case registration and risk tiering
multidisciplinary review records
recorded approvals
data classification and privacy assessments
supplier due diligence and relevant contractual terms
pre-deployment test results and validation records
defined human oversight procedures
ongoing monitoring data
incident and exception records
reassessment history
closure or retirement decisions
Documenting material decisions provides evidence that the organisation applied appropriate governance and oversight.
The objective is not documentation for its own sake.
It is to demonstrate that a considered decision was made and that the risk continues to be managed.
Measure Operating Effectiveness
Tracking the number of approved AI use cases measures activity, not governance effectiveness.
More useful measures may include:
high-risk use cases without a named senior accountable owner
time from intake to decision by risk tier
overdue reassessments
use cases operating under active exceptions
uses operating outside approved conditions
performance deviations, material errors and near misses
high-risk systems without tested fallback arrangements
unresolved supplier assurance gaps
material changes that did not trigger reassessment
These indicators can help identify two distinct problems:
governance that is too weak to manage the risk
governance that is so cumbersome that teams work around it
Both matter.
A process that approves everything is not effective.
A process that unnecessarily obstructs safe adoption is not effective either.
Common Failure Patterns
Several policy-led weaknesses recur.
The Policy Is Too Broad
It requires responsible AI use without defining what responsible adoption means in practice.
The Policy Is Too Detailed
It attempts to codify every technical and regulatory requirement in a relatively static document and quickly becomes difficult to maintain.
Accountability Is Unclear
Several functions contribute, but no single business leader is accountable for the operational outcome.
Engagement Starts Too Late
Governance checks appear during procurement approval or shortly before deployment rather than during initial design.
Every Use Case Follows the Same Route
Low-risk uses face unnecessary friction while higher-risk uses may not receive sufficient scrutiny.
Controls Are Not Operationalised
Requirements exist, but owners, evidence, thresholds and escalation routes have not been defined.
Exceptions Are Not Managed
Temporary exceptions are approved, but their expiry and associated remediation are not tracked.
Governance Is Not Reassessed
The use case changes, but its original approval and assessment remain untouched.
These are operating-model weaknesses.
Rewriting the high-level policy alone will not resolve them.
What the Board Needs to See
Boards do not need to review individual standards or approve specific use cases.
They need confidence that the governance model is operating as intended.
Reporting should provide appropriate visibility of:
material AI dependencies across important business services
high-risk use cases, trends and areas of concentration
unresolved accountability or control gaps
active exceptions
incidents and material near misses
overdue remediation
evidence that controls for high-risk systems are tested and operating effectively
indicators showing whether governance is enabling safe adoption or creating avoidable delay
The board-level questions remain straightforward:
Do we maintain an accurate view of where material AI is used?
Is business accountability clear?
Are higher-risk use cases subject to proportionately stronger scrutiny?
Are controls operating effectively rather than merely documented?
Can management demonstrate that governance enables safe and responsible adoption?
The CISO’s Role
The CISO cannot and should not own every AI business outcome.
The role is to help design and operate a governance model that works effectively across the organisation.
This includes:
translating high-level policy into practical standards, control requirements and decision pathways
aligning AI governance with security, privacy, resilience and third-party risk
establishing proportionate control expectations based on the use case, potential consequence and wider risk profile
challenging unclear ownership and ensuring accountability remains with the accountable business owner
ensuring evidence is available for board, audit, client and regulatory assurance
identifying where governance is being bypassed or creating unnecessary friction
The CISO needs to distinguish between a control gap and a process-design problem.
Sometimes the answer is stronger oversight.
Sometimes it is a simpler route.
Practical governance requires both judgement and restraint.
From Policy to Practice
A well-drafted policy establishes authority and direction.
The practical test is whether the organisation can translate that intent into consistent day-to-day behaviour.
Can teams find the correct entry point?
Are requirements clear and actionable?
Is the review proportionate to the risk?
Is executive accountability clear?
Are controls monitored and evidenced?
That is how AI governance moves from a policy document into an effective operating model.
The objective is not policy length or detail for its own sake.
It is to create a control environment that people can understand, use and evidence.
What friction points have you encountered when moving from AI policy to operational execution? I would welcome your experience and lessons in the comments.
Part 6 of this series will examine the evolving role of the modern CISO in AI governance: where security should lead, where it should enable and where accountability should remain with the accountable business owner.
Personal commentary. Views are the author’s own.