AI Policies, Standards, Monitoring and Audit

In May 2026 the American Arbitration Association published a survey of 500 senior legal and executive leaders at large organizations in the United States and Canada. Almost nine in ten, 87 percent, said their organization had some form of AI governance in place. Before reading on, guess how many said that governance was operating effectively.

The answer was 22 percent. The same share, 22 percent, were very confident they could produce evidence of their governance decisions if a regulator or an auditor asked for it. Only a third had defined how to escalate when an AI system misbehaves¹.

These are self-reported figures from a single survey, not audited results, and they should be read that way. But they describe a gap that many executives will recognize. The documents exist. What is missing is the machinery that turns a document into behavior, notices when behavior drifts, and lets someone outside the work confirm that it is all real.

The core idea

A policy says what must be true. A standard makes that requirement specific enough to test. A control is the mechanism that makes it happen. Monitoring shows management, continuously, whether it is happening. Audit tells the board, independently, whether management’s picture can be trusted. And every finding feeds back into the policy, the standard or the control.

AI Policy vs AI Governance traced a single requirement from principle to evidence and showed that every link needs an owner. This chapter is about the machinery that keeps those links working day after day: how standards are written, what kinds of control exist, how a control is tested, what management watches, how exceptions are handled without becoming a second, unwritten policy, and what independent audit adds. ISO/IEC 42001, the international standard for AI management systems, is built on the same loop. It asks for a documented AI policy, then for monitoring and measurement, internal audit, management review and corrective action².

Standards turn a policy into something you can test

A policy is written to last. It states intent in words broad enough to survive new tools and new teams: high-risk AI systems must be evaluated before use. That durability is also its weakness. Nobody can check whether “evaluated” has happened, because nobody has said what it means.

A standard says what it means. It sets the minimum that every team must meet, in terms concrete enough that a third party could check it.

Three properties make a standard useful. It is specific: it names the evidence that shows compliance. It is reusable: a small library of standards for data use, evaluation, human oversight, third-party AI, logging and the permissions of AI agents means each new project inherits its requirements instead of renegotiating them. And it is stable: the procedures that carry out a standard, such as which form to fill in or which tool runs the tests, can change every quarter without the standard changing at all.

Policies and standards also need governing themselves. Each has an owner, an approver, a version, and a date by which it will be reviewed. ISO/IEC 42001 lists the review of the AI policy at planned intervals among its reference controls². A standard that nobody has reviewed since the last generation of tools is a standard that teams have already started to work around.

Controls prevent, detect and correct

A control is any mechanism that makes an unwanted outcome less likely or less harmful. Controls come in three kinds, and a sound system uses all three.

Preventive controls stop the unwanted event: a release pipeline that refuses to deploy without an approval record, an access rule that keeps an agent away from the payments system, a filter that blocks restricted data from leaving the network. Detective controls find what prevention missed: logs, alerts, periodic sampling of outputs, and channels for users to report problems. Corrective controls restore an acceptable state: rolling back a release, revoking access, switching a feature off, retiring a system. The COSO internal control framework, which is widely used by finance and audit teams, asks organizations to choose a deliberate mix of preventive and detective, manual and automated control activities³.

Two design rules follow. First, set a baseline that applies to every AI system, such as a named owner, a risk tier, approved data use, access control, logging and an incident route, and add controls as the tier rises. The tiers themselves are set in AI Inventory and Risk Classification. Second, automate routine controls wherever you can. A manual check that people skip under deadline pressure is a control in name only, as the story later in this chapter shows.

A control can fail twice: in design and in operation

A useful idea executives can borrow from financial audit is that a control has two separate ways to fail. The standard that governs audits of internal control at US listed companies makes the distinction precisely. Design effectiveness asks whether the control, if it is operated as prescribed by competent people, would actually meet its objective. Operating effectiveness asks whether it is in fact operating as designed. Auditors test the second by inquiry, observation, inspection of records and, where it matters, re-performing the control themselves⁴.

Take one requirement and test it both ways. The policy says no high-risk system goes live without approval. The control is a release pipeline that blocks deployment without an approval record. The design test asks whether the block covers every route to production, including the vendor-hosted tool a business team can configure without touching the pipeline at all. The operating test tries a controlled release without approval and samples last quarter’s releases to see whether any went through. A control can pass one test and fail the other, and either failure can go unnoticed for years if nobody runs the test.

For AI used in financial reporting, none of this is optional. The Sarbanes-Oxley Act requires management to assess internal control over financial reporting each year, with auditor attestation for larger filers, and AI used in the close, in reconciliations or in reporting falls inside those controls.

Monitor the controls, not only the system

AI Lifecycle Governance covered monitoring the system itself: its accuracy, drift, cost and business outcomes. This chapter adds a second layer that is easy to miss. Management also has to watch whether the controls are working. How many high-risk systems are running on a current approval? How many exceptions are past their expiry date? How many alerts were acknowledged within the agreed time? How many audit actions are overdue? How much of the AI estate is in the inventory at all?

COSO calls this ongoing evaluation, built into normal operations, as distinct from the separate evaluations that an independent function carries out from time to time³. The NIST AI Risk Management Framework asks organizations to plan ongoing monitoring and periodic review of the risk management process itself, with roles and review frequencies defined⁵.

Every indicator needs thresholds, and every threshold needs an owner and a clock. A dashboard can show red for weeks and still look like control to the people who glance at it. If an alert goes to a shared mailbox, nobody has been asked to act. The test of monitoring is not how many indicators you track. It is how long a red indicator stays red.

Exceptions: controlled flexibility or a second policy

No policy anticipates every situation. A team needs a tool the standard has not yet approved; a deadline means an evaluation will finish a week after launch. A mature system plans for this. An immature one pretends it will not happen, and the exceptions happen anyway, informally, where nobody can see them.

A controlled exception has a short, fixed anatomy. It names the rule being departed from and the reason. It states the extra risk and the compensating controls that will hold it down, such as a human review of every output until the evaluation is complete. It has an owner who answers for it and an approver who is not the person asking. It has an expiry date, and when the date arrives the exception lapses unless someone makes a fresh decision; it does not renew with a click. All exceptions sit in one register that the governance office can see, and expired ones show up on the control dashboard like any other failed control.

Two neighbors handle the edges. When a business chooses to live with a known residual risk rather than depart from a rule, that is risk acceptance, covered in AI Evaluation and Approval Gates. When the same exception is requested again and again, that is a signal that the policy itself no longer fits, as AI Policy vs AI Governance argued. The most dangerous exception is the one nobody recorded: a step that was simply skipped, once, and then again.

Audit is separate, and closes findings in fact

Monitoring and audit are often confused, and the confusion weakens both. Monitoring is management watching its own controls. Audit is a separate evaluation by people who do not run those controls, reporting to the board.

AI Roles, Ownership and Accountability placed internal audit in the third line of the IIA’s Three Lines Model, providing independent and objective assurance⁶. The audit profession’s own standards show why that independence has to be protected in practice. Internal auditors must not assess activities they were responsible for, and their objectivity is presumed impaired if they give assurance on something they ran within the previous twelve months⁷. That is the practical reason not to put internal audit on the approval panel for AI systems. An auditor who approved a system cannot later judge, with any credibility, whether the approval process worked. Audit can advise on how a control is designed; management must own and operate it.

Audit needs a trail to follow. For any material AI system, the organization should be able to reconstruct what was decided, by whom, on what evidence, under which version of which standard, which exceptions applied, and what has changed since. If the trail is captured as the work happens, in the release pipeline, the inventory and the exception register, an audit is a matter of sampling. If it has to be assembled afterwards, the audit mostly measures how good people are at remembering.

The last step is where programs often fall short. An audit finding is closed when the control has changed and the change has been tested, not when a plan or a new document has been written. The IIA’s standards require internal auditors to confirm that management has actually implemented agreed actions, with risk-based follow-up and a tracking system. Where management has not acted by the agreed date, the chief audit executive must decide whether management, “by delay or inaction”, has accepted a risk beyond the organization’s tolerance⁷. ISO/IEC 42001 makes the same demand of the organization itself: nonconformities lead to corrective action whose effectiveness is reviewed². Overdue findings are not an administrative backlog. They are decisions to live with a known weakness, made by default.

Story: the pitch that passed every check but one

One of the most candid recent post-mortems of a control failure involving AI comes from a national technology magazine, a publication whose staff report on AI for a living and whose newsroom includes a dedicated team of fact-checkers. In August 2025 it published an unusually frank account of how it had been deceived⁸.

On 7 April an editor received a pitch about couples who hold their weddings in online games. It was, in the magazine’s words, the kind of story it might have built in a lab. The editor assigned it, the writer responded promptly to edits, and the story ran on 7 May. Over the following days the writer could not provide enough information to be set up in the payments system and insisted on being paid through an online payment app or by check. Now suspicious, an editor ran the article through two third-party AI-detection tools. Both said it was probably written by a human. A closer look at the story’s details and further correspondence showed it was an AI fabrication, and after more checking by the head of the research desk the magazine retracted it⁸. Other publications removed pieces under the same byline⁹.

The magazine’s own diagnosis is the instructive part. The story “did not go through a proper fact-check process or get a top edit from a more senior editor”, and first-time contributors “should generally get both”⁸. Read that through this chapter’s layers. The policy was sound: publish only verified journalism. The standard existed: first-time contributors get a fact-check and a senior edit. The control was skipped, without any record that it had been, which makes it an unrecorded exception. The detective control that worked was not an editorial one at all; it was the finance process that verifies who is being paid. The AI-detection tools, which looked like a control, gave false reassurance: a design failure. And the remediation, by the magazine’s account, was “steps to ensure this doesn’t happen again”, which it did not specify.

An auditor reviewing the episode would not ask for a new policy. The question is whether the senior edit and fact-check for first-time contributors are now enforced by the workflow, for example by a publishing system that will not release a first-time byline without both sign-offs, and whether anyone has tested that block. That is the difference between a closed finding and a closed file.

What this means for leaders

The survey that opened this chapter suggests that, for large organizations, the question is no longer whether they have AI governance. The better question is whether it operates, and whether they could show that it does. Leaders can push that question in four ways. Ask for standards that come with their tests. Ask for control health, not only system health, on the dashboards you see. Treat the exception register as a list of decisions with dates, not a list of favors. And measure audit by verified fixes, not by findings raised.

Check yourself

1. A clear, published AI policy is enough for an organization to show its AI is governed.MythFact
2. A control can be well designed and still fail.MythFact
3. Monitoring dashboards make independent audit unnecessary.MythFact
4. Internal audit should sit on the approval panel for high-risk AI systems.MythFact
5. A well-run exception has an approver other than the requester and an expiry date.MythFact
6. An audit finding can be closed once management has written a remediation plan.MythFact

Reflection: the control nobody tested

What comes next

This chapter completes the control and oversight mechanisms of AI governance: inventory and classification, lifecycle controls, approval gates, and now the standards, monitoring, exceptions and audit that keep them honest. The final chapter of the module, Module 07 Synthesis — Governing AI at Scale, puts all of these pieces together into a single executive governance framework that can grow with the number of AI systems you run.