Compliance and audit
How the signed, per-decision record maps to what the EU AI Act, ISO/IEC 42001, and the NIST AI RMF ask you to produce.
Sooner or later someone outside your team asks you to prove why an agent did what it did. A regulator, an internal auditor, a customer's security review, a court. The frameworks they bring differ, but the thing they ask for is the same: evidence, per decision, that you knew what the system was doing and could intervene.
AISquare's answer is the decision record. This page lays out what that record contains and maps it to the three frameworks that come up most often: the EU AI Act, ISO/IEC 42001, and the NIST AI RMF.
What every governed decision leaves behind
Once an agent is connected, every run produces the same set of artifacts, whether anyone is watching or not:
- The reasoning graph. The claims the agent made, the evidence behind each one with its confidence, the assumptions it filled in, and the inference chain that connected them. See Understand.
- Policy verdicts. Each action passed or blocked against a named rule, with the citation attached. Proof that governance ran is part of the record, not a transient log line. See Prevent.
- Corrections. When a reviewer fixes a decision, the correction is written back as durable context, with who changed what. See Fix.
- A signed, tamper-evident audit record for the run, including an AIBOM (AI Bill of Materials) listing the models and tools involved, persisted as enterprise memory you can query and replay. See Remember.
Sensitive data is handled before any of this is stored: detected PII, PHI, and PCI is screened at connection time (redacted when your data policy is set to mask), and memory is scoped to your workspace.
The evidence layer, not a certificate
No tool makes you compliant. Compliance is a property of your organization, its processes, and its people. What AISquare removes is the scramble: when an auditor asks for evidence, the record already exists, structured, per decision, from the day the agent was connected.
EU AI Act
For high-risk AI systems, the EU AI Act requires, among other things, that the system keeps automatically generated logs over its lifetime (Article 12), that it is transparent enough for the people operating it to understand and use its output (Article 13), and that it remains under effective human oversight, including the ability to intervene or interrupt (Article 14). Deployers carry their own obligations, including retaining those logs.
| The Act asks for | The record provides |
|---|---|
| Automatic, lifetime logging of operation (Art. 12) | Every run recorded as a trace with per-step model, tool, latency, and cost, kept as durable enterprise memory |
| Output the operator can interpret (Art. 13) | The reasoning graph readable as a flow diagram, a graph, or a plain-English narrative, not a raw transcript |
| Effective human oversight with the ability to intervene (Art. 14) | Policy gates that allow, deny, escalate, or modify before an action runs, plus in-place corrections kept on the record |
| Reconstruction after an incident | Any decision reopened with its claims, evidence, assumptions, and the rule that fired, and replayed |
ISO/IEC 42001
ISO/IEC 42001 certifies an AI management system. An auditor working through it needs two things from your tooling: documented controls, and records showing those controls actually operate. Both are what the decision record is.
| The audit asks for | The record provides |
|---|---|
| Documented, operating controls | Policies enforced at the decision point, each verdict citing the named rule it ran against |
| Evidence of monitoring and measurement | Per-decision traces with confidence signals, including the confidence of the reasoning extraction itself |
| Corrective action and continual improvement | Reviewer corrections written back as durable context, so the fix is provably in force on later runs |
| Records management | A signed, tamper-evident record per decision, scoped to the workspace and queryable after the fact |
NIST AI RMF
The NIST AI Risk Management Framework is organized around four functions. The Trust Loop lines up with them directly:
| Function | Where it lands in AISquare |
|---|---|
| Govern | Decision-level policies with named rules, workspace scoping, and an accountable record of every intervention |
| Map | The reasoning graph documents how the system actually behaves in context: what it relied on and what it assumed |
| Measure | Confidence on every piece of evidence, extraction confidence per decision, and per-step cost, latency, and tokens |
| Manage | Prevent blocks the bad action, Fix corrects the one that happened, Remember carries the outcome forward |
Answering an audit, concretely
A compliance lead asks: "Show me every automated refund above $25 last quarter, the rule that approved each one, and any human correction along the way."
Without a decision record, that is weeks of transcript archaeology. With one,
it is a query: each refund decision carries its policy verdict
(refund-auto-approve, pass, with citation), its evidence and confidence, and
any reviewer correction, all on the same graph. A
Studio report built on those decisions is auditable
by construction, because every figure traces back to the verdicts that
produced it. The proving was done when the decisions were governed, not when
the question arrived.