From Managed Service to Platform Dependency: How Proprietary Telecom AI Models Change Your Vendor Risk

Three entanglement points, and why each one compounds over time

The mechanism worth understanding isn’t contractual lock-in in the traditional sense — it’s architectural and operational entanglement, and it shows up differently across this year’s three proprietary AI moves.

AT&T’s OTel 2.0 ships with an AI Gateway that routes requests by cache-aware logic across models, tuned to the operator’s own traffic patterns and cost curve, and credited with cutting inference spend by up to 90 percent. That routing logic is exactly the kind of infrastructure a customer’s own workflows get built around over time — not because anyone designs it that way deliberately, but because once an integration is tuned to a specific gateway’s caching and routing behaviour, migrating away means re-architecting the integration, not swapping an API endpoint. The deeper a workflow is optimised around one gateway’s cost curve, the more expensive it becomes to leave, and that cost accumulates silently in engineering time rather than showing up as a line item anyone reviews.

SK Telecom‘s A.X K2 entangles differently. A model built specifically for Korean-language and scientific reasoning becomes embedded in customer-facing workflows in a way that’s harder to unwind than a general-purpose model swap, because the switching cost isn’t purely technical — it’s linguistic and cultural. A replacement model has to match not just capability benchmarks but the specific reasoning conventions and cultural fluency the original was built around, and that’s a much higher bar to clear in a competitive evaluation than a straightforward feature comparison.

The consumer AI bundling trend entangles a third way: expectation, not infrastructure. Once employees or customers become accustomed to a ChatGPT or Gemini subscription arriving as part of a mobile plan, unwinding that bundling — whether because the operator relationship changes or the underlying deal shifts — means disrupting a user experience people have come to expect as a default, which carries its own organisational friction even when no technical migration is required at all.

The AT&T–D-Wave pattern: dependency deepening through everyday integration

A separate development this year illustrates the same dynamic outside the AI model layer specifically, and it’s worth including here because it shows the pattern isn’t unique to language models. AT&T expanded its partnership with D-Wave to scale quantum annealing across network operations and embed it into agentic AI workflows, with pilot benchmarks reportedly cutting a key optimisation workload from roughly an hour to under 15 seconds, targeting outage response, field technician routing, and traffic and capacity management. That expansion — from a bounded optimisation pilot to embedding across multiple operational workflows — is the entanglement mechanism in miniature. Each additional workflow that comes to depend on a specific optimisation engine’s output makes the underlying technology harder to replace, not because of a contract clause, but because more of daily operations has been built assuming that engine’s behaviour and performance characteristics.

Nokia‘s lifecycle framework: governance for the dependency, not an escape from it

Nokia‘s response this year — a framework for governed AI model lifecycle operations and monetisation across telecom networks — is a useful development, but it’s worth being precise about what it actually solves. A lifecycle governance framework helps an operator or enterprise manage which models are running, how they’re versioned, and how their usage is monetised across a network. It doesn’t, on its own, reduce the underlying dependency on whichever models and infrastructure sit beneath that governance layer. If anything, a mature governance framework can make a proprietary model’s continued use feel more, not less, embedded — because now there’s a formal lifecycle process built around managing it, which is itself another layer of process an enterprise would need to unwind on the way out.

The roadmap capture question worth asking directly

The clearest practical risk sitting underneath all three entanglement points is roadmap capture: once an enterprise’s workflows depend on a proprietary model’s gateway, language capability, or bundled distribution, the pace and direction of that model’s development — what gets prioritised, what gets deprecated, how pricing evolves — is set by the operator’s own commercial interests, not by the enterprise depending on it. That’s a manageable risk if it’s evaluated openly at the point of adoption. It becomes a much harder problem to manage retroactively, after two or three years of integration have made the practical cost of leaving higher than the cost of tolerating a roadmap that no longer serves your priorities.

Structuring for optionality before entanglement sets in

• Architectural abstraction: Build an abstraction layer between your workflows and any operator-specific AI gateway or routing logic, so a future migration touches one integration point rather than every workflow that currently calls it directly.
• Portability clauses: Negotiate explicit data and configuration portability terms at the point of adoption, not after the relationship is already load-bearing — including how customer-facing language or reasoning customisation would transfer to a replacement model if needed.
• Roadmap alignment reviews: Schedule periodic reviews of whether the vendor’s model roadmap still matches your priorities, treating any growing divergence as an early signal rather than something to address only once it becomes operationally painful.
• Exit terms upfront: Negotiate sunset and exit terms as part of the original agreement, including a defined transition period and support commitment, rather than leaving exit terms to be negotiated under pressure once a dependency is already deep.

None of this argues against adopting AT&T’s, SK Telecom’s, or any other operator’s proprietary AI capability — the performance and cost gains on offer are genuine, and this series has covered why they matter. It argues for treating “managed service” as a starting classification rather than a permanent one, and building the architecture and contract terms now that keep the relationship a managed service in practice, not just in name, three years into the integration.