As AI Moves Into Critical Infrastructure, One Engineer Is Focused on the Question Most Companies Are Still Avoiding

Sept. 2 2026, Updated 1:03 p.m. ET
Nikhil Goel’s work at Theom.ai sits inside one of enterprise technology’s most difficult transitions: making artificial intelligence useful enough to matter and controlled enough to trust.
In April 2026, the National Institute of Standards and Technology sharpened a question that had already been circulating through boardrooms, security teams, and engineering organizations: What does trustworthy artificial intelligence look like when it is used within critical infrastructure?
For most consumers, AI still arrives as a polished interface. A chatbot answers a question. A tool summarizes a document. A software assistant drafts code. The experience can feel almost frictionless.
Within a large financial institution, the same technology raises a more difficult set of questions.
What data did the system access? Which employee’s authority was it acting under? Was it allowed to combine one data set with another? If it produced a recommendation, can the institution explain how it got there? If it took an action, can that action be audited later?
Those are the questions that have shaped Nikhil Goel’s work.
Goel is a Founding Engineer and Engineering Manager at Theom.ai, a cloud data security and AI governance company whose platform is used by major U.S. financial institutions. His role is not the kind that typically produces a public profile. He is not a celebrity founder, a keynote regular, or a policy voice speaking from a distance. He works closer to the infrastructure layer, where the problems are less visible and often more consequential.
That is also what makes his story timely.
Financial services have long been treated as part of the country’s critical infrastructure, and for good reason. A failure inside a major bank or asset manager is rarely just an internal technology incident. It can have regulatory, customer, market, and systemic implications. As AI moves deeper into that environment, governance is no longer a back-office compliance exercise. It becomes a question of operational trust.
“When generative AI arrived, a problem that had been building quietly for years became urgent almost overnight,” said Navindra Yadav, CEO and co-founder of Theom. “The hard part is not describing that risk. Everyone can describe it. The hard part is building systems that hold up inside a large enterprise’s real data volumes. That is the work Nikhil has been at the center of.”
Goel came to this work through systems engineering. Before Theom, he worked at Qualcomm on 4G and 5G modem systems, an environment where reliability and precision are not optional. He later worked as a research intern at Microsoft Turing, contributing to infrastructure connected to large-scale document systems. Earlier still, he built machine learning models at Flipkart.
The common thread was not simply software. It was software under pressure.
At Theom, that pressure arrived quickly. Goel joined the company at the seed stage and helped build the core platform from the ground up. At the time, enterprises were already moving sensitive data into cloud platforms faster than many traditional security tools could follow. Data no longer lived neatly in one database with one owner and one clear boundary. It moved through warehouses, SaaS applications, analytics tools, transformation systems, and external services.
Then generative AI changed the timeline.
A problem that had been building for years suddenly became urgent. If data was already hard to track across cloud systems, it became even harder once AI tools began reading, summarizing, interpreting, and acting on that data. The older security model assumed a human user, a known application, and a relatively clear access path. AI agents blur those lines.
One meeting in particular stayed with Goel. During a conversation with a security team at a large U.S. bank, someone asked whether Theom could control what an LLM was allowed to do on behalf of an employee. At the time, the question still felt somewhat ahead of the market. Within months, it no longer did. Employees across large institutions were experimenting with tools that could read documents, draft messages, analyze internal information, and potentially take actions under a human identity.
That shift helped shape one of Goel’s lead patent filings, focused on identity-aware security for LLMs and AI agents. The idea is straightforward in concept but difficult in practice: an AI system acting for a person should not exceed the access rights, compliance boundaries, or audit expectations that apply to that person.
Another patent filing on which Goel is the lead inventor addresses data lineage across opaque transformations. In plain language, it focuses on tracking data even when it moves through systems that do not naturally explain how information has changed. That problem has become increasingly important as enterprises rely on layered cloud data architectures where sensitive information can be transformed, combined, and reused many times.
According to company materials, Goel has been named as an inventor on four patent filings in the past year related to Theom’s platform. Two list him as the lead inventor. The company says the underlying technologies are deployed in production at major U.S. financial institutions.
Those claims are notable, but they also sit within a crowded and highly competitive market. Cloud providers, cybersecurity companies, governance platforms, and AI infrastructure startups are all trying to solve pieces of the same problem. Some focus on model safety. Others focus on data loss prevention, identity, compliance workflows, or application security. The challenge for companies like Theom is not merely to describe the risk, but to prove that their systems can operate inside the messy, high-volume environments where regulated enterprises actually work.
Goel’s most revealing example is not a patent filing. It is a scaling problem.
During one of Theom’s early large financial deployments, the company’s platform encountered a customer operating at a data volume far beyond what earlier deployments had required. The system had worked well before. Then queries began timing out.
According to Goel and company materials, the core data processing engine had originally handled roughly 100,000 queries per day. As Theom onboarded larger institutions, that same engine eventually needed to support more than 500 million queries per day while reducing average response times from about two seconds to roughly 200 milliseconds.
Goel spent weeks reworking the system. He redesigned the query path, changed how data was partitioned, introduced parallel and distributed processing, and added the observability and fault tolerance needed for production use. It was the kind of engineering work that rarely appears in public AI narratives because it happens beneath the product surface. But for large institutions, that is often where trust is built or lost.
“The scaling work Nikhil led took our core engine from roughly 100,000 queries a day to supporting more than 500 million, while cutting response times by an order of magnitude,” said Ravi Sankuratri, COO and co-founder of Theom. “It is the kind of contribution that rarely surfaces publicly, but it is exactly what large institutions are paying for.”
People who have worked in enterprise software know that this is where many promising products fail. A platform that works in a controlled demo can behave very differently when it meets the volume, complexity, and risk expectations of a major bank. The difference between the two is not marketing. It is architecture.
Goel’s role has also expanded beyond individual technical ownership. He now leads an engineering team while remaining involved in architecture decisions, code reviews, and hiring. According to company materials, he is the principal hiring manager for engineering at Theom and has helped build the technical interview process used to evaluate candidates globally. The company says its engineering team has tripled in size since he took on that hiring role.
That detail matters less as a management credential than as a window into how he thinks. Goel’s standard for engineers is rooted in a principle he repeats often: no one should ship code they cannot explain.
In an era of AI-assisted development, that principle sounds almost old-fashioned. It is not. AI tools can generate code quickly, but speed can disguise risk. In security-sensitive environments, working code is not enough. Engineers need to understand why it works, where it fails, and what assumptions it depends on.
That belief connects Goel’s management style to his technical work. Whether the system is a data lineage engine, an access-control layer for AI agents, or a hiring process for engineers, his emphasis is on clarity under pressure.

There is still uncertainty around how enterprise AI governance will evolve. Regulators are moving. Standards bodies are developing frameworks. Large companies are experimenting with internal policies. Vendors are racing to define categories. Some of today’s approaches will last; others will disappear.
That uncertainty is part of what makes Goel’s work relevant. He is building in the period before the rules are fully settled, when technical practice and governance expectations are still shaping each other.
The public conversation around AI often rewards the most visible breakthroughs: bigger models, faster assistants, more dramatic demos. But inside critical institutions, the more important breakthrough may be quieter. It may be the ability to prove that an AI system acted within the right boundary, touched only the right data, and left behind enough evidence for the institution to trust what happened.
Goel is not trying to make AI sound more magical. His work is focused on making it more governable.
That may be the less glamorous side of the AI race, but it is increasingly the side that determines whether the technology can be used where the stakes are highest.


