The COO's Guide to AI Vendor Selection in Regulated Industries

Every COO in a regulated industry will face this decision within the next 18 months: which AI vendors do we select, on what terms, and how do we govern them once they are embedded in our operations? The decision is consequential because AI vendors, unlike traditional technology vendors, become part of your decision-making infrastructure. A vendor whose model scores your credit applications or triages your insurance claims is not providing a tool; it is participating in your regulated activity.

This post is the practical procurement guide. It covers the regulatory framework (principally DORA for financial services, but with parallels for healthcare and energy), the build-vs-buy decision matrix, the vendor lock-in risks that most procurement teams underestimate, and the contractual provisions that actually matter when things go wrong.

We write this because vendor selection is one of the most common topics in our AI enablement scoping conversations, and the mistakes we see are consistently the same.

The regulatory frame: DORA and beyond

DORA third-party risk requirements

The Digital Operational Resilience Act (DORA) applies to all EU financial entities and their critical ICT third-party providers from January 2025. For AI vendors, DORA imposes specific obligations:

Register of ICT third-party arrangements. Every financial entity must maintain a complete register of all ICT third-party service providers, including AI vendors. The register must document the nature of the service, the criticality assessment, the contractual terms, and the exit strategy. If your AI vendor is not in this register, you are already non-compliant.

Concentration risk assessment. DORA requires firms to assess concentration risk in their ICT third-party arrangements. If three of your five critical AI use cases depend on the same vendor (or the same underlying foundation model provider), that is a concentration risk that must be assessed, documented, and mitigated. The EBA guidelines on ICT third-party risk provide the detailed framework.

Exit strategy requirements. Every critical ICT third-party arrangement must have a documented exit strategy executable without disruption. For AI vendors, you must be able to replace the vendor's model with an alternative within a defined timeframe. If the vendor's proprietary format or architecture makes this impossible, you have a DORA compliance gap.

Incident reporting. AI vendor service failures must be reported through the DORA incident reporting framework, meaning your operational resilience monitoring must cover AI vendor performance, not just infrastructure availability.

For a deeper treatment of DORA compliance in the context of AI, see our dedicated post on the topic.

Beyond DORA

DORA is the most prescriptive framework, but it is not the only one. The FCA's outsourcing and third-party risk guidance applies to all UK-regulated firms and imposes similar requirements on vendor governance, concentration risk, and exit planning. The EU AI Act's high-risk provisions add a layer of AI-specific obligations (conformity assessment, transparency, human oversight) that apply regardless of whether the AI capability is built in-house or procured from a vendor.

The common thread across all regimes: the regulator holds you, the regulated entity, accountable for the AI system's behaviour, regardless of whether you built it or bought it. Vendor selection is not a procurement decision; it is a regulatory compliance decision.

The build-vs-buy decision matrix

The build-vs-buy decision for AI in regulated industries is more nuanced than for traditional software. The matrix below captures the dimensions that matter.

When to build

Build when: the AI capability is core to your competitive differentiation, the data is proprietary and sensitive, the regulatory requirements demand full auditability of the model, or the use case requires deep integration with your existing workflows and data layer.

Concrete examples: credit scoring models where the training data is your proprietary portfolio data, claims triage models that are integrated into your end-to-end claims workflow, and transaction monitoring models that learn from your investigators' disposition decisions (the data flywheel mechanism).

Building gives you full control over the model, the data, and the governance framework, plus the compounding advantage: models trained on your specific data get better over time in ways that a vendor's generic model cannot. The cost: building requires internal ML engineering capability, MLOps infrastructure, and model risk management capacity. Reserve the build decision for use cases where the competitive or regulatory case is clear.

When to buy

Buy when: the AI capability is a commodity (document processing, speech-to-text, standard NLP), the vendor's model is trained on a dataset you cannot replicate, the speed-to-deployment matters more than long-term differentiation, or the use case is non-core to your regulated activity.

Concrete examples: intelligent document processing for onboarding, email classification for customer service routing, translation services, and general-purpose search and summarisation.

Buying gives you speed and access to capabilities you could not build in a reasonable timeframe. The cost: dependency on the vendor, limited ability to customise, and the governance burden of managing a third-party AI system under your regulatory framework.

When to partner

The third option, often overlooked, is a partnership model where the vendor provides the platform and the foundation model, but you provide the data and the fine-tuning. This is the pattern that works for use cases where the base capability is commodity but the domain-specific performance requires your proprietary data.

The partnership model requires careful contractual structuring. The key questions: who owns the fine-tuned model? Who owns the data used for fine-tuning? Can the vendor use your data to improve their general model (this is usually unacceptable in regulated industries)? What happens to the fine-tuned model if the relationship ends?

Vendor lock-in: the risks most procurement teams miss

Vendor lock-in in AI is structurally different from traditional software lock-in. Beyond the usual proprietary formats and API dependencies, AI introduces three additional sources:

Model dependency. If your workflows are designed around a specific vendor's model outputs (confidence scores, classification taxonomy, latency profile), switching requires redesigning the workflow, not just the integration. This is why the AI enablement approach insists on designing workflows around the capability rather than the specific vendor's implementation.

Data dependency. If you have been fine-tuning the vendor's model with your proprietary data, switching means retraining from scratch or negotiating portability. Most vendor contracts do not address this.

Feedback loop dependency. If the vendor's model is learning from your production data, the accumulated learning is embedded in the vendor's model. Walking away means starting the flywheel from zero. This is the most insidious form of lock-in because it strengthens over time.

The mitigation strategy has three components:

1. Architectural abstraction. Design your workflows and data layer so that the AI vendor's model is accessed through a standard interface (an internal API gateway) that can be pointed at a different provider without changing the upstream workflow. This is part of the action-data layer architecture.

2. Data sovereignty. Ensure that all training data, fine-tuning data, and production feedback data remains in your infrastructure, with the vendor accessing it under your terms. The contract must specify that the vendor cannot use your data to improve their general-purpose model.

3. Exit rehearsal. DORA requires an exit strategy. Go further: rehearse the exit. Run your top three AI use cases against an alternative provider or an in-house model annually, and measure the performance gap. If the gap is growing, your lock-in is increasing.

The contractual provisions that matter

Most AI vendor contracts are adapted from standard SaaS agreements. They are missing the provisions that matter for regulated industries. Here are the nine provisions that every regulated firm should negotiate:

1. Model version control and notification. The vendor must notify you before deploying a new model version to your environment, with sufficient lead time for your model risk team to assess the change. Silent model updates are unacceptable under PRA SS1/23 and DORA.

2. Explainability requirements. The contract must specify the level of explainability the vendor's model provides, and the vendor must warrant that this level of explainability is maintained across model versions. Regulatory expectations under the EU AI Act require explainability for high-risk AI systems.

3. Performance SLAs with regulatory teeth. Standard uptime SLAs are insufficient. The contract must include model performance SLAs (accuracy, precision, recall, latency) with remediation obligations and, for critical use cases, the right to revert to the previous model version or a manual fallback.

4. Data ownership and portability. All data you provide to the vendor (training data, fine-tuning data, production data, feedback data) remains your property. The vendor must provide data export in a standard format on request and on contract termination.

5. Audit rights. You (and your regulator) must have the right to audit the vendor's AI development process, training data provenance, model validation procedures, and security controls. DORA makes this mandatory for critical ICT providers.

6. Subprocessor transparency. If the vendor uses a foundation model from a third party (OpenAI, Anthropic, Google, etc.), that subprocessor relationship must be disclosed, and the subprocessor's data handling must meet your regulatory requirements.

7. Concentration risk disclosure. The vendor must disclose any concentration risk in its own supply chain (single-cloud dependency, single-foundation-model dependency) that could affect service continuity.

8. Exit assistance. The contract must include a defined exit assistance period during which the vendor supports the transition to an alternative provider or an in-house solution, including data export, model documentation, and knowledge transfer.

9. Regulatory co-operation. The vendor must agree to co-operate with your regulator on request, including providing information, attending meetings, and submitting to regulatory audits. DORA makes this mandatory for critical ICT providers, and Gartner's research on AI vendor governance recommends it for all AI vendor relationships.

The evaluation framework

When comparing vendors, weight the evaluation towards operational and regulatory factors, not just technical performance. The framework we use in AI enablement engagements has five dimensions: technical performance (20%), regulatory alignment (25%), operational integration (20%), lock-in risk (20%), and commercial terms (15%). The weighting reflects a consistent finding: most shortlisted vendors meet the technical bar, so the differentiators are regulatory fluency, integration complexity, and long-term dependency risk.

Common mistakes

Selecting on demo performance. The vendor's demo uses clean data and cherry-picked examples. Always run a proof-of-concept on your own data before committing.

Ignoring the governance cost. The vendor's licence fee is typically 20-30% of the total cost. The remaining 70-80% is integration, governance, model risk management, and ongoing vendor management. Evaluating on licence fee alone systematically selects vendors that are cheap to buy but expensive to operate.

Treating AI vendors like SaaS vendors. A SaaS vendor provides a tool. An AI vendor provides a decision-making participant. Your vendor management framework needs an AI-specific tier.

Not involving the risk function. Involve second-line risk from the vendor shortlisting stage, not the contract signing stage. Procurement decisions made without risk input produce compliance gaps that surface after the contract is signed.

Getting started

If you are about to start an AI vendor selection process in a regulated industry, three actions will improve the outcome:

1. Run the AI Enablement Maturity Diagnostic. This tells you which AI capabilities you should build (where you are mature enough to develop in-house) and which you should buy (where you need vendor capability to reach the target state). The diagnostic prevents the common mistake of buying capability you should build and building capability you should buy.

2. Use the AI Enablement ROI Calculator to model total cost of ownership. The calculator includes governance and integration costs, not just licence fees. It also models the lock-in risk over a 5-year horizon so you can see the long-term cost of vendor dependency.

3. Engage your risk function early. The DORA register, the concentration risk assessment, and the exit strategy are regulatory requirements, not optional extras. Building them into the vendor selection process from the start is cheaper than retrofitting them after the contract is signed.

For firms that want a structured vendor evaluation, our AI enablement diagnostic includes a vendor landscape assessment as part of the AI portfolio audit.