June 29, 2026
/
3 Mins

Why Semantic Modeling Is Critical for Regulated Industries

Blog Post
Data Culture
Sami Hero
CEO
Abstract:
Regulated industries don't struggle with data volume, they struggle to prove their definitions are consistent and their calculations repeatable. Semantic modeling addresses this by establishing shared definitions for concepts like customer, policy, and exposure across departments and systems that were never designed to agree with each other. The article walks through how this plays out in financial services (BCBS 239 risk aggregation), insurance (Solvency II reporting), and healthcare (HIPAA-governed patient data), and argues that most organizations already have the data infrastructure but lack agreement on the business concepts feeding into it. It also makes the case that AI raises the stakes rather than solving the problem: AI systems inherit and accelerate inconsistent definitions rather than resolving them, which creates additional explainability risk in regulated environments. The piece closes by positioning semantic modeling as a traceability requirement, not a documentation exercise, connecting the number a regulator sees back to the definition that produced it.

Regulated industries don't struggle with data volume. Banks, insurers, and healthcare providers all generate plenty of it. What they struggle to do is explain what that data means, where it came from, and whether the same number would show up the same way in two different reports. That's what regulators actually test for: can you show your definitions are consistent and your calculations are repeatable, not just that you filed on time.

Semantic modeling is the layer that makes that possible. It's the shared definition of business concepts (customer, policy, exposure, claim) that sits underneath every system, report, and audit trail. As AI gets embedded deeper into operations that shared definition layer stops being a nice-to-have.

Compliance Is a Consistency Problem, Not a Reporting Problem

Take an insurer where underwriting, claims, finance, and customer service all touch policy data. Each team can reasonably define "active policy" differently for their own purposes. That's fine until finance needs a number that reconciles with what claims reported, and now someone's manually chasing down why the two don't match. Multiply that across financial services, healthcare, and telecom, where reporting draws from a dozen systems that were never designed to agree with each other, and you get the audits that take three times longer than they should.

Where This Plays Out by Industry

Financial services. A single customer might hold a mortgage, a credit card, and an investment account, each living in a different system with its own logic. Regulatory reporting and AML programs depend on "customer" and "exposure" meaning the same thing across all three. This is the exact problem BCBS 239 was written to address: banks being unable to aggregate risk data consistently across business lines.

Insurance. The same policy gets touched by underwriting, claims, actuarial, and finance, each of whom may use "coverage" or "claim exposure" slightly differently. Solvency II reporting requirements assume those terms mean one thing across the organization, not four things depending on which team pulled the number.

Healthcare. Patient records, treatment data, and billing sit in separate systems that rarely share a data model. HIPAA compliance and clinical reporting both depend on definitions holding steady across departments that have no reason to coordinate on their own.

Why Data Infrastructure Alone Doesn't Fix This

Most regulated organizations already have warehouses, catalogs, and governance tooling. Many are running AI pilots on top of that stack. And many still can't answer "what counts as an active account" without a meeting. That's because most data tools manage technical assets (tables, lineage, quality scores) rather than business concepts. You can have perfect data lineage and still have four different definitions of "customer" feeding into it.

This is a conceptual modeling gap, not a tooling gap. Definitions that live in one analyst's head or a spreadsheet nobody else has access to don't scale past the size of team that created them.

What Regulators Actually Want

A correct number isn't sufficient on its own. Regulators and auditors want to see where the number came from, which rules were applied to calculate it, and who signed off on the definition behind it. When a definition changes, an organization needs to be able to trace every downstream report or metric that depended on it, quickly, not after three weeks of grepping through spreadsheets.

AI Makes This Worse, Not Better, If the Foundation Isn't There

AI systems don't resolve inconsistent definitions, they inherit them and apply them faster. An AI assistant answering questions about "customer risk" will give a different answer depending on which system's definition it happened to pull from. That's not an AI reliability problem, it's a semantic foundation problem that AI just makes visible faster than a human analyst would have. And in a regulated environment, being unable to explain why a model gave a particular answer is its own compliance risk, separate from whatever the model actually got right or wrong.

Where Ellie.ai Fits

Ellie.ai connects conceptual models, business glossaries, governance metadata, and technical implementation so that business and technical teams work from the same definitions before those definitions reach a regulatory submission or an AI system. In practice that means:

  • Consistent definitions for customers, accounts, policies, and claims across departments that don't naturally talk to each other
  • Visibility into what breaks downstream when a definition changes
  • A shared reference point for business, compliance, and technical teams instead of three separate ones

The goal isn't another documentation layer. It's making sure the number regulators see and the definition that produced it are traceable back to something that was actually agreed on, not assumed.

Get Data Modeling News!