PDPL and AI Governance

PDPL and AI governance meet at a practical question: who can authorise a specific use of personal data, on what documented basis, and with which controls throughout the AI service? A model's technical capability does not answer that question. Governance must connect the proposed purpose to the data, supplier, configuration and operating process actually used.

This guide is for Saudi privacy teams, AI sponsors, procurement leaders and service owners. It develops a decision workflow around an illustrative merchant considering personalised marketing. The workflow helps prepare evidence for qualified privacy and legal review; it is not a finding that a particular processing activity complies with the law.

Review the processing purpose before approving the tool

The Personal Data Protection Law governs personal-data processing, including purpose, controller responsibilities and data-subject rights. Its marketing provisions require particular attention to consent and exclude sensitive data from the marketing permission described in Article 26. The law and implementing rules must be assessed against the actual activity.

For governance design, separate the reason data was collected from the new AI purpose. Information obtained to deliver an order is not automatically an unrestricted asset for profiling, promotion or supplier model improvement. The review should state what changes and identify the legal assessment needed before the new use proceeds.

Write one purpose per processing activity. “Improve customer experience with AI” combines too many possible actions. “Draft a response to a customer's delivery enquiry” and “rank customers for promotional offers” involve different recipients, consequences and information needs. Give each a separate decision boundary.

Record what the AI will produce and how people will use it. A draft can become a marketing decision if staff routinely accept it without further assessment. Review the actual workflow rather than relying on a product label such as assistant or analytics.

Make a purpose-to-data map

List inputs, transformations, outputs and recipients. Include free-text notes and attachments, not just database columns. A support conversation may contain information unnecessary for marketing even when it sits in the same customer record as a permitted contact preference.

For each input, ask why the task needs it and whether a narrower representation is sufficient. The answer should change the configuration. If the purpose only requires a product category and an authorised contact preference, sending a full delivery history and service narrative needs a separate justification.

Proposed purpose-to-data review worksheet

Field	What to record	Decision supported
Activity	A specific action and intended recipient	What is being authorised?
Original collection	Source, stated purpose and relevant notices or permissions	What prior context can be relied on?
Proposed AI use	Inputs, generated information and downstream action	What has changed?
Legal assessment	Responsible reviewer, applicable basis and conditions	May the defined processing proceed?
Technical boundary	Permitted fields, identities, retention and recipients	Can the decision be implemented?
Evidence and review	Tests, unresolved items and change triggers	What supports continuing operation?

Use references to controlled evidence instead of reproducing personal data in every worksheet. The governance record itself needs appropriate access because its examples and issue descriptions may reveal information about individuals.

Worked example: delivery records proposed for personalised marketing

Consider an illustrative online merchant that holds delivery addresses, order details, customer-service messages and communication preferences. The marketing team proposes an AI service that drafts tailored promotional messages. It also asks the supplier to improve future recommendations using past support conversations.

The intake separates four activities: handling a delivery enquiry, analysing service quality, selecting a marketing audience and allowing supplier model improvement. These activities should not receive one undifferentiated approval. Each needs its own purpose, data boundary, recipients and relevant legal assessment.

The initial proposal includes all support messages because the supplier says more context improves personalisation. The privacy reviewer asks what information is necessary and what may appear in the free text. A customer may have mentioned a health circumstance to explain a delivery problem. The team cannot assume that the entire conversation is suitable marketing input.

The proposed design therefore excludes support narratives from the marketing experiment. It uses a controlled, authorised field set only after the applicable conditions are resolved. Supplier model improvement remains a separate question rather than being silently bundled into service delivery. These are illustrative design decisions; the actual legal basis and conditions require review.

The merchant also separates drafting from sending. Even a permitted draft should not bypass the current audience and communication-preference check at the point of dispatch. A list exported earlier may no longer reflect a customer's current position.

Give privacy review a defined place in the approval route

Identify who prepares the processing description, who assesses privacy conditions and who owns the business decision. Privacy advice, security approval and commercial sponsorship are different responsibilities. A sponsor should not reinterpret an unresolved legal condition as a discretionary risk that can be accepted by a business manager.

The AI intake process should collect enough information for the specialist review without requiring unrestricted production data at the start. A field map, synthetic example or controlled demonstration may answer an early design question. Request identifiable records only where they are necessary and appropriately authorised.

Use explicit outcomes: proceed within a stated boundary, proceed after specified conditions, redesign, or do not proceed. Record what evidence closes each condition and who can verify closure. “Privacy approved” is too vague if it hides limits on data, recipients or supplier use.

Link the decision to the approval route and service configuration. The deployment owner needs the actual restrictions, not only a meeting minute saying the proposal was discussed. An approval that cannot be translated into settings or procedures is not ready for operation.

Assess the complete supplier arrangement

Identify the parties' roles from their actual activities and contractual arrangements. Do not assume that a supplier is merely a processor because a sales page uses that word. Understand who determines purposes, which instructions apply and whether any service feature uses information for its own purposes.

Ask for evidence covering input retention, output storage, diagnostic logs, support access, subcontractors, model improvement and deletion. A statement about one API feature may not describe the application, connector or support process purchased by the customer.

The law's controller and processor provisions make supplier selection and oversight relevant to the review. Use the current SDAIA regulatory materials with the responsible specialists to establish the applicable conditions. Then express the required commitments and verification rights in the actual arrangement.

The supplier evidence requirements should distinguish a contractual commitment, a product capability and a demonstrated configuration. All three may be useful, but they answer different questions. Record unknowns where the supplier has not provided service-specific evidence.

Trace rights and preferences through derived copies

In the merchant example, a customer changes a marketing preference after an audience file has been exported. The team needs to identify every place where that preference affects processing: source record, segmentation job, campaign queue, generated draft and dispatch system. Updating one screen may leave another copy active.

Design an event or reconciliation process that carries the relevant change to the consuming systems. Record which actions are required, which are completed and which need manual intervention. Test the dispatch boundary with a controlled account whose preference changes between draft generation and sending.

Do not make a universal promise that every historic record must immediately disappear. Retention and rights handling can involve distinct legal obligations and exceptions that specialists must assess. The governance requirement is a documented, implementable response for each relevant copy and purpose.

Generated profiles and inferred attributes need attention too. Removing a raw input does not establish that an associated prediction, saved draft or index entry has been addressed. Ask what the service stores and how the organisation can find, correct, restrict or remove relevant information where required.

Make impact assessment a decision input

Ask the responsible privacy specialist whether and how a personal-data impact assessment is required under the applicable rules. An AI impact assessment can also examine broader effects on people and operations. The two reviews may share evidence, but their purpose, scope and legal significance should remain clear.

For the marketing example, examine unwanted inference, inaccurate audience selection, inappropriate use of support information and disclosure to unintended recipients. Identify who could be affected and how the proposed controls change those outcomes. A list of generic risks is insufficient if it does not influence the design.

Use the AI impact assessment template to structure the broader analysis where useful, while preserving the privacy assessment's specific requirements. Record disagreements and uncertainty rather than forcing every issue into an aggregate score.

Keep assessment versions linked to the implemented service. A later feature that creates new profiles or adds a new recipient can change the earlier conclusion. The change owner should know which facts the assessment relied on and when a new review is required.

Treat processing location as one part of the decision

Map where input, inference, storage, backup, diagnostics and support access occur. A Saudi storage location does not establish the location of every processing or access activity. Equally, the existence of cross-border rules does not mean that every personal-data activity must always remain inside the Kingdom.

Have specialists assess the actual arrangement against the relevant transfer rules and other applicable requirements. Record the facts needed for that assessment, including recipient, country, purpose, data categories and contractual or technical conditions. Avoid choosing a location based only on a supplier's regional marketing page.

If a location or support route is unknown, retain it as an unresolved condition. A synthetic demonstration can continue under an appropriate separate scope while real personal data remains outside the unapproved route. This keeps useful design work moving without pretending that uncertainty has been resolved.

Review the map after supplier or architecture changes. An additional logging service or external support escalation can alter the processing arrangement even when the main model endpoint remains unchanged.

Test privacy controls with realistic failure cases

Use controlled tests designed around the actual decisions. Include a record with an outdated preference, a mixed support note, an unauthorised reviewer, an incorrect customer link and a failed deletion or restriction request. Define the expected result before running the test.

Inspect what reaches the model and what appears in downstream logs. A user interface that hides a field does not prove the field was excluded from processing. Likewise, a redacted answer does not establish that an unrestricted input was never sent.

Record both successful and failed tests with configuration and version information. A failed case should produce a treatment, narrower boundary or decision to defer the affected use. Repeating the test without changing the underlying cause is not evidence of improvement.

Include the support team in the exercise. Staff need a way to investigate a complaint without copying an entire customer's history into another unapproved tool. The employee generative AI policy should explain the permitted investigation route in practical terms.

Connect incidents to both operational and privacy decisions

If a generated campaign exposes another customer's information, the team must contain the service, preserve relevant evidence and assess the affected individuals and data. It should not wait for a model supplier to label the event before following the organisation's response process.

Privacy specialists determine applicable notification and rights-handling duties from the actual facts and current rules. The operational team supplies reliable timestamps, recipients, configurations and containment evidence. Avoid inserting a universal reporting deadline into every AI playbook without assessing the applicable trigger and scope.

The AI incident response plan should connect these responsibilities and maintain a decision log. An incident can require correction of data, changes to access, revised supplier instructions or withdrawal of the affected workflow. Restart needs evidence for the revised boundary.

Report the cause and the control change to the governance owner. A repaired prompt alone may not address a purpose mismatch, overbroad data feed or missing preference check.

Close a changed purpose across the copies already created

Return to the merchant considering personalised marketing from delivery records. Suppose the approved decision narrows the proposed dataset and excludes customer-service free text. Changing the next export is necessary, but the team should also identify existing test extracts, saved prompts, evaluation examples and supplier support material that contain the excluded fields. The operating task is to reconcile those copies with the revised decision.

Use a disposition record for each relevant location: what information is present, who controls it, why it is retained, what action is authorised and what evidence confirms the result. Appropriate action may differ by record and applicable obligation. A required retained record, a live processing copy and an unnecessary development extract should not be treated as if they have the same purpose or retention basis.

Have the privacy and record owners resolve any conflict before an engineer deletes material or leaves it indefinitely. If a copy must remain for a specific reason, restrict its use and access accordingly. If deletion or return is required under the applicable arrangement, obtain evidence that covers the actual location and relevant supplier responsibilities. A generic assurance about the main database may say nothing about a troubleshooting attachment.

Test the effect on the workflow. A withdrawn marketing preference should reach the authorised operational decision point, and a removed field should not reappear through an old saved extract. Record the source of the preference, the propagation result and the unresolved exception route. The test is designed to verify the agreed process; it does not imply that one technical mechanism satisfies every legal rights request.

Finally, give operations a trigger for reconsideration. A new export destination, support provider, enrichment field or use of old evaluation material can reopen the purpose and access questions. The person maintaining the pipeline needs to know which changes require review, not merely that a privacy assessment was once completed. This is how a scoped privacy decision remains meaningful after the project handover.

Hand over a privacy decision that operations can maintain

The final record should identify the activity, data boundary, legal-review outcome, parties, locations, control evidence, owner and review triggers. Keep unresolved conditions visible and specify which activities remain outside approval. A signed form is useful only if the operating team can implement its meaning.

Maintain a review path for new purposes, new inferred attributes, supplier changes, changed data subjects and broader audiences. These events can matter even when the same model name remains in use. The inventory should connect each use to its current assessment and approval.

For AI governance setup, bring the proposed workflow, data map, notices, supplier terms and existing privacy decisions. Discuss PDPL-aware AI governance setup with Open for AI to connect specialist review to intake, approval and operating evidence. The outcome should make the permitted activity and its continuing responsibilities explicit.