Scaling Enterprise AI Requires Clean Data, Strong Workflows and User Adoption
Databricks CIO Naveen Zutshi says production readiness depends on measurable results, governed data, sound development processes and user feedback.


Moving an AI model into production is less a question of how long it has been tested than whether the product built around it works reliably for its intended users. That distinction shapes advice from Naveen Zutshi, Databricks’ CIO: teams need to evaluate real outcomes, prepare data and workflows, and earn adoption from the people expected to use the system.

The pressure to make that transition is growing. Databricks’ State of Data + AI report recorded a 1,018% year-over-year increase in AI models registered for production, compared with a 134% increase in logged experiments. The figures suggest that more projects are advancing beyond trials, though registration alone doesn’t establish how widely or effectively those models are being used.
Zutshi brings an enterprise operations perspective to the problem. Before joining Databricks, he spent six years as CIO at Palo Alto Networks, overseeing analytics and AI, applications, infrastructure, operations and corporate services. He previously led infrastructure and operations at Gap, held an engineering leadership role at a software-as-a-service startup, and worked in IT management at Cisco.
Test the product, not a calendar
There’s no universal experimentation period that makes a model ready for deployment, Zutshi argues. Readiness depends on the application. A general-purpose model such as ChatGPT can underpin products with very different risks and performance requirements, so teams should assess the product’s behavior in its actual setting rather than apply a fixed waiting period.
For AI-generated email, for example, teams can track click-through and open rates and compare results with human-written messages. A/B testing can reveal whether the AI performs well for the audience and workflow in question. User feedback and performance metrics then guide further changes, including work to improve accuracy and reduce hallucinations.
This approach makes deployment a measured decision. A team needs evidence that the product meets its goals and behaves acceptably, then a way to keep watching performance after release. Results from one use case won’t automatically transfer to another, even when both rely on the same underlying model.
Build the surrounding system
Choosing a capable frontier or open-source model is only one part of a production system. Zutshi also points to the user experience, the software development lifecycle (SDLC), data management and governance. A conversational interface may be a starting point, but teams still need to understand how people will use the tool and whether it will change their work.
A strong SDLC gives teams a repeatable way to train, update and manage models and data. That matters as systems move from a controlled experiment into workflows where changes must be reviewed and performance must be maintained. Without dependable processes, a promising demo can be difficult to operate at scale.
Data access needs similar care. Zutshi says organizations should govern their sources and use measures such as access control lists to protect privacy. They also need to consider intellectual property and prevent data leakage. In business settings, accuracy expectations may be stricter than in casual conversations. Retrieval-augmented generation can help by grounding model responses in existing organizational information, though teams still need to monitor results.
Governance extends to security, AI policies and bias mitigation. These are operational requirements for deployment: they affect what data a model can use, who can access its outputs and how the organization handles failures or unwanted behavior.
Data quality is an ongoing job
For Zutshi, the first technical obstacle is often the condition of the data. Organizations may hold both structured and unstructured information in large quantities, but volume doesn’t tell teams whether it is clean, usable or well governed. Poor inputs can undermine the system even when the model and deployment workflow are sound.
He recommends a coherent data management strategy, potentially organized around a lakehouse that can hold structured, semi-structured and unstructured data. Strong access controls and clearly defined data metrics help teams manage the information. Business stakeholders also have a role: data champions and stewards can support cleansing and governance close to the people who understand how the data is used.

That work doesn’t end at launch. Data quality needs continuous attention as sources change and new use cases emerge. Treating it as a one-time cleanup leaves production systems exposed to stale, inconsistent or poorly managed information.
Adoption depends on people
The third challenge Zutshi identifies is change management. Organizations can build a technically sound model and still fail to get value from it if users don’t trust the tool, understand its purpose or see how it helps their work.

“Make sure you are focusing a lot on improving or educating the user base, making sure they’re comfortable with the use of those models, that they feel it is beneficial to them in their work, and they’re going to adopt it and give you feedback on what can be done to improve it.”
That calls for a close relationship between technical teams and the business. Training users and gathering feedback are part of improving the product, not tasks to postpone until after engineering is complete. Adoption can also change how a workflow operates, so teams should account for user behavior when they design and evaluate the system.
What may expand enterprise use
Zutshi sees three developments shaping enterprise AI. First, organizations are getting more model choices, including a wider range of high-quality open-source large language models. More options could give businesses greater control and flexibility, with potential cost advantages; the trade-offs will depend on the use case and the resources needed to operate each model.
Second, systems are moving beyond simple chatbot exchanges toward models that use tools and complete multi-step tasks. Zutshi describes agents that could handle a sequence such as arranging travel. The practical test will be whether these systems can complete those steps reliably within the intended workflow.
Third, he expects new kinds of data to matter as the gains from traditional data become harder to find. He points to chain-of-thought data as a possible way to help models represent aspects of human reasoning and tackle more involved problems. How much this contributes in practice remains an open question, but it highlights the close link between data innovation and model capability.
The operational lesson is straightforward: production AI is a product, a data practice and a change in how people work. Teams should set application-specific measures, maintain governed data and development processes, and build user feedback into the cycle. Zutshi also describes the personal demands of a connected technology role; hiking without cell service gives him time to be present with his family. For enterprise teams, the parallel is useful: systems need ongoing attention, but their value ultimately depends on fitting into human work.