Each of these arrives long after the decision, from someone who was not there.
These are the questions themselves, drawn from the workflows we build for.
AI vendors selling into regulated buyers
“How do we verify what your AI decided in production, and under which policy?”
Decision runs in production
Signed here, before it runs
Weeks to months
Security review, per buyer
Checked here, without us
Today
The answer is assembled by hand for every new customer: screenshots, an engineer’s explanation, a policy document, a log export.
With Seal
Each decision returns a signed record naming the policy that applied and what was decided, refusals as well as approvals. The pack goes to the reviewer once and is the same pack for the next buyer.
What a reviewer can establish
Which policy version was in force when the call ran
What was decided, including calls that were refused before reaching the model
That the record has not been altered since it was signed
That the reviewer can check all of this without an account and without contacting us
What it does not establish
That the model reasoned well, or that the decision was correct
“Why was this application declined on the fourteenth of March?”
Application declined
Signed here, before it runs
Eighteen months
Regulator, auditor or solicitor
Checked here, without us
Today
The question usually arrives from outside, and the answer has to travel there too.
With Seal
The customer’s own policy runs before the model call. The decision is signed at the moment it is made, and the evidence pack drops into the existing model-risk file rather than replacing it.
What a reviewer can establish
The decision, the policy applied, and the moment it happened
Per-decision evidence behind the AI entries in a DORA Article 28(3) Register of Information
Chained export, so an insertion, deletion or edit is detectable by any reader
What it does not establish
That the underwriting judgement was sound
That the applicant was treated fairly, which is a separate question requiring separate evidence
“Did each of these decisions clear under the policy that was in force when it ran?”
Claims and underwriting calls
Signed here, before it runs
Before go-live
Chief risk officer signs off
Checked here, without us
Today
The approval rests on a description of the system rather than a record of it.
With Seal
The approved policy is the policy that executes, and each decision carries the version that applied. A reviewer opens a docket with one fixed question, set before the evidence is opened so it cannot be adjusted to fit the answer.
What a reviewer can establish
Which rule applied to each decision in scope
That approvals and refusals were both recorded, not only the outcomes that passed
A named reviewer’s verdict, signed with a credential Aqta did not issue
What it does not establish
That the pricing or claims judgement was right
That the model is free of bias, which the record does not measure
A dashboard is useful inside the organisation and carries no weight with a reviewer outside it.
With Seal
PHI categories are masked or rewritten upstream, so the model runs on what it is cleared to see. Routes where the model should not decide alone require a human decision before anything executes, and the record names who cleared what.
What a reviewer can establish
The model, the policy, the verdict, the time, and a one-way fingerprint of the prompt
That a clinician signed off where sign-off was required
That the record itself carries no clinical content: it holds a fingerprint of the prompt, not the note
What it does not establish
That the clinical decision was correct
Any certification, accreditation or compliance opinion. Aqta issues records, not approvals
The limits are published on purpose.
A signature proves a record was not altered. It does not prove the computation ran as described, or that no decision was omitted.
