Writing an AI Procurement Policy That Doesn't Block the Business

A working AI procurement policy does two things: it routes low-risk tools through in days, and it stops high-risk tools until someone competent has looked. Policies that treat every purchase the same fail at both, because the review queue fills with note-takers while the resume screener slips through on a corporate card.

Tier first. Everything else follows from the tiering.

How should the tiers be defined?

Not by price, and not by vendor size. By what the tool touches and what it decides.

Two notes on this table. First, price is deliberately absent. Free tools are frequently the highest risk, because nobody read the terms and the vendor's business model may involve training on your inputs. Second, the medium tier is where most tools land, and it should be the fastest path you have, not the slowest.

The high tier deserves the friction. A tool that screens job applicants, scores customers, or drafts clinical text is a different category of decision, and taking two weeks over it is proportionate.

What should you ask a vendor?

Twelve questions, and be willing to accept "no" as an answer as long as it is on the record.

1. Which model provider or providers sit behind your product, and can that change without notice?
2. Is our input used to train your models, or the underlying provider's models, under any plan?
3. Where is the data processed, and where does it come to rest?
4. What is your retention period for prompts, outputs, and logs, and can it be shortened?
5. Can we disable human review of our data by your staff?
6. Do you offer a data processing agreement, and does it name sub-processors?
7. How do you notify us of a sub-processor change, and can we object?
8. What happens to our data on termination, and how fast?
9. What is your incident notification commitment, in hours?
10. Do you hold SOC 2, ISO 27001, or ISO 42001, and can we see the report?
11. What is your documented accuracy, and on what data was it measured?
12. What are the known failure modes you have seen in production?

The last two are the ones nobody asks and the ones that separate serious vendors from wrappers. A vendor who cannot describe their failure modes has either not looked or will not say, and both are findings worth recording in your vendor inventory.

Where should you actually say no?

Four situations warrant a hard stop, regardless of how much the team wants the tool.

Training on your data with no opt-out. If the terms permit training on customer inputs and there is no enterprise tier that disables it, personal information should not go near it.

No data processing agreement. For anything touching personal information, a vendor unwilling to sign a DPA is telling you they have not built for business customers. That is a legitimate stage of company, and not one you can put customer data into.

Undisclosed sub-processors. If the vendor cannot name the model provider behind their product, you cannot assess where the data goes, and you cannot answer your own customers when they ask.

Automated decisions with no override. A tool that decides something about a person with no practical way for a human to reverse it fails the oversight expectations in both Quebec's Law 25 and every framework worth following.

Everything outside those four is a negotiation, not a veto.

How do you keep the policy from being ignored?

Make the compliant path faster than the non-compliant one. That is the entire trick, and it is more about operations than about drafting.

Three things that work. Publish the turnaround time you commit to for each tier and then meet it. Let low-tier registration be self-service, so most requests never reach a queue. And give a named person the authority to approve medium-tier tools alone, because a committee that meets monthly cannot serve a team that needs an answer this week.

One thing that does not work: enforcement through the expense process alone. Free tools and browser extensions leave no financial trail, which is why the AI system inventory and its discovery passes matter more than purchase approval.

What about tools you already have?

Run the tiering backwards over what is already in use, high tier first, and expect to find two or three things you would not approve today. That is normal and not a scandal. Record them, assess them, and either fix the configuration, negotiate the terms, or retire the tool with a date.

Resist the urge to retroactively approve everything to make the register look clean. An unresolved item with an owner and a date is a functioning programme. A register with no exceptions in it is one nobody believes.

For the deeper look at what a vendor relationship should carry contractually, reading a DPA before you sign it covers the clauses that decide your exposure.

This is general information, not legal advice.

Valdra tracks vendors, their sub-processors, their review dates, and the assessments attached to each one, so the procurement decision and its evidence stay together. The vendor inventory is where that starts.