LLM·Dex
ProcurementEnterpriseCompliance

The AI Tool Procurement Checklist

If you're a CTO buying an AI assistant for the company, here's the list to run before you sign. License, security, data handling, vendor stability.

By LLMDex Editorial

Buying an AI assistant for an organization in 2026 is not the same as picking the model with the best benchmark score. The procurement layer matters, license terms, data handling, security posture, vendor stability, IP indemnification, and getting it wrong is expensive in ways that don't show up at evaluation time.

This article is a checklist we'd run on any AI tool before signing. It's the questions a CTO should ask, the gotchas to look for, and the order to ask them in.

Before you start

Three preliminary decisions:

1. What's the actual workload?

"AI for productivity" is not a workload. "AI coding assistant for our 50 engineers, deployed on our Github Enterprise repos" is a workload. Specifics matter for procurement because they determine which compliance regimes apply.

2. Who's the buyer / champion?

Engineering procurement is different from operations procurement. Engineering teams care about feature parity and developer experience; operations care about license clarity and audit trails. Match the procurement process to the actual buyer.

3. What's the failure mode?

If the AI tool is unavailable for a day, what happens? If it leaks data, what happens? If the vendor goes out of business, what happens? Set the bar for risk tolerance before evaluating.

The checklist

1. License terms

  • Is the model open-weight or closed? This determines what self-hosting options exist as a fallback.
  • Are there revenue or user caps? Llama's community license has revenue thresholds; some other licenses have them too.
  • Is commercial use permitted in your industry? Some licenses explicitly carve out certain industries (defense, healthcare).
  • Is fine-tuning the model allowed? And can you commercially deploy a fine-tuned version?
  • What about derivative works? Custom GPTs, fine-tuned variants, model distillations, are these permitted?

For closed-frontier models, the license is the provider's terms of service. For open-weight, the license file is in the repo. Read it.

2. Data handling

  • Are inputs used for training? OpenAI defaults to opt-out for API customers, but Plus / Pro tiers may differ.
  • Are inputs stored, and for how long? 30-day retention is typical for closed providers; some offer zero-retention via custom contracts.
  • Where is data processed? Geographic data residency matters for GDPR, EU AI Act, and various state regimes.
  • What's the breach notification policy? If a security incident occurs, when do you find out?
  • Are sub-processors disclosed? A model provider often uses cloud sub-providers; their compliance posture matters too.

For enterprise customers, get a Data Processing Addendum (DPA) signed before any non-trivial usage.

3. Security posture

  • SOC 2 Type II? ISO 27001? HIPAA? GDPR? FedRAMP? Match the provider's certifications to your industry's requirements.
  • What's the auth model? SAML SSO, role-based access controls, audit logs, table stakes for enterprise.
  • Encryption at rest and in transit? TLS 1.2+, AES-256. Yes, you should still ask.
  • Penetration testing cadence? Annual at minimum from any serious vendor.
  • Bug bounty program? A public bounty signals real security investment.

4. IP indemnification

This is the under-discussed but critical piece. If your AI assistant generates code that turns out to be a verbatim copy of GPL'd code from training data, who's liable?

  • Does the provider indemnify you against IP claims on output? OpenAI, Anthropic, Microsoft / GitHub, Google, and AWS all offer this for enterprise customers. Smaller providers often don't.
  • What are the exclusion conditions? Most indemnification has carve-outs (the user must use enterprise features, comply with policies, etc.).
  • What's the cap on liability? The number after the comma matters.

For any production code-generation use case, IP indemnification is the most important contractual term you'll review. If a vendor doesn't offer it, that's often a deal-breaker.

5. Service-level agreements

  • What's the uptime guarantee? 99.9% is standard for enterprise; below that is usually a red flag.
  • What's the credit on outage? Service credits are usually small but they signal commitment.
  • What's the latency guarantee? Less standard but increasingly important for production agents.
  • Rate limits? Both at floor (your typical day) and ceiling (your worst-case spike).

6. Vendor stability

  • How long has the vendor existed? Younger vendors are higher risk. Less of an issue for the Big Three but real for newer entrants.
  • What's the funding picture? A startup with 6 months of runway is a different bet than one with 5 years.
  • What's the customer concentration? A vendor whose top 5 customers are 80% of revenue is at risk if one churns.
  • Source code escrow? For mission-critical deployments, escrow is sometimes worth negotiating.

7. Migration

  • How portable is the workflow? If you build against this tool's specific API surface, can you migrate?
  • Data export? Can you get your prompts, conversations, or fine-tuned models out?
  • Standards adoption? A vendor that supports MCP, OpenAI-compatible APIs, etc. is more migratable than one that's proprietary-everything.

If you're getting locked in deeply, build a migration plan before you sign. The right time to think about leaving is before you arrive.

8. Pricing model

  • Per-seat, per-token, per-call, or hybrid? Each has different scaling characteristics.
  • What's the price escalation clause? Year-2 pricing matters more than year-1.
  • Are there usage caps that trigger surge pricing? Avoid contracts that surprise you.
  • What's the cancellation policy? 30 days is reasonable; auto-renewal with 90-day notice requirements is hostile.

9. Compliance specifics

For regulated industries, sector-specific questions:

  • Healthcare: BAA available? HIPAA controls in place? PHI handling explicit?
  • Financial services: SOC 2 + relevant ISO? Audit support?
  • Government: FedRAMP? StateRAMP? CMMC?
  • EU: GDPR DPA? EU data residency? EU AI Act compliance?

Match the provider's compliance posture to your regulatory exposure. The AI tool that's perfect for a startup may be unusable for a healthcare provider.

10. Real-world references

Three references in your industry, similar size, using the tool in production. Specific questions:

  • "What broke that you didn't expect?"
  • "What's the support quality like when something's wrong?"
  • "If you had to do procurement again, what would you ask differently?"

References that are too positive are suspicious. Real users have nuanced views.

Red flags

A short list of things that should make you pause:

  • No security questionnaire response within 5 business days. Either the vendor is overwhelmed or under-resourced. Both are problems.
  • "Custom" pricing for the basic tier. Usually means the standard tier doesn't include something material.
  • No published list of certifications. If they have them, they'd say.
  • Refusal to share their data handling architecture. Either it's bad or they're uncooperative. Both are bad.
  • Insistence on auto-renewal with onerous notice periods. Vendor confidence in the product, in a bad way.

Green flags

The opposites:

  • Pre-prepared security responses with detailed certifications, sub-processors, and data flow diagrams. Indicates the vendor has done this before.
  • Public pricing across all tiers. Transparency.
  • Recent customer wins in your industry. Means they're already meeting your bar.
  • Active engineering team blogging about technical decisions. Means the team is real and accountable.
  • Open-source components. A vendor that's transparent about its stack is generally a better bet than one that isn't.

What to skip

Three things procurement processes often over-emphasize:

  • The pitch deck's "AI quality" claims. They're not falsifiable. Run your own eval.
  • The vendor's roadmap. Roadmaps move. Buy what works today.
  • Surface-level "feature comparison" matrices. They miss the operational realities (uptime, support, integration depth).

The honest takeaway

AI procurement in 2026 looks more like SaaS procurement than software procurement. The model itself is one part of the deal; the security posture, the data handling, the IP indemnification, the SLA, and the vendor stability are the other parts. Run the checklist. Don't sign without it.

For most enterprises, the conservative pick (Microsoft / GitHub Enterprise + Copilot, AWS Bedrock + Anthropic, Google Vertex + Gemini) is procurement-friendlier than the cutting-edge alternative. The cutting-edge alternative is sometimes the right call, but only after the checklist is satisfied.

Further reading

Keep reading

Friday digest

Intelligence, distilled weekly.

One short email every Friday, new model launches, leaderboard moves, and pricing drops. Curated by hand. Free, no spam.