AI Audit Checklist

An AI audit checklist is useful when each item leads to an evidence-based judgement. It becomes misleading when a policy document, a successful demonstration and an operating control all receive the same tick. This checklist is designed to help an assessor record the question, procedure, evidence and resulting limitation. It is an original practical starting point that must be adapted to the system and engagement, not a universal compliance checklist or certification test.

The intended users are internal audit teams, risk reviewers and technology owners working through a defined assessment. A hypothetical restaurant allergen-information assistant illustrates why checklist results need interpretation. The assistant communicates information from an approved menu and ingredient source; the example does not establish that any meal is safe for a particular person or replace qualified food-safety responsibilities.

Use the checklist as a record of work, not a readiness score

Before testing, agree the system boundary, decision, period, criteria and authorised methods. An item that is irrelevant to the scoped system can be marked not applicable with a reason. An item that is relevant but untested must remain untested. An unavailable evidence item is not a pass. These distinctions matter because a completed-looking checklist can otherwise conceal exactly the questions management needs answered.

The US GAO AI Accountability Framework organises accountability considerations around governance, data, performance and monitoring. It is a primary reference for examining AI in context, not a Saudi legal requirement. The checklist below is independently written and uses its own questions, evidence prompts and decision logic; it does not reproduce GAO's procedures.

Assign a procedure reference and evidence reference to every conclusion. A statement such as “owner confirmed” identifies an assertion, not necessarily proof of operation. Record whether the assessor inspected design, observed a demonstration, examined operational records or performed an authorised test. Use working papers for the detailed reasoning so the checklist can remain concise without becoming unsupported.

Part one: confirm the boundary and authority

Original checklist: scope, criteria and accountability

Question	Procedure and evidence	Decision if evidence is insufficient
Is the assessed use case specific?	Trace a real or masked task through inputs, model response, human handling and downstream action; record versions and environments.	Narrow the conclusion until the workflow and relevant interfaces are identified.
Are criteria agreed and applicable?	Inspect the requirement sources, owner approval and applicability record; separate internal criteria from external obligations.	Resolve the criterion rather than inventing a pass threshold during testing.
Is an accountable process owner identified?	Confirm authority over the business outcome and response to findings, not merely ownership of an API subscription.	Escalate the accountability gap and identify who can make the required decision.
Are testing and evidence access authorised?	Inspect permitted targets, accounts, data, actions, handling arrangements and stop conditions.	Do not perform the unauthorised procedure; record its effect on coverage.
Are third-party boundaries understood?	Map supplier-controlled components and assess the relevance of available supplier evidence to the customer's configuration.	Use alternative evidence where suitable and disclose the remaining boundary.

In the restaurant example, “allergen assistant” is not a sufficient boundary. Does the tool only locate approved information, generate free-text answers, recommend alternatives or initiate an order? Does it distinguish menu versions and locations? Those questions determine the controls to examine. If ordering is excluded, state that exclusion without implying that order handling is safe or assessed.

Part two: examine sources and meaning

Original checklist: source integrity and output meaning

Question	Procedure and evidence	Decision if evidence is insufficient
Can the authoritative source be identified?	Inspect source ownership, approval, version and effective context for selected outputs.	Do not treat a plausible answer as supported information when its authority is unknown.
Can the input-to-output path be reconstructed?	Compare source content, extracted input, retrieved passages and generated or accepted output where relevant.	Record which part of the pathway cannot be examined and limit causal claims.
Are unsupported statements identified?	Use an agreed rubric and qualified source comparison, including statements that sound reassuring but lack source support.	Record exceptions or unresolved judgements; do not rely only on the model's self-assessment.
Are unknown or conflicting sources handled?	Test missing fields, inconsistent revisions and ambiguous wording with authorised fixtures.	Require an explicit decision about referral or restriction where the system fills gaps without support.
Are Arabic and mixed-language meanings assessed?	Use competent reviewers and relevant cases, preserving negation, qualifiers and source references.	Disclose untested language coverage or unresolved interpretation rather than assuming equivalence.
Are source changes reflected appropriately?	Examine revision propagation, stale content handling and the basis on which the system identifies the applicable version.	Separate current-source results from historical outputs and investigate stale information paths.

For the hypothetical assistant, the relevant distinction is between repeating approved information and inferring that an item is suitable for an individual. A source that does not contain an ingredient detail does not support a confident absence claim. The checklist should examine how the system represents uncertainty and routes the enquiry to an authorised person. It should not invent domain assurances merely to produce a complete answer.

Part three: test permissions, human decisions and actions

Original checklist: control boundaries in operation

Question	Procedure and evidence	Decision if evidence is insufficient
Is access limited to authorised information?	Inspect roles and perform bounded tests using approved accounts and synthetic or masked data.	Escalate a demonstrated boundary failure; distinguish it from an untested permission assumption.
Are consequential actions separately authorised?	Trace proposed, approved, attempted and confirmed actions; inspect enforcement at the execution boundary.	Do not treat a prompt instruction or approval screen as proof of enforced authorisation.
Can human reviewers make a meaningful decision?	Examine source visibility, competence, time, authority and selected intervention records.	Record whether review is merely prescribed or evidenced in operation.
Are exceptions routed and resolved?	Follow selected referrals into the responsible queue and inspect disposition, including pending cases.	A generated escalation message is not proof that a person received or resolved the case.
Are adverse tests bounded and authorised?	Inspect rules of engagement, suitable environments and stop procedures before testing difficult inputs.	Do not expand into real external actions or unauthorised data access.

The restaurant assistant may display “ask a staff member” while the operating process provides no visible handoff or staff access to the original question. A checklist tick for an escalation phrase would miss that gap. Examine whether the referral is meaningful within the agreed scope. At the same time, a single unobserved resolution does not prove that every referral fails; distinguish evidence gaps from confirmed operating exceptions.

Part four: evaluate the evaluation and follow-up

Original checklist: evaluation integrity, change and remediation

Question	Procedure and evidence	Decision if evidence is insufficient
Does selection support the claimed result?	Review population, sampling unit, selection method, exclusions and denominators.	Limit the inference; targeted challenge results should not become population accuracy claims.
Are expected outcomes defensible?	Inspect the rubric, qualified adjudication, disagreement handling and automated-judge validation where used.	Resolve unreliable labels before relying on the reported score.
Are important contexts covered?	Map objectives to tested versions, languages, channels and scenarios, with reasons for omissions.	Record untested and partially tested areas explicitly.
Are material changes assessed?	Examine change identifiers, approval, relevant testing and deployment scope.	A successful test on an earlier configuration should not silently cover a replacement.
Are monitoring signals actionable?	Trace selected alerts into investigation and decision records, checking what the signal actually measures.	Do not equate dashboard availability with effective response.
Are findings closed with suitable evidence?	Inspect the response, implementation evidence, retest result and authorised disposition.	Keep planned, deployed, verified and risk-accepted states distinct.

Use sampling guidance and evaluation integrity when the checklist reaches statistical or judgement questions. A percentage without a defined population and reliable labels cannot repair an incomplete assessment. Use the coverage record to reconcile what was actually examined against the agreed objectives.

Record outcomes with a controlled vocabulary

Use outcome labels with explicit meanings. “Evidence supports the criterion” means the defined procedure provides adequate support within its scope. “Exception observed” means a supported departure was found. “Inconclusive” means the procedure or evidence cannot support a judgement. “Not tested” identifies work not performed. “Not applicable” needs a reason tied to the scope. These labels should not be converted automatically into a single compliance percentage.

Record the evidence reference, assessor, date, affected version and limitation beside the outcome. A later reviewer should understand why the label was selected. Where a checklist item includes several distinct controls, split the record or state which part is supported. A single positive label can otherwise hide that design was reviewed while operating effectiveness was not.

Keep the checklist linked to the findings process. Not every inconclusive item is a confirmed defect, and several exceptions may support one finding. Decide whether the result requires more evidence, a formal finding, a scope change or a management decision. The checklist documents the procedure outcome; the finding requires an assessed relationship between criterion, condition and consequence.

Worked checklist row: an unsupported reassurance

Suppose the hypothetical assistant responds to a customer enquiry with a reassuring statement not supported by the approved ingredient source. The assessor preserves the source version, submitted question, retrieved material and response. A qualified source reviewer confirms that the statement goes beyond the available information. The checklist row records an observed exception against the agreed information-support criterion.

The next step is to examine the pathway and consequence within scope. Was the answer displayed to a real customer or produced in a controlled test? Was a qualification or referral visible? Could a staff reviewer intervene before use? The report should state what the evidence establishes. It should not invent an injury or claim that every menu answer is wrong. It can still require prompt management attention to a credible consequential information gap.

Filled checklist record for the hypothetical information-support test

Field	Illustrative entry
Objective	Determine whether the assistant stays within approved source information for the selected enquiry.
Procedure	Compare the preserved response with the applicable source and assess qualifiers through competent review.
Outcome	Exception observed: a reassurance exceeded the source support.
Scope	Controlled test of the identified version; no claim about a real customer's outcome.
Follow-up	Assess the mechanism, referral behaviour and need for an authorised restriction.
Limitation	The selected case does not estimate the frequency of unsupported statements in ordinary use.

Define when to stop or escalate

Testing should stop when the agreed rules require it, such as an unexpected consequential action, exposure of information outside the authorised boundary or an unsafe interaction with a live process. Preserve the relevant evidence without expanding the exposure, notify the responsible contact and follow the authorised response arrangement. Completion of every checklist row is not more important than controlling an unexpected event.

A lack of access can also stop a procedure without stopping the entire engagement. Record the blocked question, alternative evidence considered and effect on the conclusion. Do not improvise access around a restriction or replace a difficult control test with an unrelated easy check. The scope owner can decide whether to change the engagement, defer a conclusion or accept a clearly described limitation.

Escalation should be proportionate to the supported concern. A formatting inconsistency and a credible consequential boundary failure should not receive the same treatment merely because both are exceptions. Conversely, uncertainty does not automatically justify inaction. Record the evidence, plausible pathway and decision needed, then use the agreed management process.

Adapt the checklist without losing its discipline

Remove irrelevant items with a documented reason and add procedures specific to the use case. A predictive model needs different performance questions from a conversational assistant; an agent that executes actions needs execution-boundary evidence; a retrieval system needs source and access tracing. The common discipline is the connection between question, method, evidence and conclusion, not an identical list for every technology.

For an SME, a smaller set of well-executed procedures can be more useful than a large unsupported checklist. For an enterprise, shared controls may be assessed once with carefully defined reliance, while deployment-specific differences still require examination. Proportionality changes the scope and effort; it does not turn an assertion into evidence or remove the need to disclose what was not tested.

Keep the checklist version and engagement-specific changes. If criteria or procedures change during fieldwork, assess which completed rows need reconsideration. A later reader should not see a result produced under an old criterion beside a new criterion without explanation. Preserve the history rather than making the completed form appear to have been fixed from the beginning.

Resolve conflicting evidence within the checklist row

A checklist item may receive several pieces of evidence that point in different directions. The restaurant owner may provide a policy requiring approved sources, a demonstration may retrieve the correct menu, and a preserved operational response may contain an unsupported statement. Do not let the strongest-looking document overwrite the observed exception. Record what each item supports: intended design, demonstrated behaviour or an operating observation.

Investigate whether the evidence concerns the same version and conditions. The demonstration may use a corrected instruction set while the operational record predates it. Alternatively, the policy may apply to one location while the response came from another. Those distinctions can reconcile apparently conflicting evidence without denying any of it. If the discrepancy remains unresolved, the checklist should state the uncertainty and the resulting limitation on the conclusion.

Use a short evidence-resolution note with four elements: the competing items, the relevant scope differences, the additional check performed and the final interpretation. For example, confirming that a newer menu source was introduced after the observed response may explain the timeline but does not establish that the earlier response was supported when issued. The original question and time boundary still govern the result.

Review positive rows as well as exceptions. A row marked supported because a configuration setting exists may need operating evidence that the setting is applied on the relevant path. A source citation in an answer may need inspection to determine whether it actually supports the statement. Checking only failed rows can leave superficial passes untouched and create an unjustifiably favourable overall picture.

Assign unresolved evidence requests without changing the current outcome to positive. Record the requested item, owner, due point and the question it could resolve. When it arrives, reassess the row and preserve the earlier status and reason for change. If it does not arrive, the report should explain the remaining limitation. A request sent is an administrative event, not evidence obtained.

Before final review, perform a small trace-through exercise. Select one supported row, one exception and one inconclusive row, then ask a competent reviewer to reconstruct each from its evidence and procedure. This tests whether the checklist is functioning as an assessment record rather than a form-filling exercise. Resolve any gaps in reference, interpretation or scope before relying on the checklist in the report.

Turn the completed checklist into a defensible conclusion

Review the material exceptions, unresolved questions and coverage limits together. Do not calculate a favourable overall score by counting easy positive rows against one consequential unresolved issue. Explain which findings govern the management decision and why. The conclusion should match the actual scope and evidence, including limitations that prevent a broader statement.

Preparation is a separate task: preparing for an AI audit explains how owners assemble records and access without manufacturing historical evidence. After findings are addressed, retesting determines whether the agreed correction criteria are met. The checklist is useful at each stage only when its labels accurately describe the work performed.

For a scoped AI audit, bring the intended decision, workflow description and available evidence rather than a prefilled sheet of positive answers. Discuss a proportionate AI audit checklist and evidence plan.