Over the past year, the most interesting part of AI has moved from model demos to enterprise systems.
TechCrunch’s AI coverage spans generative AI, large language models, speech, vision, predictive analytics, AI companies, and ethical questions. Behind the daily news cycle, one trend is becoming clear: AI is moving from isolated capabilities into enterprise workflows.
As a CTO, I am less interested in which model was released this week and more interested in a harder question:
Can AI actually enter the real data workflows of an enterprise?
That question is still unresolved.
An enterprise is not a chat window. It is a complex machine made of data sources, permissions, business processes, metrics, systems, teams, and accountability boundaries. Even the strongest model will struggle if it cannot understand the company’s data structure, business semantics, and governance rules.
OpenAI COO Brad Lightcap made a similar point in a TechCrunch interview, saying that enterprise AI has not yet really penetrated business processes because enterprises are complex organizations with many people, teams, systems, tools, and layers of context.
That is the reality.
Bringing AI into the enterprise is not the same as connecting a chatbot to internal systems.
The real question is whether the enterprise is ready to make its data world understandable to AI.
The first-principles question: what must AI understand?
When companies start building AI data applications, they often begin with tool selection.
Should we buy a BI tool?
A data catalog?
A semantic layer?
An agent platform?
An NL2SQL engine?
A governance tool?
A RAG system?
A Copilot-style interface?
These are valid questions, but they are not the first-principles question.
The real question is:
When a business user asks a question in natural language, how does the system move from that question to a trustworthy answer?
Take this example:
Which products contributed most to the profit decline of strategic customers in the East region this year?
This question looks simple. It is not.
It hides several layers of meaning:
What does “this year” mean? Calendar year, fiscal year, or business reporting period?
What is “East region”? Customer ownership region, sales territory, delivery region, or financial reporting region?
What is a “strategic customer”? Revenue-based, contract-based, manually tagged, or account-tier based?
What does “profit” mean? Gross profit, net profit, contract margin, project profit, or finance-adjusted profit?
How are customers, products, contracts, orders, invoices, and profit detail tables connected?
Does the current user have permission to access this data?
If these questions are not answered systematically, AI can only guess.
And in enterprise data intelligence, the most dangerous failure mode is not that the system is slow. It is that the system gives a fluent, confident, and wrong answer.
Why traditional tools are not enough
Traditional data tools are valuable, but most of them were designed for humans using data, not for AI understanding data.
Data warehouses are good at storage, computation, and modeling.
BI tools are good at reporting and visualization.
Data catalogs are good at registering assets and metadata.
Governance platforms are good at standards, permissions, quality, and compliance.
ETL and ELT tools are good at data movement and transformation.
These tools have supported enterprise digitization for years.
But AI introduces a new requirement:
In the past, humans read documentation, inspected schemas, and wrote SQL. Now AI needs to understand those things and act on them.
That means enterprise data assets must not only be managed. They must become machine-understandable.
Many traditional toolchains have structural gaps:
Business semantics are disconnected from technical fields.
Data lineage is disconnected from actual query paths.
Metric definitions are disconnected from SQL generation.
Permission systems are disconnected from AI tool usage.
Data governance is disconnected from user-facing analytics.
This is why many NL2SQL, intelligent query, and data agent projects work well in demos but break down in real business scenarios. They select the wrong tables. They infer the wrong fields. They generate unstable joins. They mix metric definitions. They ignore permission boundaries. They produce results that cannot be traced.
The problem is not always that the model is weak.
The problem is often that the enterprise has not provided enough reliable context.
The global trend: models must connect to enterprise context
Recent enterprise AI coverage points toward the same conclusion: AI is no longer just about standalone models. It is about connecting models to enterprise data, tools, permissions, and workflows.
TechCrunch noted in early 2026 that agents failed to live up to the hype in 2025 partly because it was hard to connect them to the systems where work actually happens. Protocols like MCP matter because they reduce the friction of connecting agents to databases, search engines, APIs, and external tools.
Snowflake’s partnership with OpenAI reflects the same direction. TechCrunch reported that Snowflake customers would gain access to OpenAI models across major cloud providers, with the goal of building and deploying AI on top of trusted, secure, governed enterprise data.
Glean is another example. TechCrunch described Glean’s strategy as becoming the connective layer between models and enterprise systems. Its CEO made the point directly: large language models are generic; they do not understand a company’s people, work, products, or internal context by themselves.
The pattern is clear:
Enterprise AI is not just a model race. It is a context engineering race.
The companies that organize data, semantics, permissions, workflows, and tools into AI-readable context will have the better chance of turning AI into production capability.
Do not start with the chat interface
Many enterprise data intelligence projects begin with an intelligent query interface.
That is understandable. A chat interface is the easiest way to demonstrate AI.
But from a CTO’s perspective, starting with the chat window is risky. The chat interface is only the entry point. It is not the capability.
A more reliable implementation path has five layers.
1. Make data assets visible
The enterprise must first know what data exists.
This includes data sources, tables, fields, primary keys, row counts, update frequency, owners, quality status, and system ownership.
Without this layer, AI does not know what it can use.
Traditional catalogs and metadata platforms cover part of this, but AI needs a more structured and callable representation of fields, business objects, and data interfaces.
2. Make data relationships knowable
Knowing which tables exist is not enough.
The hard part of enterprise data is the relationship between tables.
How does the customer table connect to the order table?
How does the order table connect to invoices?
How does a project connect to employee time records?
Can a contract table directly connect to profit details?
If not, which intermediate table is required?
Traditionally, this knowledge lives in senior engineers’ heads, legacy SQL scripts, ETL jobs, and report logic.
AI cannot rely on institutional memory. It needs structured relationship context.
This is where a data relationship layer becomes important. In the Arisyn / Intalink architecture, Intalink is positioned as an enterprise data lineage and relationship discovery platform. Its documented capabilities include data source management, table management, relationship discovery, task execution, and relationship quality indicators such as co-occurrence count, distinct count, and inclusion ratio.
The point is not to draw a nice lineage diagram.
The point is to provide AI with a computable, verifiable, and callable map of how enterprise data connects.
3. Govern business semantics
Data relationships explain how tables connect. They do not explain what the business means.
Business users do not ask:
SELECT SUM(amount) FROM fact_sales WHERE region = 'East';
They ask:
How are our strategic customers performing in the East region?
Terms like “performance,” “strategic customer,” and “East region” are business concepts, not database columns.
Enterprises need a semantic layer to manage metrics, dimensions, terminology, formulas, units, scope, versions, and governance rules.
Arisyn is documented as an enterprise semantic-layer intelligent query engine. Its architecture includes natural language understanding, business semantic definitions, semantic mapping, terminology management, metric and dimension definitions, and version/gray-release management.
A semantic layer does not exist to make terminology look organized.
It exists to constrain AI before it generates SQL, selects data, or explains results.
4. Make intelligent query explainable
Once data assets, data relationships, and business semantics are in place, intelligent query finally has a reliable foundation.
A trustworthy enterprise query system should not only return results. It should answer:
Why were these tables selected?
Why was this join path used?
Which metric definition was applied?
How was the SQL generated?
What is the business definition of the result?
Were there ambiguities?
Was the user authorized to access this data?
If the result looks unusual, what might explain it?
Arisyn’s intelligent query flow includes intent recognition, synonym retrieval, clarification, table relationship discovery, SQL generation and validation, query execution, and result summarization. Its result display includes summary, reasoning, boundaries, SQL, data, charts, and timing details.
For a CTO, explainability is not a nice-to-have.
It is a production requirement.
Without explanation, business users cannot trust the result.
Without SQL, technical teams cannot review it.
Without definitions, management cannot rely on it.
Without boundaries, governance cannot control it.
5. Build a feedback loop
Enterprise data intelligence is not a one-time project. It is a system that must improve over time.
Every failed query, field ambiguity, metric conflict, and user correction should feed back into semantic governance, relationship correction, knowledge supplementation, and test validation.
Without a feedback loop, the system remains a demo.
With a feedback loop, it gradually becomes production-grade.
In the documented relationship between Intalink and Arisyn, Intalink provides data lineage, relationship discovery, and metadata management, while Arisyn builds semantic definitions, intelligent querying, and workflow orchestration on top. Together they form a layered data infrastructure and intelligent application architecture.
This layered design turns one-off AI answers into a governable, auditable, and continuously improving data intelligence system.
Tool selection: stop comparing feature checklists
Enterprise teams often evaluate tools by feature lists.
Does it support natural language query?
Does it support NL2SQL?
Does it have lineage?
Does it have a data catalog?
Does it support permissions?
Does it have agents?
Does it support MCP?
Does it have workflow orchestration?
These questions matter, but they are not enough.
A CTO should ask deeper questions.
Does the tool strengthen the existing data system, or bypass it?
Some AI tools produce fast demos by bypassing existing governance, permissions, and metric systems.
That is dangerous.
A good enterprise AI data tool should organize existing systems into AI-readable context, not replace them with an isolated shortcut.
Can it turn technical metadata into business semantics?
Managing tables and fields is not the same as supporting business questions.
Can fields map to business metrics?
Do metrics have versions?
Do dimensions have valid scopes?
Can business definitions be governed?
Can ambiguity be detected and resolved?
Does it understand table relationships, or only field names?
Many NL2SQL errors come from incorrect joins.
If a system relies mainly on field-name similarity, it will fail in complex enterprise environments.
Relationship discovery, relationship confidence, candidate paths, best-path selection, and relationship updates are foundational for intelligent querying.
Is the result explainable and auditable?
Enterprise data intelligence is not a consumer chatbot.
Wrong results can affect business decisions.
Wrong permissions can create compliance risks.
Wrong definitions can create organizational conflict.
The system must explain reasoning, SQL, data sources, metric definitions, and access boundaries.
Can it learn from failure?
Many intelligent query projects fail because the first production results are not accurate enough.
But the real issue is not that the first answer is wrong. The issue is whether the system can understand why it was wrong and retain the correction.
Without feedback, humans will always be firefighting.
With feedback, the system can improve.
My view of the enterprise data intelligence stack
If I were designing an enterprise data intelligence architecture from scratch, I would not define it as an “AI query tool.”
I would define it as a five-layer system.
The first layer is the data asset layer: connecting data sources, extracting metadata, and maintaining table and field assets.
The second layer is the data relationship layer: discovering and validating table relationships, field relationships, cross-source relationships, and join paths.
The third layer is the semantic governance layer: managing business terms, metrics, dimensions, formulas, versions, and permission constraints.
The fourth layer is the intelligent execution layer: handling intent understanding, query generation, tool calls, SQL validation, multi-step reasoning, and result generation.
The fifth layer is the feedback and operations layer: collecting user feedback, diagnosing errors, supplementing knowledge, managing tickets, evaluating quality, and improving continuously.
Each layer has a clear responsibility.
The model should not decide business definitions by itself.
The semantic layer should not guess data relationships.
The relationship layer should not replace business explanation.
The query layer should not bypass governance.
The feedback layer should not depend on human memory.
That is the architecture enterprise AI data systems need.
Conclusion: the stronger AI becomes, the more enterprises need data order
The global AI trend is becoming clearer.
Models will become stronger.
Agents will become more common.
Tool-calling standards will mature.
Enterprise systems will become more deeply connected to AI.
But the real dividing line will not be who adopts the newest model first.
The real dividing line will be:
Who can organize messy enterprise data into AI-understandable structure?
Who can turn business language into governed semantics?
Who can turn table relationships into verifiable connection maps?
Who can make intelligent query explainable, auditable, and correctable?
Those are the companies that will move AI from demo capability to production capability.
The future of enterprise data intelligence will not be just a smarter BI tool.
It will not be just a chatbot that writes SQL.
It will be a new operating layer for enterprise data:
Semantics to understand the business.
Relationships to connect the data.
Governance to define the boundaries.
Agents to execute work.
Feedback to improve over time.
That is the real implementation path for enterprise data intelligence in the AI era.
Top comments (0)