How AI fits into Bronze/Silver/Gold without breaking lineage, PIT, or SMCR: This article sets out a regulator-defensible approach to integrating AI and LLMs into UK Financial Services data platforms (structurally accurate for 2025/2026). It argues that AI must operate as a governed consumer and orchestrator of a temporal medallion architecture, not a parallel system. By defining four permitted integration patterns, PIT-aware RAG, controlled Bronze embeddings, anonymised fine-tuning, and agentic orchestration, it shows how to preserve lineage, point-in-time truth, and SMCR accountability while enabling practical AI use under PRA/FCA scrutiny.

Executive Summary (TL;DR)

AI and LLMs can be safely integrated into UK Financial Services data platforms only when they operate as governed consumers and orchestrators of a temporal medallion architecture — not as parallel data platforms.

In 2025–2026, UK Financial Services organisations seeking regulator-defensible AI integration generally require:

• SCD2 and temporal truth to remain confined to Bronze, with AI accessing data only via PIT-aware views and slices.
• RAG to operate over Silver and Gold layers, never directly against raw or latest-only data.
• Any embeddings of Bronze data to be time-bounded, explicitly scoped, and lifecycle-controlled.
• Fine-tuning to use anonymised, minimised Silver or Gold data only.
• Agentic systems to orchestrate via governed APIs above the semantic (Platinum) layer, with humans retaining execution and accountability.
• End-to-end lineage from prompt → retrieved context → source rows → output.
• Explicit SMCR accountability for both AI platform integrity and business use.

Architectures that bypass these constraints may work technically, but they will not survive PRA/FCA scrutiny, Consumer Duty reviews, or Section 166 investigations.

Contents

1. Introduction: AI Meets a Temporal, Regulated World

In 2023–2025, most “AI in Financial Services” conversations sounded like vendor theatre: generic diagrams, vague talk about “insights”, and almost no consideration of temporal truth, SMCR accountability, or what happens in a Section 166 review.

By 2025–2026, that stopped being cute.

UK Financial Services organisations have now:

• SCD2 Bronze layers carrying audit-grade temporal truth
• Non-SCD Silver layers serving current-state views
• Gold and Platinum layers adding business logic and semantics
• Increasing regulatory emphasis on Consumer Duty, model risk, and operational resilience
• A Board and Executive who are asking, very plainly: “How do we safely let AI touch this platform without getting fined or breaching SMCR?”

This article is about integration, not hype.
Where AI and LLMs actually belong in a modern FS data platform — and where they absolutely do not.
Throughout this article, AI is treated as a governed consumer and orchestrator of the data platform, not a parallel or bypassing system.

It assumes the rest of the medallion stack is already in place:

• Bronze: SCD2 temporal backbone
• Silver: non-SCD current-state and PIT-derived views
• Gold: business metrics, MI, risk, regulatory outputs
• Platinum: conceptual / semantic model

Our job is to layer AI and LLM capabilities on top of this without breaking:

• lineage
• point-in-time reconstruction
• multi-source precedence
• privacy and data minimisation
• SMCR accountability

2. Why Most “AI + Data Platform” Diagrams Are Dangerous in FS

Open any vendor deck and you’ll see some version of the following:

1. “Unified Data Lakehouse + AI Cloud”
   A big blob labelled Data Lake feeding a big blob labelled AI Services. No mention of effective dates, SCD2, PIT, or regulatory boundaries.
   Hidden problem: there’s no distinction between historical truth and current truth. An LLM trained or prompted on “the lake” cannot explain which state it used, or when.
2. “End-to-End AI Fabric”
   Pretty arrows from “Operational Systems” → “Data Lake” → “AI Models” → “Business Apps”.
   Hidden problem: lineage stops at the data layer. There’s no trace from AI output back through the retrieved context to the Bronze rows and source system records that fed them.
3. “Intelligent Lakehouse with Embedded Copilot”
   A workspace user can “just ask questions” of the data and get answers.
   Hidden problem: standard RAG implementations almost always fetch from today’s reconstructed state, not the state as known on date X, which is fatal for complaints, remediation, AML, or Consumer Duty look-backs.

2.1 FS Reality Check

In regulated Financial Services, these omissions are not cosmetic. They are failure modes:

• A mis-selling remediation where the LLM answers based on corrected attributes rather than what the bank believed at the time of sale.
• An AML investigation where the AI’s narrative can’t be traced back to specific screening events, hits, and overrides.
• A Consumer Duty case where you can’t show which version of the risk score or affordability assessment the LLM used.

Most generic “AI + data platform” diagrams would not survive a serious PRA/FCA review.

We need something different: AI that plugs into a temporal, governed medallion platform rather than bypassing it.

3. Exact Placement of AI in the Medallion Architecture

The starting point is simple:

AI and LLM systems are consumers and orchestrators of the data platform, not parallel data platforms.

Here is the high-level placement:

• Bronze (SCD2, temporal truth)
  • AI should not write here.
  • AI may read via controlled PIT extracts and temporal repair pipelines.
• Silver (current-state & PIT-derived views)
  • Primary source for LLM-readable structured and semi-structured data.
  • Source for RAG corpora (with temporal rules applied).
• Gold (business metrics, MI, risk outputs)
  • Source for aggregated, de-risked signals used in model prompts/fine-tuning.
  • Where you feed AI with post-processed, business-meaningful data, not raw events.
• Platinum (enterprise semantic / conceptual model)
  • Defines vocabulary and meaning used by AI/LLM systems.
  • AI agents sit here when they orchestrate cross-domain tasks (“Customer → Account → Product → Contract”).

3.1 Allowed AI Touchpoints (Conceptually)

1. RAG over Silver/Gold
   • LLM retrieves documents and structured slices from Silver/Gold views.
   • All retrievals are PIT-aware (more in Temporal RAG).
2. Embeddings of Bronze PIT Views
   • For investigation use-cases, you build time-bounded slices of Bronze, then embed that slice only.
   • Vectors are tagged with effective_from / effective_to / as-of timestamp.
3. Fine-tuning on anonymised / minimised Silver or Gold data
   • No raw PII.
   • No full raw transaction streams.
   • Use aggregates, patterns, synthetic or partially masked data.
4. Agentic orchestration above Platinum
   • Agents that orchestrate data platform actions (e.g. “repair PIT view”, “recalculate daily risk snapshot”), always via well-governed APIs and workflows.
   • Agents call into the platform — they do not bypass it.

3.2 Common Misconceptions

• “We’ll just let the LLM read directly from Bronze.”
  No. Bronze is too raw, too dense, too temporal, and too dangerous to expose as-is.
• “We can train on the entire lake and let the model figure it out.”
  In FS, that’s effectively an instruction to create an un-auditable model.
• “If it’s inside our cloud, it’s compliant.”
  Compliance is about how data is used, transformed, and governed — not simply where it is hosted.

4. The Four Permitted Integration Patterns

There are arguably infinite ways to bolt AI onto a data platform. In UK FS, there are four patterns that are both useful and regulator-defensible.

Anything outside these should be treated as exceptional and high-risk.

4.1 Pattern 1 – RAG Over Silver/Gold (The Default)

Use case:

• Internal copilots for analysts, risk teams, operations
• Complaint handlers, remediation analysts, internal policy Q&A

How it works:

1. Silver/Gold views publish PIT-safe, domain-specific tables and documents.
2. These are indexed into a vector store or document index, with metadata:
   • domain (Customer, Account, AML, Complaints)
   • as_of_date / effective window
   • source_system / lineage pointer
   • sensitivity classification
3. The LLM receives a user question, plus retrieved context from Silver/Gold.
4. Outputs are logged with full prompt + context + source metadata.

Why this is safe-ish:

• Silver/Gold are closer to business truth and current/structured views.
• SCD2, precedence, and PIT logic has already been applied in Bronze.
• Data can be filtered, masked, and restricted per domain.

Key constraint:
This remains read-only and contextual. The LLM is not allowed to update Silver/Gold directly.

4.2 Pattern 2 – Embeddings of Bronze PIT Views

Use case:

• Deep investigations
• AML / fraud / conduct risk case narratives
• Historical scenario replay where you want the LLM to “read” the full temporal trace

How it works:

1. You define a PIT slice of Bronze:
   • “All customer + account attributes as known on 2019-06-30”
   • “All AML events for this customer between 2020-01-01 and 2020-12-31”
2. Materialise that slice into a temporary or dedicated investigation table/view.
3. Embed that slice into a vector store, tagging:
   • effective_from, effective_to
   • as_of_date
   • source_system, precedence_rule_version
4. LLM retrieves only within that slice, and you log exactly what was retrieved.

Why this is powerful:

• You treat Bronze as the temporal source of truth, but you never expose it raw.
• PIT logic stays within the platform, not in the LLM layer.
• You can rebuild and re-embed the same slice if challenged by regulators.

Control Note:
Embeddings derived from Bronze PIT slices must have explicit lifecycle controls.
Vectors should expire when underlying data is corrected, superseded, or reprocessed, and must be re-embedded from the revised PIT slice to preserve audit integrity.

4.3 Pattern 3 – Fine-Tuning on Anonymised Silver / Gold

Use case:

• FS-specific copilots (“explain this RWA calculation”)
• Classification models (“categorise complaint type from narrative”)
• Pattern-learning on behaviour, not identity

How it works:

1. Choose narrow, high-value tasks, not generic “know everything” objectives.
2. Extract minimal, anonymised training data from Silver/Gold:
   • remove direct identifiers
   • generalise or bin sensitive fields
   • consider synthetic or aggregated representations
3. Fine-tune an internal model (LLM or SLM) on this curated corpus.
4. Deploy behind strict access controls and monitor outputs.

Constraints:

• No raw SCD2 Bronze; no full transaction logs with identifiers.
• Training sets should be treated as regulated artefacts with lineage and retention policies.

4.4 Pattern 4 – Agentic Orchestration Above Platinum

Use case:

• AI “assistants” that help orchestrate platform actions:
  • propose temporal repairs
  • generate tests
  • suggest schema changes
  • generate MI report templates
• Regulatory automation:
  • draft narrative for ICAAP/ILAAP sections
  • generate control evidence packs

How it works:

• Agents call well-defined APIs that:
  • query PIT views
  • run parameterised SQL
  • trigger pre-existing pipelines
• Agents do not directly write to Bronze/Silver/Gold.
• Every action goes through:
  • logging
  • approval workflow
  • human sign-off for high-risk operations.

Why this sits above Platinum:

• Platinum defines meaning and relationships.
• Agents operate on that conceptual layer, not raw data structures.

Hard Constraint:
Agents must never execute material data changes, regulatory submissions, or control actions without explicit human approval.
Agentic systems may propose, draft, or orchestrate — but accountability and execution remain human responsibilities.

4.5 Do / Do Not: Integration Cheatsheet

Do	Do Not
Use Silver/Gold as primary AI/RAG source	Point LLMs directly at Bronze tables
Use PIT slices for investigation RAG	Let standard RAG fetch from “latest-only” views for historical questions
Fine-tune on anonymised, minimised data	Fine-tune on full customer profiles with identifiers
Log prompt + context + source metadata	Treat AI queries as ephemeral or unlogged
Use agents to orchestrate via APIs + workflows	Let agents directly write SCD2 rows or modify schemas
Treat AI pipelines as regulated components	Treat AI as “just another tool” with no formal controls

5. Lineage Must Flow End-to-End

A critical shift with AI is that lineage no longer stops at the data layer.
We now need lineage that covers:

• Prompt (user question / system instruction)
• Retrieval (which documents/rows were used, under which PIT conditions)
• Transformation (how the LLM combined or summarised them)
• Output (what was shown, to whom, and when)

From a platform perspective, this means:

1. Every retrieved chunk must carry:
   • table/view name
   • primary key(s) or business key(s)
   • as_of timestamp or effective window
   • source_system identifier
   • precedence_rule_version (if applicable)
2. The RAG layer (or AI gateway) must log:
   • prompt_text
   • retrieved_context_ids and their metadata
   • model_version
   • temperature/parameters
   • response_text
   • user_id / role / channel
3. Lineage tools (e.g. OpenLineage, Unity Catalog, custom metadata stores) should represent:
   • AI requests as first-class jobs
   • Retrievals as edges from AI jobs to data assets
   • Outputs as derived artefacts with links back to the sources.

5.1 PRA/FCA Expectation Summary

If asked “How did this AI-assisted decision / answer / report come to be?”, you must be able to show:

• which data it saw
• as of which effective dates
• which precedence rules applied
• which model version ran
• which human(s) approved or actioned the result

If you can’t do that, the platform is not regulator-defensible.

6. SMCR Accountability Mapping for AI

Under the Senior Managers and Certification Regime (SMCR), accountability is not abstract. It attaches to named individuals.

For AI and LLM integration, your operating model needs to answer:

• Who owns the AI platform? (usually under CDO, CIO, or Chief Data & Analytics Officer)
• Who owns the data feeding the AI? (domain product owners, data owners)
• Who owns the retrieval logic and precedence rules? (data architecture / platform engineering)
• Who owns the user-facing application? (business function: complaints, AML, risk, etc.)
• Who is the accountable SMF (Senior Manager Function) for AI-related decisions?

A pragmatic pattern:

• SMF for data & analytics – accountable for platform capabilities, lineage, and controls.
• SMF for each business function – accountable for use of AI in that function (e.g. complaints, lending, AML).
• RACI matrix per AI use case:
  • Responsible: AI platform team / data engineering
  • Accountable: SMF (business + data)
  • Consulted: Risk, Compliance, Legal
  • Informed: Audit, IT Operations

6.1 FS Reality Check

In practice, what fails isn’t the technology — it’s the lack of clarity on who signs what.

You want to be able to say, in a Board or PRA meeting:

“For AI-assisted complaint handling, SMF X is accountable for the business outcome; SMF Y is accountable for the data and AI platform integrity. Here is the signed-off RACI and evidence.”

Without that, even technically sound systems will struggle under regulatory scrutiny.

7. Where the AI Platform Team Actually Sits (Real Org Patterns)

In theory diagrams, “AI” is a neat layer on top of everything. In reality, org design determines whether your AI integration is coherent or fragmented.

Two patterns I’ve seen repeatedly in Tier-1 UK banks and large insurers (anonymised but very real):

7.1 Pattern A – AI Platform Under the CDO (Data-Led)

• Chief Data Officer (or Chief Data & Analytics Officer)
  • Data Platform & Engineering (medallion, SCD2 Bronze, PIT, lineage)
  • AI/ML Platform Team (MLOps, LLMOps, RAG services, AI gateway)
  • Data Governance & Metadata (catalogue, glossary, policies)

Business units then build:

• Domain AI Products (Complaints Copilot, AML Case Summariser, Risk Copilot) on top of the AI platform.

Pros:

• Strong alignment between AI and data lineage
• Easier to embed PIT, precedence, and SCD2 awareness into AI pipelines
• Governance is centralised

Cons:

• Requires a mature CDO function and strong sponsorship
• Risk of being seen as “central ivory tower” if not carefully managed

7.2 Pattern B – AI Platform Under CIO / CTO, Federated with CDO

• CIO / CTO
  • AI Engineering / Platform
  • Application Development
• CDO
  • Data Platform (medallion, SCD2)
  • Governance & Lineage

Alignment is enforced via:

• Joint Steering Committees
• Shared RACI for AI + Data
• Platform contracts (AI can only access data via defined, governed endpoints)

Pros:

• AI seen as part of mainstream technology
• Easier integration with applications and channels

Cons:

• Higher risk of AI bypassing data governance if the partnership is weak
• Needs very tight coordination to keep AI from plugging directly into “whatever database is easiest”

8. FS Reality Check: What Actually Goes Wrong

A few recurring patterns that look harmless on whiteboards but fail disastrously in production:

• Shadow RAG: A team spins up its own vector DB, feeds it CSV extracts from “some warehouse tables”, and points a model at it. No PIT, no SCD2 awareness, no lineage.
• Compliance-as-a-Workshop: AI use is “governed” through one-off workshops and policy PDFs, but there is no enforceable technical architecture.
• Fine-Tuning on Raw Exports: Someone builds a domain assistant by dumping raw tickets, emails, or case notes into a fine-tuning corpus without minimisation, masking, or retention controls.

The architecture in this article is designed to make those architecturally impossible, not merely discouraged.

Emerging Risk:
As AI usage matures, organisations should also monitor for model drift, stale embeddings, and the misuse of synthetic or augmented data that no longer reflects regulated source truth.
These risks do not change the architecture — they reinforce the need for tight lineage and lifecycle controls.

9. Conclusion: AI as a First-Class Citizen of the Temporal Platform

If there is a single theme running through this series, it is:

You cannot treat time, truth, and lineage as optional in UK Financial Services.

Integrating AI and LLMs into your platform is no exception.

The patterns that work are:

• AI as a consumer and orchestrator of the medallion, not a parallel universe
• SCD2 and temporal repair only in Bronze, with AI reading via PIT-aware slices
• RAG over Silver/Gold, never blind against arbitrary current-state tables
• Fine-tuning on minimised, anonymised data, with clear lineage and retention
• End-to-end lineage from prompt → context → source rows, not just table-level lineage
• Clear SMCR accountability and organisational placement for the AI platform

In 2025–2026, the question is no longer whether AI belongs in FS data platforms.
The question is whether your architecture allows you to say, with a straight face to a regulator:

“We can show you exactly what this AI system saw, when it saw it, which state of the data it used, which rules governed it, and who is accountable.”

If the answer to that is yes, then AI becomes a powerful, defensible extension of your medallion architecture — not a liability layered on top of it.