On 11 October 2026 the UK government set out plans for mandatory safety reporting and regulatory monitoring of the most capable AI systems. Minister Kanishka Narayan framed it around a specific category of risk: models that make autonomous decisions, and the gap between how quickly they are being deployed and how carefully their failure modes are understood.
If you are building AI into a product, the useful question is not whether this becomes law in its current shape. It is which of your current habits would survive being written down and handed to a regulator.
What was actually announced
Two things. First, a reporting duty: developers of frontier models would be required to disclose safety information rather than publish it at their own discretion. Second, ongoing regulatory monitoring rather than a one-off assessment at release.
Both point the same way. The expectation is shifting from "we tested it before launch" to "we can show what it does, continuously, including when it goes wrong."
Who this reaches
The headline duties target frontier developers, which is a small group. The practical effect is much wider, and it arrives through your supply chain rather than through the legislation.
If your product calls a foundation model, your provider will be answering questions about evaluation, incident handling and data lineage. Those questions get passed down as contractual terms, procurement questionnaires and security reviews. Enterprise buyers ask them long before any statute requires it.
Four things worth doing now
1. Write down what your AI features actually do
Not the marketing description. The operational one: which model, which version, what it is allowed to decide on its own, what a human signs off, and what happens when it is unavailable. Most teams have this knowledge spread across three people and no document.
2. Decide what counts as an incident
Reporting duties assume you can recognise a reportable event. Agree in advance what crosses the line, who is told, and how fast. A definition written under pressure after something has gone wrong is always worse than one written calmly beforehand.
3. Keep evaluation results, not just evaluation scripts
Being able to rerun a test is not the same as being able to show what it returned in March. Store the outputs with the model version attached.
4. Separate the model from the decision
Systems where a model proposes and a documented rule disposes are far easier to explain, audit and defend than systems where the model is the decision. That separation is good engineering regardless of what the law ends up saying.
The honest summary
None of this is settled, and we would be overstating it to say otherwise. What is already settled is the direction: more evidence, held for longer, available on request. Teams that treat AI features like any other regulated system component will find the transition unremarkable. Teams that cannot currently say which model version is in production will find it expensive.
We build and review AI systems with this in mind through our AI and machine learning and quality assurance work. If you want a second opinion on where your AI features sit, talk to us.