This Engineer Is Turning AI Policy Into Working Code. Here’s His Playbook for Building Systems That Hold Up.
As AI enters regulated industries, engineers like Theom’s Nikhil Goel are working on how to enforce governance rules in code.
When the National Institute of Standards and Technology began developing a profile for trustworthy artificial intelligence in critical infrastructure, it confirmed what banks, utilities and other regulated operators already knew: AI is inside sensitive environments now, and “responsible AI” can no longer live in a policy document. It has to run in production.
Nikhil Goel has spent the past several years on the front line of that shift. As a founding engineer and engineering manager at Theom.ai, he helps build the cloud data security and AI governance systems that major U.S. companies rely on to keep AI tools inside their rules. In the past year alone, he has been named an inventor on four patent filings tied to Theom’s platform, including lead inventor on two, while rebuilding a core engine to handle a 5,000-fold jump in query volume and tripling the company’s engineering team as its principal hiring manager.
That combination of invention, scale and team-building is rare, and it maps almost exactly onto where the industry is heading as NIST pushes AI governance from aspiration to implementation. In conversations about his work, Goel shared the strategies, tactics and mindset shifts that helped him get there. They are lessons any founder or engineering leader building for high-stakes customers can put to use.
Recognize When a Theoretical Problem Becomes Real
Goel’s first lesson is about timing. The opportunity in enterprise AI security did not arrive with fanfare; it arrived as a change in the questions customers asked.
“Two years ago, ‘how do you secure an LLM’ was a theoretical question,” Goel said in describing the shift. “Today it is something every enterprise I work with is actively trying to solve.”
Generative AI compressed what might have been a decade-long governance debate into an urgent engineering problem almost overnight. Institutions still learning to secure cloud-native data flows suddenly faced AI agents that read, summarize, combine and act on sensitive information faster than any employee could.
The takeaway for entrepreneurs: Watch for the moment your market’s hypothetical concern becomes a live one, and be ready to ship before your competitors finish describing the problem. “The hard part is not describing that risk. Everyone can describe it,” said Navindra Yadav, Theom’s CEO and co-founder. “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.”
Build for the Scale You Haven’t Hit Yet
Early in one of Theom’s financial deployments, the company landed a customer whose data volume dwarfed anything the platform had seen. Queries that once returned in seconds began timing out.
The core data processing engine had originally handled roughly 100,000 queries per day. In the larger environment, it eventually needed to support more than 500 million queries per day while cutting average response times from about two seconds to roughly 200 milliseconds.
Rather than patch the timeouts, Goel redesigned the query path, changed how data was partitioned, introduced parallel and distributed processing, and strengthened the observability and fault tolerance the system needed for production use.
“What stood out was not that Nikhil fixed the timeouts,” said Danesh Irani, Theom’s vice president of engineering. “It was that he rebuilt the engine so the next jump in scale would not surprise us. That kind of forward design is rare, and it is a big reason we can operate inside our largest customers’ environments today.”
The lesson: When growth breaks something, resist the quick fix. Rebuild for the customer two sizes bigger than the one in front of you, because in enterprise sales, that customer is your next deal.
Turn Your Policies Into Something You Can Enforce
Plenty of companies have a responsible AI policy, a risk committee and an approval process. Goel’s view is that none of it matters unless the underlying systems can enforce those rules at scale and prove it afterward.
Consider the questions his customers face daily: If an employee can see one category of information but not another, should an AI agent acting for that employee inherit the same access? If the agent summarizes a restricted document, does the summary carry the same restrictions? If it combines data from several systems, can anyone still say which policies apply?
Goel’s answer has been to engineer those boundaries directly into the platform. One of his patent filings addresses data lineage across black-box transformations, meaning the ability to know where information came from, how it changed and where it went, even when systems don’t explain themselves. Another focuses on identity-aware security for large language models and AI agents, keeping an AI inside the same access controls and audit trail as the person it represents.
“Patent applications are easy to file and hard to make real,” Yadav said. “What matters about Nikhil’s is that the ideas behind them … are running in production at major financial institutions, not sitting on a shelf.”
For founders, the principle travels well beyond security: A promise your product can’t demonstrate under audit is not a feature. Build the evidence in.
Don’t Ship Code You Can’t Explain
AI-assisted development can make engineers dramatically faster. It can also tempt teams to accept systems they have not fully examined. Goel holds his teams to a standard that predates the AI boom: Engineers should not ship code they cannot explain.
In a consumer app, unexplained code is a productivity risk. In a bank or a utility, it can become a governance failure. An AI tool that works in a demo but cannot say what it accessed or why it produced a result may never make it into a high-stakes environment. As NIST’s critical infrastructure profile takes shape, the bar is moving from “is the model accurate?” to “can you prove it stayed inside its authorized boundaries?”
Leaders who adopt that standard early, Goel’s experience suggests, won’t be scrambling to retrofit explainability when auditors and customers start demanding it.
Hire People Who Can Carry the Judgment
Tools and frameworks only go so far. As Theom grew, Goel became the principal hiring manager for engineering, responsible for recruitment globally, including in the United States. The engineering team tripled in size after he took the role, and he built the technical interview process used to evaluate candidates.
That focus was deliberate. Critical infrastructure AI depends on engineers who understand failure modes, data movement, identity boundaries and the expectations of regulated customers. That kind of judgment is not something a framework supplies on its own. Designing the interview process himself meant every new hire was screened against the standard the customers required, not just for raw coding skill.
The lesson for any founder scaling a technical team: Treat your hiring process as a product. If you want systems that hold up under scrutiny, hire people who already think that way, and build the pipeline that finds them.
NIST’s profile is still developing, and no framework will settle every question in enterprise AI.