AI Third-Party Risk Checklist: Assessing a Vendor Properly

AI vendors introduce risks that ordinary software vendors do not, and the assessment questions differ accordingly. This checklist covers them, drawn from FISTA Solutions' AI enablement governance work. This is general guidance, not legal advice.

What is being assessed?

Six areas beyond a standard vendor review.

Area	Why it is AI-specific
Data handling and training use	Your data may improve their product
Subprocessor chain	Extends to model providers
Audit trail access	You own the accountability
Model provenance and change	Behaviour shifts without your release
Quality assurance practice	No standard exists yet
Continuity	Young market, thin balance sheets

Data handling

Get it in the contract, not in an email.

• Whether inputs or outputs train any model, stated contractually
• Retention period for your data
• Processing and storage locations
• Deletion process and certification on termination
• Data segregation between customers
• Whether human reviewers see your data, and under what controls
• Handling of any special category data your use involves

Subprocessor chain

The chain extends further than for conventional software.

• All subprocessors named, including model providers
• Notification process for subprocessor changes
• Right to object to a new subprocessor
• Terms flowing down to subprocessors confirmed
• Locations of each subprocessor's processing
• Your obligations to disclose their subprocessors to your own customers
• Whether inference runs on the vendor's infrastructure or a third party's

Audit trail and accountability

You remain answerable for what their system decides. See the coming audit of AI systems.

• Decision records available to you
• Records exportable in a usable format
• Retention period for records matches your obligations
• Ability to answer a query about a specific past decision demonstrated
• Explanation available for automated decisions affecting individuals
• Incident notification obligations defined with timeframes
• Cooperation obligations for regulatory enquiries

Model provenance and change

Behaviour can change without any release on your side.

• Which models the product uses, and from whom
• Notice period before a model change
• Whether version pinning is available to you
• How the vendor evaluates a model change before deploying it
• Whether you can evaluate before a change reaches you
• Rollback capability if a change degrades your use
• History of past model changes and how they were handled

Quality and security practice

No standard exists, so ask for evidence rather than assurance.

• Evaluation practice described with actual examples
• Quality metrics reported to customers, and how often
• Handling of prompt injection and adversarial input
• Security certifications relevant to your sector
• Penetration testing cadence and scope
• Vulnerability disclosure and patching commitments
• Access controls on their side, including staff access to your data

Continuity and exit

A young market with many thin balance sheets. See AI vendor offboarding checklist.

• Financial stability assessed proportionate to dependence
• Service level commitments with meaningful remedies
• Disaster recovery and continuity arrangements
• Export capability tested, not just described
• Transition assistance provisions agreed
• Source escrow considered where dependence is high
• Your fallback if the vendor stops operating

What are the most common failures?

Assuming training terms rather than reading them. Not asking about subprocessors. Accepting audit trail as a roadmap item. Skipping assessment for AI features in existing products. And no tested export.

Who should own this?

Procurement runs the process; security assesses the posture; legal reviews data terms; the business owner accepts the residual risk. Assessment by procurement alone misses the technical and regulatory questions.

How often should it run?

At selection, at renewal, and whenever the vendor announces a material change to their model providers or data handling. Annual review for vendors handling customer data.

What evidence should it produce?

The completed assessment, contract terms on data handling and subprocessors, a tested export, and the residual risk acceptance with a named accepter.

How do you assess AI features in existing software?

With the same questions, applied when the feature is enabled rather than when the product was bought.

This is the largest unassessed exposure in most organisations, because the AI capability arrived through an update rather than a purchase. A periodic sweep asking which of your existing vendors have added AI features is the practical starting point. See what boards will ask about AI.

What should you do first?

Ask your most critical AI vendor to name their model providers. If they cannot, they have not assessed their own chain, which tells you something.

How FISTA Solutions helps

FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: vendor assessment covering the subprocessor chain to the model provider, with audit access and export tested rather than accepted as described, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To adapt this checklist to your environment, message FISTA on WhatsApp, or read AI vendor offboarding checklist.