AI without a data scientist in the room

There is a quiet assumption baked into most conversations about enterprise AI: that to use it, you need a data science team. Hire the PhDs, stand up the platform, build the pipelines, and eventually value comes out the other end. For a handful of large companies, that path works. For almost everyone else, it stalls before it starts.

I spend time with two kinds of organizations where this assumption falls apart in an instructive way. One is industrial: factories, machine builders, automation engineers. The other is financial: the NBFCs, microfinance institutions, and cooperative banks that quietly run a huge share of lending in markets like India. Neither has a data science department. Neither is going to build one. And both are sitting on exactly the kind of data that AI is good at.

The expertise is already there, just not where we keep looking

A PLC programmer on a factory floor understands that machine better than any model ever will. A loan officer at a cooperative bank understands their borrowers in ways no dataset fully captures. The domain expertise is abundant. What's missing is a way for that expert to apply AI to their own problem without first becoming a different kind of professional.

This is the framing I find most useful, and it's why I've been drawn to advising companies working on it from both ends. On the industrial side, the goal is to let an automation engineer use AI the way they already use a library of control logic: pick a model, configure it, run it on the machine, no Python and no cloud round-trip. On the banking side, it's about wrapping AI inside the actual workflow of lending, from onboarding a customer to originating a loan to staying compliant, so the intelligence shows up as a faster, cleaner version of the job the team already does.

The win isn't a smarter model. It's removing the translator who used to sit between the expert and the tool.

Why "no data scientist" is a feature, not a compromise

It's tempting to read all this as the budget version of real AI, the thing you settle for when you can't afford a research team. I'd argue the opposite. Routing every AI decision through a specialist team introduces a translation layer, and translation layers lose information and time. The expert explains the problem to the data scientist, who builds something, which gets handed back weeks later, often slightly wrong because the nuance didn't survive the trip.

Collapse that loop and something better happens. The person who understands the problem is the person configuring the solution and seeing the result immediately. They iterate in minutes, not sprints. They catch the subtle errors that an outsider would never notice. The feedback loop that actually produces good systems gets dramatically shorter.

There are real constraints that make this approach not just nice but necessary. A factory often can't send its data to the cloud, for reasons of latency, reliability, or plain industrial caution, so the AI has to run locally on the machine. A regulated lender can't treat compliance as an afterthought, so the intelligence has to be built around the rules from the start. In both cases the messy, specific reality of the domain forces a design where AI meets the work where it already happens, instead of demanding the work reorganize itself around AI.

What this means if you're not a tech company

Most organizations are not going to become AI companies, and they shouldn't try. The opportunity isn't to build a research lab. It's to ask a narrower, more answerable question: where do my best people spend time on judgment that a well-aimed model could support, and can I get them a tool that fits their existing workflow?

If adopting AI in your organization requires hiring a team you've never needed before, the friction will usually win, and the project will join the pile of stalled initiatives. If instead it shows up as a sharper version of a job your people already know how to do, adoption takes care of itself. After twenty-two years building software for enterprises, that's the pattern I trust most: technology wins when it meets people where they already are.