Bring the decision, authority and usable evidence
How to Prepare for AI Governance Setup
Prepare a governance setup engagement with a clear decision brief, bounded use list, authority map, evidence access and realistic acceptance expectations.
Prepare for AI governance setup by bringing a clear account of the decisions your organisation needs to make, the uses already in operation and the authority and evidence available today. You do not need to solve the entire governance programme before the engagement. You do need to make its starting conditions visible so the work can be scoped and accepted honestly.
The most useful preparation pack connects business activities, responsible people, existing processes and known gaps. It distinguishes facts from assumptions and makes access constraints explicit. Sending a large collection of policies without explaining how requests currently move can consume time while leaving the central operating questions unanswered.
This guide is for Saudi sponsors, governance coordinators and functional owners preparing a governance setup discussion. It includes a practical pack structure, a law-practice example and a first-workshop design that protects the distinction between preparation, assessment and implementation.
Write the decisions that triggered the engagement
Begin with a few concrete problems. Perhaps employees use assistants without a clear permission boundary, procurement cannot decide which supplier evidence is necessary, or an approval condition is lost when a system goes live. Describe the last occurrence and the consequence. “We need an AI policy” may be part of the answer, but it is not yet a full description of the operating need.
For each problem, identify the decision that should become possible after setup. A sponsor might need a proportionate route for employee tools, a local owner for embedded features or a reliable way to reopen review after an agent gains action authority. This gives the supplier something more precise to design than a generic framework.
Separate desired outcomes from proposed solutions. The need may be faster, well-supported decisions; a new committee is only one possible design choice. Record constraints such as existing delegations or a requirement to use the current procurement system, while leaving routine implementation choices open for evidence-based discussion.
State what the engagement is not yet authorised to decide. A programme can design a route for risk acceptance without itself accepting the organisation's risks. It can prepare a policy without adopting it on behalf of management. Clarifying these boundaries early prevents a later disagreement about who was expected to approve the finished arrangement.
Prepare a minimum useful evidence pack
| Item | What to bring | Why it matters |
|---|---|---|
| Decision problems | Recent cases with the unresolved question and consequence | Defines the operating outcome to improve |
| Initial use list | Known activities, tools, owners and current states | Establishes a bounded starting portfolio |
| Authority map | Relevant delegations and reserved decisions | Prevents design from assigning powers that do not exist |
| Existing processes | Procurement, security, privacy, change and incident routes actually used | Shows where AI-specific work should connect |
| Supplier evidence | Available contracts, configuration facts and unanswered questions | Separates established facts from commercial assumptions |
| Operating examples | Prepared records or controlled walkthroughs showing difficult cases | Supports a realistic rehearsal without indiscriminate data sharing |
| Delivery constraints | People, access, languages, systems and approval availability | Makes the schedule and acceptance conditions credible |
A partial pack can be a useful start if its limits are labelled. Do not fill unknown fields with guesses to make the document look complete. Mark which facts need discovery, who may know them and what decision depends on the answer. This allows the engagement to include the necessary investigation rather than treating it as an unexpected failure later.
Use the inventory guide for a fuller record design. During preparation, focus on identifying meaningful activities and owners. A perfect asset register is not a prerequisite for discussing setup, but an unexplained list of software logos gives little basis for estimating the work.
Choose representative cases rather than the easiest demonstrations
Select cases that expose different decision boundaries. An ordinary approved use shows the existing route; a stalled request shows missing evidence or authority; a changed use shows how permissions are maintained. Include a purchased or embedded feature if those are part of the intended scope.
Explain why each case was selected. A deliberately difficult case is useful for design, but it does not estimate how common the issue is across the organisation. A clean demonstration may show one capability while concealing the conditions that make ordinary work harder. The engagement should understand the evidence purpose before drawing conclusions.
Bring the actual question and available evidence, not a polished narrative that resolves the problem in advance. If different teams disagree about what happened, preserve their accounts and identify records that may settle the factual issue. The setup team can then design around a real boundary rather than an agreed story that omits the awkward part.
Where a live demonstration would create an external action or expose restricted material, use a controlled method appropriate to the question. Demonstrating the route does not require sending a real customer message or executing a financial transaction. Agree the method and authority before the workshop.
Worked example: a law practice prepares document-assistant cases
Consider a fictional law practice exploring an internal assistant for finding approved document-index entries. Partners want a governance route for new uses, but the initial workshop does not need unrestricted client matter files. The preparation lead provides a list of proposed activities, role descriptions, existing access rules and synthetic index examples.
One example shows a user requesting an entry from a matter they cannot access. Another shows an outdated index item whose status is unclear. A third shows a proposal to extend the assistant from locating entries to summarising underlying documents. These cases reveal access, source ownership and scope-change decisions without requiring disclosure of actual client content.
The lead also records what the examples cannot establish. Synthetic records can support a workflow rehearsal, but they do not prove the production access configuration or the quality of real document indexing. If those claims become part of the scope, the engagement needs a separately agreed controlled evidence method.
A prepared real extract is not automatically anonymous merely because names are removed. Matter context, identifiers or distinctive facts may still reveal information. The practice's authorised specialists determine the preparation and access arrangement. The project should preserve the difference between synthetic material, restricted real evidence and an assertion about anonymisation.
The first workshop can therefore establish the decisions, evidence gaps and review route while leaving sensitive content within its appropriate boundary. Later work can obtain the specific evidence needed for implementation or acceptance through an authorised method. Preparation has reduced unnecessary exposure without pretending to prove facts it has not tested.
Bring the existing authority, including its uncertainties
Identify who can adopt policy, approve procurement, accept relevant risks, authorise business actions and pause operation. Include the delegations and reserved matters that affect the proposed scope. If the organisation cannot yet answer a question, name it as a decision for the appropriate authority instead of assigning it informally to the project team.
Map the difference between advice and permission. A security specialist may advise on a control; an operational owner may confirm the workflow; a budget holder may approve expenditure. None of those decisions automatically supplies every other approval. The decision-rights guide provides a more detailed method.
Check availability as well as role names. A workshop that depends on one director's decision needs that person's participation or an agreed decision route. A schedule that assumes immediate approval from unavailable specialists will be unreliable even if the supplier's own delivery capacity is adequate.
Include absence cover and conflict handling. The person sponsoring a use may also own a supplier relationship or a disputed prior decision. Preparation should make that context visible so the governance design can establish an appropriate challenge and escalation route without surprising the participants later.
Collect existing rules with their status and applicability
Provide current policies, procedures and relevant contract requirements, together with their owner, version, approval status and actual use. Distinguish an adopted policy from a consultant draft or a document that has been superseded. The setup team should not treat every file in a shared folder as equally authoritative.
Use current primary references for the requirements your specialists need to assess. SDAIA's regulations and policies hub is an official starting point. Record the relevant document and version and obtain an applicability conclusion for the organisation and use. The existence of a guidance document does not establish that every provision is a binding requirement for every business.
Identify working processes worth retaining. A procurement review may already obtain useful supplier information; an incident process may already have appropriate escalation. Bring examples showing how these work. The aim is to connect missing AI-specific decisions, not to replace functioning arrangements simply because a new programme has begun.
Record conflicts explicitly. If one policy allows a tool while another restricts the information it needs, the setup team needs to know. The policy-framework guide addresses hierarchy and maintenance. Preparation should reveal the contradiction and its owner rather than silently choosing the more convenient document.
Agree access and evidence handling before requesting files
List the evidence questions and the minimum access each requires. A process interview, a screen walkthrough, a prepared extract and a controlled live inspection answer different questions. Choose the method based on the intended claim and the organisation's handling requirements, not on the convenience of uploading everything to one project folder.
Define participants, permitted copies, retention, access removal and how findings are recorded without unnecessary source content. Include supplier portals or external systems that may require separate permission. A promised evidence source is not available until the authorised reviewer can actually reach it through the agreed route.
Preserve a simple access dependency list. For each missing item, state the owner, expected resolution and work affected. This makes it possible to proceed with independent tasks while deferring the claims that need unavailable evidence. It also helps the sponsor distinguish delivery delay from a change in the scope of what can be concluded.
If an access constraint cannot be resolved, agree whether the engagement narrows, uses a valid alternative or reports a limitation. Do not conceal the constraint and expect the final report to make an unsupported assurance claim. The supplier evidence requirements can help when the missing evidence sits with a vendor.
Design the first workshop around an actual decision
Ask the sponsor to describe a selected activity and the decision they need. Let the operating owner explain the workflow, the technical owner explain relevant capabilities and specialists identify the questions within their remit. Keep the proposal version visible so participants are discussing the same activity.
Work through a normal path and one difficult variation. In the law-practice example, locating an authorised index entry is the normal path; an inaccessible matter or a proposed document-summary expansion creates the variation. Record who decides, what evidence is needed and what happens if it remains missing.
End with decisions and actions, not a general agreement that governance is important. Identify the initial scope, existing arrangements to preserve, unresolved authority, evidence work and a proposed acceptance exercise. The committee setup guide may help where a forum is needed, but the workshop should not assume that a new committee is the answer.
Distinguish workshop conclusions from adopted policy. A participant may agree that a design looks workable without having authority to approve it. The output should identify the next formal decision and its owner, rather than treating attendance as consent to every proposal discussed.
Prepare a workshop packet that can survive missing evidence
For each selected case, prepare a short packet with the business purpose, the proposed activity, the affected people, the relevant source or supplier and the decision sought. Add links to available evidence and mark what is missing. The packet should allow participants to discuss the actual boundary without requiring a large collection of unrelated files.
In the law-practice example, the unauthorised-matter case should identify the expected access boundary and how the synthetic exercise represents it. The old-index case should state which version is intentionally stale and what result the participant is expected to recognise. The proposed move from finding documents to summarising them should be presented as a separate scope decision with its own questions.
Give each uncertainty a classification that helps the workshop proceed: a factual question awaiting evidence, an authority question awaiting a decision, or a design question requiring options. If these are mixed together in one “open issues” list, participants may spend time debating facts that an administrator could verify or ask an administrator to resolve a business authority question.
Assign a facilitator to keep the discussion tied to the decision. The business owner explains the intended use and consequence; the relevant specialist identifies evidence and applicability issues; the authorised participant resolves matters within their remit. If the necessary authority is absent, record the options and referral rather than interpreting attendance by another senior person as implied delegation.
Agree how the workshop handles unexpected sensitive material. Participants should know where evidence can be viewed, whether it may be copied and who can authorise additional access. A useful discussion can pause the affected inspection and continue with other scope questions. The pressure to finish the meeting should not determine how a confidential client record is shared.
End by checking the decisions with their owners. Distinguish a confirmed scope boundary, an assumption used for planning and a decision awaiting another party. Record the next evidence item and its purpose. The sponsor should leave able to understand which work can start, which depends on an unresolved input and what acceptance evidence the eventual engagement must produce.
After the workshop, send the controlled record through the agreed internal review route and reconcile corrections before using it as the basis for a proposal. If a participant changes a material assumption, show its effect on the scope. This preparation discipline reduces the chance that a later commercial document quietly embeds a misunderstanding from the initial discussion.
Make scope, cost and acceptance assumptions reviewable
State the intended entities, use categories, languages, artefacts, configuration work, training and rehearsals. Identify client contributions and exclusions. A proposal can then explain what it will deliver and how the result will be accepted. The pricing guide shows why these scope units matter more than a generic fee per policy.
Use the setup checklist to define evidence states and handover conditions. If live operating evidence is required, allow for the operating period and access. If the first phase covers design and rehearsal only, make that clear. Neither party benefits from discovering at acceptance that they meant different things by “implemented”.
Prepare a governance setup discussion with a clear starting pack for Open for AI. Bring the decisions, people and evidence you have, and label what remains unknown. Good preparation does not mean arriving with every answer; it means making the next work specific enough to price, perform and judge.
FAQ
Your questions, answered.
What should we bring to the first governance setup discussion?
Bring the decisions that prompted the work, a bounded list of known uses, relevant owners and delegations, existing review routes and a few representative cases. Include available supplier evidence and access constraints. Label unknowns rather than filling them with assumptions. The aim is to make scope and acceptance reviewable, not to complete the entire governance programme before a useful discussion can begin.
Do we need a complete AI inventory before commissioning setup?
No, but the starting list should identify meaningful activities and known owners rather than only product names. State its coverage and discovery limits. The engagement can include further inventory work where needed. A partial, honest register is more useful than an apparently complete list that omits embedded features, confuses subscriptions with permissions or hides uncertainty about who owns an activity.
Must a law practice share client matter files in the first workshop?
Not automatically. The evidence method should follow the question. Synthetic index cases and role maps can support early workflow design, while production access or indexing claims may need separately authorised evidence. The practice determines appropriate preparation and handling through its responsible specialists. Removing names alone should not be treated as proof that a real extract is anonymous or suitable for unrestricted sharing.
Which cases are most useful for governance preparation?
Choose cases that reveal different boundaries: an ordinary permitted use, a stalled request and a changed activity, with purchased or embedded features where relevant. Explain why each was selected and what its evidence can show. A deliberately difficult case supports diagnosis but does not estimate issue prevalence. Preserve factual disagreements and identify the records that could resolve them instead of preparing only a polished success demonstration.
What if we cannot identify who may accept a particular AI risk?
Record the authority question, affected activity and consequence as an unresolved decision for the appropriate organisational role. Do not assign it informally to the adviser or assume that a budget approval supplies risk authority. The setup can help design a valid route, but the organisation must establish or confirm the relevant delegation. Make the dependency visible in scope, schedule and acceptance.
How should unavailable supplier evidence affect the preparation pack?
List the missing evidence, the claim it affects, the supplier or internal owner and the expected access route. Consider a valid alternative, narrower scope or explicit limitation if access cannot be obtained. Do not conceal the gap or treat a promised document as inspected evidence. Independent design tasks may proceed while the affected conclusion remains deferred and visible to the sponsor.
Does agreement in a governance workshop adopt a policy?
Not necessarily. Participants may support a design without having authority to adopt it. Record the workshop outcome, unresolved questions and the next formal decision with its owner. Distinguish design agreement from policy adoption, risk acceptance and permission to operate. This prevents attendance or informal consensus from being used later as evidence of an approval that the organisation never actually gave.
How do preparation choices affect governance setup pricing?
Entities, use categories, languages, configuration work, training, rehearsals and access dependencies determine effort. A clear pack shows what can be reused and what requires discovery. State client contributions and acceptance expectations, especially whether live operating evidence is required. This supports a concrete proposal and avoids a generic price that assumes unresolved work, unavailable participants or evidence the client cannot provide.