Knowledge is a decision system, not an archive
Most organizations hold large volumes of Arabic material: policies, operating procedures, contracts, meeting records, reports and correspondence. Volume does not equal usable knowledge. If an employee cannot identify the authoritative source, see when it was last reviewed, or understand where it applies, the organization has an archive rather than a knowledge system. The risk grows when an AI assistant gives a fluent answer based on an obsolete document or an unapproved draft.
The right objective is a visible chain between question, evidence and decision. When a regional manager asks how a commercial proposal should be approved, AI search should return an answer with its source, version and owner, while stating whether the rule applies to that sector, geography or exception. This changes the conversation from “Should we buy a RAG tool?” to “Which knowledge may shape our decisions, and who is accountable for it?”
Start with a knowledge map tied to real work
Before moving files into any platform, map recurring decision journeys. Begin with questions that consume expert time or produce inconsistent practice across units: How should a complaint be handled? Which documents are needed for a request? Who can approve an exception? Then classify the possible evidence: a formal system record, policy, template, documented expertise or prior case decision. This map exposes gaps that shared folders hide.
Use a simple record for each knowledge domain: process name, users, decision supported, approved sources, content owner, review cycle, sensitivity level and quality indicator. In Saudi organizations, the record may also need to distinguish the source language, whether a translation is authoritative or explanatory, and boundaries for sharing content among subsidiaries or partners. Taxonomy should not be a back-office exercise. Test it with staff who need answers while work is moving.
Arabic quality determines retrieval quality
Arabic content needs language-aware preparation, not merely conversion into indexable text. Variations in hamza, taa marbuta and alif forms, together with Arabic terms written beside English acronyms, all affect search results. Enterprise documents also contain vague headings, scanned pages and tables that do not survive text extraction cleanly. Without addressing these details, the system may retrieve a linguistically similar document that is operationally wrong.
Set acceptance criteria before content enters the knowledge base. Is the text machine-readable? Do headings describe the topic? Are tables and appendices connected to their context? Are terms standardized, or supported by a synonym dictionary? Does the content show an effective date? A bilingual enterprise glossary for commercial, operational and technical terms is worth creating, with a short definition and owner for each term. It serves people and Arabic AI search at the same time.
Design RAG as a governed service
RAG does not remove governance. It makes governance part of every answer. Keep approved content separate from temporary working materials, and apply access controls before retrieval, not after it. The system may need to recognize a user’s role and business unit so it does not expose material they are not entitled to see. In sensitive domains, the answer should point to an accessible source rather than reproduce a full passage outside its context.
Define explicit assistant behavior: when it may answer, when it should ask for clarification, and when it must refer the user to the process owner. It should not turn legal or contractual text into a binding determination unless the organization has deliberately designed and reviewed that use case. Practical governance questions include: Can every answer be traced to a specific passage? Are questions logged without retaining unnecessary information? How are conflicting sources handled? Who can withdraw or correct knowledge that proves wrong?
Measure decision quality, not usage alone
Conversation count and search volume indicate activity, not value. Useful measurement begins with a sample of real questions and reference answers reviewed by process owners. Assess source accuracy, answer completeness, confidence boundaries, adherence to access rights and time required to reach a decision. Also track the share of cases where the system says it has no approved source. That can reveal a genuine knowledge gap or weak retrieval design.
Run a monthly or quarterly improvement cycle according to the sensitivity of the domain. Collect retrieval failures, terms users did not understand and conflicting sources, then fix the cause rather than the symptom. The remedy may be a policy update, a clearer heading, a new synonym or removal of a source from indexing. Give leadership a small, readable dashboard: domains with highest benefit, domains with highest risk, reviewed-content coverage and the most material open knowledge gaps.
A practical first 90 days
In the first 30 days, choose one use case with clear value and manageable boundaries, such as internal HR policy inquiries or customer-service procedures. Assign an executive owner, content owner and technical owner. Limit the approved sources, then inspect them for text quality, permissions and version status. Do not begin with the entire enterprise repository. That delays learning and makes failure difficult to diagnose.
From days 31 to 60, build a constrained prototype and test it with real employee questions, including ambiguous questions and exceptions. From days 61 to 90, address recurring faults, establish publication and review rules, and agree the measurement criteria before scaling. Expansion should rest on evidence: Did the system improve access to trusted sources? Did it reduce rework or search time in the target workflow? Do users know when not to rely on the answer? If those answers remain unclear, expansion is premature.