Here's an uncomfortable compliment: if AI is working in your business, your business is becoming dependent on it. Processes reshape around it; people stop doing things the old way. That's not a governance failure — it's success. But it is a dependency, and dependencies get managed.
The real question
The dependency already exists — most organisations just haven't written it down. In one survey of enterprise leaders, 81% were concerned about AI vendor dependency, only 6% could switch providers without material disruption, and 47% said a key business function would stop in a provider outage. Boards have noticed: the question is no longer "should we use AI?" but "what happens if our provider raises prices, degrades a model, or goes down?" If the honest answer is a shrug, the risk isn't the AI — it's the unmanaged dependency.
How to do it
Start with optionality. Never architect around a single provider. Run the models your organisation chooses — direct API keys, a cloud provider's model service, or the subscriptions you already pay for — and make switching a settings change, not a migration project.
Then make the dependency visible. Instrument AI like any other critical system: usage, cost and logs per model, key, integration and endpoint, plus a self-service usage page for everyone. Concentration risk becomes a report instead of a debate: which functions lean on which models, and what that costs.
Finally, put human gates on consequential actions. AI drafts the outbound work, but a person reviews, edits and approves it before anything sends. That's what keeps dependency from quietly becoming autonomy.
What this looks like
In Pebble, this looks like: administrators enable models from more than one provider — API keys alongside the subscriptions the business already pays for. When a provider has a bad week, people switch models mid-conversation and keep the thread. PebbleObserve shows usage, cost and logs per model, key, MCP server and endpoint — so the quarterly risk report states where AI is load-bearing and what it costs. When AI drafts a customer email, the account manager reviews, edits and approves it in chat, and it sends from their own Microsoft 365 mailbox with an AI-disclosure footer. The dependency is real — and it's governed.
Why this holds up in a regulated business
- Organisations run the models they choose — API keys, AWS Bedrock, or centrally managed subscriptions — and switch models mid-conversation without losing the thread.
- Admins manage which models are enabled and provisioned per organisation and workspace; routing strategy is admin-set, service-wide.
- Usage, cost and logs per model, key, MCP server and endpoint, with a self-service usage page for every user; costs derive from configured pricing.
- Outbound email sends through the user's connected Microsoft 365 mailbox only after the user approves it, with the AI-disclosure footer preserved.
- Deployed across US, Europe and Australia.
One honest limit: provider switching is deliberate, not automatic failover; observability covers model activity; spend is visible, not hard-capped.
Where to start
Take one question into your next risk review: if our AI provider degraded tomorrow, what stops — and how would we know? Then make the answer boring: a second provider enabled, the usage dashboard on the agenda, a person approving outbound work. You don't choose whether the business depends on AI; you choose the shape of the dependency. Depend on AI on your own terms.
Pebble Powered AI.
