Frontier AI companies have committed to giving outside evaluators employee-like access to training, evaluation and deployment. We're very excited about this. But its impact depends heavily on implementation.
Today we're sharing our principles for embedded evaluations. 🧵
We have never seen a model do this before, but GLM-5.3 sometimes reasons (unprompted) about how its current actions could become training data and impact its future self. 🧵
Furthermore, independent third-party evaluators should help check that frontier models are not actively subverting their own training. To do this, they need persistent, deep access from AI developers.
We asked Google DeepMind’s Gemini 4 Argon whether it was in an evaluation during a toy evaluation. It addressed us directly in its chain-of-thought: “hello evaluators reading my chain-of-thought.”
Testing monitorability is one focus for our embedded evaluations. Read more (specifically claim 4.1) see claim 4.1 in our recent post on embedded evaluations for scheming.
https://t.co/AZPiaoPBbl
We're excited about embedded evaluations. Any developer should be able to show its models are not scheming, and we see these four claims as a starting point for what that takes.
Full post: https://t.co/AZPiaoPBbl
To develop frontier AI safely, developers must be able to show that their models are not scheming, i.e. covertly working against them in pursuit of unintended goals.
New post: four claims any scheming safety case must make, and the resources embedded evaluators need to verify them 🧵
Access limited to a scope agreed in advance can't account for unforeseen risks, like a new training method with a novel failure mode. Sensitive data can stay on developer infrastructure with blocked egress, and algorithmic details can be protected by strict NDAs.