Glossary

Vendor AI Assessment

A security review of a third-party AI feature or SaaS AI product, performed without runtime access to the vendor's source — based on documented architecture, declared data flows, and contractual control claims.

A vendor AI assessment is what a security review looks like when you cannot inspect the source. You cannot audit the vendor's model weights, the training data, or the runtime configuration. What you can audit is what the vendor has documented and what they will commit to contractually.

The assessment covers six evidence categories: documented architecture (model used, hosting, prompts, tool access); data handling policy (what enters the model, what is retained, where, used for training?); contractual control claims (in the contract or security addendum, not the marketing site); evidence of those claims (SOC 2, ISO 27001, penetration tests, model cards, AI-specific assessments); sub-processor list and accountability; and incident history and disclosure policy.

Vendor refusal to disclose is itself evidence. A vendor that declines to share their sub-processor list, model card, or AI-specific test results has produced an evidence gap of equivalent weight to a 'no'. The assessment record captures the refusal. The disposition can then require disclosure as a condition before moving from pilot to production.

EU AI Act applies. If you are the deployer of a vendor AI system that qualifies as high-risk under Annex III, you retain deployer obligations under Article 9 even though you did not build the system. The vendor assessment is your evidence that you assessed the system before deployment and continue to monitor changes.

Vendor assessments produce conditional clearances. The conditions cover what the vendor must commit to (contractually or evidenced) before the system progresses from pilot to production. They include re-assessment triggers: vendor changes model, adds sub-processors, has a disclosed AI incident.