← Blog

    Can You Prove What Your AI Did? NexArt Evidence Briefing, November 2026

    Jeremy Bouedo6 min read
    NexArt Evidence Briefing, November 2026: Can you prove what your AI did? Four updates: EN 18286 is in force, insurers may set the bar first, tamper-evident to whom, and the AI Act clock.

    Pick one AI decision your system made last month. Can you show what the model received and returned, which version ran, and who triggered it, and can someone outside your team verify that none of it has changed since? That is the test I would put in front of any team running AI in a regulated workflow this month.

    DigiCert's October briefing framed trust as what your team can prove after deployment. For AI decisions, the bar is one step higher: what you can prove to someone who does not trust you. A customer disputing a decision, an auditor, a regulator, an insurer. It is a standard we hold ourselves to: NexArt records carry a DigiCert RFC 3161 timestamp, so even the time a record was sealed can be checked without trusting us.

    Four developments this autumn all ask that question. Here is what each one asks for, where execution evidence helps, where it does not, and one concrete action for November.

    EN 18286 is in force. Your QMS now needs evidence, not just records.

    On 14 October 2026, Commission Implementing Decision (EU) 2026/2274 cited EN 18286 in the Official Journal. It is the first harmonised standard under the EU AI Act. Providers of high-risk AI systems that apply it get a presumption of conformity for the quality management system required by Article 17.

    Most of EN 18286 is organisational: leadership, planning, competence, management review. But several clauses depend on operational evidence of what the system actually did in production: documented information (4.5), identification of the AI system (8.7), post-market monitoring (9.5) and serious-incident reporting (9.6). Today that evidence usually comes from logs the operator controls and can change.

    Boundary: execution evidence supports those clauses. It does not design your risk management system, write your technical documentation, or make you conform to EN 18286. Conformity is the provider's job.

    November action: for one high-risk workflow, list the four clauses above and, for each, write down where the evidence comes from today and who could alter it. If the answer is "our database, and the engineering team", you have found your gap.

    Insurers, not regulators, may set the bar first

    Gartner's press release "Gartner Unveils Top Strategic Predictions for 2027 and Beyond" (15 September 2026) includes two predictions that land directly on AI evidence: "By 2030, insurers – not regulators – will drive AI governance," and "By 2030, 80% of Global 500 companies will contractually make their CIO (or CAIO) the "Evidence Custodian"" for AI accountability. Its recommendation is that organisations "assess their digital evidence management capabilities and establish clear accountability for AI actions."

    An underwriter pricing AI liability will ask the same question as a regulator, with money attached: when something goes wrong, can you show what the system did, and whose decision it was?

    Boundary: a verifiable record shows what was executed and that it has not changed. It does not show the decision was correct, fair or lawful, and it does not replace the accountability framework itself.

    November action: name the person who would be your Evidence Custodian for one AI system. Ask them what they would hand an insurer after a disputed decision, and how the insurer would check it.

    Agent security is maturing. Tamper-evident to whom?

    Replit's Agent Habitat paper, published on 28 October, is one of the most testable agent-security frameworks so far: sandbox isolation, brokered credentials, default-deny policy, per-action approval, containment. Its observation track sets a clear Level 3: logs written off-host, tamper-evident, tied to identity and trigger, out of the agent's reach. Its core assumption is the right one: no control may depend on the agent's own account of what it did.

    That protects the operator from the agent. It does not answer a different question. Six months later, a customer disputes what an agent did to their account. The logs are tamper-evident to the operator. The customer, their lawyer, an auditor or a regulator still cannot check them without trusting the operator, which is exactly what is in dispute.

    Tamper-evident and independently verifiable are different properties. The first is a security control. The second is evidence.

    Boundary: execution evidence does not sandbox, gate or contain an agent. It sits after those controls and makes what happened checkable by an outsider.

    November action: take one agent action from last week. Hand its record to someone with no access to your systems and ask them to confirm it has not been altered. If they cannot, you have logs, not evidence.

    The AI Act clock is shorter than it looks

    Under the timetable amended by the Digital Omnibus, Regulation (EU) 2026/1744, high-risk obligations apply from 2 December 2027 for Annex III systems (credit scoring, life and health insurance pricing, employment, essential services) and from 2 August 2028 for AI in Annex I products. Article 12 requires high-risk systems to allow automatic recording of events over their lifetime, and Articles 19 and 26(6) require logs to be kept for at least six months.

    Thirteen months sounds comfortable. It is not, because evidence only covers what happened after you started keeping it. A record created in late 2027 says nothing about a decision made in early 2027.

    Boundary: one verifiable record does not show that every relevant event was captured. Completeness depends on instrumenting the right execution boundary, and that remains a design decision.

    November action: for one high-risk workflow, check three things: how long execution records are kept, whether they can be exported in a form that verifies outside your systems, and whether that still works if a supplier disappears.

    Where NexArt fits, and where it stops

    NexArt produces Certified Execution Records: the input, parameters, output, model and context of an AI execution, sealed at the moment it runs. An independent node signs each record, and the record carries an RFC 3161 timestamp from DigiCert's public timestamping authority, so the time of sealing can be checked offline against DigiCert's public root, with no reliance on NexArt. Anyone can verify a record with standard cryptography, using only the record and the published keys, with no account and no access to the operator's systems.

    • Confidential mode replaces sensitive fields with commitments, so personal or privileged data stays inside the organisation while the record still verifies. A disclosed value can later be checked against its commitment.
    • Identity binding seals the identity your application authenticated into the record, so the record shows which user or system triggered the execution, and that this cannot be quietly changed. The identity is asserted by your application; NexArt does not authenticate the person.
    • Evidence Bridge turns JSON your systems already produce into records through a reviewed, versioned mapping, without changing your event schema. Sealing at the execution boundary with the SDK remains the strongest option.

    Those are building blocks for evidence. They do not make a decision correct, fair or lawful, they do not gate or contain an AI system, and they do not establish EU AI Act or EN 18286 conformity. The organisation still decides which executions to capture, how long to keep them, and who answers for them.

    The one question

    Standards, insurers, agent architectures and regulators are converging on the same test. Not "do you have a policy", but "show me what happened, in a form I can check without trusting you."

    If one of your AI decisions were challenged tomorrow, what would you hand over, and could the other side verify it?

    NexArt makes AI execution records that an outsider can verify. You can check one yourself at verify.nexart.io.

    Sources

    Share this article