Foundations & Models
Proprietary Model
Access only through the provider's interface: you send data out, get answers back and pay per use. In return you usually get the strongest models and the least operating effort. The flip side is loss of control — over prices, model changes and the question of what happens to your own data. Contracts and exit paths therefore belong to the architecture.
An example
A mid-sized company builds its quoting process on a cloud model. After eight months the provider retires the model version in use; the successor version phrases things differently, and the carefully tuned instructions suddenly produce different results. None of this is a breach of contract — model versions have life cycles like software. It is just that nobody had expected an update to change behavior without a single line of their own code moving.
A closer look
Access runs through the provider's interface. Versioning, availability, price and behavior are thus outside your own control. A model change on the provider's side can alter results without anything having been changed in your own code.
Why it matters
The decisive difference from classic supply: you are not buying a specification but a behavior that is allowed to change. Anyone using proprietary models in production therefore needs three things in the contract and in operation — a commitment on lead time for deprecations, the ability to pin a model version, and a test suite of their own that runs after every change. Without the third, you notice a change in behavior only when a customer complains.
Commonly misunderstood
Lock-in rarely arises through the model but through everything around it: prompts, tool integration, evaluations. Anyone who wants to keep switching open has to build this layer so that it is interchangeable.