Banks Are Buying AI With Contracts Written for 2015

Banks are buying one of the fastest-changing technologies in the market with procurement templates built for conventional software.

The template asks about uptime, hosting, support, data protection, and price increases. Those questions matter, but they assume a stable service performing a defined function.

An AI service may depend on a foundation model, cloud platform, retrieval layer, bank data, vendor prompts, and subcontractors. Any one can change. The same system can draft a note today and influence a customer decision tomorrow.

That is why the old contract can be legally complete and operationally weak.

My thesis is simple: an AI contract is not only a mechanism for transferring risk. It is part of the production control system. If it does not define how the service will be tested, changed, monitored, challenged, and replaced, it does not govern the technology the bank is actually buying.

“2015” is shorthand for a software-as-a-service mindset that treats technology as a fixed object. AI is a continuing operating relationship.

The dependency is growing faster than the contract

The issue is already material. In the Bank of England and FCA's 2024 survey, 75% of responding financial firms said they were using AI. One-third of reported AI use cases were third-party implementations, up from 17% in the 2022 survey. The three most-used model providers accounted for 44% of reported third-party model providers.

These are survey results, not a market census. They still show rising external use and a concentrated supply chain. Some 46% of respondents reported only a partial understanding of the AI they used; 34% reported complete understanding.

Procurement cannot eliminate that dependency. It can make the dependency visible and manageable.

The US banking agencies' interagency guidance on third-party relationships treats planning, due diligence, contract negotiation, monitoring, and termination as one lifecycle. It also makes a basic point: using a third party does not remove the bank's responsibility for compliant operations.

In Europe, DORA Article 30 requires financial entities' ICT contracts to address matters including service descriptions, subcontracting, data locations, access and recovery, service levels, audit rights, incident assistance, termination, and exit planning. That is much closer to an operating model than a traditional purchase order.

The regulatory message is consistent: signing the contract is not the end of oversight. It is the start.

Where the standard template breaks

The first weakness is the service-level agreement.

An AI endpoint can be available 99.9% of the time and still be useless. It may produce unsupported answers, omit material facts, behave differently across customer groups, or fail on the documents that matter most. Uptime measures whether the service responds. It does not measure whether the response is dependable enough for the use case.

The second weakness is change control.

Traditional contracts often let the supplier modify a product if the overall service is not materially reduced. But a model change can alter accuracy, latency, refusal behavior, explainability, or cost. A better public benchmark can still mean a worse bank workflow.

The third weakness is an incomplete view of the supplier.

The application vendor may rely on another company's model and a third company's cloud. If an upstream provider changes terms, retires a model, moves processing, or suffers an incident, a generic subcontractor clause rarely captures the dependency.

The fourth weakness is the exit clause.

Deleting an account is not an exit plan. The bank may need prompts, configurations, evaluation sets, logs, embeddings, workflow rules, and evidence of deletion. Without those assets, replacing the vendor can mean rebuilding the operating process.

The seven-clause AI contract review

I would put every material AI purchase through this seven-part review. Its depth should match the use-case risk; an internal drafting assistant is not a credit or fraud system.

1. Define the decision boundary

State what the system is allowed to do, for whom, with which data, and at what level of autonomy. Separate drafting, recommending, deciding, and executing. Name the decisions that require human approval and the person with authority to stop the system.

This is also where the contract should define prohibited uses. An AI platform is not a scope. A bounded workflow is. That distinction also explains why banks buy AI they never deploy.

2. Contract for change, not just delivery

Define what counts as a material change: a new model, a new upstream provider, a new processing location, a significant prompt or retrieval change, or a change that affects measured performance. Set notice periods, regression-testing rights, approval rules for high-risk changes, and a rollback path.

No bank should discover a production model migration from a release note after it happens.

3. Measure behavior as well as availability

Keep the uptime SLA, then add use-case measures. Depending on the workflow, these may include factual accuracy, source traceability, false-positive and false-negative rates, latency, escalation rates, stability across relevant groups, and the frequency of unsupported outputs.

The measurement method matters as much as the threshold. Define the evaluation set, test frequency, reporting format, failure remedy, and who can challenge the result. This is why human oversight needs an operating design. The NIST Generative AI Profile is voluntary, but its focus on governance, content provenance, pre-deployment testing, and incident disclosure is a useful structure for these terms.

4. Map data and intellectual-property rights

Specify which inputs the vendor may retain, whether bank or customer data can be used for training, how prompts and outputs are handled, where data is processed, and what applies to telemetry and metadata. Define ownership or usage rights for configurations, evaluation materials, fine-tuned components, and generated outputs.

A promise not to train on bank data is not enough. The contract needs definitions, exceptions, retention periods, and obligations that flow down the supply chain.

5. Secure evidence, access, and incident duties

The bank needs enough evidence to oversee the service: test results, model and system documentation, relevant logs, security assurance, known limitations, and timely notice of incidents or material degradation. Audit rights should be workable, not theoretically available under conditions that make them unusable.

For covered high-risk systems, the EU AI Act assigns specific duties across providers and deployers, including human oversight and monitoring by deployers. A contract should make the information and cooperation required for those duties available in practice.

6. Align remedies with failure modes

A service credit is a sensible remedy for downtime. It is a weak remedy for a data breach, an intellectual-property claim, a discriminatory outcome, an unreported model change, or a failure that creates customer remediation work.

Liability, indemnities, insurance, and remediation should reflect the failure type and exposure. The goal is not to push every risk to the vendor. It is to avoid leaving the bank with the consequence while limiting the supplier's exposure to a small portion of fees.

7. Make exit technically possible

Define export formats, transition support, deletion evidence, continuity obligations, and access to the assets needed to move the workflow. Identify critical upstream dependencies and what happens if one becomes unavailable. Test the exit plan before the relationship becomes too important to leave.

Portability is not a procurement preference. In a concentrated market, it is resilience.

Where the market is going

I expect more modular AI contracts. The master agreement will cover the relationship; use-case schedules will set boundaries, thresholds, approved models, data permissions, and control owners. Higher-risk deployments will receive stronger change rights and evidence requirements.

This will also change vendor selection. The strongest suppliers will not be the ones promising that their AI never fails. They will be the ones that can show how failures are detected, reported, contained, and learned from. Evidence will become part of the product.

Banks do not need a 200-page AI addendum for every experiment. They need proportionality, clear ownership, and a repeatable framework. Legal, risk, security, procurement, data, and the business owner should be designing the operating relationship together.

The market will keep moving faster than contract cycles. The answer is not to freeze the technology at signature. It is to contract for controlled change.

The best AI agreement will not predict every new model or risk. It will give the bank the rights, evidence, and decision points required to respond when they arrive.

That is the difference between buying access to AI and being able to operate it.