What you are going to ask
These questions come up in every project. They just do not come from the same person, and they rarely all reach the table before the decision is made. That is where projects run aground later.
Below they are set out, grouped by who asks them. Do you recognise five of them and have you had an answer to none of the five from your current supplier? That is a good moment to call.
Board
“What does this deliver, and when will we notice?”
The first thing you notice is that searching stops. Someone who now loses half an hour retrieving an earlier decision finds it in a minute, with the source attached. Usually visible during the proof of concept already. What comes after is harder to count and more important: answers become more consistent, because everyone draws on the same documents.
“What if we want something different in two years?”
Then you keep your documents, your permissions, your infrastructure code and your logs. What you replace is the language model and the search layer, and those are separated from the rest by design, precisely because they age fastest.
“Why do this now instead of waiting until our supplier delivers it?”
Sometimes waiting is the right choice. Weigh this: what a supplier delivers, he delivers to all his clients at once, therefore generically, and it works on his arrangement of permissions and not on yours. For a general knowledge base that is fine. For the moment when departments with different permissions have to draw on the same system, it is usually the problem.
“Will we be dependent on you afterwards?”
No. It runs in your own Azure environment, on your own documents, with the infrastructure as code in your own repository. We hold no key you cannot revoke.
“Why place this with a small firm rather than a large one?”
That is a fair question and the answer is not always in our favour. With a large firm you buy continuity and a contract. With us you buy that the person who designed it is also the person at the table. What you have to arrange in both cases is who maintains it once we are gone, and that is exactly why the setup is delivered as code and is transferable to your own team or your existing supplier. Transferable is not the same as transferred: appoint that person before you start.
Privacy and security
“Will anything of ours go to a model that trains on it?”
No. We build on Azure OpenAI, where Microsoft contractually records that customer data is not used to train models and is not shared with OpenAI. That is a commitment from Microsoft and you can read it back in your own terms. We build nothing in which your documents leave your environment.
“Do we need a DPIA?”
Probably yes, and that is not a problem but work. We are not your legal adviser and we do not carry out the DPIA for you. What we deliver is the technical description your data protection officer needs: which data sits where, which operations are performed on it, and how access is partitioned. Start early. A DPIA that only begins at delivery is the most predictable delay in projects of this kind.
“Can I see who asked what?”
Yes. Questions, answers and consulted sources can be logged. How long you retain them and who may inspect them belongs in your own policy, not in our design. Note that the logging itself contains personal data and therefore falls under the same DPIA.
“Can someone from social services reach HR documents through this thing?”
No, and that is the first thing set up, not the last. Nor the source reference: no pointer to a document they may not open.
Information management
“Does this work on our SharePoint as it currently looks?”
Usually yes, and the exceptions are predictable. What the exploration establishes is not whether it can be done, but where it chafes: folders where permissions have been carved up by hand over the years, libraries with guests in them, and places where the same document sits three times with three different permissions. That is where the work is.
“Will this be another island in our landscape?”
It runs in your own environment, on your own identities, on the documents where they already sit. We do not move your document management and we do not ask you to migrate. That is a design rule, not a concession.
“What if it is broken on Monday morning?”
Then the question is who is on call and what the agreed recovery time is. That is a maintenance agreement, not a technical question, and it belongs on the table before you go into production. We make it explicit because otherwise it lands with nobody by accident.
“What if our documents are a mess?”
Then you are normal. We have yet to meet an organisation where this was not the case. It is not a reason to wait, because nobody sustains tidying up without visible results. We start on the part that is good enough and make visible which mess is actually obstructing the answer.
“What happens to a document we withdraw?”
It disappears from the assistant along with it, within the period you specify. Not at the next big reindexing. Ask this of every supplier you speak to. The answer is vaguer than you would like more often than not.
“And what if it simply makes something up?”
Then you will see it, because a source is always attached and it opens with one click. You will not get an answer without a source. That is not a guarantee that the model never goes wrong, it is the reason you notice before anyone acts on it.
Procurement
“What does it cost per year once it is running?”
The costs fall into three parts that move differently. Consumption in Azure, which moves with the number of questions and the size of your documents, and which we make measurable during the proof of concept so that production holds no surprise. Licences, which you probably already hold. And maintenance, which is a choice and not a given. We do not quote an annual figure before we know your scale, because any figure you get from anyone right now is a shot in the dark.
“And if it turns out not to work after the proof of concept?”
Then you stop, and the proof of concept has done exactly what it is for. You keep the outcome: which documents hold up, where your permissions are shaky, and what a next step would cost. That is value, even if nothing gets built.
“How does a public body actually procure this?”
Exploration, proof of concept and production are three separate assignments, each with its own result. You are free to stop after every phase. That usually fits within your own thresholds, and it is also the only honest moment to decide whether it works.
The shop floor
“Will my people have to work differently?”
As little as possible, and that is a design choice. The documents stay where they are. What is added is a place to ask a question. What disappears is the searching.
“What if my people simply do not use it?”
This is the question that is most often right and least often asked. Systems that work technically and go unused are the most common outcome of projects of this kind. What helps: start with a group that has a concrete problem, not with the group that finds it most convenient. Choose a type of question that recurs often and genuinely costs time now. Always show the source, because trust comes from the document and not from the answer. And measure usage from day one, so that you know whether it is fading before it has already faded. What does not help: a broad rollout with an instruction afternoon.
“What happens if I call?”
No proposal and no presentation. We ask which of these points pinches hardest for you and whether it can be solved within what you already have. Sometimes the answer is that you do not need us. We would rather hear that now than in three months.
Is your question not here? Then that is the question we want to hear.
Come and talk, and we will see where we get to.
Get in touch