Short answer: The cost of an AI implementation in the UAE is driven less by the model and more by the work around it: how many document or request types it handles, how many systems it connects to, how often it meets exceptions, which languages and formats it must read, where it must run, and how it is monitored afterwards. We don't publish a rate card. This guide explains what moves the cost so you can scope sensibly before any proposal.
Three stages, priced separately
Assessment. A scoped piece of work for when the workflow, data or integration route is unclear. It produces a workflow map, an opportunity ranking, a data and access inventory, a current baseline, the cost drivers and a pilot scope. Not every project needs one; a clear, bounded workflow can go straight to a pilot.
Pilot. One process owner, one main input source, one output integration, an exception queue, an agreed sample set and acceptance criteria. It produces a working workflow, evaluation results, an operating guide and an ongoing cost model. It ends with an explicit decision: expand, revise or stop.
Operate and expand. Running costs, monitoring, updates when layouts or rules change, and adding the next document type or system once the first one has proved itself.
What drives the build cost
- Scope of inputs. One document type with a handful of layouts is a different project from twenty types from fifty suppliers.
- Languages and quality. Clean digital PDFs are easier than phone photos; mixed Arabic and English adds testing work, not a different product.
- Checks and reference data. Matching against purchase orders, supplier records or price lists means connecting to those sources and keeping them current.
- Integrations. A system with a documented API is simpler than one that needs a custom import or a workaround. The failure handling for each integration is part of the cost.
- Exception rate. The more documents need review, the more the review screen, queue and rules matter.
- Access and permissions. Who may see which documents, and which approvals are required, shape the design.
- Hosting and processing requirements. Where the application runs, and which model provider may process the text, are agreed per project and can change the architecture.
- Evaluation. Building a proper test set and measuring against it is real work, and it is the part that tells you whether the tool is worth running.
What drives the running cost
- Model usage, which scales with volume, document length and how many passes each document needs.
- Hosting and storage for the application, logs and document history.
- Monitoring and maintenance, including updates when suppliers change layouts or your rules change.
- Human review time, which does not disappear. A good design reduces it; it should still be in the budget.
Ask for the running-cost model before you approve a build. A tool that is cheap to build and expensive to run is not a bargain.
When a custom build is the wrong answer
If your accounting or ERP software already includes document capture that covers your volume and layouts, using it is usually cheaper. If volume is low, the build may never pay back. If there is no system that can receive the approved record, start with the integration question. Saying so early is part of a useful scoping conversation.
How to compare proposals
- Is the scope defined by document types, layouts, systems and acceptance criteria, or only by "AI automation"?
- Is there a pilot with an explicit stop or expand decision?
- Are evaluation results part of the deliverables, measured on a held-out sample?
- Is the monthly running cost stated, with what drives it?
- Who owns the code, the prompts and the test set at the end?
For a rough sense of the capacity a workflow could release, use the value worksheet on our document processing page. For the broader software picture, see how much custom software costs in the UAE.
