Databricks and Infosys: Why Data, Not Models, Blocks AI Deployment

Companies increasingly discuss artificial intelligence at the board level, but the real deployment of AI in business is often hindered not by models or computation, but by the state of corporate data. While consumer services have trained the market to expect instant impact, inside large organizations it quickly becomes clear that without unified, managed, and operationally suitable data infrastructure, AI remains a beautiful demonstration rather than a working tool. The main problem is that corporate data typically lives in too many different layers.

Some of it sits in analytical marts and data lakes, some in transactional systems like CRM, ERP and internal applications, and the rest is scattered across files, email, knowledge bases, tickets and cloud services. For typical reporting, such a landscape can still be tolerated. But when a business wants to give a model real-time access to data, embed AI into processes, or launch agents that not only answer questions but also take actions, fragmentation becomes a direct limitation.

A model can be powerful, but if it cannot see the current context, does not understand data lineage, and does not operate within clear access rights, the result becomes unstable and risky. This is precisely why the conversation about enterprise AI is increasingly shifting from models to architecture. One of the key theses is that enterprises need not a set of disparate AI tools, but a new data stack where data is stored in open formats, described by metadata, accessible through unified policies, and suitable simultaneously for analytics and operational scenarios.

Hence the interest in architectures that bridge the OLAP and OLTP worlds: on one hand, companies need the depth of analytics, history and scale, on the other — low latency, transactionality and the ability to act quickly. In this approach, Databricks promotes Lakebase as a serverless Postgres layer for operational AI workloads, and Unity Catalog as a unified layer for access management, data lineage, and governance for data and AI assets. The point is not the specific products, but the trend itself: business needs a foundation on which AI can work in production, not just in a pilot.

A separate question is how to measure impact. At an early stage, companies often get by with attractive metrics like the number of chatbot queries or the percentage of employees who opened copilots. But as they mature, this is no longer enough.

If AI is to automate processes, reduce operation cycles, increase conversion, or create new revenue streams, it must be evaluated as a full-fledged business system. Therefore, in the discussion of a new data stack, the question of measuring value also appears: the impact of AI must be linked not to the wow factor, but to concrete business results. This is especially important as we transition to agentic AI, where the model gains more autonomy, and thus requirements for observability, logging, data quality, and access policy become much stricter.

The evolution of enterprise AI here looks quite clear. First, companies deploy individual productivity tools — assistants for search, summarization, code writing, or document preparation. Then they transition to process automation: ticket handling, task routing, internal support, financial and operational scenarios.

And only after that does the third stage open — launching new products and business lines that are built around AI from the start. With each successive stage, data requirements grow. What still worked for a personal copilot no longer works for a process where precision, full action logging, and the ability to safely perform operations on behalf of the company are needed.

Hence the main conclusion: the next battle for enterprise AI is not about the best model interface, but about restructuring data for machine use. Those companies will win that managed to make data unified, managed, and compatible with agentic scenarios. For business, this means an uncomfortable but useful truth: the path to scaled AI does not start with choosing a model, but with rebuilding the data stack.