What it takes to trust AI in production: Lessons from Salesforce and Dropbox at Snowflake Summit

At Snowflake Summit 2025, we brought together two of the most thoughtful data leaders building in the agentic era — Naveen Chhajer, Senior Director of Trust and Discovery at Salesforce, and Philip Zelitchenko VP, Data & AI Platform at Dropbox — to talk candidly about what it takes to ship AI you can actually trust. Here are some of the key insights we took from this discussion.

The rules have changed

Since agents have become consumers of data, the rules have changed in terms of how we manage and organize our data systems.

For years, data teams could get away with a certain level of ambiguity. A dashboard could be a little wrong or a definition could be a little fuzzy because humans have intuition — they can look at a number and sense when something is off.

Agents, however, can’t.

As Barr put it during the discussion: dashboards were wrong silently. AI is wrong confidently — it’ll argue with you if you try to correct it. That shift changes everything about how data teams need to think about quality.

Philip framed the foundational problem well: if data enters a platform at zero trust — without embedded signals or clear ownership — and flows through to an agent making a customer-facing decision, every gap compounds. The accountability model that worked for BI doesn’t scale to agentic speed.

Trust has to travel with the data

One of the most concrete ideas from the conversation came from Naveen, describing what Salesforce has been building toward:

“Data itself should be able to tell an agent whether it can answer a question. The signal should be embedded within the data. The trust travels with the data.”

Salesforce operates across three data platforms simultaneously — Salesforce Data Cloud, Snowflake, and internal infrastructure. Data moves constantly, but the metadata doesn’t automatically move with it. And now agents are pulling from all of it simultaneously.

The practical implication: you can’t bolt trust onto the end of a pipeline. Signals, context, and definitions need to be attached at the source and preserved through every transformation and hop.

The archaeological site problem

Philip was direct about what he walked into at Dropbox:“It looked like an archaeological site. You go there and you can see things from different eras.”

He was dealing with twenty years of legacy, an on-premises data center, and technical debt that was overwhelming. And on top of all of it, there was the pressure to ship AI fast.

This isn’t unique to Dropbox — it’s the story of most enterprises trying to move quickly on AI while carrying the weight of everything built before. The temptation is to throw AI on top of the existing stack, add context, and call it done.

Naveen also commented here, pushing back on that instinct: “The same platform optimized for warehouses and BI is not going to be ready for AI. If you were doing it for AI, you have to rethink your entire stack. And that completely changes how you think about quality as well.”

The move that helped at Dropbox was shifting data ownership back to the teams producing it. Product engineering teams own the generation step and data teams focus on the application layer, forcing implicit contracts to become explicit ones.

We can’t attribute accountability solely to people anymore

When an agent does something wrong — surfaces the wrong number, sends the wrong message, makes a bad call at a customer touchpoint — who’s accountable?

Naveen didn’t soften when he said “On behalf of the data family, all fingers point to data people.”

But the more useful answer is structural. The problem isn’t who to blame — it’s that the old accountability model, with humans in the loop at every decision point, doesn’t scale to agentic speed.

“Accountability has to move from people and process to systems. I don’t sit down before sending an email and check whether I’ve encrypted the data. It’s embedded within the system itself.”

At Salesforce, that means rebuilding the security layer close to the agents — policies, degradation frameworks, regression testing, self-feeding pipelines with continuous reinforcement learning. The goal isn’t to remove human accountability. It’s to build systems that let humans be accountable at scale.

Philip added that the accountability model needs to operate at both ends: data producers owning their domain and certifying what gets exposed, and data consumers — whether human or agent — working only with data that’s been through that process. When both sides own their piece, the finger-pointing problem gets smaller.

Reads versus writes: a simple AI readiness diagnostic

One of the sharpest moments came from Naveen with a deceptively simple gut-check for AI readiness:

“If your reads are not in a 70-30 ratio with writes, you are not even ready to have the AI conversation. You’re just making more data, not using it.”

Every data platform has two types of activity: writes (building — pipelines, transformations, loading data in) and reads (consuming — querying data, acting on it, serving it to users or agents). Most platforms are heavily skewed toward writes. Teams spend the majority of their time constructing data infrastructure rather than actually using the data to drive decisions or take action.

Naveen’s point is that if your platform is still mostly in build mode, it isn’t oriented around value delivery — it’s still a construction site. And that’s a problem for AI, because agents don’t produce data. They consume it. They need a platform that’s been optimized for use, not just for production — where data is queryable, contextualized, and ready to act on. If you haven’t cleared that bar yet, adding agents on top won’t help.

The composability principle

When Barr asked how to keep up in a world where models change every two weeks, Philip landed on architecture as the answer — specifically, composability:

“Our ability to switch out models and evaluate their impact on the things we’ve built is key. The cost of changing things is going to be lower just because of how the architecture is built.”

Picking the right model isn’t as important as building systems where swapping out the wrong model is an agile, efficient process – one that doesn’t cost months of rework. Composability, in this case, is a hedge against the pace of change rather than just a technical property.

Naveen added that at Salesforce, the fundamental why stays stable even as the how keeps shifting:

“The fundamentals do not change. The why is still the same thing — we are still trying to solve customers’ problems. How you do it, who does it, whether humans or agents, that is changing. But the why is not.”

Creating an AI-first culture

Both Naveen and Philip were candid that the most difficult challenge in this environment isn’t technical; it’s often the people.

This is not because teams lack capability, but rather because expectations haven’t been defined clearly enough for what it means to do data work in a rapidly changing agentic world.

Philip put it plainly:

“In software, the SDLC is pretty standard. In the data world, things weren’t defined well before AI came in — and now we’re expediting all of it into a new world that hasn’t been defined either.”

What does it mean to 10x a data practitioner? What’s the data equivalent of “number of PRs per month”? Nobody has a clean answer yet. The leaders who are ahead are the ones defining those frameworks themselves.

Naveen added that the speed of change makes the empathy challenge real:

“The hardest part is how do we keep that empathy. There are still people that are important. Technology will figure it out — but we cannot lose sight of people.”

The gap between pilot and production

The conversation closed on a topic that is at the heart of the discourse for most data and AI leaders in enterprises today. This is the gap between prototyping an agent and running one reliably in production, and it is significant.

Plus, making it to production isn’t even the finish line.

As Naveen noted, Salesforce has prototyped hundreds of agents, but only 5–10% went live. And the ones that did still require ongoing maintenance, continuous evaluation, and degradation monitoring. The work doesn’t end at launch; it begins there.

The leaders who’ve made it through describe the same thing on the other side: data teams finally operating as product teams rather than service teams, agents handling the first line of response, and humans freed up for the deeper, higher-leverage work.

Our promise: we will show you the product.