For Saudi audit, law & professional firms
Can a Saudi audit or accounting firm use ChatGPT on client files under PDPL?
No — not for sensitive client data. Pasting a client's national ID, IBAN, VAT or CR number, or financial records into ChatGPT hands that information to a third party your firm doesn't control, which breaks your professional confidentiality duty and collides with PDPL's rules on cross-border and third-party data transfers. Non-sensitive, everyday work can still safely use cloud AI, as long as sensitive material stays off it.
What Actually Happens When You Paste Client Data Into ChatGPT
When someone types a client's trial balance, a payroll file, or a national ID number into ChatGPT, that text leaves the firm's own devices and network. It becomes a prompt sent over the internet to servers run by the provider, located outside the firm's infrastructure and, for a Saudi firm, outside Saudi Arabia entirely. What happens next depends on the account type. On consumer-tier accounts, that input can be logged, reviewed for safety and abuse, retained for a period, and — unless the user has explicitly opted out or is on a business or enterprise plan with different data controls — used to help improve future models. Even where a provider states it does not train on business-tier data, the content still passes through and rests, at least temporarily, on infrastructure the firm doesn't own or control, run by a company the firm has no confidentiality agreement covering that specific use.
The point isn't that any particular provider is careless. It's that the moment a prompt is sent, both control of the data and its physical location change — and that change is exactly what triggers the confidentiality and data-protection questions below.
Why This Collides With Your Confidentiality Duty and PDPL
Auditors and accountants operate under a professional duty of confidentiality that predates AI tools: financial statements, ownership structures, payroll data, tax positions, and deal terms are meant to stay inside a controlled circle of people bound to protect them. That duty is generally about who can access client information, not about which software touches it. Pasting an unredacted trial balance or a client's Iqama number into a public AI tool run by an unrelated company is, in substance, sharing that information with a third party — often without the client's knowledge, and without the contractual protections the firm would normally insist on before disclosing anything to an outside party.
Saudi Arabia's Personal Data Protection Law (PDPL) adds a second, more specific layer. PDPL governs how personal data is collected and processed, requires a proper legal basis, treats certain categories with extra care, and restricts transferring personal data outside Saudi Arabia unless specific conditions are met. National ID and Iqama numbers, phone numbers and emails tied to an identifiable person, banking details such as IBANs, and client financial records are exactly the kind of personal — often sensitive — data that audit and accounting work handles daily. VAT numbers and commercial registration (CR) numbers identify a business, but in a small or closely held company they routinely lead straight back to identifiable individuals. Sending any of that into a public AI tool is, functionally, a cross-border transfer to a third-party processor — one the firm usually can't fully account for, let alone show it met PDPL's conditions for.
Not Every Prompt Is Equally Risky
The realistic goal isn't banning AI outright — it's knowing, prompt by prompt, which category you're in.
- National ID or Iqama numbers
- IBANs and other banking details
- VAT numbers and commercial registration (CR) numbers
- Phone numbers or emails tied to an identifiable client
- Financial statements, payroll data, or tax positions
- Any text that combines a client's name with numbers or account details
Non-sensitive, everyday work looks different: drafting a generic email template, checking the wording of an accounting standard, summarizing a publicly available regulation, or brainstorming the firm's own internal marketing copy. None of that identifies a client or exposes their numbers.
Quick test: before pasting anything into a public AI tool, ask: "If this text named a real client and they read it over your shoulder, would you be comfortable?" If the answer is no, it doesn't belong in a public AI tool.
How to Keep Using Frontier AI Without the Exposure
The practical fix is to screen every prompt before it leaves the firm's control, rather than leaving that judgment call to whichever staff member is typing. Prompts that contain the sensitive categories above should be processed and answered on hardware the firm already owns, inside its own office, and never offered to any cloud provider. Prompts that don't contain sensitive personal or client data can still go to a frontier model such as ChatGPT or Claude — on the firm's own API key — because there's nothing in them that creates a PDPL or confidentiality problem in the first place. The routing decision itself should happen automatically and consistently, not case by case in someone's head.
What Evidence Should a Firm Keep
Whatever approach a firm takes, it should be able to show — after the fact, not just in policy — what happened to a given prompt. That means being able to answer:
- Did this prompt stay on our own hardware, or did it go to a cloud provider?
- When did that happen, and how was it classified at the time?
- Can that record be shown to have not been quietly edited afterward?
- Can we produce a plain-language report for a client or an assessor without exposing the actual prompt content in the process?
That last point matters: a compliance log that reproduces client financial details is itself a new confidentiality risk. The useful version captures metadata — timestamps, classification decisions, routing outcomes — not the underlying content.
How Ithbat Addresses This
Ithbat is built around exactly this split. It's an on-premise AI gateway installed on machines the firm already owns, running Arabic-first models like ALLaM or SILMA locally, alongside an OpenAI-compatible endpoint. Every prompt is classified before it's processed: prompts matching Saudi-sensitive patterns — national ID or Iqama numbers, IBANs, VAT and CR numbers, client financial records, and related keywords — are kept and answered on the firm's own hardware and are never offered to any cloud provider, as a hard guard rather than a setting someone can forget to enable. Non-sensitive, everyday prompts can still be routed to a frontier model such as Claude or ChatGPT, on the firm's own API key, governed and logged either way.
Every inference — local or cloud-routed — produces a tamper-evident, hash-chained evidence record. Only metadata reaches the coordinator dashboard; prompt and response content, and any cloud API keys, stay on the firm's own node. That record feeds a bilingual Client Confidentiality Assurance report mapped to PDPL and NDMO. Because sensitive personal data is processed on-premise inside Saudi Arabia rather than transferred elsewhere, the cross-border and third-party questions that complicate public AI tools largely don't arise for that data — formal certification is still completed with the firm's own assessor. Firms typically start with a fixed-scope, six-week pilot from SAR 15,000 for one office, before scoping annual licensing.