Finland's classified AI assistant raises a question every government will face

A state AI that handles state secrets

Finland's Ministry for Foreign Affairs has developed UMAI, an AI assistant designed to process security-classified and confidential documents ^[1]. It runs on the ministry's own servers, not in a third-party cloud, precisely because of the sensitivity of the material it handles. That decision reflects a wider pattern: when AI is used in environments where data classification matters, someone has to decide early where the data lives, who can see it and how its handling is documented.

Think of it like the locked drawer in a government office. You can put an AI assistant in the drawer with the files, but once you do, the drawer's lock and its log of who opened it when become part of the same security question.

The case is interesting not because it is unusual, but because it will become common. Governments, hospitals, financial institutions and defence contractors all have data that is classified, confidential or subject to strict access controls. AI that works with such data needs to deliver value without creating new risks. One of those risks is what happens to the logs.

What the AI Act requires

Article 12 of the AI Act says that high-risk AI systems must technically allow for the automatic recording of events over their lifetime ^[2]. The rule applies to systems under Annex III from 2 December 2027 and to systems under Annex I from 2 August 2028. It does not say how to protect the logs, only that they must be kept.

Article 19 and Article 26.6 then say that providers and deployers must keep the logs they control for at least six months, unless another law requires longer ^[3]. For a foreign ministry handling classified material, other laws almost certainly do require longer, and they probably also say who may access the logs and under what conditions.

The gap is this: the AI Act asks for logs, but it does not specify what stops someone with the right access from editing them later. In most settings, that gap is closed by access controls, monitoring and regular audits. In a classified setting, those controls are tighter, but the question remains: if a log records who accessed what document when, and someone with administrator rights could change that log, how do you show an auditor or a supervisor that the log you are presenting is the one written at the time?

The GDPR layer

If the logs contain personal data, which they often do, GDPR applies. Article 5.1(c) requires that personal data be limited to what is necessary, and Article 5.1(f) says it must be protected against unauthorised alteration ^[4]. Article 32 adds that the protection must be appropriate to the risk.

For a system like UMAI, the logs might record which official queried which document, when and what the AI suggested. That is personal data, and it is also operationally sensitive. Keeping such logs longer than needed, or accessible to more people than necessary, creates a risk under GDPR. Allowing them to be altered, even inadvertently, creates another.

The short version: GDPR does not say you must seal your logs, but it does say you must protect them, and one common way to show protection is to demonstrate that changes would be detectable.

What this means for you

If you are deploying AI in an environment where access is restricted or data is classified, ask these questions now:

• What will the AI log, and where will those logs be kept?
• Who can access the logs, and who can change them?
• If you had to show a supervisor or an auditor that a log has not been edited, how would you do it?
• Does the log contain personal data, and if so, how long do you need to keep it under GDPR and any sector-specific rules?
• If the AI handles classified or confidential material, are the logs themselves classified, and does that change how they must be stored and audited?

Those questions do not have one answer for every organisation. A foreign ministry, a hospital, a bank and a defence contractor will answer them differently. What they have in common is that they need to answer them before the system goes into production, not after someone asks to see the logs.

How a digital witness fits here

Here, a digital witness is a direct answer to one part of the problem: proving that a log has not changed.

What you seal is each log entry as it is written. That might be a record of a query (user reference, document reference, timestamp and the AI's response summary), or it might be a batch of entries every few minutes. You seal a fingerprint, not the content, so the log itself stays on your servers, under your access controls. The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back ^[5].

When an auditor or a supervisor asks to see the logs, you give them the log file and the witness ID. They calculate the fingerprint again and check it against the sealed one. If it matches, the log has not changed since it was sealed. Change one character and it will not match.

Who can check it: internal audit, supervisors, the data protection officer and, if it comes to it, a court. The content of the log remains classified, but its integrity is checkable.

What it shows: that the log entry is exactly what was written at that time, even if someone with administrator rights has had access to the server since.

What it does not do: it does not replace access controls, monitoring or encryption. It does not show that the log is complete, that the AI's answer was correct or that the query was lawful. It shows one thing: that the record has not been altered.

How it would work

1. Each log entry is sealed as it is written, or in small batches.
2. The fingerprint, not the log content, is sent to WitniumChain.
3. To check, anyone with the right clearance calculates the fingerprint of the log entry again and compares it with the sealed one.

The first 2,000 witnesses a month are free ^[5].

What to watch

2 December 2027 is when the high-risk requirements under Annex III, including Article 12's logging duty, apply to new systems. Systems already on the market have longer, but the question of how to protect logs is worth answering now, not in late 2027 when someone asks for them.

If you work in a sector where data classification, confidentiality or strict access controls apply, the Finland case is worth reading as a preview. The ministry has solved the first question, which is where the AI runs. The next question is how to show that what it logged is what it actually logged, and that question applies to every AI that handles sensitive material.