AI Governance for Government

AI governance for a Saudi government entity should preserve lawful decision authority, reliable service delivery and an understandable route for people to correct information or challenge an outcome through the applicable process. An AI system can assist officials without acquiring the authority of the public body or silently changing the rules of a service.

This guide is for public-service owners, AI and data offices, legal teams, technology leaders and assurance functions. It uses a permit-application completeness assistant to show how governance can be implemented at the point where an automated observation affects a person's application. The operating design is illustrative and must be adapted to the entity's mandate and actual procedures.

Start with the service mandate and authorised decision

Identify the public service, its governing requirements and the official empowered to make each decision. Distinguish receiving an application, checking documents, requesting information, determining eligibility and issuing a final decision. These actions may have different procedural consequences.

Write the AI role in that sequence. A tool that flags an unreadable attachment should not automatically reject the application or reset its submission date. The responsible team needs to determine the authorised handling of that condition under the actual service rules.

Saudi Arabia's national AI information page identifies government-focused generative-AI guidance and an adoption framework. Treat these as relevant references for the applicability review, alongside binding requirements and the entity's own authority. The official national risk-framework announcement also describes a guiding reference, not a substitute for a service-specific legal analysis.

The AI approval route should connect these decisions to named owners. A technical team can demonstrate capability, but the service owner and relevant specialists must determine whether the proposed role is permissible and appropriate.

Define the citizen-facing consequence of every output

For each AI output, ask what changes for the applicant. A flag may trigger another document request, delay review or direct the case to a different officer. Even if the output is labelled advisory, its position in the workflow can make it consequential.

Document what staff see and what they can override. If a system hides applications with a low completeness score, the officer may never have an opportunity to correct the error. Meaningful review requires access to the underlying submission and a practical route to disagree.

Separate a missing document from a document the system failed to read. A scanned form with an unfamiliar layout may contain the required information. Treating extraction failure as applicant non-compliance transfers a technical limitation to the person seeking the service.

Use AI impact assessment to examine those effects, including accessibility, language and the burden of repeated requests. The assessment should change the process, not only record a general concern about fairness.

Worked example: permit-document completeness assistance

Consider an illustrative public entity testing an assistant that organises permit attachments and drafts a proposed request for missing information. An authorised case officer reviews the evidence and decides the next procedural step. The assistant does not determine eligibility or issue the permit.

The team constructs 28 prepared challenge cases: nine complete submissions, seven with a genuinely missing page, six using a valid Arabic form variation, four with duplicate attachments and two withdrawn applications. The categories are deliberately separate. They are a diagnostic design, not a claim about actual application volumes.

The expected handling is different for each group. Complete cases should not receive invented requirements. Missing-page cases should identify the specific evidence gap. Valid form variations should be assessed against the substantive requirement rather than rejected for visual difference. Duplicates should not count as additional evidence, and withdrawn cases should follow their actual status.

Illustrative controls for a completeness assistant

Observed condition	Proposed system response	Authority retained
Unreadable attachment	Mark extraction uncertainty and preserve the original	Case officer determines the permitted next step
Possible missing item	Show the requirement and evidence searched	Officer verifies whether information is actually absent
Valid alternative form	Assess relevant content without assuming a template mismatch is failure	Service owner defines acceptable evidence
Final application outcome	Outside the assistant's scope	Authorised public decision process

The pilot decision should specify whether the proposed requests are useful and sufficiently supported, and whether staff can correct errors before they affect applicants. It should not infer wider readiness for automated permit decisions.

Maintain authoritative requirements and versions

Assign an owner to the service requirements the assistant uses. Record the version, effective date and affected application types. A public guidance update, internal procedural instruction and draft policy proposal are different sources and should not be mixed indiscriminately.

Keep the relevant date of an application visible. A change in requirements may need an authorised transition rule. The AI system should not decide retrospectively that an earlier submission failed a requirement that was not applicable to it.

When two sources conflict, route the conflict to the responsible policy or legal owner. The assistant should identify the uncertainty rather than select whichever paragraph seems more confident or recent. Source recency alone may not establish authority.

Link the source map to change triggers. When a requirement changes, identify affected prompts, retrieval collections, staff instructions and pending drafts. A website update without a corresponding service change can leave the assistant applying stale rules.

Make Arabic handling a substantive service test

Test formal Arabic, common document variants, mixed-language attachments and names or identifiers that appear differently across records. The purpose is to establish whether the system preserves the evidence needed for the service, not merely whether it produces fluent Arabic.

Review how it handles scanned stamps, tables and supporting notes. A missing extraction result should remain a system uncertainty until an authorised process determines the document's content. Staff need the original attachment available for review.

Assess the wording of proposed requests. They should identify the specific missing or unclear item and the relevant service requirement without inventing extra conditions. A generic request to resubmit everything can impose unnecessary burden and conceal the true technical issue.

Use accessible communication channels consistent with the entity's approved service design. The governance team should examine whether applicants who cannot use a particular digital format still have a workable route through the service.

Design correction and challenge into the workflow

Identify how an applicant can provide a correction, ask for clarification or use the applicable review or complaint route. The AI-supported process should connect to those existing mechanisms. Do not invent a new statutory appeal right or replace the actual authorised process with a chatbot conversation.

Preserve enough information to explain the procedural action: requirement version, submitted evidence, system observation, officer review and final communication. The explanation should distinguish an AI suggestion from the official decision.

When a person supplies the requested item, reconcile it with the existing application rather than creating an unrelated record by default. A correction route that loses context can lead to repeated requests and inconsistent treatment.

Review overturned or corrected suggestions to improve the service. Do not treat applicant disagreement as evidence of misuse. It may reveal a source, language, accessibility or process defect that the initial evaluation missed.

Protect public and personal information through the full flow

Determine the applicable data-management, classification, privacy and cybersecurity requirements for the entity and activity. Map the submission, extracted text, model request, draft, logs and support route. A protected original repository does not automatically protect every derived copy.

Give staff and service identities only the access required for their roles. A completeness assistant should not retrieve unrelated applications because they happen to share a name or address. Test cross-case access and identity mismatches with controlled evidence.

The PDPL governance workflow supports the personal-data portion of the review. Other public-sector information requirements can apply separately. Preserve those distinctions in the obligation register rather than using one broad confidentiality label.

Use synthetic or appropriately controlled material for demonstrations and supplier evaluation. Avoid making a convenient shared test folder the uncontrolled destination for real applicant records.

Procure evidence and continuing responsibility

Ask the supplier to demonstrate the intended workflow with difficult cases, including valid alternative forms and unreadable attachments. A generic document-extraction score does not establish that the service applies the entity's requirements correctly.

Require clarity about configuration, source updates, support access, logging, incident assistance and changes to model behaviour. Determine which commitments belong in the contract and which need local operational tests.

The governance vendor assessment can test whether a partner can hand over a maintainable process and evidence structure. The entity should retain an understanding of its own decision rules and the ability to operate the service when personnel or suppliers change.

Trusted Data's public-sector AI overview offers wider implementation context. Its sector discussion should not be read as a statement of the Saudi entity's legal requirements or as approval for a particular public-service decision.

Manage a requirement update across pending applications

Consider a change to the permit service's required supporting document. The policy owner confirms the new requirement and its effective context, but some applications are already submitted, some have draft information requests and others are waiting for officer review. The implementation task is to apply the authorised transition decision to each relevant state, not simply replace the document in the assistant's source collection.

Create a transition record that identifies the old and new source, affected application types, applicable dates or conditions, owner of interpretation and required operational changes. Where treatment of pending applications is unclear, escalate it to the authorised owner. The assistant should not invent a transitional entitlement or apply the newest rule retrospectively because it is the first result returned by search.

Separate three practical activities: changing the source, updating the workflow and reconciling existing work. A source update may change future drafts while leaving already generated requests in a queue. A workflow update may label new cases correctly while preserving an incorrect status on older cases. The service owner should identify both populations and decide the appropriate review.

Use a controlled sample of pending cases to verify the transition, including a valid alternative Arabic form and a previously unreadable scan. Ask the officer to identify the governing requirement and the applicant's next permitted step. If two officers following the available instructions reach conflicting procedural actions, resolve the instructions or authority question before wider use.

Preserve the reasoning for an earlier decision even when the rule changes. The official record should show which source and authorised interpretation applied at the time. This makes later explanation possible without pretending that the new wording had always governed the service. Retain records under the entity's applicable arrangements rather than keeping informal duplicates in the project team's shared folder.

Give correction work a complete operating closure

Suppose an Arabic form variation was wrongly treated as missing information and the officer sent a request. Correcting the form parser is only one part of closure. Identify the affected application, the message sent, the status change and any related pending request. The authorised service process determines what must be corrected or communicated and whether other applications require review.

Track the work through separate states: issue identified, procedural effect assessed, correction authorised, correction applied and outcome checked. The responsible officer should be able to see which state is current and who owns the next action. A technical ticket marked resolved should not obscure an applicant still waiting on a request that should no longer apply.

Test the return path when the applicant has already supplied a replacement attachment. Keep both the original procedural history and the corrected handling clear, without forcing the person to start a new application merely because the system lost context. The actual service rules determine the permitted administrative treatment; the governance design ensures that the question reaches the right authority.

Review what the event teaches about the operating boundary. It may reveal that alternative forms were missing from evaluation, that staff could not inspect the original, or that a source update lacked a transition owner. Choose corrective work that addresses the cause. A generic instruction to check all AI results more carefully does not by itself repair those distinct problems.

Before closing the event, ask a staff member outside the project to reconstruct one corrected case from the authorised record. They should identify the original request, the basis for correction, the approving officer and the current status. If the answer still depends on an informal explanation, improve the record before treating the case as fully resolved.

Measure applicant burden as well as processing speed

Track unnecessary information requests, repeated submissions, correction effort and cases delayed by system uncertainty. Separate those measures from total throughput. Faster initial screening can still make the overall service slower for applicants who receive avoidable requests.

Compare meaningful case types and language patterns within the approved evaluation design. Preserve the denominator: the number of applications reviewed, drafts generated, suggestions rejected and cases requiring manual handling answer different questions.

Inspect staff workload after the pilot. If officers must spend substantial time explaining model errors, the apparent saving in document sorting may not be realised. Include the burden of maintaining sources and resolving exceptions in the operational assessment.

Use governance metrics to show whether conditions are being met and who must act. Do not present a small prepared test set as evidence of nationwide service performance.

Plan restriction, continuity and accountable restart

Define events that restrict the assistant: applying an incorrect requirement version, cross-applicant disclosure, repeated unsupported requests or inability to preserve the official record. Identify who can act immediately and how the service owner is informed.

Maintain the established manual route for receiving and reviewing applications. A model outage should not silently erase submitted evidence or change an application's status. Staff need clear instructions for pending drafts and incomplete processing.

The incident response plan should connect service, privacy, security and legal owners. Preserve a common timeline and distinguish technical restoration from authorisation to resume the affected public-facing function.

Restart requires evidence that the relevant defect is treated and the approved boundaries remain effective. Test the cases that exposed the issue and check whether the cause affects other application types or requirements.

Prepare an accountable public-sector governance handover

Deliver the service authority map, inventory entry, requirements-source record, evaluation findings, supplier commitments, access controls, correction routes and change procedure. Each item needs an owner and a usable location, not merely a place in a presentation.

Run a scenario in which an Arabic form variation is wrongly flagged after a policy update. Ask the team to identify who verifies the requirement, corrects the applicant communication, assesses other affected cases and authorises the revised configuration. Resolve the gaps before wider rollout.

For AI governance setup, bring the public-service workflow, delegations and current guidance. Discuss AI governance setup for government services with Open for AI to build the operating decisions and evidence around the entity's mandate. The objective is a service whose AI assistance remains traceable, correctable and accountable to the authorised public process.