For Saudi audit, law & professional firms
How to prove to a client their data never left your office when using AI
A verbal assurance is not proof — real proof is a per-inference record showing that each AI prompt was classified, where it was processed, and that sensitive data never left your firm's hardware.
That record should be tamper-evident and hash-chained, so any later edit is detectable, and summarized into a report you can hand to the client. It demonstrates diligence with objective evidence — it is not a legal certification.
Why "we kept it in-house" no longer satisfies clients or regulators
Saudi audit, accounting, and law firms increasingly use AI tools to draft memos, summarize files, or answer questions on live client data. When a sophisticated client — a bank or a listed company — asks “did any of our data get sent to an outside AI service,” a partner's verbal reassurance is no longer a sufficient answer. Clients who understand the risk want to see how a firm actually processed their information, not just hear a promise about it.
This is not primarily a regulatory problem. It is a trust problem. A firm's reputation for confidentiality is a core asset, and when clients already question cloud AI use, “trust us” is a weak answer compared to a firm that can produce a record. The Kingdom's data protection framework, نظام حماية البيانات الشخصية (PDPL), and مكتب إدارة البيانات الوطنية (NDMO) guidance reinforce this expectation by focusing on how personal data is actually processed, not on assurances after the fact — but the underlying pressure is commercial before it is regulatory.
What real proof looks like: per-inference evidence
Proof starts at the level of the individual AI request, not the firm as a whole. Every time someone at the firm submits a prompt to an AI system, that single event should generate its own evidence — this is what “per-inference evidence” means. Instead of one blanket statement covering months of work, the firm has a record for every prompt, at the moment it happened.
A useful per-inference record captures:
- Classification result — whether the prompt was flagged as containing sensitive data (national ID or Iqama numbers, IBAN, VAT or commercial-registration numbers, client financial figures, and similar categories) or treated as routine.
- Processing location — whether the request was handled on the firm's own hardware or, for non-sensitive prompts only, routed to a cloud AI provider under the firm's own account and policy.
- Egress confirmation — an explicit indicator, for anything classified sensitive, that it was not offered to any external service.
- Timestamp and requester context — when the request happened and which workflow it belonged to, without needing to store the prompt or response content itself.
Note what is deliberately excluded: the record itself should not need to contain the client's actual data or the content of the AI's answer to be useful as evidence. Metadata about how the request was handled is what proves the process; the underlying content stays where it always was — on the firm's own systems.
Why the record has to be tamper-evident, not just a log file
A plain log file is easy to edit, delete, or quietly regenerate after the fact — which means, on its own, it is only marginally more convincing than a verbal claim. If a firm could produce a “clean” log after a client complaint, the log proves very little.
The fix is a hash-chained structure: each record's hash is calculated to include the hash of the record before it. Change or remove any entry, and every hash after it fails to match, so the tampering is detectable rather than hidden. This is what “tamper-evident” means in practice — it does not require anyone to sign each record individually, and it is not the same claim as a legal signature. It simply means any break in that consistency is visible on inspection.
Tamper-evident is not the same as “signed” or “certified.” A hash chain shows that a sequence of records has not been altered after the fact. It does not, by itself, make the records a legal certification of compliance — that still depends on the firm's own policies, a lawyer's review, and, where relevant, a formal assessment against PDPL by a qualified assessor.
What a client confidentiality assurance report should contain
Individual records are the raw evidence; a client or a regulator will want a readable summary. A confidentiality assurance report built from per-inference evidence should include:
- The engagement scope and time period the report covers.
- A summary of how many prompts were classified as sensitive versus routine, without exposing the underlying content.
- Confirmation that sensitive prompts were processed on the firm's own hardware and were not offered to any external AI provider.
- An explanation, in plain language, of how the hash-chained record was checked for integrity over the period covered.
- A mapping of these practices to PDPL and NDMO principles the client or regulator would recognize.
- Bilingual Arabic and English text, since the client, their board, or a regulator may need either version.
The practical steps to produce one
Producing this kind of evidence is not a one-time document; it is a byproduct of how the firm runs AI day to day. In practice, a firm needs to:
- Put a classification step in front of every AI request, before it reaches any model, local or cloud.
- Define the sensitive-data categories relevant to Saudi client work — national ID/Iqama, IBAN, VAT and CR numbers, and client financial records.
- Record each request's classification, processing location, and egress status automatically, without relying on staff to self-report.
- Store those records in a hash-chained sequence and periodically verify the chain has not broken.
- Generate a confidentiality assurance report per client engagement or reporting period, rather than only when a client asks.
- Share the report proactively — offering this evidence unprompted signals more confidence than producing it only under pressure.
What this proves — and how Ithbat does it
Be clear about the limits of this evidence. A per-inference, hash-chained record demonstrates that a firm has a disciplined, auditable process for classifying and routing AI requests, and gives objective evidence that sensitive data was kept on the firm's own systems. It is not a legal guarantee, and it is not a substitute for formal PDPL certification, which still requires the firm's own legal counsel and a qualified assessor. What it does is replace an unverifiable promise with something a client or regulator can actually inspect.
This is the specific problem Ithbat's Evidence Trace is built to solve. Ithbat classifies every prompt before processing it, keeps anything flagged as sensitive on the firm's own on-premise hardware as a hard guard — never offering it to any cloud provider — and generates a tamper-evident, hash-chained record for every single inference. Only metadata about how each request was handled is shared with the coordinator dashboard; prompt content and cloud API keys never leave the firm's node. That evidence rolls up into a bilingual Client Confidentiality Assurance report mapped to PDPL and NDMO, which a firm can hand directly to a client or regulator.