Large language models can reveal patterns in public data that create privacy risks beyond the data itself.
2
Enterprise teams should keep confidential data inside their security perimeter instead of sending it to public APIs.
3
Reliable production applications need large language models alongside traditional machine learning, rules, and heuristics.
Summary
This panel discusses privacy, security, trust, and practical adoption of large language models. Vin Vashishta argues that models can uncover complex patterns in public data, creating risks that are easy to miss when teams focus only on the data itself. Saahil Jain describes hallucination as both a technical problem and a product problem, since users need clear expectations about what a system can and cannot do. Shreya Rajpal recommends grounding model outputs in trusted sources and adding constraints with external data, rules, or tools. Gevorg Karapetyan advises enterprises with confidential data to bring models inside their own security perimeter rather than sending that data to public APIs. The panel also stresses that use cases should be judged by business value and risk. Internal applications are a safer place to test. The final advice is to combine language models with traditional methods when production systems need dependable behavior.
Large language models can expose patterns hidden inside public data
Vin Vashishta says privacy and security concerns now extend beyond the original data. As models become more capable, they can uncover increasingly complex patterns in information that people publish. He cites a study from Pepperdine in which creative prompting produced a convincing venture capital pitch in the style of different venture capitalists. His point is that social media and other public datasets can reveal deeper patterns about people and organizations, creating vulnerabilities even when a team is not directly exposing a private record.
Hallucination needs both technical controls and product design
Saahil Jain separates two parts of the hallucination problem. Teams can work on technical methods such as reducing hallucinations and grounding models in reliable information. The product also needs to set the right expectations, because a hallucinating model can still be useful in some situations. Users should understand where the system may mislead them and how to use its output responsibly. For Jain, safety depends on how the model works and on how the surrounding product presents and limits it.
Grounding and constraints are more practical than eliminating hallucination everywhere
Shreya Rajpal describes hallucination as a group of problems, including false claims and conflicts between sources. She recommends grounding outputs in trusted data and checking generated answers against domain-specific sources, tools, agents, or embeddings. Bigger or better-trained models may reduce some errors, but Rajpal says machine learning systems are unlikely to provide complete certainty. Her approach uses a language model for generation, then applies constraints and validation that match the needs of a particular application.
Confidential enterprise data should stay inside the enterprise security perimeter
Gevorg Karapetyan says enterprise customers already see the potential of generative AI, but their data often belongs to clients and is subject to contractual obligations. For confidential use cases, he advises against using public ChatGPT APIs. Instead, organizations can run smaller models inside their own security perimeter, fine-tune them on domain data, and improve the product through human feedback. He says enterprise adoption depends on trust. If users lose confidence in the system, they will stop using it.
Teams should choose deployment methods according to risk and value
Diego Oppenheimer argues that organizations should not apply one deployment pattern to every use case. Some situations may justify a fast, inexpensive API, while others require models and data to remain inside the enterprise. The latter option costs more and needs specialized knowledge. The decision should account for privacy, security, and the value of the application instead of treating every project as equivalent.
Internal use cases provide a lower-risk way to test ideas
Vin Vashishta recommends starting with targeted opportunity discovery and studying problems that other industries have already solved. Internal applications are useful proof-of-concept environments because the risks are lower than exposing a system directly to customers. He says companies should ask where customer queries go, how they are stored, and what privacy obligations follow from using them. Teams should connect a proposed use case to a clear return before interrupting their existing business strategy.
Production systems need language models alongside traditional controls
Shreya Rajpal says current models are powerful but are not automatically ready for reliable production deployment. Her proposed approach combines large language models with traditional machine learning, rules, and heuristic methods. This hybrid design can retain model performance while adding the reliability and safety constraints needed by an application. She presents Guardrails as a tool for adding those checks, while stressing that the broader pattern is the combination of model generation with conventional control methods.
"When we think about data privacy and data security with respect to these types of models, it's no longer the data itself. It is the patterns within the data that can be uncovered and create vulnerabilities."Vin Vashishta06:36
Who should watch
You are deciding whether a confidential AI application should use a public model API or run inside your own security perimeter.
Your team is building a language-model product and needs practical ways to handle hallucinations, grounding, user expectations, and validation.
You are evaluating AI opportunities and want to test lower-risk internal use cases before exposing a system to customers.
