AI audit records that can be checked, not just trusted.

Companies now let AI systems decide and act. The rules that follow ask for a record of what those systems did. Sigilbase keeps that record in a tamper-evident ledger held by neither the company nor anyone it answers to, and anyone can verify it offline.

Start free The pages in this section

The problem with an AI decision log

When a model declines a loan, screens a candidate or an agent acts on someone's behalf, the record of what it did lives in the deployer's own database, writable by the people under scrutiny. An edit leaves no trace. A corrected entry and a rewritten one look identical, and nobody can tell which they are looking at.

Three moments make this expensive:

After a complaint. A customer contests an automated decision. The inputs, model version and output the company produces are the company's version of events.
Before a regulator. The logs the rules require are sampled months later. A backfilled record looks identical to a real one.
After an agent acts. The agent used a person's credentials. Its log is the only account of what it did, and the company holds it.

Who holds the pen?

Where a record lives decides what it proves. The same audit trail means three different things depending on who holds it. Only one custody arrangement takes the pen out of the hands of the party being audited.

In the model vendor's logs

Useful to you. Held in the vendor's account, under the vendor's retention, invisible to a regulator or a customer.

The vendor's pen.
In your database

Observability tools show you everything. They cannot show anyone else that you did not change it afterwards.

Your pen.
In Sigilbase

Held by a third party, anchored beyond everyone, verifiable offline by the person who contests the decision.

Nobody's pen.

What Sigilbase does

Each decision or agent action becomes one event: the model or agent as the actor, what it did as the action, the thing it acted on as the resource, and the inputs as hashes, so the ledger need not hold personal data. Each event is hashed and chained to the one before. Every few minutes the chain is sealed into a Merkle checkpoint and signed. On the Business and Enterprise plans, independent RFC 3161 authorities timestamp the checkpoint roots.

Any range exports as an evidence bundle carrying an open-source verifier. A regulator, auditor or customer runs it offline, with no account and no need to trust us. A changed, deleted or reordered record fails at that exact event.

POST /api/v1/streams/model-decisions/events

{
  "occurred_at":  "2026-10-06T09:14:02.000000Z",
  "actor":        "model:credit-policy-v4",
  "action":       "decision.declined",
  "resource":     "application:9f21c",
  "payload": {
    "inputs_sha256":  "7d3a…e10b",
    "decision":       "declined",
    "reason_codes":   ["DTI_TOO_HIGH", "THIN_FILE"],
    "model_version":  "credit-policy-v4",
    "policy_version": "2026.09"
  }
}

The rules, as they stand

Checked October 2026. This page describes the rules in plain words and is not legal advice. Dates have moved before and may move again.

Record-keeping rules that bear on AI systems, summarised.
EU AI Act	Article 12 requires high-risk systems to record events automatically over their lifetime. Articles 19 and 26 require providers and deployers to keep those logs for at least six months. For stand-alone high-risk systems, including credit scoring and hiring, the obligations apply from 2 December 2027.
UK, from February 2026	The Data (Use and Access) Act 2025 lets firms automate more decisions, with safeguards: the person can be told, make representations, get human review and contest the decision. Contesting a decision needs its record.
ISO/IEC 42001	The certifiable AI management standard. Control A.6.2.8 requires event logging throughout the operation of an AI system, and certifiers sample it.
UK AI assurance	The government's September 2025 roadmap sets out a professionalised third-party AI assurance market. Assurance providers need evidence they can test.

None of these is satisfied by buying Sigilbase. Each is a reason someone has to produce a record that survives examination. The pages below take them one at a time.

In this section

AI decision logging. One event per decision, what to put in it, and what it proves.
Records of what an AI agent did. Agents as actors, tool calls as events, credentials on loan.
EU AI Act record-keeping, plainly. Articles 12, 19 and 26 in plain words, and where Sigilbase fits.
UK automated decisions. The 2025 Act's safeguards, and the record a contested decision needs.
ISO/IEC 42001 event logs. What control A.6.2.8 asks for and what a certifier samples.
For AI assurance providers. The verifier, auditor grants and how to request evidence.

What this proves, and what it does not

Sigilbase proves that a record has not been modified, deleted or reordered since we received it, when we received it, and which identity sent it. Any lawful redaction is declared, never silent.

It does not prove that a model produced the output in the record, or ran at all. It does not prove a decision was accurate, fair or lawful. It does not prove that everything which happened was recorded; coverage is the sender's control. It does not prove the sender's claimed time, only ours. And it says nothing about the period before the sender started.

Sigilbase is the evidence layer. The conclusion belongs to the person examining the evidence.

Start recording provable history

Chained, sealed, independently verifiable audit logs, from the first event. Free while Sigilbase is in beta.

Start free Read the auditor guide

Questions first? Write to hello@sigilbase.io.