Data lakehouses have become the gold standard for enterprise data platforms since they combine a data lake’s ability to support a variety of different types of data at low cost, and the reliability, structure and governance of a traditional data warehouse.
The fact they offer a central repository of information that might come from different places at a company, together with security and auditing tools, make them a perfect fit for enterprise AI systems, too. In fact, they’ve become so popular and useful that all the major data lake and data warehouse vendors have all but converged into data lakehouse vendors. Snowflake, for example, started out as a data warehouse and over the course of several years and acquisitions, has transformed into a full data lakehouse platform.
Docusign is now using it to support its agentic AI ambitions, too. For example, data is pulled in from Salesforce and then used to train an internal AI agent for sales, says Shivi Verma, Docusign’s senior manager of engineering. The company is also training ML models in order to serve customers more accurately.
The information also goes out to LLMs using RAG embedding pipelines, and MCP connectivity is being explored as the technology matures.
One issue Docusign keeps top of mind when exposing the data in its lakehouse is security and governance.
“We’re proceeding very cautiously,” Verma says. “It goes through a stringent security review and discussion with both technical and business stakeholders to make sure we’re not doing anything that isn’t allowed from the security lens and compliance lens.”
The security checks are in place both when the data first goes into Snowflake, he says, and when it goes out again. The restrictions are particularly tight when it comes to access to anything sensitive, such as customer data.
“We’re first exposing those with a low risk profile,” he says. That can include publicly-facing information like website content or product details.
Docusign isn’t alone. “We see 65% adoption of lakehouses among Gartner’s client base,” says Gartner analyst Prasad Pore. “It’s a very strong number in a short time.”
And the future of lakehouses looks even brighter.
“Lakehouse is becoming the foundation for the future of AI,” Pore says, adding that vendors are evolving to support this use case. For example, lakehouse as a concept doesn’t support vector databases, which are a key type of data structure for AI systems that use RAG to feed data into LLMs.
“But many lakehouse vendors have added capabilities for vector indexing,” he says. “Databricks and Microsoft Fabric both have a vector capability built into their platform.” Yet smaller players might not provide the functionality, he adds.
Similarly, support for MCP, a standard that allows AI agents to connect to data and systems, varies by vendor, and isn’t traditionally a core lakehouse functionality.
A data lakehouse isn’t the only option for companies looking to provide their AI system with the critical business context they need to be useful to the enterprise.
For example, companies can build vector databases or vector database pipelines manually from individual sources, or use a data fabric to make the connection. “Fabric can directly connect to original sources, which is a good use case for quick analytics,” Pore says. “But then you’re over your source systems, which isn’t a good thing for those products and machines.”
Microsoft Fabric is a lakehouse platform, though, and not a data fabric platform in the way Gartner defines the term.
Another downside is that the data models used in original systems aren’t usually optimal for analytics, and can be expensive. “Connecting to direct sources isn’t efficient,” Pore says.
Finally, there are well-established processes for managing data permissions in a lakehouse.
“A lakehouse physically unifies your data, maintenance, security, and governance,” he says. “This is very critical for AI implementation. As an organizational single source of truth, a lakehouse is the modern way to create a central repository.”
Consulting firm Lemongrass originally started out with a data lake about a decade ago, and then began upgrading it to a lakehouse four years ago.
“Back then, the concept of a lakehouse wasn’t that popular,” says Kausik Chaudhuri, chief innovation officer at Lemongrass. So the firm built custom lakehouse functionality on top of its Amazon S3 data lake. Now that it’s using the data lakehouse to support AI, it’s time for another upgrade.
“Right now, we’re working on something for our incident and change management,” he says. The original data is in ServiceNow, and it’d be too expensive to pull it out directly from the lakehouse to use in an AI system. “So now we’re thinking of building an MCP server to query that data,” he adds.
And they also plan to upgrade from its own custom lakehouse add-ons to a standard solution. “Lemongrass was primarily an AWS evangelist when we started, and a lot of our tooling was on top of AWS,” Chaudhuri says. “Now we’re thinking of changing this because with AI, there’s a lot more opportunity.” Then again, AWS now offers lakehouse functionality. “The data’s already there,” he adds. “We don’t have to reinvent it.”
Plus, AWS has connectivity to Anthropic’s Claude AI and other AI models. And since the models are also running on AWS, there are no data egress fees. Lemongrass plans to start the upgrade with a POC in Q3 this year. “Everybody’s busy, so we need to pull in people and figure out when and how we implement that,” he says. For example, the company has to be careful about what data and how much is pulled in from the lakehouse and sent to the AI.
“We don’t send out customer data to an LLM,” he says. “And I’m not reading 10,000 rows and sending it to Claude, which would blow up to token usage. We figured out a couple of years ago we can go bankrupt if we’re not careful about the amount of tokens we use.”
And for some use cases, the LLM doesn’t need to see anything at all after the solution is deployed. For example, firm employees used to manually generate status reports about its customers for internal use, which was a time-consuming process. An AI model could, in theory, take over that job, but then it’d see the customer data. And since AIs aren’t deterministic, each report would look different.
Or, say, the firm needs to generate forms to fill out and then the customer would sign. Again, an LLM could create a custom form each time. “So then we asked Claude to write a program that takes this input and writes this report,” says Chaudhuri. The process of generating reports or the forms is traditional, deterministic software. The customer data is never exposed, and the reports are cheap and fast to produce.
But other companies are use AI to make better use of its data. In a recent report by Databricks based on data from 20,000 organizations, the percentage of databases created by AI agents rose from 0.1% to 80% over the past two years, and agents now create 97% of database branches.
One major area of struggle for enterprises is to figure out how to handle security and other related issues for when AI agents access data lakehouses.
In the past, data went out to dashboards, in which the security and access controls were programmed. Or the data went to data analysts, who worked within their own access privileges. The first use cases for AI involved RAG embeddings, which were easier to manage.
In a RAG embedding, traditional, deterministic software is used to pull in data and embed it into an LLM prompt for a particular workflow. The developers setting it up would handle the security aspects for each particular use case. With agentic AI and MCP servers, however, the AI can go and grab data autonomously, as needed.
According to Genpact’s Arellano, enterprises need to figure out how to manage the identities of AI agents, control access to data, create audit trails, and filter prompts and content.
“Agents need their own credentials,” he says. For example, AI agents might not have permissions to ever touch patient records. “And audit trails are important, with full observability of what the agent did.”
Some lakehouse vendors, including Databricks, offer this functionality, he says, and there are other tools that can be brought in like Okta, Palo Alto, or Zscaler.
The next evolution of the lakehouse is the semantic layer, and Gartner estimates that universal semantic layers will be critical infrastructure by 2030.
“Developing a universal semantic layer is now a must‑do for data and analytics leaders either leading or supporting AI,” Gartner says. “It’s the only way to improve accuracy, manage costs, substantially cut AI debt, align multiagent systems, and stop costly inconsistencies before they spread.”
It’s one thing for an AI to have access to data, but entirely something else to understand what that data actually means to the business. The semantic layer is the business knowledge that’s not normally formalized in a structured database, such as, say, the knowledge that an order or a customer means different things in different systems.
“Before, the semantic layer was nice to have but not as necessary because data scientists know what data sources they want to query,” says Amit Kinha, board member of the FinOps Foundation and field CTO at DoiT International, a cloud consultancy.
But now, without it, an AI agent won’t know where to look for the data it needs, he says. “Or it’ll do a bad join, or do something that creates a cost explosion,” he adds. “The semantic layer is going to be critical for leveraging lakehouses effectively.”
This semantic layer can also become part of a feedback loop, where the agentic systems learn from experience, says Kevin Martelli, consulting AI solution development leader at EY Americas.
Say for example a company has a process where approvals are required for certain payments, and a CFO is required to sign off for payments over half a million. If the AI agent goes to a human for approval, he says, the human might say this is telling me to approve this invoice, but I know it’s over $500,000 and I need to get CFO approval on this. “Then it can be stored in the session and persisted back in the lakehouse as a procedural document or as a record of something that occurred,” says Martelli. “This is where it becomes more beneficial and aggregates over time with usage because you’re never going to get it perfect on day one.”
The semantic layer is still very much an evolving area, and different data lakehouse vendors handle it differently.
“There’s this great debate going on in the industry of how lakehouses converge with semantic layers and where they actually live,” says Matt Arellano, SVP of data and AI at digital transformation consultancy Genpact.
Some vendors are building semantic tools into their data lakehouse platforms, or acquiring additional firms to get the technology. In other cases, customers are using third-party tools instead.
“Clients are struggling with that,” Arellano says. “They’re all trying to figure out the different combinations and permutations of tools and processes.”
Steven Karan, VP of AI transformation for Capgemini Australia and New Zealand, says he sees the lakehouse as evolving into a central orchestration layer.
“Organizations are now less focused on analytics and reporting, and more on building AI-driven applications and agentic systems,” he says. “The most effective architectures I see today combine a lakehouse core with specialized serving layers.”
That includes vector databases for AI, streaming platforms for real-time data, and operational databases for low-latency applications. The lakehouse isn’t just for analytics anymore, he adds. It’s the foundation for enterprise data and AI. “Its role is now less about replacing all other systems, and more about unifying and governing them to accelerate innovation while maintaining control,” he says.