Ask a wealth manager whether they have an AI policy and the answer arrives fast. It is a document, it was approved, it is on the intranet.
An AI audit trail is the record of what your AI systems actually did. It is not a policy about AI. It is the evidence that the policy was followed.
Producing that evidence is another matter. Ask the same firm to reconstruct why one specific client received a recommendation on a Wednesday in March:
- Which model produced it?
- What data did it read?
- Whose permissions did it run under?
- Who approved it before it left the building?
These answers take longer. Often they never arrive.
The two often get treated as the same thing. They are not, and neither are explainability and auditability, which is the second confusion sitting underneath the first.
This piece looks at the difference between them, the six core fields behind a defensible audit trail, the four places the trail tends to break, and where the regulators in Switzerland and the UK have already put the standard.
A policy tells a supervisor what you intended. An audit trail tells them what happened.
Is explainability the same as auditability?
No, and the gap between the two is where most AI governance programs are currently sitting. Explainability is a claim about the model: this is how the system reaches its outputs, these are the factors behind this one, here is why the answer is plausible.
Auditability is a claim about your records. On 14 March at 09:42, this version of this model read these documents, produced this output, under these permissions, and this person approved it.
Supervisors care about both, and FINMA’s guidance expects explainability proportionate to the audience. But explainability alone will not let a supervisor reconstruct and evidence a specific decision after the fact. Auditability will, and they can test it in an afternoon, assuming the system was built to answer.
Which is why firms that have invested heavily in explainability can still fall short here. A better account of how a model reasons does not, on its own, prove what happened in one particular case, on one particular date, under one particular set of permissions. That is what a supervisor has to be able to reconstruct.
What does an AI audit trail need to record?
Six core fields. These are not a checklist any regulator has prescribed; they are the fields a firm should be able to evidence for any AI-assisted step, and together they form the core of a defensible audit trail. If your system captures all six, for every step, and can produce them on demand without help from a vendor, you have a trail you can stand behind.
| Field | What it has to record | Why it fails |
|---|---|---|
| Model | Which model, which version, which provider, where it was running | “We use model XYZ” is not a record. Versions change, and the output you are defending came from exactly one of them |
| Output | What the system produced, retained unaltered, plus every subsequent human edit | Firms keep the final version and overwrite the machine’s. The edit history was the oversight evidence |
| Source data | Which documents, records and fields the model was given, and their state at the time | An output is only defensible if you can show what it was reading |
| Timestamp | When the step ran, and when the underlying data was last refreshed | Stale inputs are a common failure and an invisible one |
| Entitlement | Whose permissions the request ran under, and what that permission set was allowed to see | The field most often missing entirely |
| Named owner | A person accountable for that specific step, not a committee and not a function | Ownership gets recorded at the workflow level, where it answers nothing |
Where do AI audit trails break?
In four predictable places. Each one is visible before a supervisor arrives, if anyone looks.
| Where it breaks | What it looks like in the firm | What a supervisor finds |
|---|---|---|
| On the vendor’s infrastructure | The model runs on a supplier’s systems, so logs are generated on their side and retained on their schedule | A record the firm has to request is not a record the firm controls |
| At the entitlement boundary | Permissions are enforced carefully in core systems, then a document set is assembled for the model that ignores them | Once retrieval flattens entitlements, who was allowed to see what becomes unanswerable |
| Where nobody is named | Approval sits with the AI governance committee, or with a function | The question is who. The answer has to be a person with the standing to stop that step |
| At the final step only | The advisor signs the recommendation. Data selection, screening, drafting and framing happened upstream, unrecorded | The signature is real. Everything it rests on is unrecorded, so the approver cannot see what they are approving |
Signing the last step in a chain you cannot reconstruct is not accountability. It is exposure.
Who approves what, and at what threshold?
Human oversight at every step does not mean a human in every step. That is how firms build workflows costing more than the process they replaced.
In practice, firms can operationalize proportionate oversight through thresholds set in advance and recorded when they trigger. This is one workable control model rather than a regulatory template; the aim is to match the level of human involvement to the risk of each step:
- Steps with no regulated outcome, such as retrieval, reconciliation, formatting and monitoring, run automatically and are logged.
- Steps producing a regulated outcome, meaning anything touching suitability, advice, pricing, execution or a written communication reaching a client, should require a named approver before the output leaves the firm.
- Anything that changes a client’s risk classification, or crosses a monetary threshold the firm has set, escalates a level.
The record has to capture what the reviewer did, not only that a review happened. Approvals, edits, overrides, rejections.
A trail containing only approvals is not evidence of oversight. It is evidence of a rubber stamp.
How do wealth firms evidence AI decisions under the UK Consumer Duty?
For UK firms the Consumer Duty makes this concrete, because it already asks for evidence rather than intent. Firms monitor outcomes for retail customers and report to the board annually on whether good outcomes are being delivered.
Apply that to AI-drafted client communications and the consumer understanding outcome does the work. If a model drafted the letter, the firm needs to show what was sent, what review it received and who approved it.
The FCA’s Mills Review, published in July 2026, sharpens this. It confirms the Consumer Duty and the Senior Managers Regime apply as they stand, and sets out a spectrum of AI autonomy running from human as operator through to human as observer. For firms, the practical implication is to understand where each of their AI deployments sits on that spectrum, and to hold the evidence that matches it.
Does the Swiss regulator FINMA allow AI in client advice?
Yes. FINMA has not prohibited AI in client-facing processes, and its published guidance is deliberately technology-neutral. Guidance 08/2024 sets out supervisory expectations rather than a permitted-use list: clearly allocated responsibility, an inventory of AI applications with risk classification, data quality, explainability proportionate to the audience, and independent review. FINMA also observed that institutions were defining AI narrowly and that inventories were frequently incomplete, because use was scattered across the organization.
The supervisory question was never whether you may use AI in advice. It is whether you can show how a particular piece of advice was produced, who was responsible, and what review it received.
Who stays accountable when the model runs somewhere else?
In 2026, the Financial Stability Board’s consultation report on Sound Practices for the Responsible Adoption of AI pointed the same way for financial institutions globally. It stresses that firms keep clear governance and accountability for AI regardless of who supplies the model, and it flags the third-party dependency risk directly, including vendors changing the models behind their tools without adequate notice. The accountability-does-not-transfer principle is not unique to the FSB; it is explicit in the UK’s Senior Managers Regime and in FINMA’s expectation of clearly allocated responsibility.
The real question is therefore not where the model runs but who controls what it does. In practice, a regulated firm should be able to answer five questions wherever the model sits:
- Who controls the environment it runs in
- How much of the stack depends on a third party
- Who can reach the data it reads
- Where that data is stored and under which jurisdiction
- Who remains accountable for the outcome
Private or dedicated hosting can make some of those answers easier, data location and isolation in particular, but on its own it settles neither accountability nor third-party dependency. A firm that hosts privately but still cannot reconstruct what a model did has solved the wrong problem. The test is whether the deployment, wherever it sits, produces evidence the firm controls and can stand behind.
What governance built into the system looks like
The practical test is whether governance exists inside the system, not in a policy sitting alongside it.
That is how WealthAi’s operating system has been designed. Every action creates an audit record, including model calls, while retrieval-based answers retain the sources behind them. That means a firm can reconstruct not just the final output, but what the system did to produce it.
Permissions remain part of that trail. Access is governed through role-based controls and per-tenant isolation, so introducing AI does not mean flattening the permissions already protecting a firm’s data.
Where an action requires human judgement, that control is built into the workflow. Financial and outbound actions require explicit approval before execution. Models sit behind an enterprise routing layer, with no training on client data and no dependence on a single model provider. Client data is held in the UK and EEA, with a Swiss region planned for FINMA-sensitive tenants.
None of that transfers accountability from the firm to the technology provider. Nor should it.
The firm remains responsible for suitability, advice and the outcomes delivered to its clients. The role of the technology is to make the evidence behind those decisions visible, attributable and reconstructable when the firm needs to demonstrate what happened.
That is the difference between putting governance around AI and building governance into the way AI works.