Why do AI initiatives often stall even when built on world-class technical foundations? Samuel Nagy of Dawiso explores the missing link in modern data architecture: the human-centric context that technical catalogs often overlook. He discusses the shift toward ‘AI-ready’ ecosystems and how aligning data engineering with business reality finally delivers measurable ROI.
In the race to operationalize AI, many enterprises have built impressive technical foundations using the Databricks platform and its Unity Catalog governance layer. Yet, a persistent gap remains: the ‘Context Gap’ between technical metadata and business meaning.
To explore how organizations can close this gap, we sat down with Samuel Nagy, VP of Strategic Growth at Dawiso, a next-generation data governance platform.
Samuel brings a unique ‘boots-on-the-ground’ perspective to the conversation, balancing high-level go-to-market strategy with the hands-on reality of a solution engineer. At Dawiso, he plays a pivotal role in evolving the platform from a traditional data catalog into a critical AI Context Layer – working directly with organizations to turn raw data landscapes into governed, ‘AI-ready’ ecosystems.
In this interview, Samuel shares why technical governance alone isn’t enough to drive business outcomes, how to create a bidirectional flow between engineers and business owners, and why a centralized ‘Single Source of Truth’ for metadata is the only way to ensure AI agents are not just fast, but actually accurate.
Unity Catalog is perceived as a robust technical foundation for data management within Databricks. Why is it often so difficult for purely business users to navigate and start using it effectively?
In general, the Databricks platform is great in that it includes Unity Catalog, which ensures governance across the entire data environment. Today, other platforms are moving in this direction as well, because it’s a model that has proven effective, for example, Fabric with its OneLake catalog. The issue is not with technical governance. The problem arises when we talk about comprehensive data governance, which naturally includes business users.
In any company, the owners of data cannot be technicians or data engineers. They must be people who are responsible for business processes and understand where the data comes from, why it is there, and what it means.
Although Databricks offers tools such as Genie or dashboards that are designed specifically for business and less technical users, Unity Catalog is not one of the places that business users are typically expected to access, nor is it primarily designed for them from the outset.
The second issue is that business governance is not just about being able to look at the data you have. Business governance is much broader. It includes things like KPI definitions, business glossaries, metadata definitions for data products, various entity and attribute models, and similar concepts. I wouldn’t say these are missing from Unity Catalog, because that is not its purpose. However, if I want to build comprehensive governance, these are capabilities I need… and I won’t get them directly within Unity Catalog.
When it comes to the business layer on top of Unity Catalog, what specific business capabilities and functions need to be built so that a purely technical tool becomes useful for the entire organization?
The most important element is definitely the business definitions we just mentioned. If I want to understand what is in the data, not only from a technical perspective, but also from a business perspective – someone needs to provide that context. For example, in Dawiso, on top of the scanned data, we have descriptions that explain the data from a business point of view. These descriptions are then linked to other metadata assets, such as business glossaries or KPI definitions, which need to be maintained in a centralized way.
Another important aspect is that elements like business glossaries must be centralized in one place. It is not possible to maintain them separately in every tool. For instance, a database or data warehouse cannot have a different business glossary than the reporting layer, because that leads to conflicts, unclear data interpretations, and situations where metrics are calculated differently than they should be. That is why it is often very important to manage these definitions in a dedicated tool, such as Dawiso.
Concepts such as business glossaries, data products, or approval workflows are often handled outside the technical layer. How can you ensure that these business elements do not become just an “isolated island,” but remain closely connected to the data in Unity Catalog?
That’s a great question, and it actually has two dimensions. The first is that business concepts need to be connected to the scanned metadata. In practical terms, I know that a table exists somewhere in a specific schema in Databricks, and now I need to understand which business concepts it contains. This means there has to be a connection at the metadata layer. In Dawiso, this is very straightforward. We have features such as auto-linking that help establish these connections.
The second dimension is that some of this information needs to flow back into the technical layer. The reason is that data engineering happens in the technical layer, but it requires input from the business side. Engineers need definitions, they need to understand how the business thinks about processes, and they need key information such as who owns the data or whether it contains GDPR-related or sensitive data. This is the second mode we address in Dawiso. We take selected metadata elements and write them back into Unity Catalog so that when new data solutions are being built, they are already based on the correct metadata structures.
So we are also talking about bidirectional metadata synchronization. Why is it so critical to maintain a Single Source of Truth, and how can we prevent metadata duplication across different platforms and tools in practice?
It is just as important for metadata as it is for data. With data, we always need to know which specific record is correct, so that we don’t end up building reports on different versions of the data and getting inconsistent results. The same applies at the metadata level. We need one place where we know the metadata is correct and approved by the data owners and the business. Otherwise, the data warehouse may develop its own interpretation of metadata, the reporting layer another interpretation, and conflicts inevitably arise.
This becomes even more critical today with the rise of AI tools across all these platforms. Databricks, for example, is very strong in this area. We need AI systems to provide predictable and transparent answers. If someone asks, “What was the revenue last month?”, it should not matter whether the question is asked in Databricks or in the reporting layer – the answer must be the same. Otherwise, those AI systems lose their value.
That is precisely why it is necessary to manage metadata in a centralized way, so that all these tools rely on a single source of truth as their foundation.
Many companies do not use only Databricks. How can you enable unified data management across other platforms (e.g., Snowflake) while still keeping Unity Catalog as a key metadata authority?
This is exactly where we encounter the issue I mentioned earlier. If there are multiple tools in the environment, standardizing metadata across them becomes quite complex. We see Unity Catalog as one of the consumption layers for metadata. The main mastering of metadata happens in Dawiso.
Another dimension of this is that Unity Catalog provides valuable capabilities within a single platform, such as visibility into data, lineage, tables, columns, and data types. That is excellent for that one platform. However, if I need to see this across my entire data infrastructure, I cannot rely solely on Unity Catalog. I need a solution that can describe and connect data consistently across all platforms. That is where a data catalog becomes essential.
We connect to source systems and extract metadata from Unity, Snowflake, Confluent, and other platforms. We then build unified lineage, unified report catalogs, and data dictionaries that standardize column names and definitions across the entire data infrastructure. All of this would be extremely difficult (if not impossible) to achieve without a third-party tool.
Let’s move more toward AI. Today, there is a lot of discussion about AI agents. Why are enriched business metadata and context more important than ever for their successful deployment?
The issue with AI tools operating on data is that today it is relatively easy to build a text-to-SQL translator that generates scripts or queries, pulls data directly from a database, and works with it. However, there are two major unresolved problems.
The first is that this text-to-SQL functionality must run against the correct data sources. If I execute a complex query directly on the main fact table and it runs for an hour, I may consume significant resources and potentially block the database for a long time. Instead, I want to run it against a view or a warehouse layer that is already prepared for analytical workloads. To make that decision correctly, I need the metadata layer.
The second issue is interpretation. Once I retrieve a number or a table from the database, AI agents today do not inherently know how to interpret it correctly. They can make assumptions, but for accurate interpretation within a specific company context, the agents need access to the company’s precise definitions. That is exactly where the business metadata layer, the context layer, becomes essential.
If you look into the near future, what will be the main difference between a company that manages metadata only at a technical level and one that also embeds full business context into it?
I believe the main difference will be that companies managing metadata purely at a technical level may have excellent technical implementations. What is being built today on Databricks, for example, is often technically very strong. However, it is much harder to translate that into business impact and ultimately extract real business value from it.
If I address metadata at the business level as well, it becomes much easier to deliver value, reduce time to delivery, and implement AI agents or “talk to my data” chatbots that can take things even further. That business context is what enables organizations to move from well-engineered data platforms to platforms that actually drive measurable business outcomes.
Dawiso joins the 11th edition of the Data Innovation Summit (DIS) in Stockholm as an official partner.
If your organization is looking to align technical infrastructure with actual business value, we invite you to visit the Dawiso booth to meet the team. Don’t miss their Technology in Practice (TIP) sessions, titled:”Why Is Your AI So Confused? And How Context Fixes It” and „Extending Unity Catalog for Business Use Cases“.
This session will dive deeper into how enriched business metadata and bidirectional synchronization can transform a complex data landscape into a trusted foundation for the next generation of AI.
