⚡ Quick Summary
Published by GovAI, this policy brief examines what Measure 7.1, point (4) of the EU GPAI Code of Practice requires Signatories to include in Model Reports for general-purpose AI models with systemic risk (GPAISR). It treats a model specification as a description of intended model behaviour, encompassing principles, the prioritisation of principles and instructions, refusal topics, and the system prompt. The brief argues that the requirement’s purpose is to enable the EU AI Office (AIO) to assess whether a Signatory’s systemic-risk mitigations are appropriate.
On that reading, it advances four criteria: record all intended behaviour with a significant effect on systemic risk; give enough detail on principles to reveal material risk implications; state how significant conflicts between principles and instructions are managed; and provide system prompts for every AI system through which the Signatory integrates the model. These are collated into a rubric in Table 1, intended to inform Signatory compliance and AIO interpretation. The brief also says the Code can be a benchmark for non-Signatory frontier AI companies’ compliance with EU AI Act obligations.
🧩 What’s Covered
The brief proceeds from the Code’s terminology and stated reporting context to a proposed interpretation of four requirements.
- Scope and key terms: Introduces GPAISR and Measure 7.1, point (4), then defines principles as rules for model behaviour, instructions as directions from users, downstream developers or external data sources, refusal topics, and system prompts.
- Purpose of model specifications: Argues that specifications help the AIO assess whether mitigations match the systemic risks posed by a model. It describes specs both as possible safety mitigations and as baselines for detecting problematic deviations from intended behaviour.
- Significant intended behaviour: Proposes that a spec include all intended principles, prioritisation and refusal topics with a significant impact on systemic risk. It identifies public capability advertisements, Safety and Security Frameworks, and Model Reports as possible evidence of omitted intentions.
- Detail in principles: Discusses ambiguity in high-level restrictions, using CBRN-related assistance as an example. It proposes descriptions, examples or exceptions where details could materially affect systemic risk, particularly for principles related to risks in Appendix 1.4, such as loss of control.
- Managing conflicts: Explains why principles and instructions can conflict, and argues that specifications should address significant potential conflicts rather than document every possible pair. Examples include honesty versus avoiding information hazards, user instructions versus safeguards, and user instructions versus external data such as prompt injections.
- System prompts and verification: Argues for including prompts for all of a Signatory’s integrated AI systems, rather than a single prompt. It suggests checking whether submitted prompts are current, considering potentially unreliable third-party extractions, and requesting documentation on controls against unauthorised prompt changes.
- Conclusion and rubric: Restates the four proposed requirements and presents Table 1 as assessment questions covering inclusion, thoroughness, conflict management and system-prompt coverage.
💡 Why it matters?
For teams preparing Model Reports, the brief turns a short Code provision into concrete documentation questions: whether material intended behaviours are absent, whether safety-relevant principles are sufficiently precise, whether priority rules address consequential conflicts, and whether deployment prompts are complete. It links these questions to the AIO’s assessment of systemic-risk mitigations rather than treating a model specification as a stand-alone disclosure. The discussion is also relevant to system-prompt governance, since differences among web, mobile and API deployments can affect the mitigations visible to an assessor.
❓ What’s Missing
The brief explicitly frames its conclusions as arguments about what the Code “likely” requires, rather than legal advice, and states that it represents the author’s views rather than those of GovAI. Its analysis concentrates on Measure 7.1, point (4); Measure 10.1 appears only as a possible basis for requesting additional system-prompt information. The rubric consists of assessment questions rather than a scored methodology. The document does not provide scoring thresholds, a completed assessment of a Model Report, or an empirical test of the criteria. It also notes that third-party extracted prompts may be unreliable without setting out a procedure for resolving contradictory prompt evidence.
👥 Best For
This brief is best suited to compliance and safety leads preparing GPAISR Model Reports, AIO staff interpreting model-specification disclosures, and governance teams maintaining system prompts across web, mobile and API deployments. It is also useful for reviewers assessing whether stated model behaviour and systemic-risk mitigations are documented consistently.
📄 Source Details
Requirements for Model Specifications in the EU GPAI Code of Practice is an English-language policy brief by Alan Chan, published by GovAI in March 2026. The supplied complete PDF has 11 pages, including a cover; its internal pagination runs from pages 1 to 10. The document states that GovAI policy briefs have not undergone an official peer-review process.
