The AI Assistant That Took Three Times Longer to Build, and Why That Was the Right Call
Building faster isn't always building better. For one AI assistant project, development took nearly three times longer than expected—but intentionally. Security requirements, user expectations, and the risks of cloud-based AI meant taking a more deliberate approach. Here's why that extra time ultimately led to a better product.
The AI Assistant That Took Three Times Longer to Build, and Why That Was the Right Call
A case study in choosing the slower architecture
A client came to us with a request that has become common: they wanted their staff to have an AI assistant that actually knew things about the company. Not a generic chatbot, but something that could answer questions about their own operations, pull from their own records, and save people the daily grind of hunting through four systems for one answer.
They are a hardware manufacturer. Their contracts impose strict requirements on how company data is handled and where it can travel. Leadership was enthusiastic about the productivity case and genuinely worried about the exposure case, and they were right to be worried about both.
This is the story of one decision inside that project, and why the version that took longer was the version worth building.
The constraint that shaped everything
Because of their contractual obligations, sending company data to a commercial AI service was off the table. That pushed the project toward a self-hosted setup: an open-weight model running on their own hardware, inside their own network, with nothing leaving the building.
That solves the data residency problem cleanly. It also introduces a quieter one. Self-hosted open-weight models are meaningfully less reliable than the large commercial ones. They are more prone to confidently stating things that are false, and more prone to following instructions they should have ignored. You gain control over where the data lives and you give up some of the model's judgment.
Every subsequent decision on the project came back to that tradeoff.
The build everyone expects
There is a fast way to do this, and most deployments choose it.
You create one account for the assistant, give that account broad access to the company's systems, and connect it. The assistant can now answer questions about anything. It demos beautifully. You can be live in about a week.
The problem shows up when you ask a specific question: when a warehouse coordinator asks the assistant about executive compensation, what stops it from answering?
In the fast build, the answer is the model's own discretion. The assistant has access to the payroll data, because the assistant has access to everything. The only thing standing between a curious employee and that information is whether the model decides to be cautious, and we had already established that this particular model's judgment was the weak link.
That is a policy control pretending to be a security control. It works until someone phrases a request cleverly, or until a document the assistant is reading contains instructions written to manipulate it. It would also not survive a serious audit, because there is nothing to show an auditor except a promise.
What we built instead
We put a proper authorization layer in front of the company's internal platform, using the same standards that govern how any modern application grants access to another. When an employee connects the assistant to their internal systems, the assistant receives that specific person's permissions. Not more.
The practical result: the warehouse coordinator's assistant can reach exactly what the warehouse coordinator can already reach. If they cannot open payroll records at their desk, no phrasing of any question will produce payroll records from the assistant. The limit is enforced by the system rather than by the model's willingness to refuse.
We applied the same model to their email, calendar, and file storage. Each person's assistant acts as that person, within that person's existing boundaries.
Then we made a second decision that surprised them: the first release was read-only. The assistant could look things up and could not change anything. Given how much more prone this class of model is to error, letting it edit live operational records on day one would have been an unforced risk. Write access is a later conversation, taken one narrow capability at a time, after the tool has demonstrated it can be trusted with the easier job.
What it cost
Honestly: several weeks of engineering that the fast build would not have required, plus ongoing work on the model itself to get its answers to a quality the team would actually use. The permission layer is real software with real edge cases. It does not come free with anything, and no vendor was going to hand it to us.
During those weeks, the client had nothing to show. That is the genuinely hard part of choosing this path, and it is why most organizations do not.
What it bought
The assistant is in daily use. Employees connect their own accounts and get answers scoped to their own work.
Three things came out of that architecture that the fast build would not have produced.
The compliance conversation became a technical one. When leadership asks how they know the assistant will not leak sensitive data, the answer describes a mechanism rather than an intention. That is a very different conversation with an auditor, a customer, or a board.
Expansion is now incremental. Adding a new system to the assistant means defining the permissions for that system. It does not mean revisiting whether the whole approach is safe, because the answer to that question is already built in.
A bad day stays small. If someone eventually manages to manipulate the assistant through a document it reads, the damage is bounded by that one user's existing access. In the fast build, the same trick reaches everything.
What transfers to your situation
The specifics here were shaped by one company's obligations, but the shape of the decision is general.
If you are evaluating or already running an internal AI tool, the question worth asking is simple and non-technical: whose permissions does it use when it looks something up? If the answer is a single shared account with broad access, everything that tool can reach is effectively reachable by anyone who can talk to it.
The second question: can it change things, or only read them? If it can change things, someone should be able to name the specific actions and say who approved that list.
Neither question requires you to understand how the model works. Both of them tell you most of what you need to know about how much trouble the tool can cause.
The gap between the fast build and the careful one is invisible for months. Both versions work. Both impress the team. The difference only surfaces on the day something goes wrong, and by then the decision was made a long time ago by whoever was moving quickest.
---
Emmabyte Engineering builds and secures internal AI systems for organizations with real data constraints. If you are weighing a deployment like this one, we are happy to talk through it — emmabyte.io