AI Act for the Public Sector: What Applies and When

What the AI Act asks of public authorities right now

The AI Act came into force on 1 August 2024, and some of its rules already apply ^[1]. Since 2 August 2026, anyone deploying an AI system that interacts with people has had to make sure those people are told they are talking to an AI, unless it is obvious from the circumstances ^[2]. That includes chatbots, virtual assistants and automated phone systems in the public sector.

Think of it as the equivalent of a receptionist saying "I'll transfer you to our automated system" rather than quietly putting you through. The rule is there so people can adjust their expectations and ask for a human if they prefer.

For now, that transparency duty is the main obligation in force. The heavier requirements—technical documentation, logging, risk management and fundamental rights assessments—apply from later dates, depending on which category of AI the public authority is using.

High-risk AI and the two dates to remember

AI systems used in the public sector can fall into the high-risk category under Annex III of the AI Act ^[3]. The list includes biometric identification, management of critical infrastructure, access to education and vocational training, employment and worker management, access to essential public services and benefits, law enforcement, migration and border control, and administration of justice.

For those systems, the full set of high-risk obligations applies from 2 December 2027 ^[4]. That means automatic logging under Article 12, data governance under Article 10, technical documentation, human oversight, a quality management system and a conformity assessment before the system is placed on the market.

A second wave follows on 2 August 2028, covering high-risk systems under Annex I: products already subject to third-party conformity assessment, such as machinery, medical devices and toys with AI components ^[5].

The practical upshot is that most public authorities have until December 2027 to get their high-risk systems into line, and a further eight months for certain product categories.

What Article 12 says about logging

Article 12 requires high-risk AI systems to technically allow for the automatic recording of events over their lifetime ^[6]. The logs must support traceability, post-market monitoring and the user's oversight.

The article says what to log. It does not say how to protect the logs. A log its operator can quietly edit is easy to challenge. When someone questions a decision months later—say, a refused benefit or a failed job application—the question will be whether the log can be shown to be unchanged since the decision was made.

Access controls and monitoring are the foundation. An independent seal on each log record goes further, because a change shows up even when it is made by someone with the right access.

Impact assessments before deployment

Article 27 adds an obligation for certain users of high-risk AI: a fundamental rights impact assessment before the system is put into use ^[7]. Public authorities are explicitly on that list, as are private actors providing public services.

The assessment must describe the deployment context, the period of use and frequency, the categories of people likely to be affected, the specific risks to their rights, and the measures taken to address those risks. If the authority already carries out a data protection impact assessment under the GDPR, the two can be combined into one document.

The duty applies each time a high-risk system is deployed, not just once for the whole organisation.

Who checks the logs, and when

Logs are kept by the same people who could change them. That matters when an auditor, a supervisor or a court asks to see them. Under Article 19, providers must keep logs for at least six months, and under Article 26.6, so must deployers ^[8].

Internal audit, supervisors and individuals affected by decisions can all ask for evidence of what the AI did. If the log is the only record, its integrity becomes the question.

What a digital witness does in a public authority's logs

Here, the thing to seal is each log record as it is written: the input reference, the model version, the output and, if there is one, the reviewer. Sealing takes a fingerprint of the record, not the record itself, so nothing sensitive leaves the authority's systems.

The seal goes onto WitniumChain, where any later change would show, even one made by the authority itself. To check, an auditor or a supervisor calculates the fingerprint again and compares it with the sealed one. Change a single character in the log and it will not match.

Who can check: internal audit, supervisors, the person affected and, if it comes to it, a court.

What it shows: that the log record is exactly what was written at that time.

What it does not do: it does not show that the decision was right, fair or lawful, or that the log is complete. It just shows that the record has not been rewritten since it was sealed.

You seal log records through the REST API, the SDK or the MCP server read the docs. Your system sends a fingerprint, gets a witness ID back and stores both. The first 2,000 witnesses a month are free.

How it would work

1. The authority's system writes a decision to the log and sends a fingerprint to WitniumChain.
2. WitniumChain seals the fingerprint and returns a witness ID.
3. Months later, when the decision is questioned, the authority calculates the fingerprint again. If it matches, the record has not changed.

What this means for you

If you run AI in the public sector, ask:

• Which of our AI systems interact with people, and have we told them they are talking to an AI since August 2026?
• Which systems fall under Annex III, and do we have until December 2027 to meet the high-risk requirements?
• For each high-risk deployment, have we planned the fundamental rights impact assessment?
• Who keeps the logs Article 12 requires, and could we show they have not been edited if someone asks?
• If a decision is challenged a year from now, what record will we have?

What to watch

The AI Office's guidelines on Article 27 impact assessments are expected in the first half of 2027 ^[9]. Harmonised standards for technical documentation and logging will follow later in the year.

Public procurement rules are also being updated to reflect the AI Act, so tendering authorities will need to check that systems they buy meet the relevant requirements before deployment.

The first enforcement actions are likely to focus on transparency breaches and high-risk systems placed on the market without conformity assessment, so getting the logging and documentation right early is a good use of time.