The European Commission has issued its first formal requests for information to General-Purpose AI Model providers under Article 90 of the EU AI Act. If you're facing one of these requests, or expect to, you need a structured response framework that meets regulatory expectations while safeguarding operational details you're not required to disclose.
This template helps you respond to Commission information requests about cybersecurity practices, external evaluation access, and post-market monitoring. It's built around the three focus areas Tech Commissioner Henna Virkkunen identified in recent enforcement actions: model theft prevention, evaluator access protocols, and public usage monitoring.
Purpose of This Template
Use this template when responding to:
- Article 90 requests for information from the AI Office
- Follow-up inquiries about systemic risk mitigation under Article 91
- Pre-enforcement dialogue about General-Purpose AI Model compliance
The template structures your response around what the Commission can legally request under the AI Act, not what a vendor questionnaire might ask. It separates mandatory disclosures from optional context, so you know where you have discretion.
Prerequisites
Before drafting your response:
Confirm the legal basis. The request should cite Article 90 and specify which obligations it's examining. If it doesn't, ask for clarification before responding.
Identify your disclosure authority. Determine who can approve statements about model security architecture, red teaming protocols, or monitoring thresholds. Involve them early.
Gather existing documentation. You'll need your Technical Documentation (Annex IV if classified as high-risk), your systemic risk assessment if you're above the 10^25 FLOP threshold, and any post-market monitoring reports you've generated.
Check your timeline. The Commission sets response deadlines in the request. Unanswered requests can lead to fines of up to 3% of annual turnover, so mark the deadline and allow time for review.
The Template
RESPONSE TO EUROPEAN COMMISSION REQUEST FOR INFORMATION
Article 90, EU AI Act
Provider: [Your legal entity name]
Model(s) in scope: [Specific model names and versions]
Request reference: [Commission reference number]
Response date: [Date]
---
SECTION 1: MODEL SECURITY AND THEFT PREVENTION
1.1 Access Control Architecture
We implement [describe your access control model: role-based, attribute-based, zero-trust] with the following controls:
- [Technical control 1]
- [Technical control 2]
- [Technical control 3]
1.2 Model Weight Protection
Our model weights are protected through:
- Storage: [encryption standard, key management approach]
- Transit: [protocol, authentication requirements]
- Inference: [describe whether weights are exposed during inference, any obfuscation]
1.3 Automated Threat Detection
We monitor for unauthorized access attempts using:
- [Detection system 1 and what it monitors]
- [Detection system 2 and what it monitors]
- Alert threshold: [describe when human review is triggered]
1.4 Incident Response Protocol
When unauthorized access is detected:
- [Step 1 and responsible role]
- [Step 2 and timeline]
- [Notification protocol for the Commission if systemic risk is implicated]
---
SECTION 2: EXTERNAL EVALUATOR ACCESS
2.1 Evaluation Framework
We provide external evaluators with:
- Access type: [API access, model weights, structured red teaming environment]
- Scope: [which capabilities can be tested, any exclusions]
- Duration: [typical engagement length]
2.2 Evaluator Qualification
We grant access to evaluators who meet:
- [Criterion 1: technical capability, independence, etc.]
- [Criterion 2]
- [Criterion 3]
Current qualified evaluators: [list or state "available upon follow-up request if relevant to specific systemic risk concern"]
2.3 Evaluation Cadence
- Pre-deployment: [describe evaluation requirements before release]
- Post-deployment: [ongoing evaluation frequency]
- Trigger events: [circumstances requiring additional evaluation]
2.4 Evaluation Results Integration
We incorporate evaluator findings by:
- [Process for reviewing findings]
- [Decision framework for mitigation]
- [Documentation approach]
---
SECTION 3: POST-MARKET MONITORING
3.1 Usage Monitoring Scope
We monitor the following aspects of public model usage:
- [Metric 1 and collection method]
- [Metric 2 and collection method]
- [Metric 3 and collection method]
3.2 Systemic Risk Indicators
We track indicators of systemic risk related to:
- Public health: [specific indicators]
- Safety: [specific indicators]
- Fundamental rights: [specific indicators]
- Democratic processes: [specific indicators]
- Environment: [specific indicators]
3.3 Threshold and Response Protocol
When monitoring detects [describe threshold or pattern]:
- [Immediate response action]
- [Investigation protocol]
- [Mitigation decision framework]
- [Timeline for Commission notification under Article 91(3)]
3.4 Monitoring Infrastructure
Our monitoring infrastructure includes:
- [Technical capability 1]
- [Technical capability 2]
- [Human review integration point]
---
SECTION 4: ADDITIONAL CONTEXT [OPTIONAL]
[Use this section for information that provides helpful context but isn't directly responsive to the request. Examples: relevant certifications, voluntary commitments, participation in industry safety initiatives.]
---
SECTION 5: REQUESTS FOR CLARIFICATION
We request clarification on the following aspects of this information request:
- [Question 1]
- [Question 2]
---
ATTACHMENTS
[List any supporting documentation you're including: excerpts from Technical Documentation, summaries of red teaming results, incident response runbooks, etc.]
---
AUTHORIZED SIGNATORY
[Name, title, date]
[Contact information for follow-up]
How to Customize It
Section 1 (Model Security): If you're using a research model internally that might fall under the Act's scope, describe how you prevent that model from being integrated into a system placed on the market without appropriate controls. The Commission hasn't ruled out applying the Act to internal models where they're integrated into deployed systems.
Section 2 (Evaluator Access): You're not required to give every researcher full model weights. Describe what level of access enables meaningful evaluation of the specific risks your model poses. If your model is below the 10^25 FLOP threshold, you have more discretion here.
Section 3 (Monitoring): Connect your monitoring to the five systemic risk categories in Article 3(65). If you can't monitor for a particular risk category, explain why it's not applicable to your model's capabilities rather than leaving it unaddressed.
Section 5 (Clarification Requests): Use this strategically. If the request asks for information you believe exceeds the Commission's authority under Article 90, ask for the legal basis. If it's unclear which model version is in scope, ask for specificity.
Validation Steps
Before you submit:
Cross-check against your Technical Documentation. Your response shouldn't contradict what's in your Annex IV documentation or systemic risk assessment. If it does, update the underlying documentation first.
Verify you haven't over-disclosed. You're required to provide information the Commission needs to assess compliance. You're not required to provide competitive intelligence, customer lists, or detailed architecture beyond what's necessary to understand your controls.
Confirm your timeline claims are defensible. If you say you'll notify the Commission within 24 hours of detecting a systemic risk incident, make sure your incident response process actually supports that timeline.
Test your monitoring threshold descriptions. Can you actually detect the patterns you're describing? If your monitoring infrastructure can't support the thresholds you've documented, the Commission will discover that gap during an evaluation under Article 91.
Review with legal counsel. Your response is an official statement to a regulatory authority. Get legal sign-off before submission, especially on sections describing incident response obligations and systemic risk notification triggers.
The Commission's enforcement approach is still taking shape, but one pattern is already clear: they're focused on the gap between what providers document and what they actually do. Your response should describe controls you've implemented, not controls you're planning to implement. If you're still building out your monitoring infrastructure or evaluator access protocols, say so and provide a timeline. That's better than describing capabilities you can't yet demonstrate.
