AI Audits Need Independent Testing, Not Company Scripts
AI audits matter only if auditors can choose what to test. See how independent testing, secure hardware and public oversight can make audits credible.
Who Gets to Set the AI Audit? That's the Real Test
A company can invite an outside auditor and still steer the outcome. It can pick the auditor, set the questions, limit what the auditor can access, and control what gets published. The process may look independent, but the real decisions often stay with the company under review.
That distinction matters as governments and AI developers make voluntary commitments about model safety. In September 2026, six major AI companies signed a White House accord promising to work with independent auditors or evaluators. It's a useful starting point. But agreeing to an audit doesn't, by itself, tell us whether the audit tests the risks that actually matter.
The practical question isn't just whether outside testing is possible. New testing methods can let evaluators examine a model without receiving a copy of it or seeing their test questions in advance. The harder issue is governance: who selects the auditor, who chooses the tests, and who makes sure the company addresses what goes wrong.
This article looks at what makes an AI audit credible, why voluntary commitments can fall short, and how secure testing and stronger oversight could close the gap. The goal isn't to make audits perfect. It's to make them harder to stage-manage.
What an AI audit needs to establish
An audit isn't independent just because the auditor works outside the company. Independence is something the whole process creates: who appoints the auditor, what access they get, how the tests are chosen, and what happens after the report lands.
That's easy to miss because people use "audit" to describe different activities. A review might focus on documentation, inspect a model's evaluation results, test a deployed interface, or examine the model directly in a controlled environment. All of those can be useful, but they don't answer the same questions.
For instance, testing a public-facing chatbot can show how it responds to a set of prompts. It may not show how the model behaves under different conditions, what capabilities exist that aren't exposed through the product, or how the company handled known weaknesses before release. If a report doesn't spell out its scope, it can sound more comprehensive than the work actually was.
A useful audit should make four things clear:
- Who selected and paid the auditor? Paying for an audit doesn't automatically destroy independence, but the appointment and compensation structure can create pressure to keep the client satisfied.
- Who selected the tests? If the developer supplies the test set, it may already know what's coming and narrow the evaluation to what it expects.
- What could the auditor access? Limited access can make sense for security or privacy, but the limitation should be stated, along with what it prevents the auditor from concluding.
- What happens when a problem is found? A report is only one step. There has to be a way to assign responsibility, set a remediation timeline, and verify the fix.
The core issue isn't whether a company has an audit document. It's whether the evidence supports the claim being made. Saying "an external evaluator tested the model" isn't complete without the boundaries of that test.
This is why an audit should be treated as a system, not a badge. Scope, independence, evidence, and follow-up are tied together. A weak link in any of them can undermine the result. For a broader look at the policy questions involved, see our guide to AI governance and accountability.
Why company-controlled audits can fail
The incentive problem in financial auditing is familiar: a client pays for an audit, and the auditor is supposed to challenge the client's claims. If management controls the appointment, scope, and access, the auditor can end up avoiding friction - sometimes without anyone having to explicitly ask for a favorable report.
The Enron and Arthur Andersen collapses are a well-known example of what happens when independence breaks down. AI audits aren't identical to accounting audits. They aren't. Financial statements and advanced models involve different kinds of evidence, technical risks, and regulatory settings. The lesson is narrower but still important: expertise doesn't magically erase conflicts of interest.
AI companies have also made voluntary commitments. In 2023, leading firms promised - among other things - that they would let outside experts test systems before release. Researchers at Stanford, Harvard, and Brown later scored 16 companies against those commitments. The reported average was 53%, and eight companies scored zero on a promise related to helping outsiders identify and report problems.
That result doesn't prove every voluntary commitment is meaningless. It does show why a pledge needs a way to check whether it's being followed. Without published scope, clear responsibility, and consequences for non-compliance, the public is stuck relying on the company's own account of whether it did what it promised.
Access is another constraint. When METR, a nonprofit evaluator, tested OpenAI's o3 model before release, it reported that the work took place over three weeks, with limited information about the model and no access to its step-by-step reasoning. Those boundaries don't make the work pointless, but they do limit what conclusions an evaluator can reasonably draw.
That's the distinction organizations should keep intact: an audit can be useful even if it isn't comprehensive. The problem is when a limited evaluation gets presented as broad assurance that a model is safe, reliable, or adequately controlled.
A good report should say what was tested and what wasn't. For example, it should distinguish between:
- tests of a model in a specific interface versus tests of the model itself;
- a defined set of known risks versus exploratory testing for unanticipated behavior;
- a one-time pre-release review versus ongoing evaluation after deployment;
- findings the evaluator verified directly versus claims supplied by the developer.
These distinctions aren't "extra paperwork." They help product teams, regulators, and customers understand what the evidence actually supports. Our related piece on evaluating AI systems in production explains why monitoring model behavior shouldn't stop at a single pre-launch assessment.
How independent testing can protect models and test questions
For years, outside testing came with a trade-off. An evaluator could give the developer test questions, letting the company keep control of the model while risking the test being exposed. Or the developer could provide a copy of the model, which raises security and intellectual-property concerns.
A trained model is valuable technical property. Building an advanced model can cost more than $100 million, and a copy can reveal capabilities or information the developer may not want to distribute. It's reasonable for a company to resist handing out an unrestricted copy. But that concern shouldn't be used to justify audits where the company controls every meaningful input.
Secure testing environments offer a different path. In August 2026, Google DeepMind described a double-blind evaluation carried out with Singapore's AI Safety Institute and other external groups. The test ran on sealed computer hardware. The evaluators didn't see the model, and the developer didn't see the evaluators' questions. DeepMind also said each side could use mathematical checks to confirm that what each party brought stayed private.
The point here is practical, not mystical. A well-designed environment can allow evaluators to run tests against a model without taking possession of the model or exposing the test set. That makes independent evaluation more feasible while reducing exposure of both valuable assets and sensitive testing methods.
It also changes where trust sits. Instead of only trusting the company and the evaluator, participants have to trust the hardware, the software configuration, and the people who control the machines. That's a real trade-off - not a footnote.
Researchers have shown attacks against sealed-hardware setups using less than $1,000 in equipment, though the reported attack required physical access to the server. That doesn't mean secure hardware is useless. It does mean the environment needs an explicit threat model: who can access the machine, how it's configured, what gets logged, and how participants can verify the setup.
A credible design should document:
- The isolation model: what data is protected, from whom, and under which assumptions.
- The evaluator's control: whether outside testers can run their own chosen tests or only a developer-provided suite.
- The execution record: what model version and configuration were tested, and whether results can be checked independently.
- Operational access: who can access the hardware (physically or remotely) and what controls prevent unauthorized changes.
- Known limitations: what the system can't prove, including risks that may sit outside the test environment.
This is similar to other security engineering decisions: reducing one risk doesn't eliminate all risks. The job is to make the remaining assumptions visible and manageable. A secure test setup is useful only if the evaluator has enough room to ask meaningful questions and the evidence can be reviewed afterward.
Conclusion
External AI audits are worth pursuing, but "independent" should describe the process - not just the auditor's job title. If a company picks the auditor, controls the test plan, limits access without explaining the consequences, and keeps the outcome entirely private, outsiders won't know whether the audit tested the system or simply confirmed the company's preferred version of events.
Secure testing methods can reduce the old trade-off between protecting a model and giving evaluators meaningful access. They don't solve governance, incentives, or follow-up on their own. Those require clear rules about who chooses the tests, what gets disclosed, and who checks the auditors.
When you assess an AI assurance claim, start with the scope: who tested what, under which conditions, and what happened to the findings. If those questions don't have clear answers, treat the audit as limited input - not a guarantee. For more on building accountable AI practices, explore our AI governance resources.