UK AI Security Institute sets out eight priorities it calls most urgent for frontier AI best practice

The UK's AI Security Institute (AISI) published a blog post on 12 October 2026 setting out what it calls "the most urgent priorities for new technical best practice" in frontier AI development. It says the work draws on "three years of experience testing, evaluating and researching frontier AI models".

AISI is a research organisation within the Department for Science, Innovation and Technology. The post links the work to steps the Prime Minister set out on 22 September, which AISI says include "a commitment to work towards principles and standards that ensure the most capable AI systems are developed securely and with appropriate transparency".

What AISI says it has learned

AISI says much of how frontier developers manage risk today is voluntary: they publish safety frameworks, share models with outside testers before release and, "most recently, have begun embedding third-party evaluators".

It says that, working with industry, it has "independently evaluated more than 55 models before release". It also points to its open-source testing tool Inspect, which it describes as "now the standard framework for leading third-party evaluators".

The two problems it names

AISI says its technical work has turned up "two new challenges facing frontier AI organisations today".

• Risks are arising earlier. Testing has mostly been about making models safe for public release. AISI says today's systems are "autonomous and capable enough, particularly in cyber, to pose risk even while unreleased: during training, internal deployment, and evaluation itself". Internal deployment means a company using its own model internally rather than releasing it publicly.
• Evaluations are struggling to keep pace. AISI says "Capability benchmarks are often saturated soon after they're created" and that building credible new tests takes time. (Saturated means the best models score near the top, so the test stops telling them apart.) It says methods for testing alignment and control "are still nascent".

It adds several trends that make this harder. It says "Models' growing awareness of when they're being tested may allow them to mask how they would behave when deployed", and that "as AI contributes more to its own development, progress could accelerate". (For background on that second idea, see our 23 August explainer on recursive self-improvement, which describes a fully self-building AI as still speculative.)

The eight priorities, in AISI's order

AISI says "The list is not exhaustive", and that it is not suggesting it should address every item itself. Each priority is framed as a set of open questions.

1. Assessing and documenting risk. How companies should assess and report risk "throughout development", what assessments should cover, and what standard of evidence they should meet. In plain terms: written risk checks at every stage, not only at launch.
2. Overseeing AI systems throughout their lifecycle. What "controls, monitoring, detection, and other mechanisms" should keep systems working as intended during training, testing and internal and external use, and how firms should share what works.
3. Preserving and evaluating oversight mechanisms. Which technical choices "will preserve developers' ability to oversee AI systems as they become more capable", and how those oversight tools should themselves be tested.
4. Detecting, responding to, and reporting agentic AI incidents. How to define unsafe behaviour by AI agents (systems that take actions, not only answer questions), how to judge its severity, how to spot it quickly, and how incidents should be reported "to affected parties, governments, and the public".
5. Sharing information on the speed of AI development. Which measures best track progress, "including AI's use in its own development as an indicator of recursive self-improvement", and when to share them "so that rapid progress (or stagnation) does not come as a surprise".
6. Enabling independent auditors and evaluators. What expertise outside auditors need, what scope and access "embedded auditors and other independent third parties" should get, and what they should report.
7. Measuring capabilities in security-relevant domains. How testers can "measure the full extent of system capabilities", including through elicitation (drawing out the most a model can do), realistic test settings and test design.
8. Measuring AI alignment. Which techniques reliably test how a model behaves "in various high-stakes situations", and "what are the limits of what these evaluations show".

Voluntary, not mandatory

AISI states: "AISI is not seeking to mandate requirements for frontier developers, but to contribute our expertise to an industry-wide effort to advance technical standards and best practice."

Its proposed route is for industry and others first to develop and share practices, which "could be formalised via international standards development organisations" as they mature. It says it will "work with frontier developers and others to develop voluntary practices", and invites collaborators to get in touch. The post does not name any AI company.

Why it matters

On our reading, the significance is less in any single item than in where AISI now draws the line: it says risk no longer starts at public release, and that the tests used to check models are themselves falling behind. Because AISI frames this as voluntary best practice that "could later inform formal technical standards", how much changes will depend on what developers choose to adopt.