General-Purpose AI Code of Practice

• General-Purpose AI Code of Practice is a comprehensive framework outlining obligations for transparency, human oversight, and systematic risk management in large-scale AI systems.
• It aligns regulatory elements from the EU AI Act with standards like NIST and ISO, integrating ethical principles such as autonomy, beneficence, and accountability.
• The framework emphasizes iterative risk assessment, advanced uncertainty and robustness controls, and clear role differentiation between providers and deployers.

A General-Purpose AI Code of Practice denotes an actionable, end-to-end framework for organizations that develop or deploy large-scale general-purpose AI models and systems. In the cited literature, it is presented not as a single metric or isolated control, but as a structured set of obligations spanning design, data curation, model development, evaluation, release, deployment, monitoring, documentation, and governance. Under the EU AI Act, this framework is anchored in provisions on transparency and documentation, human oversight, accuracy, robustness, and cybersecurity, and it becomes more stringent for any general-purpose AI whose cumulative training compute exceeds $10^{25}$ FLOPS and is therefore treated as a “GPAI with systemic risk” (Valdenegro-Toro et al., 2024).

1. Regulatory setting and scope

The legal and institutional background of a GPAI Code of Practice is defined primarily by the EU AI Act’s treatment of general-purpose models and by adjacent risk-management standards. A General-Purpose AI model is described as one trained on large-scale data, using self-supervision at scale, displaying generality, and performing a wide range of tasks; parallel formulations describe GPAI or foundation models as trained on broad, large-scale data and adaptable to many downstream tasks (Valdenegro-Toro et al., 2024). The relevant obligations include provider-facing transparency and documentation duties, requirements for human oversight, and accuracy, robustness, and cybersecurity obligations, with systemic-risk provisions applying automatically once the $10^{25}$ FLOPS threshold is crossed (Valdenegro-Toro et al., 2024).

Outside the EU legal text itself, proposed codes of practice are commonly aligned with the NIST AI Risk Management Framework and ISO/IEC 23894. In that alignment, GPAI-specific extensions are required for emergent capabilities and vulnerabilities, large-scale misuse scenarios such as automated disinformation and CBRN or cyber weapon design, and release-strategy questions such as open-weights versus structured-access deployment (Barrett et al., 30 Jun 2025). This positions the code of practice as an interface between abstract regulation and operational controls.

The scope is broader than model training alone. The literature explicitly treats GPAI systems as AI systems built around a GPAI model and capable of accomplishing diverse tasks, including unintended ones. Consequently, the code of practice applies not only to frontier model providers but also to downstream developers and deployers who shape application-specific behavior, user interaction, logging, human oversight, and context-specific risk treatment (Barrett et al., 30 Jun 2025).

2. Normative architecture and conceptual foundations

Across the literature, the normative structure of a GPAI Code of Practice is multi-layered. One strand organizes trustworthiness around four overarching values—Autonomy, Beneficence, No-Harm, and Accountability—refined into six requirements: Human Oversight and Control, Impact Mitigation and Robust Deployment, Open Development and Transparent Reporting, Privacy, Diversity, and Accessibility in, by, and for Design, Ethical Stakeholder Inclusion and Co-creation, and Democracy and Human Rights (Corrêa et al., 2024). A second strand operationalizes the Blueprint for an AI Bill of Rights through five principles: Safety, Privacy, Explainability, Fairness, and Human Oversight/Fallback (Oesterling et al., 2024). A third strand analyzes GPAI under eight responsible-AI principles: fairness, privacy, explainability, robustness, safety, truthfulness, governance, and sustainability (Patro et al., 19 Jan 2026).

A distinctive conceptual contribution is the formalization of the “Degree of Freedom in Output” (DoFo), intended to explain why responsible-AI problems are amplified in general-purpose systems. Let $f$ be a general-purpose AI system, $x$ its input, and $y=f(x)$ its free-form output. Then

$$\mathrm{DoFo}(f)=\max_x \dim(\text{affine hull of } Y_x),$$

where $Y_x$ is the set of possible outputs for input $x$. The cited formulation contrasts low-DoFo classification and regression settings with text generation, for which $\mathrm{DoFo}\to\infty$ (Patro et al., 19 Jan 2026). On this view, open-ended generation increases the space in which stereotypes, memorization leakage, hallucinations, plausible but unfaithful explanations, jailbreaks, sycophancy, provenance gaps, and token-level inference costs can arise.

To respond to that problem, one proposal derives the C²V² desiderata: Control, Consistency, Value, and Veracity. Control governs whether the system answers, declines, escalates, or accesses tools; Consistency requires stable behavior across similar contexts; Value enforces a value system such as non-discrimination or confidentiality; and Veracity requires grounding in verified facts or evidence (Patro et al., 19 Jan 2026). This suggests that a GPAI Code of Practice is best understood not merely as a compliance checklist but as a system architecture for constraining high-DoFo behavior.

3. Lifecycle governance and risk-management structure

Operational proposals for GPAI codes of practice are strongly lifecycle-oriented. One recurring structure is an iterative four-phase cycle: Identify, Analyze/Assess, Mitigate/Respond, and Monitor. In the NIST AI RMF vocabulary, these are coupled to GOVERN, MAP, MEASURE, and MANAGE functions, with explicit practices for contextual risk identification, trustworthiness evaluation, prioritization, treatment, monitoring, and feedback loops (Barrett et al., 30 Jun 2025). Formal quantitative risk assessment is summarized as

$\text{Risk}=\text{Likelihood}\times\text{Impact}.$

Within this lifecycle, the Identify phase enumerates intended purposes, foreseeable uses, misuses, and abuses; documents user groups, legal and ethical norms, and potential human-rights impacts; defines unacceptable-risk thresholds and “go/no-go” criteria; and classifies use cases via an AI-system taxonomy. The Analyze/Assess phase adds red-teaming, adversarial testing, trustworthiness measurement, and explicit documentation of “unmeasurable” risks in a risk register. The Mitigate/Respond phase specifies risk treatment, staged release, structured access, rate-limiting, watermarking, incident response, deactivation criteria, and third-party risk management. The Monitor phase instruments telemetry, reassesses emergent risks, updates risk registers, and feeds new incidents back into model cards and system cards (Barrett et al., 30 Jun 2025).

A complementary safety-and-security interpretation of the EU GPAI Code of Practice breaks this governance structure into sixteen commitments. These begin with adoption of a Safety and Security Framework, continue through lifecycle-wide systemic risk assessment, systemic risk identification, analysis, acceptance determination, safety mitigations, security mitigations, model reports, adequacy assessments, responsibility allocation, independent external assessors, serious-incident reporting, non-retaliation protections, notifications, documentation, and public transparency (Stelling et al., 21 Apr 2025). This decomposition makes explicit that a code of practice is simultaneously a governance document, an evaluation protocol, and an incident-management regime.

Several proposals also specify organizational roles. Upstream developers are tasked with cross-domain misuse analysis and maintenance of the risk registry; downstream developers identify context-specific end-use risks; risk-management teams or chief risk officers update tolerance thresholds; ethics and human-rights review boards advise on impact assessment; release committees enforce “go/no-go” decisions; and external audit partners perform independent safety and compliance audits (Barrett et al., 30 Jun 2025). The resulting structure is institutional as well as technical.

4. Technical controls, evaluation methods, and operational metrics

The technical core of many GPAI codes of practice is measurement and control of uncertainty, robustness, privacy, fairness, explanation quality, and factual grounding. One proposal argues that uncertainty estimation should be a required component for deploying models in the real world because it can support transparency, accuracy, trustworthiness, human oversight, and risk management under the EU AI Act (Valdenegro-Toro et al., 2024). The central quantities are the predictive distribution $10^{25}$0, predictive entropy

$10^{25}$1

the predictive mean

$10^{25}$2

and the predictive variance

$10^{25}$3

The cited method classes include full Bayesian inference, Laplace approximation, variational inference, deep ensembles, MC-Dropout with typical $10^{25}$4, and single-forward-pass DUQ or DDU architectures with lower overhead but classification-only applicability (Valdenegro-Toro et al., 2024).

Robustness and safety controls extend beyond uncertainty. The cited operational literature includes adversarial training, certified robustness via randomized smoothing, and Distributionally Robust Optimization, together with internal audits using SMACTR, external red-teaming, drift detection, rollback or human flagging below performance thresholds, and generative-AI-specific controls such as retrieval-augmented generation, model editing, RLHF fine-tuning, safety classifiers, and prompt filters (Oesterling et al., 2024). Another system-design proposal maps C²V² to concrete components: guardrails or prompt filters, Attribute-Based Access Control, Retrieval-Augmented Generation, neurosymbolic reasoning, RLHF or DPO for value alignment, custom value-check modules, self-verification, and chain-of-thought plus self-consistency for cross-checking facts (Patro et al., 19 Jan 2026).

Privacy-preserving controls are equally prominent. Operational recommendations include privacy-by-default consent flows, data minimization, encryption at rest and in transit, federated learning, DP-SGD, inference-time noise for $10^{25}$5-DP, exact or approximate unlearning, deletion-request audit logs, and evaluation under black-box and white-box membership inference attacks (Oesterling et al., 2024). Fairness controls include pre-processing, in-processing, and post-processing interventions, as well as continuous monitoring of subgroup disparities (Oesterling et al., 2024).

For fairness evaluation in GPAI specifically, one proposal requires model-level reporting of Demographic Parity Difference and Equal Opportunity Difference,

$10^{25}$6

$10^{25}$7

along with a Representational Bias Score for generative output based on the KL divergence between conditional token distributions under demographic prompts (Raman et al., 6 Oct 2025). These metrics are meant to be reported on both synthetic benchmarks such as counterfactual pairs and on available naturalistic validation sets.

5. Division of responsibilities between providers and deployers

A recurring feature of GPAI codes of practice is role differentiation. Providers control pretraining data, architecture choices, fine-tuning pipelines, guardrails, and release artifacts; deployers control application context, personalization, human review procedures, post-deployment monitoring, and downstream mitigations. The literature therefore assigns distinct but linked obligations to each side of the supply chain (Raman et al., 6 Oct 2025).

For providers, required disclosures include model cards and provenance statements reporting training data sources, known limitations, intended deployment contexts or domains, and summaries of fine-tuning and safety interventions. Providers are also asked to maintain a supply-chain registry of major deployers or integrators categorized by domain. Their evaluative research agenda includes measuring bias persistence through pretraining-to-fine-tuning pipelines using model-level disparity correlation, perturbing fine-tuning size and composition to study changes in performance gaps, and adversarial red-teaming of safety and fairness guardrails (Raman et al., 6 Oct 2025).

For deployers, the emphasis shifts toward context capture and real-world evaluation. Deployers are asked to collect demographic attributes only when necessary and with consent, disclose whether and how personalization uses past interactions, publish or otherwise disclose system prompts affecting personalization, and maintain an internal registry of application domains and downstream model modifications. Their evaluation program is layered across pre-deployment versus post-deployment, naturalistic versus non-naturalistic data, and internal versus external assessment. The cited examples include A/B tests with demographic slices, adverse event reporting, incident aggregation, internal regression tests, third-party audits, and sanctioned fairness bug bounties (Raman et al., 6 Oct 2025).

Actor	Core disclosures	Core evaluation and controls
Provider	Model cards, provenance, known limitations, intended contexts, supply-chain registry, guardrail summaries	Bias-persistence studies, fine-tuning perturbation studies, adversarial red-teaming, public DPD/EOD/RBS reporting
Deployer	User-group labels with consent, personalization parameters, system prompts, use-case catalog	Pre/post-deployment testing, naturalistic and synthetic evaluation, A/B tests, AER, internal monitoring, third-party audits

Human oversight is distributed across both roles. Under the EU AI Act, systems must enable users to interpret outputs, intervene, override, or stop the system to prevent harm (Valdenegro-Toro et al., 2024). Operational guidance therefore recommends confidence-based alerts, “I don’t know” responses, reject-option or selective-classification regions, one-click pathways to request human review, reviewer training, and audit trails of escalations and overrides (Oesterling et al., 2024). This turns the code of practice into a socio-technical design for fallback, not merely a documentation obligation.

6. Documentation, external scrutiny, and unresolved tensions

Documentation is one of the most stable elements across proposals. Recurrent artifacts include model cards, data sheets or datasheets, bias reports, broader impact reports, system cards, risk registers, transparency reports, and, in the EU safety-and-security framing, dedicated Safety and Security Model Reports for each systemic-risk GPAI placed on the market (Corrêa et al., 2024). These documents are expected to cover capabilities, limitations, intended and out-of-scope uses, performance metrics, fairness and privacy metrics, red-team findings, residual risks, and release justifications.

External scrutiny is treated as necessary but unevenly implemented. In the safety-and-security commitment structure, independent external systemic-risk assessments are required before market placement of a GPAISR unless the model is safely derived or similarly safe to another GPAISR, and exploratory external assessments are to be facilitated post-release (Stelling et al., 21 Apr 2025). The same framework also requires adequacy assessments, serious-incident reporting, non-retaliation protections for workers reporting systemic risks, notifications to the AI Office, retention of documentation, and public transparency through publication of frameworks and model reports or summaries (Stelling et al., 21 Apr 2025).

Industry evidence shows partial convergence and substantial gaps. The cited review finds strong precedents for frontloaded risk work, lifecycle risk assessment, qualitative risk-acceptance tiers, and technical security mitigations. It also finds that full public Model Reports are, at present, only fully realized by OpenAI and Anthropic; formal external assessor programs are limited; public evidence of notification to the EU AI Office is absent across providers surveyed; and non-retaliation protections, adequacy-assessment schedules, and model-specific public transparency remain uneven (Stelling et al., 21 Apr 2025). This suggests that the most mature part of current practice lies in internal framework construction, while external accountability mechanisms remain less standardized.

The literature also emphasizes persistent trade-offs. One paper identifies a specific dilemma: uncertainty estimation can improve compliance with transparency, accuracy, and trustworthiness requirements, yet ensemble or MC-Dropout methods multiply compute by $10^{25}$8, and even training-time uncertainty methods can add $10^{25}$9-fold cost; this may push cumulative compute over the $f$0 FLOPS threshold and reclassify the model as a systemic-risk system subject to stricter obligations (Valdenegro-Toro et al., 2024). Other documented tensions include fairness versus privacy when subgroup labels are needed for auditing but raise data-protection concerns, explainability versus robustness when detailed explanations aid adversaries, transparency versus security when robustness disclosures can expose internals, human fallback versus over-reliance when explanations inflate trust, and sustainability versus capability when token-by-token generation and large-model deployment drive energy and carbon costs (Oesterling et al., 2024). In the responsible-AI literature on GPAI, these tensions are traced back to high output DoFo and the need for control, consistency, value enforcement, and veracity checks across the full system stack (Patro et al., 19 Jan 2026).

A plausible implication is that a mature GPAI Code of Practice must remain dynamic. The cited proposals repeatedly describe it as a living document or a process for periodic updating, tied to incident learning, re-evaluation, evolving standards, and new technical specifications (Oesterling et al., 2024). In that sense, the code of practice functions as a continuously revised operating constitution for general-purpose AI.