On September 1, 2026, the EU AI Office sent its first Requests for Information to 30+ GPAI providers. This guide maps each RFI question area to the SWT3 procedures that produce verifiable evidence for your response.
Who this is for: GPAI model providers who received Article 91 RFIs, compliance teams preparing RFI response packages, legal counsel advising on enforcement risk and penalty exposure, Notified Bodies and scientific panel experts evaluating GPAI compliance, and assessment firms supporting provider readiness.
Critical Assessor Notice: Boundaries of Cryptographic Evidence
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. The EU AI Office retains sole determination authority over GPAI compliance. Each provider must satisfy its own legal obligations under the AI Act.
Enforcement Active
The EU AI Office sent its first Article 91 RFIs on September 1, 2026 to more than 30 GPAI providers. Incomplete, incorrect, or misleading responses carry fines of up to 3% of global annual turnover or EUR 15 million, whichever is higher (Article 101). Violations dating back to August 2, 2025, when GPAI obligations first took effect, are in scope.
| Regulation | EU AI Act (Regulation (EU) 2024/1689) |
| Enforcement Authority | EU AI Office (European Commission) |
| Legal Basis | Article 91: Power to request documentation and information |
| First RFIs Sent | September 1, 2026 (30+ providers) |
| Confirmed Recipients | OpenAI, Anthropic, Google (per Euractiv reporting) |
| RFI Strands | Strand 1: Safety and security. Strand 2: Copyright and transparency. |
| Penalty for Non-Response | Up to 3% of global annual turnover or EUR 15 million (Article 101) |
| Escalation Path | Inadequate responses trigger Article 92 evaluations by Scientific Panel |
| Scientific Panel | 60 independent experts recruited, published June 1, 2026 (Article 68) |
| SWT3 Procedures Mapped | 24 procedures across 9 RFI question areas |
Article 91 grants the EU AI Office the power to request any documentation drawn up pursuant to Articles 53 (GPAI model obligations) and 55 (systemic risk obligations), plus "any additional information" needed to assess compliance. Providers must respond within the deadline specified in the request. The AI Office can issue RFIs to any GPAI model provider, regardless of whether the provider has signed the Code of Practice.
The AI Office can request:
When Article 91 responses are insufficient, the AI Office may escalate to Article 92 evaluations, appointing independent experts (including members of the Scientific Panel established under Article 68) to conduct direct model evaluations. Article 92 evaluations can include adversarial testing, red-teaming, and systemic risk assessment. The September 1 RFIs represent the information-gathering phase before formal evaluation proceedings.
On June 1, 2026, the Commission published the full membership of the Scientific Panel: 60 independent experts with competence in AI safety, security, and societal impact. The panel advises the AI Office on systemic risk classification, evaluation methodologies, and cross-border surveillance. Panel members may be appointed to conduct Article 92 evaluations on behalf of the Commission. Their qualified alerts to the AI Office can trigger formal investigations.
The safety and security strand focuses on the most advanced AI models and asks providers to demonstrate:
This strand applies primarily to GPAI models classified as presenting systemic risks under Article 51 (models trained with more than 1025 FLOPs or designated by the Commission).
The copyright and transparency strand targets all GPAI model providers and asks for:
This strand particularly targets providers that have not participated in informal compliance dialogues with the AI Office prior to the RFI.
August 2, 2025: GPAI model obligations take effect (Articles 53, 55). Providers must begin complying. Violations from this date forward are in scope for enforcement.
August 2, 2026: Commission enforcement powers activate. AI Office can issue RFIs, conduct evaluations, impose fines.
June 1, 2026: Scientific Panel of 60 independent experts published.
September 1, 2026: First Article 91 RFIs sent to 30+ GPAI providers. Two strands: safety/security and copyright/transparency.
October-November 2026 (estimated): RFI response deadline. AI Office evaluates submissions.
Q1 2027 (projected): Article 92 evaluations begin for providers with inadequate responses. Scientific Panel experts appointed to conduct model evaluations.
December 2, 2027: High-risk AI system obligations take full effect.
Each RFI question area maps to specific SWT3 procedures that produce timestamped, cryptographically verifiable evidence. The witness anchors generated by these procedures serve as independent records that governance controls were active at the time the RFI period covers.
RFI asks: How do you defend your models against adversarial attacks?
Each guardrail evaluation produces a witness anchor recording whether the guardrail was active, what inputs were tested, and whether the guardrail held. AI-GRD.1 witnesses the overall guardrail framework integrity. AI-GRD.2 witnesses content safety filter effectiveness. AI-GRD.3 witnesses prompt injection defense status.
Include the count of AI-GRD anchors over the RFI period, the pass/fail distribution, and any revocations (AI-REV.1) triggered by guardrail failures. The anchor timestamps prove continuous defense, not point-in-time snapshots.
AI-SEC.1 witnesses the security posture of the AI system infrastructure. AI-CYBER.1 records vulnerability assessment results. Together, they demonstrate that the provider maintains active security monitoring of the model serving environment.
These anchors address the "how do you defend" question directly. Include time-series evidence showing continuous security posture, not a single assessment report.
RFI asks: Have independent experts evaluated your models?
AI-REDTEAM.1 witnesses red-team evaluation campaigns: who conducted the test, what attack surface was covered, and the outcome. When a third-party red team uses SWT3 to record their assessment, the resulting anchors are independently verifiable and cannot be retroactively modified by the provider.
This is the most critical procedure for the safety strand. The AI Office is explicitly asking whether independent experts have evaluated the model. SWT3 anchors from a third-party assessment are structurally independent: the provider does not control the witnessing infrastructure. Include the red-team organization name, assessment scope, and anchor fingerprints.
AI-AUDIT.1 witnesses the integrity of the audit trail itself: tamper detection, chain continuity, and evidence completeness. This procedure proves that the evidence chain supporting the RFI response has not been selectively edited.
Include AI-AUDIT.1 anchors to demonstrate that the evidence submitted in the RFI response is complete and unmodified. The AI Office can verify any anchor independently via the public verification endpoint.
RFI asks: How do you monitor systems after launch?
AI-DRIFT.1 witnesses model drift detection events: what metric drifted, by how much, and when. AI-DRIFT.2 extends this with consequence-mapped thresholds that trigger escalation based on the severity of the drift. Together they prove active post-deployment monitoring, not just a monitoring policy document.
AI-PERF.1 witnesses ongoing performance metrics against defined thresholds. AI-ROBUST.1 witnesses robustness testing results under adversarial and edge-case conditions. These procedures generate continuous evidence of post-launch quality assurance.
The combination of drift detection + performance + robustness anchors demonstrates a complete post-market monitoring pipeline. Include the monitoring cadence (e.g., continuous inference-level vs. daily batch) and any threshold breaches that triggered remediation.
RFI asks: What does your training data contain?
AI-DATA.1 witnesses data provenance (where training data originated). AI-DATA.2 records data lineage (how data was transformed). AI-DATA.3 witnesses data quality assurance processes. AI-DATA.4 records privacy compliance measures applied to training data. These four procedures address the copyright strand's training data questions and the transparency obligations under Article 53(1)(b).
For the copyright strand, AI-DATA.1 provenance records are particularly important. They document the sources of training data without revealing the data itself. At Clearing Level 2 and above, raw data references are stripped from the anchor, preserving compliance evidence while protecting proprietary training sets.
RFI asks: Provide technical documentation for each GPAI model.
AI-MDL.5 records a cryptographic hash of model weights at a specific point in time. AI-MDL.6 witnesses the adapter stack (LoRA, fine-tuning layers) applied to the base model. AI-MDL.7 records quantization parameters. Together they provide a verifiable technical fingerprint of the exact model configuration that was deployed, linking the model documentation to a specific model state.
RFI asks: How do you meet Article 50 and Article 53 transparency requirements?
AI-TRANS.1 witnesses transparency disclosures: what information was provided to deployers and end users about the model's capabilities, limitations, and intended use. AI-EXPL.1 records the explainability method used and its coverage. These procedures address both the Article 50 (AI-generated content labeling) and Article 53(2) (downstream provider information) obligations.
RFI asks: What information do you provide to downstream AI system providers?
AI-CHAIN.1 witnesses the handoff of a model or inference result from one provider to another in a multi-provider chain. AI-CHAIN.2 correlates evidence across chain boundaries. When a GPAI model feeds into a downstream high-risk AI system, these anchors prove that the required information (Article 53(2)) was transmitted to the downstream provider at a specific time.
RFI asks: What measures mitigate systemic risks including CBRN, cyber, loss of control, and manipulation?
AI-SAFE.1 witnesses safe-state recovery mechanisms: if the model enters a dangerous operating state, this procedure records whether the system can return to a known-safe configuration. AI-INCIDENT.1 documents incidents including severity classification, incident type, affected scope, and notification timestamps. For systemic risk models, these procedures provide evidence that risk mitigation measures are operational, not just documented in a framework.
The Safety and Security Model Report required under the Code of Practice Chapter 3 should reference AI-SAFE.1 and AI-INCIDENT.1 anchor chains. Include any incidents that occurred since August 2, 2025 (when obligations first took effect) and the corresponding response evidence.
RFI asks: How do you report material changes to models already on the market?
AI-REV.1 records the revocation of a previous witness anchor with one of seven standardized reason codes: model recall, policy violation, data contamination, consent withdrawal, regulatory order, error correction, or unspecified. When a material change invalidates prior compliance evidence, AI-REV.1 creates a verifiable record of when the change was recognized and what evidence was superseded.
Include all AI-REV.1 anchors from the RFI period. Revocations demonstrate active governance: a provider that revokes and re-assesses is more compliant than one that never revokes because it never detects problems. The 14-day materiality disclosure obligation under Article 53(1)(d) maps directly to AI-REV.1 timestamps.
GPAI providers operate across multiple jurisdictions. The EU AI Office's RFIs may require evidence that spans EU, US, and APAC deployments. SWT3 handles this through two mechanisms:
Every witness anchor can carry Cross-Jurisdictional Transparency (CJT) fields: jurisdiction (ISO 3166-1 country code), legal_basis (e.g., "GDPR Art. 6(1)(f)"), and purpose_class (the processing purpose). These fields survive all four clearing levels, ensuring that jurisdictional context is preserved even when other data is redacted for privacy.
When preparing RFI responses, clearing levels determine how much operational detail is included in the evidence:
The AI Office receives the same cryptographic proof of compliance at every clearing level. The difference is the amount of operational detail visible in the anchor payload.
The GPAI Code of Practice (final version published July 10, 2025) provides the compliance framework that Article 91 RFIs are designed to verify. Providers who signed the Code of Practice committed to specific obligations across three chapters:
The Article 91 RFIs ask providers to demonstrate compliance with these commitments. SWT3 witness anchors serve as the evidence layer: each Code of Practice obligation maps to one or more SWT3 procedures that produce verifiable proof of compliance.
For a detailed mapping of Code of Practice obligations to SWT3 procedures, see the GPAI Code of Practice Mapping guide.
from swt3_ai import Witness
w = Witness(
tenant_id="EU_GPAI_PROVIDER",
api_key="your-api-key",
endpoint="https://sovereign.tenova.io/api/v1/witness",
jurisdiction="EU",
legal_basis="AI Act Art. 53",
purpose_class="gpai_compliance"
)
# Witness guardrail integrity (AI-GRD.1)
w.record("AI-GRD.1",
factor_a="guardrail_framework_v3.2",
factor_b="prompt_injection_test_suite_2026Q3",
factor_c="PASS:847/850")
# Witness red-team evaluation (AI-REDTEAM.1)
w.record("AI-REDTEAM.1",
factor_a="external_redteam_org:TechAudit_GmbH",
factor_b="attack_surface:cbrn,cyber,manipulation",
factor_c="PASS:report_ref:TA-2026-0914")
# Witness post-launch drift monitoring (AI-DRIFT.1)
w.record("AI-DRIFT.1",
factor_a="model:gpt-frontier-v4",
factor_b="accuracy_drift:0.003",
factor_c="within_threshold:0.01")
w.flush()
import { Witness } from '@tenova/swt3-ai';
const w = new Witness({
tenantId: 'EU_GPAI_PROVIDER',
apiKey: 'your-api-key',
endpoint: 'https://sovereign.tenova.io/api/v1/witness',
jurisdiction: 'EU',
legalBasis: 'AI Act Art. 53',
purposeClass: 'gpai_compliance'
});
// Witness guardrail integrity (AI-GRD.1)
w.record('AI-GRD.1', {
factorA: 'guardrail_framework_v3.2',
factorB: 'prompt_injection_test_suite_2026Q3',
factorC: 'PASS:847/850'
});
// Witness red-team evaluation (AI-REDTEAM.1)
w.record('AI-REDTEAM.1', {
factorA: 'external_redteam_org:TechAudit_GmbH',
factorB: 'attack_surface:cbrn,cyber,manipulation',
factorC: 'PASS:report_ref:TA-2026-0914'
});
// Witness post-launch drift monitoring (AI-DRIFT.1)
w.record('AI-DRIFT.1', {
factorA: 'model:gpt-frontier-v4',
factorB: 'accuracy_drift:0.003',
factorC: 'within_threshold:0.01'
});
await w.flush();
| RFI Question Area | Strand | SWT3 Procedure(s) | Evidence Type | Coverage |
|---|---|---|---|---|
| Model defense against attacks | Safety | AI-GRD.1, AI-GRD.2, AI-GRD.3 | Guardrail integrity anchors | Full |
| Security posture | Safety | AI-SEC.1, AI-CYBER.1 | Security config + vuln assessment | Full |
| Independent expert evaluation | Safety | AI-REDTEAM.1 | Third-party red-team anchors | Full |
| Audit chain integrity | Both | AI-AUDIT.1 | Tamper detection evidence | Full |
| Post-launch monitoring | Safety | AI-DRIFT.1, AI-DRIFT.2 | Drift detection + thresholds | Full |
| Performance monitoring | Safety | AI-PERF.1, AI-ROBUST.1 | Accuracy + robustness metrics | Full |
| Training data contents | Copyright | AI-DATA.1, AI-DATA.2 | Provenance + lineage records | Full |
| Data quality and privacy | Copyright | AI-DATA.3, AI-DATA.4 | Quality + privacy compliance | Full |
| Model weights documentation | Both | AI-MDL.5, AI-MDL.6, AI-MDL.7 | Hash, adapter, quantization | Full |
| Transparency (Art. 50/53) | Transparency | AI-TRANS.1, AI-EXPL.1 | Disclosure + explainability | Full |
| Downstream notification | Transparency | AI-CHAIN.1, AI-CHAIN.2 | Chain handoff records | Full |
| Systemic risk mitigation | Safety | AI-SAFE.1 | Safe-state recovery evidence | Full |
| Incident reporting | Both | AI-INCIDENT.1 | Severity + notification times | Full |
| Material change reporting | Both | AI-REV.1 | Revocation with reason codes | Full |
| Cross-jurisdictional context | Both | CJT metadata | Jurisdiction + legal basis | Full |
Article 91 RFIs are the first step in an enforcement pipeline. When the AI Office determines that RFI responses are insufficient, the next phase is Article 92 evaluation.
When Scientific Panel experts conduct an Article 92 evaluation, they need verifiable evidence that compliance measures were active during the period under review. SWT3 anchors provide this: every anchor carries a timestamp, a procedure identifier, and a cryptographic fingerprint that can be independently verified via the public verification endpoint. The evaluator does not need to trust the provider's claims. The evidence is structurally independent.
Non-compliance with GPAI obligations (Articles 53, 55) carries fines of up to 3% of global annual turnover or EUR 15 million. For the largest GPAI providers, this represents billions in potential exposure. The AI Office has also announced it is hiring 40 additional enforcement staff, signaling sustained enforcement capacity through Q4 2026 and beyond.