What Should Frontier AI Developers Disclose About Internal Deployments?

Technical Summary: What Should Frontier AI Developers Disclose About Internal Deployments?

Problem Statement

As frontier AI developers advance, they increasingly rely on Internally Deployed Models (IDMs) to automate critical tasks such as machine learning engineering (MLE), AI research and development (AI R&D), training data generation, and model evaluation. Unlike public-facing models, IDMs operate within the "black box" of a lab’s private infrastructure.

This lack of visibility creates significant information asymmetries that prevent policymakers and the public from assessing systemic risks. The authors identify several critical risks associated with IDMs:

• Security & Misuse: Models exploiting privileged access to sensitive infrastructure (e.g., model weights or training pipelines).
• Alignment & Autonomy: Models autonomously pursuing misaligned goals or engaging in recursive self-improvement.
• Safety Degradation: Models potentially poisoning training data or inserting vulnerabilities into code used for successor models.
• Concentration of Power: Insiders using highly capable systems without external oversight.

Current regulatory frameworks (e.g., California’s SB 53, NY RAISE, and the EU GPAI Code of Practice) mandate some level of reporting but lack specific guidance on what technical information regarding internal deployments should actually be disclosed.

Methodology

The authors employ a framework-based approach to bridge the gap between high-level regulatory requirements and actionable technical disclosure. Their methodology involves:

1. Defining IDMs: They define IDMs based on the tasks they perform (privileged tasks that shape R&D or infrastructure) rather than just whether they are exclusive to the organization, ensuring safety-critical models are captured.
2. Categorization: They organize potential disclosures into four functional dimensions: Capabilities, Usage, Safety Mitigations, and Governance.
3. Risk-Benefit Analysis: For every proposed disclosure, the authors perform a dual-sided analysis, weighing the oversight benefits (e.g., tracking capability jumps) against disclosure risks (e.g., intellectual property theft, revealing security vulnerabilities, or exacerbating competitive "race dynamics").
4. Mitigation Strategy Design: They propose practical mechanisms to balance transparency with security, such as tiered disclosure (public summaries vs. private, encrypted reports to regulators).

Key Contributions

The primary contribution is a comprehensive disclosure framework (summarized in Table 1 of the paper) that provides specific examples of what should be reported:

• Capabilities: Benchmarking on autonomous-relevant tasks (e.g., SWE-Bench Pro), compute allocation (FLOPs/GPU-hours) for internal vs. external models, and divergence from public model families.
• Usage: Task types (coding, R&D, data gen), levels of autonomy (unsteered duration), and the proportion of human review in the training pipeline.
• Safety Mitigations: Details on output monitoring, stress-testing results (red-teaming), and scores on misalignment/monitorability evaluations.
• Governance: Prohibited uses (e.g., self-modification of weights), access control (who has access and at what seniority), and incident reporting/response protocols.

Additionally, the paper proposes a reporting architecture:

• Format: Standalone periodic reports (every 90 days or upon significant change) rather than just model system cards.
• Audience: A two-tiered approach involving high-level public reports and detailed, confidential reports to trusted third-party auditors and regulators.

Results and Discussion

The paper concludes that while disclosure carries risks, these are manageable through established auditing practices.

• Mitigating IP/Security Risks: Developers can use "redacted summaries" for the public and "secure document management" (encrypted transfers) for regulators.
• Mitigating Competitive Pressure: Normalizing compute data or reporting on a delay can prevent immediate competitive retaliation.
• Mitigating Reputational Risk: The authors argue that identifying vulnerabilities early through disclosure is in the developer's long-term interest to prevent catastrophic failures.

Significance

This paper is highly significant for the field of AI Governance and Safety. It moves the conversation from the abstract ("we need more transparency") to the concrete ("we need to report on the ratio of unsteered model autonomy in the training pipeline").

By providing a standardized taxonomy for IDM disclosure, the work serves as a technical roadmap for:

1. Regulators to draft more precise and effective legislation.
2. Developers to build robust, transparent internal safety cultures.
3. Third-party Auditors to develop standardized methodologies for evaluating the safety of the AI development process itself.