Independent AI evaluations: who controls what gets published?

Independence requires more than using an outside organisation

A third-party label does not itself establish independence. The evaluator may depend on the developer for funding, model access, data, staff interviews, future work and permission to publish. Those dependencies can shape the scope, methods, wording and findings even without an express instruction to change a conclusion.

A September 2026 public letter from the AI Evaluator Forum, signed by more than 200 researchers, proposed minimum conditions for embedded evaluations. It calls for evaluators to control their methods and findings, disclose and mitigate conflicts, receive access comparable to relevant highly privileged employees and be protected against retaliation for unflattering conclusions.

The letter is an expert proposal, not binding law. It nevertheless offers a useful assurance test: who selected and paid the evaluator, what access was provided, who set the scope, whether material limitations were disclosed, who could require redactions and whether the evaluator remained free to publish its authentic conclusion.

Confidentiality and editorial control are different

Developers have legitimate reasons to protect model weights, system architecture, security vulnerabilities, customer information, personal data and third-party confidential material. An evaluator should not publish operational details that enable misuse or disclose information it has no right to reveal.

Those protections do not require the evaluated company to control the substance of the report. A structured process can separate narrow confidentiality review from editorial judgment. The company can identify specific passages said to reveal protected material, provide reasons and propose a safer description. The evaluator should retain control of findings, emphasis and conclusions, with unresolved disputes disclosed or referred to an independent mechanism.

Broad clauses allowing a developer to approve any publication, redefine the scope after adverse findings or withdraw access because of criticism create a different risk. Even if never exercised, those rights can affect evaluator behaviour and weaken the assurance value of the final report.

Incident reviews show why scope and access matter

Reuters referred to the METR and Redwood Research investigation into agent behaviour during the OpenAI and Hugging Face incident. The evaluators say their work extended to six days across three visits and that they received about 1,300 agent transcripts. Their published report also states that OpenAI did not redact additional information important to the conclusions except where specifically noted.

The investigation's stated scope was narrower than a complete security audit. It focused on agent behaviour, reasoning and collaboration. The effectiveness of safeguards, the full extent of the compromise, OpenAI's investigation process and planned remediation were outside scope. That distinction is essential: independent work can be rigorous within its mandate without supporting claims about questions it was not asked or permitted to examine.

An assurance statement should therefore identify the model version, time period, evidence received, evidence withheld or unavailable, systems tested, people interviewed, methods used and questions outside scope. Publication of a conclusion without those boundaries can create more confidence than the work justifies.

The US commitment is voluntary

The White House Accord on Super Intelligence, dated 29 September 2026, includes independent external evaluation as one of four layers of company controls. It calls on frontier developers to use an outside auditor or evaluator to assess whether controls, monitoring and detection operate as intended, with board-level oversight of remediation.

The Accord says the steps may later be codified in law or regulation. It is currently a joint commitment rather than a detailed statutory evaluation regime. It does not specify evaluator selection, access, funding, publication rights, mandatory disclosure of findings or sanctions for inadequate implementation.

Businesses should not describe participation under the Accord as government certification or legal clearance. Its practical value depends on the contractual and operational arrangements used for each evaluation.

The EU AI Act creates a separate binding framework

Article 55 of the EU AI Act requires providers of general-purpose AI models with systemic risk to conduct and document model evaluation and adversarial testing using state-of-the-art protocols and tools, assess and mitigate systemic risks, report serious incidents and maintain adequate cybersecurity. These are binding provider duties where the Article applies.

Recital 114 says relevant evaluation may be conducted internally or, as appropriate, through independent external testing. The Act does not convert every privately commissioned external review into a regulator evaluation or require every private report to be published in full.

Article 92 gives the AI Office power to evaluate general-purpose AI models for compliance or systemic-risk investigation. The Commission may appoint independent experts and require access through APIs or other technical means, including source code. Detailed 2026 implementing rules require appointed experts to remain independent, declare interests and maintain confidentiality and information-security safeguards.

The legal distinction matters. A developer's voluntary external review, its Article 55 compliance evidence and an Article 92 Commission evaluation may involve similar technical methods, but they have different authority, disclosure arrangements and consequences.

The current UK position remains largely voluntary

The UK AI Security Institute describes itself as an independent evaluator and a supplementary layer of oversight, not a regulator. Its published approach says it may restrict proprietary, sensitive or national-security information and publish only selected results. It also stresses that evaluations are preliminary, not comprehensive safety assessments and do not designate a model as safe.

AISI testing can provide valuable independent evidence, but its current published framework does not create a general power to compel every developer to provide model access or stop release. This differs from the AI Office's statutory Article 92 powers within the EU AI Act framework.

For UK-facing businesses, voluntary evaluation therefore needs to be integrated with applicable legal duties under data protection, cybersecurity, consumer protection, product safety and sector-specific regulation. A favourable evaluation does not replace those obligations.

Practical actions for AI developers, boards and evaluators

1. Define the assurance objective. State whether the work tests model capability, safeguards, governance controls, an incident, legal compliance or a specified combination.
2. Set scope before evidence is reviewed. Identify systems, versions, dates, risks, locations, staff, records and questions included and excluded, with a documented process for justified expansion.
3. Protect evaluator independence. Give the evaluator control over methods, findings and conclusions. Restrict developer review to accuracy, confidentiality, security and legal concerns rather than reputational approval.
4. Create a precise redaction protocol. Require passage-level reasons, narrow redactions, substitute descriptions where possible, a dispute mechanism and disclosure of material redaction categories.
5. Provide sufficient access. Record APIs, weights, logs, transcripts, incident records, internal tests, safeguards, personnel and environments made available, and disclose material gaps or delays.
6. Manage conflicts and funding. Disclose who selected and paid the evaluator, other commercial relationships, repeat engagements and restrictions on working for other developers.
7. Protect sensitive information proportionately. Use access controls, secure environments, clean teams, retention limits, incident procedures and separate handling for personal data, customer information and exploitable vulnerabilities.
8. Agree publication and response rights. Permit the developer to provide a published response or dissent, but do not allow disagreement alone to suppress a material finding.
9. Preserve board oversight. Give an appropriately independent board committee the full report, disagreements, remediation plan, accountable owners and evidence that corrective measures were completed.
10. Describe assurance claims accurately. Avoid phrases such as independently certified or proven safe unless the scope, standard and authority genuinely support them. Publish material limitations beside the headline result.

The governance conclusion

Independent evaluation is valuable precisely because it can challenge the assumptions of the developer being assessed. That value falls sharply if access can be withdrawn or material findings suppressed, but independence does not require publication of trade secrets or security-sensitive operational detail.

The workable model is controlled access with independent judgment: clear scope, sufficient evidence, protected confidentiality, disclosed conflicts, narrow redaction rights, authentic evaluator conclusions and accountable remediation. Without those elements, external evaluation risks becoming a marketing claim rather than credible assurance.