A Practical Third-Party AI Governance Framework

A useful supplier AI programme follows the information and delegated capabilities through the delivery chain. It also asks who remains accountable, whether the service can survive a dependency shock and what value the supplier contributes.

The eight disciplines below bring the edition’s questions into one review. They are a practical framework proposed by this publication, not a certification scheme or a substitute for applicable legal duties.

01 · Know

Identify material AI use in development, support and operations. Record providers, purposes, accessible information and important downstream dependencies. Use a real customer workflow to check whether the inventory matches practice.

Evidence to request: a current workflow and dependency map with a named owner.

02 · Control

Examine what the AI can read, change, execute or transmit. Check credentials, customer separation, network destinations and approval for consequential actions. The system should enforce limits independently of instructions inside the model’s context.

Evidence to request: scoped permissions and a demonstration of how access is revoked.

03 · Flow down

Determine how protections follow information and access through model providers, tool operators and subcontractors. Coordinate personal data obligations with broader contractual protections for confidential Customer Information.

Evidence to request: the relevant downstream obligations and an explanation of any gaps.

04 · Monitor

Refresh assurance when the supplier’s architecture, providers, permissions or human review changes. Compare delivery activity with outcomes and investigate adverse patterns without treating weak signals as proof.

Evidence to request: a material change log, agreed reporting measures and review dates.

05 · Account

Keep responsibility clear when work is delegated to agents or other providers. Establish named owners for technical approval, incidents, customer communication and remediation. Check how records from downstream services support investigation.

Evidence to request: an incident scenario showing decisions, notification and evidence preservation.

06 · Resilience

Map critical model and infrastructure dependencies. Test how the service responds to outages, model retirement, reduced access and price shocks. Assess shared dependencies behind supposedly separate alternatives.

Evidence to request: a recent continuity or migration exercise, including its limitations.

07 · Exit

Plan how the customer can move when exposure becomes unacceptable or the service changes materially. Cover data, configuration, evaluation assets, tool integrations and transition assistance. A critical service needs an orderly path, not an untested right to terminate.

Evidence to request: export formats, a transition plan and realistic recovery timings.

08 · Value

Identify the supplier’s expertise, integration, validation and operational contribution. Compare complete costs and reliable outcomes. Ask which capabilities remain if access to the underlying model changes.

Evidence to request: demonstrations of difficult cases and measurable service outcomes.

Turn the framework into a review

Assign an internal owner and an evidence requirement to each discipline. At onboarding, establish the baseline. At renewal and material change, revisit it. After an incident, update the assumptions that proved wrong.

Record unresolved questions, agreed actions and the next review date. The objective is a continuing, proportionate conversation supported by evidence, rather than an annual questionnaire that no longer describes the service.

References and companion reading

• NCSC: Supply chain security for established supplier assurance principles.
• Your Supplier Contract May Describe Yesterday’s Service for the distinction between statutory duties and proposed contract rights.
• What Happens If Your AI Supplier Loses Its AI Supplier? for the dependency exit plan.