The vendor AI risk lifecycle

Lesson 1 of 5 in Third-Party AI, Generative AI, Agentic AI, and Frontier Governance.

Here is the uncomfortable arithmetic of modern AI governance: in most organizations, the majority of AI risk walks in through the procurement door, not the data-science lab. The hiring screen is a SaaS product. The fraud model is an API. The chatbot is a fine-tuned frontier model you have never seen the weights of. You are accountable for outcomes produced by systems you did not build, cannot inspect, and often cannot even test directly.

That is why mature programs treat third-party AI as a lifecycle, not a one-time checklist: pre-contract due diligence → contracting → onboarding → continuous monitoring → exit. Each stage has a distinct failure mode. Skip due diligence and you buy a lawsuit. Skip contracting and you have no rights when the vendor changes the model. Skip continuous monitoring and you discover the silent model update six months after it degraded your outcomes. Skip exit planning and the vendor holds your process hostage.

The vendor AI risk lifecycle

  1. Business wants an AI product
  2. Tier the vendor by AI criticality

    Not all vendors deserve the same scrutiny. Tier by decision impact (does it touch consequential decisions about people?), data sensitivity, and substitutability. A meeting-transcription tool and a credit-underwriting engine are not the same conversation.

  3. Due diligence

    Question sets on training data provenance, evaluation results, subprocessors, update cadence, incident history, certifications. The vendor’s refusal to answer is itself a finding.

  4. Answers acceptable?
  5. Contract with AI clauses

    Audit rights, no-training-on-our-data, model-change notification, bias-testing representations, indemnification, exit terms. Covered in the next lesson.

  6. Onboard: register + assess

    The system enters your AI inventory like any internal build — risk tier, owner, applicable regimes, required assessments. Vendor origin is a registry field, not an exemption.

  7. Continuous monitoring

    Annual re-attestation, output monitoring on YOUR population, tracking vendor incident disclosures and model-change notices, watching for silent feature additions.

  8. Material change or incident?
  9. Re-assess / renegotiate
  10. Exit: portability + teardown

    Data return and deletion certification, output portability, transition support, revocation of access. Designed at contract time, executed years later.

Due diligence is where you learn what kind of vendor you are dealing with. The questions that separate serious AI vendors from marketing decks:

  • Training data provenance — what went into the model, under what rights? A vendor who cannot describe their data sources is describing your future litigation exposure. Clearview AI’s customers learned this when regulators across Europe fined the scraping and courts constrained the product.
  • Evaluation evidence — not "our model is 95% accurate" but disaggregated results, on a population like yours, with the methodology attached. Ask for the model card or system card; a vendor without one has not done the work or will not show it.
  • The supply chain behind the product — which foundation model sits underneath? Which subprocessors touch your data? Many "AI vendors" are thin wrappers over a frontier API; your risk assessment must reach the model provider you never contracted with.
  • Update cadence and change control — how often does the model change, and will you be told? This question, more than any other, predicts operational pain.
  • Incident history and certifications — past incidents disclosed voluntarily are a good sign, not a bad one. ISO/IEC 42001 certification and SOC 2 reports with AI criteria are emerging table stakes for high-tier vendors.

Key terms: vendor due diligence, embedded ai, AI inventory, model card, system card, subprocessor

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.