On 29 October 2026 The Pensions Regulator, which regulates workplace pension schemes in the UK, published detailed guidance titled “Use of artificial intelligence (AI) in pension schemes”. It is addressed to trustees and scheme managers, and the regulator adds that it “may also help pension service providers understand and prepare for the questions trustees are likely to ask.” The guidance is not intended to set new requirements: it explains how duties trustees already have apply once AI enters the process, whether the scheme uses it directly or a provider does.
At its centre is a list of ten questions that every trustee or scheme manager “should be able to answer” for each significant use of AI. Among them: what data it uses and how that data is handled, how it is tested, how a decision can be challenged, how humans can override it, and what happens to the process if the AI fails or becomes unavailable.
The same question may not get the same answer twice
Where AI has significant influence on a decision, the guidance asks for more. Trustees should be able to explain five things about that decision:
what AI tool or system was used and for what purpose
what information and assumptions the output was based on
what human checks or reviews were made against the AI output
the reasons for accepting, rejecting, or departing from the AI-informed output
who was responsible for making the decision
The five points, in the regulator's wording. Source: The Pensions Regulator, “Use of artificial intelligence (AI) in pension schemes”, 29 October 2026. © Vardix Group
In the same section the regulator warns that AI outputs “may appear authoritative even when they are incomplete or inaccurate” and “may also change between generations, or when prompts and context change.” Read those two passages together and the practical consequence follows, in our view: if asking the same question again can produce a different answer, asking it again a week later cannot show what the original answer was based on. Only a record made at the moment of the answer can.
Embedded AI can arrive with a software update
For AI that a provider runs, the guidance lists areas trustees may ask about. They include “what records, audit logs and documentation are kept”, “where the AI systems are operated from”, and how data protection, data handling and access controls apply. The regulator also notes that AI “may be embedded within existing software or introduced through system updates”, and that governance should include a way to identify “significant changes to the model, data, function, access, or scale of use.”
The regulator is explicit that this “is not a checklist”, and that obtaining the information does not, by itself, show that anyone has met their obligations. Where trustees cannot get sufficient assurance, the guidance says they “should record their assessment and any limitations on the action they are able to take.” It also asks them to consider exit provisions before signing, including how scheme and member data would be transferred or returned; we looked at that side of the problem in our piece on Singapore's AI rules for financial institutions.
What an integration has to write down when it answers
This record is the part of a language-model project that our AI / LLM Integration practice treats as the work itself rather than an extra. In the systems we build, the facts a model may rely on are stored and versioned in the client's own data instead of being left to the model; in operation we log what was asked and what was answered; and the model provider is a configuration setting, so changing it does not mean rewriting the system. Hosting is chosen per project against where the data is allowed to live, self-hosted open models included.
Set against the regulator's wording, the record has to hold roughly this:
| Named in the guidance | What the system has to have kept |
|---|---|
| What information and assumptions the output was based on | The client's records the model read, at the version in force when it answered |
| What human checks or reviews were made against the AI output | Who reviewed the answer, and whether they accepted, changed or rejected it |
| A way to identify significant changes to the model | The provider, model and configuration behind each answer, so a change appears as a dated event |
| Where the AI systems are operated from | The hosting decision taken for the project and written down, not inherited from a vendor default |
| What records, audit logs and documentation are kept | The answer exactly as it was shown, stored next to everything above |
One answer, one record. An illustrative diagram, not a format any regulator prescribes. © Vardix Group
Our experience is that adding such a record after launch is the expensive way round: the answers already given were never written down, and those are the ones a trustee, an auditor or a member is most likely to ask about first.
A record shows the review; it does not replace it
The guidance is written for UK pension schemes and their providers, and it applies existing duties rather than creating new ones. A record does not make an answer right, either. The regulator's position is that AI “should support, rather than replace, trustee judgement, professional advice and meaningful challenge”, and it suggests trustees could consider safeguards such as checking important outputs against trusted sources and keeping suitable human review.
For partners whose customers answer to a regulator, these questions make a better opening than a demo. A buyer who has read the guidance may well bring them to the first meeting, and a system designed to answer them is an easier sale than one that has to be retrofitted.