Analysts at Grand View Research put the global edge AI market at $24.91 billion in 2025, with a path to $118.69 billion by 2033 and North America already accounting for more than 36% of that spending. Many edge AI projects succeed in controlled testing yet take real effort to hold the same performance across hundreds of real-world sites with different lighting, network quality, and operating conditions.
Siddharth Pani, Senior Technical Project Manager at Anicca Data Science Solutions and a doctoral researcher in cyber engineering, has spent over five years closing that gap, taking computer vision off the whiteboard and into McDonald's drive-thru lanes, where the Enhanced Vehicle Detection (EVD) system he led now runs in 120 U.S. locations. He is also the author of several peer-reviewed papers spanning cybersecurity, digital transformation, AI, blockchain, edge computing, and IoT across a range of critical sectors.
We asked him what the edge AI boom looks like from inside the restaurants, data centers, and edge servers where the inference happens, and what separates a deployment that lasts from one that quietly gets switched off.
Forecasts measure spending, not difficulty. A model that works in a lab and a model that works in 120 restaurants are two different products. Inside a lab, you control the lighting, the camera angle, and the network. Drop that same model into a live drive-thru, and it meets rain on the lens, a camera someone bumped overnight, a connection that drops at lunch rush. Our job was never just accuracy on a test set. Cutting three seconds off order processing time and lifting detection by about 20% only mattered if those numbers held steady across stores that look nothing alike. Honestly, the spending follows once you solve that part, not the other way round.
Payments taught me the part of engineering nobody romanticizes. Settlement has to be right every single time, and that obsession with reliability is what stayed with me. When I moved to Anicca in 2021 and later took on the McDonald's and Microsoft accounts, the domain changed completely. What did not change was the underlying question: can this run unattended, at scale, without someone babysitting it?
Two reasons, latency and cost. A drive-thru decision has to land in well under a second, and a round trip to the cloud does not give you that margin once the network has a bad afternoon. Sending raw video from every camera up to the cloud is also expensive, and the bill climbs with every new store. Keeping the processing on a server inside the restaurant fixes both. The harder part was the hardware. Working with NVIDIA, we reworked the models so several camera feeds could share one machine instead of one box per camera, which cut the hardware bill by about 30%.
Almost everything outside the model itself. Prototypes assume an engineer is nearby; a rollout assumes nobody is. So onboarding a new store had to become close to automatic, and the monitoring had to catch a problem before anyone on site even noticed it. Working with Microsoft on that pipeline gave us the backbone for it, and being part of the AKS Edge Essentials world at Embedded World put our setup right next to the platform it would run on. I’d say recognition is pleasant, but repeatability is the thing that actually pays the bills.
Stakes look different, though the instincts are identical. Data-center buildouts punish small mistakes brutally, because one wrong configuration file or a miscategorized hardware fault can ripple across the whole operation. To keep that from happening, we automated the config generation and built error-notification and retry logic, so nobody was stuck babysitting a repetitive loop. Restaurant edge AI punishes the same carelessness, only with cameras instead of servers. Both worlds reward a single instinct, assume the rare failure will arrive at the worst possible moment, and design so it costs minutes, not days.
They feed each other far more than people assume. Writing that paper made me slow down and articulate something I had been treating as instinct on the job. For me, that is not an academic point. Choosing a local server over a cloud round-trip in a restaurant comes down to the same reasoning: less data in flight and fewer things to defend. What I keep coming back to is that the security argument and the deployment argument are the same one in different clothes.
More than I expected, yes. IEEE pulls me into conversations happening outside my immediate project work, and that cross-pollination matters in a field that shifts as fast as edge AI. Reviewing for APSIT added something different: you see where engineers make their assumptions explicit and where they quietly leave them out. In deployment work, those omissions are exactly where things break in the field. It sharpened how I document assumptions on my own projects, especially around environment variability.
My honest answer is the boring layer of work that nobody puts on a slide. Money will keep chasing the models, but the projects that survive will be the ones that took monitoring, field reliability, and deployment discipline seriously from the very first day. Personally, I want to turn the patterns we built across Microsoft, IBM, and the rest into something other teams can reuse, and to finish my doctoral work in cyber engineering while keeping the research going. If I had one piece of advice for engineers entering this field, it would be to fall a little in love with the unglamorous 20% of the work that begins after the demo ends. That, in the end, is where both the value and the difficulty really live.