Arabic government AI means systems that treat Arabic as a first-class language, not a translation layer: OCR that handles ligatures, diacritics and stamped scans, retrieval that normalises alef and hamza variants, models evaluated on Modern Standard Arabic and Gulf dialect, and a right-to-left interface. Delivery in the GCC also requires in-country hosting and bilingual documentation.
Swedish Technology delivers in Arabic and English and tests Arabic quality with a measured evaluation set built from the entity's own documents, not a vendor demo.
What problem does this solve?
Almost every AI product sold into the GCC is described as supporting Arabic. In practice that claim covers a wide range, from a genuinely multilingual pipeline down to an English system with a translated interface. The gap shows up on day one of a pilot: the interface is right-to-left but the search returns nothing because the index never normalised alef and hamza variants; the model answers in fluent Arabic but the citation points to the wrong paragraph because OCR merged two columns; a user asks a question in Emirati dialect and the retrieval finds nothing because every document is written in Modern Standard Arabic.
Scanned archives are the hardest part. Government correspondence in the region includes decades of scanned material with stamps across the text, signatures over words, low-resolution faxes, tables drawn as images, and pages where Arabic and English sit in the same line with numbers running left to right inside right-to-left text. General-purpose OCR handles clean printed Arabic reasonably well and handles this material badly. If nobody measures extraction quality before the project starts, the failure surfaces months later as unreliable answers, and the model gets the blame.
The third problem is acceptance. Arabic quality is rarely written into procurement criteria in a testable form, so disputes at go-live become a matter of opinion. Meanwhile data residency, Arabic hand-over documentation and Arabic user training are often assumed rather than scoped, and they are the items that delay sign-off.
How the solution works
Treat Arabic as an engineering requirement with measurable acceptance criteria. That means an OCR baseline measured on your own worst documents rather than a clean sample; text normalisation applied identically at indexing and query time so spelling variants match; a retrieval layer that supports mixed Arabic and English content in one index; dialect handling in the query path so a colloquial question still finds a formal document; and an interface built for right-to-left from the start, including numbers, dates, mixed-direction strings, forms and printed output.
Swedish Technology builds the evaluation set with the entity before the system is built: a fixed list of real Arabic questions with agreed correct answers and source pages. Every change to OCR, index, prompt or model is re-tested against it, so Arabic quality is a number that can be reported to a steering committee. Hand-over documentation, administrator guides and user training are delivered in Arabic and English.
- 1Input Collect a representative sample deliberately weighted towards the difficult material: stamped scans, faxes, handwritten annotations, mixed Arabic-English pages and tables, plus real questions in both formal Arabic and dialect.
- 2Capture Run OCR with Arabic models, image pre-processing (deskew, denoise, contrast, stamp handling) and layout detection so columns, tables and headers are recognised rather than flattened into one text stream.
- 3Processing Normalise text consistently: alef and hamza forms, taa marbuta and yaa, tatweel removal, diacritic handling, Arabic-Indic and Western digits, and Hijri and Gregorian date parsing. Store the original text alongside the normalised form for display.
- 4Retrieval Index with multilingual embeddings plus keyword search over the normalised text. Dialect queries are expanded to formal vocabulary, and cross-language retrieval lets an English question find an Arabic document and the reverse.
- 5Generation The model answers in the language of the question, quoting the Arabic source text verbatim for any clause or figure, and states clearly when the source is only available in the other language.
- 6Action The officer sees the answer and the original Arabic page side by side, in a right-to-left interface, and confirms or escalates before acting on it.
- 7Reporting Evaluation runs report OCR character accuracy, retrieval hit rate and answer correctness separately for Arabic and English, so a drop can be traced to the layer that caused it.
Reference architecture
Arabic support is not one component; it appears in five places, and weakness in any one of them is visible to the user as a wrong answer.
| Layer | What it contains |
|---|---|
| Document capture | Scanner settings and image pre-processing, Arabic OCR engine with layout analysis, table extraction, and a manual correction queue for pages that fall below a confidence threshold. |
| Text normalisation | A single shared library applied at both index and query time: character normalisation, digit handling, punctuation, stop-word treatment, and preservation of the original string for display and citation. |
| Retrieval | Multilingual embedding model plus keyword index, mixed-language documents in one collection, dialect and synonym expansion in the query path, and re-ranking tested on Arabic pairs rather than English benchmarks. |
| Generation and guardrails | An instruction-tuned model with acceptable Arabic fluency, prompts written in Arabic for Arabic queries, verbatim quoting of source clauses, and refusal behaviour when retrieval is weak. |
| Interface and output | Right-to-left layout, correct bidirectional text handling for mixed strings, Arabic fonts with proper shaping, Hijri and Gregorian date display, and Arabic-correct PDF and Word export including headers and page numbering. |
Deployment options: Deployed on-premise or in a UAE-region private cloud so Arabic government content never leaves the country. Air-gapped deployment is supported; Arabic OCR models and language model weights are shipped as offline bundles.
Key capabilities
Arabic OCR with layout preservation
Scanned circulars and correspondence become searchable text with tables and headings intact, not one unstructured block.
custom developmentConsistent Arabic normalisation
Users find a document whether they typed the alef with or without hamza, with or without diacritics.
availableCross-language retrieval
An English question finds the relevant Arabic policy, and the answer cites the Arabic clause.
availableDialect-tolerant queries
Staff can ask in everyday Gulf Arabic and still reach documents written in Modern Standard Arabic.
custom developmentRight-to-left interface and exports
Screens, forms, printed memos and PDF exports read correctly in Arabic without manual fixing.
availableArabic evaluation set and scoring
Arabic quality is reported as measured numbers per release instead of being argued about at acceptance.
availableHijri and Gregorian date handling
Deadlines, circular dates and validity periods are parsed and displayed correctly in both calendars.
availableArabic voice input
Field and counter staff can dictate a question or a note in dialect instead of typing Arabic on a phone.
conceptIntegrations
Arabic handling has to survive every hop between systems, so integration work focuses on encoding, direction and date formats as much as on APIs.
| System | Integration point & data exchanged | Direction |
|---|---|---|
| Document & correspondence management | Arabic metadata, subject lines and full text indexed with correct encoding; deep links open the original Arabic record. → Document Management & Correspondence System | inbound |
| On-premise RAG assistant | The Arabic pipeline is the language layer under a private retrieval assistant; both share the same index and evaluation set. → Government AI Assistant with On-Premise RAG | bi-directional |
| Document intelligence pipeline | Arabic OCR and normalisation feed classification and field extraction for permits, contracts and correspondence. → AI Document Intelligence: OCR, Classification & Extraction | bi-directional |
| Workflow automation | Arabic case data, notifications and approval steps carried through the workflow platform without encoding loss. → Primavera P6 – Project Management | bi-directional |
| CRM and service channels | Arabic customer enquiries classified and routed, with suggested bilingual replies for agent review. → Smart CRM | bi-directional |
Industry use cases
Federal and emirate government
Staff query circulars, resolutions and internal procedures in Arabic and receive answers citing the exact Arabic clause and issue date.
Municipalities
Scanned Arabic permit files and inspection reports are made searchable, so a case history can be reconstructed in minutes.
Legal and compliance departments
Arabic contracts and regulations are compared clause by clause, with the Arabic text treated as the governing version.
Customer service centres
Enquiries arriving in Gulf dialect by chat or email are classified and routed, with bilingual draft replies for agent approval.
Education and training bodies
Arabic curricula, policies and circulars are searchable in one place across departments.
UAE & GCC considerations
In the UAE and wider GCC, Arabic is the official language of correspondence and the governing version of most legal texts, so an assistant that handles Arabic as a secondary feature will fail acceptance regardless of its English performance. Government content is normally classified in a way that requires hosting inside the country, which pushes deployment on-premise or into a UAE-region private cloud and rules out sending Arabic documents to public AI services. Procurement documents increasingly ask for a demonstrated Arabic OCR accuracy figure, an Arabic user interface including printed output, Arabic training and hand-over documentation, and an Arabic-speaking support contact. Swedish Technology, based in Dubai, delivers projects in Arabic and English across the UAE, Saudi Arabia, Qatar, Oman, Kuwait and Bahrain, and builds the Arabic acceptance criteria into the test plan rather than leaving them to the end.
Implementation approach
- 1Sample and baseline (1-2 weeks) Collect a deliberately difficult document sample and measure current OCR and search quality. This baseline decides whether the project is a software task or a scanning and remediation task.
- 2Build the Arabic evaluation set Fifty to one hundred real questions in formal Arabic and dialect, with agreed correct answers and source pages, signed off by subject-matter experts before development.
- 3OCR and normalisation pipeline Tune pre-processing and OCR on the sample, implement the shared normalisation library, and set the confidence threshold that sends a page to manual correction.
- 4Retrieval tuning Select and test embedding models on Arabic pairs from your own corpus, configure hybrid search and dialect expansion, and measure retrieval hit rate per language.
- 5Interface and output Build the right-to-left interface, verify bidirectional text in mixed strings, and test Arabic PDF and Word export including headers, tables and page numbering.
- 6Pilot with Arabic-speaking users Four to eight weeks with a real department, feedback captured per answer, and weekly review of failures split by OCR, retrieval, generation and interface.
- 7Acceptance and hand-over Report Arabic and English scores separately against the evaluation set, deliver bilingual documentation and training, and hand over the evaluation harness so the entity can re-run it.
- 8Archive remediation (parallel) Where the baseline shows scans are unusable, run a re-scanning or manual correction programme on the highest-value documents rather than trying to fix it in software.
Security & deployment
Arabic government content is treated as classified data throughout: OCR, index, model and logs run inside the entity's network or a UAE-region private cloud, with no processing by external services and no outbound calls at run time. Access to Arabic documents follows the source system's permissions, applied at retrieval, and the audit log stores the Arabic question and the source identifiers so an investigation can reconstruct any answer. Manual OCR correction queues are themselves access-controlled, since correction staff see full document text. Air-gapped delivery is supported, with Arabic OCR models, embedding models and language model weights transferred as signed offline bundles.
Limitations & prerequisites
- Arabic OCR accuracy on degraded scans, stamped pages and handwriting remains materially below what is achievable on clean printed English; some archives need re-scanning or manual correction rather than a better algorithm.
- Dialect coverage is uneven. Gulf dialect in writing is inconsistent in spelling, and no model handles every variant; dialect support is best implemented as query expansion plus fallback, not as an assumption.
- Handwritten Arabic recognition is not production-grade for general correspondence and should be scoped as a manual process with AI assistance, not automation.
- Multilingual embedding models are usually weaker in Arabic than in English, so retrieval tuning and Arabic-specific testing take longer than an English-only project.
- Mixed-direction text (Arabic with embedded English terms, numbers, codes and URLs) breaks in export and printing more often than on screen; it needs explicit test cases.
- Translation between Arabic and English introduces drift in legal and technical terms. Where the Arabic text governs, the system should quote it verbatim rather than paraphrase in English.
- Arabic evaluation requires subject-matter experts' time to build and maintain the gold answer set; without that commitment from the entity, quality cannot be measured objectively.
Levels of Arabic support in AI products
Use this table to test a vendor claim of Arabic support, including our own.
| Capability | Translated interface only | Multilingual model, no tuning | Arabic-first engineered pipeline |
|---|---|---|---|
| Right-to-left screens | Usually yes | Yes | Yes, including print and export |
| Arabic OCR on scanned archives | No | Basic, clean pages only | Tuned and measured on your worst pages |
| Alef and hamza normalisation | No | Inconsistent | Applied identically at index and query |
| Dialect queries | No | Partial | Query expansion plus fallback behaviour |
| Cross-language retrieval | No | Sometimes | Tested in both directions |
| Hijri date handling | No | No | Parsed and displayed in both calendars |
| Arabic accuracy evidence | Vendor claim | Public benchmark | Score on your own evaluation set |
| Arabic documentation and training | Rarely | Sometimes | Delivered as part of hand-over |
The practical test is simple: ask for measured numbers on your own documents, in writing, before award.
FAQ
Document preparation. The software work is broadly similar; the difference is OCR tuning, manual correction of poor scans and the time subject-matter experts spend building and reviewing the Arabic evaluation set. On archives with heavy stamping or faxed material, preparation can exceed the development effort.
A sample baseline and evaluation set take two to three weeks. A working bilingual assistant on one document set is typically six to ten weeks after that. Archive remediation, where needed, runs in parallel and is sized by document count, not by software.
Yes. Arabic OCR models, embedding models and open-weight language models all run inside your network with no internet access at run time, delivered as offline bundles with a documented update procedure.
No training corpus is required for retrieval-based systems. What is required is a representative sample for OCR testing, typically one to two hundred pages spanning your worst and best material, and fifty to one hundred real questions with agreed answers.
Clean, natively digital or well-scanned printed Arabic extracts reliably. Quality falls with resolution, stamps over text, skew, low-contrast faxes and handwriting, and there is no fixed percentage that applies to all archives. We measure character and field accuracy on your own sample and report it before any commitment is made.
Dialect questions are handled by expanding the query into the formal vocabulary used in the documents, plus keyword fallback. This covers common administrative language well. It is not a general dialect understanding claim, and colloquial phrasing far from the document vocabulary will still need rephrasing.
Through read connectors to the document management, correspondence, CRM or ERP systems, with attention to character encoding, text direction and date formats at every hop. The source systems remain unchanged; the AI layer holds an index and returns links back to the original records.
You do. The normalisation library, prompts, dialect expansion lists, evaluation set and OCR configuration are handed over with documentation in Arabic and English, so your team can extend them to new document types without the vendor.
Does the Arabic actually work on your documents?
Send a sample of twenty representative Arabic documents and twenty real questions. We run OCR and retrieval quality tests inside your environment and return a written readiness report with measured numbers and the remediation needed.
Request an Arabic AI Readiness AssessmentSources & evidence
- Unicode — UAX #9: Unicode Bidirectional Algorithm — mixed-direction text handling
- W3C Internationalization — Structural markup and right-to-left text
- Unicode CLDR — locale data for Arabic formats, calendars and digits
- Tesseract OCR — open source OCR engine and language data
- NIST — AI Risk Management Framework (AI RMF 1.0)
Vendor and product names are trademarks of their respective owners; references are for technical context and do not imply partnership, certification or endorsement unless stated on the vendor's official pages.