Why Domain Experts Should Control AI Systems (Not Engineers)

There's a pattern we see in almost every enterprise AI initiative. A business team identifies a problem. Leadership gets excited. The project gets assigned to the engineering department. Six months later, the engineers deliver a technically impressive system that completely misses the point.

This isn't an engineering failure. It's an organizational design failure.

The Knowledge Gap Problem

When a compliance team asks for an automated document review system, they understand something engineers don't: which paragraphs actually matter, what constitutes a material change, and where the real risk lives. That knowledge takes years to develop. No requirements document captures it fully.

Yet the standard approach is to have the compliance team write a spec, hand it to engineers, and wait. The spec is inevitably incomplete. The engineers fill in the gaps with assumptions. The result is a system that passes unit tests but fails the people who have to use it.

The best AI systems don't have this gap. They're designed by the people who understand the problem, with engineers providing the technical scaffolding.

When Domain Experts Lead

We worked with a financial compliance team that had been waiting two years for an automated alert triage system. The engineering backlog was too deep. The project kept getting deprioritized.

We took a different approach. Instead of writing a spec for engineers, we worked directly with the compliance analysts. They described their decision-making process. We translated it into rules, prompts, and workflows — with them reviewing every step.

The system was in production in three weeks. Not because we're faster engineers. Because the domain experts were making the design decisions in real time. No spec-writing. No game of telephone. No six-month feedback loop.

The analysts caught issues in prototype reviews that would have taken months to surface in a traditional development cycle. "That rule doesn't apply to derivatives" or "we need to check the counterparty threshold first" — corrections that take seconds when the expert is in the room and weeks when they're across a ticketing system.

Another Example: Supply Chain

A manufacturing client had a supply chain team drowning in Excel spreadsheets. They'd built increasingly complex models to optimize inventory across twelve warehouses. The models worked, but they took a full-time analyst to maintain and update.

We didn't replace the analyst. We sat with them and turned their spreadsheet logic into a proper system — preserving their exact methodology, their edge cases, their hard-won heuristics about which suppliers deliver late in Q4.

The supply chain team owned the logic. We owned the infrastructure. The system runs faster, handles more scenarios, and the team can modify the rules themselves without filing an engineering ticket.

Why AI Makes This Possible Now

The reason domain experts couldn't drive software development before was the technical barrier. You needed to write code to build software. That constraint forced an organizational model where experts describe and engineers build.

AI dramatically lowers that barrier. Domain experts still aren't writing production code — but they can now participate meaningfully in the design and iteration cycle. They can review AI-generated logic, test scenarios directly, and validate behavior against their expertise.

The role of the engineer shifts from "translator of business requirements" to "enabler of domain expertise." We build the framework. We handle the infrastructure. We ensure production quality. But the decisions about what the system does and how it behaves — those belong to the people who understand the domain.

The Organizational Implication

This means AI projects shouldn't live exclusively in the engineering department. The domain team should own the project, with engineering support embedded alongside them.

It's a harder organizational model. It requires engineers who listen well and domain experts who are willing to engage with technology. But the results are categorically better.

Stop asking your engineering team to guess what the business needs. Let the business build what it knows, with engineering making sure it actually works.