AI Audit under PDPL

A PDPL-focused AI audit examines whether a defined personal-data processing activity has a supported legal and operational basis, and whether the organisation can demonstrate the controls it claims to use. The subject is the processing activity across its lifecycle. It is not simply the model, the hosting region or the privacy notice. An encrypted database does not explain why information was collected, and a signed contract does not establish what a supplier actually retains.

For Saudi privacy officers, HR leaders, technology owners and internal auditors, the practical objective is a traceable chain from purpose to data, recipients, controls and evidence. This guide develops an original audit approach using a hypothetical employee-survey theme analysis service. It supports a scoped technical and operational review; the accountable privacy and legal specialists must determine the applicable legal interpretation and any unresolved processing decisions.

Define the processing activity before the model assessment

The Saudi Personal Data Protection Law addresses personal-data processing and data-subject rights. The Implementing Regulation adds operational requirements, including processor selection and impact assessment. For audit purposes, identify the relevant provisions through a documented applicability analysis; describing a tool as AI does not supply that analysis.

In the illustrative service, staff submit survey responses and an AI application groups free-text comments into themes for management. The declared purpose is understanding workplace issues at an aggregate level. The service is not authorised to rank employees, infer individual health conditions or create performance scores. Those exclusions should be reflected in the inputs, prompts, reports and access arrangements, rather than appearing only in a project presentation.

Write the unit of review precisely: the named survey, participating employee population, collection period, approved analysis, model and application versions, recipients and output channels. Separate the pilot from any later rollout. If managers copy comments into another assistant, that is a different processing route to investigate. A review of the approved application cannot establish the behaviour of unrecorded parallel tools.

Assign a business owner and a privacy decision owner. The first explains why the analysis is needed; the second determines the documented legal basis and safeguards with the appropriate specialists. The technical team supplies evidence of actual processing. This division helps prevent a model engineer from being asked to approve a legal basis, or a privacy officer from being expected to verify a configuration without technical access.

Build a processing map that can be challenged

Start with one response and follow every relevant copy and transformation. In this example, the chain may include a survey platform, export file, preprocessing job, model request, temporary storage, theme output, management dashboard and support record. Treat this as a hypothesis to verify. The configured service may send diagnostic content to another recipient that does not appear on the business diagram.

For each stage, record the data fields, intended purpose, recipient, access roles, location evidence, retention setting and deletion mechanism. Distinguish identifiers removed from a file from information that still makes a person identifiable. A comment mentioning a unique role, branch and incident can identify someone without a name. Replacing employee numbers with stable codes should not be described as irreversible anonymisation.

Proposed processing-map evidence for an employee-survey AI review

Stage	Question to resolve	Evidence worth examining
Collection	What were staff told about this analysis and its recipients?	Notice version, form configuration and documented processing decision
Preparation	Which identifiers and unnecessary details are removed?	Transformation specification and masked before-and-after samples
Model processing	What content and metadata leave the application?	Authorised request evidence, service settings and contractual scope
Reporting	Can a manager infer individual respondents from filters or excerpts?	Role-specific views, aggregation rules and controlled disclosure tests
Retention and support	Where do secondary copies remain after the business task ends?	Storage inventory, support access records and verified disposal evidence

Mark an unknown field as unknown. A region name from a sales slide is not evidence of every processing or support location. A retention option in the interface may cover the main request store but not backups, abuse-monitoring records or exports. Obtain the scope of each statement and identify who can confirm it. The aim is to find the actual boundary of a claim rather than accumulate reassuring documents.

Examine purpose and legal-basis evidence together

The auditor should ask whether the recorded purpose matches what the service actually does. Inspect the approved analysis instructions, enabled features and representative outputs. If the application creates individual sentiment scores while the approved purpose describes aggregate themes, record the mismatch for the responsible privacy and business owners. Do not assume that an appealing new feature is covered because it uses data already collected.

Where the organisation relies on consent, inspect the relevant wording, version, collection record and process for handling withdrawal. Where it relies on another basis, request the documented assessment and its conditions. The audit should not imply that consent is always required or always sufficient. In an employment setting, a generic acceptance box does not resolve every question about the processing arrangement.

Test the notice against the actual route. If it says reports are aggregated but a manager can download raw comments, that is an operational inconsistency worth investigating. If it names one processor while the purchased service uses additional processing parties, determine whether the documentation and approvals address them. A later notice update may improve future communication without proving what earlier participants were told.

Maintain the distinction between an observation and a legal conclusion. The assessor can show that an export contained fields outside the approved specification. Whether that constitutes a breach of a particular provision, and what response is required, should be determined through the agreed governance process. A clear audit scope identifies these responsibilities before fieldwork begins.

Worked disclosure test: aggregate reports can still identify people

Consider a hypothetical survey with 420 responses. A dashboard allows filtering by office, department and role. One combination leaves three respondents, and the AI summary includes a distinctive sentence about a single employee's experience. The problem is not resolved by removing the employee-name column. The question is whether the permitted audience can reasonably connect the output with an individual using the context available to it.

Use synthetic comments and fictional organisational attributes to test this route. Establish the report's approved disclosure rule before testing. That rule may include minimum group sizes, restrictions on verbatim excerpts and combinations of filters, but the numerical choices require an organisation-specific assessment. This guide does not prescribe a statutory minimum group size or claim that any one threshold guarantees anonymity.

1. Create controlled test groups with known overlapping attributes and harmless distinctive phrases.
2. Generate the authorised aggregate report and record the application and prompt versions.
3. Use each permitted managerial role to apply single and combined filters.
4. Check displayed summaries, downloads and exports, including whether one view reveals information suppressed in another.
5. Test whether repeated queries or comparisons between adjacent groups expose a small group's contribution.
6. Document observed disclosure paths and the conditions under which they occurred.

A successful test supports the specific disclosure controls under the tested conditions. It does not prove irreversible anonymity across every possible external dataset. A failed test should distinguish direct exposure of raw text from inference enabled by combinations of outputs. These mechanisms may need different corrections: an export permission change for the first, and a reporting design change for the second.

Do not use genuine sensitive employee comments merely to make the demonstration persuasive. Synthetic fixtures can establish whether a filter or export control behaves as designed. If production evidence is needed to assess historical exposure, authorise a separate, minimised review with defined access and handling. Evidence handling for AI audits explains how to preserve a finding without unnecessarily multiplying personal-data copies.

Test minimisation at the point where data leaves

Compare the approved input specification with actual requests for selected, authorised cases. The audit question is not whether the model could process less data in theory; it is whether the chosen implementation sends only the information justified for its purpose. Employee names, account identifiers and precise timestamps may be unnecessary for theme grouping, while some organisational context might be justified. Record the rationale field by field.

Examine free text separately from structured columns. A preprocessing step can remove a name field while preserving a self-identifying narrative. Test known synthetic patterns and review failure categories, including Arabic names, transliteration and mixed-language comments. Do not interpret a successful match on a short test list as complete coverage of all identifiers or sensitive content.

Follow the transformed data into the real processing route. A masking function used in a notebook may not be enabled in the deployed application. A retry or support export may bypass the primary transformation. Examine these routes where they fall within scope, and record unavailable evidence explicitly. The conclusion should identify which transformations were observed in operation and which were reviewed only as design.

Evaluate processors, support access and secondary use

Build a responsibility record for the survey platform, application operator and model service. The parties' actual roles should follow the processing arrangement, not merely the labels in a marketing document. Ask who determines the purposes and means, who acts on instructions, and which further parties receive data. Have the privacy owner resolve role uncertainty before contractual controls are assessed.

Compare the signed arrangement with the purchased plan and current configuration. A statement about no training use should identify the service, data categories and exceptions to which it applies. Audit the evidence supporting that statement without claiming direct visibility into inaccessible supplier infrastructure. Likewise, distinguish customer-selected retention settings from a supplier's separate contractual or security-related retention.

Request evidence about support access: who can approve it, what information can be viewed, how access is recorded and how it ends. A support ticket containing a raw survey export can create a route outside the normal application controls. Sample relevant support events or witness a safe access process, and identify whether the available evidence demonstrates design, operation or only a supplier assertion.

Where evidence cannot be obtained, state the consequences for the engagement. Supplier evidence for AI systems helps assess relevance and sufficiency, while auditing vendor-controlled AI addresses restricted access. Neither approach turns a refusal to provide evidence into proof of wrongdoing; it may instead prevent the auditor from supporting a particular conclusion.

Check transfers against actual data flows

The Regulation on Personal Data Transfer Outside the Kingdom establishes conditions for transfers. A Saudi hosting region alone does not settle the assessment. The responsible specialists should evaluate the actual destination, recipient and transfer mechanism, together with any sector-specific requirements that apply to the organisation.

For the survey example, examine model processing, remote support, administrative access, exports and disaster-recovery arrangements within the agreed scope. Request evidence rather than infer the route from an invoice address. A supplier may have a Saudi contracting entity while a particular function uses another location; a foreign corporate parent does not by itself prove that every request crosses a border.

Record the approved transfer assessment and test whether the selected operational evidence matches it. If an unexpected destination appears, preserve the relevant facts and escalate for assessment. Do not label all overseas processing prohibited, or assume a contractual clause automatically resolves every condition. The finding should specify the mismatch and the unanswered legal or operational question.

Make rights and retention operationally testable

Select a permitted synthetic identity and walk through a rights request appropriate to the service. The objective is to establish how the organisation locates relevant records, verifies the requester, routes the request, assesses any lawful limitation and records the response. Avoid creating a real employee request without authority. The test should include derived records where they remain associated with an identifiable person.

For correction, examine whether an amended source response updates the relevant downstream report or whether the old statement remains available. For deletion, trace the approved disposition through primary storage, exports and derived stores. A deletion ticket is evidence of a request, not necessarily completion. Some retained records may have a separate justified purpose; document that decision rather than promising indiscriminate destruction of every copy.

Define the retention clock clearly. “Thirty days” is incomplete without a starting event, covered data categories and exceptions. It could mean thirty days after submission, project closure or account termination, which are materially different. Test an authorised example that has passed the relevant point and obtain evidence of the disposition or of a documented retention exception. Report backup and restoration limitations accurately.

Review impact assessment and breach readiness without inventing rules

Have the privacy owner assess whether the processing triggers an impact assessment under the applicable provisions, including Article 25 of the Implementing Regulation. The audit can then examine whether the recorded risks match the actual service and whether promised mitigations operate. A generic impact template that never considers employee identifiability, secondary use or manager filtering may not address this processing activity.

Test the organisation's ability to recognise and escalate a potential personal-data incident using a tabletop scenario. For example, a fictional manager downloads a report containing synthetic respondent-level detail outside the approved reporting rule. Trace detection, ownership, fact gathering and notification decision-making. Under Article 24, the authority-notification rule includes a qualified 72-hour period from awareness; the team should assess its conditions and other applicable notifications, rather than assume every event follows one identical rule.

Record separate times for event occurrence, detection, organisational awareness and escalation. An incident ticket opened late does not necessarily establish when awareness began. The exercise should also show who can preserve evidence while limiting access and preventing further disclosure. It evaluates readiness; it does not establish how the organisation handled an actual breach that was not examined.

Reconcile conflicting evidence before forming a conclusion

Privacy reviews often reveal documents that describe different versions of the same service. A procurement questionnaire may promise one retention period, a signed addendum another, and the current configuration a third. Record each item's date, author, contractual status and service coverage. Ask the accountable owner to establish which commitment governs and what actually happened. Selecting the most favourable document is not an audit resolution.

Apply the same discipline to historical model use. A new no-training setting does not establish how earlier requests were treated. Obtain the effective date and relevant supplier evidence, and distinguish known history from unavailable history. If the original population cannot be reconstructed, explain the resulting limit rather than invent a complete retrospective account.

Finally, test whether a material service change reaches the privacy decision process. Adding individual recommendations, a new recipient or another reporting audience can change the original assessment. A useful change record identifies the altered processing, the specialist review and the evidence required before use. This is an original audit proposal, not a claim that every configuration adjustment requires the same approval route.

Report a processing conclusion with a usable remediation path

An example finding might state that the tested dashboard export exposed synthetic respondent-level text despite an approved aggregate-only reporting rule. Link the criterion, role, report version, filter state and export evidence. Describe the potential impact and distinguish the observed export behaviour from any unverified historical disclosure. Ask the owner to investigate the cause rather than assume the model itself is responsible for an application permission defect.

A remediation package could restrict the affected export, correct role permissions, review historical access within an authorised scope and retest combined filters. Define what evidence closes each action. Management acceptance of an unresolved limitation should remain visible and should not be confused with technical correction. Use retesting to verify the relevant behaviour and a findings register to retain ownership, dependencies and closure evidence.

For an AI auditing engagement, prepare the processing map, legal-basis decision, notices, supplier arrangements, impact assessment decision and a masked example of available records. Request an audit scoping discussion for an AI personal-data processing activity to agree the evidence boundary and specialist responsibilities. A useful report explains the supported processing claims, the observed exceptions and the decisions still requiring an accountable owner.