Leadership: Make Risk, Governance and Assurance Decisions

July 20, 2026 · 37 min read

AI Playbook author

Data and AI create significant opportunities for growth, operational improvement, better decision-making and new client services. However, these opportunities also introduce risks that are different from, and often more complex than, those associated with traditional technology.

An AI system may expose confidential information, produce inaccurate recommendations, introduce unfair outcomes, breach regulatory obligations, undermine professional judgement or create reputational damage. A technically successful solution can therefore still be unacceptable from a business, ethical, legal or professional perspective.

For this reason, an Executive Data and AI Leader is accountable not only for accelerating innovation, but also for ensuring that innovation proceeds within the organisation’s risk appetite.

Their objective is not to eliminate all risk. That would prevent experimentation and slow down useful progress. Their responsibility is to ensure that risks are:

Identified early.
Assessed consistently.
Owned by the right people.
Reduced through appropriate controls.
Supported by evidence.
Escalated when necessary.
Monitored throughout the system lifecycle.
Accepted only by people with the authority to do so.

The leader must create an environment in which teams can innovate confidently because the boundaries, decision rights and assurance requirements are clear.

1. Risk Governance Is a Leadership Responsibility

Risk management cannot be treated as a final compliance review that takes place immediately before deployment.

By that stage, the team may already have:

Selected an unsuitable technology.
Used data without the correct permissions.
Designed a process with insufficient human oversight.
Created a dependency on an unacceptable third party.
Built a solution that cannot be properly audited.
Made commitments to a client that cannot safely be delivered.
Invested significant time and money in an approach that will not receive approval.

Effective governance begins when the opportunity is first identified.

The Executive Data and AI Leader should ensure that risk considerations influence:

Use-case selection.
Business-case development.
Data sourcing.
Model and vendor selection.
Solution architecture.
Testing and evaluation.
Human oversight design.
Deployment approval.
Production monitoring.
Incident response.
Periodic reassessment.
System retirement.

Risk governance must therefore be integrated into the complete Data and AI lifecycle.

The leader does not personally carry out every legal, privacy, security, model-risk or assurance review. Instead, they ensure that the organisation has a reliable governance system in which:

The correct specialists are involved.
Responsibilities are clearly assigned.
Decisions are documented.
Evidence is retained.
Exceptions are controlled.
High-risk matters are escalated.
Production systems remain monitored.
Accountable executives understand the residual risk they are accepting.

2. Establish the Organisation’s Risk Appetite

One of the most important responsibilities of an Executive Data and AI Leader is translating the organisation’s broad risk appetite into practical rules for Data and AI teams.

A general statement such as “we are committed to responsible AI” is not sufficient. Delivery teams need to understand what this means in practice.

The leader should help define:

Which AI uses are prohibited.
Which uses require senior approval.
Which uses may proceed under standard controls.
Which data types may be processed.
Which model providers may be used.
Which decisions must remain under human control.
Which environments are approved for experimentation.
What level of explainability is required.
What evidence is required before production deployment.
Which incidents must be reported immediately.
Who can accept residual risk.

For example, an organisation may permit employees to use an approved generative AI assistant for summarising public information but prohibit the use of unapproved public tools for processing confidential client data.

Similarly, an internal administrative assistant may be approved under a lightweight review, while an AI system influencing audit conclusions, credit decisions, employment decisions, legal advice or regulated client outcomes may require extensive assurance and executive approval.

The leader must ensure that risk requirements are proportionate. Applying the same governance process to every use case creates unnecessary bureaucracy. Applying too little governance to high-impact systems creates unacceptable exposure.

The aim is risk-based governance.

3. Classify AI Use Cases by Risk

A consistent risk-classification process helps determine the level of review, evidence and executive oversight required.

Risk classification should consider more than the type of model being used. A relatively simple model may create serious consequences if it influences a high-impact decision. A technically advanced model may present limited risk if it operates in a controlled, low-impact environment.

The classification should consider several dimensions.

3.1 Impact on people

The leader should ask:

Could the system affect a person’s employment, finances, access to services or legal rights?
Could an incorrect output cause physical, financial, emotional or reputational harm?
Is the user aware that AI is being used?
Can an affected person challenge the decision?
Is there a clear route for human review?
Could the system treat groups differently?

Systems influencing people’s rights or opportunities generally require stronger controls.

3.2 Impact on clients

The leader should determine:

Could the output influence client decisions?
Could the client rely on inaccurate or incomplete information?
Is the system presented as advisory or authoritative?
Could errors create contractual, legal or financial consequences?
Has the client approved the proposed use of AI?
Are limitations clearly communicated?

The more directly the system contributes to client advice or deliverables, the greater the assurance requirement.

3.3 Data sensitivity

The review should consider whether the system processes:

Personal data.
Special-category or highly sensitive personal data.
Confidential client information.
Financial information.
Health information.
Employee information.
Legally privileged material.
Commercially sensitive information.
Security credentials.
Source code.
Intellectual property.
Government-classified or regulated information.

Higher data sensitivity requires stronger restrictions on access, processing, retention, transfer and model-provider usage.

3.4 Autonomy

The leader should ask:

Does the system merely provide information?
Does it recommend an action?
Does it make a decision?
Does it execute an action?
Can it access other systems?
Can it communicate externally?
Can it modify records?
Can it initiate financial or operational transactions?
Can it act repeatedly without human approval?

Agentic or autonomous systems may require enhanced controls because their actions can create real-world consequences before a human intervenes.

3.5 Scale

A small pilot involving ten trained users creates a different risk profile from a system serving thousands of employees or millions of customers.

Scale considerations include:

Number of users.
Number of decisions or transactions.
Geographic reach.
Number of clients affected.
Volume of data processed.
Level of dependency on the system.
Difficulty of reversing an error.
Potential cumulative impact of repeated mistakes.

3.6 Regulatory and professional significance

The system may require stronger review if it affects:

Audit work.
Financial reporting.
Tax advice.
Legal services.
Regulated financial activity.
Public-sector decisions.
Healthcare activity.
Employment decisions.
Consumer protection.
Competition law.
Data protection.
Sector-specific regulatory requirements.

The Executive Data and AI Leader should ensure that each use case is assigned a clear risk level and that the classification is reviewed when the use case, data, model, scale or operating environment changes.

4. Review High-Risk AI Use Cases

High-risk use cases require structured executive attention.

The leader should not allow a high-risk proposal to proceed solely because:

The technology appears impressive.
A competitor has launched something similar.
A client has requested it.
A senior sponsor is enthusiastic.
A vendor claims the solution is compliant.
A successful proof of concept has been completed.
The team has already invested heavily in development.

The decision must be based on evidence.

A high-risk review should examine:

Business purpose

What problem is being solved?
Is the use case genuinely necessary?
Is AI the most appropriate approach?
Is there a less risky alternative?
What business value is expected?
Who owns the outcome?

Affected stakeholders

Who will use the system?
Who may be affected by its outputs?
Could vulnerable groups be affected?
Are users adequately informed?
Can people challenge or appeal outcomes?

Data

What data is being used?
Where did it come from?
Is there a lawful and contractual basis for using it?
Is the data accurate, representative and current?
Does the system require all the data being collected?
How long will the data be retained?
Where will it be processed?

Model

Which model is being used?
Is it internally developed or externally provided?
How was it evaluated?
What are its known limitations?
Can the provider use submitted data for training?
Can the provider change the model without notice?
Is the model available in approved regions?
Is there an acceptable exit strategy?

Controls

What prevents misuse?
What prevents unauthorised access?
How are inputs and outputs monitored?
What human checks are required?
Can unsafe outputs be blocked?
Can the system be stopped quickly?
Are logs sufficient for investigation?

Residual risk

What risks remain after controls are applied?
Who is accepting those risks?
Is the residual risk within the organisation’s appetite?
Are additional conditions required before deployment?

The review must result in a clear decision rather than an open-ended discussion.

Possible decisions include:

Approved.
Approved with conditions.
Approved for a limited pilot.
Returned for remediation.
Escalated for specialist or executive review.
Deferred until evidence is available.
Rejected.

5. Make Production-Readiness Decisions

A system should not proceed to production simply because the development team has completed its technical work.

Production approval should be based on a complete view of readiness.

The Executive Data and AI Leader should ensure that the decision includes the following areas.

5.1 Business readiness

The business owner has accepted responsibility.
The intended outcomes are measurable.
The operating process has been redesigned where necessary.
Users have been trained.
Support arrangements are in place.
Limitations are clearly communicated.
Adoption and change-management plans exist.

5.2 Technical readiness

The architecture has been reviewed.
Performance is acceptable.
Capacity and scalability have been tested.
Availability requirements are understood.
Dependencies are documented.
Disaster-recovery arrangements are appropriate.
Rollback mechanisms exist.
The system can be disabled safely.

5.3 Data readiness

Data ownership is clear.
Data quality is sufficient.
Data permissions have been verified.
Retention rules are defined.
Data lineage is documented.
Sensitive data is appropriately protected.
Cross-border processing has been reviewed.
Production data has not been used improperly during testing.

5.4 Model readiness

Evaluation results meet agreed thresholds.
Known failure modes are documented.
Bias and fairness concerns have been assessed where relevant.
Hallucination or inaccuracy risks are understood.
Model drift can be detected.
Prompt, model and configuration versions are controlled.
Model changes can be traced.
The system can be revalidated after material changes.

5.5 Security readiness

Access is based on least privilege.
Authentication and authorisation controls are in place.
Secrets are securely managed.
The system has been tested for relevant attacks.
Prompt injection and data-exfiltration risks have been considered.
External tools and plugins are controlled.
Network boundaries are appropriate.
Logs and alerts support incident detection.

5.6 Legal, regulatory and policy readiness

Required privacy assessments are complete.
Contractual restrictions have been reviewed.
Regulatory obligations have been identified.
Intellectual-property risks have been assessed.
Client approval has been obtained where necessary.
Internal policy requirements have been satisfied.
Records of decisions are retained.

5.7 Operational readiness

Monitoring is active.
Incident-management procedures are documented.
Escalation contacts are known.
Human review responsibilities are defined.
Service ownership is confirmed.
Support teams understand the system.
Post-deployment review dates are scheduled.

The executive decision should be supported by an assurance pack summarising the evidence, outstanding risks, control owners and approval conditions.

6. Review Privacy, Security and Confidentiality Concerns

Data and AI systems often process large quantities of information, combine data from different sources and transmit information to external platforms. This creates privacy, security and confidentiality risks that require executive oversight.

Privacy

The leader should ensure that teams answer:

What personal data is being processed?
Why is it necessary?
Is the purpose clearly defined?
Is the processing lawful?
Are individuals appropriately informed?
Can the data be minimised?
Can data be anonymised or pseudonymised?
Are retention periods appropriate?
Are individual rights supported?
Is automated decision-making involved?
Are international data transfers involved?

Privacy cannot be reduced to a consent checkbox. It requires clarity about purpose, necessity, proportionality, transparency and individual rights.

Security

AI introduces new attack paths in addition to traditional application-security risks.

The leader should ensure that teams consider:

Prompt injection.
Indirect prompt injection.
Data poisoning.
Model extraction.
Sensitive-information disclosure.
Insecure output handling.
Excessive system permissions.
Malicious file uploads.
Uncontrolled tool use.
Supply-chain vulnerabilities.
Compromised third-party models.
Adversarial inputs.
Weak identity and access management.
Inadequate logging.
Unprotected APIs.
Insecure model endpoints.

The security review should reflect what the AI system can actually do, not merely what the interface appears to allow.

Confidentiality

In a professional-services environment, confidentiality is fundamental.

The leader must ensure that:

Client data is used only for approved purposes.
Access is limited to authorised engagement personnel.
Data is not entered into unapproved public AI tools.
Model providers cannot reuse confidential information inappropriately.
Client-specific material is separated from other clients.
Retrieval systems apply access control before returning information.
Logs do not expose sensitive content unnecessarily.
Test environments do not contain uncontrolled production data.
Confidential outputs cannot be accessed by unauthorised users.

Confidentiality must be enforced through architecture, access controls, contracts, training and monitoring. It cannot rely solely on employee judgement.

7. Protect Client Confidentiality and Cross-Client Data Separation

Professional-services firms frequently work with competing organisations, regulated businesses and clients involved in confidential transactions.

An AI platform that serves multiple clients must therefore enforce strict information barriers.

The leader should ensure that cross-client data separation is addressed at multiple layers.

Identity layer

Every user must be authenticated.
Client and engagement membership must be verified.
Permissions must be role-based.
Temporary access must expire.
Privileged access must be controlled and reviewed.

Application layer

Users should only be able to search, retrieve or generate content from authorised data sources.
Client context should be established before processing begins.
Administrative functions should be restricted.
The system should not rely on the model to decide whether data is accessible.

Data layer

Client data should be logically or physically segregated.
Metadata should identify ownership, sensitivity and permitted use.
Row-level, document-level or object-level security should be enforced.
Encryption keys may need to be separated for high-risk clients.
Backups must preserve segregation.

Retrieval layer

Access control must be applied before information is passed to the model.
Vector databases and search indexes must support tenant isolation.
Embeddings must not become an uncontrolled route to cross-client information.
Retrieved evidence should be traceable to authorised sources.

Model layer

Prompts must not combine information from unrelated clients.
Fine-tuning must not use client data without explicit approval.
Training data must be governed.
Model memory and conversation history must be separated.
Cached responses must not leak information across users or clients.

Monitoring layer

Access patterns should be monitored.
Cross-client retrieval attempts should generate alerts.
Unusual bulk extraction should be investigated.
Logs should support forensic review.
Periodic penetration and segregation testing should be performed.

A serious cross-client data leak can create contractual, legal, regulatory and reputational consequences. For that reason, separation should be treated as a core architectural requirement, not an optional enhancement.

8. Preserve Professional Judgement

AI systems can support analysis, research, drafting, summarisation and pattern recognition. However, professional responsibility cannot be delegated to a model.

The Executive Data and AI Leader should ensure that AI does not create the false impression that professional judgement has been automated.

This is especially important where outputs contribute to:

Audit conclusions.
Tax positions.
Legal interpretations.
Valuations.
Risk assessments.
Regulatory submissions.
Financial advice.
Due-diligence findings.
Investigations.
Client recommendations.

Human professionals must understand:

What the system produced.
Which evidence was used.
What assumptions were made.
What limitations apply.
What checks are required.
Who remains accountable for the conclusion.

The leader should challenge systems that encourage users to accept outputs without critical review.

Useful controls may include:

Mandatory source citations.
Confidence or uncertainty indicators.
Human sign-off requirements.
Review checklists.
Restricted use for specific tasks.
Independent validation.
Clear separation between AI-generated content and approved professional conclusions.
Training on appropriate reliance.
Sampling of completed work.
Monitoring for automation bias.

The principle should be clear: AI may support professional judgement, but it does not replace professional accountability.

9. Protect Audit Independence

In firms providing audit and assurance services, AI innovation must be assessed against independence requirements.

An AI service may create concerns if the firm:

Designs or operates systems that it later audits.
Makes management decisions for an audit client.
Assumes responsibility that belongs to client management.
Creates financial dependence or conflicting commercial interests.
Uses confidential information obtained through an audit engagement for another purpose.
Provides prohibited non-audit services.
Develops tools that impair objectivity.

The Executive Data and AI Leader must ensure that independence specialists are involved early when a proposed capability may be used for audit clients.

Key questions include:

Is the service permitted for this client?
Would the firm be auditing its own work?
Would the system make decisions that management should make?
Who owns the system and its outputs?
Does the proposed commercial arrangement create a concern?
Can the capability be separated from the audit engagement?
Are additional safeguards required?
Must the use case be prohibited for certain clients?

Independence cannot be treated as a commercial inconvenience. It is a foundational obligation that protects trust in the firm and the profession.

10. Identify and Manage Conflicts of Interest

AI platforms may combine data, expertise, reusable assets and insights from multiple engagements. This creates potential conflicts of interest even when direct data leakage does not occur.

For example:

A model developed for one client may later be used for a competitor.
A sector solution may incorporate confidential knowledge from multiple engagements.
An AI system may prioritise products from a commercial partner.
A firm may advise different parties involved in the same transaction.
Internal data may reveal confidential information about future client activity.
A vendor relationship may influence recommendations.

The leader should ensure that conflict checks cover both the client engagement and the AI capability itself.

The review should determine:

Who funded the capability?
Who owns the intellectual property?
What data contributed to its development?
Which clients may use it?
Could its use disadvantage another client?
Are commercial partnerships influencing the output?
Are information barriers sufficient?
Does the firm need client consent?
Should certain use cases be restricted?

Conflicts must be identified before commercial commitments are made.

11. Protect Legal Privilege

Some client material may be protected by legal professional privilege or similar legal doctrines.

Using privileged material in AI systems can create risks if:

It is transferred to a third-party provider.
It is stored in an inappropriate jurisdiction.
It is accessed by people outside the privileged relationship.
It is reused for model training.
It appears in system logs.
It is incorporated into a shared knowledge base.
It is disclosed through generated outputs.
Retention controls are unclear.

The Executive Data and AI Leader should ensure that legal counsel determines whether privileged information may be processed and under what conditions.

Possible controls include:

Approved private environments.
Restricted access groups.
No provider training on submitted data.
Limited logging.
Segregated storage.
Regional processing.
Explicit retention and deletion terms.
Contractual protections.
Prohibition of certain tools.
Client-specific approvals.

The safest approach is not to assume that a general enterprise AI approval automatically covers privileged material.

12. Manage Intellectual-Property Risk

AI systems create intellectual-property questions relating to inputs, outputs, training data, models, software, prompts and reusable assets.

The leader should ensure that the organisation understands:

Whether it has the right to use the input data.
Whether client materials may be used for model training.
Whether generated outputs can be used commercially.
Whether outputs may reproduce protected content.
Whether open-source components have acceptable licence terms.
Whether model-provider terms grant excessive rights.
Whether employees are uploading proprietary code.
Who owns fine-tuned models, prompts and evaluation datasets.
Whether reusable assets contain client-specific intellectual property.
Whether the firm can transfer the solution to another client.

A sound intellectual-property review should cover the complete solution supply chain, not only the final output.

Controls may include:

Approved data-source lists.
Code-scanning and licence-review processes.
Restrictions on external training.
Output review for high-risk content.
Contractual ownership provisions.
Provenance records.
Clear separation of client and firm intellectual property.
Approval before reusing engagement assets.
Vendor terms review.
Documentation of human contribution.

13. Assess Third-Party and Model-Provider Risk

Many organisations depend on external model providers, cloud platforms, data suppliers, AI tools and specialist vendors.

The Executive Data and AI Leader should ensure that third-party assessments examine more than functionality and price.

The review should consider:

Data handling

What information is sent to the provider?
Is it retained?
Is it used for provider training?
Can retention be disabled?
Where is it processed?
Which subprocessors are involved?
Can data be deleted?

Security

What security certifications and controls exist?
How is tenant isolation implemented?
How are vulnerabilities managed?
How are incidents reported?
Does the provider support customer-managed encryption?
Are administrative actions logged?

Model behaviour

How is the model evaluated?
Are limitations documented?
Can the model generate unsafe or discriminatory outputs?
How frequently is it updated?
Can updates materially change behaviour?
Can customers remain on a fixed version?

Availability and resilience

What service levels apply?
Is the provider financially and operationally stable?
Is there a fallback option?
Can the system continue if the service is unavailable?
How difficult would migration be?

Contractual protection

Who owns inputs and outputs?
What liability does the provider accept?
Are confidentiality obligations sufficient?
Are audit rights available?
Can the provider change terms unilaterally?
What happens when the contract ends?

Regulatory suitability

Is the provider acceptable for the relevant jurisdiction and sector?
Can it support regulatory inquiries?
Does it provide the evidence required for assurance?
Are cross-border transfer mechanisms adequate?
Does it meet client-specific requirements?

Vendor approval should not be permanent. Providers should be reassessed when there are material changes to their ownership, terms, model behaviour, subprocessors, security posture or service architecture.

14. Design Appropriate Human Oversight

“Human in the loop” is often used as a general assurance statement, but it is meaningful only when the human role is clearly designed.

The leader should ask:

Who performs the review?
At what stage does the review occur?
What information does the reviewer receive?
Does the reviewer have sufficient expertise?
Does the reviewer have enough time?
Can the reviewer reject or override the AI output?
Is the reviewer accountable for the decision?
Is the review recorded?
Are reviewers trained to recognise AI failure modes?
Is the review practical at the expected scale?

A human review may provide little protection if the person:

Sees only the AI recommendation.
Cannot inspect the supporting evidence.
Reviews hundreds of cases under severe time pressure.
Assumes the model is more accurate than they are.
Has no authority to reject the result.
Is measured mainly on processing speed.
Does not understand the model’s limitations.

Human oversight should be proportionate to the consequence of error.

Examples include:

Human-on-the-loop

The system performs actions while a human monitors activity and intervenes when necessary. This may suit lower-risk, reversible processes with strong monitoring.

Human-in-the-loop

The system proposes an output, but a human must approve it before action is taken. This may suit client communications, financial decisions or professional conclusions.

Human-in-command

Humans retain authority over the purpose, boundaries, design, deployment and termination of the system. This is a wider governance principle that should apply to all significant AI systems.

The leader should ensure that the selected oversight model is tested in real operating conditions.

15. Review and Respond to AI Incidents

AI incidents should be treated as business-risk events, not merely technical defects.

Examples may include:

Disclosure of confidential information.
Cross-client data leakage.
Harmful or discriminatory outputs.
Incorrect client advice.
Unauthorised autonomous actions.
Security compromise.
Use of an unapproved model.
Processing of data without permission.
Major hallucinations in a production workflow.
Failure of required human oversight.
Regulatory non-compliance.
Inappropriate use by employees.
Unexpected model changes.
Significant service disruption.
Intellectual-property complaints.

The Executive Data and AI Leader should ensure that the organisation has a specific AI incident-management process.

Immediate response

The first priorities may include:

Containing the issue.
Disabling the system or affected feature.
Preserving logs and evidence.
Preventing further data exposure.
Informing legal, privacy, security and risk teams.
Identifying affected clients or individuals.
Activating regulatory or contractual notification processes.
Establishing an incident leader.

Investigation

The investigation should determine:

What happened?
When did it begin?
Who or what was affected?
Which data was involved?
Was the incident caused by design, model behaviour, user action, malicious activity or control failure?
Why was the issue not detected earlier?
Did the system operate outside approved boundaries?
Were previous warning signs ignored?
Is the issue isolated or systemic?

Executive decisions

The leader may need to decide:

Whether the system remains suspended.
Whether affected clients must be informed.
Whether regulators must be notified.
Whether outputs must be withdrawn or corrected.
Whether similar systems must be reviewed.
Whether a vendor should be restricted.
Whether disciplinary or contractual action is required.
Whether the system can safely return to service.

Learning

After the incident, the organisation should identify:

Root causes.
Control failures.
Governance weaknesses.
Required policy changes.
Required technical changes.
Training needs.
Monitoring improvements.
Wider implications for the AI portfolio.

A mature organisation does not hide incidents to protect innovation metrics. It uses them to improve controls and decision-making.

16. Approve and Control Exceptions

No governance framework can anticipate every situation. Teams may occasionally need an exception to a standard requirement.

For example, a team may request:

Temporary use of a non-standard model.
Processing in a different region.
A shortened testing period.
Use of a new vendor before full onboarding is complete.
A temporary manual control.
Access to restricted data.
Deployment before every low-priority issue is resolved.

Exceptions should not become informal workarounds.

Every exception should state:

The requirement being waived.
The business justification.
The duration.
The affected systems and users.
The risks introduced.
The compensating controls.
The accountable owner.
The expiry date.
The approval authority.
The remediation plan.

The Executive Data and AI Leader should ensure that:

High-risk exceptions receive appropriate senior approval.
Exceptions are time-limited.
Expired exceptions are reviewed.
Repeated exceptions trigger a policy or architecture review.
Exception volumes are monitored.
Teams cannot approve their own material exceptions.

A growing number of exceptions may indicate that the policy is unrealistic, the platform is inadequate or teams are bypassing governance.

17. Maintain Regional and Global Policy Alignment

Large professional-services organisations frequently operate under multiple layers of governance.

These may include:

Global AI principles.
Regional regulation.
National law.
Industry-specific requirements.
Firm-wide security policies.
Service-line standards.
Client contractual obligations.
Local professional rules.
Model-provider restrictions.

The Executive Data and AI Leader must ensure that local innovation remains aligned with global standards while also addressing regional requirements.

This can be difficult when:

Global policies are broad.
Regional laws are more restrictive.
Different countries classify risk differently.
A global platform lacks local functionality.
Client requirements exceed firm standards.
Responsibility is split across teams.
Regulations evolve faster than policy updates.

The leader should establish a clear hierarchy of requirements.

A practical principle is that the strictest applicable requirement should generally prevail unless legal or policy specialists determine otherwise.

The leader should also ensure that policy interpretation is converted into practical delivery guidance. Teams should not be expected to interpret complex legal and regulatory language without support.

18. Establish Clear Decision Rights

Risk governance fails when everyone participates in discussions but nobody has clear authority.

The operating model should distinguish between:

Who proposes.
Who assesses.
Who advises.
Who approves.
Who accepts residual risk.
Who operates the control.
Who monitors compliance.
Who can stop the system.

A typical decision structure may include:

Business owner

Accountable for the business outcome, process design, user adoption and operational impact.

Product or solution owner

Accountable for delivery, requirements, system performance and lifecycle management.

Data owner

Accountable for data quality, permitted use, access and retention.

Technology owner

Accountable for architecture, integration, reliability and technical operation.

Security owner

Advises on security risk and validates relevant controls.

Privacy or legal owner

Advises on privacy, legal basis, contracts, privilege and regulatory obligations.

Model-risk or Responsible AI owner

Assesses model behaviour, fairness, explainability, human oversight and AI-specific risk.

Professional-practice or independence owner

Determines whether the use is consistent with professional obligations.

Executive risk acceptor

Has the authority to accept significant residual risk.

Internal audit or independent assurance

Provides independent assessment of governance and control effectiveness.

The Executive Data and AI Leader ensures that these roles operate as one governance system rather than as disconnected approval functions.

19. Require Evidence, Not Reassurance

A mature risk decision cannot be based on statements such as:

“The model is industry leading.”
“The vendor says it is secure.”
“The team has tested it.”
“A human will check the output.”
“The data is anonymised.”
“The client is comfortable.”
“The pilot worked well.”
“The system is only advisory.”

The leader should ask for evidence.

Relevant evidence may include:

Architecture diagrams.
Data-flow maps.
Data-protection assessments.
Threat models.
Security-test results.
Model evaluations.
Bias and fairness assessments.
Accuracy and hallucination tests.
Human-oversight procedures.
Access-control records.
Vendor-risk assessments.
Contractual terms.
Client approvals.
Independence assessments.
Incident-response plans.
Monitoring dashboards.
User-acceptance results.
Training records.
Decision logs.
Residual-risk statements.

Evidence should be proportionate to risk, but material decisions should always be traceable.

20. Create an AI Assurance Case

For important systems, the leader should require an assurance case.

An assurance case is a structured argument showing why the system is considered acceptable for its intended use.

It should explain:

What the system is intended to do.
What it is not intended to do.
Who may use it.
What data it processes.
Which risks have been identified.
Which controls address those risks.
What testing has been completed.
What evidence supports the claims.
What limitations remain.
Who has approved the system.
How it will be monitored.
Under what conditions it will be suspended.

The assurance case creates a coherent view of the system rather than relying on separate documents held by different functions.

It is particularly valuable where multiple specialists must contribute to one executive decision.