By Jay KT
A Dallas engineer working on the frontlines of American healthcare technology is raising an uncomfortable question: what happens to your personal data when artificial intelligence wants access to everything? His answer now spans academic research, enterprise engineering, and a new initiative called TRUST.AI.
Every time you visit a hospital, see a specialist, or have a lab test processed, your medical data travels through a network of software systems that most patients never think about. Who built those systems? Who decided how your information is stored, accessed, and protected? And when artificial intelligence starts asking for access to that data in order to deliver faster diagnoses or better treatment outcomes, who decides what the AI can see?
For Prasanth Kumar Chevva, a Senior Software Developer at DaVita Inc. in Dallas, these are not hypothetical questions. They are the practical engineering challenges he encounters contributing to enterprise software systems that support healthcare operations at one of the country’s largest kidney care organizations. And they are the subject of research he has been publishing in the academic literature, work that argues, in precise technical terms, that the way most organizations handle data today is not good enough.
His position is not that technology is the problem. It is that the wrong architecture is the problem and that the right architecture, built correctly from the start, can give people the benefits of AI and data analytics without asking them to surrender control of their most sensitive information.
“Privacy is not a feature you add at the end. It is a structural decision you make at the beginning. Once your architecture assumes centralization, every privacy protection you build on top of it is fighting against the grain.”
The Problem with Centralization
To understand what Chevva is arguing, it helps to understand how most data systems work today. When you use a health app, visit a hospital portal, or participate in a clinical trial, your data is typically sent to a central server, a database owned and operated by a company or institution. From that central store, the data can be analyzed, shared with partners, used to train machine learning models, or, in the worst cases, stolen in a breach.
The appeal of centralization is obvious: it is simple, it is fast, and it makes analytics easy. The problems are equally obvious, even if they are less often discussed. Centralized stores are single points of failure. They concentrate risk. And they place the user in a position of permanent dependency on whoever controls the central system to handle their data responsibly.
Chevva’s published research proposes a different model, which he calls the Personal Web Observatory, a distributed architecture in which data stays on the user’s device or local environment, and the analytics travel to the data rather than the data travelling to a central server. The result is a system that can generate the same insights a centralized system would generate, such as health trends, usage patterns, and anomaly detection, without ever requiring the raw, identifiable data to leave the user’s control.
Why This Matters for Healthcare Right Now
American healthcare is currently in the middle of a technology transformation that is generating real benefits and real risks simultaneously. AI systems can now detect certain cancers in medical images with accuracy that rivals radiologists. Predictive algorithms can flag patients at risk of readmission before they leave the hospital. Natural language processing can extract insights from clinical notes that would take a human researcher months to analyze.
But each of these applications requires data. Enormous amounts of it. And the pressure to aggregate that data, to pool it from multiple hospitals, insurers, and health systems into single large training sets, creates exactly the kind of centralization risk that Chevva’s research is designed to address.
He is not alone in identifying this tension. The concept of federated learning, training AI models across distributed data sources without centralizing the underlying data, has gained significant traction in both research institutions and healthcare companies. What Chevva’s work adds is a practical architectural framework for implementing this kind of approach at the individual user
level, not just the institutional level. The question he is trying to answer is not just how hospitals share data safely, but how a person owns their data in a world that increasingly treats data as a commodity.
“The AI can learn from my health data and give me better recommendations. I want that. What I do not want is for my raw data to sit in a server I do not control, vulnerable to a breach I will hear about in a letter three years from now.”
A Decade inside the Systems That Touch Your Care
Chevva’s perspective on data in healthcare is not theoretical. He has spent the better part of a decade working inside the systems that process, store, and protect patient information at scale. His career spans enterprise software engineering across healthcare and technology sectors, giving him a cross industry view of how large scale data systems behave across different compliance environments and how the fundamental tension between data utility and user privacy is rarely resolved in the user’s favor.
“What you notice when you work across different sectors is that the data problems are actually very similar. The sensitivity of the data varies. The compliance frameworks vary. But the fundamental tension between utility and privacy is the same everywhere. And it is rarely resolved in the user’s favor.”
From Research to Product: The TRUST.AI Initiative
The same convictions that shaped his healthcare research have now carried Chevva into technology entrepreneurship. He is the creator and research lead of TRUST.AI, an early stage research and product development initiative exploring an explainable, privacy first trust layer for digital communication. The project, presented at trustairesearch.com, tackles a problem almost everyone recognizes: digital communication has become easier than ever, but trust has not.
Every day, people interact through email, SMS, WhatsApp, phone calls, websites, QR codes, and AI assistants, yet there is still no universal way to determine whether a digital interaction should be trusted before responding, clicking a link, sharing information, or making a financial decision. Phishing emails, scam messages, fake recruiters, fraudulent payment requests, and
impersonation produced by AI have turned that gap into one of the defining consumer safety problems of the decade.
TRUST.AI is Chevva’s attempt to close it. The initiative already has a working public MVP that lets users paste a suspicious message, link, payment request, job offer, or document request and receive an AI assisted risk assessment in seconds, complete with a trust score and a plain language explanation of the exact signals that drove the assessment, such as an unverified sender, a newly registered domain, or a known scam pattern. For organizations, the roadmap envisions verified sender identities, approved payment and document registries, and public audit trails, so customers never have to guess whether a message from a business is genuine.
What connects the venture to his academic work is its architecture of restraint. TRUST.AI is being built around responsible AI principles: collect only the information necessary for risk assessment, explain every conclusion in language users understand, clearly distinguish verified identities from inferred signals, monitor the system for bias and error, and always leave the final decision with the human being. The system is designed to support judgment, not replace it.
The initiative is currently in a public validation stage, and Chevva is actively seeking collaboration from researchers, cybersecurity professionals, businesses, universities, and individuals affected by digital fraud. Later phases of the roadmap include pilot programs, browser tools, business verification services, and independent security and privacy evaluation. It is, in effect, the consumer facing continuation of the argument he has been making in healthcare all along: that trust should be engineered into a system from the first line of code, not patched in after something goes wrong.
Recognition From IEEE and the Research Community
Chevva’s research contributions have been recognized by the technical community beyond the publication of individual papers. He holds the status of IEEE Senior Member, a designation from the world’s largest professional technical organization that reflects sustained and significant contributions to engineering, and serves as a reviewer for academic journals and international conferences in distributed systems, cloud computing, and AI applications.
He has also served as a technology judge and invited speaker at industry forums, contributing to the evaluation of emerging technologies and sharing his perspectives on architecture, privacy, and the responsible deployment of AI systems in high stakes environments.
His second published paper, on optimizing microservice deployment using Docker and cloud based registries, reflects a complementary preoccupation: not just how systems should be designed for privacy, but how they should be deployed for reliability and scale. In healthcare, these two concerns are inseparable. A system that is private but fragile is not good enough. A system that is robust but leaky is worse.
What Patients Should Know
For most patients, the software that handles their medical data is invisible. It works or it does not. It protects their information or it does not. Most people do not have the technical literacy to evaluate what is happening to their data inside a hospital’s systems, and most healthcare institutions do not make it easy to find out.
Chevva’s argument, in his research, in his engineering practice, in his work on TRUST.AI, and in the conversations he has at industry events, is that this invisibility is a design choice, and it can be reversed. The architecture of privacy first systems is not significantly more complex than the architecture of systems that treat privacy as an afterthought. The difference is in the sequence of decisions: when you decide that privacy matters, and whether you make that decision before or after you have already built the thing.
“Patients trust us with the most personal information that exists. That trust should be the starting constraint, the thing we build around, not the last thing we remember to protect.”
