Most internal assistants are tried before launch with questions written by the project team, so the answers look convincing. Real employees, however, ask in their own dialect, abbreviate, write dates in different formats and ask about documents they are not entitled to see.

NIST’s Generative AI Profile, published in 2024, warns against extrapolating system performance from narrow, non-systematic assessments, and calls for performance to be demonstrated in conditions similar to the deployment setting, with the expected context of use documented. ^[1] The profile also notes that language models may perform less well in non-English languages or certain dialects, and that they can present false information with complete confidence. ^[1] Both are direct risks for any assistant that answers in Arabic.

What goes into the test set?

Start by gathering real questions: service desk logs, staff emails to HR, and recurring queries about policies. Then add what a casual trial never surfaces.

For each question, write down three things: the reference answer approved by a specialist, the document and paragraph it rests on, and the expected behaviour if an answer is not possible, such as asking for clarification or referring the user to the right team. Evaluators such as response completeness measure whether a reply contains the key information compared with the reference answer, so completeness cannot be judged without a reference answer written in advance. ^[4]

The questions and reference answers should be written by specialists from the departments that own the policies, not by the technical team alone, because they know which questions staff usually get wrong. Weight the categories by the impact of an error, so that allowances, leave and permissions get a larger share than general information.

Keep the acceptance set separate from the examples used to tune prompts or configure the assistant. If the team adjusts settings until the acceptance questions themselves pass, it has measured its ability to memorise the questions, not the quality of the assistant.

How should each answer be scored?

Do not give each answer a single score. Split the evaluation into independent dimensions, because an answer can be correct in substance but drawn from a document the user may not see, or grounded in the right source but incomplete.

Evaluation platforms offer automated metrics that help with triage, including groundedness, which estimates how well the retrieved context supports the answer, and relevance to the question. ^[4] These save time on large sets but do not replace a specialist’s judgement. NIST recommends comparing outputs with reference answers using both human oversight and automated evaluation, and reviewing the sources and citations the system provides. ^[1]

Attribution is tested by hand: open the cited document, match the paragraph and confirm it is from the current version. A link in the answer does not mean the information is actually there.

Can the user see what they should not?

An assistant that answers from organisational documents retrieves passages and sends them to the model. If document permissions are not enforced at retrieval, the answer may surface information from a file the user is not allowed to open. ^[3] Microsoft notes that trimming results by permission inside the search pipeline itself removes the need for custom permission code in the application, and is faster than loading larger result sets and trimming them there. ^[3]

Create test accounts that represent different roles: an ordinary employee, a department head and an employee from another department. Ask each account the same question and check that the answer reveals nothing beyond its access, not even as a summary or a hint. Also test what happens after access is withdrawn, because permission changes appear in search results only once the permission metadata has synced to the index. ^[3]

Testing untrusted input

The document itself can carry risk. Indirect prompt injection happens when the model reads external content, such as a file or web page, containing instructions that alter its behaviour. ^[2] OWASP stresses that retrieval-augmented generation and fine-tuning do not fully remove this risk, and that attackers may use multiple languages or encodings to slip past filters. ^[2]

Include documents prepared for this purpose in the test environment, containing text in Arabic and English that tells the assistant to abandon its task or reveal other content. The expected result is that the assistant carries on with its original task and the application blocks any action or disclosure beyond the user’s permissions. NIST lists red-teaming against attacks such as prompt injection among its measurement actions. ^[1]

Hypothetical example: a travel allowance question

A hypothetical organisation has built an assistant that answers questions on HR policies, and has approved a new travel policy taking effect at the start of next month. The team designed three cases:

• A question with a clear date for a trip after the effective date: the expected answer applies the new policy and states when it takes effect.
• A question with no date: the assistant should ask when the trip is, or set out both the old and new rules with the changeover date, rather than silently choosing one.
• A question from an employee without access to the senior management allowance table: neither the attachment nor its figures should appear in the answer.

An HR specialist reviewed all three answers, and the results were logged with the model version and documents used, so that the same cases can be rerun after every update.

How to read the results and decide on launch

Do not base the launch decision on the average pass rate alone. Divide errors into two categories:

1. Critical errors: disclosing content beyond the user’s permissions, following injected instructions, or giving a wrong answer on a financial or regulatory matter. These are fixed before launch, however rare they are.
2. Quality errors: an incomplete answer, weak wording or an imprecise referral. These are measured against a threshold the service owner sets in advance.

Record the limits of acceptable use in the launch decision: which topics the assistant answers, and which it refers to a member of staff.

To make results comparable from one round to the next, log for each test case: the question ID, the model version and settings, the version of the indexed documents, the role of the account that asked, the result on each dimension, and the reviewer’s name and review date. Without this log, after an update you cannot tell whether the assistant improved or the questions changed.

When should you retest?

Keep the same test set as a regression suite and rerun it when the model or its settings change, when documents are updated or new sources added, and when permissions are modified. NIST recommends re-evaluating risks when a model is adapted to a new domain and checking regularly that security measures remain effective. ^[1]

Applying this in Gulf workplaces

Involve specialists from different sites to cover local terminology, since the name of an allowance or type of leave may differ from one organisation to another. Include the Hijri and Gregorian date formats and the currencies your organisation deals in.

Arabic has features that affect retrieval before they affect the answer: variant spellings of the hamza, taa marbuta written as haa, alif maqsura written as yaa, and English terms transliterated into Arabic script. Write the same question in more than one spelling and check that the assistant reaches the right document each time. If retrieval fails, no amount of model quality will rescue the answer.

Do not put real employee data in test examples unless the environment is approved for it and appropriate controls are in place, and comply with the personal data protection law in force in your country, such as Saudi Arabia’s Personal Data Protection Law or the UAE’s Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data.

Conclusion

Testing an Arabic assistant is a project in its own right: questions from real work, reference answers, separate scoring dimensions, and tests for permissions and injected input. Anything tested once needs testing again whenever the model, the documents or the users change.

Staff are already using generative AI tools to draft messages, summarise reports and analyse data, whether or not a policy exists. The question is not whether AI is being used, but whether it is being used under known rules.

The generative AI profile that NIST published in 2024 identifies twelve risks that are unique to or made worse by this technology, including confabulation (confidently presenting invented information), data privacy, information security, intellectual property, harmful bias, and reliance on third-party components and suppliers. ^[2] Inside an organisation, each of these becomes a practical question: what may staff enter? Who checks the output? Who is accountable?

NIST explicitly recommends that organisations define acceptable use policies for generative AI interfaces and address illegal uses in them. ^[2]

What should the policy be built on?

The NIST AI Risk Management Framework (AI RMF 1.0) was released in January 2023 for voluntary use and is built on four functions: Govern, Map, Measure and Manage. The Govern function sets policies and accountability and cuts across the other three, so an acceptable use policy sits at its heart. ^[1]

ISO/IEC 42001:2023 was published in December 2023 and sets requirements for establishing, implementing, maintaining and continually improving an AI management system. It applies to any organisation that provides or uses AI-based products or services, whatever its size. ^[3] It includes a clause on AI policy (5.2) within the leadership requirements, a clause on AI system impact assessment (6.1.4), and an annex of reference controls. ^[4]

SDAIA’s AI Ethics Principles (Version 1.0, September 2023) apply to everyone who designs, develops, deploys, uses or is affected by AI systems in the Kingdom, and set out seven principles: fairness; privacy and security; humanity; social and environmental benefits; reliability and safety; transparency and explainability; and accountability and responsibility. ^[5]

The ten clauses of the policy

1. Purpose and scope

State who the policy covers: employees, contractors and trainees. State what it covers: public generative AI tools, AI features built into office software and systems, and models the organisation develops or buys.

2. Roles and responsibilities

Name the policy owner, the body that approves new tools, and who assesses high-risk uses. The NIST framework calls for documented roles and for staff to be trained in AI risk management. ^[1] SDAIA’s principles set out specific roles for adopting entities, including a Responsible AI Officer and an AI System Assessor. ^[5]

3. Approved tools and a register of uses

Maintain a list of permitted tools and the conditions for each, and keep a register of the AI systems in use. The NIST framework requires mechanisms to inventory AI systems, ^[1] and the generative AI profile suggests that the inventory record data provenance, known issues, human oversight roles and the underlying foundation model. ^[2]

4. Data classification: what may be entered?

In practice this is the most important clause. Link it directly to the organisation’s approved data classification policy: public data is permitted in approved tools; internal data only in tools the organisation has contracted; and personal or confidential data only in an environment approved for that purpose, in line with the personal data protection law in your country.

5. Permitted, conditional and prohibited uses

Classify uses by risk instead of writing a long list of prohibitions. SDAIA’s principles place systems in four categories: little or no risk; limited risk; high risk, which requires conformity assessments before and after deployment; and unacceptable risk, which is not allowed, with examples including social profiling of individuals and the exploitation of children. ^[5]

6. Human review and verification of output

Staff are responsible for any output they use as if they had written it themselves. Require numbers, references and names to be checked before use, because confabulation is one of the main risks of generative models. ^[2] Any decision affecting a person’s rights, such as hiring, appraisal or eligibility, remains a documented human decision.

7. Disclosure and transparency

Specify when AI use must be disclosed: in content published to the public, in automated replies to customers, and in reports that rely on automated analysis. Transparency and explainability is one of SDAIA’s seven principles. ^[5]

8. Intellectual property and confidentiality

Prohibit entering third-party protected documents or contractual secrets into public tools, and specify who owns the output and how it may be used in published material. Intellectual property is one of the twelve risks in the NIST profile. ^[2]

9. Cyber security and suppliers

Require cyber security approval before any tool is connected to the organisation’s systems or data. The NIST profile suggests red-teaming generative systems to test their resilience against attacks such as prompt injection, and including clauses on content ownership and security in contracts and service level agreements. ^[2] The core framework calls for policies and procedures that address AI risks associated with third parties, including intellectual property risks. ^[1]

10. Incidents, training and review

Define an AI incident, such as a data leak through a tool, publication of incorrect content or a biased decision, and set a reporting channel. The NIST framework calls for incidents and errors to be communicated to relevant parties, and tracked, responded to and recovered from under documented processes. ^[1] Tie the policy to short mandatory training, and set a review date.

Hypothetical example: a use classification table

Hypothetical example: a mid-sized service organisation attached this table to its policy:

The advantage of the table is that staff find the answer in seconds, and any new use is added to the right category rather than rewriting the whole policy.

How do you launch the policy so it does not stay on paper?

1. Map current practice first: a short survey of the tools actually in use and what they are used for.
2. Draft it with a joint team: legal, IT, cyber security, data protection, HR and a representative of the user departments.
3. Have it approved by top management: ISO/IEC 42001 places the AI policy within its leadership requirements. ^[4]
4. Provide the approved alternative before banning: at least one enterprise tool.
5. Train, then measure: short training with examples from the organisation’s own work, followed by periodic review of the register and incidents.

What differs across the Gulf?

Reference points differ from one Gulf country to another, so do not apply one country’s rules to the others. In Saudi Arabia, SDAIA’s principles are a key reference for principles, risk categories and roles, ^[5] and SDAIA has since issued further tools, including a national AI risk management framework, so check its latest publications before adopting the policy. In the UAE, the official government portal lists a generative AI guide covering uses and data privacy, and notes that the government has created the role of Chief Executive Officer for Artificial Intelligence in ministries and federal entities, with duties that include strategic planning and setting governance frameworks for AI adoption. ^[6] In other countries, check with the national data and AI authority and your sector regulator before adopting the policy.

Conclusion

A good AI acceptable use policy is short enough for staff to read and specific enough for them to find an answer to their everyday situation. Build it on the ten clauses, link it to data classification, classify uses by risk, and review it whenever the tools or requirements change.