Field Guide · Vendors & procurement
What to Ask Before Signing the Next AI Contract
Many consequential AI decisions arrive through vendor contracts or embedded features in systems the institution already owns. Readiness starts before procurement, not after.
Most institutional AI decisions do not arrive as strategy. They arrive as contracts, one at a time, each looking reasonable. Readiness is knowing what to ask before the signature.
The demo went well. It usually does. The product found the at-risk students in the sample data, drafted the emails, generated the report that normally takes a week, and did it all through a clean interface with the institution’s colors already loaded. Somewhere in the room, someone whispered the only question that matters less than people think: how much does it cost?
Here is the thing about AI strategy in higher education right now. For most institutions it will not be written in a strategic plan. It will be assembled, contract by contract, from a series of procurement decisions that each felt too small to escalate. The vendor conversations are where the abstract governance work of the last six issues either shows up or does not. A committee with decision rights, a policy with teeth, data rules with bright lines: all of it gets tested in the moment someone is holding a pen.
The institutional question
What does AI readiness look like before procurement, not after?
After procurement, your options are what the contract says they are. Before procurement, everything is negotiable and every question is free. The institutions that get this right are not the ones with the cleverest lawyers at renewal time. They are the ones that asked ordinary questions at the start, wrote the answers into the agreement, and walked away from vendors who would not put the answers in writing.
What this looks like in practice
Start with the question underneath every other question: what happens to our data? Not the marketing answer, the contractual one. Where is it stored and processed. Who can see it. Whether the vendor uses it to train models, and if so, whose. What happens to it when the contract ends. Whether the vendor will notify you of a breach, and how fast. If student records are involved, the FERPA questions from the last issue come with the territory, and the agreement needs to survive them. A vendor who answers these fluently has been asked before. A vendor who gets vague is telling you something more useful than the demo did.
Then the exit, which is the part everyone skips while they are excited. Can you get your data out, in a usable format, without a fee that punishes leaving? What happens if the price triples at renewal, once your advisors have built three years of workflow into the tool? Lock-in is rarely a dramatic event. It is a slow accumulation of dependence that converts your renewal conversation from a negotiation into a hostage exchange. The time to prevent that is before the first signature, when you still have the one thing you never get back: the ability to walk away cheaply.
Ask about the vendor’s own footing, too. The AI market is young, crowded, and consolidating. Some of these companies will be acquired, some will pivot, some will quietly die, and some will change their terms when the venture money wants a return. What happens to your data and your workflows in each of those futures is a fair question to ask out loud. A vendor’s financial stability is not a rude topic. It is a dependency you are agreeing to carry.
And ask what the product actually does, in your context, with your data, at your scale. The demo ran on data curated to make the product look good, which is fair, that is what demos are for. A structured pilot with clear success criteria, defined before the pilot starts, is how you find out whether the tool works on your campus rather than in the vendor’s best case. If a vendor resists a pilot with measurable goals, that is also an answer.
Who should be asking all this? Not IT alone. A tool that touches advising needs advising in the evaluation. A tool that touches student data needs whoever owns data governance. The pattern to avoid is the one where the office with the budget picks the tool and everyone else discovers it at rollout. Procurement is a governance act wearing an administrative costume, which is why the decision-rights work from earlier in the series matters here more than anywhere.
Two quieter cases deserve a mention. The first is the AI that arrives without a procurement decision at all: features switched on inside platforms you already license, through a routine product update nobody evaluated. Your LMS, your CRM, your meeting software. Somebody needs to notice when the tools you already own become AI tools, because the contract you signed three years ago did not contemplate what the product does now. The second is the small purchase. A department buys a niche AI tool on a corporate card for less than the threshold that triggers review, and it quietly becomes infrastructure. Threshold rules were written for software that stayed put. AI tools rarely do.
None of this requires an adversarial posture toward vendors. Most are not villains, and some will become genuine partners. The point is that a partnership is what you have after the hard questions are answered in writing. Before that, it is a sales relationship, however friendly.
The Atlas connection
In Atlas, our AI operating map, this is the vendor and procurement domain, in the Defense group — Protect — and it is where much of the map converges into a single, repeated institutional moment: the decision to sign. It draws on governance, over in Foundation, for who evaluates and who approves; on data governance for the data agreement; on security and risk for the risk assessment; on the equity and ethics lens for bias testing; and on compliance and legal for the floor the whole thing has to clear. If those domains are healthy, the contract questions almost ask themselves. If they are not, the vendor’s paper becomes your policy by default, which is the quietest way an institution loses control of its AI posture.
Questions worth putting on the agenda
These work as a pre-signature checklist for any AI purchase, large or small.
- Does the agreement say, in writing, where our data lives, who sees it, whether it trains models, and what happens to it at exit?
- Can we leave? What does getting our data out actually cost, in fees and in disruption?
- What happens if this vendor is acquired, shuts down, or changes its terms mid-contract?
- Did we run a pilot with success criteria we defined before the pilot started?
- Who besides IT evaluated this, and did the people whose work it touches have a real voice?
- Who is watching for AI features that appear inside platforms we already license?
The bottom line
Your AI strategy will be written one contract at a time, whether or not anyone calls it a strategy. Each signature is a small transfer of institutional dependence, and the questions you did not ask become the terms you did not set.
The best time to negotiate is the moment before you need to. There is no second-best time. There is just the renewal.
Also published on LinkedIn: read this guide on the newsletter .