Foundation Model

A single model, trained once at enormous cost, now powers hundreds of downstream applications across banking, insurance, and capital markets. Foundation models are the base layer of modern AI, but deploying one inside a regulated institution means answering questions about provenance, validation, and accountability that the model's creators never had to consider.

What is a foundation model?

A foundation model is a large AI model trained on broad data that can be adapted to many tasks without being retrained from scratch. GPT-4, Claude, Gemini, and Llama are foundation models. So are domain-specific models trained on medical literature, legal documents, or financial filings. The defining characteristic is generality: one model serves as the starting point for many applications.

This is a departure from the traditional approach in financial services, where each business problem gets its own purpose-built model. A credit scoring model is trained on credit data. A fraud model is trained on transaction data. A foundation model is trained on everything available, then steered toward specific tasks through prompting, fine-tuning, or retrieval augmentation.

The economic logic is compelling. Training a foundation model from scratch costs tens of millions of pounds. Adapting an existing foundation model to a specific task can cost thousands. This ratio explains why most financial institutions will use foundation models rather than build them. The strategic question is which ones, from which providers, under what terms.

The landscape

The EU AI Act creates a distinct regulatory category for general-purpose AI models, which includes all foundation models offered to third parties. Providers must document training processes, evaluate capabilities and limitations, and implement risk mitigation. Models above a computational threshold (10^25 FLOPs) face additional systemic risk obligations, including adversarial testing and incident reporting.

The concentration risk is real. Four or five foundation model providers supply the base technology for most enterprise AI applications. If a model provider changes its terms, increases its prices, or suffers a security breach, every downstream application is affected. The PRA has flagged this as a systemic risk analogous to cloud concentration, and firms should expect supervisory attention to their foundation model dependencies.

Open-weight models (Llama, Mistral, Qwen) offer an alternative. They can be hosted on private infrastructure, modified, and inspected. For institutions handling sensitive data, this reduces third-party risk. But open-weight does not mean zero cost. Running a 70-billion-parameter model requires specialist GPU infrastructure. The total cost of ownership for self-hosted models often exceeds API costs at moderate volumes.

How AI changes this

Foundation models collapse the timeline from business need to working prototype. A compliance team that wants to summarise enforcement notices, a claims team that needs to extract damage descriptions from adjuster reports, or an operations team automating email triage can each build a working prototype in days, not months. The model already understands language. The team only needs to provide context and constraints.

Retrieval-augmented generation is the primary adaptation pattern. Rather than fine-tuning the model (expensive, slow, requires ML expertise), you connect it to your own data sources and let it retrieve relevant context before generating a response. This is how most financial services applications use foundation models today: the model provides language capability, the organisation provides domain knowledge.

Multi-modal foundation models (those that process text, images, and structured data) are beginning to address document intelligence tasks that previously required specialised pipelines. A single model that can read a scanned contract, extract the key terms, and summarise them in plain English replaces a chain of OCR, NER, and summarisation components.

What to know before you start

Model risk management applies. The PRA's SS1/23 does not distinguish between a bespoke model and a foundation model. If the model informs a material business decision, it falls within scope. You need to validate the model's performance on your specific tasks, not rely on the provider's published benchmarks. Their evaluation dataset is not your data.

Vendor lock-in is the strategic risk. Building twenty applications on one provider's model creates a dependency that is expensive to unwind. Design your application layer to be model-agnostic where possible. Abstract the model behind an internal API. Test with multiple providers. The switching cost for a well-abstracted application is weeks. For a tightly coupled one, it can be months.

Evaluate total cost of ownership honestly. API pricing is per token, and token counts grow quickly when you process long documents. A process automation pipeline that sends 50-page reports to a foundation model API will cost materially more per document than a purpose-built extraction model. Use foundation models where their generality creates value. Use specialised models where cost and latency matter.

Start by mapping your current AI and automation estate. Identify which existing components a foundation model could replace, which it could augment, and which are better left alone. The answer is rarely "everything." A targeted deployment that replaces three brittle NLP pipelines with one foundation model is more valuable than a blanket strategy that puts a language model behind every internal tool.