What architectural capabilities and contractual conditions are required to…

Research Question

What architectural capabilities and contractual conditions are required for an enterprise to maintain multi-platform portability and mitigate Artificial Intelligence (AI) vendor lock-in risk from: Microsoft ecosystem concentration (Microsoft 365, Azure AI Foundry, GitHub Copilot, Copilot Studio), Amazon Web Services (AWS) Bedrock dependency, contractual constraints (model usage terms, data residency clauses, exit provisions), and data gravity (accumulated embeddings, fine-tuned weights, and proprietary index formats that are costly to migrate), and how should these be incorporated into an enterprise AI capability model?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

For enterprise AI workloads where acceptable substitute models exist, portability depends more on keeping state, policy, and evidence outside vendor-exclusive surfaces than on merely abstracting model calls.

Amazon Bedrock reduces direct dependence on any one model vendor, but it does not remove dependence on AWS-native identity, networking, routing, and contractual surfaces.

Microsoft ecosystem concentration becomes most material when Microsoft 365 grounding, GitHub Copilot policy, and Azure Foundry state management become the system of record for how agents operate.

For regulated financial-services firms, the controlling legal test is credible exit readiness and concentration-risk management for critical services, so the right target is tiered portability with tested exit runbooks, not universal dual-vendor operation for every use case.

Key Findings

1. The decisive portability boundary is ownership of state and operating evidence, because model calls are comparatively easy to reroute while retrieval indexes, conversation history, policy bindings, and audit records are expensive to reconstruct after a platform move.
2. Amazon Bedrock materially reduces dependence on a single model provider, but it does not make an enterprise platform-agnostic because model access, security controls, private connectivity, inference routing, and geography rules remain AWS-specific.
3. Microsoft ecosystem lock-in is strongest when Microsoft 365, GitHub Copilot, and Azure Foundry become the enterprise system of record for governance and runtime evidence, because leaving the vendor then means rebuilding the control plane rather than only replacing a model endpoint.
4. Open standards and abstraction frameworks, including MCP, LangChain, LlamaIndex, DSPy, and LiteLLM, lower interface-switching cost, but an enterprise still has to normalize identity, residency, audit, approval, and retention semantics with an additional control layer above those abstractions.
5. Public vendor documents are strong on content ownership, isolation, and deletion rights, but they are weak on migration assistance and export guarantees, so contracts must explicitly require transition support, exportable artefacts, change notice, and deletion evidence.
6. For regulated financial-services workloads, the primary documented requirement is a realistically executable exit strategy for critical services and concentrated vendors, and the cited regulatory texts do not prescribe universal multi-vendor deployment for every Artificial Intelligence (AI) workload.
7. For workloads where acceptable substitute models exist, the cheapest robust portability pattern is to keep raw corpora, ingestion logic, evaluation datasets, approval evidence, and telemetry in customer-controlled systems while treating provider-managed threads and vector stores as replaceable execution conveniences.
8. Portability premium is economically justified when the workload is customer-impacting, regulated, high-spend, or tied to concentrated vendor dependency, and is usually not justified for low-criticality internal use cases that can tolerate a planned single-vendor exit path.
9. The enterprise Artificial Intelligence (AI) capability model should add explicit portability capabilities for standards-based interfaces, customer-owned state, cross-provider telemetry export, contractual exit governance, and periodic portability drills for critical workloads.

Assumptions

• The enterprise can keep authoritative raw corpora outside provider-managed retrieval features, which is what makes derived embeddings and indexes regenerable rather than authoritative state.
• Acceptable substitute models exist across more than one provider for the workload being protected, because interface portability only has operational value when the enterprise can tolerate functional substitution at migration time.

Analysis

The evidence weighs most strongly toward a layered answer because vendor documents consistently separate model access from surrounding policy, storage, and monitoring services.

That makes the main design decision architectural rather than purely procurement-led: preserve independent ownership of identity, policy, evidence, and raw data, then treat model providers as replaceable execution dependencies where practical.

Adding staff to maintain separate bespoke integrations for each vendor can reduce immediate migration pressure, but it does not satisfy the regulatory requirement for explicit exit strategies, access rights, and concentration-risk management on critical outsourced services.

Relying on stronger model-quality gates alone is also insufficient, because quality gating does not export audit history, recreate policy lineage, or remove concentration exposure if the governed service still depends on one vendor-admin surface.

Vendor-unique model capability can still be the primary lock-in vector when acceptable substitutes do not exist, which means portability efforts should focus first on workloads whose quality bar can be met by more than one provider.

The strongest practical pattern is therefore selective portability: build the portable rail for critical services, use single-vendor convenience for low-criticality internal uses, and keep both categories under a common control-plane and evidence architecture so the enterprise can escalate a workload into the portable tier when its risk profile changes.

The contract package follows the same logic: public ownership and deletion language is necessary, but it does not prove exit readiness unless it is paired with artefact export, transition assistance, notice of model-term changes, and evidence that the vendor will support a controlled migration window.

Risks, Gaps, and Uncertainties

• Public documents do not provide a comprehensive, vendor-neutral export guarantee for provider-managed fine-tuned weights, policy configuration, or evaluation artefacts, so some migration obligations remain contract-dependent rather than documentation-backed.
• GitHub's public enterprise documents expose policy, audit, and short retention windows, but they do not provide complete public documentation for exporting local prompt-session data or long-term prompt history, so enterprises should assume they must own that evidence path themselves if it matters.

Open Questions

• Which artefacts in modern enterprise AI stacks are hardest to export in practice: prompt lineage, evaluation data, workflow definitions, or provider-managed vector stores?
• What minimum drill frequency would make an Artificial Intelligence (AI) portability runbook credible to regulators without imposing disproportionate cost on low-criticality workloads?
• Which provider-specific capabilities are differentiated enough that an enterprise should consciously accept lock-in rather than pay the portability premium?

sources

• [x] Mitchell (2026) Vendor-agnostic enterprise Artificial Intelligence (AI) capability model: Microsoft Copilot and GitHub families vs AWS Bedrock ecosystem - baseline vendor capability map used to distinguish portability controls from general platform capability.
• [x] Mitchell (2026) Multi-provider AI control planes: capabilities, vendors, and coverage gaps - prior repository synthesis on cross-provider control surfaces and gateway patterns.
• [x] Mitchell (2026) What constraints do vendor platforms impose on governance, and how should enterprises design compensating controls for Artificial Intelligence (AI) and low-code systems? - prior repository synthesis on platform-native governance limits.
• [x] Mitchell (2026) What control-plane architecture is required to manage Artificial Intelligence (AI) agents and low-code systems as distributed, semi-autonomous actors within enterprise environments? - prior repository synthesis on central policy, identity, and observability layers.
• [x] Mitchell (2026) What identity and access management model is required for Artificial Intelligence (AI) agents and low-code artefacts operating within enterprise systems? - prior repository synthesis on machine identity, delegation, and attribution.
• [x] Mitchell (2026) Enterprise Artificial Intelligence (AI) capability model for use-case maturity decisions - prior repository capability taxonomy that this item extends with portability-specific controls.
• [x] Mitchell (2026) Enterprise Artificial Intelligence (AI) platform operating models: organisational structure and ownership - prior repository operating-model guidance for shared enterprise platform layers.
• [x] Model Context Protocol Introduction - open protocol reference for portable tool and context interoperability.
• [x] LangChain Overview - framework evidence for multi-provider model integrations.
• [x] LlamaIndex Large Language Model (LLM) modules - framework evidence for a unified Large Language Model (LLM) interface across providers.
• [x] DSPy Documentation - framework evidence for portability across models, inference strategies, and learning algorithms.
• [x] LiteLLM Proxy Quick Start - gateway evidence for OpenAI-compatible routing, budgets, and multi-provider support.
• [x] AWS Documentation Amazon Bedrock overview - Bedrock service scope and model-provider breadth.
• [x] AWS Documentation Data protection in Amazon Bedrock - Bedrock data handling, provider isolation, and security responsibilities.
• [x] AWS Documentation Amazon Bedrock Knowledge Bases - retrieval architecture and supported vector-store choices.
• [x] AWS Documentation Geographic cross-Region inference in Amazon Bedrock - data residency and destination-region requirements.
• [x] AWS Organizations AI services opt-out policies - service-improvement opt-out and deletion behavior for stored improvement copies.
• [x] AWS Service Terms - contractual baseline for Customer Data, Data Processing Addendum (DPA), and post-closure deletion.
• [x] AWS Legal Serverless Third-Party Models on Amazon Bedrock - additional seller terms for third-party models on Bedrock.
• [x] Microsoft Learn Data, privacy, and security for Azure Direct Models in Microsoft Foundry - Azure Direct Model data handling, stateful features, deletion, and geography behavior.
• [x] Microsoft Learn Foundry provisioned throughput - deployment-type flexibility, regional capacity constraints, and redirection behavior.
• [x] GitHub Docs GitHub Copilot policies - enterprise and organization policy controls over Copilot features and models.
• [x] GitHub Docs Metrics data properties for GitHub Copilot - retention window for Copilot activity and authentication data.
• [x] GitHub Docs Copilot audit logs - enterprise audit scope, exclusions, and retention window.
• [x] GitHub Docs Manage GitHub Models at scale - model allowlists, bring-your-own-key support, and preview exceptions.
• [x] OpenAI API guide: Your data - data retention controls and stateful-endpoint behavior used as a comparator for OpenAI-compatible interfaces.
• [x] Financial Conduct Authority (FCA) PS21/3 Building operational resilience - operational resilience, mapping, and third-party obligations for regulated firms.
• [x] European Banking Authority (EBA) Guidelines on outsourcing arrangements - official outsourcing governance page and downloadable final guideline set.
• [x] EBA revised Guidelines on outsourcing arrangements PDF - primary text for exit strategies, termination rights, access rights, and concentration-risk clauses.
• [x] EUR-Lex Regulation (EU) 2024/1689 - official European Union (EU) Artificial Intelligence Act text checked for applicability to portability and data-governance claims.