![Modeling and AI 2026]()
Artificial Intelligence is changing how people consume data.
Today, business users do not only open reports. They ask questions in natural language. They expect copilots for example to explain trends, detect anomalies, generate SQL, summarize dashboards, and recommend decisions.
Because of this, many teams are asking an important question:
Do we still need the same data warehouse modelling standards in 2026?
My answer is simple:
Yes, but they must evolve.
AI does not remove the need for good data modelling. In fact, AI makes good data modelling more important than ever.
The mistake: Thinking AI can fix bad data models
A common misconception is that AI can sit on top of any data source and magically produce correct answers.
For example, imagine we have these tables:
Sales_2024
Sales_Final
Sales_New
Customer_Data
Customer_Master_v2
Invoices_Backup
Revenue_Adjusted
Revenue_Final_Final
A user asks the AI assistant:
What was our revenue last quarter by customer segment?
The AI may generate a query, but which table should it use?
Should it use Sales_Final, Revenue_Adjusted, or Invoices_Backup?
What is the trusted definition of revenue?
Does revenue include cancelled invoices?
Does it exclude tax?
Does it use invoice date or payment date?
This is where AI becomes dangerous. It may produce an answer that looks professional but is based on the wrong logic.
AI can help users ask questions faster, but it cannot compensate for unclear definitions, bad relationships, poor data quality, and inconsistent modelling.
What still matters in 2026
The core principles of data warehouse modelling are still valid.
We still need:
Facts
Dimensions
Clear grain
Business keys
Surrogate keys
Conformed dimensions
Data quality checks
Lineage
Certified metrics
Security rules
These are not old fashioned concepts. They are the foundation for trusted analytics.
For example, a fact table should still have a clear grain:
FactSales
One row = one invoice line
A dimension should still describe a business entity:
DimCustomer
One row = one customer version
A metric should still have one approved definition:
Net Revenue = Gross Amount - Discounts - Returns - Tax
Without this, AI tools will generate inconsistent answers depending on which table, column, or report they access.
Example 1: Revenue definition problem
Let us take a fictional company called BlueWave Retail.
They have three departments:
Finance
Sales
Operations
Each department has its own revenue logic.
Finance says:
Revenue = invoiced amount excluding VAT
Sales says:
Revenue = order amount before discounts
Operations says:
Revenue = shipped amount
Before AI, this was already a problem. Different reports showed different revenue numbers.
With AI, the problem becomes bigger.
A user asks:
Why did revenue drop in April?
The AI assistant might use the Sales definition in one answer, the Finance definition in another answer, and the Operations definition in a third answer.
The result is confusion.
The solution is not to remove modelling standards. The solution is to strengthen them.
There should be a certified business definition:
Certified Net Revenue =
Invoice Amount Excluding VAT
- Credit Notes
- Approved Adjustments
Then this metric should be exposed through the semantic layer, not redefined separately in every report.
Example 2: Bad relationships in Power BI
Imagine a Power BI semantic model with these relationships:
Products → Sales
Products → Product Mapping → Sales
Product Hierarchy → Products → Sales
Product Hierarchy → Product Mapping → Sales
This creates duplicated filter paths.
The model may still work, but performance can be poor and results can become confusing.
A report user may not notice the issue. They only see a slow visual.
But when AI is added, the risk increases.
A copilot may try to explain sales by product hierarchy, but the filter path may not be clean. The generated answer can become unreliable because the model itself is ambiguous.
In this case, classic modelling standards are still needed:
Use a clean star schema
Avoid unnecessary bidirectional relationships
Avoid many-to-many relationships unless justified
Keep dimensions clean
Keep facts at a clear grain
AI does not replace good Power BI modelling. It depends on it.
Example 3: A Lakehouse without a business layer
Many companies are now using lakehouse platforms such as Microsoft Fabric, Azure Databricks, or similar technologies.
A common structure is:
Bronze
Silver
Gold
This is a good approach, but it does not automatically mean the data is ready for business users or AI.
For example:
Bronze.CustomerEvents
Silver.CleanedCustomerEvents
Gold.CustomerActivity
This may be technically clean, but business questions still need modelling.
A user may ask:
How many active customers did we have last month?
The system needs to know:
What is an active customer?
Is it based on login?
Purchase?
Subscription?
Invoice?
Contract status?
So even in a lakehouse architecture, we still need dimensional and semantic modelling.
A better structure is:
Bronze Layer
Raw source data
Silver Layer
Cleaned and standardized data
Gold Layer
Business-ready facts and dimensions
Semantic Layer
Certified metrics and business definitions
AI Consumption Layer
Copilots, vector search, natural language Q&A, APIs
The lakehouse does not replace the data warehouse model. It extends it.
What needs to change in 2026 ?
The standards should not stay exactly the same. They need to evolve.
In the past, data warehouse standards were mostly designed for:
SQL reports
Dashboards
OLAP cubes
Power BI datasets
Excel extracts
In 2026, they must also support:
AI assistants
Natural language queries
Semantic search
RAG solutions
Machine learning features
APIs
Real-time analytics
Self-service BI
Data products
This means our modelling standards need additional rules.
New standard 1: Every important metric must be certified
In the AI era, metrics cannot be scattered across reports.
Bad example:
Revenue defined in Report A
Revenue redefined in Report B
Revenue calculated differently in Excel
Revenue recreated by AI-generated SQL
Good example:
Certified metric: Net Revenue
Owner: Finance
Definition: Invoice amount excluding VAT minus credit notes
Source: FactInvoiceLine
Date logic: Invoice Date
Refresh frequency: Daily
Security: Region-level access
This gives AI a trusted source of truth.
New standard 2: Data products need business metadata
AI needs context.
A table name like this is not enough:
fact_transactions
The AI also needs to understand:
What does one row represent?
Which date should be used?
Which amount is official?
Which records should be excluded?
Who owns the data?
How fresh is the data?
Which columns are sensitive?
For example:
Table: FactBilling
Grain: One row per billing transaction
Official amount: Net_Amount_EUR
Business date: Transaction_Date
Exclude: Cancelled transactions
Owner: Finance Data Team
Refresh: Daily at 06:00
Sensitive columns: Customer_Email, Tax_ID
This metadata is not only documentation. It becomes part of the AI-ready data foundation.
New standard 3: Data quality rules are mandatory
AI should not answer business questions on top of broken data.
For example, before exposing a billing table to AI, we should validate:
Transaction date is not in the future
Currency is not null
Exchange rate exists
Customer key exists
Department exists
Amount is not duplicated
Status is valid
A simple data quality rule could be:
SELECT *
FROM FactBilling
WHERE Currency_Code IS NULL;
Another one:
SELECT *
FROM FactBilling
WHERE Transaction_Date > CURRENT_DATE;
Another one:
SELECT *
FROM FactBilling
WHERE Net_Amount_EUR IS NULL
AND Original_Amount IS NOT NULL;
If these checks fail, the AI layer should either not use the data or should clearly warn the user that the data is incomplete.
New standard 4: AI needs governed access, not direct access to everything
Giving AI access to every raw table is risky.
Bad approach:
AI can query all Bronze, Silver, Gold and report tables.
Better approach:
AI can query only certified business views, semantic models and approved data products.
For example:
vw_certified_sales_summary
vw_certified_customer_activity
vw_certified_billing_quality
vw_certified_inventory_status
This reduces the risk of AI using temporary, obsolete, or technical tables.
New standard 5: Semantic layer becomes critical
The semantic layer is no longer just a Power BI convenience.
It becomes the business contract between data and AI.
The semantic layer should define:
Measures
Relationships
Hierarchies
Business descriptions
Security
Synonyms
Certified KPIs
Calculation logic
For example:
Measure: Total Net Revenue
Expression: SUM(FactBilling[Net_Amount_EUR])
Business description: Total invoiced revenue excluding VAT and credit notes
Default date: Transaction Date
Allowed breakdowns: Entity, Region, Department, Customer, Month
This helps AI understand not only the data structure, but also the business meaning.
Practical Example: old Standard vs 2026 standard
Old data warehouse standard:
Create fact and dimension tables
Create relationships
Build reports
Document tables
2026 AI ready standard:
Create facts and dimensions
Define clear grain
Certify business metrics
Add data quality rules
Add ownership and lineage
Add sensitivity labels
Expose through semantic layer
Expose only trusted views to AI
Monitor usage and accuracy
The foundation is the same but the expectations are higher.
Example: AI ready sales model
A good AI ready sales model may look like this:
FactSales
- Sales_Key
- Customer_Key
- Product_Key
- Date_Key
- Region_Key
- Quantity
- Gross_Amount
- Discount_Amount
- Net_Amount
- Tax_Amount
DimCustomer
- Customer_Key
- Customer_ID
- Customer_Name
- Customer_Segment
- Country
- Valid_From
- Valid_To
- Is_Current
DimProduct
- Product_Key
- Product_ID
- Product_Name
- Product_Category
- Product_Family
DimDate
- Date_Key
- Date
- Year
- Quarter
- Month
- Week
Certified metric:
Total Net Sales = SUM(FactSales[Net_Amount])
Business rule:
Cancelled orders are excluded from FactSales.
AI metadata:
Use Transaction Date for sales trend analysis.
Use Customer Segment for customer grouping.
Use Net Amount for official revenue reporting.
Do not use Gross Amount unless the user asks for before-discount value.
Now when a user asks:
Which customer segment had the highest revenue growth this quarter?
The AI has a much better chance of giving a correct answer.
What we should stop doing
In 2026, we should stop accepting these habits:
Creating one big flat table for everything
Duplicating measures in every report
Using unclear column names
Keeping unused tables and columns forever
Allowing many-to-many relationships without review
Using bidirectional filters everywhere
Building AI on top of raw data
Letting every team define KPIs differently
Ignoring data quality issues
Treating documentation as optional
These habits were already bad for BI. With AI, they become even more dangerous.
What we should keep doing ?
We should continue to enforce:
Dimensional modelling
Star schema design
Clear fact grain
Conformed dimensions
Surrogate keys where needed
Slowly changing dimensions where needed
Validated business rules
Controlled access
Performance optimization
Documentation
These standards are not outdated. They are the reason AI can be trusted.
My final thought
AI changes the way people interact with data but it does not remove the need for modelling.
A bad data model with AI is still a bad data model.
Actually, it is worse, because AI can make wrong answers look confident.
The future is not:
AI instead of data modelling
The future is:
AI on top of trusted data modelling
So, are we keeping the same data warehouse modelling standards in 2026?
We are keeping the principles but raising the bar.
The modern standard is:
Dimensional modelling
+ Lakehouse architecture
+ Semantic layer
+ Data quality
+ Governance
+ AI-ready metadata
Because in the AI era, trusted data is not optional.
It is the product.