What is AI decision logging?

AI decision logging is the practice of recording what an automated system saw and decided as durable, reviewable events. Sigilbase makes each of those events tamper-evident by hashing, chaining and signing it. The result is a record you can prove was not altered after the decision was made.

Does this satisfy EU AI Act logging requirements?

Sigilbase provides the tamper-evident record-keeping layer that logging obligations assume; whether a given deployment satisfies the EU AI Act depends on what you choose to log, which remains the deployer's responsibility. We give you an append-only, verifiable record and a standalone verifier. We are not your compliance advisor, and we make no dated claim that using Sigilbase alone makes a system compliant.

What should an AI decision event contain?

An AI decision event should contain enough to reconstruct the decision: the model or actor identifier, the action taken, a hash of the inputs, the decision itself, and the reason codes. Sigilbase seals whatever fields you send in the event payload. Hashing the inputs lets you prove what the model saw without storing the underlying data in the log.

Can I prove a model decision was not changed later?

Yes. Each decision event is chained to the one before it and sealed into a signed checkpoint, so any later edit, deletion or reordering breaks verification. The standalone verifier names the sequence number that failed, so you can see exactly which record was touched.

Do I need to send Sigilbase my model inputs?

No, you do not have to send raw inputs. You can log a SHA-256 hash of the inputs instead, which proves what the model saw without placing the underlying data in the record. What each event contains is entirely under your control.

Does Sigilbase prove the model actually produced this output?

No. Sigilbase proves what you recorded and when, and that it has not changed since. It holds the record, not the computation. If you need proof that a given model ran on given inputs, that is a different problem, and we say so rather than blur it.

AI decision logging that proves what your model decided.

Sigilbase is an AI decision log that records what an automated system saw and decided, then makes that record tamper-evident.

Each decision event is hashed, chained to the one before it, and sealed into a signed checkpoint. Anyone can verify the record offline with a standalone verifier, without a Sigilbase account.

Start free See the event model

One event per decision. What the model saw, by hash, and what it decided.
Sealed within minutes. Chained and signed, so nothing is rewritten after the fact.
Checkable by anyone. A regulator or a customer, offline, without an account.

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.

The Sigilbase event model, applied to an AI decision

Sigilbase records each automated decision as one event: an actor, an action, a resource and a payload. Here a credit policy model declines an application, logging a hash of its inputs rather than the raw data.

Chain

Sigilbase hashes each decision event with SHA-256 and chains it to the previous one, so altering an earlier decision breaks every hash after it.

Seal and verify

Sigilbase seals recent events into a signed checkpoint every few minutes, and the standalone verifier recomputes the chain and signatures offline to confirm nothing was touched.

Hash the inputs, not the person

The event carries inputs_sha256, so a regulator can confirm a stored input file matches what the model saw without the ledger holding the data. Operators at Sigilbase do not see payloads in any case.

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"
  }
}

A log records events. Sigilbase makes them provable.

How a standard application log compares with a Sigilbase decision record.
Question	A standard log	Sigilbase
Can the operator rewrite history unnoticed?	Yes, with database access	No, it breaks the hash chain
Can a third party verify it independently?	No, they must trust your export	Yes, offline with the standalone verifier
Does the evidence survive the vendor disappearing?	No, it depends on the vendor's system	Yes, the evidence bundle verifies on its own
Is each record cryptographically sealed?	No	Yes, in a signed checkpoint

Wiring decisions into the API reliably. What a tamper-evident audit log is and what it proves.

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 other pages in this section take them one at a time.

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.

Questions about AI decision logging

What is AI decision logging?

AI decision logging is the practice of recording what an automated system saw and decided as durable, reviewable events. Sigilbase makes each of those events tamper-evident by hashing, chaining and signing it. The result is a record you can prove was not altered after the decision was made.
Does this satisfy EU AI Act logging requirements?

Sigilbase provides the tamper-evident record-keeping layer that logging obligations assume; whether a given deployment satisfies the EU AI Act depends on what you choose to log, which remains the deployer's responsibility. We give you an append-only, verifiable record and a standalone verifier. We are not your compliance advisor, and we make no dated claim that using Sigilbase alone makes a system compliant.
What should an AI decision event contain?

An AI decision event should contain enough to reconstruct the decision: the model or actor identifier, the action taken, a hash of the inputs, the decision itself, and the reason codes. Sigilbase seals whatever fields you send in the event payload. Hashing the inputs lets you prove what the model saw without storing the underlying data in the log.
Can I prove a model decision was not changed later?

Yes. Each decision event is chained to the one before it and sealed into a signed checkpoint, so any later edit, deletion or reordering breaks verification. The standalone verifier names the sequence number that failed, so you can see exactly which record was touched.
Do I need to send Sigilbase my model inputs?

No, you do not have to send raw inputs. You can log a SHA-256 hash of the inputs instead, which proves what the model saw without placing the underlying data in the record. What each event contains is entirely under your control.
Does Sigilbase prove the model actually produced this output?

No. Sigilbase proves what you recorded and when, and that it has not changed since. It holds the record, not the computation. If you need proof that a given model ran on given inputs, that is a different problem, and we say so rather than blur it.

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.

More in this section

AI audit records. Why an AI decision log needs a custodian, and the rules that ask for one.
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.