AI Readiness Checklist for Saudi Enterprises

An enterprise AI readiness checklist should turn broad questions into inspectable evidence and accountable next decisions. A tick beside “data available” is not enough when different subsidiaries use the same field for different meanings, access rules differ by entity, or a proposed assistant could expose another business unit's records.

This checklist is designed for Saudi enterprise teams preparing a defined AI use case across several functions or legal entities. It is an original working tool, not a regulatory certificate. Use it alongside enterprise data and AI readiness assessment to identify prerequisites for investigation or a controlled pilot, rather than declaring the whole organisation ready for every AI activity.

Complete the scope card before answering the checklist

Write the task, intended users, included entities, source systems, languages, outputs, action rights and next decision. Name the assessment cutoff and the responsible sponsor. A checklist completed without these fields produces answers that cannot be interpreted: “access approved” may mean an analyst can inspect an extract, while the proposal assumes every employee can query the live system.

For the worked example, a hypothetical business group wants an internal assistant to explain support entitlements. Users would ask whether a device, software subscription or service request falls within a named support arrangement. The assistant would cite the relevant agreement and route uncertainty to a service-desk reviewer. It would not purchase licences, amend contracts, grant access or close support cases.

The initial proposal includes three entities with different arrangements. Entity A has equipment-support agreements, Entity B has software-subscription support and Entity C handles partner-customer support under separate terms. These are not one uniform entitlement population. The checklist must reveal whether a limited pilot can include all three, only some, or none until source and permission questions are resolved.

Use evidence states rather than unchecked confidence

For every item, record verified within scope, gap observed, unknown, not assessed or not applicable with a reason. Add the evidence reference, owner, next action and acceptance condition. A yes-or-no answer is insufficient when the team has a design but no demonstration, a source owner but no approved use, or a sample that excludes the most consequential cases.

Verified does not mean perfect or permanent. It means the stated evidence supports the particular condition at the assessment cutoff. Unknown does not mean a failed test. Not applicable must follow from the agreed scope, not from a desire to avoid a difficult question. Readiness gates and scores explains how these evidence states affect the next decision.

Decide which items are mandatory for the proposed activity before reviewing the final results. Some findings may restrict a pilot, while others become improvement work. Do not turn the completed checklist into an unweighted percentage of green cells. Ten easy items cannot compensate for an unresolved permission needed by the eleventh.

The enterprise readiness checklist

Reusable checklist for a defined enterprise AI activity

Check	Evidence to inspect	Accountable role	Escalate or restrict when
Decision and permitted action	Task contract, user group and explicit excluded actions	Business sponsor	The team cannot state what the output may influence
Entity and population boundary	Included legal entities, business units and record populations	Process owner	Shared group branding is mistaken for shared rights
Source authority and meaning	Approved versions, owners, identifiers, dates and definitions	Source owner	Conflicting agreements or ambiguous entitlement terms remain
Data quality and sample basis	Defined population, selection method and defect observations	Data quality lead	A convenient export is presented as representative
Purpose and information classification	Data categories, intended use and applicable review	Responsible privacy and information owners	Required use or disclosure is unresolved
Access and identity	User-to-entity mapping and effective source restrictions	Access owner	One entity can retrieve another's restricted evidence
Processing and location map	Storage, processing, support and transfer paths	Architecture and information owners	A region label substitutes for the full data-flow analysis
Language and source quality	Arabic/English versions, extraction evidence and conflict handling	Content or policy owner	Translation changes scope, dates or exclusions
Evaluation and uncertainty	Reviewed cases, expected responses and escalation rules	Evaluation owner	Unknown entitlement is forced into a yes/no answer
Action boundary	Available tools, permissions and boundary demonstrations	Application owner	A read-only proposal can change records or permissions
Operating responsibility	Review coverage, correction route and stop responsibility	Service owner	No one accepts unresolved questions or source changes
Next decision and conditions	Evidence-linked recommendation and closure owners	Decision authority	A checklist completion is treated as launch approval

Copy the questions into the organisation's own review format and add a row for each material local requirement. The table is deliberately not exhaustive. Its purpose is to expose the evidence necessary for the next activity, including obligations specific to the entity, sector, contracts and information involved. It does not establish that every Saudi enterprise has the same obligations or data-location constraints.

Apply the checklist across entities, not only centrally

In the illustrative support-entitlement case, a central service desk can see several systems, but that does not establish a right to reuse every record in an AI assistant. A shared identity directory may identify employees without resolving which entity's agreement applies. An employee transferred between entities may retain an old account, while the relevant support entitlement depends on the device owner or contracting entity.

Filled entity-boundary matrix for the illustrative pilot

Entity	Entitlement basis	Key unresolved question	Proposed treatment
A	Named equipment and support period in an approved agreement	Can transferred devices be linked to the current responsible entity?	Include only the verified device population after boundary acceptance
B	Subscription product, plan and eligible user arrangement	Does the available export preserve the relevant support conditions?	Inspect source meaning before approving inclusion
C	Separate partner-customer support terms	Is this reuse and disclosure permitted for the proposed assistant?	Exclude until the required authority is established

This matrix avoids a common false conclusion: because Entity A has usable evidence, the group must be ready. Each included entity needs an adequate basis for the intended task. A central team may coordinate the work, but source authority and use rights remain tied to the actual records and arrangements. Enterprise readiness across a portfolio addresses shared dependencies beyond one pilot.

Walk one support question from identity to evidence

Use a masked case such as: “Can this employee request on-site support for this device today?” First identify the user's permitted context and the device's stable identifier. Then determine the responsible entity and the agreement that governs the service. Inspect the effective period, support location, service hours and exclusions relevant to the question. A product name alone may not determine entitlement.

Next check whether the assistant can retrieve only the evidence permitted for that user and task. The fact that an administrator can open an agreement is not proof that every employee should see it. If a document contains commercial terms beyond what the user needs, determine whether an approved derived view can support the answer without exposing unnecessary material. That view still needs a traceable relationship to the authoritative agreement.

Finally, define the expected answer states: supported by the named evidence, not supported by the named evidence, or unresolved because required information is missing or conflicting. Do not treat an absent device identifier as proof that support is unavailable. The useful readiness test is whether the process can preserve this distinction and route the question to an accountable reviewer.

Request a representative sample and a separate challenge set

Ask the data owner to define the eligible record population and explain how the sample was selected. Include relevant entity, agreement type, language, age and source-format differences where they affect the task. A sample consisting only of the cleanest agreements cannot establish ordinary data quality. Record exclusions and inaccessible records so the sponsor can see what the evidence does not cover.

Build a separate challenge set around known boundaries: a transferred device, an expired agreement with a later amendment, an employee associated with two entities, a missing subscription plan and conflicting Arabic and English wording. These cases test failure handling. They should not be mixed into a population defect-rate estimate as though they were randomly selected.

Use representative-sample data-quality methods for the measurement design. In the checklist, retain both the observation and its implication for the proposed pilot. A formatting defect may be repairable without changing meaning, while an unresolved agreement owner may prevent an authoritative answer. Counting both as one “data issue” hides the decision consequence.

Handle Saudi information requirements through the actual data flow

Record what information the use case handles, why it is needed, who may use it and where each processing step occurs. Employee identifiers, contractual information and confidential business terms are different categories with different questions. Do not assume that every business record is personal data, or that a confidentiality label resolves all personal-data obligations.

Use PDPL data classification to examine personal-data categories in the intended context and data residency and hosting in Saudi Arabia to map location and transfer questions. The checklist should record the responsible review and its scoped conclusion. It should not replace that review with a statement that a Saudi cloud region automatically makes the whole workflow compliant.

Include derivative material in the map where relevant: extracted text, indexed content, generated drafts, diagnostic records and support access. A read-only user experience can still create new copies or disclosures. At readiness stage, the aim is to establish the intended paths and necessary evidence, not to claim that a completed checklist is a legal opinion or a finished assurance engagement.

Check Arabic and English meaning at the decision boundary

An entitlement phrase such as “business-day support” needs a source-defined meaning. The assistant should not infer working days, service hours or date conventions solely from the language of the question. Preserve the source's effective dates and any relevant calendar convention. A fluent Arabic explanation can still be wrong if it translates a support exclusion as an inclusion.

Request paired cases with the same facts in both languages and compare the supported conclusion, cited source and uncertainty. Determine whether the documents are equally authoritative versions, an approved translation and its source, or unrelated agreements for different entities. Bilingual evidence and source conflicts explains how to distinguish a translation issue from a legitimate difference in scope.

If an Arabic scan cannot be extracted reliably, record that source-quality limitation rather than interpreting missing text as an absent contractual condition. If the language boundary remains unresolved for part of the population, a narrower pilot may be possible only if the exclusion is explicit and enforceable. Do not announce bilingual readiness from a few polished sample answers.

Write expected answers for the difficult entitlement cases

The checklist becomes more useful when abstract requirements are connected to expected responses. Prepare masked cases before evaluating an assistant, and have the appropriate agreement owner approve the answer basis. The expected response may be an explicit request for information rather than a yes or no. That is a valid result when the evidence does not support a definite entitlement conclusion.

Illustrative boundary cases and expected response principles

Case	Expected response principle	Evidence needed
Device moved from Entity A to B, ownership record unresolved	Do not select an agreement solely from the employee's current login	Accepted device/entity relationship and effective date
Subscription name present, plan missing	Request the relevant plan or direct the question to the owner	Authoritative product and support-condition mapping
Agreement appears expired, amendment referenced but unavailable	State the missing amendment and avoid a definitive denial	Approved amendment or confirmation of its status
User asks about another entity's confidential terms	Apply the approved access boundary and offer a permitted escalation route	Effective identity, access and disclosure rules

These examples are deliberately selected boundary cases. Passing them would not estimate answer accuracy across all support questions. Their purpose is to show whether the proposed process respects the distinctions that matter. A later evaluation needs its own sampling and measurement design. Record whether an observed error arose from source meaning, identity mapping, retrieval or answer generation so the next action addresses the actual cause.

Sequence the evidence requests so owners can act

Do not send every checklist question to every team at once. Begin with the scope and source inventory, because later access, sampling and language questions depend on which records are included. Resolve essential meaning questions before asking reviewers to label expected answers. Confirm the authorised evidence channel before requesting application extracts or contract examples. This sequence reduces rework without postponing a mandatory condition until after a pilot has begun.

Keep a compact request record for each unresolved item: the specific question, requested artifact, source owner, permitted handling route, dependency, acceptance owner and review date. For example, request “the effective device-to-entity mapping and its amendment rule for the included asset population,” rather than “all asset data.” The narrower request is easier to fulfil and makes it clearer whether the response actually answers the readiness question.

If the owner cannot supply the requested evidence, ask what alternative observation could establish the same condition. A preserved source snapshot may answer one version question; a witnessed demonstration may answer an access question. Neither substitutes automatically for the other. Record why the alternative is sufficient, what remains unproven and whether the pilot boundary must change. An unavailable document should lead to a reasoned evidence decision, not an automatic tick or an indefinite vague request.

Run a review meeting that produces owned decisions

Circulate the scope card and evidence references before the meeting. Assign each checklist question to a role that can explain its evidence, not merely the person who filled the spreadsheet. During the meeting, focus on unknowns, contradictions and conditions that affect the next step. Confirm whether each item is a gate, a scoped limitation or follow-up improvement work.

For every unresolved item, capture an owner, required evidence, dependency and review point. “IT to confirm” is not a useful action when the question concerns contract meaning or permission held by another entity. Name the decision required and the person able to make it. Where no owner exists, record the ownership gap as a finding rather than assigning it informally to the implementation supplier.

End with a written conclusion: proceed with the defined evidence exercise, restrict the pilot to a verified population, defer pending named prerequisites, or decline the proposed use. The conclusion should preserve the actual decision authority. The completed checklist supports the decision; it does not make the decision automatically.

Keep the checklist current without repeating the whole assessment

Assign a custodian for the accepted checklist itself. That person keeps evidence references usable, records changes raised by owners and ensures that unresolved conditions reach the next decision-maker. This administrative responsibility does not give the custodian authority to approve source use or change agreements; it prevents the review record from becoming disconnected from the people who hold those responsibilities.

Attach change triggers to material findings. New entities, changed agreements, different users, additional actions, new processing paths or amended source permissions can invalidate part of the earlier conclusion. Reassess the affected evidence and connected dependencies. Do not assume that a minor interface change is harmless if it exposes a previously excluded source or action.

Preserve the accepted checklist version, supporting evidence and unresolved conditions. A later reviewer should be able to distinguish an old gap from a newly introduced one. The NIST AI Risk Management Framework provides voluntary context for managing AI risks; this checklist remains an original practical tool whose suitability depends on the specific decision.

For a readiness checklist discussion, prepare a masked scope card, entity/source matrix and a few ordinary and difficult support questions. The most useful starting point is the evidence that different owners currently interpret differently. Resolving those boundaries gives the organisation a firmer basis for a controlled next step than collecting a large number of unexplained ticks.