How to Update Your Procurement Checklist for AI Vendor Contracts
A procurement checklist built for traditional SaaS covers real ground, and none of it should be thrown out. It just predates a category of risk, so several important questions never get asked.
What the existing checklist already gets right
Data storage and access security, standard escalator and notice period terms, basic vendor financial stability checks, integration and support requirements, standard compliance certification review. None of this needs to change for AI vendors. It's still directly relevant and shouldn't be duplicated or replaced, just extended.
Extend the checklist, don't fork the process
- Data storage and access security
- Escalator and notice period terms
- Vendor stability checks
- Integration and support requirements
- Data training usage
- Pricing structure clarity
- Model change notice
- Data and model portability
- Underlying provider dependency
- Acceptable use and output liability
- SLA scope for output quality
Placed directly after the standard security review, as a gate before sign-off rather than an optional deep dive.
Seven additions, and why standard checklists miss them
- Data training usage: is your data used to train or improve the vendor's models, opt-in or opt-out. Traditional SaaS doesn't process data through a model that could retain patterns from it
- Pricing structure clarity: seat-based, usage-based, or hybrid, and what specifically drives cost. Traditional SaaS pricing is overwhelmingly seat-based and predictable by default
- Model deprecation and change notice: what commitment exists around notifying you before the underlying model changes. Traditional software has no equivalent to a model that gets swapped
- Data and model portability: if you fine-tune or customize anything, does it transfer if you switch. Traditional SaaS configuration is portable in a way model customization isn't
- Underlying model provider dependency: if built on a third-party model, has that provider also been assessed. Traditional vendors rarely carry this kind of foundational dependency
- Acceptable use and output liability: who is responsible if the AI generates something problematic, and what usage restrictions apply. Traditional software doesn't generate novel content that creates its own liability
- SLA scope for output quality: does the SLA cover more than basic uptime. Traditional SLAs were never designed to address output quality degradation
Who owns each addition
Add the seven items as a required addendum triggered whenever an evaluation involves an AI capability, core product or a feature added to an otherwise traditional tool. Then assign ownership: data training and acceptable use review sit naturally with legal or compliance, pricing structure and portability with whoever owns vendor negotiation, model deprecation and SLA scope with IT or the technical team that will depend on output consistency.
Where the addendum belongs in the workflow
The cleanest integration point is right after the standard security review. Once a vendor has cleared the baseline checks, route any AI-capability vendor through the addendum before final sign-off, rather than treating it as a parallel process that might get skipped under time pressure. Making it a required gate rather than an optional deep dive is what gets it applied consistently, not only to the vendors someone remembers are AI enough to warrant extra scrutiny.
The question that surfaces eight months late
A procurement team runs its standard checklist on a new AI analytics tool, covers security and pricing structure, and approves it on the normal timeline because nothing raised a flag. Only later, during a broader AI governance initiative, does anyone check whether the vendor uses customer data for model training. The answer turns out to require an internal legal review that should have happened before signing, not eight months into the term when unwinding the arrangement is far more disruptive.