What DAIS 2026 revealed about context, control, and the widening governance gap in enterprise data operation
At this year’s Databricks Data + AI Summit, every keynote theme Ali laid out, whether it is Agentic Data, Unity AI Gateway, or governance at the platform layer, points to the same underlying reality enterprises are hitting right now: AI systems are moving faster than the operational layer beneath them. Pipelines proliferate. Models ship. Guardrails don’t.
According to Databricks’ own State of AI Agents report, 80% of databases on their platform are now created by agents, not humans. That’s not a projection or an aspirational benchmark. That’s the current state of production environments at large enterprises running on Databricks today.
The creation side of the data estate has fundamentally changed. The operational side has not kept pace. And the gap isn’t just about governance controls. It starts earlier, with context. When agents are building pipelines at volume, the institutional knowledge about why something was built a certain way, what business logic it carries, and what it connects to downstream simply doesn’t accumulate the way it does when humans build incrementally. Without that context, maintaining control over what’s running in production becomes considerably harder. That’s where things get expensive.
What Databricks Put on the Main Stage
The product announcements at DAIS this year were significant, but the more important signal was in the framing behind them: Governance as a platform-level capability, not an add-on.
- Unity AI Gateway bringing policy controls directly into AI workflows.
- Agentic Data recognized as a first-class concept that requires its own operational model.
- And the launch of Apps on Databricks Marketplace, a new distribution model where third-party applications run natively inside a customer’s own Databricks workspace, with no data movement to external infrastructure.
What connects these announcements is a shared messaging: AI agents operating without sufficient context and control are a liability at enterprise scale.
Unity AI Gateway and the Agentic Data concept aren’t just about speed or capability, they’re about giving AI systems the context to operate within defined boundaries, and giving teams the controls to govern what those systems produce. Databricks is building the platform layer to support that. The question for enterprise data teams is whether their operational practices are building toward it too.
What the Governance Gap Actually Looks Like Day to Day
Three days of conversations at the Opsera booth made one thing clear. The context and governance gap is not a future concern for the teams we spoke with. It’s a current one.
Here is what it looks like in practice.
AI agents are generating pipelines at a volume that outpaces any manual review process. Many of those pipelines accumulate in production without clear ownership and without documented logic. When something breaks, the team diagnosing it has no context about how the pipeline was built, what it was built to do, or what changed since it was deployed. There is no trail to follow.
Compliance posture, which used to drift slowly between quarterly audits, now shifts week to week as new agent-generated workloads land in environments governed by controls that were scoped for a different pace of change. SQL workloads generated or modified by agents carry security exposure that goes unreviewed, not because teams don’t care, but because nobody has established which compliance requirements apply to which workloads, and at agent volume, manual review isn’t practical anyway.
Deployment governance is another consistent pain point. Teams are still promoting changes across environments through manual processes with limited validation and no reliable audit trail. When a deployment introduces configuration drift, diagnosing it often takes hours precisely because the context about what changed and why was never captured.
Disaster recovery may be the starkest example. Most enterprise data teams have DR plans. Far fewer have tested those plans against the estate that actually exists today, because the estate is changing faster than the plans are updated, and the context required to rewrite those plans isn’t centralized anywhere.
The CTOs and data platform leads we spoke with at DAIS weren’t describing edge cases. They were describing last quarter.
What BrickForge Does and Why the Architecture Matters
BrickForge is a purpose-built AI application that gives enterprise data teams what they have been missing: a native command center to observe, diagnose, fix, and govern their entire Databricks estate, without adding infrastructure or touching business data.
The intent behind each stage is straightforward. Teams need to see what’s happening across their Databricks estate before problems surface as incidents. They need to understand the root cause quickly, with enough context to make a good decision. They need to act on that diagnosis with a human-authorized, version-controlled fix rather than a manual workaround. And they need continuous assurance that the overall environment stays compliant and recoverable as it evolves.
The architecture is worth understanding because it’s directly relevant to how quickly an enterprise data team can actually adopt the product.
BrickForge runs natively inside a customer’s existing Databricks tenant. It evaluates metadata and infrastructure patterns, not row-level business data. Nothing leaves the customer’s environment. This is what Opsera calls the Zero Business Data Contact principle, and it matters for a practical reason: it removes most of the security and architecture review overhead that typically makes enterprise software adoption a months-long process.
There is no new infrastructure to evaluate, no data egress agreement to negotiate, and no new vendor trust boundary to establish. The security posture the team has already built around their Databricks environment extends to BrickForge from day one.
That’s a meaningful difference when the operational problem you’re trying to solve is already compounding in production.
The Same Gap Runs Through Software Delivery Too
BrickForge addresses the governance gap on the data operations side. Forge addresses it on the software delivery side.
When AI is generating code at volume, the same failure modes appear, no architectural context, no traceability, deployments that can’t be explained after the fact. Forge brings spec-driven, context-driven, and eval-driven development to AI-assisted software delivery, so what ships has a full audit trail and human oversight built in from the start, not added later.
How This Fits the Bigger Picture
BrickForge addresses the context and governance gap on the data operations side of the enterprise. Forge, Opsera’s AI software factory, addresses the same gap on the software delivery side, ensuring that AI-generated code moves from intent to production with architectural context, human oversight, and a full audit trail built in throughout.
The two products operate on different surfaces, but the underlying problem they respond to is the same. As AI agents take on more of the building work, whether that’s generating pipelines or writing application code, the operational layer above them has to carry more of the governance load. The execution tools enterprises already have, their CI/CD platforms, their Databricks environments, their ITSM systems, are not the problem. What’s been missing is a control layer above them that understands context, applies policy, and makes autonomous actions traceable and recoverable.
That’s the direction Databricks signaled at the summit. It’s also the direction Opsera has been building across both products.
What Enterprise Leaders Should Be Thinking About Now
The shift that Databricks put on the main stage at DAIS is already underway in most large enterprises.
Agents are generating data products faster than operational practices were designed to handle. The teams that will navigate this well are the ones that treat context and control as foundational requirements now, before the gap between what AI is building and what the operational layer can govern gets wide enough to create real business risk.
A few questions worth sitting with if you run a data platform, architecture, or engineering team:
- Do you have reliable visibility into what’s running across your Databricks estate today, including what was generated or modified by agents in the last 30 days?
- When a pipeline fails in production, how long does it take your team to establish the context needed to diagnose and fix it? How much of that time is spent finding information rather than acting on it?
- When was the last time your DR plan was tested against the estate as it actually exists, not as it was documented six months ago?
- And one layer up: do you know how much of the code shipping through your delivery pipeline was AI-generated and whether it carried architectural context when it did?
If the honest answer to any of those is uncomfortable, that’s roughly the same place the conversations at DAIS started.
BrickForge is available now on the Databricks Marketplace. If you want to see it in context of your own environment, you can reach the Opsera team at opsera.ai/brickforge.
