For Saudi audit, law & professional firms
How to Write an AI Usage Policy for a Saudi Professional Firm — What to Include
A usable AI policy for a Saudi audit, accounting, or law firm needs five things: scope and data classification, clear rules for sensitive versus non-sensitive client data, an approved-and-prohibited tool list, logging and incident-reporting expectations, and a review cadence with partner sign-off.
The policy should be short enough that staff actually read it, and enforced with tooling — not just a document nobody follows.
Why your firm needs a written AI policy now
Your staff are almost certainly already using ChatGPT, Copilot, or similar tools for client work — drafting memos, summarizing contracts, checking numbers — whether or not anyone approved it. Without a written policy, your firm carries that risk without having chosen it: nobody has decided which tools are acceptable, what data can go into them, or what happens if a staff member pastes a client's financial statement into a public chatbot. A short, clear policy turns an unmanaged habit into a managed decision.
This matters especially for audit, accounting, and law firms, where the professional duty of client confidentiality already exists independently of any AI tool — an AI policy is simply how that duty gets applied to a new category of software.
What a usable AI policy must include
A policy that staff will actually follow needs to be short, specific, and organized around real decisions people make day to day. At minimum, include these sections:
- Purpose and scope — why the policy exists, who it applies to (partners, staff, contractors), and which activities it covers (client work, internal admin, marketing, and so on).
- Data classification — a plain-language definition of what counts as sensitive client data in a Saudi context, so nobody has to guess.
- Approved vs prohibited tools — a named list of AI tools staff may use, tools that are explicitly prohibited, and who to ask when a new tool comes up.
- Rules by data class — sensitive client data stays on in-house or approved systems only; non-sensitive, everyday work may use approved cloud AI tools under the firm's own account.
- Logging and evidence expectations — what record, if any, is kept of AI usage, and who can review it.
- Incident reporting — what a staff member must do immediately if they suspect client data was pasted into the wrong tool, and that reporting it early is not treated as a disciplinary matter.
- Training and acknowledgment — every staff member reads the policy, attends a short briefing, and signs an acknowledgment before using any AI tool for client work.
- Review cadence — a fixed schedule, for example every six months, to update the tool list and rules as AI products change.
What counts as sensitive client data in a Saudi context: national ID or Iqama numbers, IBAN and bank details, VAT numbers and commercial registration (CR) numbers, phone numbers and email addresses tied to a client, client financial records and figures, and client names combined with case, deal, or engagement context. If any of these could appear in a prompt, treat that prompt as sensitive.
A realistic rollout order
Writing the policy is the easy part; getting it adopted is not. A rollout that actually works tends to follow this order:
- Draft the policy using the sections above, in plain language, ideally under two pages.
- Partner sign-off — the policy needs visible ownership from partners, not just IT or a junior compliance hire, or staff will not take it seriously.
- Staff briefing — a short, mandatory session where staff can ask real questions about their actual daily tools, not just a read-and-sign email.
- Tooling that enforces it — deploy whatever technical controls make the rules easy to follow, such as blocked tools, an approved gateway, or automatic classification, rather than relying on memory alone.
- Periodic review — revisit the policy and the tool list on the schedule you set, and sooner if a new AI tool becomes popular with staff.
The honest limitation: a document is not enforcement
A written policy cannot classify a prompt in real time, and staff under deadline pressure make mistakes even when they know the rules. A policy that says "do not paste client financial data into public AI tools" is necessary but not sufficient — it relies entirely on a person noticing, in the moment, that the paragraph they are about to paste contains an IBAN, or a client's name next to financial figures. That is exactly the kind of judgment call that breaks down under time pressure.
This is why the strongest policies pair the document with tooling that enforces the same rules automatically, so a mistake at the keyboard doesn't automatically become a confidentiality incident.
How Ithbat operationalizes the policy
Ithbat is built to be the enforcement layer behind exactly this kind of policy. It installs on hardware the firm already owns and classifies every prompt before it is processed, checking for Saudi-specific sensitive data — national ID or Iqama numbers, IBAN, VAT and CR numbers, client financial details, and sensitive keywords in Arabic and English. Prompts flagged as sensitive are kept and answered on the firm's own hardware and are never offered to any cloud provider; everyday, non-sensitive prompts can still be routed to a frontier cloud AI model on the firm's own account, under the firm's own policy.
Every inference, sensitive or not, produces a tamper-evident, hash-chained evidence record. Only metadata is shared with a dashboard; prompt and response content, and any cloud API keys, stay on the firm's own node. Because sensitive data is classified and processed on the firm's own hardware inside Saudi Arabia, this also supports PDPL alignment by construction — though the firm's own compliance program and independent assessor remain the final word. Engagements start as a fixed-scope, six-week pilot from SAR 15,000 for one office.