Session transcripts tell you what a vendor logged. Witness anchors prove what your system did. Assessors need both -- and need to know which is which.
Who this is for: Assessors and Notified Bodies evaluating AI compliance evidence, compliance officers at enterprises using multiple AI providers, and DevSecOps engineers choosing governance tooling. No prior SWT3 knowledge required.
SWT3 witness anchors prove that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessors must verify that anchored evidence is sufficient, appropriate, and relevant to the specific assessment context. Each regulatory framework retains its own assessment authority, methodology, and determination standards.
Most enterprises now run AI workloads across multiple providers simultaneously. A typical deployment might use Anthropic Claude for customer support, OpenAI GPT-4 for document analysis, AWS Bedrock for internal reasoning, and a self-hosted Llama model for sensitive workflows. Each provider offers its own logging API in its own format with its own retention policies.
Compliance teams face a fragmented evidence landscape. When an assessor asks "show me your AI logging controls," the organization produces four different log schemas, three different dashboards, and zero unified audit trail. The question is not whether these logs exist -- they do. The question is whether they constitute sufficient, independent, and tamper-evident evidence for regulatory purposes.
This guide draws a clear line between three categories of compliance evidence: vendor-provided logs, aggregated log platforms, and independent cryptographic attestation. Each serves a distinct function. None replaces the others.
AI providers increasingly expose compliance-oriented APIs that return session data for enterprise governance workflows:
Vendor compliance APIs are essential for internal security operations, data loss prevention, incident response, and usage monitoring. They provide visibility into what happened inside the vendor's system. This guide does not argue against using them.
Enterprise platforms ingest vendor logs into centralized dashboards for policy enforcement and monitoring:
Aggregators add value by normalizing heterogeneous log formats into a single query surface. A security analyst can search across Claude, GPT-4, and Bedrock logs in one dashboard. This is operationally important.
A log aggregator inherits the trust properties of its source. If the source log is a mutable database row provided by the AI vendor, the aggregated version is also a mutable database row. Centralization does not add cryptographic integrity.
Independent attestation generates compliance evidence from a system that is structurally separate from the AI provider being witnessed. The evidence is cryptographically bound to execution facts at the moment of occurrence.
Why does this matter? Because compliance evidence is only as strong as its independence from the system being evaluated. When an EU Notified Body conducts a conformity assessment under Article 43, or when a C3PAO evaluates CMMC controls, or when a bank examiner reviews model risk under SR 11-7, the assessor's fundamental question is: "Can I trust this evidence without trusting the entity that produced it?" If the answer is no, the evidence supports internal operations but does not satisfy independent assessment requirements.
An SWT3 Witness Anchor is a deterministic SHA-256 fingerprint derived from:
The fingerprint formula is locked, open-source, and identical across 10 language SDKs. Any party can recompute the fingerprint from the same inputs and verify it matches -- without contacting the AI provider, without API keys, and without trusting any vendor's database.
The anchor format is a single greppable string:
SWT3-E-AWS-AI-TOOL1-PASS-1723891200-a4f8c92d0e17
When an AI provider logs its own sessions and presents those logs as compliance evidence, the evidence has a structural dependency: the entity being evaluated controls the evidence chain. This is not a statement about any vendor's integrity. It is a statement about evidence architecture.
Consider the parallel in financial auditing. Every public company maintains internal accounting records. Those records are essential for operations. But no regulator accepts internal records alone as proof of financial compliance. External auditors exist precisely because independent verification is structurally necessary, regardless of how trustworthy the company is.
The same principle applies to AI compliance evidence:
Assertions can be amended, truncated, selectively retained, or retroactively modified. The log entry and the execution event are not cryptographically bound -- there is no way for an external party to prove the log was not altered after the fact.
Facts, expressed as deterministic cryptographic fingerprints, are either correct or incorrect. They can be verified by any party with access to the inputs. The math does not depend on trust.
Consider a concrete scenario. A high-risk AI system approves a loan application. Six months later, the applicant challenges the decision. The regulator asks the deployer: "Prove that your guardrails were active, your model was the version you claim, and human oversight was in place at the moment of this specific decision."
With vendor logs alone, the deployer presents a database row from the AI provider's compliance API. The regulator asks: "Can you prove this log entry was not modified after the challenge was filed?" The deployer cannot, because the log is a mutable database record controlled by a third party. The evidence is an assertion.
With an independent witness anchor, the deployer presents a SHA-256 fingerprint that any party can recompute from the original execution factors. The regulator verifies it independently -- no API call, no vendor cooperation, no trust assumption. The fingerprint either matches or it does not. The evidence is a mathematical fact. That is the difference between evidence that supports an internal narrative and evidence that survives adversarial cross-examination.
Vendor compliance logs are database rows. They can be updated, deleted, or modified by database administrators, automated retention policies, or operational processes. There is no cryptographic seal binding the log entry to the execution moment. An SWT3 Witness Anchor is a SHA-256 hash -- if any input changes by a single bit, the fingerprint changes entirely.
Each provider's compliance API returns data in its own proprietary schema. An organization using three AI providers maintains three separate evidence pipelines with three different formats. Switching providers means rebuilding the compliance pipeline. SWT3 anchors use a single format across all providers and all SDKs.
Vendor compliance APIs require cloud connectivity to the provider's infrastructure. They produce zero evidence for locally hosted models: Ollama, vLLM, TensorRT-LLM, Meta Muse Glimmer, or any model running on-premises. Organizations running local models for data privacy or security reasons have no vendor API to call. SWT3 SDKs run locally inside the application code and mint anchors without any cloud dependency.
An enterprise running Claude, GPT-4, Bedrock, and a local Llama model produces four different log schemas. An assessor reviewing this evidence must understand four different formats, four different retention policies, and four different trust models. SWT3 produces one format across all providers -- same fingerprint formula, same anchor structure, same verification method.
Vendor session transcripts contain the full text of prompts and responses. Sending these to a log aggregator means PII, trade secrets, and sensitive data now reside in a second system. SWT3 anchors contain only SHA-256 hashes and numeric factors. Raw prompts and responses never leave the originating infrastructure. At Clearing Level 3, even the model name is hashed.
| Dimension | Vendor Compliance API | Log Aggregator | Independent Attestation (SWT3) |
|---|---|---|---|
| Evidence source | Provider's internal systems | Ingested from provider APIs | Out-of-band SDK in your code |
| Mutability | Mutable database rows | Inherits source mutability | Deterministic SHA-256 hash |
| Cryptographic binding | None | None | SHA-256 fingerprint locked to execution moment |
| Vendor independence | Requires vendor cooperation | Requires vendor API access | Verifiable without vendor |
| Air-gap support | No (requires cloud API) | No (requires cloud ingestion) | Yes (SDK runs locally) |
| Local model coverage | None (Ollama, vLLM, on-prem) | None (no source to ingest) | Full (same SDK, same format) |
| PII in evidence | Full transcripts (prompts + responses) | Full transcripts (inherited) | Hashes and numeric factors only |
| Assessor independence | Assessor relies on vendor's log integrity | Assessor relies on vendor + aggregator | Assessor verifies math independently |
| Multi-provider unification | Separate schema per provider | Normalized but format varies | One format across all providers |
| Regulatory mapping | Provider-specific (varies) | Generic (SIEM/DLP oriented) | 266 procedures across 36 frameworks |
In 2026, AI providers are rapidly launching compliance APIs. Enterprise teams are connecting these to Purview, Splunk, and Datadog and treating the result as "compliance solved." This is understandable -- the logs are real, the dashboards are useful, and the security value is genuine. But assessors and regulators operate under a different evidentiary standard. When GPAI transparency obligations became enforceable in August 2026, and as high-risk AI enforcement approaches in December 2027, the question will shift from "do you have logs?" to "can you prove those logs were not altered, and can I verify them without your cooperation?" Organizations that build their entire compliance posture on vendor-provided evidence will face this question unprepared. The time to add independent attestation to the evidence chain is before the assessment, not during it.
Different regulatory requirements have different evidence standards. Some can be satisfied with vendor logs alone. Others structurally require independent evidence.
| Requirement | Vendor Logs Sufficient? | Independent Attestation Needed? | Rationale |
|---|---|---|---|
| EU AI Act Art. 12 Record-keeping |
Partially -- internal records accepted for routine logging | Yes -- for high-risk systems, Notified Bodies require evidence that cannot be unilaterally modified by the provider | Art. 12(1) requires logs that "allow the tracing back" of AI system operation. Mutable logs can be challenged. |
| EU AI Act Art. 14 Human oversight |
No -- vendor logs show what the model did, not whether human oversight was active | Yes -- AI-HITL procedures record oversight status at execution time | Oversight is an organizational control, not a model behavior. The provider cannot attest to the deployer's oversight practices. |
| NIST 800-53 AU-2/AU-3 Audit events and content |
Partially -- vendor logs satisfy AU-2 (event identification) | Recommended -- AU-3 (content of audit records) benefits from cryptographic integrity for FedRAMP/CMMC | AU-3 requires audit records that "contain sufficient information." Independent fingerprints add non-repudiation. |
| ISO 42001 Annex A AIMS record controls |
Partially -- internal records accepted for certification | Recommended -- independent evidence strengthens the conformity assessment | Certification bodies evaluating AIMS effectiveness benefit from evidence the organization cannot unilaterally modify. |
| CMMC AU.L2-3.3.1 System audit logging |
Partially -- for CUI systems, vendor logs may not meet integrity requirements | Recommended -- C3PAOs evaluating AU controls benefit from tamper-evident records | CMMC assessors look for evidence of audit log integrity. Cryptographic binding exceeds minimum requirements. |
Vendor compliance APIs and independent attestation serve different buyers within the same organization:
| Function | Primary Evidence Source | Why |
|---|---|---|
| Data Loss Prevention (DLP) | Vendor API + Purview/Splunk | DLP needs full text content to scan for PII, secrets, and policy violations |
| Incident response | Vendor API + SIEM | Responders need session transcripts to understand what happened |
| Usage monitoring | Vendor API | Token counts, cost tracking, and rate limiting are provider-specific |
| Regulatory submission | Independent attestation (SWT3) | Assessors need evidence that cannot be modified by the entity being assessed |
| Cross-provider audit trail | Independent attestation (SWT3) | One format across all providers, including local models with no vendor API |
| Vendor due diligence | Independent attestation (SWT3) | Supply chain partners need verifiable evidence without accessing your vendor accounts |
Vendor APIs for internal security operations. Independent attestation for assessor-grade evidence and regulatory submissions. Neither replaces the other. An organization that presents only vendor logs to a Notified Body may face questions about evidence independence. An organization that presents only witness anchors without operational logging may lack incident response capability.
In practice, both evidence streams run in parallel without interfering with each other:
Both pipelines observe the same AI execution. The vendor API captures the text content for security operations. The SWT3 SDK captures the execution facts as cryptographic proof for compliance. The two are complementary, not competing.
For local models (Ollama, vLLM, on-premises deployments), only the SWT3 pipeline exists -- there is no vendor API to call. The same SDK, the same anchor format, and the same verification method apply regardless of whether the model runs in a vendor cloud or on a workstation GPU.
An organization that relies exclusively on vendor compliance APIs is building its regulatory posture on a foundation that a sophisticated assessor, opposing counsel, or regulator can challenge with a single question: "Can you prove this log was not modified after the event?" If the answer depends on trusting the vendor's database integrity, the evidence is an internal control, not an independent attestation. This does not mean the evidence is worthless -- it means it serves a different purpose than the organization believes.
The organizations that will navigate AI regulation successfully are the ones that understand this distinction now, before the assessment, and build both evidence pipelines from the start. Adding independent attestation after a regulatory finding is reactive and expensive. Adding it during initial deployment is three lines of code.
When evaluating an organization's AI compliance evidence, consider these questions:
Records model identity, input/output hashes, latency, and token counts at each inference. The primary attestation point for EU AI Act Article 12 record-keeping. Registry entry
Witnesses every tool call an AI agent makes -- API calls, database queries, file operations, code execution. The primary attestation point for agentic workflows (Claude Code, Cowork, MCP-based agents). Registry entry
Records the physical hardware executing the model -- GPU model, CPU architecture, runtime environment. Proves execution was bound to specific silicon, not just a cloud region label. Registry entry
Records whether guardrail controls (content filters, safety classifiers, output validators) were active and what their status was at the moment of inference. Proves organizational controls were in place, not just that the model behaved. Registry entry