Runtime evidence
How proof works
Governance tools approve AI for production. Quantlix produces operating-effectiveness evidence — tamper-evident, time-stamped records that controls actually fired on live traffic. Quantlix does not declare conformity; it produces the evidence an auditor relies on to assess it.
The seven evidence artifacts
The same evidence base serves whichever management system the control sits under — SOC 2 (Trust Services Criteria), ISO 27001, 27701, 31000, 42001, GDPR, ISO 22301, or the EU AI Act. The standard changes; the underlying record does not.
1. Hash-chained trace store
Every request produces a trace capturing the full lifecycle: input (post-redaction), model and parameters, each policy decision and verdict, output, latency, cost, and provider. Records append to a per-tenant ledger where each entry carries a digest of the prior entry. Segments anchor to the public Sigstore Rekor transparency log so a third party can verify integrity without trusting Quantlix.
Serves: ISO 27001 logging controls · EU AI Act Art. 12 · SOC 2 A1
2. Enforcement records
Each request generates an enforcement record: which policy version was in force, which rules were evaluated, the verdict, and the reason. The policy version is pinned to each decision — not reconstructed afterward. Records are filterable by verdict, rule, policy, date, deployment, and environment.
Serves: ISO 27001 · ISO 31000 · EU AI Act Art. 9 · SOC 2 CC7.1–7.2 / CC8.1 / PI1
3. Redaction / PII events
When the boundary detects personal data, it records what category was detected, what action was taken, and at what latency — without retaining the PII itself. Per-rule evidence that data-minimisation controls fired on live traffic.
Serves: ISO 27701 · GDPR · EU AI Act Art. 10 · SOC 2 C1
4. Provider & model attribution
Every call records the provider and model that served it, with per-deployment activity rollups. When a request fails over from its primary provider, a failover event records the primary and fallback provider and the reason on the request trace.
Serves: ISO 27001 supplier controls · ISO 22301 · SOC 2 A1
5. Approval-gate & human-oversight records
Where a workflow routes a decision to a human, the approval or rejection is logged with user identity, timestamp, and the request it applies to. Role-based access governs who may approve, override, or stop a deployment; stop events log the actor, timestamp, and reason.
Serves: ISO 42001 · EU AI Act Art. 14 · SOC 2 PI1
6. Eval & adversarial-detection records
Eval suites run on deployment candidates and in production; a candidate that regresses below threshold is blocked, and the result (pass/fail, suite version, scores) is logged. At the request boundary, prompt-injection and jailbreak detections are logged with the rule and confidence signal.
Serves: ISO 42001 · EU AI Act Art. 15 · SOC 2 CC7.2
7. Exportable audit bundle
On demand, Quantlix composes a manifest-led bundle in PDF, CSV, or JSON containing policy configuration, enforcement logs, redaction evidence, provider activity, change history, an AI-register extract, attestations, and a coverage statement — each stamped with catalogue version and policy versions in force. Bundles are framework-scoped: an EU AI Act view, or a SOC 2 view that adds a criterion-mapping section citing which bundle sections back which Trust Services Criteria. Exports ship with HOW_TO_VERIFY.txt, bundle.json, and verify_audit_bundle.py.
Serves: The audit deliverable — independently verifiable by external reviewers
How does a reviewer verify a bundle without a Quantlix account?
PDF and CSV audit-bundle exports ship as zip files. Each zip includes bundle.json, HOW_TO_VERIFY.txt, and the standalone verify_audit_bundle.py script — the strongest enterprise signal: a reviewer can confirm manifest digest and Rekor anchors without a Quantlix account.
- Unzip the export (PDF or CSV format) — you receive bundle.json, HOW_TO_VERIFY.txt, verify_audit_bundle.py, and audit_bundle_verify_lib.py.
- Run python verify_audit_bundle.py bundle.json — checks manifest content digest and internal integrity references.
- When Rekor UUIDs are present, the script confirms segment Merkle roots match public Rekor log entries (or use --offline with embedded rekor_entry_b64 snapshots).
- Without Quantlix software: open each Rekor lookup URL from HOW_TO_VERIFY.txt and confirm spec.data.hash.value matches the segment Merkle root in the manifest.
pip install httpx unzip audit-bundle.zip python verify_audit_bundle.py bundle.json python verify_audit_bundle.py bundle.json --json python verify_audit_bundle.py bundle.json --offline
Verification checks internal consistency of the exported bundle and, when Rekor anchors are present and passing, public-log anchoring of listed segment Merkle roots. It does not prove completeness of your AI estate (see the Coverage section) and is not a compliance assessment. To prove the artifact has not changed since export, compare manifest.content_digest with a trusted external copy. A passing digest check alone does not prove completeness, compliance, or authenticity of the export source.
Full trace-integrity details: Trust center → Trace integrity · Verify an audit bundle
Which standards does the evidence serve?
Quantlix is not an "AI Act tool" alone. The evidence maps across the standards your integrated management system already uses — so risk, security, privacy, and audit teams can justify it in their own frameworks.
| Evidence type | Status | Standard fit |
|---|---|---|
| Policy enforcement at runtime | Evidenced | 27001 / 31000 / 42001 / TSC CC7.2 · PI1 |
| Request & response logging | Evidenced | 27001 / AI Act Art. 12 / TSC A1 |
| PII detection & redaction | Evidenced | 27701 / GDPR / TSC C1 |
| Provider attribution per call | Evidenced | 27001 supplier mgmt |
| Provider failover / availability | Evidenced | 27001 / 22301 / TSC A1 |
| Adversarial input detection | Evidenced | 42001 / AI Act Art. 15 / TSC CC7.2 |
| Eval-gated promotion | Evidenced | 42001 / AI Act Art. 15 |
| Approval-gate decisions | Evidenced | 42001 / AI Act Art. 14 / TSC PI1 |
| Deployment stop control | Evidenced | 42001 / AI Act Art. 14 / TSC CC7.3–7.5 inputs |
| Reviewer access & activity | Evidenced | 27001 access control |
| AI system inventory / estate | Partial — register evidenced, completeness attested | 42001 / AI Act Art. 26 |
| Organisational risk process | Requires attestation | 31000 / 42001 / TSC CC3 · CC9 |
| Training-data governance | Out of scope (upstream of runtime) | — |
| Conformity assessment | Out of scope (qualified body, not a platform) | — |
Evidenced vs. attested — the honesty boundary
Quantlix is explicit about what runtime data can and cannot prove. Obligations backed by stored traffic are marked evidenced; obligations that need a human statement (estate completeness, organisational process, documentation completeness) are marked requires-attestation, with an owner and review date. An obligation only moves to the evidenced side when a stored field backs it.
We produce the evidence; your advisor, auditor, or notified body renders the judgment. Quantlix does not declare anyone "compliant" or "safe."
The in-product obligations map carries both EU AI Act and SOC 2 (TSC) views. For the EU AI Act side in depth: EU AI Act readiness evidence
SOC 2: evidence for the AI-runtime slice
Auditors increasingly ask what AI systems an organisation runs and what controls operate on them — and most teams have nothing runtime-grade to show. Quantlix produces the runtime evidence for the AI-runtime slice of a SOC 2 examination: the gatewayed AI traffic your readiness platform cannot see. A Type II examination samples evidence across an observation window — runtime evidence accrues in real time and cannot be backfilled, so the window you can cover starts when the gateway does.
The SOC 2 view of the obligations catalogue maps nine Trust Services Criteria to stored evidence, honesty-tagged the same way as everything else: runtime-evidenced where a stored field backs the criterion (boundary enforcement → CC6.6–6.7, monitoring → CC7.1–7.2, change management → CC8.1, processing integrity → PI1, confidentiality → C1), mixed where runtime records meet an attested process (incident management, availability), and requires-attestation where the judgment is organisational (the access review, risk and vendor programs). A SOC 2 audit bundle adds a criterion-mapping section — criterion, honesty tag, backing sections, and the evidence rows in the bundle — that a CPA firm's workpapers can cite directly, with the same independent verification as any bundle (the standalone verifier ships in every CSV and PDF export).
The boundary is stated in the artifact itself: HR and personnel controls, endpoint management, physical security, business continuity programs, organisation-wide vendor management, and the Privacy category are outside Quantlix's evidence scope. SOC 2 scopes an entire service organization; Quantlix is an evidence source for the AI-runtime slice — your readiness platform and auditor cover the rest. Quantlix evidences; only a licensed CPA firm can attest under AICPA standards, and every SOC 2 bundle carries that statement on its cover.
Full criterion-by-criterion reference: SOC 2 runtime evidence
Sample audit bundle & enterprise pilot
Download an illustrative bundle JSON to inspect structure, section layout, and manifest fields. Synthetic data only — not exported from a live tenant. Rekor anchors are omitted; automated Rekor verification reports SKIP on this sample.
The SOC 2 variant adds a criterion-mapping section (evidence type → Trust Services Criteria) and the CPA-boundary statement: it is evidence for the AI-runtime slice of a SOC 2 examination — not a SOC 2 report; only a licensed CPA firm can attest.
For a pilot with your own traffic, scoped deployments, and a real export: book an enterprise pilot. Production bundles are generated from Dashboard → Audit bundles.
Capabilities described as of August 2026. Technical reference only — not legal advice or a compliance assessment.