A business buys a chat interface, an API subscription, or a feature bolted onto software it already owns, and calls all three “the AI.” Underneath every one of them sits something narrower and more specific: a model — a large file of learned numerical parameters that was produced once, in a training run, and does not change between the questions you ask it. The app is a wrapper built around that file. Confusing the two is the source of a surprising share of AI buying mistakes.
Key takeaways
Say “ChatGPT,” “Copilot” or “our AI assistant” and you are naming a product: a piece of software with a login screen, a chat window, a memory of what you said five minutes ago, and rules about what it will and will not do. Underneath that product sits a model: the actual trained system that turns your text into a response. The model has no login screen and no memory of its own between separate requests — on its own it is closer to a very large lookup engine than to an application. Everything you experience as “the personality” or “the features” of a chatbot is mostly product-layer work sitting on top of the model, not the model itself.
Innovation, Science and Economic Development Canada's Voluntary Code of Conduct on generative AI splits obligations between two roles for exactly this reason. A developer's work is “methodology selection, collection and processing of datasets, model building, and testing” — producing the model itself. A manager's work is “putting a system into operation, controlling the parameters of its operation, controlling access, and monitoring its operation” — running the product built on top of it. (ISED, Voluntary Code of Conduct, footnotes 1 and 2) A business can be a manager without ever touching a model directly — which describes most companies buying an AI feature today: they are managing a product, not building a model.
The clearest evidence that model and wrapper are genuinely different assets, not just a technical nuance, comes from how businesses that trade in AI companies value them. Deavo's own editorial guidance on AI business sales puts it bluntly: “Buyers price proprietary data and a defensible model far above the wrapper around someone else's API.” (deavo.ai, AI industry guide) A company that built its own model, or holds a genuinely differentiated dataset, is worth more than a company that built a nice interface calling someone else's API — because the second company's entire product could, in principle, be replaced by any competent developer with API access. The interface is real work and real value, but it is not the same kind of asset as the model behind it.
Training a general-purpose model from scratch requires enormous amounts of data, specialized compute infrastructure and research expertise that sit entirely outside what a typical business does. In practice, nearly every company “using AI” is a manager in the ISED sense, not a developer: it licenses access to a model someone else built — through a chat product, an API, or a feature embedded in software it already owns — and controls how that access is used inside its own operations. This is not a lesser way to use AI; it is how almost all commercial AI use actually works, and understanding it reframes a lot of vendor conversations. On the rare occasion a business does commission bespoke AI development rather than licensing an existing model, who actually owns what gets built is a term the parties negotiate, not a default the law hands over automatically. See Treadstone Law's guide to custom software development agreements. A vendor pitching “our proprietary AI” is worth asking a direct question of: did you build the model, or did you build a product around someone else's model? Both are legitimate businesses, but they carry different risk if the underlying model provider changes its terms, its pricing or the model itself, and only one of them controls that risk directly.
A common, confusing experience: a business's AI writing tool suddenly answers differently, or refuses requests it used to handle, with no announcement and no change on the user's end. The usual explanation is not that the model quietly learned something new overnight — a deployed model's parameters are fixed between training runs, and retraining a large model is a deliberate, resource-intensive project, not a background process. The far more common explanation is that the vendor swapped which model sits behind the product, adjusted the product-layer instructions wrapped around every request, or changed a safety filter in the wrapper. From the user's chair these look identical — “the AI changed” — but only one of them is actually a change to the model, and knowing which one happened changes whether raising it with a vendor or simply adjusting your own prompts is the right response.
Related: what artificial intelligence actually means, what happens when you send a prompt, and, on the question of building on top of a model versus buying a finished product, the custom AI solutions hub.
There was nothing to forget in the model itself. Any sense that a tool “remembers” you comes from the product layer storing your conversation history and feeding relevant parts of it back into future requests — the underlying model has no memory of you between separate uses unless the product is explicitly built to supply that context.
Yes, and it happens routinely. A vendor can license access to a general-purpose model and build its own interface, business rules and data handling around it. Two products that feel completely different to use can share the same underlying model, and two versions of the same product can quietly swap which model answers your request.
No — fine-tuning is a separate, deliberate training step done on a copy of a model using a chosen dataset, not something that happens automatically as you use a product. Canada's Cyber Centre guidance recommends organizations “continuously fine-tune or retrain the AI system with appropriate external feedback” as a mitigation practice, which is itself evidence that this is a planned action a vendor takes, not a background effect of ordinary use. (Cyber Centre, ITSAP.00.041)
Often yes, for the same reason it is worth knowing which engine is under a car's hood. If a vendor cannot or will not answer, that is itself useful information about how much of the product is their own work versus a thin layer over someone else's model, and it affects how exposed you are if that underlying model changes.
This is one page in a plain-English series on how AI actually works and where it fits in a Canadian business.
