AI systems are becoming more capable faster than the tools used to understand them. That gap is the strongest argument for independent testing: developers should not be the only organizations deciding whether their own models are ready for deployment.

Independent evaluation could make AI development more accountable without requiring everyone to agree on the most dramatic predictions about its future. But hiring an outside tester is not enough. The value of an evaluation depends on what the tester can inspect, how it measures risk and whether its findings can change a release decision.

The problem is an evaluation gap

In the interview, independent AI evaluator Rayan Krishnan argues that investment in model capabilities has outpaced investment in testing. His concern is not simply that models are improving quickly. It is that our ability to build them is running ahead of our ability to explain their strengths, limitations and potential failures.

That distinction matters. A model can perform impressively on a benchmark while remaining unreliable in a particular workflow. And a test designed for a standalone chatbot may reveal little about a system connected to tools, software repositories or other AI agents.

Independent evaluators can provide a second line of scrutiny. They can challenge developers’ assumptions, compare systems using consistent methods and identify gaps that internal teams may overlook. Their findings are evidence, however—not a blanket guarantee of safety.

AI research automation is an important test case

One area discussed in the interview is recursive self-improvement: the prospect of an AI system autonomously developing a more capable successor. That is a substantially higher bar than helping a human researcher write code or run an experiment.

Krishnan describes an index that uses proxy tasks to track progress toward that capability. In the results he discusses, models show strength in executing experiments and handling engineering work, but remain weaker at proposing novel experiments and producing fundamental breakthroughs.

These are different abilities. A capable research assistant does not automatically amount to an autonomous research organization.

Krishnan also offers an extrapolation suggesting that models could surpass human researchers around August 2027. That date should be understood as a forecast based on benchmark trends, not a demonstrated capability or a reliable deadline. Performance on proxy tasks does not establish that a system can independently complete the full cycle of developing its successor.

What evaluators cannot see matters

A crucial qualification in the interview is that the research-automation index covers publicly available models—not unreleased internal systems, specialized agents or multi-agent arrangements. That limitation applies to the index, rather than necessarily to all of the evaluator’s work.

The distinction illustrates a wider challenge. Testing a public model may not capture what a developer can achieve with additional tools, scaffolding and internal infrastructure. Equally, a strong result in a carefully configured experiment may not translate into reliable real-world performance.

Embedding external evaluators within AI companies could help close this visibility gap. Earlier access could allow testing before release and provide a clearer view of how a complete system operates. Yet closer access creates its own question: can an evaluator work inside a company without becoming dependent on it?

Who pays—and who controls the findings?

Developer-funded evaluation has an obvious tension: the organization being assessed may also be the customer. Financial auditing and credit ratings offer precedents for this arrangement, but they also show why commercial relationships need safeguards.

Krishnan highlights a boundary between evaluating a system and selling the means to improve its test performance. He says his organization publishes methodologies while keeping test sets private, and does not sell training data or solutions to the labs it tests.

Those measures address important risks. Private test items can make it harder to optimize directly for the exam, while separating assessment from remediation reduces the incentive to identify problems that generate follow-on sales. Neither measure, by itself, resolves every conflict.

A credible oversight framework should also answer:

• Scope: Can evaluators inspect the relevant system, or only a version selected by the developer?
• Disclosure: Can significant findings reach an appropriate oversight body even when they are commercially inconvenient?
• Consistency: Are comparable systems assessed under comparable conditions?
• Follow-through: Do serious failures trigger mitigation, retesting or a delayed release?
• Accountability: Are the evaluator’s methods, limitations and financial relationships open to scrutiny?

Testing needs consequences to improve safety

Krishnan expresses optimism that labs, governments and enterprise customers can cooperate, with market-based evaluation playing a role alongside other approaches. Shared standards could make results easier to compare and reduce the advantage of choosing a more permissive assessor.

But agreement to test is only the beginning. Buyers need evidence relevant to their intended uses. Developers need procedures for responding to failures. Oversight bodies need clarity about what an assessment does—and does not—establish.

Independent testing can make AI safer when it connects better evidence to better decisions. Without that connection, it risks becoming a badge of reassurance. With meaningful access, protected independence and clear responses to concerning results, it can become a practical check on a technology advancing faster than our understanding of it.

This article was inspired by Can Independent Testing Make AI Safer? from Bloomberg Tech. Please visit the original video for the creator’s full presentation and context.