Compliance Mapping

READ THIS FIRST

This page is engineering documentation, not legal advice and not an audit opinion. Query Fanout is a logging and evidence tool. Using it does not by itself satisfy the EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2, or any other law, framework, or standard, and Query Fanout holds no certification, attestation, or SOC 2 report. Whether a record is sufficient for a given obligation depends on your system, your role (provider or deployer), your processes, and your assessor. Confirm with your counsel and your auditor.

EU AI ACT

Articles 12, 19 and 26 apply to high-risk AI systems (Art. 6 and Annexes I and III). Many agents are not high-risk; check classification first. Under Regulation (EU) 2026/1744 the high-risk obligations apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.

Art. 12(1) High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.

FEATURE: /evidence and /policy/evaluate decisions are written automatically (audit defaults to on) to an append-only, hash-chained, Ed25519-signed ledger record with an audit_id.
HOW IT HELPS: Supports automatic event recording for the agent decisions that pass through Query Fanout. It does not log anything that bypasses it, or requests sent with audit: false.

Art. 12(2) (summarised) logging capabilities shall enable the recording of events relevant for (a) identifying situations that may result in risk or in a substantial modification, (b) facilitating post-market monitoring under Art. 72, and (c) monitoring the operation under Art. 26(5).

FEATURE: Records hold the query, sources, policy version, policy reasons, and outcome. GET /audit search and GET /audit/{id}/replay re-run the recorded policy on the recorded evidence.
HOW IT HELPS: Helps produce evidence for traceability reviews and for investigating a specific decision.

Art. 19(1) providers shall keep the logs automatically generated by their high-risk AI systems, to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law

FEATURE: Per-tenant retention schedule with a configurable floor (QUERY_FANOUT_AUDIT_RETENTION_MIN_DAYS, default 180 days); legal holds that block expiry; signed tombstones so the chain still verifies after a payload expires.
HOW IT HELPS: Supports keeping logs for at least six months and documenting when and why a payload was removed. You choose the period that fits your purpose and any other applicable law.

Art. 26(6) (summarised) deployers shall keep the logs automatically generated by the high-risk AI system, to the extent such logs are under their control, for a period appropriate to the intended purpose, of at least six months.

FEATURE: Same retention and legal-hold controls, scoped per tenant. Signed evidence packs (GET /audit/evidence-pack) let you keep your own copy.
HOW IT HELPS: Supports a deployer’s log-keeping, including copies held outside our servers.

Art. 26(5) (summarised) deployers shall monitor the operation of the high-risk AI system on the basis of the instructions for use.

FEATURE: Read-only auditor role, auditor workspace, search by agent, run, policy action, and time range.
HOW IT HELPS: Helps produce evidence that operation was reviewed. The monitoring process itself is yours.

Art. 19(1) (cont.) in particular in Union law on the protection of personal data

FEATURE: Email, phone, card, and SSN-shaped values are redacted before anything is written (on by default).
HOW IT HELPS: Supports data minimisation in the logs you are required to keep.

Not covered by Query Fanout: risk classification, the risk management system (Art. 9), technical documentation (Art. 11), human oversight design (Art. 14), quality management (Art. 17), conformity assessment, and serious-incident reporting.

Sources: Regulation (EU) 2024/1689 (Artificial Intelligence Act), OJ L, 12.7.2024; Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending the AI Act's application dates. Quoted article text is from Regulation (EU) 2024/1689 as published; check the consolidated text for later amendments.

NIST AI RMF 1.0

The AI RMF is voluntary. NIST notes its actions “do not constitute a checklist”.

MEASURE 2.4 The functionality and behavior of the AI system and its components – as identified in the map function – are monitored when in production.

FEATURE: Signed ledger record for every gated decision; dashboard metrics; search API.
HOW IT HELPS: Helps produce evidence for production monitoring of the agent’s answer/escalate decisions.

MEASURE 2.8 Risks associated with transparency and accountability – as identified in the map function – are examined and documented.

FEATURE: Replay shows what the agent saw, which policy ran, and why it answered or escalated.
HOW IT HELPS: Supports documenting accountability for individual decisions.

GOVERN 2.1 Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization.

FEATURE: admin, writer, and auditor roles; SSO email/domain-to-role mappings; key and mapping changes recorded as ledger events.
HOW IT HELPS: Helps produce evidence of who could do what, and when that changed.

MANAGE 4.1 Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.

FEATURE: Ledger records, replay, and legal holds.
HOW IT HELPS: Supports the record-keeping part of a monitoring plan. The plan itself is yours.

MANAGE 4.3 Incidents and errors are communicated to relevant AI actors, including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented.

FEATURE: Legal holds on a tenant, agent, or run; evidence packs an outside party can verify offline with qf-verify.
HOW IT HELPS: Helps produce evidence for incident tracking that a third party can check.

Sources: NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023; NIST AIRC, AI RMF Core (functions, categories, subcategories).

ISO/IEC 42001:2023

ISO/IEC 42001 specifies an AI management system. The standard is copyrighted, so requirements below are named by clause or control and paraphrased; read your licensed copy for the exact text.

Annex A, control A.6.2.8 “AI system recording of event logs” (paraphrased: decide in which life-cycle phases event logging is enabled, at minimum while the AI system is in use).

FEATURE: Automatic, signed, hash-chained ledger records while the agent is in use.
HOW IT HELPS: Supports event logging during operation.

Clause 7.5 “Documented information” (paraphrased: documented information is controlled, including protection against loss of integrity).

FEATURE: Append-only database triggers, hash chain, signatures, Merkle checkpoints, and optional RFC 3161 timestamps.
HOW IT HELPS: Helps produce evidence that log records were not changed after the fact.

Clause 9.2 “Internal audit”.

FEATURE: Read-only auditor role, evidence packs, and offline verification with qf-verify.
HOW IT HELPS: Supports auditors who need to check records without trusting our servers.

Source: ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system.

SOC 2 (AICPA TRUST SERVICES CRITERIA)

A SOC 2 report is an auditor’s opinion on your controls. Query Fanout can be one of the systems those controls rely on; it holds no SOC 2 report of its own.

CC6.1 The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity’s objectives.

FEATURE: Tenant-scoped API keys; self-serve keys stored only as SHA-256 hashes; OIDC single sign-on with signed, httpOnly session cookies and CSRF checks; Postgres row-level security per tenant (Postgres backend).
HOW IT HELPS: Supports your logical-access controls for the audit data.

CC6.2 Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.

FEATURE: Admins create named keys with a role and expiry, shown once; revoke at any time; SSO users get access only through an explicit email or domain mapping, re-checked on every request.
HOW IT HELPS: Helps produce evidence of credential issue and removal (each is a ledger event).

CC6.3 The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives.

FEATURE: Separate admin / writer / auditor roles; auditors cannot write decisions.
HOW IT HELPS: Supports least privilege and segregation of duties for audit data.

CC7.2 The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.

FEATURE: GET /audit/verify and qf-verify detect changed, removed, or reordered records; the query-fanout-audit-admin daily checkpoint-and-timestamp job.
HOW IT HELPS: Helps produce evidence for monitoring the integrity of the decision log.

PI1.5 The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity’s objectives.

FEATURE: Each record commits to its inputs, sources, policy, and outcome by hash; inclusion and consistency proofs.
HOW IT HELPS: Supports showing that stored decision records are complete and unchanged.

Source: AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus — 2022).

LIMITS

Only decisions sent through Query Fanout are recorded.
Tamper-evident is not tamper-proof: whoever holds the signing key and the database could rebuild history. External timestamps and checkpoints you keep yourself are what make that detectable.
Timestamp certificates are checked offline; revocation (CRL/OCSP) is not checked.

See how the ledger works and the API docs.

SOURCES

Last reviewed: October 2026