Artificial intelligence is reshaping far more than model benchmarks and chatbots. Across the enterprise, it is transforming how organizations engineer their data infrastructure, secure their cloud environments, and extend intelligent systems into domains as varied as manufacturing, agriculture, and environmental science. Few professionals have engaged with that shift from as many angles as Somnath Banerjee.
With more than a decade of experience spanning enterprise data engineering, cloud security, artificial intelligence, and sustainability research, Somnath has built a career at the intersection of applied engineering and academic research. As an AI Data Engineer, IEEE Senior Member, international conference session chair, peer reviewer, and published researcher, he has helped organizations build resilient, intelligent data platforms while contributing to the broader research community through publications, conference leadership, and research review work extending as far as a national research funding initiative in Germany.
In this interview, Somnath shares his perspective on how enterprise data engineering is evolving in the age of AI, what genuine progress on AI-driven sustainability looks like versus what’s still hype, the leadership lessons behind the recognition his research has earned internationally, and why he believes the organizations that lead in the AI era will be the ones that treat trustworthy data as a foundation rather than an afterthought.
Your career has evolved from enterprise data engineering into AI-driven cloud architecture, sustainability research, and international research leadership. Looking back, what has driven that evolution, and how has it influenced the way you approach innovation today?
When I began working in enterprise data engineering, my primary responsibility was making sure large, high-volume systems stayed reliable, accurate, and available under real operational pressure. It was a role that demanded precision and a genuine understanding of how organizations actually depend on their data, not just how a pipeline is supposed to work on paper. That foundation taught me that a data system isn’t valuable because it’s sophisticated, it’s valuable because people trust it enough to act on what it tells them.
As the field evolved, I saw a bigger opportunity than just keeping systems running. The discipline was moving from managing infrastructure toward building infrastructure that could reason about itself, systems that could flag their own problems, adapt to changing load, and eventually feed AI models directly. Rather than treating cloud architecture, security, and artificial intelligence as separate specialties, I started treating them as one continuous problem: how do you take a large, messy, high-volume stream of data and turn it into something a system, or a person, can actually trust and act on.
That question is also what pulled me toward research and toward sustainability specifically. I kept noticing that the same discipline that makes a security pipeline trustworthy applies just as directly to environmental data — water quality, soil composition, energy consumption — if you’re willing to take it there. Publishing that work, and getting involved in peer review and conference leadership, reinforced something I keep coming back to: innovation gets stronger when it’s shared and stress-tested by people outside your own organization, not just validated internally.
Looking back, I don’t think my work has been defined by chasing whatever’s newest. It’s been defined by one recurring question whenever a new problem shows up: is this system trustworthy enough for something else — a person or a model — to act on without checking my work first? That question still shapes everything I take on.
Innovation is often associated with breakthrough new models, but some of the most meaningful advances come from questioning an existing approach. Can you share an example from your research where rethinking a well-established assumption led to a far-reaching result?
One piece of research that stands out is my work on deepfake detection. At the time, most detection models were built the same way: train a network once against a known set of manipulation techniques, hand-tune the architecture for that dataset, and ship it. That worked reasonably well right up until someone used a manipulation technique the model hadn’t seen, at which point accuracy dropped fast. Like a lot of established processes, it had just become ‘the way detection models are built.’
Instead of trying to hand-tune a slightly better version of the same architecture, I asked a different question: why does the architecture have to be fixed at all? That became the starting point for combining YOLO-based facial segmentation with Neural Architecture Search, so the model configuration itself keeps adapting rather than staying frozen at whatever the training data looked like on day one. The result reached 99.04% accuracy on the Celeb-DF v2 benchmark, but the part that mattered more to me was that it stayed lightweight enough to run in real time, which is what actually makes it deployable for things like media forensics and identity verification instead of just a benchmark exercise.
What that project changed for me wasn’t just the specific result, it changed how I approach a new problem generally. I stopped asking ‘how do I make this specific step better’ and started asking ‘why does this have to work this way at all.’ That question has shaped every project since, whether it’s cloud security architecture or an environmental monitoring system, because the biggest gains rarely come from optimizing an assumption — they come from questioning it.
Technology has transformed dramatically over the past several years. Looking back, which shift fundamentally changed the way you think about enterprise data engineering?
The biggest shift wasn’t the move to cloud infrastructure by itself, it was the move from managing data to building systems trustworthy enough for something else to act on autonomously. Early on, success meant a pipeline ran on schedule and the numbers reconciled. That’s still necessary, but it’s no longer sufficient. Organizations now expect the same data to feed a model that makes a decision without a person checking it first, which is a much stricter bar.
Cloud computing was the first catalyst, because it forced organizations to rethink architecture instead of just relocating it. Automation followed, replacing manual, rule-based processes with consistent, scalable workflows. What AI adds on top is the expectation that the system itself can flag a problem — a schema drift, a data quality issue, an emerging bottleneck — before it silently corrupts whatever depends on it downstream.
The realization that’s mattered most to me is that data engineering, security, and AI can’t really be treated as separate disciplines anymore. They’re one connected system, and the organizations that succeed are the ones that engineer for that connection deliberately, rather than bolting AI onto infrastructure that was never built to be trusted at that level.
Everyone is investing in AI, yet many organizations struggle to realize its value. What do you think they’re overlooking?
Most organizations are treating AI as a technology purchase instead of a data and trust problem. They’ll invest heavily in models and tooling while the actual foundation — data quality, governance, and a clearly defined problem worth solving — gets far less attention. AI is only as good as the environment it’s operating in, and that environment is usually the part nobody wants to spend the budget on.
There’s also an expectation of immediate results that doesn’t match how this actually plays out. Adopting AI well is a multi-year discipline, not a deployment. The organizations I’ve seen get real value are the ones that start from a specific, measurable problem, and treat the model as one component of a larger system rather than the whole solution.
I’d also push back on the framing of AI as a replacement for expertise. In the environmental and security work I do, AI is excellent at finding patterns across more data than a person could review manually. It’s not a substitute for the judgment of deciding what those patterns actually mean, or what to do about them responsibly. The organizations that get this right treat AI as something that sharpens human judgment, not something that replaces the need for it.
If cloud migration was the first chapter of enterprise data transformation, what does the AI era change?
Cloud migration was about scale — it let organizations handle far more data than on-premises infrastructure ever could. AI changes something more fundamental: it moves the system from executing predefined rules to interpreting information and anticipating what’s about to happen. A traditional pipeline moves and transforms data on a schedule. An AI-aware system can flag an anomaly before it becomes an incident, or predict a capacity problem before anyone requests more resources.
That shift changes what data engineers actually spend their time on. Less time on the repetitive mechanics of keeping a pipeline running, more time on the architecture and governance decisions that determine whether the AI layered on top of that pipeline can actually be trusted. It’s less about working faster and more about the system getting genuinely smarter about the problems it’s built to catch.
To me, that’s the real difference between automation and this current era. Automation executes. AI increasingly has to reason, at least within a narrow, well-defined scope, and that’s a fundamentally different engineering problem than the one most data platforms were originally built to solve.
Looking beyond the formal sessions, what are the hallway conversations at conferences like IEEE SISIMPACT and GC4T telling you about the future of enterprise AI and sustainability?
Chairing sessions gives you a slightly different vantage point than presenting, because you spend the whole track listening to how the audience reacts and what they ask afterward, not just what’s on the agenda. A couple of years ago, most of those conversations were about getting a model deployed at all. Now, almost every conversation eventually turns to a much more specific question: how do we actually measure whether this is working, and what’s it costing us to run.
That’s especially true in the sessions that touch on sustainability. People aren’t asking whether AI can help the environment anymore — that part’s assumed. They’re asking how you actually validate a claim like that: what’s being measured, over what timeframe, against what baseline. It’s a much more skeptical, much more specific set of questions than a few years ago, and I think that’s healthy. It means the conversation is maturing past the pitch stage.
The other pattern I keep noticing is how much the roles are blending. I’ve had conversations with data engineers who are now expected to understand model governance, and with domain researchers — agricultural scientists, environmental scientists — who are being asked to evaluate AI proposals in fields adjacent to their own. That blending is exactly what led to me reviewing a robotics and AI proposal for a German ministry-funded agricultural research initiative last year, well outside my own core specialty. The traditional boundaries between roles are genuinely fading.
If you had the opportunity to build an enterprise data platform from the ground up today, what would you do differently in the age of AI and sustainability, and what mistakes would you avoid?
I’d start from a simple principle: efficiency and sustainability shouldn’t be a layer added on afterward, they should be part of the same technical review as latency and accuracy from day one. That doesn’t mean optimizing for energy use at the expense of everything else, it means never treating it as someone else’s problem to solve later.
The first investment would be in data itself — governance, quality, and lineage built in from the start, because AI built on top of ungoverned data just automates the existing mess faster. From there, I’d build cloud-native infrastructure with automation embedded throughout, so the platform can scale without every new workload requiring manual intervention.
The mistake I’d actively avoid is adopting AI because it’s expected, rather than because it’s solving a defined problem. I’ve seen that pattern enough times to recognize it early: a team reaches for a model before they’ve agreed on what specifically needs to improve, and the project stalls once the initial novelty wears off. The platforms that hold up are the ones built around a specific, measurable problem, with efficiency treated as a real constraint rather than a nice-to-have.
Your work is rooted in enterprise data engineering and cloud security, yet a significant share of your recent research turns to environmental science — six chapters in a forthcoming book on environmental pollution, among other work. What made you see that opportunity?
At first glance, cloud security and environmental science look like completely different worlds, but I’ve come to see them as the same underlying problem: take a large, messy, high-volume stream of data — soil composition readings, water contaminant levels, network traffic — and build something that makes it trustworthy enough to act on. The domain changes, the discipline doesn’t.
That realization is what pulled me into the environmental pollution book, ‘Sustainable Solutions for Environmental Pollution,’ where my six chapters cover food security, soil health, water resource pollution, waste treatment, and the effects of pollution on medicinal plants. None of my co-authors on that book are people I’d have crossed paths with through my day-to-day work — they’re academics working in environmental and interdisciplinary science who needed someone who could handle the applied AI and data engineering side of a genuinely messy scientific problem.
I don’t think of that as a departure from my core work, I think of it as the same question applied somewhere new: if this discipline can make a security pipeline trustworthy, why couldn’t the same rigor make an environmental monitoring system trustworthy too? Some of the more interesting opportunities I’ve come across happen exactly there — when a way of thinking from one field gets applied seriously somewhere it hasn’t been tried yet.
If every organization had unlimited AI resources tomorrow, what would still prevent success?
Unlimited resources wouldn’t solve the actual bottleneck, which has never really been the technology. It’s trust, governance, and a clear definition of the problem being solved. An organization can have the most advanced models available and still fail if the underlying data isn’t reliable or if nobody agreed in advance what success actually looks like.
I’ve seen relatively simple systems outperform far more sophisticated ones because the team had strong governance and a tight definition of the problem from the start. I’ve also seen advanced technology underperform because those fundamentals were missing. The technology was never really the differentiator in either case.
Trust is the other piece that resources can’t buy directly. As AI gets embedded deeper into decisions — whether that’s a security system or an environmental monitoring platform — people need confidence that the underlying data is sound and the reasoning is at least somewhat explainable. That confidence gets built through governance and oversight over time, not through a bigger budget.
Is there a technology trend everyone’s excited about that you think we’re getting wrong?
‘AI for sustainability’ as a broad claim is the one I’d push back on hardest. It gets pitched constantly without naming the specific measurement, dataset, or decision that’s actually changing, and large models carry their own real energy cost that rarely makes it into the more enthusiastic version of that pitch.
The applications that actually hold up are much smaller and much more specific than the framing suggests: predictive resource allocation that measurably cuts energy draw in a cloud environment, a monitoring system that catches a specific contaminant before it becomes a crisis instead of after. That’s a far smaller claim than ‘AI for sustainability,’ but it’s the part of it that’s real right now, and I think the industry undersells how much value is sitting in exactly that kind of unglamorous, well-defined application.
The other trend I’d flag is treating AI adoption as a volume question — how much of it are we using — rather than a fit question — is it solving the right problem. I think that conversation is shifting, slowly, toward asking what’s actually being measured and improved, and I’d like to see it shift faster.
What continues to inspire you after more than a decade working across data engineering, security, and research?
It’s the same thing that pulled me from infrastructure and pipeline work into research in the first place: the moment a problem that looked purely technical turns out to have a much broader reach than expected. Reviewing a robotics and AI proposal for an agricultural research initiative I had no prior connection to, or seeing a detection model I built get cited by researchers working in fields I’ve never worked in directly, both remind me that the specific discipline of making messy data trustworthy travels much further than any one domain.
That’s really what continues to drive the work. Every shift I’ve been part of — from managing infrastructure, to securing it, to extending it into AI and now into research most people wouldn’t associate with a data engineer — has been an opportunity to apply the same underlying discipline somewhere new. What I keep coming back to is that the most meaningful contributions aren’t defined by which technology you used, they’re defined by whether the problem actually got solved, and whether that solution held up when someone outside your own team looked closely at it. That’s the standard I hold every project to, and it’s the contribution I want to keep making.
Disclaimer: Somnath Banerjee is speaking in his personal capacity. The views expressed in this interview are his own and do not necessarily represent the views of his employing organization. No confidential or proprietary information is discussed.
