Anyone deploying an AI system for sensitive decisions wants to be able to show how the model reached an outcome. The most obvious way to do that is the reasoning narrative that large language models produce themselves: the so-called chain-of-thought (CoT). New research summarised at the end of July 2026 in an analysis on AI Governance draws a line through that idea. According to a synthesis of work from, among others, Apple, the Santa Fe Institute and Google DeepMind, such a reasoning text does not necessarily reflect the model's actual internal decision-making process.
A model can reach a correct answer through pattern recognition or shortcuts, and then generate a plausible-sounding explanation alongside it that does not causally describe the process. For anyone who uses that explanation as evidence, this is a problem: a seemingly clear narrative is not yet a reconstruction of what really happened.
Explainability and auditability are not the same thing
The heart of the insight is that explainability and auditability are drifting apart. Explainability concerns the question of whether an outcome is understandable: which features and scores played a role, and does the explanation sound logical. Auditability concerns something else: can you, after the fact, independently and demonstrably reconstruct what happened in a specific decision?
An academic study on audit-ready explainable AI for fraud detection makes that distinction sharp. The authors define audit readiness as the measurable capacity to reproduce, justify, challenge and manage alerts over time using stored artefacts: the data used, the model versions and the decision logs. Understandable behaviour of a model is therefore something other than the ability to fully reconstruct and account for a warning.
That distinction plays out not only in theory. The Enterprise Guide to AI Governance from the IBM Institute for Business Value describes a concrete accountability and auditability gap: many organisations do have high-level AI ethics principles and explainability goals, but lack the structured responsibilities, traceable decision logs and verifiable documentation to genuinely audit AI outcomes. Outcomes sound explainable, but cannot be demonstrably traced.
What a defensible audit trail requires according to regulators
What auditability concretely demands becomes clear from two practical guides. The guide AI Audit Trail Requirements by Regulation from DeepInspect defines an AI audit trail as a per-decision record that captures:
- who or which agent initiated the request;
- which data with which classification were used;
- which policy version and control state applied;
- which result was generated, and when;
- an integrity mechanism against later modification.
The guide emphasises that such an audit trail must be written independently of the application, must be tamper-evident and externally verifiable, and that ordinary application logs are not sufficient for this.
The analysis by ProvenRail on EU AI Act Article 12 compares several regimes — the EU AI Act (articles 12, 19 and 26), ISO/IEC 42001 and the NIST AI RMF with IR 8596 — and distils from them three hard requirements for AI logs: tamper-evident storage, independent verifiability (auditors can check the integrity without having to trust the operator) and reliable timestamps linked to an external time source. A simple database log without integrity control does not, by that measure, count as a defensible audit trail.
The common thread is clear: auditability sets a stricter technical and legal bar than common explainable-AI practice. The reasoning text of a model, however clear, does not meet it.
Redesigning explainability as a testable transparency layer
For professionals working with sensitive or high-trust information, this means that explainability must be rethought: not as a standalone chain-of-thought, but as part of an audit architecture. Every AI decision should then record which person or agent initiated something, which data scope and policy version applied, which model configuration was running and how human review intervened — stored in a way that is externally testable.
In that context, IamVera.ai is not a model that produces new explanations, but a verification layer. Vera can route a task through selected, independent AI models and make the verification steps, corrections, disagreements and sources visible for inspection. This supports review and control, but it is not a guarantee of correctness; it makes control possible by making the process visible.
In the area of sensitive data, Vera works with a Semantic Privacy Shield: sensitive document values can be replaced on EU infrastructure with synthetic, session-only equivalents before the AI chain gets to work. The architecture is designed to send onward only anonymised content, and the workflow is fail-closed: if the privacy check fails, the document is not sent onward. For working with documents within that protected workflow, Vera Office offers viewing and editing functionality based on Collabora Online, with the final judgement remaining with the user.
The lesson from the research and guides of mid-2026 is sober. An AI system that sounds understandable is not automatically testable. Anyone deploying AI in regulated or trust-sensitive contexts would be wise to treat explainability and auditability as two separate requirements — and to link the visible explanation to hard, verifiable decision and context artefacts. The professional final judgement about what the outcome is worth remains, in any case, with the human.