The most common architecture for Arabic document processing was never designed. It accumulated. Teams inherit tooling built for English, so they put a machine translation step in front of it: scan the Arabic contract, translate it to English, then run extraction, classification, and search on the translation. On a slide it looks tidy. In production it quietly rewrites the record before anyone has analyzed it.

The problem is not that translation is bad. It is that translation is a lossy transform applied at the exact point where fidelity matters most, and every stage after it inherits the loss.

The pipeline that looks reasonable

Translate-then-analyze survives because each component is individually respectable. The OCR is decent, the translation engine is strong, the English NLP stack is mature. The failure lives in the seams. Translation optimizes for readability, not for preserving the legal and factual skeleton of a document. It smooths over ambiguity an analyst needed to see, and it makes confident choices that no one ever reviews.

There is a second cost that rarely appears on the architecture diagram: most translation engines are hosted services. The moment a contract or an ID scan is sent out for translation, the sovereign perimeter is broken, whatever the rest of the pipeline does. For a bank, a ministry, or a hospital, that alone is often disqualifying.

What the translation hop drops

Run enough real documents through a translate-then-analyze pipeline and the same categories of loss keep appearing.

  • Entities. One Arabic name has many Latin spellings. Abdulrahman, Abd al-Rahman, and Abdel Rahman can all be the same عبد الرحمن, translated three ways across three documents, so downstream entity resolution sees three people. Organization names fare worse: a literal rendering of a company name may or may not match the English name it actually registered.
  • Dates. Arabic documents routinely carry Hijri dates, Gregorian dates, or both. A translation layer either passes the Hijri date through as an unparseable string or converts it silently, and the conversion depends on which calendar variant is assumed. A deadline of 15 Muharram 1447 that drifts by a day is not a rounding error in a contract. It is a different obligation.
  • Negation and intent. Arabic negation rides on short particles whose scope is easy to mistranslate. The distance between لا يحق للمستأجر, the tenant has no right, and its affirmative reading is one dropped particle. Obligation, permission, and prohibition are exactly what contract analysis exists to find.
  • Digits, IDs, and addresses. Arabic-Indic digits, national ID formats, deed and plot numbers, and address conventions get normalized, reordered, or partially transliterated. A district name can come back translated as a common noun, and the address no longer joins to the master address table.

Take a supply contract as an example. The Arabic original counts penalties from a Hijri date, names three subsidiaries whose spellings differ across their own registration papers, and excludes liability in a negated clause. After translation, each of those is an approximation. The extraction model then performs well on text that is no longer the document.

Diglossia is not a spelling problem

Arabic adds a layer English pipelines have no equivalent for: diglossia. The contract is in fusha. The complaint attached to it is in dialect. The adjuster's notes mix both, with English loanwords in Arabic script. A translation engine trained mostly on formal news text renders dialect confidently and wrongly, and dialect is where intent lives: satisfaction, escalation, sarcasm, urgency.

Register carries signal too. Whether the writer used the formal register of an official complaint or the loose register of a follow-up message matters for routing and for risk. Translation flattens both into the same neutral English, and the signal is gone before classification starts.

A translated document is a new document. Analyzing the translation means analyzing the translator's choices, and nobody audits the translator.

What native processing keeps

Native Arabic document processing means the models read the Arabic itself: no pivot language, no intermediate rewrite. Entities keep their written form and resolve to one canonical identity across spelling variants. Hijri and Gregorian dates are parsed as first-class calendar types and stored side by side. Negation and modality are classified in the language where they are marked. Dialect is detected and handled as dialect, not mistranslated as broken fusha.

Just as important is what lands in the lakehouse afterwards. A native pipeline keeps the extracted field, the exact source span behind it, and both calendars, so every answer stays traceable to the Arabic text it came from:

-- what the native pipeline keeps
SELECT party_name_ar,           -- as written in the deed
       party_name_canonical,    -- one identity across spellings
       contract_date_hijri,     -- 1447-01-15
       contract_date_gregorian, -- derived, not guessed
       source_span              -- the exact Arabic sentence behind the field
FROM   contracts_extracted;

That source span column is lineage doing its real job. When a reviewer questions an extracted deadline, the answer points at the sentence in the deed, not at an English paraphrase of it.

The perimeter question

There is a final reason translate-then-analyze keeps failing governance review: the translation hop is usually the egress. Native processing removes the reason the data was leaving in the first place. In 0plus, Arabic document understanding runs inside your perimeter, on-premises, in a private cloud, or fully air-gapped, with zero calls to public AI and an audit log on every read and transform.

The test we suggest is simple. Pick ten real documents: contracts, ID scans, addressed correspondence. Run them through your current pipeline, then compare the extracted entities, dates, and negated clauses against a careful human read of the Arabic. The gap you find is not a model quality problem. It is an architecture problem, and it is fixable at the architecture level.