AI for Defence: Arabic Document Triage and Multilingual Intelligence Workflows

A defence ministry scenario, the kind that recurs across the Gulf. A single intelligence directorate ingests, on an average week, several thousand Arabic documents (court filings, parliamentary transcripts, regional press, social-media archives, leaked PDFs, scanned signals, transcribed broadcasts) plus a comparable English and Persian load. The team has perhaps thirty analysts. The arithmetic is unforgiving: most of the pile is never read by anyone before it is overtaken by the next pile. AI triage is the response to that arithmetic, and it has to work in Arabic first, multilingual second, and offline always.

This pillar walks through the operational shape of an Arabic-first triage system for a defence buyer. It is not a vendor pitch. It is the architecture, the model choices, the air-gap discipline, the analyst integration, and the evaluation posture that any sovereign defence customer should expect from a credible deployment in 2026. Hosn is one realisation of this pattern. The pattern itself, and the reasoning behind each choice, is what matters for procurement.

The Arabic-OSINT pile-up problem

Open-source intelligence used to be a workable manual discipline. A team of regional specialists could read the major Arabic dailies, monitor a handful of broadcast channels, and clip what mattered into a weekly product. That model has not survived the volume increase of the last decade. Telegram channels, X archives, regional podcasts, leaked court documents, parliamentary committee transcripts, ministry tender portals, and dialect-rich social media now generate daily volumes that no manual team can fully read.

The volume problem is compounded by three structural challenges. The first is multilingualism: a single dossier on a regional actor will mix Modern Standard Arabic, Gulf and Levantine dialects, English, and often Persian or Turkish on the periphery. The second is format diversity: the same dossier contains scanned PDFs of varying quality, photographed pages, machine-generated transcripts, raw HTML, and structured tables. The third is the speed of relevance decay: a document that mattered on Tuesday morning may be operational waste by Wednesday evening.

The result is a directorate that does not have a quality problem. It has a coverage problem. Strong analysts read deeply; the unread tail behind them is what carries the strategic surprise. AI triage exists to compress that tail.

What AI triage actually means here

The defence-AI conversation has been polluted by autonomy fantasies on one side and reflexive scepticism on the other. Triage is neither. It is a narrowly scoped, well-defined, and auditable function. A triage system does three things, in order.

• Rank. Score every incoming document against the unit's standing collection priorities. Documents move from a flat queue into a prioritised one. Nothing is deleted; nothing is hidden. Analysts can always re-sort.
• Summarise. Produce a short, language-faithful summary of every document, with named-entity highlights, claim extraction, and links to the spans the summary is grounded in. The summary is for the analyst, not for distribution.
• Surface. Cluster related documents, expose contradictions across sources, and flag novelty against the directorate's existing knowledge base.

What a triage system does not do is decide. It does not classify documents at the security level. It does not declare an event significant. It does not write external products. The analyst remains the only authority for any output that leaves the unit. Inside that boundary, the system can move very fast.

The contrast with commercial document-intelligence platforms is useful. Palantir's AIP Document Intelligence, for example, also operates as ranked extraction over media sets, with classification and entity-extraction transforms exposed as pipeline steps. The shape is similar. The difference for a sovereign defence buyer is that the weights, prompts, and pipeline live inside its own perimeter rather than on a vendor-managed plane.

The three-layer architecture

A defence-grade triage system has three logical layers. Each layer is independently auditable and independently replaceable. Buying a single black box that fuses them is the most common procurement mistake.

Layer 1, ingest. Document acquisition, format normalisation, OCR, transcription, and language identification. Inputs include scanned PDFs, image stacks, audio, video, HTML, and email exports. Output is a uniform internal representation: clean text, page metadata, source provenance, language tags, and a hash for chain-of-custody. OCR for Arabic at this layer is now a near-solved problem on clean print: the QARI multimodal OCR family reports word-error rates near 16 per cent on diacritically dense text, with newer Arabic-specialised models reaching low single digits on standard benchmarks. Bad inputs (low-light photos, faxes, handwritten margin notes) are routed to a human reviewer with confidence scores attached, not silently mangled.

Layer 2, classify. Topic classification, entity extraction, sentiment, claim extraction, and dialect tagging. This is where the language model spends most of its tokens. Each task is its own prompt template with a documented schema, and each classification carries a confidence score and a quoted span. The unit owns the topic taxonomy. The model fits the taxonomy, never the other way around. The KITAB-Bench Arabic document understanding benchmark covers nine task families that map directly onto this layer, which is useful both for vendor selection and for ongoing internal evaluation.

Layer 3, surface. Ranking, clustering, deduplication, contradiction detection, and the analyst-facing UI. This is where the system meets the human. The UI is a queue, not a chatbot. Each item shows the source document, the structured extraction, the confidence-coded summary, and the action buttons the analyst needs (read, defer, escalate, archive, mark wrong). All actions feed back into the evaluation pipeline.

The three layers communicate through a documented internal schema. Replacing the OCR engine, the model, or the UI must not require touching the others. This is what keeps the system upgradable for the next decade rather than the next quarter.

Arabic-specific challenges

Arabic is not English with different glyphs. Four characteristics of real-world Arabic text break naive pipelines, and a defence-grade system has to address each one explicitly.

Dialect divergence. Modern Standard Arabic dominates official writing, but social media, intercepted communications, and broadcast informal speech are dialectal. Gulf, Levantine, Iraqi, Egyptian, and Maghrebi forms diverge at the lexical, morphological, and syntactic level. A model trained primarily on MSA will silently underperform on dialectal inputs. Falcon Arabic from the Technology Innovation Institute was specifically trained to span MSA plus Gulf, Levantine, and other major dialects, and is the strongest open-weight option for that breadth in 2026.

Code-switching. Real Arabic-language documents in defence-relevant domains routinely mix Arabic with English, Persian, or technical Latin terminology in the same paragraph. Tokenisers and language-identification systems that operate at document level get this wrong. The fix is to identify language at the span level (paragraph, sentence, sometimes clause) and to route mixed spans through a multilingual generalist alongside the Arabic specialist. Qwen 3.6, which spans more than two hundred languages and dialects, plays this role well.

Transliteration. Names, places, and proper nouns appear in multiple Romanised forms across sources. The same Iranian general can appear under five spellings in five reports. Resolving them is a deterministic mapping problem, not a model problem. The system maintains an institution-owned name authority file and applies it at ingest. The model is allowed to suggest new mappings, but the authority file is human-edited.

OCR quality on degraded sources. Court filings, faxes, photographed seizures, and historical archive material vary wildly in quality. The pipeline keeps both the raw OCR output and a model-cleaned variant, with diffs preserved. Analysts can always see what the OCR thought versus what the model rewrote, which protects against fluent-but-wrong reconstructions.

Model selection

No single open-weight model covers the full triage workload at the quality level a defence directorate needs. The right configuration in 2026 runs three models concurrently and routes each task to the model best suited to it.

• Arabic core: Falcon Arabic plus Qwen 3.6. Falcon Arabic carries the MSA-and-dialect heavy lifting: summarisation, named-entity recognition, claim extraction, and dialect tagging on Arabic documents. Qwen 3.6 covers code-switched spans and provides a second opinion when Falcon's confidence is low. Routing between them is determined by language identification at the span level, not by the document as a whole.
• English and long-context: Gemma 4. Gemma 4 from Google DeepMind, released April 2026 under Apache 2.0, with a 256K context window on the larger variants, handles English-language summarisation and any task that needs to ingest a full long document at once. The 27B mixture-of-experts variant fits comfortably on departmental hardware.
• Analyst question answering: DeepSeek R1. DeepSeek R1, the MIT-licensed reasoning model with distilled 32B and 70B variants, is the right choice for the interactive Q&A surface where an analyst poses follow-up questions across the directorate's accumulated knowledge base. Its structured-reasoning behaviour is what the analyst experience needs, even if Falcon and Qwen handle the upstream extraction.

All three families are open-weight and run fully air-gapped. None of them require a vendor heartbeat. The institution owns the weights file, the prompts, and the evaluation harness. Updates are pulled, signed, and tested on an internal cadence rather than imposed by a remote control plane.

Air-gap deployment realities

A defence-grade triage system is not an air-gapped system because the marketing brief said so. It is air-gapped because the source material includes seized media, intercept-derived documents, and partner-shared products whose handling rules forbid public-network exposure. The architecture has to respect that reality at every layer.

The deployment ships as a signed bundle: operating system, hardened Linux base, container images, model weights, OCR engines, dependencies, and an offline package mirror. The bundle is verified against a published hash and loaded once across a one-way data diode into the classified enclave. From that point forward, the system never reaches outward. Updates follow the same path on a documented cadence (typically monthly for security patches, quarterly for model refresh) and are staged in a non-production enclave before promotion.

Storage is encrypted with keys held on a hardware security module the institution owns. Logs are local and survive operator turnover. The retention policy aligns with the institution's existing classification regime. The general principle for hardened computing on classified networks (whether expressed through US SIPRNet-style separation or through ICD-705-style facility controls) is straightforward: assume the public internet does not exist, and design every operational procedure to work without it. AI triage fits inside that posture cleanly because the modern open-weight stack is designed to run fully offline.

Analyst workflow integration

The triage system is judged by what the analyst does with it, not by what the model produces in isolation. Three integration choices shape that experience.

The first is queue, not chat. The default surface is a prioritised work queue with structured items, not a free-form conversation. Free-form chat has its place (it lives on the analyst Q&A surface, see DeepSeek R1 above) but the daily volume work happens in a queue the analyst can drive at speed: read, defer, escalate, archive, mark wrong, with one keystroke each.

The second is grounded summaries. Every model-produced summary in the queue links to the spans in the source document it is grounded in. The analyst sees the original Arabic alongside the summary, with the cited span highlighted. Hover a sentence in the summary, see the source. This is what allows the analyst to trust the queue at speed, and what protects against fluent fabrication.

The third is feedback that improves the system. Every analyst correction (a wrong entity, a missed claim, a misread dialect, a poor summary) is captured as a structured signal. These signals feed both retrieval (better examples for in-context grounding) and a periodic supervised fine-tune of the Arabic core. The model adapts to the unit's specific taxonomy, vocabulary, and threshold for relevance, rather than averaging into a generic baseline.

The integration is not glamorous. It looks like a well-built case-management tool with very fast keyboard shortcuts and a model in the back. That is the point. The model disappears into the workflow.

Evaluation and red-team posture

A defence customer cannot evaluate this kind of system on vendor benchmarks alone. Three evaluation tracks run in parallel from day one of deployment.

The first track is gold-standard recall. The unit holds a frozen, curated set of historical documents with analyst-written ground truth: the right priority, the right entities, the right summary, the right cluster. Every model and prompt change is run against this set before it is allowed near production. The set is updated quarterly with new material so it does not stale into irrelevance. Public benchmarks like KITAB-Bench are useful for vendor screening but never substitute for a unit-specific gold set.

The second track is online analyst feedback. Every triaged item is exposed to the analyst with a one-keystroke "this was wrong" path. The aggregate of those signals, rolled up by topic, model, and prompt version, is the operational health metric. A model that scores well on the gold set but degrades on live analyst feedback is the canary that something has shifted in the source distribution.

The third track is adversarial red-teaming. A small internal team produces inputs designed to break the system: prompt-injection embedded in source documents, dialect mixes the model has seen rarely, transliterated names crafted to confuse the authority file, synthetic OCR noise designed to flip a classification. Findings feed both a regression test set and the fine-tune corpus. This track runs continuously rather than as a single pre-deployment exercise.

A triage system that runs all three tracks and acts on the findings will improve over time. A system that runs none of them will quietly rot. The discipline, more than the model choice, is what separates a useful deployment from a procurement museum piece.

If your defence directorate is sizing an Arabic-first triage system, the next step is a one-hour briefing tailored to your concurrency, classification, and integration requirements. Email [email protected] or message +968 9889 9100. We will come to you, walk through the architecture, the models, the evaluation posture, and a credible plan against your timeline. Pricing is by quotation, sized to your specific requirement.