Third-party AI risk management
Decide which supplier and deployment risks need evidence and ownership
When an agent depends on external AI products or services, this area becomes relevant. For the third-party risk and AI system owner, the concern is specific: supplier documentation is accepted as evidence for controls the customer must configure. The governance implementation design starts from that consequence and follows the relevant evidence through the customer workflow. Third-party review should connect supplier evidence to the actual deployment. Separate properties of the provider's service from customer configuration, integration behaviour, and operating responsibilities that remain outside the supplier's assurances.
Connect the operating question to inspectable evidence
- Third-party risk and AI system owner
- Owns the bounded decision and the consequence of acting.
- Provider inventory
- Defines the starting context for the proposed work.
- Customer configuration responsibility
- Exposes the first material uncertainty to examine.
- Shared responsibility and exit map
- Carries unresolved conditions into an accountable next action.
Decision at stake
Decide which supplier and deployment risks need evidence and ownership
Make the decision explicit
- Third-party risk and AI system owner
- An agent depends on external AI products or services.
- Decision
- Which supplier and deployment risks need evidence and ownership.
- Customer configuration responsibility
- Use provider inventory to establish the relevant starting condition.
For the third-party risk and AI system owner, this becomes relevant when an agent depends on external AI products or services. The immediate decision is which supplier and deployment risks need evidence and ownership. The scope should be narrow enough that the governance owners can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that supplier documentation is accepted as evidence for controls the customer must configure. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Coverage
Examine customer configuration responsibility alongside change notification
Keep the review distinctions visible
- Customer configuration responsibility
- Separate provider statements from customer-controlled configuration.
- Change notification
- Identify material provider changes that invalidate local evidence.
- Exit and incident support
- Allocate evidence access, containment assistance and transition obligations.
Customer configuration responsibility
For this scope, customer configuration responsibility should be examined alongside provider inventory. Separate supplier-controlled properties from customer configuration and integration behaviour. Review the actual deployed data and action paths. The proposed assessment should identify which supplier documents are relevant and where they cannot answer questions about the customer’s use of the service.
Change notification
For this scope, change notification should be examined alongside data and service dependencies. Examine how material provider changes reach the customer and which owner decides what to reassess. A notification clause or status page is not the same as an operating response. The review should trace a representative change from detection to impact assessment and action.
Exit and incident support
For this scope, exit and incident support should be examined alongside supplier assurance materials. Review incident support, data return, replacement, and exit dependencies in the intended deployment. Identify which questions require legal interpretation and which can be answered technically. Missing information should remain a named procurement or operating dependency instead of an assumed supplier commitment.
Prerequisites
Start with provider inventory
Give each input a specific job
- Provider inventory
- Defines the operating boundary.
- Data and service dependencies
- Examine change notification.
- Supplier assurance materials
- Shows conditions affecting exit and incident support.
- Policy or risk owner
- Confirm access and a reviewer who can resolve gaps.
The starting material is provider inventory, data and service dependencies, and supplier assurance materials. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include an accountable policy or risk owner, relevant system owners, and qualified legal or domain reviewers when interpretation is needed. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Follow the requirement into an accountable operating practice
Follow the evidence through the work
- Customer configuration responsibility
Use provider inventory to define the decision criteria.
- Change notification
Inspect data and service dependencies and retain observations that challenge the expected result.
- Exit and incident support
Use supplier assurance materials to identify unresolved conditions and a responsible owner.
- Shared responsibility and exit map
Link the recommendation to its evidence, remaining limits and next validation condition.
Separate supplier statements from deployment evidence in the review record. A provider may describe its infrastructure or contractual practices while the customer’s agent configuration determines data flows and authority. The proposed assessment should identify which questions require supplier clarification and which can only be answered by inspecting the customer’s integration.
A practical first slice would focus on customer configuration responsibility and then follow its consequences into change notification. Keep exit and incident support visible as a separate review question rather than assuming it is satisfied by the first result. The governance owners should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefacts
Use shared responsibility and exit map to make the next action explicit
Every artefact needs an operating use
Illustrative working format
- Third-party AI risk profile
- Boundary — provider inventory.
- Evidence request list
- Findings about change notification.
- Shared responsibility and exit map
- Action on exit and incident support.
Indicative outputs include third-party AI risk profile, evidence request list, and shared responsibility and exit map. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Three provider boundaries: visible dependencies
Examine the constructed decision boundary
Illustrative scenario
- Three provider boundaries
An agent combines managed modelling, external retrieval and a separate connector.
- Task-data trace
Follow the data path and locate change, incident-support and exit responsibilities.
- Visible dependencies
Keep unanswered ownership questions open and send legal interpretation to qualified reviewers.
Consider an illustrative situation in which an agent uses a managed model, external retrieval service, and connector from different providers. This is a constructed example, not a client engagement or an observed Softlander outcome.
For the multi-provider agent, an illustrative mapping would trace a task’s data through model, retrieval, and connector services. The review would identify ownership of change notifications, incident support, and exit. Missing answers should remain visible procurement or operating dependencies, with legal interpretation assigned to qualified reviewers.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves exit and incident support unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and authority
Governance evidence supports decisions within defined professional limits
Keep analytical work separate from decision authority
- Operating requirements and evidence mapping
- Can include third-party AI risk profile.
- Policy or risk owner
- Authorised policy owners decide; qualified specialists interpret professional requirements.
- Legal conclusions and certification decisions
- Cannot be inferred from evidence request list.
This work supports governance preparation and operating evidence. It does not provide legal advice, determine regulatory compliance, award certification, or replace a formal audit. Authorised customer owners retain policy, release, and residual-risk decisions.
Ways to engage
Related engagement scopes
AI Privacy Engineering Review
Trace personal data through your agent workflow. Examine collection, memory, retrieval, tool access and retention against your agreed requirements.
AI Governance Operating System
Make AI oversight part of daily operations. Connect inventories, accountable owners, change decisions and evidence into a workable governance process.
Continue exploring
Related insights and resources
Governing agent decisions
Governance becomes useful when it changes a decision. Connect each agent workflow to an accountable owner, explicit operating conditions, proportionate evidence and a practical route for exceptions and withdrawal.
Protecting agent data and memory
An agent's information footprint extends beyond the conversation. Map the copies, derived records and retrieval paths that influence future actions, then connect each to purpose, access, retention and verifiable handling.
AI agents in legal operations: assistance without invented authority
Legal agents can organize evidence and prepare work, but professional judgement, client authority and verified legal positions cannot be delegated by interface.