Mapping the Eight-Pillar Framework to Continuous Cryptographic Evidence
Who this is for: Bureau Veritas auditors conducting AI maturity assessments. Enterprise GRC teams preparing for BV assessments. AWS AIRI integration teams building automated evidence pipelines.
Bureau Veritas launched its AI maturity audit in April 2026 across France, UK, Spain, Italy, Netherlands, and Nordic countries. The audit evaluates AI systems across eight standardized pillars, using AWS AI Risk Intelligence (AIRI) to automate document review and reduce audit cycles from weeks to days. The eight pillars -- Security, Robustness, Data Privacy, Governance, Fairness, Explainability, Controllability, and Transparency -- represent a comprehensive framework for assessing organizational AI readiness.
The BV methodology draws from ISO/IEC 42001 and aligns with the EU AI Act's risk-based approach. AIRI accelerates document analysis, classifying evidence against pillar requirements and identifying gaps before the auditor arrives on site. This combination of human expertise and automated review creates the fastest path to a maturity rating available today.
But point-in-time audits capture a snapshot. EU AI Act Art. 9(2)(b) requires continuous risk estimation during operation, not merely at the moment of assessment. The maturity report describes what was true on audit day. It does not describe what was true the day before, or the day after. Between audits, evidence decays. Policies change without attestation. Models drift without detection. Fairness thresholds are met in testing but violated in production.
SWT3 provides what was true every day between audits. Each witness anchor is a cryptographically fingerprinted, timestamped evidence event tied to a specific procedure. The anchors accumulate continuously and are available for machine-readable export at any point. When the next BV audit cycle begins, the evidence is already structured by pillar, timestamped by day, and verified by fingerprint.
A maturity report without runtime evidence is a photograph of a moving target. The photograph proves the subject existed. It does not prove the subject is still there.
Note: SWT3 does not replace the Bureau Veritas audit. It provides the continuous evidence layer that makes the next audit faster and the maturity report evidence-backed rather than opinion-based.
Protection against adversarial attacks, prompt injection, data poisoning, and model extraction. The Security pillar evaluates whether the organization has implemented detection and response mechanisms for AI-specific threat vectors beyond traditional IT security controls.
| Pillar Requirement | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Adversarial threat detection deployed | AI-SEC.1 |
Timestamped scan results with threat categories and detection counts |
| Prompt injection mitigation active | AI-SEC.1 |
Per-scan anchor with threat type classification and threshold status |
| Security scan cadence documented | AI-SEC.1 (series) |
Anchor timeline proving continuous scan execution, not one-time review |
from swt3_ai import Witness
witness = Witness(api_key="your_key", tenant_id="your_tenant")
witness.witness_security_scan(
threat_score=0.12,
threshold=0.5,
threat_type="prompt_injection",
)Request AI-SEC.1 anchors for the assessment window. The first numeric factor represents threat categories checked. The second numeric factor represents threats detected -- this should be 0 for a PASS verdict. A high detection count indicates active attacks that require investigation of response procedures.
Organizations often deploy detection tooling but fail to witness results. Without anchors, "we have a WAF" is an unverifiable claim. The WAF may exist, but whether it was active, configured correctly, and producing clean scans on any given date cannot be confirmed.
Model stability under distribution shift, adversarial perturbation, and data quality degradation. The Robustness pillar evaluates whether the organization monitors model behavior over time and can detect when production conditions diverge from training assumptions.
| Pillar Requirement | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Drift detection operational | AI-DRIFT.1 |
Metrics evaluated, drift count, detection method, and threshold per scan |
| Consequence-mapped response defined | AI-DRIFT.2 |
Drift severity classification with mapped business impact and response action |
| Weight integrity verified | AI-MDL.5 |
SHA-256 hash comparison confirming deployed weights match approved baseline |
| Stability trend documented | AI-DRIFT.1 (series) |
90-day anchor timeline showing drift count trajectory |
from swt3_ai import Witness
witness = Witness(api_key="your_key", tenant_id="your_tenant")
witness.witness_drift(
metrics_evaluated=12,
drifted_count=0,
drift_type="prediction",
detection_method="psi",
threshold=0.25,
)Request 90 days of AI-DRIFT.1 anchors. The drifted count trending upward over time indicates degrading robustness even if individual scans still pass. Cross-reference with AI-MDL.5 to confirm weights have not been silently swapped -- a weight change without a corresponding drift reset is a red flag.
Many organizations monitor drift internally but produce no externally verifiable evidence. The monitoring dashboard is not an audit artifact. It can be reconfigured, its thresholds adjusted, or its history cleared without any record of the change.
GDPR compliance, data minimization, purpose limitation, and consent management. The Data Privacy pillar evaluates whether the organization processes personal data through AI systems in accordance with applicable data protection regulations, with particular emphasis on lawful basis documentation and data subject rights.
| Pillar Requirement | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Jurisdiction documented per processing activity | CJT fields on all anchors | jurisdiction (ISO 3166-1) on every witness event |
| Legal basis recorded | CJT fields on all anchors | legal_basis (GDPR lawful basis code) on every witness event |
| Purpose limitation enforced | CJT fields on all anchors | purpose_class classification on every witness event |
from swt3_ai import Witness
witness = Witness(
api_key="your_key",
tenant_id="your_tenant",
jurisdiction="EU",
legal_basis="legitimate_interest",
purpose_class="model_monitoring",
)Verify every anchor includes CJT fields. Missing jurisdiction on any anchor is an evidence gap for GDPR Art. 13/14 disclosure requirements. CJT fields survive all clearing levels, including Level 3 (Classified), so redaction cannot be used as an excuse for missing jurisdiction data.
Teams often configure CJT fields at the witness level but forget to propagate them when using the wrap() proxy pattern for OpenAI or Anthropic clients. Check both direct witness calls and proxy-generated anchors to confirm CJT fields are present on all evidence events.
Organizational AI policy, accountability structures, and risk management frameworks. The Governance pillar evaluates whether the organization has established clear ownership, documented policies, and ongoing review cycles for AI systems.
| Pillar Requirement | SWT3 Procedure | Evidence Produced |
|---|---|---|
| AI acceptable use policy active | AI-GOV.1 |
Controls defined, controls active, framework version, last review date |
| Audit log integrity maintained | AI-AUDIT.1 |
Integrity verification result with hash confirmation |
| Policy review cadence documented | AI-GOV.1 (series) |
Anchor timeline proving periodic policy attestation, not annual-only |
from swt3_ai import Witness
witness = Witness(api_key="your_key", tenant_id="your_tenant")
witness.witness_governance_framework(
controls_defined=45,
controls_active=43,
framework_version="v2.1",
last_review_date="2026-09-01",
)AI-GOV.1 anchors should show active controls greater than or equal to defined controls. A declining ratio over time indicates governance erosion -- controls being added to the policy without corresponding implementation. AI-AUDIT.1 with a positive integrity confirmation proves log integrity was verified on that date.
Governance policies exist as documents. Without AI-GOV.1 attestation, there is no proof the policy was active on any given date. Annual policy reviews leave 364 days unattested. An auditor asking "was this policy active on March 15?" receives silence.
Bias detection and mitigation, demographic parity, and equalized odds measurement. The Fairness pillar evaluates whether the organization systematically measures and addresses disparate impact across protected attributes in AI system outputs.
| Pillar Requirement | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Protected attributes tested | AI-FAIR.1 |
Per-inference disparity measurement with attribute count and threshold status |
| Bias assessment completed | AI-FAIR.3 |
Assessment-level summary with methodology, max disparity percentage, pass/fail |
| Remediation evidence for threshold violations | AI-FAIR.1 (series) |
Before/after anchor pairs showing disparity reduction following mitigation |
from swt3_ai import Witness
witness = Witness(api_key="your_key", tenant_id="your_tenant")
witness.witness_bias_assessment(
protected_attribute_count=5,
all_thresholds_met=True,
max_disparity_pct=8.2,
methodology="demographic_parity",
)This mints an AI-FAIR.3 (assessment-level) anchor. For per-inference fairness monitoring, use AI-FAIR.1 via the ledger to capture continuous disparity measurements.
Request AI-FAIR.3 anchors from the assessment window. The protected attribute count should match the organization's declared list of protected characteristics. A threshold-met indicator of 0 (not met) requires corresponding remediation evidence -- look for subsequent anchors showing reduced disparity after mitigation actions.
Fairness testing at model training does not prove fairness in production. Distribution shift can introduce bias that was not present in training data. A model that was fair on test data may produce disparate outcomes on real-world populations. Continuous fairness monitoring is the only evidence that survives audit scrutiny.
Interpretable outputs, reasoning traces, and attribution for high-stakes decisions. The Explainability pillar evaluates whether the organization generates, delivers, and records explanations for AI-driven decisions, particularly those affecting individuals' rights or opportunities.
| Pillar Requirement | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Explanation generation active | AI-EXPL.1 |
Explanation required/provided status per decision, with recipient type |
| Automated decision disclosure | AI-TRANS.1 |
Disclosure event with type classification and delivery channel |
| Explanation coverage documented | AI-EXPL.1 (series) |
Ratio of explanations provided to explanations required over time |
from swt3_ai import Witness
witness = Witness(api_key="your_key", tenant_id="your_tenant")
witness.witness_transparency(
disclosures_made=1,
disclosure_type="automated_decision",
recipient_type="end_user",
)AI-EXPL.1 is currently witnessed through the transparency method family. The first factor indicates whether an explanation was required (1), and the second indicates whether an explanation was provided (1).
For high-risk systems under the EU AI Act, every inference should have a corresponding AI-EXPL.1 or AI-TRANS.1 anchor. Missing anchors indicate inferences without explanations -- a gap under Art. 13(1). Compare the total inference count against the total explanation anchor count to calculate coverage.
Organizations claim "our model is interpretable" without evidence of actual explanation generation. An interpretable architecture does not mean explanations were generated, delivered, or recorded. The model's capability to explain is not the same as evidence that it did explain.
Human override capability, safe shutdown, operational boundaries, and kill switches. The Controllability pillar evaluates whether the organization can intervene in AI system operations, halt processing when necessary, and maintain meaningful human oversight of high-risk decisions.
| Pillar Requirement | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Human review for high-risk decisions | AI-HITL.1 |
Human review completion status with reviewer identity binding |
| Safe state mechanism exists and tested | AI-SAFE.1 |
Mechanism type, existence confirmation, and operational test result |
| Override capability demonstrated | AI-SAFE.1 (series) |
Periodic test anchors proving safe state mechanisms remain operational |
from swt3_ai import Witness
witness = Witness(api_key="your_key", tenant_id="your_tenant")
witness.witness_safe_state(
mechanism_exists=True,
safe_state_confirmed=True,
mechanism_type="circuit_breaker",
)AI-SAFE.1 anchors prove safe state mechanisms exist and were tested. AI-HITL.1 (via reviewer identity binding) proves human review occurred for high-risk decisions. Request both. A single AI-SAFE.1 anchor proves the mechanism was tested once. A series proves it remains operational. Gaps in the series indicate untested periods.
"We have a kill switch" is the most common unverifiable claim in AI audits. Without AI-SAFE.1 anchors, there is no evidence the mechanism was ever tested or confirmed operational. A kill switch that has never been tested is indistinguishable from one that does not work.
AI system disclosure, data processing notification, and automated decision transparency. The Transparency pillar evaluates whether the organization informs affected parties that AI is being used, what data is being processed, and what decisions are being made or supported by automated systems.
| Pillar Requirement | SWT3 Procedure | Evidence Produced |
|---|---|---|
| AI usage disclosed to affected parties | AI-TRANS.1 |
Disclosure event with type, recipient classification, and delivery channel |
| Data processing notification delivered | AI-TRANS.1 |
Per-notification anchor with disclosure type code and recipient type |
| All required disclosure types covered | AI-TRANS.1 (series) |
Disclosure type distribution across the assessment window |
from swt3_ai import Witness
witness = Witness(api_key="your_key", tenant_id="your_tenant")
witness.witness_transparency(
disclosures_made=3,
disclosure_type="ai_usage",
recipient_type="end_user",
channel="in-app",
)The disclosure count represents the number of disclosure events in this batch. Disclosure type codes: 0=ai_usage, 1=data_processing, 2=automated_decision, 3=profiling, 4=capability_limitation. Verify that all required disclosure types have anchors across the assessment window.
Request the full set of AI-TRANS.1 anchors and verify coverage across all five disclosure type codes. Missing disclosure types indicate categories where users were not informed. Cross-reference disclosure counts against user interaction volumes to identify coverage gaps.
Transparency is often treated as a checkbox rather than an evidence event. GDPR Art. 13/14 and EU AI Act Art. 50 require disclosure at the point of interaction, not in a privacy policy buried four clicks deep. An anchor proves the disclosure happened at a specific time through a specific channel. A privacy policy page proves only that the page exists.
SWT3 evidence flows into the BV/AIRI audit pipeline through a structured integration path. The production runtime generates witness anchors continuously. The ledger accumulates evidence by procedure and date. At audit time, the JSON export provides machine-readable evidence that AIRI can parse without manual document review.
Witness calls from production AI systems
Fingerprinted anchors by procedure and date
Machine-readable evidence structured by procedure ID
Automated gap analysis and pillar classification
Expert evaluation with pre-structured evidence
Evidence-backed pillar ratings
The JSON export from the SWT3 ledger is structured by procedure ID. AIRI can parse anchor volumes, numeric factor distributions, and gap patterns without manual document review. Each pillar maps to specific procedure IDs, so the automated classification is deterministic rather than heuristic.
Note: The integration is one-directional. SWT3 produces evidence. AIRI consumes it. Neither system requires access to the other's infrastructure. The JSON export is the only integration surface.
Related guides: AI Model Escrow Integration for model integrity evidence, EU AI Act Conformity Assessment for the full Article 9-15 mapping.
Install:
# Python
pip install swt3-ai
# TypeScript
npm install @tenova/swt3-aiWitness drift in three lines:
from swt3_ai import Witness
witness = Witness(api_key="your_key", tenant_id="your_tenant")
witness.witness_drift(metrics_evaluated=12, drifted_count=0, drift_type="prediction")Full SDK documentation: SDK Docs. Create a free account: Sign Up.