The Cleanroom Standard for AI.

Executive summary

What it is. A classification standard for AI deployments, modelled on the cleanroom. It defines what a governed AI deployment looks like. It does not restrict who can build one. It applies to any AI system, including AI agents, whose actions or outputs have consequences outside the system: decisions, records, payments, instructions to equipment, submissions to regulators, or advice relied on by others.

A cleanroom does not catch contamination. It never claimed to. It makes the environment provable and every entry traceable. This standard does the same for AI. It does not promise to detect a wrong prediction. It requires proof of what a human authorized, proof of what the system was permitted to do at that moment, and a hold on the action when the two stop matching. Provenance and a hold, not correction.

The four principles.

• The environment is certified, not trusted. The rules of what the AI may do are held outside the AI, where it cannot rewrite them.
• Everything that enters is checked at the boundary, at the moment of action, not audited months later.
• A human holds the authority, and the human's decision is recorded when it happens.
• The record is independent. Anyone can verify it, without the vendor's help and without trusting the operator's own logs. Change one byte and the verification fails.

The three classes. The class is chosen by the consequence of the deployment's actions, not by the size of the model. Each class is a floor, and a higher class meets every lower one.

What every class requires. Authority set by a named person and held outside the AI. Every consequential action checked against current authority before it takes effect. Fail closed: no answer is a no, and a stop stays tripped until a named person re-arms it. A withdrawal of authority applies at once, including to queued actions. A record of every decision, whatever its outcome, that an outsider can verify.

What an operator attests. The class and why it was chosen; every path by which the AI can act; who holds authority and over what; how drift is measured and when earlier approvals lapse; where the record is held and how an outsider verifies it; how the control fails closed and when that was last tested. Classes 1 and 2 self-attest, signed. Class 3 is also verified by a body the operator does not employ.

What an insurer, buyer or regulator can ask for. The authority register, named person by named person. The drift trend. The stopping distance after each withdrawal. The value the control held. Wrong refusals and availability. The control's shared dependencies. A record of absence: that no action took effect outside authority. A sealed packet of records they can check on their own machine. The record supplies the evidence. The insurer, the auditor, the regulator or the court makes the determination.

How to start.

1. List every path by which your AI can take an action outside its environment.
2. Choose the class by the consequence of the most consequential action (Clause 5).
3. Name the person who holds each authority, and state its scope and expiry (6.1).
4. Put every path through the boundary check, failing closed (6.2, 6.3).
5. Run the test methods in Annex E, and record the results.
6. Sign the attestation (8.2). For Class 3, engage an independent verifier (8.4).

Define the floor. Let anyone check.

Foreword

This standard is published as a reference. Regulators, standards bodies, insurers, procurement teams and professional bodies are welcome to read it, cite it, and build on it.

It follows the path by which USP Chapter 797 became the floor for sterile compounding in the United States: written, carried by people the field already trusted, and adopted by reference into the places that already have the power to require it.

When a powerful technology arrives, gatekeeping does not work. So this standard does not restrict who can build governed AI. It defines what governed AI looks like, and it leaves the check to whoever the operator hands the proof to.

This is Version 1.0. It is complete in itself. Later versions will be published under new version numbers, and a deployment states the version against which it attests.

Disclosure of interest

The author is the founder and inventor of Regulayer™, which builds controls of the kind this standard describes. Patents are pending on aspects of such controls. This standard names no product and specifies no method: it states what must be true and what must be provable, never how. Any implementation that meets its requirements conforms, whoever built it, and a deployment is checked against this text and Annex E in the same way, whatever it runs on.

Drafting conventions

This standard uses the verbal forms of an international standard.

• shall states a requirement. A deployment that does not meet it does not conform to the class concerned.
• should states a recommendation. A deployment that departs from it should be able to say why.
• may states a permission.
• can states a possibility or a capability.

Notes and examples are informative. They help the reader apply a requirement and do not add to it. Annexes A to D are informative. Annex E is normative. Clauses 1 to 9 are normative unless marked otherwise.

Where a requirement applies only from a given class upward, it carries a class mark, for example Class 3. A requirement without a mark applies to every class.

Introduction

0.1 The cleanroom

A cleanroom does not ask whether the technician is careful. It certifies the environment and everything that enters it. Air, gowns, wipes, materials, all proven clean, continuously, with records. The operator works inside a proven environment, and the proof does not depend on anyone's word.

The model has five parts, and this standard carries each of them across.

A certified environment. A cleanroom is classified. Its class states the cleanliness the room must hold, and the class is chosen by the process the room protects, not by the preference of the people working in it. Before work begins, the room is shown to meet its class. Certification belongs to the room, not to the people in it.

Controlled entry. Nothing reaches the room by any path except the one that is controlled. People, materials and equipment pass through the airlock, and each is checked or cleaned before the inner door opens. An airlock does not slow anyone down. It holds one door shut until the other is cleared.

Gowning as authority. Entry is a qualification, not a status. A person enters only gowned to the standard the room requires, and the qualification to gown is proven again, not assumed from last time. Gowning is the cleanroom's form of current authority: it holds at the moment of entry, or the person does not enter.

Continuous monitoring. The room is measured while it works. Counts are taken, excursions are recorded when they occur, and the record exists before anyone asks for it. A room that was clean at certification and is not monitored afterwards is a room nobody can vouch for.

Recertification. Certification is repeated, and it is repeated after any change to the room, its equipment or its process. A change to the environment is a reason to prove the environment again.

Across all five runs a sixth condition: everyone inside is held to the same floor. The senior scientist gowns as the new technician does. The contractor's equipment is wiped as the room's own equipment is. No one is trusted on their own word.

0.2 What a cleanroom actually promises

A cleanroom does not catch contamination. It never claimed to. What it does is make the environment provable and every entry traceable, so that when something goes wrong you can establish where it came from, what was authorized, and who accepted it. That is what allows a regulator to approve a process rather than inspect every particle. Approval does not rest on a promise that nothing will fail. It rests on being able to prove the conditions and reconstruct the path.

0.3 The same discipline, applied to AI

Apply that honestly to AI and the claim gets smaller and much stronger. A standard for AI should not promise to detect a wrong prediction, because no current method can guarantee that, and a standard built on that promise would be asking for the same trust the cleanroom was invented to replace. What a standard can do is prove what a human authorized, prove what the system was permitted to do at that moment, and hold the action when the two stop matching.

Provenance and a hold, not correction.

In an AI deployment, the room is the environment: the AI system, its permissions, its data, its connections to the world and the people accountable for it. The airlock is the boundary, the point at which an action of the AI would take effect outside the environment. Gowning is current authority: what a named person allows the AI to do, checked at the moment of action rather than assumed from the moment it was granted. The particle count is drift, the quiet divergence between what a human authorized and what the system is now doing. The batch record is the independent record of every governed decision. The cleanroom's certification has its counterpart in the operator's signed attestation, and for the highest class, in verification by a body the operator does not employ. Annex A sets the two side by side.

The AI produces the candidate. The deployment governs the consequence. The model may agree. The action still requires current human authority.

0.4 Everyone inside works to the same floor

Everyone who works inside the environment works to the same floor: the people who grant authority, the AI agents that act, the models they run on, and the vendors who supply them. No one is trusted on their own word. Everyone is held to a certified environment.

People. Authority comes from a named person, and the person's decision is recorded when it happens. A person can be persuaded, can tire and can be wrong. This standard does not depend on the person being right. It depends on the person being named, on their authority being current when the action lands, and on their decision being on the record.

AI agents. An agent proposes. It does not get the final word on whether its own consequential action proceeds. AI goes rogue for more than one reason. It drifts. It gets talked into it. It follows an instruction hidden in a document. Another agent asks it. The boundary does not need to know why. Every action still has to pass a named person's current authority.

Models. A model is part of the environment. A model that is changed, retuned or replaced has changed the environment, whether or not its version number moved, and the environment is proven again.

Vendors. A vendor supplies the AI, the control or both. A vendor's own log is not an outsider's check, and a vendor's model is still the operator's responsibility. Insurance supervisors already say the same: New York, Colorado, the NAIC model bulletin and Australia's prudential regulator all keep the regulated firm answerable for the data and models it buys, Bermuda's regulator proposes the same, and Texas extends its expectations to any third party working with an insurer.

0.5 Why a standard, and why now

Some of the most regulated industries now take input from AI systems that sit outside their manufacturing controls. In drug manufacturing, the quality unit reviews the batch record before release, and any unexplained discrepancy must be thoroughly investigated (21 CFR 211.192). Upstream of that control, AI models now help propose candidates, select protocols and steer discovery. On BioLP-bench (Ivanov, 2024), qualified human experts find the single error planted in a laboratory protocol 38.4 per cent of the time, and the strongest models now score in the mid to high forties. Neither people nor models catch these errors reliably, which is the condition a cleanroom was designed for. Annex C sets out why this standard exists.

The demand for evidence is arriving before the standard does. Regulation (EU) 2024/1689, the EU AI Act, will require stand-alone high-risk AI systems, from 2 December 2027 (2 August 2028 for those embedded in regulated products), to allow the automatic recording of events over their lifetime (Article 12), and to be designed so that natural persons can oversee them effectively, including the ability to interrupt the system and bring it to a halt in a safe state (Article 14). In a warning letter dated 2 April 2026, the FDA told a manufacturer that any output or recommendation from an AI agent must be reviewed and cleared by an authorized human representative of its quality unit. The Texas Department of Insurance, in Bulletin B-0003-26 of 12 June 2026, expects a person to review and agree with all decisions before action is taken where AI is used to make a consequential decision. California SB 947, approved on 30 September 2026, bars an employer from relying solely on an automated decision system to discipline or dismiss an employee. The Bermuda Monetary Authority's consultation of 14 August 2026 asks that controls over higher-impact agent actions do not rely solely on prompts or model instructions, and that material or higher-risk agentic use be assessed for whether records of actions, tool calls, access decisions, approvals, exceptions and outcomes are needed.

Insurers writing AI cover are asking the question a telematics box answers for cars: what actually happened? Today the answer usually comes from the operator's own logs.

The obvious answer, a person approving every step, has a measured cost. In KPMG's AI Quarterly Pulse for Q1 2026, 63 per cent of surveyed US leaders said their organizations now require human validation of AI agent outputs, up from 22 per cent a year earlier. Yet across a review of 17 studies, clinicians overrode drug safety alerts in 49 to 96 per cent of cases (van der Sijs et al., 2006), and in a controlled experiment with 292 participants, a human-in-the-loop design produced less accurate decisions than full delegation with no option to adjust (Sele and Chugunova, 2024). On this evidence, approval at every step does not by itself make decisions better, and its cost grows with every step it gates.

This standard therefore places the person where the person's judgment counts. It's not human in the loop. It's human authority in the loop. A named person's authority is set in advance and is re-checked by a separate control at the moment the action would take effect; the run does not wait for a person, and an action outside that authority is stopped. The person is brought in when an action falls outside what they allowed, and their decision is recorded when it happens.

0.6 How to read this standard

Clause 4 states the four principles from which every requirement follows. Clause 5 defines the three classes and how to choose one by consequence. Clause 6 sets the requirements every class shares. Clause 7 sets what each class adds. Clause 8 sets how conformance is shown and checked, and Clause 9 how it is kept. The annexes compare the standard with the cleanroom, map its evidence to the rules and standards an operator already runs under, tell the story of why it exists, and give an example statement and record. Annex E gives the test methods by which each key requirement is shown to hold.

This standard specifies what must be true and what must be provable. It never specifies how. Two deployments built in entirely different ways can both conform, and a buyer, insurer or regulator can check either of them in the same way.

1Scope

1.1 This standard specifies three classes of AI deployment and the requirements each class must meet. It applies to any AI system, including AI agents, whose actions or outputs have consequences outside the system: decisions, records, payments, instructions to equipment, submissions to regulators, or advice relied on by others.

1.2 It specifies what must be true and what must be provable. It does not specify how a deployment achieves it, and it does not specify any product, method, model, architecture or supplier.

1.3 It is intended for use by operators who run AI deployments and attest to a class; by buyers and procurement teams who require a class of their suppliers; by insurers who read a class and its evidence when they price and cover AI risk; by auditors, notified bodies and independent verifiers; and by regulators, professional bodies and courts who ask what an AI system did and under whose authority.

1.4 It applies across sectors. It applies equally to a deployment built by the operator, a deployment bought from a vendor, and a deployment in which several AI agents, of one or several organizations, act in a chain.

1.5 It does not assess whether an AI system's output is correct, whether a model is accurate, or whether a decision was wise. It establishes who authorized an action, whether that authority was current when the action took effect, what happened, and whether an outsider can check the record of it.

1.6 It does not replace a physical safety interlock where one is required by machinery, device or process safety rules. A control under this standard is consequence control for actions; where a physical stop is required, both apply.

Note. This standard does not establish conformance with any law or any other standard. Annex B identifies where its evidence may support other frameworks. The determination is always made by the regulator, auditor, insurer or court concerned.

2Reference documents

There are no normative references. No other document is required in order to apply this standard.

The following documents informed this standard. They are cited for their principles, not as requirements of it: ISO 14644 (cleanrooms and associated controlled environments); USP General Chapter 797 (pharmaceutical compounding, sterile preparations); FDA 21 CFR Part 11 (electronic records and signatures); FDA 21 CFR Part 211, in particular 211.22, 211.68 and 211.192; EU GMP Annex 11 (computerised systems) and the consultation draft of Annex 22 (artificial intelligence); ISO/IEC 42001 (AI management systems); ISO/IEC 27001 (information security); ISO/IEC 23894 (AI risk management); NIST AI Risk Management Framework; EU AI Act, Articles 9, 12, 13, 14, 15 and 26; NIST SP 800-53 and NIST SP 800-207; OWASP Top 10 for LLM Applications. Full references are given in the Bibliography.

3Terms and definitions

For the purposes of this standard, the following terms and definitions apply.

3.1 The environment and its boundary

3.1.1 AI system. A machine-based system that produces outputs such as content, predictions, recommendations, decisions or actions from the inputs it receives.

3.1.2 AI agent. An AI system that can take actions with effect outside itself, such as calling tools, moving money, sending messages, changing records or instructing equipment, with or without a person reviewing each step.

3.1.3 AI deployment. An AI system together with the environment in which it acts: its permissions, its data, its connections to the world, and the people accountable for it.

3.1.4 Environment. Everything within the boundary of an AI deployment. The equivalent of the room.

3.1.5 Boundary. The point at which an action of the AI would take effect outside the environment. The equivalent of the airlock.

3.1.6 Moment of effect. The point at which an action changes something outside the environment.

3.1.7 Consequential action. An action, or an output released to a person or system, whose effect falls outside the environment and matters to someone: a decision, a record, a payment, a message, an instruction to equipment, a submission, or advice relied on by others.

3.1.8 Control. The function, outside the AI system, that checks each consequential action against current authority at the boundary, decides its outcome, and produces the record.

3.1.9 Operator. The organization that runs the AI deployment and is accountable for it.

3.1.10 Vendor. An organization that supplies an AI system, a model, a control or any part of the environment to the operator.

3.2 Authority

3.2.1 Named person. An identified human being who holds authority, recorded by name. A service account, an API key, a role or a shared login is not a named person.

3.2.2 Authority. What a named person has permitted the AI to do: which actions, how much, and for how long.

3.2.3 Scope of authority. The exact actions, targets, values, limits and expiry that an authority covers.

3.2.4 Current authority. Authority that is still in force at the moment an action would take effect, not merely at the moment it was granted.

3.2.5 Delegated authority. Authority that a named person or organization passes to another person, organization or agent, within limits of class, territory, value and time.

3.2.6 Withdrawal. The act by which a named person ends or narrows an authority.

3.2.7 Superseded authority. An authority replaced by a later decision, preserved as history and no longer governing.

Note. Superseded does not mean deleted. It means preserved as history and no longer governing.

3.2.8 Human authority in the loop. A named person's authority is set in advance and is re-checked by a separate control at the moment the action would take effect; the run does not wait for a person, and an action outside that authority is stopped.

3.3 Outcomes at the boundary

3.3.1 Governed decision. The decision the control makes on one consequential action: allowed, corrected, held or stopped.

3.3.2 Allowed. The action sits inside current authority. It is released, and the decision is recorded.

3.3.3 Corrected. The action is sent back to the AI with the reason, and is brought back inside authority before it reaches anyone.

3.3.4 Hold. The state in which an action does not take effect, because it is not covered by current authority, and remains held until a named person decides. Nothing is released and nothing is executed.

3.3.5 Stopped. The action does not proceed. What was attempted, and what stopped it, is written down.

3.3.6 Fail closed. The property that every action requires a positive yes before it runs. No answer is a no. The default state is stopped.

3.3.7 Latched stop. A stop that, once tripped, stays tripped. Nothing runs again until a named person re-arms it.

3.3.8 Re-arm. The act by which a named person ends a latched stop. It is recorded as its own decision.

3.3.9 Bounded correction. The return of a refused action to the AI, with the reason, so that it can correct inside the authority, within a limit set by the consequence of the action.

3.3.10 Stopping distance. How long after a withdrawal of authority actions could still take effect, how many did, and their value.

3.3.11 Wrong refusal. A refusal or hold that later proves to have been unnecessary, because the same action was confirmed by a named person to have been within authority.

3.4 Drift

3.4.1 Drift. The divergence between what a human authorized and what the AI system is now doing.

3.4.2 Normal operating procedure. The behaviour against which a deployment was validated and authorized, stated by the operator for the deployment, against which drift is measured.

3.4.3 Re-approval. A fresh decision by a named person, required after drift has passed the point the operator set in advance, before an affected action takes effect.

3.5 The record and its verification

3.5.1 Record. The account, made at the time, of a governed decision or of any other event this standard requires to be recorded.

3.5.2 Independent record. A record of each governed decision that a third party can verify without the help of the vendor and without trusting the operator's own logs.

3.5.3 Content-free record. A record that shows the conduct, never the content: that the AI acted, in which tool, at what time, under whose authority and with what outcome, without holding the underlying work.

3.5.4 Verification. A check, made by anyone who holds the record, that the record is complete, unchanged and attributable to its signer. Verification does not establish that the underlying work is correct.

3.5.5 Record of absence. Evidence that, for a given action, no other authority covered it at that moment, and that, for a given period, no action took effect outside current authority.

3.5.6 Provenance. The traceable path of an output from its creation to its delivery: what produced it, what entered it, who reviewed it, and who released it.

3.5.7 Evidence level. The statement, carried with each recorded fact, of how the fact was established: self-declared, tool-observed or human-present.

3.6 Isolation, attestation and verification

3.6.1 Architectural isolation. The separation of the control from the AI system it governs such that the two share no memory, no process and no storage, and authority flows in one direction only, from the control to the AI.

3.6.2 Isolation breach. Any event in which the separation in 3.6.1 does not hold: an access across the separation, a message at the boundary that fails its integrity check, or a message delivered without authentication.

3.6.3 Safe halt. The latched stop entered when the control cannot establish that the conditions of its class hold.

3.6.4 Runtime proof. Evidence that the deployment produces of its own required state while it runs, rather than in a report assembled afterwards.

3.6.5 Attestation. A signed statement by the operator that the deployment meets a class of this standard.

3.6.6 Independent verifier. A body that checks conformance and is not employed by, owned by or paid on outcome by the operator.

3.6.7 Availability interval. A recorded period during which the control was, or was not, able to make decisions.

3.6.8 Multi-party commitment. An action that commits two or more organizations at once, such as a shipment, a settlement, a batch release or a joint filing.

4Principles

Every requirement in this standard follows from four principles. Where a requirement is unclear in a particular deployment, it is read in the light of the principle it serves.

4.1 The environment is certified, not trusted

The rules of what the AI may do are held outside the AI, where it cannot rewrite them.

Rationale. If the rules live inside the AI, the AI's behaviour can change them. A model can drift, can be persuaded, can follow an instruction hidden in a document, and can be asked by another agent. The obvious attack on a control is not to argue with it. It is to switch it off. A control that runs outside the system it governs means the governed system cannot vote on whether it stays on.

What conformance looks like. Authority is held where the AI cannot write to it. Output produced by the AI cannot become the governing human authority. The control fails towards stop: attack it, silence it, bypass it or crash it, and it goes to a safe stop, and it stays there until a person re-arms it. Requirements 6.1, 6.3 and 6.8 carry this principle, and Class 3 carries it to full architectural isolation.

4.2 Everything that enters is checked at the boundary

The check happens at the moment of action, not in an audit months later.

Rationale. Authority changes. A person withdraws it, narrows it, or replaces it with a later decision. An earlier approval in an audit trail establishes that authority existed then. It does not, by itself, establish that the same authority still governs when the action executes. For an autonomous system, detecting the mistake afterwards can be too late.

What conformance looks like. Every path by which the AI can act passes through the boundary. Each consequential action is checked against current authority before it takes effect, and the outcome is allowed, corrected, held or stopped. A queued action that reaches the boundary after its authority was withdrawn is held. Requirements 6.2, 6.4 and 6.5 carry this principle.

4.3 A human holds the authority

The human's decision is recorded when it happens.

Rationale. The frameworks mapped in Annex B place accountability on people. Under 21 CFR 211.22, the authority to approve or reject rests with the quality unit. Solicitors remain accountable for all work and advice delivered to clients, whether or not AI has been used. Insurance supervisors name the board and senior management. An AI agent cannot hold authority. Authority comes from a person, or it does not exist.

What conformance looks like. Every authority traces to a named person, never to a service account or a shared login. Grants, withdrawals, re-approvals and re-arms are each recorded at the moment they are made. The person is brought in when an action falls outside what they allowed, so that their attention goes where it counts. Requirements 6.1, 6.3 and 6.4 carry this principle.

4.4 The record is independent

Anyone can verify it, without the vendor's help and without trusting the operator's own logs. Change one byte and the verification fails.

Rationale. Application logs are written by the system under question, so depending on their architecture they may not independently establish the integrity and contemporaneity an outside reviewer is looking for. A record reviewed later and assembled after the question arrives is reconstruction, not evidence. The judge is not employed by the defendant.

What conformance looks like. Each governed decision produces its record at the time it is made. The record can be checked by a stranger, offline, without an account and without the vendor's system, code or cooperation. A missing, altered or reordered entry shows. Requirements 6.6 and 6.7 carry this principle, and Class 3 adds verification of the deployment itself by a body the operator does not employ.

None of this limits what AI can discover or create. A cleanroom never made a drug weaker. It made the drug provable. The same is true here: the standard does not slow the model down. It makes the work provable, with a record built to support its use as evidence before an insurer, an auditor, a regulator or a court.

5Classification

5.1 General

5.1.1 An AI deployment is classified as Class 1, Class 2 or Class 3. As with cleanroom classes, each class is a floor: a deployment that meets a higher class meets every lower one.

5.1.2 The class is chosen by the consequence of the deployment's actions, not by the size of the model.

5.1.3 A deployment conforms to a class when it meets every requirement of Clause 6, every requirement of that class and of each lower class in Clause 7, and the requirements of Clause 8 for that class.

5.1.4 A deployment that does not meet Class 1 is not classified under this standard.

5.2 The three classes

The table below sets out how the classes differ on each dimension of the standard.

5.3 Choosing a class by consequence

5.3.1 The operator shall choose the class by the consequence of the most consequential action the deployment can take, assessed on the following factors:

• Reversibility. Whether the effect can be undone, how completely, and at what cost.
• Who is affected. Whether the effect falls on the operator alone, or on customers, patients, employees, counterparties or the public.
• Regulated status. Whether the action is a regulated decision, record or submission, or forms part of a regulated process such as manufacture, clinical care, credit, insurance, employment or legal practice.
• Physical effect. Whether the action moves, doses, cuts, drives, releases or otherwise acts on the physical world.
• Scale and autonomy. How much value or how many people a single action or a run of actions can reach, and how far the agent acts without a person reviewing each step.

5.3.2 The factor that points to the highest class sets the class. Factors are not averaged.

5.3.3 The following table gives the minimum class for common consequence profiles. An operator may choose a higher class than the minimum.

5.3.4 The operator shall record the factors assessed, the class chosen and the named person who chose it, and shall include them in the attestation (8.2).

Note. The factors follow the ones supervisors already use. The Bermuda Monetary Authority's consultation of 14 August 2026, for example, asks that human oversight be matched to the risk, autonomy and reversibility of each use case.

Note, edge cases. The class is chosen by consequence in every case, including the following.

• Open-weight models run by the operator. Where the operator runs a model whose weights it holds, the operator is accountable for the model as part of the environment. The class is chosen by the consequence of the deployment's actions, not by where the model came from, and a change to the weights is a change to the environment (6.12).
• Edge devices. Where the AI runs on a device at the point of use, such as a vehicle, an instrument or a handheld unit, the boundary is the point at which the device's action would take effect outside it, and the class follows the consequence of that action.
• Offline local deployments. A deployment with no network connection is classified in the same way. Class 3 isolation can be met on a single device, provided the separation requirements of 7.3 hold between the control and the AI on that device: no shared memory, no shared process, no shared storage, and authority flowing in one direction only.
• Hardware that cannot meet Class 3. Where the hardware cannot meet the separation requirements of 7.3, the deployment is classed at the class it does meet. If its consequence requires Class 3, the actions that require Class 3 hold under 9.4.2 until the requirement is met.

5.4 Zones and chains

5.4.1 A deployment may be divided into zones of different classes, as a sterile compounding suite is divided into progressively cleaner rooms. Each zone shall have its own boundary, and an action passing from a lower-class zone to a higher-class zone shall be checked at the boundary of the higher-class zone.

5.4.2 Where AI agents act in a chain, so that the output of one governs the input of the next, every step that can take effect outside the environment shall be checked at the boundary. The class of the chain is the class of the most consequential action any step in it can take.

5.4.3 A chain that loses its authority shall stop where it stands rather than finish.

5.5 Statement of class

5.5.1 A class is stated as the class number, the name of the deployment, the version of this standard, and the date from which the attestation runs, for example: "Class 2 under The Cleanroom Standard for AI, Version 1.0, accounts payable agent, from 1 November 2026".

5.5.2 A class belongs to a deployment, not to an organization, a product or a model. An organization that runs several deployments states the class of each.

6Requirements common to every class

The requirements in this clause apply to every class. Together with the requirements of Class 1 in 7.1, they are the floor.

6.1 Authority

6.1.1 The authority under which the AI acts shall be set by a named person and held outside the AI system, where the AI cannot alter it.

6.1.2 Each authority shall identify the human who holds it, by name. A service account, an API key, a role or a login shall not stand in for a named person.

6.1.3 Each authority shall state its scope: the specific actions, targets and values it covers, any limit, and when it expires. A broad permission or a category of access shall not count as authority for a consequential action.

6.1.4 Output produced by the AI shall not become the governing human authority. An instruction that appears in the AI's own output, in content the AI has read, or in a request from another agent is a candidate for checking, never a source of authority.

6.1.5 Authority shall be granted, narrowed, restored or withdrawn only by an act attributable to the named person who holds it, or to a person to whom they have delegated that power under 6.1.7. The AI shall not grant, extend or restore authority, for itself or for another agent.

6.1.6 Each grant, narrowing, restoration and withdrawal shall be recorded when it is made, with the named person, the scope and the time.

6.1.7 Where authority is delegated, the delegated authority shall be no wider than the authority of the person delegating it, shall name the delegate, and shall state its own scope and expiry. Each action taken under delegated authority shall be checked, at the moment of the action, against the delegate's current scope, territory, limit and expiry, and refused actions shall be recorded.

6.1.8 Where two decisions cover the same action, the later decision of a person entitled to make it governs. The earlier decision shall be preserved as superseded authority, with the moment it stopped governing.

6.1.9 The operator shall keep a current register of every authority in force for the deployment: the named person, the scope, the date of grant, and the expiry.

Note 1. This standard does not prevent a person being persuaded to grant authority. It requires that no action passes beyond what a named person currently allows, and that the grant itself is on the record.

Note 2. Existing rules already ask for this shape. 21 CFR 11.100 requires each electronic signature to be unique to one individual. FDA's 2018 data integrity guidance states that where login credentials are shared, a unique individual cannot be identified through the login. The EU AI Act asks deployers to assign oversight to people with the necessary competence, training and authority.

6.2 The boundary check

6.2.1 Every consequential action shall be checked against current authority at the boundary, before it takes effect.

6.2.2 The operator shall identify every path by which the AI can take an action with effect outside the environment, and every such path shall pass through the boundary. A path that is not accounted for shall be treated as a failure of the boundary, not as an exception to it.

6.2.3 The check shall be made against the authority in force at the moment of effect, not against the authority in force when the work began, when the session opened, or when the action was queued.

6.2.4 The check shall not depend on establishing why the AI proposed the action. An action that drifted, an action the AI was talked into, an action that follows an instruction hidden in a document and an action requested by another agent shall each be checked in the same way.

6.2.5 The outcome of each check shall be one of: allowed, corrected, held or stopped. Each outcome shall be recorded under 6.6.

6.2.6 Where the AI releases an output to a person rather than taking an action, and that output is consequential, the output shall be checked at the boundary before release in the same way as an action.

6.2.7 The check shall apply to the specific action, target and value presented at the boundary. An action that differs in target or value from the one authorized is a different action.

6.2.8 The deployment shall not depend on the AI agreeing to be checked.

Note 1. Identity answers who is acting. Static permission answers what an account may access. The boundary check answers a different question: does this consequential action still match the human authority currently in force?

Note 2, time-critical systems. In a safety-critical control loop, such as the control of a robot's motion or of process equipment, the boundary check is not placed where it would degrade the loop. For such a loop, the check applies to the authority under which the loop is permitted to run, and to each consequential action that leaves the loop, such as starting, changing the task or setpoint of, or stopping the equipment. A physical safety interlock remains required wherever machinery, device or process safety rules require one (1.6).

Note 3, placement of the check. The check is made where a consequential action would take effect (3.1.6, 3.1.7), not on each model call, so reading, drafting and reasoning run as before. The control may sit beside the agent it checks, and for Class 3 in isolation from it (7.3.2). Wherever it is placed, the check is made against the authority in force at the moment of effect (6.2.3), a withdrawal applies from the moment it is made (6.4.1), and where the control cannot confirm the authority in force, actions hold (6.11.1).

6.3 Holds and stops

6.3.1 The control shall fail closed. Every consequential action shall require a positive yes before it runs. No answer shall be treated as a no, and the default state shall be stopped.

6.3.2 An action not covered by current authority shall be held, and shall not take effect, until a named person decides, unless it is returned for bounded correction under 6.3.9, in which case the corrected action is checked again at the boundary as a new action. The AI shall not release its own hold.

6.3.3 Silence shall not be read as consent. If the control stops answering, actions shall go to a safe stop on their own, with no person involved and no message to send.

6.3.4 An attempt to attack, silence, bypass or crash the control shall end in a safe stop. No failure of the control shall result in a consequential action taking effect without a positive decision.

Note. Under 6.3.4, a failure of the control can stop actions but cannot release them.

6.3.5 A safe stop under 6.3.3 or 6.3.4, or under any other clause that requires one, shall be latched: once tripped, no consequential action shall run until a named person re-arms it. The system under control shall not re-arm itself.

Note. Tripped, it stays tripped. Nothing runs again until a person re-arms it.

6.3.6 When a stop is pulled while an agent is mid-task, every action shall stop, including the one already in flight, where it has not yet taken effect.

6.3.7 A failure in the control path shall end in non-execution, never in a silent pass.

6.3.8 An action that failed, or only partly happened, shall not be retried automatically. A named person decides whether it is retried.

6.3.9 A refused action may be returned to the AI for bounded correction, with the reason, so that the AI can correct inside the authority. The operator shall set the limit on correction by the consequence of the action. An action that cannot be undone shall not be returned for automatic correction; a named person decides.

6.3.10 Every decision, every hold, every stop and every re-arm shall be recorded at the moment it happens, with the halt and its proof in the same record.

Note. There is no version of events to reconstruct later.

6.3.11 The deployment shall not depend on the AI agreeing to stop.

Note. A hold is not a failure of the deployment. It is the deployment working. A held action becomes a decision for a named person instead of an event the operator learns about afterwards.

6.4 Withdrawal of authority

6.4.1 When a named person withdraws authority, the withdrawal shall apply to every later action from that moment, including requests already in progress and actions already queued.

6.4.2 An earlier approval shall not continue to govern simply because the action was already queued. An action created while it was authorized, that reaches the boundary after the authority behind it was withdrawn, shall be held.

6.4.3 The narrowing or replacement of an authority shall be treated as a withdrawal of the part no longer covered.

6.4.4 The time of each withdrawal shall be recorded in a form an outsider can rely on, together with the named person who made it.

6.4.5 The operator shall be able to state the stopping distance for every withdrawal: how long after the withdrawal actions could still take effect, how many did, and their value. The time of an action is the time the system that made the change confirms it, never earlier than the withdrawal. Where the time is not confirmed, the record shall give a range or state "unconfirmed". An estimate or an average alone does not meet this requirement, and a stopping distance of zero shall not be stated where any path by which the agent can act is unaccounted for.

6.4.6 The withdrawn authority shall remain in the record as history. It no longer governs.

6.4.7 The record shall show what the agent attempted after the authority was withdrawn, and the outcome of each attempt.

6.4.8 Withdrawn authority shall be restored only by the named person under 6.1.5. Restoring it shall not release actions held during the withdrawal; each held action is decided on its own.

Example. At 10:00 a scientist authorizes Protocol A on Workcell 3, and the agent queues the action. At 10:12 the scientist discovers contamination and withdraws the authorization. At 10:14 the queued action reaches the boundary: the same requested action, unchanged. It is held. Had it reached the boundary while the 10:00 authority was in force, it would have been allowed. At 10:14 it is not.

6.5 Drift and re-approval

6.5.1 The operator shall state, for each deployment, the normal operating procedure against which the deployment was validated and authorized.

6.5.2 Drift shall be measured on every consequential step while the deployment operates. The measurement shall not depend on the AI's own account of whether it has drifted.

6.5.3 The operator shall set in advance, and record, the point beyond which drift causes earlier approvals to lapse. Past that point, the named person shall re-approve before an affected action takes effect.

6.5.4 When an action departs from normal operating procedure but remains capable of correction inside current authority, it may be sent back to the AI with the reason under 6.3.9, and the work may continue. When correction fails, the action shall be held.

6.5.5 A rise in drift shall be recorded when it occurs, together with the actions it affected and their outcomes.

6.5.6 Drift shall be measured whatever its cause. This standard does not require the cause to be diagnosed before the action is held.

6.5.7 The operator should review the trend of drift for each deployment, as a leading sign before a loss.

Note 1. Validation is a moment. Deployment is a continuum. Approved systems continue operating under conditions that approval did not fully anticipate. The instrument feeding the model drifts between calibration intervals. The model itself shifts under temporal distribution change. The person running it, fatigued, interrupted, trusting the system, drifts in ways the AI cannot perceive.

Note 2. Drift is measurable in published research. In SysBench (Qin et al., 2024), in conversations where each turn built on the last, the share of sessions in which a leading model had followed every rule fell from 84.8 per cent after the first turn to 33.7 per cent after the fifth. Regulators ask for monitoring over time: the EMA and FDA guiding principles of January 2026 call for scheduled monitoring and periodic re-evaluation, and EU GMP Annex 11 asks that computerised systems be periodically evaluated to confirm that they remain in a valid state.

Note 3. This standard does not specify how drift is measured, or the point at which approvals lapse. Those are set by the operator for the deployment and stated in the attestation.

6.6 Contents of the record

6.6.1 Every governed decision, whatever its outcome, shall produce a record at the time of the decision. One record shall be produced for each consequential action.

6.6.2 Each record shall contain the seven fields in the table below. The column "What does not count" states evidence that shall not be offered in place of the field.

6.6.3 When the control is down or damaged, the record shall say stopped or unknown. It shall never show success it cannot prove.

6.6.4 Where authority changed before the action, the record shall also show what was previously authorized and by whom; who changed the authority, and when; which decision governs now; which decision it replaced, and the moment that decision stopped governing; what the agent attempted afterwards; and its outcome, against the authority then in force.

6.6.5 The named person's check and the outcome shall be held together in one inseparable record. A record of the check that can be separated from the outcome, or an outcome that can be separated from the check, does not meet this requirement.

6.6.6 Events other than governed decisions shall also be recorded: grants, narrowings, restorations and withdrawals of authority (6.1.6); holds, stops and re-arms (6.3.10); re-approvals after drift (6.5.3); availability intervals (6.11); isolation breaches (7.3); and changes to the environment (6.12).

6.6.7 The record shall make a record of absence possible: for any action, evidence that no other authority covered it at that moment; for any period, evidence that no action took effect outside current authority.

6.6.8 Each recorded fact shall carry its evidence level: self-declared, tool-observed or human-present. A self-report shall never be recorded as an observation.

6.6.9 The record should be content-free. It should record the conduct, never the content: that the AI acted, in which tool, at what time, under whose authority and with what outcome. Where the underlying work is needed, the record should refer to it without containing it.

6.6.10 Each record may state which regulatory obligation it evidences. Where it does, the statement is a mapping, not a conclusion that the obligation is met.

6.6.11 Records shall be kept for at least the longest retention period that applies to the deployment under the operator's legal, regulatory and contractual obligations, and shall remain verifiable for that whole period.

Note. The record does not decide anything. It states what was measured, what was held, what a person chose, and when. Weight is the reader's to give: a court's, an auditor's, an underwriter's.

6.7 Independence and verifiability of the record

6.7.1 The record shall be made at the moment of the decision, not reconstructed after the question arrives.

6.7.2 The record shall be verifiable by a third party without the vendor's help and without reliance on the operator's own logs. Verification shall not require the vendor's system, code, account or cooperation.

6.7.3 Any alteration of the record shall cause verification to fail.

6.7.4 The record shall be kept so that an entry removed, changed or reordered shows on verification. A missing step shall read as incomplete, and a changed one as altered.

6.7.5 Neither the operator alone nor the vendor alone shall be able to rewrite the record.

6.7.6 Verification should be possible offline, free, and without an account.

6.7.7 Where coverage lapses, the lapse itself shall be recorded, with its start and end.

Note. Even silence is evidence: when coverage lapses, the lapse itself is sealed.

6.7.8 Records already made shall remain verifiable after the operator's relationship with any vendor ends, and after any licence lapses.

Note. A lapse creates a gap going forward, never backward.

6.7.9 A verification result shall state what it shows, and only what it shows: that the record is complete, signed and unchanged, by whom it was signed, when, and how the time was established. It does not establish that the underlying work is correct.

6.7.10 The operator should be able to hand any authorized party a sealed packet of the relevant records, which that party can check on their own machine, without seeing anything else the operator holds.

Note. 21 CFR 11.10(e) asks for secure, computer-generated, time-stamped audit trails that independently record operator entries and actions, and requires that record changes shall not obscure previously recorded information. The MHRA's GxP data integrity guidance asks that users should not be able to amend or switch off the audit trail. This clause asks the same of the record of an AI's actions, and adds that the check belongs to whoever receives the record.

Note, verification tools. The means of verifying a record can be made freely available to auditors, insurers, regulators and any other recipient, so that an outsider can check a record offline, on their own machine, without an account and without the vendor. This standard does not specify the technique by which a record is made verifiable.

6.8 Separation of the control from the AI

6.8.1 The control shall run outside the AI system it governs. The AI shall not be able to alter, disable, bypass or vote on the control, its rules or its record.

6.8.2 Nothing the AI sends to the control shall be able to change the authority, the control's rules or the record. Authority flows from the control to the AI, never the reverse.

6.8.3 Whether a consequential action proceeds shall be decided by the control, not by the governed system.

Note. The governed system does not get the final word on whether its own consequential action proceeds.

6.8.4 The control shall not depend on a library, setting or instruction that the AI, or the process in which the AI runs, can remove, decline to load, or override.

6.8.5 Controls over consequential actions shall not rely solely on prompts or on instructions given to the model.

6.8.6 Class 3 The control shall run in full architectural isolation under 7.3.

Note. An instruction to a model is part of the model's input. It can be drifted from, argued with or overwritten by later input. A control that the model can read but cannot reach is a different kind of control.

6.9 Data residency

6.9.1 Enforcement and the making of the record should not require the underlying work to leave the operator's environment.

6.9.2 Where the record is content-free under 6.6.9, it shall be possible to give it to a regulator, insurer or auditor, and for them to check what was held and why, without disclosing the underlying work.

Note. A content-free record can be shown to an outsider without betraying an insider.

6.9.3 Where an outside service is used for any part of the control or the record, such as independent evidence of time, the operator shall state which service, what it receives, and that the underlying content remains within the operator's environment.

6.9.4 The operator shall state where the record is held, and who holds the means to sign and verify it.

6.9.5 Class 3 Enforcement and the record shall not require any data to leave the deployment, under 7.3.9.

6.10 Actions between organizations

6.10.1 Where an action of an AI agent commits two or more organizations, each organization shall keep its own authority and its own control.

6.10.2 The commitment shall run only when each organization's control returns allowed at the final moment. Neither organization shall be able to commit for the other.

6.10.3 If a named person's authority on either side changes before commitment, the action shall not complete under the old authority.

6.10.4 Agreement by either organization's AI agent shall not be sufficient for a commitment. The commitment shall depend on the check of each organization's current authority.

Note. The other company's agent can press, and your own agent can still say yes. The commitment runs only when both companies return allowed at the final moment.

6.10.5 Both organizations shall hold the same record of the offers, refusals and approvals their agents exchanged. A missing step shall read as incomplete, and a changed one as altered.

6.10.6 An authorized auditor shall be able to check the complete record without logging into either organization's live system.

Example. A contract manufacturer's agent and the sponsor's quality agent are agreeing whether a batch can be released. Both authority checks return allowed. A deviation appears, and the sponsor's quality lead withdraws release authority. The same request runs again. The manufacturer's side remains allowed. The sponsor's agent still says yes, but the sponsor's control returns stopped, because current authority is gone. The joint release cannot commit.

6.11 Continuity and availability

6.11.1 When the control is unavailable, consequential actions shall hold. The deployment shall not continue unchecked on the ground that the control is down.

6.11.2 The deployment shall record a signed availability interval for every period in which the control was unavailable, together with what it refused or held during that period.

6.11.3 Every refusal and hold shall be linked to what followed it: approved afresh, abandoned, or the refusal confirmed by a named person. The operator shall be able to state the share of refusals that proved to be wrong refusals, and the value and hours they held.

6.11.4 The operator shall declare, for the control: the release it runs, who holds custody of its signing keys, its source of time, and the services it depends on. The declaration shall be kept current, so that a reader can tell how many deployments share one point of failure.

6.11.5 A change to the control itself shall be recorded under 6.12.

6.11.6 The operator shall test, at intervals it states in its attestation, that the control fails closed when it is silenced, crashed or removed, and shall record each test.

Note. A control that stops too much is a cost the operator and its insurer carry, as a control that stops too little is. Recording wrong refusals and availability makes both visible.

6.12 Change control

6.12.1 A change of model, of authority structure, of the control, or of the deployment's connections to the world shall be treated as a change to the environment.

6.12.2 A change to the model shall not be silent. Every change to the model or its parameters shall be authorized by a named person and recorded before the changed model acts, whether or not the change alters the model's name or version.

Note. Where the model is supplied as a service, the operator meets 6.12.2 by contract with the vendor and by detection where it can, and records which.

6.12.3 A change to the environment shall be made only by authorized personnel, in a controlled manner, under a defined procedure.

6.12.4 After a change to the environment, the operator shall confirm the deployment's class again under 9.3 before relying on its earlier attestation.

6.12.5 A change that adds a new path by which the AI can act shall not be used until that path passes through the boundary under 6.2.2.

Note. 21 CFR 211.68 requires controls over computer or related systems so that changes in master production and control records are made only by authorized personnel, and EU GMP Annex 11 asks that any change to a computerised system be made only in a controlled manner in accordance with a defined procedure. The model is part of the system.

7Requirements by class

7.1 Class 1, Foundation

Class 1 is the entry floor a buyer can verify, and the floor for internal deployments whose effects are reversible and fall on the operator alone. Behavioural drift is measured continuously, every governed decision produces a record built to support its use as evidence, and the provenance of every output is tracked from creation through delivery.

Drift measured continuously

7.1.1 Drift shall be measured continuously while the deployment operates, under 6.5, and a rise in drift shall be recorded when it occurs.

7.1.2 The measurement of drift shall itself be on the record, so that the record shows not only what was held but what the deployment was measuring when it held it.

A record built to support its use as evidence

7.1.3 Every governed decision shall produce a record built to support its use as evidence: made at the time, attributable to a named person, complete under 6.6, and verifiable by an outsider under 6.7.

7.1.4 The record shall exist from the time of the decision. It shall not need to be assembled, exported or reconstructed in order to answer a question from a regulator, insurer, auditor or court.

Provenance from creation through delivery

7.1.5 The provenance of every consequential output shall be tracked from creation through delivery: which AI system produced it, in which tool, at what time, under whose authority, and what a person chose to do about it.

7.1.6 The record of how an output was produced shall be kept separate from the record of whether a person reviewed it.

Note. Production and review are different questions. The first is how the output was produced. The second is whether a person checked it.

7.1.7 Where a person reviews an output before it is released, the record shall show what AI was used for, what the reviewer checked, who signed, and when. Where a person approves exact words, the approval shall be sealed with the words.

7.1.8 Where a person decides to keep or remove what the AI produced, that choice shall be recorded as its own record. No keep or remove decision shall be made without a record of it.

Note. The system never decides silently.

7.1.9 Provenance shall be stated in words that a reader can check, never as a percentage or probability that the evidence cannot support.

Note. A production record with no review is a publishing credential. A review log with no production record is a signature on an unexamined origin. Class 1 asks for both.

7.2 Class 2, Intermediate

Class 2 is for regulated industry, clinical decision support, financial automation and legal AI inside firms. It adds continuous operator attestation and runtime proof. The operator attests, the system measures itself, and both seal into the same decision.

7.2.1 All Class 1 requirements apply.

Continuous operator attestation

7.2.2 The operator shall attest continuously that the deployment runs under the authority recorded for it. The attestation shall be signed by a named person accountable for the deployment, and shall be renewed whenever the authority register, the class or the environment changes.

7.2.3 The operator's attestation in force at the moment of each governed decision shall be identifiable from the record of that decision.

Runtime proof

7.2.4 The deployment shall produce proof of its own state while it runs. The proof shall be produced as a by-product of running the AI, not as a report assembled afterwards.

7.2.5 The operator's attestation and the runtime proof shall be sealed into the same decision record, so that each governed decision shows both what the operator attested and what the system measured at that moment.

7.2.6 Authority shall be treated as current only while runtime proof of the required state is arriving. When the proof lapses, authority shall be treated as unconfirmed, consequential actions shall hold, and the lapse shall be recorded under 6.7.7.

7.2.7 A consistent record shall show that the monitored state remained within the conditions being recorded. A change in the record shall show when the monitored state moved outside those conditions.

7.2.8 The runtime proof shall be produced within the operator's environment, without an outbound call being required.

Measured reporting

7.2.9 The operator shall be able to report, for any period, from the record: the trend of drift; the number of holds and stops and how each was resolved; the share of wrong refusals under 6.11.3; the availability intervals under 6.11.2; and the stopping distance of every withdrawal under 6.4.5.

Example. A payments agent is paying an approved invoice under the authority of a named finance director, and that authority stays live only while proof of the deployment's state keeps arriving. The proof goes quiet, and every action stops. Authority could not be confirmed. No payment ran. The stop is written to the record as it happens.

7.3 Class 3, Cleanroom

Class 3 is the highest floor, for physical AI, AI in a patient's care pathway, defence, export-controlled and sovereign deployments. The full control runs in architectural isolation. Nothing is required to leave the deployment, and the verifying body is not employed by the operator.

7.3.1 All Class 2 requirements apply.

Architectural isolation

7.3.2 The control shall run in architectural isolation from the AI it governs: no shared memory, no shared process, and no shared storage, communicating in one direction only.

7.3.3 One direction means that authority and decisions flow from the control to the AI, and nothing flows from the AI to the control except a description of the requested action sufficient to check it. Nothing the AI sends shall be capable of changing the control, its rules or its record.

7.3.4 Every message crossing the boundary shall be authenticated and checked for integrity where it is received. A message that fails its check shall end the session and be recorded. It shall never be silently discarded.

7.3.5 The isolation shall be architectural. Placing the AI and the control in separate software packages, containers or sandboxes does not by itself meet this requirement, unless the conditions of 7.3.2 hold between them.

7.3.6 A breach of isolation shall cause a safe halt. The halt shall be latched under 6.3.5, recorded with its reason, and released only when a named person re-arms it after the isolation is restored.

Isolation monitored continuously

7.3.7 Isolation shall be monitored continuously. The deployment shall count and record every isolation breach: any access across the separation, any message at the boundary that fails its integrity check, and any message delivered without authentication.

7.3.8 For any period, the record shall show either that no isolation breach occurred, or each breach that occurred with the safe halt that followed it.

Nothing required to leave the deployment

7.3.9 Enforcement, the making of the record, runtime proof and verification shall all run inside the deployment, and shall not require any data to leave it. Records leave only as a sealed packet the operator chooses to release (7.3.11).

7.3.10 The deployment shall continue to enforce, record and prove its state with all outbound connections blocked.

7.3.11 Where the record is handed to an outside party, it shall be handed as a sealed packet the operator chooses to release, and its verification shall not require any connection back into the deployment.

Independent verification

7.3.12 Conformance shall be verified by a body that is not employed by the operator, under 8.4.

Note. Isolation is monitored as a cleanroom's air is monitored. The judge is not employed by the defendant. Class 3 applies that rule twice: to the control, which does not share a room with the AI it governs, and to the verifier, which does not share a payroll with the operator it checks.

7.4 Summary of requirements by class

The table summarizes where each group of requirements applies. A filled mark means the requirement applies. Where a class strengthens a common requirement, the strengthening clause is named.

8Demonstrating conformance

8.1 General

8.1.1 For Class 1 and Class 2, the operator self-attests conformance. The attestation shall be signed, and any third party shall be able to verify it.

8.1.2 For Class 3, conformance shall be verified by an independent body under 7.3.12 and 8.4, in addition to the operator's attestation.

8.1.3 The attestation and the records behind it shall be verifiable by any party to whom the operator gives them, including a buyer, an insurer, an auditor, a regulator or a court.

8.1.4 Conformance shall be tested by the methods in Annex E. The operator shall apply each method that applies to its class before it first attests, and the verifier under 8.4 shall apply them for Class 3.

Note 1. The floor is public, the proof is portable, and the check belongs to whoever the operator hands it to: a buyer, an insurer, an auditor, a regulator or a court.

Note 2. The author of this standard does not audit deployments against it.

8.2 Self-attestation

8.2.1 The attestation shall contain at least:

• the name of the operator and of the deployment, and a description of the deployment sufficient to identify its environment and boundary;
• the class claimed, the version of this standard, and the date from which the attestation runs;
• the consequence assessment and the named person who chose the class (5.3.4);
• the paths by which the AI can act, and a statement that each passes through the boundary (6.2.2);
• the authority register, or a reference to where it is held and who may inspect it (6.1.9);
• the normal operating procedure, and the point at which earlier approvals lapse for drift, or a reference to where they are held (6.5);
• the limits set on bounded correction (6.3.9);
• where the record is held, who holds the means to sign it, and how an outsider verifies it (6.7, 6.9.4);
• any outside service used and what it receives (6.9.3);
• the declaration of the control's release, key custody, source of time and dependencies (6.11.4);
• the intervals at which fail-closed behaviour is tested, and the date of the last test (6.11.6);
• for Class 3, the identity of the independent verifier and the date and scope of its last verification (8.4);
• the named person who signs the attestation, and the meaning of the signature.

8.2.2 The attestation shall be signed by a named person accountable for the deployment. It shall be verifiable by anyone who receives it, under the same conditions as the record (6.7).

8.2.3 An attestation states what the operator declares. Its evidence level is self-declared. It shall not be presented as having been verified by anyone else unless it has been.

8.2.4 Class 2 The attestation shall be continuous under 7.2.2, and the attestation in force shall be identifiable from each decision record.

8.2.5 The operator shall withdraw or amend its attestation when the deployment no longer meets the class attested, under 9.4.

8.3 What an outside verifier checks

Any party that receives an attestation and the records behind it can check the following. None of these checks requires the vendor's cooperation.

8.3.1 The attestation. That it is signed by the named person it identifies, that it is unchanged, and that it states each item in 8.2.1.

8.3.2 The record holds. That a sample of records, or all of them, verify; that a deliberately altered copy fails verification; and that no entry is missing from the span examined.

8.3.3 The seven fields. That each sampled record carries all seven fields of 6.6.2, with none of the evidence that does not count offered in place of a field.

8.3.4 Named persons. That every authority in the sample traces to a named person, and none to a service account, key, role or shared login.

8.3.5 Withdrawal. That, for each withdrawal in the span, actions reaching the boundary afterwards were held, and the stopping distance is stated under 6.4.5.

8.3.6 Fail closed. That the record of fail-closed tests under 6.11.6 shows the control going to a safe stop when silenced, crashed or removed, and staying stopped until re-armed by a named person. A verifier may ask to witness such a test.

8.3.7 Holds and re-arms. That every hold in the span was resolved by a named person, and that no hold was released by the AI.

8.3.8 Drift. That drift was measured across the span, that the lapse point was set in advance, and that actions past it were re-approved before taking effect.

8.3.9 Absence. That the record supports a record of absence for the span: no action took effect outside current authority.

8.3.10 Availability and wrong refusals. That availability intervals and wrong refusals are recorded for the span.

8.3.11 Changes. That each change to the environment in the span was authorized, recorded and followed by confirmation of class.

Note. Take a sealed record, check it on your own machine, then change a single character and watch verification fail. That one test tells a reader more about a record than any description of it.

8.4 Independent verification for Class 3

Who may verify

8.4.1 Independence. A Class 3 deployment shall be verified by a body that is not employed by the operator, is not owned by or under common ownership with the operator or the deployment's vendors, and has not designed, built, operated or supplied the deployment or its control.

8.4.2 Payment. The verifier's fee shall not be contingent on the outcome of the verification.

8.4.3 Competence. The verifier shall have demonstrated competence in the sector in which the deployment operates, in assessing AI systems and their controls, and in the verification of records under 6.7. The verifier shall keep a record of the competence of each person who performs the verification.

8.4.4 Method. The verifier shall work to a documented method that applies the test methods of Annex E for Class 3. The method shall be available to the operator before the verification, and shall be identified in the report.

8.4.5 Impartiality. The verifier shall disclose any relationship with the operator or its vendors, shall identify and record any threat to its impartiality, and shall not verify a deployment where a threat to impartiality cannot be removed.

8.4.6 Confidentiality. The verifier shall keep confidential the information it obtains in the verification, except as needed for its report or as required by law, and should rely on content-free records under 6.6.9 wherever they are sufficient.

What the verifier does

8.4.7 The verifier shall perform every check in 8.3, and in addition shall examine the architecture against 7.3.2 to 7.3.5, the isolation monitoring record under 7.3.7 and 7.3.8, and the deployment's operation with outbound connections blocked under 7.3.10.

8.4.8 The verifier shall issue a signed and dated report stating the scope of the verification, the version of this standard, what was examined, what was found, and the period the verification covers. The report shall be verifiable by anyone who receives it.

8.4.9 Verification shall be repeated at intervals stated in the attestation, and after any change to the environment that affects isolation, data residency or the boundary.

Note 1. This mirrors the direction of travel in law. From 1 January 2029, California AB 1405 permits only a registered AI auditor meeting standards of independence, objectivity and integrity to conduct a covered AI audit, with a signed and dated statement to the auditee. NYDFS Circular Letter No. 7 asks insurers to secure audit rights or audit reports by qualified auditing entities for vendors' systems.

Note 2. Conformity-assessment frameworks set comparable expectations of independence, impartiality, competence, documented method and confidentiality. ISO/IEC 17020, which sets requirements for bodies performing inspection, is one example. A verifier that operates under such a framework may use it to show that it meets 8.4.1 to 8.4.6.

8.5 Evidence an insurer or regulator can request

An operator that conforms can produce, on request and from the record, the following evidence. The list states what can be asked for. It is not a score, a certification or a price; the insurer prices its own risk, and the regulator makes its own determination.

8.6 Statements of conformance

8.6.1 A statement that a deployment conforms to this standard shall name the class, the deployment, the version of this standard and the date, under 5.5.1, and shall be backed by a current attestation.

8.6.2 A statement of conformance to this standard is a statement about the deployment's controls and its evidence. It shall not be presented as a statement that the deployment complies with any law, regulation or other standard, or that any decision made by the AI was correct.

8.6.3 A class shall not be stated for an organization, a product or a model in general, under 5.5.2.

8.6.4 Where a Class 3 statement is made, it shall name the independent verifier and the date of the last verification.

Note. The record supplies the evidence. The insurer, the auditor, the regulator or the court makes the determination.

9Monitoring, incidents and reclassification

9.1 Conformance is continuous

9.1.1 Conformance shall be maintained continuously, not shown at a single point in time.

Note. Conformance is continuous, not a point in time. A cleanroom is certified and then monitored. So is an AI deployment.

9.1.2 The operator shall monitor, continuously and from the record: that every consequential action passes the boundary; drift; holds, stops and re-arms; withdrawals and their stopping distances; availability; wrong refusals; and, for Class 3, isolation.

9.1.3 The operator shall review the monitoring record at intervals it states in its attestation, and the review shall itself be recorded, with the named person who made it.

9.1.4 The operator shall repeat the test methods of Annex E that apply to its class at the intervals stated in its attestation, after any incident under 9.2, and after any change under 9.3, and shall record each result.

9.2 Incidents

9.2.1 Each of the following is an incident under this standard:

• a consequential action took effect outside current authority, or its authority cannot be established;
• a path by which the AI could act was found not to pass through the boundary;
• the control failed open, or a hold or stop was released other than by a named person;
• a record failed verification, or an entry was found missing;
• the control was unavailable and actions did not hold;
• the model or the environment changed without authorization or record;
• Class 3 an isolation breach, or data leaving the deployment.

9.2.2 On an incident, affected actions shall be held or stopped, the incident shall be recorded when it is found, with what is known and what is not, and a named person shall decide what happens next. The deployment shall be re-armed only by a named person, on the record.

9.2.3 The operator shall determine, from the record, the actions affected, their stopping distance and their value, and shall record the cause where it can be established and the correction made.

9.2.4 The operator should inform those who rely on its attestation, such as buyers and insurers, of an incident that affects the class, within a period agreed with them. Where law requires incidents to be reported to an authority, this standard does not change that duty.

9.2.5 An incident record shall never be deleted or rewritten. It may be added to as more becomes known.

9.3 Confirming the class after change

9.3.1 A change of model, of authority, of the control, or of the deployment's connections to the world shall be treated as a change to the environment, and the deployment's class shall be confirmed again.

9.3.2 Confirmation shall check, at least, that every path still passes the boundary, that fail-closed behaviour still holds, that the record still verifies, and that the consequence assessment under 5.3 still points to the same class. The checks shall use the test methods E.1, E.2 and E.6 of Annex E, and E.10 for Class 3.

9.3.3 Where a change raises the consequence of the deployment's actions, the operator shall choose the class again under 5.3 before the changed deployment acts.

9.3.4 Class 3 A change that affects isolation, data residency or the boundary shall be verified again by the independent verifier under 8.4.9.

9.4 Operating below the attested class

9.4.1 A deployment that no longer meets its class shall record that fact, and shall operate at the class it does meet until the requirement is restored.

9.4.2 Where a deployment no longer meets the class its consequence requires under 5.3, the actions that require the higher class shall hold until the requirement is restored.

9.4.3 The operator shall amend its attestation to state the class the deployment meets, the date from which it fell below the attested class, and the date on which the class was restored.

9.4.4 A deployment that no longer meets Class 1 shall not state any class under this standard until Class 1 is restored.

9.5 Keeping the record

9.5.1 The monitoring record, incident records and every attestation, including attestations withdrawn or amended, shall be kept and remain verifiable under 6.6.11 and 6.7.8.

9.5.2 When a deployment is retired, its record shall remain verifiable for the retention period. A change of vendor shall not affect the operator's ability to hold and verify the record.

Annex A (informative)
The cleanroom and the AI deployment, side by side

This annex sets the concepts of controlled environments, as ISO 14644 and USP Chapter 797 express them, beside their counterparts in this standard. The comparison explains the requirements. It does not add to them.

Annex B (informative)
How the classes relate to the rules and standards you already run under

Each row maps an obligation in an established framework to the clause of this standard that produces relevant evidence, and to the lowest class whose evidence is relevant. The mapping identifies evidence capabilities that may support those frameworks. It does not establish conformance with the framework itself, and it does not state a legal conclusion. The determination is always made by the regulator, auditor, insurer or court concerned.

Note 1. The class shown is the lowest class whose evidence bears on the obligation. It is not the class a deployment under that rule should choose. That is chosen by consequence under 5.3, and a deployment in a regulated process will usually be Class 2 or higher.

Note 2. Where a rule requires a person to agree with each decision before action is taken, the operator sets the scope of authority so that each such decision holds for a named person (6.3.2). The record then shows who agreed, and when, for every decision.

B.1 Life sciences and medicines manufacturing

B.2 AI law and AI management standards

B.3 Insurance and financial services

B.4 Employment, professions and independent audit

B.5 Security frameworks

B.6 International and United Kingdom guidance

Note 3. Dates and status are as stated in the primary documents named in the Bibliography. Under Regulation (EU) 2026/1744, the high-risk obligations of the EU AI Act, including Articles 9, 12, 13, 14 and 15, apply from 2 December 2027 for stand-alone high-risk systems and from 2 August 2028 for high-risk systems embedded in products. Draft Annex 22 is a consultation draft and is not in force.

Annex C (informative)
Why this standard exists

This annex is the author's account.

The people who carried it. Eric Kastango and Lou Diorio, who lent USP 797 their standing before it had any of its own, and NuAire, whose flow hoods took it into the field.