FI to examine *cyber threats from advanced AI models*

Finansinspektionen (FI), Sweden's financial supervisory authority, has announced a review of how banks, insurers and other financial firms handle cyber threats from advanced AI models. The review will look at whether firms have adequate measures in place, and whether they can prove their security, logging and risk management meet the rules.

The timing is no accident. DORA's technical standard on ICT risk management has applied since 17 January 2025, and it includes a line about logs that matters more than it sounds: logs must be protected against tampering, deletion and unauthorised access ^[2]. The AI Act's logging requirement for high-risk systems applies from 2 December 2027 ^[3]. FI wants to know what firms are doing now, before those systems go live.

What DORA says about logs

A log is like a receipt drawer. It tells you what happened and when, and that's useful until someone needs to be sure nothing in the drawer has been rewritten. DORA's technical standard is clear that logs must be protected against tampering. The hard part is the last mile: when the people who keep the logs could also change them, how do you show that nobody did?

Article 12(2)(d) of Commission Delegated Regulation (EU) 2024/1774 says financial firms must have logging procedures that protect log systems and log information against tampering, deletion and unauthorised access, and that detect failures in the logging function ^[2]. That's what FI will be checking: not just whether logs exist, but whether they can be trusted.

What the AI Act adds

Article 12 of the AI Act requires high-risk AI systems to technically allow for the automatic recording of events over their lifetime ^[3]. The requirement applies to systems under Annex III from 2 December 2027, which includes AI used for credit scoring of natural persons, pricing of life and health insurance, recruitment and work management. Systems under Annex I, such as safety components in products, follow from 2 August 2028.

The rule says what to log. It doesn't say how to protect the logs once they exist. But in a supervised sector like finance, being able to show FI or an auditor that a log hasn't changed since it was written is not optional in practice.

Why FI is looking now

FI's review is described as a detailed analysis that will inform how the authority supervises AI-related risks in the financial sector ^[1]. Translation: FI wants to understand what firms are doing before the high-risk deadlines arrive, and what gaps need closing.

Advanced AI models bring specific risks. They can be manipulated, they can behave unpredictably under pressure, and they make decisions that may need explaining months later. If a model scores a loan application wrongly and the customer complains, the log is what tells you what the model saw, which version ran and what it decided. If that log could have been edited along the way, its evidential value is limited.

That's the question behind FI's review: not whether firms are logging, but whether the logs will hold up when they're needed.

What logs under pressure look like

Say a payment fraud alert fires at 03:00, an operations team investigates and finds nothing, and the alert is closed as a false positive. Three months later, a customer reports unauthorised transactions from that night. An auditor asks for the logs. The entries are there, but so is a question: could someone with administrator rights have tidied them up before the audit?

Access controls and monitoring are the foundation. A witness seal on each log segment goes one step further, because a change shows up even when it's made by someone with the right access.

How a witness makes logs checkable

Here, the thing to seal is log segments as they close, for example every few minutes. Your system sends a fingerprint of the segment, not the segment itself, to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back. The logs stay on your systems. To check, anyone you share a log with calculates the fingerprint again and compares it with the sealed one. Change a single character and it won't match.

Internal audit, FI and incident responders can all check it the same way, without having to trust your word that the log is clean.

What it doesn't do: it doesn't replace access control, monitoring or backups. It doesn't show that the log is complete, or that the response to an incident was adequate. It shows that what you're looking at now is exactly what was written then.

The first 2,000 witnesses a month are free. Read the docs at witniumchain.com/docs.

What this means for you

If you work with AI or ICT risk in a financial firm, FI's review is a signal to ask a few questions early:

• Can you show FI that your logs haven't changed since they were written, when your own people have access to them?
• Do you know which of your AI systems will count as high-risk under Annex III from December 2027, and what events they log?
• If an incident happens and the early warning goes out after 30 hours instead of 24, can you show exactly when you became aware of it?
• Who in your organisation decides how logs are protected, and have they read Article 12(2)(d) of the DORA technical standard?

FI hasn't said when the review will be published, but the questions it asks now are the ones that will shape supervision later.

What to watch

• 2 December 2027: High-risk requirements under Annex III of the AI Act apply, including automatic logging under Article 12 ^[3]
• 2 August 2028: High-risk requirements under Annex I apply ^[3]
• FI's publication of its findings from this review, expected later in 2026 ^[1]