Gateway basics ยท 2026-09-22
Avoiding vendor lock-in in public-sector AI architecture
Even in an architecture that already secures data residency and provider independence, tying application code tightly to one provider's API shape creates a hidden lock-in; this covers how to avoid it.
Contract-level independence doesn't prevent code-level lock-in
The data residency and provider independence decisions covered in the public-sector AI API architecture article are a high-level decision about which provider to work with. But even with that decision made correctly, if application code is written directly against one provider's proprietary request and response shape, switching providers requires a major rewrite; that means an architecture that looks independent at the contract level can carry hidden lock-in at the code level.
This risk matters especially in public-sector projects, because a procurement process can result in a provider change, or a provider can discontinue a service; a locked-in codebase turns that change into a months-long reintegration project.
Writing against a shared interface
Working through an OpenAI-compatible gateway means application code is written against a shared request/response shape rather than a provider-specific one; when the provider or model changes, the only thing that changes is a configuration value (the model identifier), not business logic code. This approach carries meaningfully lower migration cost than an integration calling one provider's API directly.
Eliminating lock-in entirely is not possible; code using a model's provider-specific capability (a particular tool-calling behavior, for example) stays dependent on that capability to some degree. The goal is not zero lock-in, but reducing a provider change to a limited configuration change rather than a major project.
- Write business logic code against a shared request/response shape, not a provider-specific one.
- Keep the model identifier as a configuration value, not hard-coded.
- Document a provider-specific capability's use as a deliberate dependency when you rely on one.
Write the anti-lock-in criterion into the procurement spec
When drafting a technical spec, stating as an acceptance criterion that the contractor must build the application against a shared interface rather than one provider's proprietary API makes the cost of a future provider change predictable at the contract stage.
Frequently asked questions
Are provider independence and avoiding vendor lock-in the same thing?
No. Provider independence is a decision about which provider to work with; avoiding vendor lock-in is writing the application in a way that preserves that decision at the code level. One is incomplete without the other.
Does using a shared interface mean giving up every provider-specific capability?
No. The shared interface covers core functions (chat, tool calling); if you want to use a provider-specific advanced capability, you can mark it as a deliberate exception and use it.