How to Audit Your AI Systems: A Practical Guide for Singapore Companies

Why AI Auditing Is No Longer Optional

ISO 42001 Clause 9.2 establishes internal auditing as a mandatory component of any conforming AI management system. This is not a best-practice recommendation — it is a normative requirement. Organisations seeking certification, or simply seeking to demonstrate conformance, must be able to show that internal audits are conducted at planned intervals, that the audit programme is documented, and that findings are reported to relevant management and tracked to resolution. For Singapore companies engaging with IMDA's AI Governance Framework — published in its current form in May 2024 — the obligations extend further. Dimension 5 of that framework covers testing and assurance: organisations are expected to test AI systems before deployment and to review performance on an ongoing basis as a condition of responsible deployment. The audit is the mechanism that makes ongoing review systematic rather than ad hoc.

But the case for AI auditing goes beyond regulatory compliance, and the companies that treat it as a checkbox exercise miss the more important point. AI systems behave differently in production than they do during testing. They encounter document types, query patterns, and edge cases that the test environment never covered. They drift as the statistical distribution of inputs shifts over time — gradually, without any single failure event that would trigger an alert. They produce outputs that may be individually plausible but systematically skewed in ways that were not apparent at launch. These are not hypothetical failure modes; they are documented patterns in deployed AI systems across industries.

Without periodic auditing, you will not know when your AI system is underperforming until the consequences are visible — and in environments where AI outputs feed consequential decisions about procurement, credit, hiring, clinical pathways, or regulatory submissions, underperformance has real stakes. The AI audit is the feedback loop that keeps the system honest. It is the mechanism that closes the distance between what you believe the system is doing and what it is actually doing in production.

What an AI Audit Actually Covers

An AI audit is not a code review, and it is not a security penetration test — though both have their place. It is a structured assessment across five domains, each of which addresses a different layer of risk.

The first domain is governance. Are the accountability structures in place? Is there a documented AI policy? Is the AI system registry current and accurate? Are the responsible persons identified — the AI system owner, the data owner, the human oversight role — and do they understand their responsibilities? Are the ISO 42001 Annex A controls applicable to this system documented in a Statement of Applicability, with implementation status recorded? Governance failures are the most foundational category of finding, because without the governance structures in place, none of the other controls can be systematically implemented or verified.

The second domain is data. Is input data quality adequate for the AI system's intended use? Is data provenance documented — can you trace where the training data came from, who labelled it, and how it was validated? For operational AI systems that process documents in real time, are data quality checks in place before documents enter the extraction or inference pipeline? Data quality issues are often the root cause of AI performance degradation, and they are frequently invisible without deliberate investigation.

The third domain is performance. Is the AI performing as intended? Has accuracy degraded since initial deployment? What is the distribution of confidence scores across the audit period — and is there a growing tail of chronically low-confidence outputs that should be triggering more human review than they currently are? For decision-support systems: how often do human reviewers override AI recommendations, and why? High override rates concentrated in a particular decision type or document category are a signal worth investigating.

The fourth domain is compliance. Does the AI system's data processing comply with the Personal Data Protection Act? Are data retention periods documented and enforced? Does the system meet the applicable ISO 42001 SoA controls? Does it satisfy the IMDA framework's expectations for the risk tier assigned to this system?

The fifth domain is incidents. Has the AI system caused any incidents during the audit period — incorrect outputs that affected a decision, a data processing error, a performance failure, a scope-of-use violation? Were incidents documented when they occurred? Were root causes identified and remediated, or were incidents handled informally with no institutional record? An audit that examines all five domains gives a complete picture of whether the AI system is operating as intended and within its governance boundaries. Addressing any one domain in isolation leaves the picture incomplete.

Step 1: Define Scope and Objectives

Before any evidence is gathered, the audit needs a clearly defined scope. Which AI systems are in scope for this audit cycle? If your organisation has deployed multiple AI systems — as is increasingly common even among mid-sized Singapore companies — a risk-based prioritisation is both reasonable and appropriate. High-risk systems, which ISO 42001 defines as systems that influence consequential decisions affecting individuals, should be audited more frequently and should be prioritised when audit resources are limited. Start with the systems where underperformance or governance failure would have the greatest impact.

Once the scope is established, define the objective. Different audit cycles may have different primary objectives. A conformance assessment against ISO 42001 asks: are the required controls implemented and documented? A performance review asks: is the AI performing at the level documented in its design specification, and has it drifted since initial deployment? A PDPA compliance assessment asks: are the data processing activities lawful, documented, and consistent with the system's stated purpose? A combined assessment covers all domains in a single cycle, which is appropriate for annual audits of higher-risk systems or for first-cycle audits where the baseline has not yet been established.

The question of who conducts the audit matters. Internal auditors can conduct AI audits, but they must be independent of the team operating the AI system being audited. For smaller organisations, this may require cross-functional arrangements: the compliance function auditing an AI system deployed by the operations team, or the finance function auditing an AI system operated by IT. External auditors provide structural independence and a perspective shaped by auditing multiple organisations — which is particularly valuable for first-cycle audits or when preparing for ISO 42001 certification. Document the scope, objectives, audit team composition, timeline, and evidence-gathering approach before beginning fieldwork. That planning document is itself ISO 42001 evidence.

Step 2: Document Review

The audit begins with document review — gathering and assessing the documented information that should exist for a well-governed AI system. This phase does not test whether controls are operating; it establishes what is claimed and whether the claims are credible. The gap between what is claimed in documentation and what is found in control testing is often where the most important audit findings emerge.

Start with the AI system registry entry for the system in scope. Does it exist? Is it current? Does it accurately describe the system's intended use, the categories of data it processes, the assigned risk classification, the controls applied, and the responsible person? A registry entry that has not been updated since deployment — despite documented changes to the system's scope or configuration — is a finding in its own right.

Review the Statement of Applicability. Which ISO 42001 Annex A controls are applicable to this system? For applicable controls, is implementation documented? For excluded controls, is the exclusion justified and recorded? An SoA with unexplained exclusions — particularly for controls that would appear relevant given the system's risk classification — should be queried.

Pull the prior audit report, if one exists. Are there open findings from the previous cycle? Were agreed remediation actions completed on schedule? Repeat findings — the same control failure appearing in successive audit cycles — are a sign that the remediation process is not working and warrant escalation.

Review the PDPA data processing record for the system. Does it accurately reflect the categories of personal data processed, the legal basis for processing, the retention period, and the cross-border transfer position where applicable? Finally, review the incident log for the audit period. Gaps in documentation — missing records, outdated entries, unexplained lapses — are themselves findings. They indicate that the governance process is not functioning as designed, or was never designed at all.

Step 3: Control Testing

Document review tells you what is claimed. Control testing tells you what is actually happening. For each applicable ISO 42001 control, the auditor verifies implementation through testing — not by confirming that a document describing the control exists, but by testing whether the control is operating in practice. The distinction is not semantic. A control that is documented but not operating provides no actual protection; in some respects it is worse than no control at all, because it creates the false impression that the risk is managed.

Consider a few concrete examples. For Control A.6.2.8 (event logging): the SoA records the control as implemented. To test it, pull a sample of five transactions from the past month and verify that each appears in the event log with the required fields populated — timestamp, system identifier, input reference, output reference, and the identity of any human reviewer who acted on the output. If the entries are present and complete, the control is operating. If the log is empty, if entries are missing required fields, or if sampling reveals gaps in coverage, the control is not operating despite being documented.

For Control A.9.4 (intended use): the registry entry says the system is used for extracting data from utility bills submitted in a specific procurement workflow. To test it, speak with the operations team. Is the system being used only for this purpose — or has it been informally extended to process supplier invoices, tenancy agreements, or other document types that were never assessed as part of the system's design specification? Scope creep beyond the assessed use case is a common and significant finding in operational AI audits. It happens not through deliberate policy decisions but through convenience: the system works well on utility bills, so someone tries it on invoices, and if it seems to work there too, the practice spreads. The audit is the mechanism that surfaces this drift.

For Control A.5.3 (human oversight): the design specification says all AI-generated outputs are reviewed and approved by a human reviewer before being committed to the system of record. To test it, examine the approval logs for the past quarter. Is every committed entry accompanied by an approval record? Does the record name an identifiable human reviewer — or is it an autogenerated system entry that cannot actually confirm that a human reviewed the output? An approval field populated by an automated process defeats the entire purpose of the human oversight control. Document all testing with evidence: log extracts, screenshots, records of interviews with relevant staff. These working papers are the audit's evidentiary foundation.

Step 4: Performance Review

An AI system that passes governance and compliance checks but is performing poorly in production is still a problem — and potentially a more immediate one. The performance review examines whether the AI is doing its job at the level that justified its deployment. This requires access to operational data: output logs, correction records, confidence score distributions, and override logs where applicable.

For extraction systems — systems that read documents and extract structured data — the primary metric is correction rate. Of the AI-proposed extractions that were reviewed by a human operator during the audit period, what proportion required correction before being accepted? A correction rate below 5% suggests the system is performing well on its current document population. A rate between 5% and 15% warrants monitoring and may indicate that the document population has drifted from the training distribution. A rate above 15% is a material finding: the system is generating enough incorrect outputs that the human review burden is substantially higher than the design assumed, and the risk of an incorrect output being accepted without correction increases accordingly.

For decision-support systems — systems that recommend an action or classification that a human then accepts or overrides — the primary metric is override rate. Of the AI recommendations presented to human reviewers during the audit period, what proportion were overridden? A high override rate is not automatically bad: if the human reviewers are well-calibrated and the AI is being appropriately conservative, a moderate override rate may reflect the system working as intended. But a high override rate concentrated in a specific decision category or time period is a signal worth investigating. Was there a model update that changed the system's behaviour? A change in the quality or format of input data? A change in the operating context — new product lines, new customer segments, new regulatory requirements — that made the AI's embedded assumptions less applicable?

In both cases, examine the distribution of confidence scores for the audit period and compare it to the prior period. An increasing proportion of low-confidence outputs suggests that the system is encountering inputs it was not trained on — a form of distributional drift that, left unaddressed, will progressively degrade performance. Document performance findings with data: aggregate metrics, period-on-period comparisons where available, and specific examples of high-impact errors where they occurred. Concrete examples make findings actionable; abstract percentage figures alone do not.

Step 5: Reporting and Remediation Tracking

The audit produces a report. The report should be structured to enable action, not merely to record what was assessed. A well-structured AI audit report covers: the audit scope, objectives, and period; the methodology used and the evidence gathered; all findings with a severity rating and a root cause assessment; recommended remediation actions with proposed timelines; and the overall audit conclusion — whether the system is operating within its governance boundaries and at an acceptable performance level.

Findings should be specific and evidence-based. The difference between a weak finding and a useful finding is specificity. "Documentation was found to be incomplete" is weak — it tells the system owner nothing actionable. Compare it to: "The AI system registry entry for the invoice extraction system had not been updated since March 2024, despite two changes to the system's document type scope recorded in the system changelog in April and June 2024. The registry entry therefore does not accurately reflect the system's current intended use or risk profile." The specific finding names the system, the gap, the evidence, and the implication. It creates accountability and makes the remediation path obvious: update the registry entry to reflect the current scope, and establish a process trigger to update it whenever the system's configuration changes.

Share the completed report with the AI system owner and with the governance committee or senior management function responsible for AI oversight. Agree remediation actions and realistic deadlines. Assign ownership for each finding — an agreed action without a named owner rarely gets completed. Track open findings until they are formally closed, and verify remediation before closure: a finding is not closed because the owner says it has been fixed, but because the auditor has retested the control and confirmed that it is now operating as required. Premature closure of findings — recording them as resolved on the basis of assertion rather than evidence — is itself an audit finding if it comes to light in a subsequent cycle.

The completed audit package — the planning document, working papers, report, agreed remediation actions, tracking records, and closure evidence — must be retained as documented information under ISO 42001. This is not merely a compliance obligation. It is the institutional memory that makes the next audit faster, more targeted, and more useful. An organisation in its third or fourth audit cycle, with well-maintained audit records and a culture of genuine remediation, is substantively more resilient than one conducting its first audit under certification pressure. The programme builds value with each iteration — but only if the records are maintained and the findings are genuinely resolved.