Third-Party AI: Governing the Models You Didn't Build

The hidden majority

For most organizations, the largest share of AI exposure comes from technology vendors quietly adding AI features. A tool approved years ago may now send your data to a third-party model provider. The CRM drafts emails, the HR suite screens candidates, the support platform summarizes tickets—each a new AI use that arrived through a feature update rather than a procurement decision.

Traditional vendor risk programs often miss this because they were built around point-in-time assessment: evaluate the vendor, sign the contract, file the questionnaire, revisit at renewal. AI features do not respect that cycle. They arrive mid-contract, sometimes enabled by default, sometimes buried in release notes nobody reads.

The accountability point is uncomfortable but important: your customers, regulators and board will not distinguish between AI you built and AI you bought. If a vendor's model produces a biased outcome for your customers using your data, it is your problem. Governance has to extend across the boundary, or it does not extend at all.

Questions to add to due diligence

Extend your existing security and privacy questionnaires with a focused AI module. The goal is not a hundred new questions; it is a short set that forces specificity about how AI is actually used in the product:

Two of these questions do most of the work. 'Is customer data used to train or improve models?' establishes the single most important data boundary. 'How will we be notified of material model changes?' addresses the core structural problem—that the product you assessed is not the product you will be running next year.

• Which AI features exist, and can they be disabled?
• Which models and sub-processors are used?
• Is customer data used to train or improve models?
• How is output quality, bias and safety tested?
• What human oversight and logging is available to customers?
• How will we be notified of material model changes?

Contract terms that matter

Contracts are where commitments become enforceable. Marketing pages and reassurances from account managers do not survive a dispute; contract language does. Prioritize limits on training with your data, data residency and retention, transparency about sub-processors, notification of material changes and incidents, audit or evidence rights, and indemnification appropriate to the risk tier.

Expect pushback, especially from large vendors with standard terms. The realistic goal is not always bespoke language—it is knowing which terms you accepted by default and factoring that into the risk decision. A vendor that will not commit to keeping your data out of training sets may still be acceptable for a low-risk use and unacceptable for a high-risk one. The contract position is an input to the tier, not an afterthought.

For high-risk vendors, negotiate change notification explicitly. A commitment to notify before material model or sub-processor changes, with a window to reassess or exit, is the single most valuable AI-specific clause you can add.

Proportional effort

Apply your internal risk tiers to vendors too. A grammar assistant with no sensitive data needs a light review; a vendor screening job applicants needs a thorough assessment, documented evidence and periodic reassessment. Using the same tiering model internally and externally keeps the program coherent and gives vendors a predictable experience.

Proportionality also means accepting evidence instead of always generating it. A vendor with a current SOC 2 report, ISO/IEC 42001 certification or well-documented model cards has already done much of the work. Review what exists before sending another questionnaire—your vendors' goodwill is a finite resource, and the answers are often better in their formal documentation anyway.

Ongoing monitoring

Reassess at renewal, on material product changes and after incidents. Renewal is the natural checkpoint: commercial leverage is highest, and the vendor expects scrutiny. But do not let renewal be the only checkpoint—an annual cycle is too slow for products that update monthly.

Track vendor AI in the same inventory as internal systems so leadership sees one complete picture. A board asking 'where do we use AI?' should get an answer that includes the vendor screening your applicants and the platform summarizing your customer calls, not just the models your own team deployed.

Finally, plan for exit. For high-risk vendor AI, know what happens if the vendor has an incident, changes terms unacceptably or is acquired. Dependency without an exit plan is not a vendor relationship; it is a vulnerability.