IAPP AIGP: Managing Third-Party AI Risk
Third-party AI risk is difficult because the organization depends on a system it does not fully control. A vendor can change models, subprocessors, security controls, training practices, pricing, retention, geographic processing, or service limits while the customer continues to depend on the same business workflow. Governance therefore has to manage both the AI behavior and the dependency relationship.
The current AIGP framework treats deployment and lifecycle governance as broader than internal development. That is important because many organizations consume AI through SaaS products, embedded copilots, APIs, and enterprise platforms rather than training their own models. The governance responsibility does not disappear just because the model was purchased.
Within AI governance, third-party oversight should connect procurement, privacy, security, legal, data, business ownership, continuity, and technical operations. A vendor review is useful only if its findings change the permitted use, contract, architecture, monitoring, or contingency plan.
Map the dependency before scoring the vendor
Start by describing what the organization actually depends on. Is the vendor providing a model API, a complete application, an agent platform, a retrieval service, or an AI feature inside a larger product? Which business processes stop if the service is unavailable? Which data classes flow to the provider? Which decisions or actions rely on the output?
Dependency risk is more useful than a generic vendor label because two services from the same supplier can have very different consequences. A low-impact drafting assistant and an automated customer-decision service deserve different depth of review even if the vendor questionnaire is identical.
Document upstream and downstream dependencies too. A vendor may rely on a foundation-model provider, cloud platform, content-moderation service, or data subprocessors. The customer may integrate the output into ticketing, identity, finance, or customer systems. Those relationships determine the true failure path.
Decide what evidence is necessary
Evidence requirements should follow consequence. Security attestations, privacy documentation, model information, evaluation summaries, incident history, architecture diagrams, retention details, data-location commitments, and business-continuity information can all be useful, but not every low-risk tool needs the same package.
For higher-impact uses, ask what the vendor can demonstrate about model changes, evaluation, human oversight, abuse controls, data use, access, logging, and incident response. If a critical behavior cannot be tested by the customer or evidenced by the supplier, record that uncertainty rather than treating missing information as neutral.
AI risk registers should link vendor uncertainties to business scenarios. “Vendor does not disclose training data” becomes decision-relevant when it connects to intellectual-property, bias, privacy, or regulatory exposure in the intended use.
Contract for the controls that matter
Contracts cannot guarantee good AI behavior, but they can create enforceable expectations around data use, confidentiality, security, subcontractors, model updates, incident notification, audit evidence, retention, deletion, service levels, termination, and assistance during transition. The contract should reflect the actual use case rather than rely only on standard procurement language.
Pay attention to unilateral-change rights. If a provider can materially change the model or data practices without notice, the organization may lose the ability to reassess before the risk changes. For important services, notice and change-control terms can be as valuable as static representations made at signing.
Exit rights matter when the dependency is hard to replace. Data export, configuration portability, transition assistance, deletion evidence, and continued access during migration can reduce the operational leverage created by lock-in.
Control what data reaches the provider
The organization should know which prompts, attachments, retrieved documents, metadata, telemetry, and user identifiers are transmitted. Data minimization is often a stronger control than relying on contractual promises after sensitive information has already left the environment.
Data governance can define permitted data classes, owners, retention, and access. Technical controls can then enforce those decisions through redaction, retrieval boundaries, tokenization, private connectivity, policy gateways, or approved workspaces.
Do not assume that a setting labeled “no training” answers every data question. The provider may still retain logs for support, abuse detection, security, or billing. Governance should map the complete service behavior relevant to the organization’s obligations.
Plan for model and product changes
Third-party AI systems can change without a customer deployment. A model upgrade may improve general quality while changing refusal behavior, output style, latency, token limits, safety filtering, or performance on a specialized task. Product features can also gain new agentic capabilities or integrations that expand the risk surface.
Define which vendor changes require reassessment and how the organization will learn about them. Release notes, API versioning, contractual notices, evaluation monitoring, and technical canaries can all contribute. High-impact workflows may need regression tests against critical scenarios before a new vendor model becomes the default.
Governance drift is a real third-party problem because internal approval can remain static while the external service evolves. Governance controls should detect material change rather than assume the approved product is permanently the same product.
Monitor the service in your context
Vendor benchmarks are useful background, but the deploying organization needs evidence from its own users, data, prompts, languages, and workflows. Monitor quality, safety, latency, availability, cost, escalation rates, user feedback, and high-severity failure scenarios that matter to the business.
AI observability should include the vendor boundary. When performance degrades, teams need to distinguish internal retrieval, prompt, integration, and data issues from changes in the external model or service.
Keep a path for user-reported issues that vendor telemetry cannot see. A customer may identify misleading advice or sensitive output long before aggregate monitoring shows a statistical shift. Operational ownership should connect those reports to vendor escalation and internal risk review.
Prepare for outage and exit
Continuity planning should match dependency. If the AI feature is optional, the fallback may be to disable it. If it sits in a critical workflow, the organization may need a manual process, alternate provider, cached capability, degraded mode, or explicit business-continuity procedure.
Test the fallback. A documented statement that employees can “work manually” is weak if the manual process has not been used since automation was introduced. Exit planning should also account for prompts, retrieval configurations, evaluation suites, integrations, and user training that may not transfer directly to another supplier.
Business continuity is relevant because resilience comes from executable alternatives, not only contracts. The more central the vendor becomes to an operating process, the more important those alternatives become.
Keep accountability with the deploying organization
Teams working toward IAPP certifications should remember that third-party due diligence is not a transfer of accountability. The organization still chooses the use case, data, configuration, users, integrations, level of automation, monitoring, and acceptable residual risk.
Assign clear internal owners for vendor performance, contract obligations, security findings, privacy commitments, model changes, and business continuity. One relationship manager cannot own every specialized obligation for a high-impact service.
A mature program can reuse evidence across vendors while keeping decisions use-case specific. Standard questionnaires, contract clauses, assessment tiers, and monitoring controls improve efficiency, but the final approval should still reflect how the service will actually be used.
Third-party AI governance is the management of dependency under uncertainty. Strong programs understand what they rely on, obtain evidence proportional to consequence, control data flows, contract for important behaviors, monitor change, and maintain a credible exit path.
The vendor supplies technology; the deploying organization remains responsible for deciding whether that technology is appropriate for the business context in which it is used.
Tier vendors by use-case consequence
A scalable program can tier reviews by consequence rather than treating every AI vendor as equally risky. Low-impact experimentation with public data may need basic security and acceptable-use checks. Systems that process sensitive data, make material recommendations, or automate customer-facing actions justify deeper technical, legal, privacy, resilience, and governance review.
Tiering should be based on the proposed use, not the vendor brand. A large established supplier can still create high exposure in a sensitive workflow, while a smaller specialist service may be low impact if it receives no confidential data and can be disabled without operational disruption.
Document the criteria so business teams can predict the review path before procurement begins. Clear tiers reduce friction because teams know which evidence and approvals will be required for the risk they are introducing.
Review concentration and correlated failure
Vendor risk becomes enterprise risk when many important systems depend on the same model provider, cloud platform, identity service, or data processor. Individual assessments may look acceptable while the combined dependency creates a single point of operational or strategic failure.
Maintain a portfolio view of critical AI suppliers and shared subprocessors. Ask what happens if one provider has a regional outage, changes its acceptable-use policy, suffers a security incident, or becomes unavailable for commercial or regulatory reasons. Concentration may justify stronger continuity controls than any one use case would require.
The same analysis can reveal negotiation leverage and monitoring priorities. A supplier supporting dozens of high-impact workflows deserves more structured relationship management than one used for a small optional feature.
Keep an evidence calendar
Vendor evidence expires. Security reports, insurance, subprocessors, model documentation, continuity tests, and contract commitments can all change on different schedules. Maintain review dates and trigger-based refresh rules so high-impact suppliers are not approved once and then forgotten.
Evidence collection should be coordinated across functions to avoid asking the supplier for the same material repeatedly. A shared record also lets privacy, security, procurement, risk, and business owners see which questions remain unresolved before renewal or expansion.