Chapter 1Two Problems with Every AI Quote

A quote for enterprise AI arrives on a CIO's desk looking like every other software quote of the last fifteen years. There is a per-user price, a minimum seat count, a term, and a discount schedule that rewards buying more seats than you need. Somewhere in the appendix is a data processing addendum. The two documents are reviewed by two different people, and the architecture that produced both is never discussed at all.

This chapter is about reading that quote the way an engineer reads it.

The per-seat arithmetic

Take a mid-sized university with 14,000 students and staff who would plausibly use an AI assistant. At a list price of $20 per person per month, the annual bill is $3.36 million. That number does not change if half the people never log in, because the pricing unit is the seat, not the work. It does not change in the summer. It does not change if the institution's own IT team could have served the same workload for a fraction of the cost, because the institution was never offered that option.

Enterprise tiers from the largest vendors sit between $30 and $60 per user per month. Vertical products for specific professions run far higher; legal assistants have been quoted at several hundred dollars per lawyer per month. The structure is identical in every case: a fixed monthly fee for every person you onboard, independent of what they consume.

Now look at what the same work costs when it is priced the way the underlying technology is actually sold. Model providers charge developers per million tokens, a few dollars for input and somewhat more for output on current frontier models, and a small fraction of that for models a few months behind the frontier. A typical knowledge-worker conversation consumes a few thousand tokens. Even a heavy user, running dozens of substantial conversations a day, consumes a few dollars of tokens a month. A light user consumes cents.

The gap between those two numbers is not a margin. It is a structural difference in what is being sold. The per-seat vendor is selling access to a model behind an interface it controls, priced to capture the value of the institution's headcount. The usage-priced alternative is selling the work actually done. Above a hundred users the two diverge by an order of magnitude; above a few thousand, by two. A SUNY team that understood this turned a six-figure multi-vendor quote into a deployment of roughly thirty thousand dollars. Syracuse University, deploying against model APIs inside its own cloud rather than buying per-seat plans, reported costs 85 percent lower than the per-seat alternative.

Where the data goes

The second problem is less visible on the quote and more visible in the incident report.

When a person types a question into a hosted AI assistant, the question, any document they attach, and often the content of the page or file they are looking at, leave the institution's network and arrive at the vendor's. The vendor's model processes it. The vendor's logging stores some version of it. The vendor's terms describe, in language reviewed by the vendor's lawyers, what the vendor may do with it. For a consumer product this is a fair exchange. For a hospital, a bank, a public agency or a university holding student records under federal privacy law, it is a transfer of custody that the institution did not design and cannot inspect.

The usual answer is a contract: a business associate agreement, a data processing addendum, a certification. These documents are necessary. They are not architecture. A contract promises that data will be handled a certain way. An architecture makes it impossible to handle it any other way. A CIO who has lived through a vendor breach knows which of the two they would rather be holding.

Why the two problems are one

Here is the connection that the quote obscures. The vendor can charge per seat because the vendor runs the system. The data goes to the vendor because the vendor runs the system. Both facts flow from a single architectural decision, made before the institution was ever in the room: the platform is hosted by the seller, the institution gets access, and access is what is priced.

Change that one decision and both problems change with it. If the institution runs the platform, on its own cloud account or its own hardware, the data never leaves. And because the institution runs it, there is no seat to sell; the institution pays the model providers for tokens, or runs open-weight models on its own GPUs and pays for electricity. The price becomes a function of work, and the data location becomes a function of the institution's own network diagram.

This is why I say the two problems are one decision. It is also why fixing them is an engineering project rather than a negotiation. No discount schedule turns a hosted product into one you run. No addendum moves the data back inside your firewall. Only the architecture does that.

What usage pricing changes

Usage pricing is not merely cheaper. It changes behaviour in ways that matter to a CIO.

It makes adoption free. Under per-seat pricing, every new user is a cost, so institutions ration access, run pilots with fifty people, and spend a year deciding who deserves a license. Under usage pricing, a user who never logs in costs nothing, so the platform can be offered to everyone on day one and the bill follows real use. The pilot becomes a question of what to connect, not whom to admit.

It makes the budget cap real. A pooled, rechargeable credit balance with a ceiling the institution sets cannot be exceeded. A per-seat contract can only be exceeded, because the next hire is the next seat.

It makes model choice an operating decision. When the institution pays the provider directly, switching from one model to a cheaper or better one is a configuration change with an immediate effect on the bill. When the model is bundled into a seat price, the vendor captures the savings from every improvement in the underlying technology and the institution sees none of it.

And it exposes the real cost of the work, which is the first step toward managing it. A CIO who knows that an advising conversation costs a few cents on one model and a fraction of a cent on another is in a position to make decisions. A CIO who knows only that the seat costs twenty dollars is not.

The question to ask every vendor

The rest of this book builds up a definition of sovereignty that can be verified line by line. But the first question is simple, and it can be asked of any vendor before the second meeting.

Who runs it?

If the answer is "we do, and you get access," then every other promise in the quote, about data, about price, about the roadmap, about what happens at the end of the term, depends on the vendor's continued goodwill and solvency. If the answer is "you do, and we help," then the institution is buying something it can keep.

Everything that follows is an elaboration of what "you do" has to mean in practice, layer by layer, for the answer to be true rather than merely marketable.