DEV Community: Arisyn

Beyond Data Lineage: Building Observability for AI-Generated Queries

Arisyn — Wed, 05 Aug 2026 15:19:00 +0000

Enterprise AI is moving from experimentation to production.

Organizations are deploying AI assistants that can query databases, generate reports, and analyze business data.

The first challenge was making AI capable of answering questions.

The next challenge is making those answers trustworthy.

When an AI system provides an answer, enterprises need to understand:

What data did AI use?
Why did AI choose those tables?
Which business definitions were applied?
How was the final answer generated?

This is where traditional data observability needs to evolve.

Traditional Data Observability Was Built for Data Pipelines

For years, enterprises focused on understanding how data moved.

A typical lineage looks like:

Source Database

↓

ETL Pipeline

↓

Data Warehouse

↓

BI Report

Organizations needed to know:

Where did data come from?
Which pipeline transformed it?
Which reports depend on it?

This became the foundation of modern data governance.

However, AI introduces a different type of data consumption.

AI does not only move data.

AI interprets data.

AI Creates a New Observability Challenge

Consider a question:

Why did sales decrease last month?

An AI assistant may:

Understand the question.
Select relevant data sources.
Generate SQL.
Execute the query.
Explain the result.

The final answer may look reasonable.

But enterprises need more visibility.

They need to understand:

User Question

↓

AI Interpretation

↓

Business Definition

↓

Selected Data Sources

↓

Relationship Path

↓

Generated SQL

↓

Final Answer

This is different from traditional data lineage.

It is AI reasoning lineage.

Why AI Query Results Need Explainability

Traditional BI systems use predefined reports.

Users usually know:

which metric is used;
which data source is connected;
how calculations are performed.

AI-powered analytics changes this.

The query path can be generated dynamically.

The selected tables may change.

The SQL may be different for different questions.

Therefore, AI systems need to explain not only the answer, but also the reasoning behind the answer.

The Four Layers of AI Data Observability

AI data observability extends traditional data governance with new capabilities.

1. Query Lineage

Traditional lineage asks:

Where did this data come from?

AI query lineage asks:

How did AI produce this answer?

It should capture:

user question;
generated SQL;
selected tables;
filters;
returned datasets.

2. Semantic Lineage

Enterprise concepts often have multiple meanings.

For example:

Revenue may mean:

sales revenue;
recognized revenue;
invoice amount;
payment amount.

AI observability needs to record:

which business definition was used;
which metric mapping was applied;
which semantic rules affected the answer.

3. Relationship Lineage

Enterprise queries often depend on relationships:

Customer

↓

Order

↓

Invoice

↓

Payment

AI needs to know:

which relationship path was selected;
why this path was chosen;
whether the relationship is trusted.

A valid SQL join does not always represent a valid business relationship.

4. Answer Explainability

Enterprise users need more than a result.

They need to understand:

where the data came from;
what logic was applied;
what assumptions were made.

This is critical in industries where decisions depend on reliable data.

From Data Governance to AI Governance

Traditional data governance focused on:

data quality;
metadata;
lineage;
ownership.

AI introduces new requirements:

AI query traceability;
semantic consistency;
relationship validation;
answer transparency.

The question is changing from:

"Can we manage enterprise data?"

to:

"Can we trust how AI uses enterprise data?"

Final Thoughts

AI can generate answers quickly.

But enterprises need more than speed.

They need confidence.

Traditional data lineage helped organizations understand how data moved.

AI observability will help organizations understand how AI reasons over data.

The future of enterprise AI will belong to systems that are not only intelligent, but also transparent and trustworthy.

Building Data Intelligence for Reliable Enterprise AI

Arisyn — Mon, 03 Aug 2026 15:37:00 +0000

Large language models are becoming more capable every year.

They can generate SQL, write code, analyze documents, and interact with enterprise systems through tools.

However, when organizations move AI applications from prototypes to production, a common problem appears:

AI can access enterprise data.

But access does not mean understanding.

Many enterprise AI failures are not caused by weak models.

They are caused by the fact that enterprise data was designed for applications and humans, not for AI systems.

Data Access Is Not Data Intelligence

Modern enterprises already have mature data platforms:

relational databases;
data warehouses;
data lakes;
BI systems;
metadata management platforms.

These systems solve an important problem:

How do we store and access data?

AI introduces a different challenge:

How does AI understand and use this data correctly?

A database can tell an AI system:

this is a customer table;
this is a revenue column;
this field contains an identifier.

But it usually cannot explain:

which customer definition is trusted;
what revenue means in this business context;
how data from different systems should be connected.

The difference is the gap between data access and data intelligence.

Why Traditional Metadata Is Not Enough

Many enterprise AI systems start by providing metadata to LLMs.

For example:

Table: customer

Columns:
customer_id
customer_name
create_time

This information helps AI discover available data.

But it does not provide enough business understanding.

Consider a simple question:

Who are our most valuable customers?

An enterprise may have:

crm_customer

erp_customer

billing_customer

All three tables may contain customer information.

The challenge is not finding these tables.

The challenge is understanding:

Are they the same business entity?
Which one is authoritative?
How should they be related?

Without this knowledge, AI has to guess.

And guessing creates unreliable answers.

Data Intelligence Starts With Business Meaning

Enterprise data contains many ambiguous concepts.

A common example is:

Revenue

It may represent:

sales revenue;
recognized revenue;
invoice amount;
payment amount;
contract value.

From a database perspective, all of these are valid fields.

From a business perspective, they answer different questions.

Humans resolve this ambiguity through experience.

AI needs this business meaning to be explicitly available.

This is why semantic understanding is a fundamental requirement for enterprise AI.

Relationships Are the Hidden Challenge

Enterprise data is not a collection of isolated tables.

Business processes connect data together.

A simple example:

Customer

↓

Order

↓

Invoice

↓

Payment

However, real enterprise environments are much more complex.

Organizations often have:

multiple systems;
duplicated entities;
inconsistent identifiers;
historical data models.

A database may allow many possible joins.

But only some relationships represent real business logic.

A technically valid join does not always mean a business-valid relationship.

For AI applications, trusted relationships matter.

Why Bigger LLMs Are Not Enough

A common assumption is:

"If the model becomes smarter, it will solve enterprise data problems."

Better models definitely improve reasoning capabilities.

But models cannot automatically know enterprise-specific knowledge.

They cannot magically determine:

which data source the company trusts;
which metric definition is correct;
which relationship represents the real business process.

The problem is not only intelligence.

The problem is the intelligence available around the data.

Building an AI-Ready Data Intelligence Layer

Reliable enterprise AI requires more than connecting an LLM to a database.

It requires data intelligence capabilities.

Business Entity Understanding

AI needs to understand important business objects:

Customer;
Product;
Supplier;
Contract;
Project.

Not just as database tables.

As business entities.

Data Semantic Understanding

AI needs to understand:

business terms;
metric definitions;
calculation logic;
organizational language.

The same field name can represent different meanings across organizations.

Trusted Data Relationships

AI needs to understand:

which entities are connected;
which relationships are reliable;
which data paths should be used.

This enables AI to generate answers based on trusted enterprise knowledge.

The Future of Enterprise AI Data Architecture

Traditional data platforms answered:

Where is the data?

AI requires a deeper answer:

What does this data mean?

How is it connected?

Can AI trust it?

The next generation of enterprise data architecture will not replace databases, warehouses, or lakes.

Instead, it will add intelligence that makes enterprise data understandable and usable for AI systems.

Final Thoughts

Enterprise AI is not only a model problem.

It is also a data intelligence problem.

Large language models provide reasoning capabilities.

Data intelligence provides the foundation that allows those capabilities to work reliably.

The future of enterprise AI will not only depend on smarter models.

It will depend on smarter data.

Why Enterprise AI Needs Data Semantics and Relationships

Arisyn — Fri, 31 Jul 2026 14:47:00 +0000

Large language models are becoming increasingly powerful.

They can generate SQL, write code, summarize documents, and reason through complex tasks.

However, when enterprises try to deploy AI systems in production, a common problem appears:

AI can access the data.

But it does not always understand the data.

This is where many enterprise AI projects struggle.

The problem is not only model capability.

It is the missing context behind enterprise data.

## The Difference Between Data Access and Data Understanding

Modern data platforms are excellent at storing and processing information.

They provide:

databases;
data warehouses;
data lakes;
metadata catalogs;
BI systems.

From a technical perspective, AI can retrieve:

table names;
column names;
data types;
sample values.

But enterprise questions are rarely only technical questions.

For example:

What are our top customers this year?

A database can show customer-related tables.

But AI still needs to understand:

Which customer definition should be used?
Which system is the authoritative source?
Does customer mean account, buyer, or contract owner?

The missing information is not stored data.

It is business meaning.

## Data Semantics: Teaching AI What Data Means

One of the biggest challenges in enterprise AI is that business concepts are often ambiguous.

Consider the word:

Revenue

An enterprise may have:

sales_amount
invoice_amount
payment_amount
contract_value

All of these contain financial information.

But they represent different business concepts.

A financial analyst understands the difference.

An AI system does not automatically know.

Without semantic understanding, AI may generate a technically valid answer that is still wrong from a business perspective.

The SQL executes successfully.

The business decision fails.

## Data Relationships: The Hidden Complexity Behind Enterprise Data

Enterprise data rarely exists in isolation.

A simple business process may involve:

Customer

↓

Order

↓

Invoice

↓

Payment

But real enterprise environments are much more complicated.

Organizations often have:

multiple customer tables;
different identifiers;
duplicated entities;
historical schemas;
disconnected applications.

Technically, many joins are possible.

Business-wise, only some relationships are meaningful.

This creates an important distinction:

A possible relationship is not always a trusted relationship.

## Why LLMs Cannot Solve This Automatically

A common assumption is:

"If the model becomes smarter, it will understand enterprise data."

But intelligence does not replace missing information.

A powerful LLM can reason about:

A → B → C

But it still needs to know:

What is A?
What does B represent?
Is this relationship valid?

If enterprise knowledge is not explicitly represented, the model has to guess.

And guessing creates unreliable AI.

## Building More Reliable Enterprise AI

Future enterprise AI systems need more than better models.

They need a stronger connection between AI and enterprise knowledge.

This requires three important capabilities.

### 1. Business Entity Understanding

AI needs to understand core business objects:

customers;
products;
suppliers;
contracts;
projects.

Not only as database tables.

As business entities.

### 2. Trusted Relationship Understanding

AI needs to understand how entities connect.

Not every foreign key or possible join represents business logic.

The system needs to identify trusted paths between data.

*### 3. Business Semantic Understanding
*
AI needs to understand business definitions.

Metrics.

Terms.

Rules.

Context.

Because the same field name can mean different things in different organizations.

## The Next Evolution of Enterprise Data Architecture

Traditional data platforms answered:

Where is the data?

AI requires a different answer:

What does this data mean?

How is it connected?

Can we trust it?

The future enterprise data stack will not replace databases or warehouses.

Instead, it will add a layer that makes enterprise knowledge understandable to AI systems.

## Final Thoughts

The next challenge in enterprise AI is not only building smarter models.

It is reducing the amount of guessing AI has to do.

Data semantics help AI understand meaning.

Data relationships help AI understand connections.

Together, they provide the missing context required for reliable enterprise AI.

Because AI does not only need access to enterprise data.

It needs to understand the business behind it.

The Next Enterprise Data Platform Won't Be Built for Humans

Arisyn — Thu, 30 Jul 2026 14:22:00 +0000

For decades, enterprise data platforms were designed around one assumption:

Humans are the primary users of data.

Data engineers build pipelines.

Analysts explore datasets.

Business users consume dashboards.

Applications execute queries.

The entire data stack evolved around helping people find, transform, and analyze information.

But AI is becoming a new type of data consumer.

And it changes the requirements completely.

The next generation of enterprise data platforms won't only need to store and process data.

They will need to help machines understand it.

Traditional Data Platforms Were Built for Access

The evolution of enterprise data platforms has always focused on improving access.

First came relational databases.

The goal was reliable transaction processing.

Then data warehouses appeared.

The goal became centralized analytics.

Later, data lakes and lakehouses emerged.

The goal was to store massive amounts of structured and unstructured data.

Each generation solved important problems.

But they shared the same assumption:

Someone already understands the business meaning behind the data.

A data analyst knows which table contains the trusted revenue number.

A developer knows which customer table should be joined.

A business expert knows what "active customer" actually means.

The platform provides data.

Humans provide understanding.

AI Changes the Consumer of Data

AI systems work differently.

An analyst can ask a colleague:

"Which customer table should I use?"

An AI agent cannot.

A developer can remember:

"Never join these two tables directly."

An AI agent cannot.

A business user knows:

"Revenue means recognized revenue, not invoice amount."

An AI agent may not.

This creates a new architectural challenge.

Enterprise data platforms were built to answer:

Where is the data?

AI needs them to answer:

What does this data represent?

Schema Is Not Enough

Most AI systems start with metadata:

tables
columns
data types
relationships
descriptions

This information is useful.

But it only describes structure.

Consider a large enterprise with multiple systems:

CRM
 |
ERP
 |
Finance
 |
Supply Chain

Each system may contain customer information.

Each system may use different identifiers.

Each system may have different business purposes.

A human employee understands that these records may represent the same business entity.

A model looking only at schemas sees disconnected tables.

The missing information is not more data.

It is meaning.

The Future Data Platform Needs More Than Storage

If AI becomes a major consumer of enterprise data, future platforms need additional capabilities.

Business Entity Understanding

AI needs to understand important business objects:

Customer
Product
Supplier
Employee
Contract
Project

Not just as tables, but as real business concepts.

Relationship Understanding

Enterprise knowledge is often hidden in relationships.

A customer connects to orders.

Orders connect to invoices.

Invoices connect to payments.

These relationships are not always defined by foreign keys.

Many exist through business rules, historical decisions, and operational experience.

AI needs trusted relationships, not guessed joins.

Business Semantic Understanding

The same word can mean different things across departments.

"Revenue" for finance may differ from "sales" for operations.

"Customer" in marketing may differ from "customer" in accounting.

AI needs business definitions, not only column descriptions.

From Data Platform to AI-Ready Data Infrastructure

This does not mean replacing existing databases or warehouses.

Those systems remain essential.

The change is that enterprises need another layer on top of existing data.

A layer that connects:

Business Concepts

        ↓

Data Relationships

        ↓

Physical Data

        ↓

AI Applications

This layer helps AI move from retrieving information to understanding information.

The Next Competition Will Not Only Be About Models

Many organizations are investing heavily in:

larger models
faster inference
better agents
more powerful infrastructure

These improvements matter.

But model capability alone does not solve enterprise understanding.

Two companies can use the same AI model and achieve completely different results.

The difference is often not the model.

It is the quality of the enterprise knowledge behind the model.

Final Thoughts

For years, enterprise data platforms were optimized for humans.

Humans interpreted the meaning.

Humans connected the dots.

Humans resolved ambiguity.

AI changes that relationship.

The next generation of data platforms will not only answer:

"Where is the data?"

They will help answer:

"What does this data mean, how is it connected, and when can it be trusted?"

The future enterprise data platform is not just a place where data lives.

It is a foundation that allows AI to understand how the business works.

AI Didn't Break Enterprise Data Models. It Exposed Their Blind Spots.

Arisyn — Wed, 29 Jul 2026 15:09:00 +0000

Over the past few years, I've worked with several enterprise AI projects, especially those involving natural language querying and AI-powered analytics.

One pattern keeps showing up.

When an AI system returns the wrong answer, people usually blame the model.

"Maybe we need a larger LLM."

"Maybe the prompt needs more context."

"Maybe SQL generation isn't mature enough."

After digging into these projects, I came to a different conclusion.

In many cases, the model isn't the real problem.

The enterprise data model is.

Enterprise Data Models Were Never Designed for AI

For decades, enterprise databases have been optimized for applications.

Normalization reduces redundancy.

Indexes improve query performance.

Foreign keys maintain integrity.

Data warehouses organize information for reporting.

Everything makes sense because applications already know how the business works.

Business logic lives in source code, service layers, stored procedures, ETL pipelines, and developers' experience—not necessarily in the database itself.

Applications don't need the database to explain what a "customer" is.

Developers already know.

AI doesn't.

Schema Describes Structure, Not Meaning

Most AI systems start by reading metadata.

They can discover tables.

Columns.

Primary keys.

Sometimes foreign keys.

But metadata only tells AI how data is stored.

It doesn't explain what the data actually represents.

For example, imagine an enterprise with three different systems.

CRM stores customers.

ERP stores accounts.

The finance system stores billing entities.

To employees, these often represent the same business entity viewed from different business processes.

To AI, they are simply three unrelated tables.

Without additional business knowledge, every SQL statement becomes an educated guess.

The Hardest Problem Isn't Writing SQL

Modern language models are surprisingly good at generating SQL.

Syntax errors have become much less common.

The bigger challenge appears earlier.

Before generating SQL, AI must answer questions like:

Which customer table should I use?
Which data source is considered authoritative?
Are these two entities actually the same customer?
Which relationship reflects real business rules?

These aren't SQL problems.

They're knowledge problems.

Business Knowledge Lives Outside the Database

One thing I find interesting is that enterprise knowledge is rarely stored where AI can access it.

Developers understand join paths.

Business analysts understand metric definitions.

Database administrators understand physical schemas.

Domain experts understand the business process.

Each group holds part of the knowledge.

Very little of it is represented explicitly in the data model itself.

Humans bridge these gaps naturally.

AI cannot.

AI Has Become a New Consumer of Enterprise Data

This is probably the biggest architectural change we're seeing.

For years, applications were the only consumers of enterprise databases.

Now AI is becoming another consumer.

Unlike applications, AI doesn't read source code.

It doesn't attend design meetings.

It doesn't ask senior developers which table is "correct."

It only sees what the enterprise has documented.

And many enterprises have documented far less than they assumed.

The Future Isn't About Bigger Models

Large language models will continue to improve.

They'll write better SQL.

Reason more effectively.

Handle longer contexts.

But none of these improvements automatically provide business knowledge.

If an enterprise hasn't clearly defined its business entities, trusted relationships, or business semantics, AI has no reliable foundation to reason from.

The model can infer.

It can estimate.

It can guess.

It cannot know.

Final Thoughts

I don't think AI is exposing weaknesses in language models.

It's exposing weaknesses in enterprise data architecture.

For years, our data models were built to support applications.

Today, they also need to support AI.

That doesn't necessarily mean redesigning every database.

But it does mean making business entities, relationships, and business semantics far more explicit than they have been in the past.

The smarter AI becomes, the more valuable well-structured enterprise knowledge will be.

Your AI Tool Can Query the Database. That Doesn't Mean It Understands the Data.

Arisyn — Mon, 20 Jul 2026 18:16:00 +0000

Most AI integrations with enterprise databases look impressive in a demo.

Connect a model.

Expose the schema.

Ask a question.

Generate SQL.

Run the query.

The hard part appears to be solved.

But once the system reaches real enterprise data, the weaknesses show up quickly.

The model can access the database. It still does not know how the business works.

A Schema Is Not a Data Model

Suppose an AI tool sees these tables:

crm_customer
customer_master
customer_profile
dim_customer

From the schema alone, all four look relevant.

A developer who knows the system may understand that:

customer_master is the authoritative source
crm_customer only contains sales activity
customer_profile is incomplete
dim_customer is prepared specifically for reporting

The model does not know any of that.

It can inspect names, types, constraints, and sample values. It may even generate valid SQL.

But valid SQL is not the same as correct business logic.

Foreign Keys Do Not Tell the Whole Story

Database relationships are often treated as a solved problem because relational databases support foreign keys.

In practice, enterprise data is much messier.

Some relationships are enforced in the database.

Others exist only in ETL code.

Some cross system boundaries.

Some rely on composite keys.

Others use fields with different names but matching values.

A real query might need to move through:

Customer
  -> Order
  -> Invoice
  -> Payment

There may be several technically possible paths.

Only one may match the reporting logic used by Finance.

That choice cannot be recovered reliably from table names alone.

More Tools Do Not Fix Missing Relationships

Adding another AI assistant does not solve this.

Neither does switching to a stronger model.

A better model may produce cleaner SQL, but it still has to decide:

which tables belong together
which join path is trusted
whether a relationship is one-to-one or one-to-many
whether joining two tables will duplicate records
whether two fields represent the same business entity

These are data relationship questions.

They need to be discovered, validated, maintained, and made reusable.

That is the role of a relationship layer, not another prompt.

Platforms such as Arisyn-IntaLink focus on discovering table-level and field-level relationships, evaluating possible links, and exposing usable relationship paths for downstream analytics and AI systems.

Meaning Is a Separate Problem

Even with the correct join path, the result can still be wrong.

Consider the word revenue.

It could mean:

SUM(invoice_amount)

or:

SUM(payment_amount)

or:

SUM(invoice_amount - refunds)

All three queries may execute successfully.

Only one may match the company’s official definition.

This is why business semantics must be managed separately from physical relationships.

A semantic layer defines terms, metrics, dimensions, mappings, and calculation rules so the same business question does not produce a different interpretation every time.

Arisyn-Semora is designed around this layer: managing business definitions and their mappings to underlying data, then using them during query generation and validation.

What a Reliable Query Flow Looks Like

A more dependable enterprise query flow looks something like this:

Business Question
      |
      v
Resolve Business Meaning
      |
      v
Identify Relevant Entities
      |
      v
Select Trusted Relationships
      |
      v
Generate SQL
      |
      v
Validate and Execute

SQL generation comes near the end.

Most failures happen earlier.

The wrong metric may be selected.

The wrong customer entity may be used.

A technically valid but untrusted join may be chosen.

By the time the SQL is generated, the answer is already heading in the wrong direction.

What Enterprise AI Actually Needs

Enterprise AI does not need an endless supply of new database tools.

It needs a more explicit representation of two things engineers already carry in their heads:

how enterprise data is connected
what enterprise data means

The first problem is about relationships.

The second is about semantics.

Both need to be governed.

Both need to be reusable.

And both need to be available before SQL generation begins.

Final Thoughts

The most visible part of enterprise AI is often the model.

The most important part may be everything underneath it.

Once relationships and semantics are governed, AI has far less room to guess.

And in production data systems, reducing guesswork matters more than generating SQL a little faster.

Text-to-SQL Penetration Tops 30%: How Enterprises Build Trusted NL2SQL Deployment Frameworks

Arisyn — Wed, 08 Jul 2026 18:32:00 +0000

A recent industry report on intelligent BI reveals that Text-to-SQL (NL2SQL) technology has now exceeded 30% penetration among mid-sized and large enterprises in BI analytics. For every three organizations, one is experimenting with natural language queries to replace manual SQL writing, aiming to lower data access barriers and empower business teams with self-service analytics. But beneath this promising adoption rate lies a frustrating reality: many enterprises hit a wall after successful pilots, struggling to scale NL2SQL across the business. Issues like occasional logical errors in generated SQL, misalignment between business terminology and data semantics leading to inaccurate results, and untraceable query processes that leave users hesitant to trust outputs all point to a critical bottleneck: the lack of a trusted NL2SQL deployment framework.

The Trend: From Pilot Promise to Scaling Pain

The rapid rise of NL2SQL is a direct response to the growing demands of enterprise digital transformation. Traditional BI workflows force business users to rely on data engineering teams to write SQL queries, resulting in response cycles that stretch days or even weeks. Miscommunication between business stakeholders and data teams often leads to outputs that don’t match intended requirements, undermining the value of data-driven decision-making. NL2SQL promises to revolutionize this by letting users ask questions like, “What’s the conversion rate for new users in East China this month?” in plain language, theoretically cutting analysis time by a factor of several.

Yet the 30% penetration figure masks a gap between pilot success and scalable adoption. Most enterprises limit NL2SQL to single business scenarios or small teams; fewer than 10% have rolled it out across all departments. A survey found that over 60% of business users report “not trusting NL2SQL-generated results,” with core concerns centered on accuracy and interpretability. This makes clear that NL2SQL deployment can’t stop at “generating SQL”—it must prioritize building confidence in the reliability of outputs and the transparency of the process.

Enterprise Challenges: The Three Barriers to Trust

To understand why scaling NL2SQL is so hard, we need to unpack three core pain points that erode user trust:

First, the semantic alignment gap. The chasm between business language and data language is NL2SQL’s first major hurdle. For example, the marketing team might define a “new user” as someone who placed their first order, while the operations team uses the term to refer to registered users who haven’t placed an order within seven days. Similarly, “user activity” could mean weekly logins ≥3 for one department, or daily session duration ≥10 minutes for another. When NL2SQL fails to recognize these nuanced business definitions, it generates SQL queries that pull the wrong data, leading to misleading results.

Second, the lack of SQL validation. Even when semantics are aligned, AI-generated SQL can contain hidden flaws: incorrect table joins that cause Cartesian products (inflating data volumes), full-table scans that cripple database performance, or unauthorized access to sensitive data that violates compliance policies. Without a way to catch these issues before execution, NL2SQL not only delivers bad results but also poses risks to data security and system stability.

Third, the opacity of query reasoning. When business users receive a result from NL2SQL, they often have no visibility into which tables or fields the data came from, or how the AI translated their natural language question into SQL. If the result contradicts expectations, neither the user nor the data team can quickly diagnose the root cause—forcing them to revert to manual SQL writing, negating all efficiency gains from NL2SQL.

Compounding these issues is the disconnect between data governance and intelligent analysis. Incomplete metadata, unclear table relationships, and inconsistent metric definitions mean NL2SQL lacks a reliable “data dictionary” to base its queries on, making accurate SQL generation nearly impossible.

Technical Interpretation: Building a Trusted Framework

Building a trusted NL2SQL system requires a closed-loop framework that addresses these pain points across three key layers:

Unified Semantic Mapping Layer: This is the foundation for accurate natural language understanding. It requires standardizing the mapping between business terms, data fields, metric definitions, and table relationships—effectively translating business language into data language. This isn’t just about AI semantic understanding; it must integrate with enterprise business rules and existing data governance efforts to avoid the “generalization errors” that come with generic AI models.
Full-Cycle SQL Validation Mechanism: After generating SQL, the system must run multi-dimensional checks: logical validation to ensure table joins align with business rules and data relationships, performance validation to avoid inefficient queries like full-table scans, and permission validation to ensure users only access data they’re authorized to view. Only queries that pass all checks should be executed.
Traceable Reasoning Visualization: Users need visibility into the entire path from natural language question to SQL query. This includes how the AI identified business terms in the question, mapped them to specific data assets, built filtering and aggregation logic, and even the data lineage of the final result. Transparency here is key to building user trust, as it allows quick debugging when results are unexpected.

Underpinning all three layers is a robust metadata governance base. Without clear, consistent metadata—including table relationships, field meanings, and standardized metrics—semantic mapping and SQL generation will lack reliable ground truth.

How Intalink and Arisyn Enable Trusted NL2SQL Deployment

Intalink and Arisyn provide a cohesive solution to build this trusted NL2SQL framework, combining a solid metadata governance base with an advanced semantic engine:

Intalink serves as the data relationship foundation, automating metadata management, relationship discovery, and lineage analysis to build a comprehensive data asset graph. For example, it can automatically identify the foreign key relationship between a “user table” and an “order table,” and document the calculation logic for metrics like “new user conversion rate.” This bridges the gap between data governance and intelligent analysis, providing NL2SQL with the accurate, consistent metadata it needs to operate reliably.

Building on Intalink’s metadata foundation, Arisyn’s Semora structured data semantic engine addresses the core pain points of NL2SQL deployment:

Dual Semantic Layer Governance: It enables enterprises to bind business terms directly to metadata assets. For instance, marketing’s definition of “new user” (first-time order placer) can be mapped to the “first_order_date” field in the order table, ensuring the AI interprets the term correctly regardless of departmental context.
Multi-Dimensional SQL Validation: After generating SQL, Semora automatically runs logical checks against Intalink’s documented table relationships, performance checks to optimize query efficiency, and permission checks aligned with enterprise access policies. It also supports multi-step reasoning for complex business questions, breaking them into sequential SQL queries and validating each step to ensure accuracy.
Visual Reasoning Traceability: Semora provides a clear, visual breakdown of the query process. Users can see how their natural language question was parsed into semantic units, each unit’s mapping to data fields, the logic behind SQL generation, and the data lineage of the final result. This transparency lets users quickly identify issues if results are off, building confidence in the system’s outputs.

Conclusion: Trust is the Key to Scaling NL2SQL

As Text-to-SQL penetration crosses the 30% threshold, enterprises are shifting their focus from “whether to adopt NL2SQL” to “how to scale it effectively.” Trust is the linchpin of this transition: only when business users feel confident in the accuracy of results and the transparency of the process will NL2SQL move beyond pilot projects to become a core tool for daily analytics.

The combination of Intalink’s metadata governance base and Arisyn’s Semora semantic engine provides a viable path to building a trusted NL2SQL deployment framework. By unifying metadata, aligning business and data semantics, validating SQL generation, and making query reasoning transparent, this solution breaks the “pilot success, scale failure” cycle. It empowers enterprises to turn NL2SQL from a promising experiment into a reliable, scalable tool that lowers data barriers, accelerates self-service analytics, and drives faster, more confident data-driven decisions.

Stop Building AI Agents Like Standalone Applications

Arisyn — Mon, 06 Jul 2026 03:01:32 +0000

Over the past few months, I've experimented with quite a few enterprise AI projects.

One thing has become obvious.

Most teams are still building AI agents the same way they used to build web applications.

Every new use case becomes another agent.

Another prompt.

Another knowledge base.

Another API integration.

It works at first.

But it doesn't scale.

Every Agent Starts Solving the Same Problems

Imagine a company with ten AI agents.

One helps Sales.

One supports Finance.

Another assists HR.

Another generates weekly reports.

They look different from the outside, but internally they're solving many of the same problems.

Each needs:

authentication
permission control
business definitions
access to enterprise data
shared documents
tools
monitoring

Yet many teams implement these capabilities over and over again.

The result is duplicated logic that becomes harder to maintain every month.

*We Already Solved This Problem in Software Engineering
*
Traditional applications rarely implement infrastructure from scratch anymore.

Authentication is shared.

Logging is shared.

Monitoring is shared.

Configuration is shared.

Developers focus on business logic because the platform provides the rest.

I think AI engineering is heading toward the same architecture.

Agents shouldn't own everything themselves.

They should consume shared platform capabilities.

What Should Live Outside the Agent?

When I look at enterprise AI systems, I increasingly think the agent should remain lightweight.

Instead of embedding everything inside prompts, I'd rather separate responsibilities.

For example:

Context Service

Responsible for business definitions, trusted datasets, and reusable organizational knowledge.

Tool Registry

A single place where agents discover available APIs, SQL tools, search services, and enterprise systems.

Permission Layer

Every agent follows the same access policies instead of implementing its own authorization rules.

Memory Service

Shared long-term memory instead of isolated conversation histories.

Observability

One dashboard to understand how agents are performing, what tools they're calling, and where failures occur.

None of these capabilities belong inside an individual agent.

They're platform concerns.

Keep Agents Small

One lesson I've learned is that smaller agents are usually easier to improve.

When an agent focuses on a single responsibility, it's easier to test, debug, and replace.

The shared platform handles everything else.

Instead of creating increasingly complex prompts, we should be investing in better infrastructure.

The more reusable the platform becomes, the simpler every new agent is to build.

A Different Mental Model

I no longer think of an AI agent as an application.

I think of it as a runtime component.

It receives a task.

It requests context.

It discovers available tools.

It checks permissions.

It completes the work.

Most of the intelligence isn't inside the agent itself.

It's distributed across the platform supporting it.

Final Thoughts

Right now, building an AI agent has become surprisingly easy.

Operating dozens—or eventually hundreds—of them inside an enterprise won't be.

The organizations that move fastest won't necessarily build more agents.

They'll build better platforms for those agents to run on.

To me, that's where enterprise AI engineering is heading next.

From Promise to Reliability: Semantic Mapping and SQL Validation as Dual Drivers for Enterprise NL2SQL Success

Arisyn — Fri, 03 Jul 2026 14:47:00 +0000

A marketing manager at a fast-growing consumer packaged goods (CPG) company needs to understand the repeat conversion rate of new customers in East China during Q3. Historically, this would mean drafting a detailed request, sending it to the data team, and waiting 1-2 days for a response. Today, with an NL2SQL tool deployed, they type their question directly into the platform and get an instant SQL query—at least in theory. When they run the query, however, the results are useless: the tool defined “new customers” as users registered within 7 days, while the company’s standardized definition is users who placed their first order in the last 30 days. This disconnect between natural language intent and data reality is not an isolated incident; it’s a core pain point plaguing enterprises that have adopted NL2SQL to enable self-service business intelligence (BI).

As enterprise data volumes explode and business teams demand real-time insights to stay competitive, traditional BI workflows—reliant on data teams to model datasets and write custom SQL—have become a bottleneck. NL2SQL (Natural Language to SQL) emerged as a promising solution, allowing non-technical users to query data warehouses using everyday language, reducing dependency on overstretched data teams and accelerating decision-making. According to industry research, nearly 60% of mid-to-large enterprises are now piloting or deploying NL2SQL tools. Yet, more than 40% report critical issues with accuracy and semantic alignment, leaving business users hesitant to trust the tool’s outputs. This gap highlights deeper enterprise challenges: disconnected data relationships across silos, inconsistent business metric definitions, a widening rift between data governance investments and AI-driven analysis, and AI workflows that fail to access trusted, context-rich data.

Core Pain Points of Enterprise NL2SQL Adoption

The failure of NL2SQL tools to deliver on their promise stems from three interconnected challenges:

First, semantic alignment gaps between business and data layers. Enterprises develop standardized business terminology—like “new customer,” “repeat rate,” or “monthly active users”—with nuanced definitions tailored to their operations. However, these terms exist in a human-readable context, while data warehouses store information in tables, fields, and relational structures that machines understand. Without a deliberate bridge between these two worlds, NL2SQL tools often misinterpret intent: for example, conflating “monthly active users” with “monthly registered users” or applying the wrong aggregation logic to calculate “customer retention.” This leads to “answer the wrong question” scenarios that erode user trust.

Second, SQL generation inaccuracy due to lack of validation. Many NL2SQL tools focus solely on translating natural language to SQL syntax, skipping critical checks for logical and business correctness. This results in queries that either fail to run or produce misleading results: joining order tables with unrelated product category tables, summing non-numeric fields like customer IDs, or applying average calculations to categorical data. Even small errors in table joins or metric logic can render insights useless, forcing business users to cross-verify results with data teams—undoing the efficiency gains of self-service BI.

Third, wasted data governance investments. Most enterprises have already invested in building semantic layers, metric systems, and governance frameworks to ensure data consistency. However, many NL2SQL tools operate in isolation, unable to reuse these existing assets. This means companies must rebuild their metric definitions from scratch for the NL2SQL tool, leading to redundant work, conflicting data outputs across BI platforms, and a breakdown in the unified data governance strategy they worked hard to establish.

The Dual-Wheel Solution: Semantic Mapping + SQL Validation

To address these pain points, enterprises need a two-pronged approach that connects business intent to trusted data and validates every step of the SQL generation process.

At the core, semantic mapping serves as the bridge between business and data semantics. Business semantics are the standardized terms and metrics that teams use to discuss performance—e.g., “new customer” defined as “users who placed their first order in the query period.” Data semantics are the underlying tables, fields, lineage relationships, and calculation logic stored in the data warehouse. Effective semantic mapping requires a robust metadata foundation to understand data relationships, paired with a semantic engine that can translate between human language and machine-readable data structures.

SQL validation, meanwhile, acts as a safety net to ensure generated queries are not just syntactically correct but logically sound and aligned with business rules. This requires three layers of checks: syntax validation to confirm compatibility with the target database; logical validation to verify table joins, field types, and aggregation functions are appropriate; and business validation to ensure the query adheres to standardized metric definitions and operational constraints.

How Arisyn and Intalink Enable Reliable NL2SQL

Intalink, as a data relationship and governance base, lays the groundwork for trusted NL2SQL by building a comprehensive data semantic layer. It automates metadata management, discovers hidden table relationships, maps field lineage, and formalizes enterprise-wide metric definitions. For the CPG example, Intalink would codify “new customer” as users with a first order timestamp within the Q3 window, and “repeat conversion rate” as the count of users who placed a second order divided by the total number of new customers. This creates a single source of truth for data semantics, ensuring consistency across all analysis tools.

Building on this foundation, Arisyn’s Semora structured data semantic engine enables bidirectional semantic mapping. On one side, it translates natural language questions into precise data logic by matching user queries to pre-defined business terms in the Intalink-managed semantic layer. On the other side, it converts data warehouse metrics into business-friendly language, making it easier for teams to understand and trust the underlying data.

Semora also integrates a multi-layer SQL validation framework that closes the loop on accuracy. When the CPG marketing manager asks about Q3 East China new customer repeat conversion rate, Semora first maps the query to the enterprise’s standardized definitions. It then generates the corresponding SQL and runs three checks: syntax validation to ensure compatibility with the company’s data warehouse; logical validation to confirm the join between the user and order tables is correct and that the aggregation function for conversion rate uses numeric fields; and business validation to verify the “new customer” filter aligns with the 30-day first-order rule. If any discrepancy is found, Semora adjusts the SQL to meet business standards before executing the query, delivering results that match the user’s intent.

Crucially, Semora integrates seamlessly with existing enterprise semantic layers, allowing companies to reuse their prior governance investments. This eliminates redundant work, ensures metric consistency across traditional BI tools and NL2SQL workflows, and closes the gap between data governance and AI-driven analysis.

Conclusion: Moving from “Usable” to “Trusted” NL2SQL

NL2SQL’s true value lies not in generating SQL quickly, but in generating SQL that produces accurate, business-aligned results. Semantic mapping solves the core challenge of translating human intent into machine-readable data logic, while SQL validation ensures every query adheres to technical and business standards. Together, these two drivers create a reliable self-service BI experience that business users can trust.

The combination of Intalink’s data governance base and Arisyn’s Semora semantic engine addresses the root causes of NL2SQL adoption pain points: it bridges the gap between business and data semantics, validates query accuracy at every step, and leverages existing governance assets. By enabling this dual-wheel approach, enterprises can unlock the full potential of NL2SQL, empowering business teams to access trusted insights independently, reducing data team bottlenecks, and turning their data assets into a competitive advantage.

Redefining Team Roles in the AI Era: How Data Intelligence Tools Enable New Talent Structures—Insights from the Creator of Claude Code

Arisyn — Tue, 30 Jun 2026 15:33:00 +0000

In a recent interview, the creator of Claude Code shared a striking observation about modern enterprise teams: the once rigid lines separating engineers, product managers, and designers are rapidly blurring. Product managers now write SQL to validate demand hypotheses on their own; designers leverage analytics to pinpoint user pain points with precision; engineers use prompt engineering to build prototypes in hours rather than weeks. This shift isn’t just a trend—it’s a fundamental restructuring of how organizations allocate talent and leverage skills, driven by the democratizing power of AI. Yet for most enterprises, this transition is far from seamless. Disconnected data relationships, inaccessible analytics tools, and a growing gap between data governance and AI-driven analysis are creating invisible barriers to effective cross-functional collaboration.

From Specialized Silos to Cross-Functional Synergy: The AI-Driven Talent Shift

The move from deep specialization to cross-functional capability is most pronounced in data-centric teams. For decades, data operations followed a strict pyramid structure: data engineers built and maintained data warehouses, data governance specialists manually curated metadata and lineage, data analysts churned out predefined reports, and business teams waited passively for insights to trickle down. Today, that model is obsolete. Business stakeholders demand direct access to data to inform real-time decisions; governance teams need to adapt quickly to evolving business metric requirements; data analysts are shifting from report generators to strategic advisors who translate data into actionable business strategy.

This role evolution stems from AI’s ability to lower technical barriers. Tools like generative AI and natural language processing (NLP) enable non-technical users to perform tasks once reserved for specialists. A marketing operations manager, for example, can now analyze user behavior data to optimize campaign performance without relying on the data team. Conversely, specialized roles like data governance are being elevated: instead of spending weeks manually mapping table relationships, these professionals can focus on ensuring data quality, standardizing metric definitions, and unlocking the strategic value of data assets.

Core Challenges in the New Talent Landscape

Despite this shift, most organizations are stuck in a gap between rising capability demands and inadequate tooling. Three critical pain points stand out:

First, data access remains prohibitively difficult for non-technical users. Business teams often lack the SQL skills or understanding of complex data warehouse schemas to answer even simple questions—like “What was the new user conversion rate in the South China region last month?” The result is a back-and-forth with data teams that can take 24 hours or longer, causing delays that miss critical decision windows.

Second, data governance is inefficient and error-prone. Governance teams face hundreds of tables and thousands of fields, manually mapping lineage and resolving metric discrepancies that can take weeks. This manual work leads to costly inconsistencies: one retail enterprise found that different departments reported user growth figures varying by 30%, undermining trust in data and slowing cross-team alignment.

Third, there’s a critical disconnect between data governance and AI-driven analysis. Many organizations invest heavily in governance initiatives, yet the curated metadata and relationship graphs remain locked in siloed tools, inaccessible to the analysis platforms business teams use. Meanwhile, generic AI tools can generate plausible-sounding insights but lack access to internal, trusted data, rendering their outputs irrelevant for enterprise decision-making.

The Technical Foundation: Dual-Wheel Architecture for New Teams

To overcome these challenges, organizations need a dual-wheel architecture that combines a robust data relationship foundation with an intuitive intelligent analysis entry point.

On one side, a trusted data relationship base is essential. This requires automated metadata management and lineage analysis to map table connections, field origins, and metric definitions across all data sources, creating a unified, visual data asset graph. This foundation ensures that all users—from governance specialists to business teams—have a clear, consistent view of data relationships and definitions, eliminating confusion and building trust.

On the other side, an intelligent analysis entry point lowers the barrier to data access. Natural language to SQL (NL2SQL) conversion, paired with dual semantic layer governance, lets business users query data using plain language, bridging the gap between business terminology and technical field names. This entry point must also support multi-step reasoning, enabling users to answer complex questions that require integrating data across multiple sources.

Crucially, these two components must work in tandem: the data relationship base provides the trusted, structured data that makes intelligent analysis accurate, while insights generated from the analysis entry point feed back into governance processes, helping teams refine metric definitions and improve data quality over time.

Intalink and Arisyn: Enabling the New Talent Ecosystem

Intalink and Arisyn are designed to deliver this dual-wheel architecture, supporting the new talent structures emerging in the AI era.

Intalink serves as the data relationship governance foundation, addressing the core pain points of data governance teams. It automatically scans enterprise data sources—from data warehouses to cloud databases—identifying table relationships, field lineage, and metric discrepancies to generate a visual, real-time metadata graph. For example, a retail enterprise’s governance team previously took 10 days to map lineage across its omnichannel user data; with Intalink, this process takes just 4 hours, with an accuracy rate of 98%. Intalink also enables real-time metadata synchronization via API integrations and task scheduling, ensuring governance teams can adapt quickly to changing business needs without manual effort.

Built on Intalink’s trusted foundation, Arisyn provides an intelligent analysis entry point for non-technical business users and analysts alike. Its natural language query functionality lets users ask questions like “What were the top 3 reasons for declining user retention in East China during Q3?” and receive structured, data-backed answers without writing SQL. Arisyn’s dual semantic layer unifies business terminology (like “new user”) with technical field names across systems, eliminating confusion about metric definitions. Its multi-step reasoning and workflow orchestration capabilities can integrate data from multiple sources—user behavior, orders, marketing campaigns—to deliver holistic insights. Most importantly, Arisyn leverages Intalink’s governed data, ensuring that every insight is based on trusted, consistent information.

Together, these tools enable a seamless transition to the new talent model: data governance teams evolve from manual data curators to data asset managers, focusing on optimizing data quality and aligning metrics with business goals; business users shift from passive data requesters to active data users, empowering them to make real-time decisions; data analysts move from report producers to strategy advisors, using their expertise to interpret insights and guide business strategy.

Conclusion: Empowering Roles to Focus on Value

AI isn’t eliminating job roles—it’s redefining them, allowing every team member to focus on the high-value work that aligns with their core expertise. The role of data intelligence tools is to break down the barriers between technical and business teams, making data a universal capability rather than a specialized skill. Intalink provides the trusted, clear data foundation that ensures consistency and trust, while Arisyn makes that data accessible and actionable for everyone. Together, they create a framework that supports the cross-functional collaboration and role evolution needed to thrive in the AI era. For enterprises looking to stay competitive, the key isn’t just adopting AI—it’s using the right tools to empower their people to work smarter, not harder.

Why NL2SQL Fails in Enterprise Deployments? Semantic Mapping and Query Validation Are the Keys to Success

Arisyn — Thu, 25 Jun 2026 16:17:00 +0000

Imagine a marketing team eager to answer a critical question: “What’s the monthly average revenue from new customers in East China during Q3?” Instead of waiting days for the data team to run a custom SQL query, they turn to their new NL2SQL tool—only to get either a “query unrecognizable” error or a result that contradicts their internal financial reports. This isn’t an isolated incident: a recent authoritative industry survey reveals that over 90% of enterprise NL2SQL deployments stall or deliver results far below expectations, forcing business teams to fall back on traditional, slow data request workflows. NL2SQL, once hailed as the solution to democratize data access, is failing to live up to its promise in real-world enterprise environments. Why is this happening, and how can organizations turn the tide?

At its core, NL2SQL aims to eliminate the technical barrier between non-technical business users and structured data. By translating natural language questions into executable SQL queries, it promises to reduce data team backlogs, accelerate decision-making, and empower every employee to leverage data for insights. In controlled lab environments, state-of-the-art NL2SQL models boast accuracy rates above 90%. But when deployed in enterprise settings, these models hit a wall. Enterprises face a perfect storm of challenges: heterogeneous data sources scattered across warehouses, lakes, and legacy systems; conflicting metric definitions across departments (e.g., “revenue” might mean gross sales to sales teams and net income to finance); and complex, undocumented table relationships that even seasoned data engineers struggle to navigate. These real-world complexities leave NL2SQL models unable to accurately interpret business intent, let alone generate reliable queries.

Beneath the survey numbers lie two fundamental, interconnected pain points that derail NL2SQL deployments:

The Semantic Gap: Misalignment Between Business and Data Language

Business teams speak in intuitive terms like “active users,” “new customers,” and “regional revenue”—but these terms rarely map directly to the technical nomenclature of enterprise data systems. For example, “active users” might be defined as users who logged in in the last 7 days by the product team, but as users who made a purchase in the last 30 days by the sales team. Data tables and fields often carry technical labels like user_behavior_log or order_pay_amount, which bear no obvious relation to business terminology. NL2SQL models relying solely on word vector matching lack the context to resolve these ambiguities, leading to either unrecognized queries or incorrect mappings. Worse, scattered data assets mean models can’t even identify which tables or fields are relevant to a given question, leaving business users stuck.

Lack of Trust: Unvalidated SQL Queries Undermine Confidence

Even when an NL2SQL model generates syntactically correct SQL, the query may contain logical flaws that render results useless. Common issues include joining tables with no meaningful data lineage, omitting critical business filters (like excluding test orders), or miscalculating metrics by using the wrong field. These errors can’t be caught by basic syntax checks, but they lead to results that are wildly off-target. Most off-the-shelf NL2SQL tools stop at generating SQL, offering no built-in validation mechanisms. As a result, business users can’t trust the output and end up sending queries to data teams for verification—adding extra work instead of reducing it.

To overcome these challenges, NL2SQL deployments need more than a powerful language model; they require a closed-loop system that integrates data governance and semantic engineering. The solution hinges on two critical components:

Building a Dual Semantic Layer for Precise Alignment

Semantic mapping is the bridge between business language and data language. It starts with a comprehensive inventory of enterprise data assets: using metadata management tools to catalog tables, fields, table relationships, and data lineage. This creates a clear, structured view of the data landscape, turning a “black box” into an understandable asset. On top of this, organizations need a business semantic layer that ties common business terms to specific data logic. For example, “new customers” might be defined as users with their first order in the last 30 days, linked to the users and orders tables with specific filters and joins. This layer codifies metric definitions, time ranges, and dimension rules, giving NL2SQL models the context they need to interpret business intent accurately.

Multi-Level SQL Validation to Ensure Result Reliability

Validation is the final guardrail to ensure query results are trustworthy. It must happen at three levels:

Syntax Validation: The basic check to ensure the generated SQL is syntactically correct and executable.
Logic Validation: Using data lineage and business rules to verify that the query aligns with predefined standards. This includes checking if table joins are based on valid relationships, filters match business requirements, and metric calculations adhere to approved definitions.
Result Validation: Post-execution checks to ensure the output makes sense in a business context. This might involve comparing results to historical data to identify abnormal fluctuations, verifying numerical ranges against business norms, or cross-referencing with trusted metrics.

Arisyn and Intalink work in tandem to address these pain points, creating a seamless NL2SQL deployment loop tailored to enterprise needs.

Intalink serves as the foundational data relationship platform, addressing the root of data chaos. Its metadata management, relationship discovery, and lineage analysis capabilities automatically scan and catalog scattered data assets across systems, mapping table relationships, field dependencies, and metric lineage. This turns unstructured data silos into a unified, governed data graph, making it easy to understand how data connects and flows through the organization.

Building on Intalink’s governed foundation, Arisyn’s Semora semantic engine constructs a dual semantic layer that bridges business and data language. It allows organizations to map business terms directly to Intalink’s cataloged assets, codifying custom metric definitions and business rules. This gives Arisyn’s NL2SQL model the context to accurately interpret nuanced business questions—like distinguishing between product team and sales team definitions of “active users.”

When a business user submits a query, Arisyn first parses the natural language to extract business intent, using the dual semantic layer to resolve ambiguities. It then leverages Intalink’s data relationship graph to generate SQL that joins the correct tables, applies the right filters, and calculates metrics according to approved definitions. Before executing the query, Arisyn uses Intalink’s lineage data to perform logic validation: ensuring joins are based on valid relationships and metrics align with predefined rules. After generating results, Arisyn runs result validation checks—comparing outputs to historical trends and business norms—to flag any anomalies.

For example, when a marketing user asks, “What’s the monthly average revenue from new customers in East China during Q3?” Arisyn first uses the semantic layer to define “new customers” as users with their first order in Q3, “East China” as a specific set of region codes, and “monthly average revenue” as grouped monthly calculations. It then uses Intalink’s table relationships to connect the users, orders, and regions tables, generating the correct SQL. Next, it validates that the SQL adheres to the new customer definition and uses valid table joins. Finally, it checks the result against Q2’s East China new customer revenue to ensure fluctuations are within expected ranges before delivering the answer to the user.

NL2SQL’s failure in enterprise deployments isn’t a failure of AI technology—it’s a failure to account for the messy, complex reality of enterprise data and business semantics. To make NL2SQL work, organizations need a systematic approach that combines robust data governance with semantic engineering. Semantic mapping solves the problem of “can the AI understand the request?” while query validation solves “can we trust the result?”

Arisyn and Intalink’s integrated solution creates a complete closed loop: from cataloging and governing data assets to building business-aligned semantic layers, generating context-aware SQL, and validating results for reliability. This breaks the bottlenecks that have stalled NL2SQL deployments, enabling true AI-powered self-service analytics that empowers business teams, reduces data team burdens, and unlocks the full value of enterprise data to drive faster, more informed decisions.

Gartner Trend Decoded: How NL2SQL Solves Enterprise Self-Service Analytics’ Three Core Pain Points

Arisyn — Mon, 22 Jun 2026 15:55:00 +0000

Gartner’s latest analysis positions NL2SQL as a cornerstone for lowering data access barriers and accelerating business intelligence (BI) efficiency. Over 60% of mid-sized enterprises plan to deploy NL2SQL solutions this year, with the goal of reducing data engineers’ repetitive query work by 80% or more. Yet for many organizations, NL2SQL remains a case of “looks good on paper, hard to implement in practice.” The gap between promise and reality stems from three unaddressed pain points that hinder meaningful self-service analytics.

The Three Core Pain Points of Enterprise Self-Service Analytics

1. Technical Barriers: The “Query Dependency Trap”
The first and most obvious hurdle is the technical divide between business users and structured data. Most non-technical teams lack SQL proficiency, forcing them to rely on data engineers for even basic query requests. This creates a cycle of backlogs: A manufacturing enterprise’s data team, for example, handles over 500 routine query tickets monthly, with an average response time of 24 hours. Data engineers are stuck prioritizing low-value, repetitive tasks instead of focusing on high-impact work like predictive modeling or data strategy, while business teams wait days for insights that could inform time-sensitive market decisions. This model fails to break down the walls between data and decision-makers, leaving democratized analytics out of reach.

2. Semantic Misalignment: The Business Term vs. Data Field Gap
A more insidious challenge is the disconnect between business terminology and underlying data structures. Enterprises often suffer from inconsistent metric definitions across departments: For instance, the operations team might define “active users” as anyone who logged into the app in a day, while the marketing team defines it as users who clicked an ad. Generic NL2SQL tools rely on literal keyword matching, which cannot distinguish these nuanced semantic differences. The result? Queries generate results that are technically correct but irrelevant to the business user’s actual need. In one case, a retail brand’s sales team used a generic NL2SQL tool to pull “monthly active customers,” only to discover the tool used the marketing department’s definition—leading to a 40% overcount and conflicting quarterly performance reports between teams. This misalignment stems from the absence of a unified business semantic governance framework.

3. SQL Accuracy: The Reliability Risk of Complex Queries
Finally, traditional NL2SQL tools struggle with the accuracy of complex queries involving multi-table joins, nested aggregations, or time-window calculations. Generic large language models (LLMs) often generate SQL that looks correct but contains hidden errors: incorrect join conditions, misapplied aggregation functions, or unauthorized data access. A grocery chain recently tested a popular generic AI tool to generate a query for “repeat buyers in the Southeast region over the past quarter.” The tool incorrectly linked customer profiles to duplicate order entries, resulting in a 3x overcount of repeat users. This error nearly led the chain to overstock high-demand items, risking significant inventory costs. For enterprises, such “plausible but wrong” SQL poses a direct threat to data-driven decision-making.

Breaking the Cycle: NL2SQL Needs a “Governance + Semantics” Foundation

Gartner emphasizes that NL2SQL success depends on more than just AI-generated text—it requires two critical pillars: a robust data governance base that clarifies data relationships, structures, and permissions; and a semantic engine that bridges business terminology to underlying data fields. Without these, NL2SQL becomes a “broken pipe”: AI generates SQL, but it lacks context about how data connects or what business terms actually mean.

This is where the combination of Intalink and Arisyn’s Semora semantic engine delivers tangible value. Intalink provides the trusted data governance foundation, while Semora builds the semantic layer that translates natural language queries into accurate, business-aligned SQL. Together, they address each of the three core pain points head-on.

Intalink + Arisyn: Targeted Solutions for NL2SQL Success

1. Lowering Technical Barriers: Letting Business Users “Talk” to Data
Arisyn’s natural language query capabilities eliminate the need for business users to learn SQL. Instead, they can pose questions in plain business language—“Show me 30-day repeat user counts for East China retail stores”—and get immediate results. Behind the scenes, Intalink’s metadata management, relationship discovery, and lineage analysis provide Semora with a comprehensive map of the enterprise’s data ecosystem: from table structures and field definitions to cross-table relationships and data flow paths. Semora uses this map to quickly identify the relevant tables, join them correctly, and generate SQL that aligns with the user’s intent. This reduces data team backlogs by shifting routine queries to business users, freeing engineers to focus on strategic work while accelerating decision-making.

2. Solving Semantic Misalignment: Building a Unified Business Language
Arisyn’s dual semantic layer governance mechanism resolves the gap between business terms and data fields by creating a centralized, agreed-upon definition for every metric. For example, an enterprise can standardize “active users” as “users who logged into the app and completed at least one interaction in a 24-hour period.” Semora automatically maps all queries involving this term to the corresponding user behavior tables and fields, eliminating ambiguity across departments. Intalink’s lineage analysis adds an extra layer of trust: it tracks the calculation logic behind every metric, so users can verify how a result was derived, ensuring consistency and traceability. This unified semantic framework ensures that all teams work from the same data “playbook,” reducing conflicts and improving data reliability.

3. Ensuring SQL Accuracy: Multi-Layer Validation for Trusted Results
Semora’s NL2SQL generation and validation process goes beyond basic LLM output to ensure accuracy, security, and efficiency. After generating an initial SQL query, Semora leverages Intalink’s data rules to perform three critical checks: first, verifying syntax correctness to avoid execution errors; second, ensuring the query does not access unauthorized tables or fields, aligning with enterprise data governance policies; and third, simulating execution to evaluate performance and identify potential bottlenecks. For complex queries requiring multi-step reasoning—such as “Compare Q3 2024 e-commerce conversion rates for new vs. returning users across North America and Europe”—Semora breaks the request into smaller sub-queries, validating each step before combining results. This layered approach ensures that the final SQL is not only accurate but also compliant and efficient, eliminating the risk of misleading decision-making.

Conclusion: NL2SQL’s True Value Lies in Governance-Semantics Synergy

Gartner’s trend report is not a distant vision—it’s a roadmap for enterprises looking to unlock the full potential of their data. NL2SQL is indeed the key to democratized analytics, but its success depends on more than just deploying an AI tool. It requires building a holistic system that combines robust data governance with a semantic engine that understands both data structures and business intent.

The combination of Intalink and Arisyn’s Semora fills this gap, addressing the technical, semantic, and accuracy pain points that have stymied NL2SQL adoption in many enterprises. By creating a trusted data foundation and translating natural language into business-aligned SQL, they turn the promise of “everyone is a data analyst” into a practical reality. As NL2SQL technology continues to evolve alongside data governance, enterprises will be better equipped to make faster, more informed decisions—and stay ahead in an increasingly data-driven world.