It is a dependency like any other, with a twist
Using a hosted model means depending on someone else’s availability, pricing, and policy — familiar risks. The twist is that the thing you depend on can change behaviour without changing its version number, which few dependencies do.
1. Keep it behind your own interface
Every call to a provider should go through one internal module. Swapping providers then becomes a contained change rather than a search across the codebase — the same reason a model should be a configuration decision.
2. Detect behaviour change, don’t assume it
Run your evaluation set on a schedule, not only when you change something. A silent upstream change shows up as movement in your own numbers, and without that you learn about it from a customer.
The dependency that worries me isn’t the one that goes down. It’s the one that quietly starts answering differently.
3. Decide what happens when it is unavailable
Every AI feature needs a defined behaviour for provider downtime: queue it, degrade to a simpler path, or tell the user plainly. Deciding in advance is what separates a degraded feature from a lead silently disappearing.
4. Read the terms on your data
What is retained, what may be used for training, where it is processed, and what you can commit to your own customers. That is a contractual question with the same weight as what the system is allowed to see internally.
Don’t over-insure
Abstracting so heavily that you can switch providers instantly usually costs more than the risk it removes, and produces a lowest-common-denominator feature. One interface and a working evaluation set is proportionate for almost everyone.