You’ve probably been in this meeting. Someone from leadership says, “We need AI.” A vendor demos something flashy. Everyone nods. Three months later, nothing works, and nobody can explain why.
I spent a week embedded inside a massive state-owned enterprise as a Field Deployment Engineer — the person whose job is to actually make AI work on the ground, not in a slide deck. I sat with four different business teams. I watched them open their real files, not the sanitized versions they put in requirement forms. And I learned something that contradicts almost everything you read about enterprise AI.
The technology was never the bottleneck. The organization was.
Here’s what actually happened when AI met reality.
The Requirement Form Is a Lie
Every business team I met said the same thing when I asked what they needed: “We want to search documents, write reports, and summarize materials.”
Easy, right? Build a knowledge base, spin up a Q&A agent, add a writing assistant. Done.
Then I walked into their actual workspaces.
One team needed to merge submissions from twenty-plus subsidiary units — each using the same Excel template — into a single report, preserving which unit contributed each data point. Another team maintained a 200-megabyte yearbook packed with text, photos, and historical content requiring special handling. A third team tracked daily priority tasks across dozens of files arriving in mixed Excel and Word formats.
All of these were called “summarization.” But the processing methods were completely different. One you could throw at a large language model. The other required field mapping, table merging, source tagging, and fixed-format output — with real samples tested iteratively.
Real requirements don’t live in forms. They live in that one Word template only the business user knows how to navigate.
The most basic rule of field deployment: don’t just record what the client says. Make them open the file they’re working on right now. Watch what they do. The gap between what people say they need and what they actually do is where every AI project lives or dies.
Stop Underestimating the People in the Room
There’s a stereotype that employees in large legacy organizations are AI novices who need to be educated. That assumption will get you killed in a deployment.
The people I met were already using large models to write scripts and generate web pages. They knew to replace sensitive information with placeholders before sending it to external models. They asked whether the underlying model was strong enough, whether information sources could be restricted, whether internet search could be disabled.
One colleague responsible for historical archives asked whether the system could temporarily block output of certain content without modifying the original archive. Another wanted to log what users searched for and what they couldn’t find — to guide next year’s content collection.
These weren’t feature requests from curious amateurs. They were precision strikes from people who spend years inside a specific responsibility boundary and can instantly identify where a product will break.
The most dangerous thing a field engineer can do is walk in and try to educate the customer. They may not know your tech stack, but they know exactly what a single wrong data point will cost them.
Who Owns the Data? (This Question Will Haunt You)
In one meeting, a business leader asked three questions that sound technical but are actually political:
First: the same metric appears in different reports with different statistical calibrations. Which one does the AI use? Second: a table with hundreds of indicators where only a third change each update — when the new version uploads, do you delete, overwrite, or keep the old one? Third: if multiple people can upload materials, who confirms which version is official?
From a technical standpoint, you can instruct the model to prioritize the latest file. You can use timestamps and version tags. But none of that solves the root problem.
If the source isn’t unified, the model is just guessing between conflicting documents.
My recommendation: enterprise and departmental knowledge bases must have designated maintainers. Material updates need confirmation and review processes. Deprecated content needs retirement rules. The model can retrieve, compare, and merge — but it must never replace the business department’s authority to decide which calibration is valid.
A data source isn’t just a technical input. It’s a map of who has the power to publish, who’s responsible for interpretation, and who bears the consequences when something goes wrong.
In a large enterprise, APIs can be connected by engineers. The accountability relationships behind the data cannot be resolved with code.
The Two-Ledger Problem
Here’s where it gets genuinely hard. Leadership wanted to see scale: how many teams onboarded, how many knowledge categories covered, how many files collected, how many data sources connected. Without those numbers, the project couldn’t justify its existence.
But the business lead on the ground said the opposite: don’t chase volume. Be small and precise. Choose authoritative sources. Select only a few credible external outlets. Too many sources of varying quality, and the model just blends garbage into something that looks complete but has no judgment.
Project momentum needs scale. Business utility needs precision. These two forces pull in opposite directions, and the field engineer sits in the middle.
My solution: maintain two ledgers simultaneously.
The first is a progress ledger — which teams are connected, what materials are collected, what knowledge domains are covered, what systems still need integration. This keeps the project moving and shows leadership where resources are going.
The second is a results ledger — which materials have confirmed production-ready versions, which questions have passed evaluation, who’s responsible for fixing conflicting answers, whether users actually saved time. This determines whether the product can go live.
Collect broadly to discover opportunities. Filter ruthlessly to serve users. Wide entry, narrow exit — that’s the only architecture that survives contact with a real enterprise.
Collecting everything upfront has practical value. If you demand meticulous data governance from every business team on day one, the project will face resistance and stall. But collecting doesn’t mean deploying. Materials enter a wide candidate pool, and only confirmed knowledge passes through the narrow gate to power live Q&A and content generation.
Saying “We Can’t Do That” Builds More Trust Than Saying “We Can Do Everything”
During one product demo, a colleague told the client that departments could maintain their own knowledge bases. The reality: the platform only supported global admin maintenance and personal knowledge spaces. The query side could restrict access by department through agent controls, but the management side hadn’t implemented department-level permission isolation yet.
Two different concepts — who can see versus who can manage — got blurred into one promise.
I corrected it on the spot, in front of the client. It was uncomfortable. But a promise made today becomes debt collected in a few weeks.
The same pattern appeared with PowerPoint parsing, complex Excel Q&A, audio transcription, and archive management. Clients see AI and naturally request everything they’ve ever wanted. The field engineer’s job is to immediately assess: can the current product handle this stably? What needs sample testing? What needs custom development?
Clarifying boundaries doesn’t reduce client confidence. What destroys confidence is promising everything in the demo and re-explaining every single item at delivery.
The Unsexy Truth About AI’s First Real Win
One requirements meeting ran ninety minutes. We discussed leadership speeches, research reports, automated PPT reading, table parsing, audio transcription, industry data scraping, auto-formatting, proofreading, and whether AI would eliminate the department’s jobs.
Then a business leader closed the loop with something quietly radical:
Step one: just solve search. Let the system find a specific viewpoint from years of reports, speeches, and meeting materials — and cite the original source. That’s it. Don’t expect AI to replace researchers’ judgment. Leadership demands are highly personalized. The important conclusions still need humans.
This is the opposite of what most enterprise AI projects do. They start with the most impressive capability — content generation — because it demos well. But in the messy reality of a large organization, the most valuable thing AI can do is help people find things.
It’s invisible. It doesn’t look impressive in a screenshot. But it eliminates hours of digging through files, recalling what was said last quarter, and begging colleagues for data. And it doesn’t threaten anyone’s core expertise.
When the system can reliably find materials, cite sources, and distinguish versions, business users will naturally start asking it to organize, analyze, and draft. That order — retrieval first, generation second — is infinitely more reliable than promising a leadership-ready speech on day one.
What Field Deployment Actually Looks Like
In the idealized version, a field engineer arrives with product, APIs, and client data, does rapid integration, and proves value through business metrics. Clean. Efficient. Satisfying.
In reality, code is just one type of interface. The field engineer handles organizational interfaces first. The people requesting features, the people controlling data, the people using the system, and the people signing off on acceptance — they’re rarely the same individuals. The people who can modify the product aren’t always on-site.
So the field engineer becomes a translator. Business operations become product requirements. Product limitations become acceptable transition plans. Project progress becomes verifiable metrics. Trial feedback becomes product team priorities.
This week, I didn’t write specs, tune APIs, or run evaluations. I scheduled meetings with business users, introduced the product, probed pain points, explained capability boundaries on the spot, collected samples, set up trial accounts, and relayed problems back to product managers.
None of it sounds like the AI revolution you read about. But this is what deployment actually looks like when the technology works and the organization is the variable.
The hardest part of enterprise AI isn’t making the model smarter. It’s making the organization ready for a model that’s already smart enough.
FAQ
Q: If organizational issues are the real bottleneck, why not just fix the organization first before deploying AI?
A: You can't. Organizations don't restructure on command, and waiting for perfect data governance means waiting forever. The field engineer's job is to make progress inside the mess — collect broadly, filter ruthlessly, and let early wins build the trust needed to drive organizational change.
Q: What does this mean for companies planning their first enterprise AI project?
A: Start with retrieval, not generation. Don't promise automated report writing on day one. Build a system that reliably finds documents, cites sources, and distinguishes versions. Once users trust the search, they'll naturally push for more — and by then you'll understand their actual workflows well enough to deliver.
Q: Isn't this just saying AI is overhyped and doesn't really work in enterprises?
A: No — it's saying the opposite. The technology is already good enough. The models can handle the tasks. What's lagging is our understanding of how to deploy inside complex organizations. The bottleneck isn't capability; it's coordination. That's actually more solvable than waiting for a smarter model.