When I teach AI procurement to government or industry audiences, I always include two slides at the beginning of every presentation. First, I teach the AI tech stack as a wedding cake. That helps people visualize the AI supply chain as tiers, from the foundational infrastructure supporting it (the cake stand) to the governance that surrounds it (the frosting). The cake answers the first question every acquisition professional must ask: what exactly am I buying? They need to understand that they are effectively buying a stack, not just an app.
But the cake can’t answer the second question: how does the model at the center of that stack actually work? And what does that mean for your intellectual property, your business processes, your compliance obligations, and your procurement risk?
Answering those questions requires a basic level of AI literacy, so to help explain it, I turn to another food-related analogy: the chef. The chef is the model, and her career illustrates how a model is developed, adapted, and used.
One caveat before we start. Like the wedding cake, this is not a technical taxonomy, and it will not cover every configuration. Real-world AI deployments are more complex than a single chef, and the vocabulary is much larger than the five terms discussed below. But these are the basics, and they are essential for everyone negotiating AI contracts.
Culinary school: training
Before the chef ever cooks for you, she goes to culinary school. She learns knife skills, sauces, techniques, and food safety: a general capability across an enormous range of cooking. That’s training, the process that builds a foundation model’s broad ability, using massive amounts of data, generally before you show up. You usually had no say in her education, and yet you inherit it, good habits and bad, because it shaped everything she does.
The apprenticeship: fine-tuning
After school, the chef apprentices at a French restaurant. She’s now specializing—learning a particular cuisine through hands-on work. When she’s finished, she’s not just a chef anymore. She’s a French chef. That’s fine-tuning: taking a generally capable model and adapting it to a specific purpose. Keep in mind that the apprenticeship is training, too. It’s specialized training layered on top of what she learned at culinary school. Now you might be thinking, “Of course, an apprenticeship is training!” If so, great, because remembering this fact is really important during your contract negotiations (more on this below).
One more thing about this stage, because everything that follows depends on it: what she learns in the apprenticeship isn’t a binder she can return at the end. It’s essentially muscle memory. For all practical purposes, she can no more hand it back than you can forget how to ride a bicycle.
The recipe book: RAG
Now she’s cooking at your restaurant, and tonight’s menu includes a dish she hasn’t made since culinary school. She could try to remember it, reaching all the way back to her lessons, reconstructing the recipe from a years-old impression. Sometimes she will get it right. Sometimes she will confidently produce something that looks sort of like the dish but isn’t quite right. That confident invention is a hallucination, and it’s especially likely when a model generates an answer from distant training rather than from a source in front of it.
So, to reduce that risk, you hand her a recipe book to reference during service. That’s RAG, retrieval-augmented generation. The model doesn’t have to remember—it looks things up in materials placed in front of it, often materials you supplied. And if you’re wondering why a trained specialist needs your book at all, that’s the point. You are not relying only on her memory. You bring the information, and she brings the skills to work with it. This is why RAG exists: as a hedge against the model’s memory. The recipe book helps, but it isn’t a guarantee, so the system can still pull the wrong recipe, and the chef can still misread the right one.
Standing instructions: configuration
Before service, the chef gets the restaurant’s standing instructions: the house style, the permitted substitutions, the safety checks she must run. That’s configuration: the system prompts, settings, and standing policies that tell the model how to behave for you specifically. Similar to the recipe book, the instructions are something you handed her. They don’t change who she is. If you take the instruction sheet off the wall, she reverts to the way she used to cook.
Dinner service: inference
Next, the orders are placed, each with its own details (say, the allergy at table six), and she cooks[1] the order. Every plate served to diners is inference, the model applying everything above (her schooling, her apprenticeship, the recipe book, the instructions) to produce an output in response to a specific request. This is the only part of the chef’s entire career that you, the AI user, actually see. Everything else happened backstage, and yet it’s your name over the door.
Once you understand her career, read a common assurance in AI contracting, “we don’t train on your data,” and notice how little it says.
The AI contract’s promise
Here’s why the chef is critical to your contracts. Once you understand her career, read a common assurance in AI contracting, “we don’t train on your data,” and notice how little it says.
Start with the word “train.” Remember that the apprenticeship is training, too, so the promise should extend to fine-tuning as well as to the culinary school. But unless your contract defines the term, its scope is open to interpretation, and in day-to-day performance, the vendor’s reading is applied first, by the party with the least incentive to read it broadly. That’s why careful drafters spell it out: “train, fine-tune, or otherwise improve.” The promise also says nothing about the recipe book: where your supplied materials are stored, who can access them, and whether they are returned to you at the end of the contract. And it says nothing about the records kept while she cooks in your kitchen: the orders, your feedback, what’s sent back, what your kitchen struggles with. The chef doesn’t learn merely by serving dinner, but the vendor who staffed your kitchen can learn a great deal from those records, without ever training anything on them.
The same goes for the other comforting promise, “we’ll delete your data when the contract ends.” If your data was used for fine-tuning and the vendor keeps the tuned model, deleting the files only removes them; it doesn’t remove what the model learned from them. You can take back the recipes. You cannot reliably make the chef forget what she learned.
To be clear, this is not a story about vendors tricking anyone. It’s about a literacy imbalance. The vendor understands the chef’s entire career, and most buyers only ever see dinner service, yet given how much depends on understanding what you are agreeing to, both parties should come to the table with a roughly equivalent understanding. Without that basic literacy, you don’t know what you’re buying, what the risks are, or what your protections cover, and that’s true whether you’re a government agency or a company.
The harder problem: what she learned
The different parts of the chef behave differently, which is exactly why the vocabulary matters. The materials you supplied, the recipe book and the instructions, can often be segregated, inspected, and returned if the system is built that way and your contract requires it. The things she learned, the schooling and the apprenticeship, are embedded in the chef herself: hard to inspect, and difficult (though not impossible) to unwind. And once that learning happens, “give it back” is essentially off the menu.
You can take back the recipes. You cannot reliably make the chef forget what she learned.
That raises a set of questions that get complicated fast. Who has rights to the customization—the version of the chef built for you—and does the vendor keep the underlying chef it arrived with? What is the vendor allowed to do with that custom chef, and with what she learned, after your contract ends? Can it send her across the street to cook your signature dishes for your competitor? Restricting use and claiming ownership are different legal tools, and they raise different problems. These are not hypothetical questions: GSA’s revised draft AI clause is wrestling with all of them right now (I analyzed the earlier draft in Lawfare). I will address those issues in a forthcoming piece. The point is simpler: you cannot even ask these questions unless you know which part of the chef your contract is pointed at. And if you can’t ask them, you don’t know whether the protection you negotiated is real.
Learn the cake. Learn the chef
The wedding cake and the chef do different jobs, and you need both. The cake helps you understand what you’re buying. The chef helps you understand how it works. That’s why I begin every AI procurement training with the same advice: learn the cake and learn the chef. If you don’t, you have no idea what you’re negotiating or what you’ve already agreed to in your contracts.
[1] Yes, I know that technically a “chef” doesn’t cook the dinner, but just go with it (please).