AI projects should start with a business metric and keep measuring that metric as the system changes.
2
Enterprise AI needs consistent data standards, governance, and release processes because data restrictions and use cases keep changing.
3
Generative AI systems need human evaluation, access-control checks, and ongoing monitoring because their outputs are difficult to score automatically.
Summary
This panel gives a practical view of what enterprise AI systems need after the prototype stage. Rama Akkiraju says teams should define the business outcome first, such as reducing incident resolution time or helping planners run what-if analyses faster, then measure progress against a baseline. Nitin Aggarwal separates business measures such as efficiency and revenue from system measures such as latency, throughput, and availability. Steven Eliuk focuses on consistent data standards, since common definitions make it easier to find, combine, govern, and reuse data across a large company. The panel also discusses new risks from generative AI, including improperly protected documents becoming searchable through language models and vector databases. Generative AI evaluation takes longer because natural-language answers often need human judgment. The panelists recommend independent evaluation, continuous monitoring, access-control work, and release platforms that can apply improvements across many use cases.
AI projects need a measurable business outcome before technology choices
Rama Akkiraju says AI is a means to an end, and that end is a business metric. For IT operations, a team might establish baselines for mean time to detect, diagnose, and resolve incidents, along with the number of incidents and their business impact. It can then test whether incident summarization, anomaly detection, alert-noise reduction, or chat capabilities improve those measures. For supply-chain planning, the relevant measure might be how long a planner needs to run a what-if analysis. She also warns against adding a conversational interface when one click or automation would solve the task more directly.
Production systems must track business measures and system behavior
Nitin Aggarwal says production AI systems usually aim at operating efficiency or new net revenue. Teams also need to identify the end user, the integration pattern, the platform, and the metrics already being monitored. Traditional measures such as precision, recall, F1 score, and accuracy remain relevant in some settings, while language systems bring other evaluation measures. System-level measures such as latency, throughput, and availability still matter. Users expect increasingly immediate responses, so an otherwise small delay or a single failure can become unacceptable for a particular application.
Consistent data standards make large-scale integration possible
Steven Eliuk argues that data silos cannot simply be removed because some data must remain restricted. Common standards let teams search for comparable data, apply the same privacy definitions, and bring together information for a use case. Standards also help with regulation, return on investment, and sustainability. Data movement can be limited by country rules, geography, sovereignty, latency, and access requirements. The team must understand those constraints before deciding whether to move or cache data. Eliuk says inconsistent approaches may work in a small company, but they do not scale across a large enterprise.
Generative AI can expose documents that were already poorly protected
Rama Akkiraju describes a new data risk created by generative AI search and summarization. Enterprise documents with weak permissions can become easy to find when language models and vector databases are added to the search process. Before making data searchable, teams may need to classify sensitive documents and correct their permissions. Generative AI responses also need citations, references, and pointers to the relevant source text so users can establish trust. These controls add work beyond the normal concerns of data quality and integration.
LLM operations changes the assumptions behind CI/CD and model management
Nitin Aggarwal says language-model systems do not follow the same pattern as traditional model training and retraining. A team may choose retrieval-augmented generation or fine-tuning instead of retraining a model on newly collected data. That changes how teams think about continuous integration, continuous delivery, model versioning, and model management. He also cites analysis from the Stanford HAI team that found more hallucination in legal reports than in retail or marketing data. His point is that evaluation depends on the availability and nature of the domain data.
Independent evaluation and continuous monitoring should continue after release
Steven Eliuk recommends assessing what happens when a use case is wrong, including false positives and false negatives. A model can perform well at launch and degrade after a week, month, or later, so teams need automation and tools that validate whether it still behaves as expected. He says the group that built a model should not define its evaluation criteria alone, because it may choose measures that present its work favorably. An outside group, audit committee, or red team can provide another view. A common release platform also lets improvements benefit multiple projects.
Generative AI testing takes longer because natural-language answers need judgment
Rama Akkiraju says traditional models can often be tested against representative datasets with ground truth and an accuracy threshold. A chatbot or summarization system produces natural-language answers whose quality can be subjective. An LLM can act as a judge, but humans still need to assess many responses. One NVIDIA chatbot took six to eight weeks to build its first version, while deployment took about three months because sensitive documents had incorrect access controls. Bots using more public data reached production faster. The panel's practical advice is to test repeatedly, use representative data, set thresholds, and involve intended users.
Responsible AI evaluation still lacks a universal standard
Nitin Aggarwal says labels for toxicity, unfriendliness, and adult content provide some measurable signals, but subjective qualities such as relatability and likeness remain difficult to quantify. He does not see one framework that can be treated as a universal answer. The evaluation problem also changes as the model, retrieval data, and criteria change. Users share responsibility by testing a model within its intended use cases instead of trying to make it handle every possible task. Teams should include model-update frequency and changing inputs in the cost of operating an AI use case.
Enterprise AI is moving from standalone language models toward composed workflows
Rama Akkiraju says early generative AI work focused heavily on language models, but production chatbots also depend on accurate retrieval. The next stage combines retrieval, language models, agents, and orchestration, which brings the work closer to software engineering. She describes language models as tools for automation that can make AI available to business users as well as data scientists and engineers. Steven Eliuk adds that organizations now have broader access to internal and external data, and that this access is likely to keep expanding.
"It's really the good old software engineering where you have good agents, good orchestration, that's bringing everything together with good retrieval and good LLMs."Rama Akkiraju34:18
Who should watch
You are taking an enterprise AI proof of concept toward production and need a way to define business, system, and risk measures.
Your organization has data silos, inconsistent standards, or document permissions that could affect search and generative AI.
You are building evaluation and monitoring for chatbots, retrieval systems, or other language-model applications and need to account for human judgment.
