Choosing On-Premise AI for Banks and Insurers: The Audit-Logging Requirements That Matter

The audit-logging requirements that matter for on-premise AI in banks and insurers are these: every model decision must be logged with its input, the model version, the authenticated actor and a precise timestamp; each record must be cryptographically signed and chained so it cannot be altered after the fact; the log must be retained for the full statutory period, commonly five years or longer; and a supervisor must be able to verify the whole chain independently and offline, without trusting the vendor. The reason is plain: a regulator does not accept a decision log that can be silently edited, so the signature and the independent check are what turn a log into evidence.

The regulatory pressure is converging in 2026. The EU AI Act adds automatic logging duties for high-risk systems, and although the Digital Omnibus deferred those Annex III obligations from 2 August 2026 to 2 December 2027, with embedded high-risk systems under Annex I moving to 2 August 2028 and Article 50 transparency duties largely unchanged, we read that as a build window and not a reprieve. Buyers choosing on-premise AI now are choosing the log they will have to defend later.

What exactly must be logged?

Log the decision, not just the event. For each AI-assisted output that touches a customer, a transaction or a control, the record should capture:

• The full input or prompt and the retrieved context that shaped the answer.
• The model identity and version, so the exact weights can be reproduced.
• The actor: the authenticated human or service account, bound to a hardware-attested identity where possible.
• The output itself, plus any confidence or consensus signal.
• A precise, synchronised timestamp.
• The downstream action taken and who approved it.

How must the log be signed, and why does that matter?

An unsigned log is a claim; a signed log is evidence. Each record should be cryptographically signed and chained to the previous one, so that altering or deleting any entry breaks the chain. FIPS 204, the ML-DSA standard, is NIST's post-quantum digital signature algorithm, the appropriate choice for a ledger that must stay verifiable for years. FIPS 203, ML-KEM, is a key-encapsulation standard for protecting data confidentiality; it does not sign anything, and a buyer should not accept it as evidence of tamper-proofing. The test is blunt: can an administrator quietly change a past record without detection? If yes, it is not an audit log.

Which rules make on-premise audit logging necessary?

Several regimes converge on the same duty.

• DORA, in force since January 2025, requires financial entities to keep records of ICT operations, incidents and third-party arrangements, available to competent authorities.
• ISO/IEC 42001 sets out an auditable AI management system, including logging, traceability and documented evidence of control.
• GDPR requires a record of processing and the ability to explain automated decisions that affect individuals.
• NIS2 raises incident-reporting and accountability duties for essential and important entities.
• The EU AI Act imposes automatic event logging on high-risk AI systems, with the Annex III obligations now deferred to 2 December 2027 and embedded high-risk systems under Annex I to 2 August 2028.

No rule is satisfied by architecture alone. Good architecture supports the duty and reduces the risk of failing it; the firm still owns the obligation.

How does a supervisor verify the log?

Verification has to be independent, or it is theatre. A supervisor, an internal auditor or a regulator should be able to check every signature against a published public key offline, confirm the hash chain is unbroken end to end, match a sampled decision back to its input and model version, and confirm that no records are missing across the retention period. The test to apply is the offline replay: hand the auditor the ledger and the public key on read-only media, disconnect everything, and ask them to prove that tampering would show. If verification needs the vendor online and cooperative, the vendor controls the evidence.

“An audit log a regulator will accept is one that survives independent, offline verification long after the vendor, the network and the administrator are gone.”

Why can regulated firms not simply use a public cloud AI service?

Public cloud AI services such as ChatGPT, Claude and Gemini are engineered for reach, not for sovereign evidence, and two issues recur. First, data egress: sending a prompt that contains customer or transaction data to an external endpoint moves regulated material outside the firm's perimeter and creates data-protection exposure. A contractual promise not to retain or train on that data is a commercial commitment, not a technical guarantee. Second, jurisdiction: under the US CLOUD Act, data held by a US-linked provider can be subject to lawful access requests regardless of where the servers sit. None of this makes cloud use automatically unlawful; it means the risk sits with the firm, and the audit log lives on infrastructure the firm does not control.

How does the Mickai SIOS approach audit logging?

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on operator-owned hardware, inside a zero-egress inbound perimeter, so regulated data is not shipped out to be processed. Every action is cryptographically sealed to a post-quantum signed audit ledger using ML-DSA under FIPS 204, and each entry is bound to a hardware-attested identity, making the recorded actor difficult to forge. The ledger is designed for offline verification, so an auditor can check the chain on air-gapped media without trusting us. This architecture supports the record-keeping duties above and reduces the risk of an unverifiable log; it does not, and cannot, certify compliance on a firm's behalf. The underlying design is covered by 104 filed UK patent applications and approximately 2,340 claims, owned by Mickai LTD; these applications are patent pending, never granted or patented.

Frequently asked questions

What is the best on-premise LLM for banks with audit logging?

The best choice is not a single model but a system that logs every decision with its input, model version and actor, signs each record cryptographically, retains it for the statutory period, and lets an auditor verify the chain offline. Ask each vendor to demonstrate the offline replay test on read-only media; a model that gives excellent answers but an unsignable log is the wrong choice for a regulated firm.

How long must AI audit logs be retained in financial services?

Retention depends on the applicable regime and record type, but financial record-keeping duties commonly require five years or longer, and some obligations extend further. Confirm the exact period with your compliance function, and design for the longest applicable period, because a log that expires before the obligation does is a gap.

Does ISO/IEC 42001 require audit logging for AI?

ISO/IEC 42001 sets out an auditable AI management system and expects traceability, logging and documented evidence of control across the AI lifecycle. It does not prescribe a single log format, but certification depends on showing that decisions can be traced and reviewed by an assessor.

Is FIPS 204 or FIPS 203 the right standard for signing an audit log?

FIPS 204, ML-DSA, is the post-quantum digital signature standard and the correct choice for signing an audit ledger. FIPS 203, ML-KEM, is a key-encapsulation standard for protecting data confidentiality, and it does not sign anything. If a vendor cites FIPS 203 as proof that a log is tamper-evident, treat it as a red flag.

Can we use ChatGPT or Claude for regulated banking work?

You can, but sending regulated customer or transaction data to an external service moves it outside your perimeter and creates data-protection and jurisdictional exposure, including under the US CLOUD Act. A contractual promise not to retain the data is not a technical guarantee. For work where the audit log must sit on infrastructure you control, on-premise processing removes that exposure.