AI readiness in financial services means having data, architecture and governance that can support AI reliably, repeatedly and with enough context to explain how information was produced.
For those of you wanting the cutting edge, that definition may sound less exciting than choosing an LLM or launching an agent but for banks, insurers and other financial organizations; it is actually usually the more consequential part of the problem. Sure, AI can generate an answer remarkably quickly. But establishing whether that answer was built on the right customer definition, the correct historical record and transformations that can be traced back to source is all too often harder.
This challenge was central to a recent WhereScape Industry Blueprint webinar presented by Filip Kraus, Data Expert at our partner UD4D, alongside fellow data veteran Hana Dostálová. Drawing on more than two decades of combined experience across insurance and financial services data warehousing, their argument was refreshingly grounded: organizations should establish the governed data foundation before expecting AI and agentic systems to make dependable use of it.
Even if you missed the live session, you can watch the full Insurance & Financial Services Industry Blueprint webinar. As the concepts discussed were so central to those in highly-regulated space, we believe several of its lessons are worth exploring in more detail because they say something important about where AI readiness work should really begin.
Why AI Readiness Is Different in Financial Services
Banks and insurers have already been making complex decisions with data for decades. What changes in this era of AI is the speed, breadth and sometimes opacity with which data can be consumed.
A traditional regulatory report normally follows a known path through defined calculations and controls. An AI assistant or agent may potentially retrieve information from many sources, combine it dynamically and use that context to generate an answer or initiate further work.
That makes familiar weaknesses in the data estate even harder to ignore.
During the webinar, UD4D identified four recurring reasons financial services data programs become slow or expensive:
- Regulatory and audit pressure requires outputs to be accurate, repeatable and explainable.
- Legacy platforms concentrate critical knowledge among a small number of specialists.
- Inconsistent definitions undermine trust when different systems produce different answers for apparently identical concepts.
- AI adoption can move faster than the data foundation underneath it.
The fourth problem tends to magnify the others. If the organization cannot confidently establish what “customer,” “exposure,” “claim” or “account balance” actually means across its existing environment, adding an AI interface does not resolve the disagreement. Instead it may simply make an uncertain answer easier to obtain.
This concern increasingly appears in regulatory thinking too. EIOPA’s AI governance opinion for insurers advocates a risk-based and proportionate approach to AI governance and risk management.
In US banking, revised interagency model risk guidance issued in April 2026 emphasizes risk-based governance, validation and ongoing monitoring for models, while explicitly noting that generative and agentic AI fall outside that particular guidance’s scope and should still be subject to appropriate organizational governance and controls.
The precise regulatory detail varies by jurisdiction and use-case but the architectural implication is more universal: financial institutions need to understand the data and processes that support consequential automated decisions.
Only Start AI Readiness With a Solid Data Foundation
A useful way to think about AI readiness is to work backward from the point of consumption.
Imagine scenarios like this: an insurer may eventually want AI to help investigate claims. A bank might want an agent to answer questions about customers, analyze regulatory information or accelerate development work. But before those use cases can be trusted, somebody needs to know where the underlying information came from and what happened to it on the journey.
In the architecture UD4D presented, source systems such as policies, claims, CRM and finance feed an enterprise data warehouse. WhereScape 3D supports discovery and design while WhereScape RED handles integration, automation, deployment and operation. Regulatory reporting, analytics, actuarial outputs and AI sit at the consumption end.
Crucially, governance, business context, metadata and lineage run underneath the whole architecture. Governance cannot begin after the Gold layer has already been built or once an AI team asks for access. Different source systems may attach different meanings to the same term, and those differences have to be understood as data is integrated.
Our own approach to data governance and lineage is based on a similar principle: models, mappings, documentation, lineage, impact analysis and deployment history are more dependable when they are created as part of data delivery rather than reconstructed later.
The Expensive Part of a Data Platform Is Often What Happens After the First Build
One observation from the webinar deserves more attention because it is easy to underestimate during an AI project.
The initial build is highly visible. It has a project plan, a budget and a launch date. Over the lifetime of a financial data platform, however, a substantial amount of cost can accumulate through understanding it, changing it and repeatedly proving how it works.
Every audit request, regulatory change or unexplained discrepancy requires people to reconstruct context. Manual reconciliation becomes routine when systems disagree. Knowledge concentrated in one architect or developer creates operational risk. Problems discovered during an audit are particularly expensive because remediation begins only after the gap already matters.
AI readiness therefore benefits from an architecture designed for change rather than simply optimized for the first implementation.
This is one reason metadata-driven automation becomes relevant. If transformation rules and patterns exist centrally, a change can be reflected through the model – then regenerated and deployed consistently, rather than manually recreated across multiple objects.
The value may appear modest on one change. Over ten, twenty or hundreds of changes, the cumulative difference can become very substantial. That was one of Filip’s recurring points in the webinar: metadata becomes most valuable when the environment has to keep evolving.
Metadata Should Describe the Warehouse and Help Build It
Metadata can all too easily become another documentation project. We find that the more interesting approach is to make metadata operational instead.
In metadata-driven architecture, the model, mappings, transformation rules and other definitions help determine what actually gets generated and deployed. Documentation and lineage can then emerge from the same metadata, rather than being manually recreated to describe the resulting system.
WhereScape 3D, for example, supports source profiling and model-driven design while maintaining information about the architecture. When combined with WhereScape RED, the delivery flow can connect models, transformations, generated code, jobs, dependencies and documentation.
For AI readiness, that creates something potentially more valuable than documentation alone: machine-readable context about how the environment works.
An AI agent that encounters a table name has limited information. Give it metadata describing the model, transformations, dependencies, lineage and business context around that table and the quality of the context available to the agent improves considerably.
The broader idea is also reflected in NIST’s AI risk-management work, which emphasizes governance and trustworthiness throughout the AI lifecycle – rather than treating them as final-stage controls.
The Architecture Question: 3NF, Dimensional or Data Vault?
It would make our lives here at WhereScape a lot easier if there was but unfortunately, there is no single modeling methodology that makes an organization AI-ready.
The webinar considered three familiar approaches: normalized enterprise models, dimensional modeling and Data Vault. Each comes with legitimate uses and, like most things in life, different tradeoffs.
Dimensional models remain excellent consumption structures because facts and dimensions are intuitive for reporting and analytics. Normalized enterprise models can create strong consistency with relatively little redundancy.
Filip mentioned that UD4D frequently favors Data Vault for the enterprise integration and historical layer, particularly when environments are expected to absorb new sources and requirements over many years.
The reason comes down largely to extensibility: Data Vault separates business identities, relationships and descriptive history, allowing the architecture to expand without repeatedly redesigning the existing foundation. The tradeoff is structural complexity: more tables, more joins and more objects for engineers to manage. Automation can remove much of that repetitive implementation work while retaining the underlying pattern.
Our Data Vault automation capabilities are built around precisely that challenge, including automated generation of hubs, links and satellites + standardized lineage and documentation.
For AI readiness, however, the modeling methodology is arguably less important than the characteristic it produces: a governed architecture whose history and relationships remain understandable as it grows.
Capture Knowledge Before AI Needs It
The phrase “tribal knowledge” can be overused in data engineering but much like a cliche than you discover from first principles, the problem itself is very real.
A senior architect may understand why a transformation works the way it does. A developer may remember why an exception was introduced six years ago. A compliance specialist may know which apparently similar fields carry very different regulatory meanings.
If that context exists only in people’s heads, the organization has both a human continuity problem and an AI context problem. Fun, right?
UD4D’s approach is to capture architecture and delivery knowledge in models, metadata and reusable templates so routine maintenance does not always require the original architect.
This does not make expert knowledge obsolete. Quite the opposite. Experienced people still establish the difficult rules, definitions and exceptions. The aim is to record those decisions in forms that can be reused consistently.
The same principle applies when AI enters the development lifecycle. An agent grounded in explicit patterns and metadata has a very different starting point from an agent trying to infer decades of design choices by reading a collection of SQL scripts.
Technical Governance and Business Governance Need Each Other
There is an important boundary to be weary of here.
WhereScape can maintain detailed technical knowledge about what occurs inside the data warehouse: models, objects, mappings, transformations, generated code, jobs, dependencies, lineage and documentation.
That does not make WhereScape a complete enterprise business-governance system.
Business definitions, ownership, regulatory interpretation and the wider meaning of data often sit outside the warehouse itself. UD4D describes combining the technical governance within WhereScape with a broader governance layer that captures those business concepts.
Technical lineage might establish that a regulatory value originated in a particular source field and passed through three transformations. Business governance explains what that value represents, who owns its definition and why the organization uses it.
AI needs both kinds of context if it is going to move beyond simple retrieval – toward more consequential workflows.
From Governed Data to Governed Agents
Perhaps the most forward-looking section of the webinar concerned agentic delivery.
UD4D is exploring how combined technical and business context can support AI agents that do more than answer questions. A sufficiently governed workflow could analyze a new requirement, determine affected warehouse objects, trace downstream impact and prepare changes for expert review.
The important phrase there is expert review.
In the approach Filip described, the specialist remains accountable. The agent handles repetitive analysis and implementation steps while the expert verifies that the requirement was understood correctly, reviews difficult business logic and approves the result.
This feels like a more realistic path to enterprise AI than assuming that autonomy itself is the objective. For regulated organizations, the valuable outcome may be giving knowledgeable people far greater leverage, while retaining identifiable decision points and review.
Our broader AI-ready data approach follows the same underlying principle: data validation, quality, governance and metadata visibility create the foundation on which more ambitious AI use cases can safely develop.
What Long-Lived Financial Data Platforms Teach Us About AI Readiness
In the webinar, Filip provided two useful examples of what this typically looks like over time.
In one insurance implementation, UD4D initially built an enterprise warehouse, integration platform, reporting environment and governance layers for the Czech branch of a major European insurer. The technical architecture was modeled in WhereScape 3D then implemented through RED, with Power BI used for reporting and data-quality rules incorporated into the modeled environment.
The same core architecture was later rolled out to other European countries. Rather than redesigning the central model each time, most additional work concerned new source integrations and genuine country-specific requirements such as local regulation. The existing architecture is now being evaluated as a foundation for an agentic implementation.
Filip’s second example involved a European bank that wanted an enterprise warehouse capable of absorbing additional sources without repeated redesign. UD4D adopted Data Vault, with the raw vault designed in 3D and generated into RED, while RED templates supported the business vault and downstream structures.
More than ten years later, the same foundation remains in use. That in itself speaks volumes. The number of sources and volume of data have of course grown considerably while historical data remains traceable, subject of course to required removals such as those driven by GDPR.
That longevity is worth considering when discussing AI readiness. A platform does not become strategically useful simply because it was delivered quickly. It becomes useful when it can absorb the next source, regulation, model or consumption pattern – without forcing the organization to rediscover how everything works.
We see comparable principles in publicly documented WhereScape customers: FinWise Bank, for example, built a Data Vault 2.0 enterprise warehouse in three months compared with an estimated 18 months for the previous manual approach, while using lineage and documentation to strengthen auditability. Toyota Financial Services used WhereScape while moving 95% of its infrastructure to Snowflake, standardizing reporting data across nine countries and using metadata, lineage and automation to support regulatory reporting.
A Practical AI Readiness Checklist for Banks and Insurers
Organizations do not necessarily need to redesign their whole architecture before exploring AI. It is useful, however, to establish whether the foundation beneath a proposed use case can answer some fairly basic questions…
- Can we define the business concepts the AI system will rely on consistently across source systems?
- Can important outputs be traced back through transformations to their original data?
- Can we explain how definitions or transformation logic have changed over time?
- Are data-quality controls repeatable rather than dependent on manual reconciliation?
- Is critical architecture knowledge captured outside the heads of individual specialists?
- Can teams assess the downstream impact of a change before deploying it?
- Can deployment and processing history provide evidence of what happened and when?
- Can the data platform absorb new sources and requirements without continual redesign?
- Are technical metadata and business meaning connected sufficiently for people and AI systems to understand the environment?
- Do human experts retain clear responsibility for consequential decisions and exceptions?
An organization that cannot answer all of these questions may still be able to run an AI pilot. The gaps become increasingly more important as that pilot moves toward operational or regulated processes.
AI Readiness Is Really About Being Ready for Change
There is an understandable temptation to treat AI readiness as a destination: clean the data, establish the platform and declare the organization ready. It’d be nice but back in reality, financial data estates rarely cooperate with that idea.
Regulation changes. Products evolve. Acquisitions introduce additional systems. Customer definitions are refined. Models change and completely new AI capabilities appear surprisingly quickly.
A more useful interpretation of AI readiness is the ability to keep changing without losing understanding.
That means capturing metadata as the environment is built, maintaining lineage alongside transformations, separating reusable architecture from genuine business exceptions and ensuring that documentation evolves with the implementation.
Filip summarized the broader lesson at the end of the webinar when asked for his biggest data warehousing takeaway. His answer was governance and ontology: when teams believe they are talking about the same concept but actually mean different things, discrepancies follow.
AI makes resolving those ambiguities more urgent because it gives organizations increasingly powerful ways to act on their data. The stronger the capability becomes, the more valuable it is to know exactly what that data means.
For a deeper walkthrough of the architecture, Data Vault decisions and agentic approach discussed here, we encourage you to watch the full UD4D and WhereScape Industry Blueprint webinar. The session provides a particularly useful view of AI readiness from people who have spent years maintaining financial data platforms after the initial implementation, which is exactly the perspective the current AI conversation demands.
FAQ: AI Readiness in Financial Services
AI readiness means having data, architecture, governance and operational controls capable of supporting AI reliably. In financial services this commonly includes consistent definitions, data quality, historical traceability, technical lineage, documentation and clear ownership.
AI systems depend on the context and quality of the data available to them. Governance helps establish what data means, where it came from, how it changed and who is accountable for important definitions and controls.
No. Data Vault is one architectural approach and it can be particularly useful where organizations need historical traceability and frequent extension of the data model. Normalized and dimensional models also remain appropriate in many scenarios. Architecture should reflect the organization’s requirements rather than adopting a methodology simply because AI is involved.
Metadata can provide AI with context about data structures, transformations, relationships, lineage and dependencies. When combined with business definitions and governance it can help an AI system understand the environment rather than infer meaning only from table and column names.
Lineage allows teams to trace data from consumption back through transformations to source. This helps with investigation, impact analysis, auditability and explaining which information contributed to an AI-supported process.
Agentic AI can potentially automate parts of analysis and data development but appropriate controls absolutely depend on the use-case and regulatory environment. A governed approach can combine metadata and business context with human review, so that experts remain accountable for consequential changes and decisions.
Our products focus on the governed data foundation beneath analytics and AI. WhereScape supports source discovery, modeling, metadata-driven development, Data Vault automation, documentation, technical lineage, impact analysis, orchestration and repeatable deployment so that teams can create data environments that remain understandable as they evolve.
