The EU AI Act (Article 27) requires a Fundamental Rights Impact Assessment (FRIA) for certain deployers of high-risk AI systems. The GDPR (Article 35) requires a Data Protection Impact Assessment (DPIA) when AI processing is likely to result in high risk to individuals. Both assessments demand evidence that safeguards are operational, not just documented.
This document maps SWT3 witness anchors to the specific evidence items required by each assessment. The goal: replace "we have a policy" with "here is cryptographic proof the policy was enforced at runtime."
Required for:
Must assess: Impact on fundamental rights of affected persons, including non-discrimination, dignity, privacy, freedom of expression, fair trial rights, and consumer protection.
Notify: Competent national market surveillance authority.
Required when processing is likely to result in high risk, including:
Must assess: Risks to rights and freedoms of data subjects, necessity and proportionality, and measures to address risks including safeguards and security mechanisms.
Consult: Data Protection Authority if residual risk remains high after mitigation.
Article 27 requires deployers to identify, assess, and document measures addressing potential impacts on fundamental rights. The following table maps each FRIA requirement to the SWT3 evidence that satisfies it.
| FRIA Requirement (Art. 27) | Fundamental Right | SWT3 Evidence | Procedure |
|---|---|---|---|
| Description of deployer's processes using the AI system | Transparency | Inference provenance anchors record every model invocation with hashed input/output | AI-INF.1 |
| Period of time and frequency of use | Proportionality | Inference volume and latency anchors provide continuous usage metrics | AI-INF.2, AI-INF.3 |
| Categories of natural persons and groups likely affected | Non-discrimination (Charter Art. 21) | Bias measurement anchors record demographic parity metrics per inference batch | AI-FAIR.1 |
| Specific risks of harm to identified groups | Non-discrimination, Dignity (Charter Art. 1) | Fairness threshold anchors flag when measured parity falls below defined bounds | AI-FAIR.2 |
| Human oversight measures | Human dignity, Fair trial (Charter Art. 47) | Human review anchors prove a human reviewed the AI decision before release | AI-HITL.1 |
| Human override capability | Human dignity | Override decision anchors record when a human overrode the AI recommendation | AI-HITL.2 |
| Measures to act on risks identified | All applicable rights | Guardrail enforcement anchors prove safety filters were active at call time | AI-GRD.1 |
| Content safety and refusal detection | Dignity, Freedom of expression (Charter Art. 11) | Content safety anchors track filter activation and refusal rate | AI-GRD.2 |
| Transparency and information to affected persons | Transparency (AI Act Art. 13) | Explainability anchors prove explanations were generated alongside AI output | AI-EXPL.1 |
| Governance and accountability chain | Accountability | Agent identity anchors bind each inference to a specific, signed agent identity | AI-ID.1 |
| Revocation of AI-generated decisions | Right to effective remedy (Charter Art. 47) | Revocation anchors provide append-only proof that a prior decision was withdrawn with stated reason | AI-REV.1 |
Article 11 of the EU AI Act requires providers to draw up technical documentation per Annex IV before placing a high-risk AI system on the market. This documentation must be kept up-to-date throughout the system lifecycle. The following table maps Annex IV documentation sections to SWT3 procedures that provide machine-generated evidence.
| Annex IV Section | Documentation Requirement | SWT3 Procedure | Auto-Populated |
|---|---|---|---|
| Section 1: General Description | Intended purpose, developer identity, system version | AI-ID.1, AI-MDL.1 |
Yes |
| Section 2: Detailed Description | Elements and development process | AI-MDL.2 |
Partial |
| Section 5: Risk Management | Risk management system description | AI-GRD.1, AI-GRD.2 |
Yes |
| Section 8: Data Governance | Training data provenance and governance | AI-DATA.1, AI-DATA.2 |
Yes |
| Section 10: Logging Capabilities | Automatic logging design and capabilities | AI-INF.1, AI-LOG.1 |
Yes |
| Section 11: Human Oversight | Measures for human oversight | AI-HITL.1, AI-HITL.2 |
Yes |
| Section 12: Accuracy/Robustness | Performance metrics and resilience | AI-INF.2, AI-SEC.1 |
Yes |
| Section 14: Post-Market Monitoring | Monitoring plan description | AI-MDL.3, AI-MDL.4 |
Yes |
| Sections 3, 4, 6, 7, 9, 13, 15 | Hardware, testing, training data details, declaration of conformity | Manual provider input | No |
The Annex IV checklist is available at the auditor portal. Auto-populated sections are seeded from the latest AI procedure verdicts. Sections not auto-populated are clearly flagged for manual completion by the provider. Evidence quality ratings (Complete / Partial / Missing) are computed per section.
Article 35 of GDPR requires assessment of processing risks to data subjects. The following table maps each DPIA component to the SWT3 evidence and clearing level that addresses it.
| DPIA Component (Art. 35) | GDPR Principle | SWT3 Evidence | Clearing Level |
|---|---|---|---|
| Systematic description of processing operations | Transparency (Art. 5(1)(a)) | Inference provenance anchors with model ID, hashed prompt/response, timestamps | Level 0-1 |
| Assessment of necessity and proportionality | Purpose limitation (Art. 5(1)(b)) | Purpose class and legal basis fields on every anchor, jurisdiction-scoped | All levels |
| Data minimization safeguards | Data minimization (Art. 5(1)(c)) | Clearing engine purges hashes, metadata, and model identity at increasing thresholds | Level 2-3 |
| Storage limitation | Storage limitation (Art. 5(1)(e)) | Clearing Level 3 retains only numeric factors. No PII, no hashes, no metadata survives on the wire. | Level 3 |
| Integrity and confidentiality | Integrity (Art. 5(1)(f)) | SHA-256 fingerprint on every anchor. Daily Merkle rollup for tamper evidence. HMAC-SHA256 payload signing. | All levels |
| Lawful basis for processing | Lawfulness (Art. 6) | legal_basis field on every anchor (consent, legitimate_interest, contract, etc.). Survives all clearing levels. |
All levels |
| Special category data safeguards | Special categories (Art. 9) | Clearing Level 2 (Sensitive) strips context and provider. Level 3 strips everything except factors. | Level 2-3 |
| Automated decision-making safeguards | Automated decisions (Art. 22) | Human-in-the-loop anchors prove human review before release. Gatekeeper mode blocks inference without guardrails. | All levels |
| Right to erasure compliance | Right to erasure (Art. 17) | Revocation anchors (AI-REV.1) with consent_withdrawal reason. Clearing Level 3 ensures original data is not retained. |
All levels |
| Privacy by design and default | Data protection by design (Art. 25) | Clearing is applied before data leaves the developer's infrastructure. The wire payload is the cleared version. | All levels |
| Records of processing activities | Records of processing (Art. 30) | Witness ledger provides a complete, immutable processing log per tenant, with Merkle integrity proofs. | All levels |
The clearing engine is the mechanism that makes simultaneous EU AI Act and GDPR compliance possible. The AI Act requires evidence. The GDPR requires data minimization. Clearing satisfies both by controlling what evidence survives on the wire at each privacy threshold.
| Level | Name | What Survives on Wire | GDPR Alignment | Use Case |
|---|---|---|---|---|
| 0 | Analytics | All hashes, model ID, context, tokens, latency, guardrail names | Full transparency for internal audit | Internal model debugging, R&D |
| 1 | Standard | Hashes, model ID, context (no raw text ever leaves) | Art. 5(1)(a) lawfulness, proportionate | B2B SaaS, general production |
| 2 | Sensitive | Hashes, model ID only. No context, no provider, no guardrail names. | Art. 5(1)(c) data minimization | Healthcare, PII-bearing prompts |
| 3 | Classified | Numeric factors only. Model ID hashed. No hashes, no metadata. | Art. 5(1)(f) integrity + confidentiality | Defense, classified, ITAR |
For deployers who must conduct both a FRIA and a DPIA, the following workflow produces a consolidated evidence package from the witness ledger.
Identify the AI system, its intended purpose, and the categories of affected persons. Record the purpose_class and jurisdiction on the witness configuration. These fields appear on every anchor and survive all clearing levels.
Query the witness ledger for the assessment period. Every anchor includes the procedure ID, verdict, factors, and timestamp. No manual evidence gathering required.
Use the mapping table in Section 3 to match each FRIA requirement to anchors in the ledger. For each fundamental right:
AI-MDL.3)AI-HITL.1 anchor count)AI-FAIR.1 parity metrics)Use the mapping table in Section 4 to match each DPIA component to the clearing level and evidence fields. Confirm:
legal_basis field is set on all anchorsGenerate the assessment report from the ledger. The report contains anchor references (not raw data), making it safe to share with regulatory authorities without exposing operational detail. If residual risk remains high after mitigation, consult the relevant Data Protection Authority (DPIA) or notify the market surveillance authority (FRIA).
| Requirement | FRIA | DPIA | SWT3 Evidence |
|---|---|---|---|
| Processing description | FRIA | DPIA | AI-INF.1 provenance anchors |
| Non-discrimination assessment | FRIA | AI-FAIR.1, AI-FAIR.2 anchors |
|
| Human oversight | FRIA | DPIA | AI-HITL.1, AI-HITL.2 anchors |
| Transparency / explainability | FRIA | DPIA | AI-EXPL.1, AI-EXPL.2 anchors |
| Data minimization | DPIA | Clearing Level 2-3 | |
| Lawful basis documentation | DPIA | legal_basis field on payload |
|
| Right to erasure | DPIA | AI-REV.1 with consent_withdrawal |
|
| Remedy / revocation | FRIA | AI-REV.1 with reason code |
|
| Risk management measures | FRIA | DPIA | AI-GRD.1, AI-GRD.2 anchors |
| Integrity / tamper evidence | DPIA | SHA-256 fingerprint + Merkle rollup | |
| Agent accountability | FRIA | DPIA | AI-ID.1 + payload_signature |
| Records of processing | DPIA | Witness ledger (per-tenant, immutable) |
SWT3 provides the technical evidence layer. The following organizational requirements must be addressed through policy and process, outside the protocol scope:
| Requirement | Assessment | Owner | SWT3 Role |
|---|---|---|---|
| Stakeholder consultation | FRIA | Deployer / DPO | None (policy process) |
| DPA notification (high residual risk) | DPIA | DPO | Evidence package supports the notification |
| Market surveillance authority notification | FRIA | Deployer | Evidence package supports the notification |
| Post-deployment monitoring plan | FRIA | Deployer / AI lead | Drift detection (AI-MDL.3) provides continuous monitoring data |
| Training documentation for human overseers | FRIA | HR / Training | None (organizational process) |
| Data subject rights procedures (access, portability, objection) | DPIA | DPO | Revocation (AI-REV.1) supports erasure requests |
| Organization | Tenable Nova LLC |
| Protocol | SWT3 v1.3.0 |
| SDKs | pip install swt3-ai | npm install @tenova/swt3-ai |
| License | Apache 2.0 |
| Patent status | Patent pending |
| Contact | founder@tenovaai.com |
© 2026 Tenable Nova LLC. This document is provided for informational purposes and does not constitute legal advice. Consult qualified legal counsel for your specific FRIA/DPIA obligations.