Pointing an assistant at your own documents is the most common first AI project in the UAE, and the one that most often disappoints quietly. The model is rarely the problem. The document set is, and nobody looks at it before the demo.
The pitch is simple enough to approve in a meeting: upload the policies, the contracts, the product sheets, the past tenders, and let staff ask questions in plain language instead of searching a shared drive nobody has tidied since 2021. It works. It also fails in a specific set of ways, all of which are visible in advance if you know where to look.
What the system is actually doing
It is not reading your library. When somebody asks a question, the system searches your documents, takes the handful of passages that look most relevant, and puts those passages in front of the model along with the question. The answer is written from that handful — not from everything you uploaded.
Which means the quality of the answer is decided by the retrieval step, not by how clever the model is. Microsoft, Google, Anthropic and OpenAI all describe the same architecture in their own documentation: retrieve, then generate. Buying a better model does not fix a system that hands over the wrong three paragraphs.
Two consequences worth stating in the room. If the answer exists in a document that was not retrieved, the system will not say so — it will answer from what it has. And if two documents disagree, whichever one was retrieved wins.
The five things it gets wrong, and why
The superseded version. Your drive holds the 2023 policy, the 2025 policy, and a draft somebody left in a personal folder. All three are retrievable. The system has no way of knowing which one governs unless the documents say so.
The near-duplicate. Twelve tender responses that are 90% identical. Retrieval finds them all, they crowd out everything else, and the answer is assembled from four versions of the same paragraph.
The table. Prices, rates, schedules. A table cut across a chunk boundary loses its header row, and the numbers end up attached to the wrong column. Providers document chunking as a design decision precisely because of this — Microsoft’s guidance on chunking is worth reading before anyone claims it is automatic.
The scan. A PDF that is a photograph of a page contains no text. Without optical character recognition it is invisible to retrieval, and in an Arabic document set the scanned proportion is usually higher than anybody estimates.
The question the documents cannot answer. Asked something outside the set, a system without an explicit refusal path will answer from general knowledge and sound exactly as confident as it does on your own policy.
Permissions are the part with consequences outside the system
Everything above is an accuracy problem. This one is a disclosure problem, and it is the one that ends careers.
If the assistant indexes a drive with a broad service account, it can surface a salary letter, a board paper or a disciplinary note to whoever asks the right question. The correct architecture is that retrieval runs with the permissions of the person asking, so the assistant can never show somebody a document they could not already open. Microsoft describes exactly this model for its own service in the Copilot architecture and data protection documentation.
Ask the supplier one question and insist on a demonstration rather than an answer: show me the same question asked by two staff with different access, and show me the answers differ. If the demo account is an administrator, you have learned nothing.
And before you index anything, run a sample: list twenty documents at random from the drive you are about to point it at, and read who can open them today. Most UAE companies find at least one thing in that sample that should never have been on a shared drive at all.
The work is document hygiene, and it is not glamorous
The preparation that makes the difference is boring and takes a week rather than a quarter.
Decide what is in scope, and index only that — a curated set of two hundred current documents outperforms a drive of twenty thousand, every time. Put a status and a date in the first lines of each document, so retrieval can see that the 2023 policy is superseded. Archive the superseded versions out of the indexed location rather than relying on file names. Convert the scans that matter. And name one person who owns the set, because a document library with no owner is stale within two quarters.
Where the documents are genuinely messy — a decade of mixed Arabic and English, scans, and no naming convention — that clean-up is the project, and the assistant is what you switch on at the end of it. Tothiq does that document work across the GCC, which is a different engagement from wiring up a model.
Arabic changes the sizing, not the approach
Three practical differences in a UAE document set. Scanned Arabic is much more common, and Arabic OCR quality varies sharply by document type, so budget for checking rather than assuming. Questions arrive in dialect while documents are written in formal Arabic, which is a retrieval mismatch rather than a comprehension one. And a bilingual set needs a deliberate decision about whether a question in one language should retrieve documents in the other — usually yes, and it rarely happens by default.
None of this is exotic, and all of it has to be in the test set rather than discovered by staff in week three.
Citations are the feature to insist on
An answer without a source is unusable for anything that matters, because nobody can check it without redoing the work. An answer that names the document and the section is checkable in ten seconds, and it changes staff behaviour: people stop treating the assistant as an oracle and start treating it as a very fast way of finding the right page.
The capability is supported directly by the providers — citation support is documented rather than exotic — so a supplier who cannot show it has made a choice, not hit a limit. Insist on it, and insist that the citation links to the document rather than naming it.
The acceptance test, written before the build
Fifty real questions, collected from the people who will actually use it, before anything is built. For each one, a named person writes the correct answer and the document it comes from. That list is the contract.
Then measure three things on the finished system: how many of the fifty are answered correctly with the right source, how many are answered from the wrong document, and how many are refused. The second number is the dangerous one, and a system that refuses more often is usually safer than one that answers everything. Run the same fifty again after every change to the document set, which is the part that makes it a system rather than a demo — and it sits alongside the record of what any automated system may decide and the data protection questions that come before either.
Running it, and who owns the set
The subscription is rarely the expensive part. The recurring costs are the re-indexing when documents change, the person who curates the set, and the periodic re-run of the acceptance questions. None is large; all of them are somebody’s job, and if that somebody is not named the system decays quietly — the answers stay fluent while slowly becoming wrong, which is worse than an outage because nothing announces it.
Put the owner in the same place you keep the rest of your technical ownership, review the set quarterly, and treat a complaint about a wrong answer as a document problem first. In the great majority of cases the fix is deleting a superseded file, not tuning anything.
Before any of this is procured, it is worth being able to describe the system somebody else built in plain terms: where the documents live, who can read them, what is indexed, and what happens when a file changes. If nobody in the room can answer those four, the project is not ready to sign.
What it is genuinely good at
After all of that, the honest case. It is very good at finding the clause you half remember, at summarising a long document you have to act on this afternoon, at drafting a first reply that quotes your own policy correctly, and at making a new employee productive in a week instead of a quarter.
Those are real, and they are worth the week of document work — which is also why the first system should cover one department’s documents rather than the whole company. A narrow set that works produces demand from the rest of the business. A broad set that half works produces the conclusion that the pilot did not reach production, and the reason will be recorded as the technology rather than the filing.
Frequently asked questions
How many documents do we need before this is worth doing?
Fewer than people expect, and the number is not the point. A few hundred current, correct, well-structured documents that staff genuinely ask about beats tens of thousands of mixed-quality files. If a person could answer most of the questions from ten documents, the project is a shortcut to those ten rather than an AI project.
Can it read our scanned PDFs?
Only if something converts them to text first. A scan is an image, and without optical character recognition it is invisible to the system — which shows up as the assistant confidently not knowing about a policy that is definitely in the folder. Check what proportion of your set is scanned before you scope the work, especially on the Arabic side.
Will staff see documents they are not supposed to?
Not if retrieval runs with each person’s own permissions, which is how the major platforms are built and what you should require. It is a real risk in a quick custom build that indexes a drive with one broad account. Ask for a demonstration with two accounts at different levels rather than an assurance.
What happens when a policy changes?
You replace the document and remove the old version from the indexed location, then re-run your acceptance questions that touch it. Systems differ in how quickly they pick up a change, and that lag is a question to ask before signing. What you must not do is leave both versions in place and hope the newer one wins.
Is this the same as training a model on our data?
No, and the distinction matters commercially. Retrieval leaves your documents where they are and shows relevant passages to the model at the moment of asking. Training bakes material into a model. Almost every business case that sounds like the second is better served by the first: it is cheaper, it updates the moment you replace a file, and it can cite its source.