EU AI Act for GovTech Developers: Public Sector AI High-Risk Compliance Guide

Post #5 in the sota.io EU AI Act Sector-Specific Developer Series

Public sector AI operates under the EU AI Act's most demanding compliance regime. While private-sector developers building high-risk AI face conformity assessments, technical documentation, and registration, GovTech developers face all of that — plus a mandatory Fundamental Rights Impact Assessment (FRIA), stricter transparency obligations toward citizens, and coverage under four distinct Annex III high-risk categories: public benefits, law enforcement, migration and border control, and administration of justice.

If your system touches public authorities or deploys AI that affects citizens' rights, access to services, or legal outcomes, you are almost certainly in scope. The compliance deadline is 2 August 2026 — and the gap between a GovTech AI system's typical procurement cycle and AI Act implementation timelines is already a risk in itself.

This guide covers the full picture for GovTech developers: which Annex III categories apply, what obligations arise, and a 30-step compliance checklist to get your system audit-ready.

Why GovTech AI Is in the Highest Scrutiny Tier

Most EU AI Act compliance discussions focus on whether a system is "high-risk." For GovTech AI, that question is largely already answered.

The regulation's Annex III lists eight categories of high-risk AI. Four of those categories — covering roughly 60% of typical GovTech use cases — apply directly to public-sector deployment:

• Annex III, Point 5: AI systems used by public authorities to evaluate eligibility for public benefits and services
• Annex III, Point 6: AI systems in law enforcement contexts
• Annex III, Point 7: AI systems in migration, asylum, and border control management
• Annex III, Point 8: AI systems in the administration of justice and democratic processes

A fifth category, Annex III, Point 1 (biometric identification), is relevant for any GovTech system that includes identity verification or surveillance components.

The result: GovTech AI doesn't need a classification exercise to trigger AI Act obligations — it needs a compliance programme.

The Four GovTech High-Risk Categories

Annex III, Point 5 — Public Benefits and Essential Services

This is the broadest GovTech category. It covers AI systems intended to be used by public authorities — or by private bodies providing public services — to evaluate eligibility for essential public benefits and services.

In scope:

• Social welfare eligibility assessment (housing benefit, unemployment support, disability payments)
• Healthcare access prioritisation (NHS-style triage AI, care needs assessment)
• Public housing allocation algorithms
• Child welfare risk scoring systems
• Public pension and retirement benefit processing

The critical scope test is whether the AI system makes or materially influences decisions about a natural person's access to essential services. If the answer is yes and the entity is a public body (or acting as one), Point 5(b) applies.

The practical challenge for developers: Many GovTech systems sit at the interface between the AI system and a human caseworker. "We just provide a risk score — a human makes the final call" does not exempt your system from high-risk classification. Under Article 14, the human oversight requirement applies to the system as a whole, and the AI developer is responsible for making that oversight technically meaningful.

Annex III, Point 6 — Law Enforcement

Law enforcement AI is subject to some of the act's strictest provisions. Covered systems include:

• Predictive policing tools (crime likelihood scoring by area or individual)
• Risk assessment for recidivism or re-offending
• AI-based evidence analysis and pattern detection
• Polygraph or emotion detection tools used in criminal investigations
• Biometric identification systems used in real-time law enforcement contexts

Real-time remote biometric identification in publicly accessible spaces for law enforcement is a prohibited AI practice under Article 5 — with narrow exceptions for serious crimes and judicial authorisation. If your system touches real-time facial recognition in public spaces, the prohibited use provisions apply before the high-risk provisions do.

For non-prohibited law enforcement AI, the obligations are full Annex III: risk management, data governance, human oversight, conformity assessment, and registration.

Annex III, Point 7 — Migration, Asylum, and Border Control

Point 7 covers AI used by border management authorities, immigration services, and asylum-processing bodies. This includes:

• Risk scoring for visa applications
• Automated asylum application triage and credibility assessment
• AI-assisted border checks and document verification
• Travel route risk analysis
• Fraud and identity detection in migration contexts

This category is particularly sensitive because adverse AI decisions — denial of asylum, flagging for secondary inspection, visa rejection — have severe, often irreversible consequences for affected individuals. The human oversight obligations under Article 14 are directly intended to address exactly this asymmetry.

Annex III, Point 8 — Administration of Justice and Democratic Processes

Point 8 is the category most developers overlook — it has the widest implications for trust in public institutions. Covered systems include:

• AI tools assisting courts in legal research, case prioritisation, or sentencing recommendations
• AI systems for assessing legal disputes in alternative dispute resolution (ADR) proceedings
• AI systems used to influence election outcomes, voter behaviour, or democratic participation

The "democratic processes" provision is significant: AI systems designed to influence voter opinion at scale — including personalised political messaging platforms, voter targeting systems, and disinformation detection tools deployed by government entities — fall within Point 8 if they affect democratic participation.

Article 7: The Annex III Expansion Power

Article 7 grants the European Commission power to amend Annex III by delegated act — adding new high-risk categories or modifying existing ones where AI systems pose risks comparable to those already listed.

For GovTech developers, this matters for two reasons:

1. Future-proofing: A system that is not high-risk today may become so within your product's operational lifetime. Building compliance infrastructure now — risk management, documentation, audit trails — is cheaper than retrofitting.

2. Procurement leverage: Public procurement frameworks in several EU member states are beginning to require AI Act compliance documentation as a tender condition. Demonstrating readiness for Article 7 amendments signals maturity to public-sector buyers.

GovTech-Specific Obligations

Article 27 — Fundamental Rights Impact Assessment (FRIA)

The FRIA is mandatory for deployers who are public authorities, or private entities providing public services. This is the GovTech-specific obligation that private-sector AI developers typically don't face.

The FRIA requires a documented assessment of how the AI system may affect:

• Fundamental rights protected by the EU Charter (dignity, equality, privacy, non-discrimination)
• Specific vulnerable groups (children, elderly, persons with disabilities, migrants)
• The right to effective judicial remedy and fair trial (particularly relevant for Point 8 systems)

The FRIA must be registered in the EU database and conducted before deployment. For systems already in use by public authorities on the date of the August 2026 obligation entry into force, retrospective FRIA compliance applies.

What this means in practice: GovTech developers building systems for public-authority deployers should design their documentation so that the FRIA can be completed efficiently. This means providing deployers with:

• Documented model training data sources and bias testing results
• Known limitations and error rates by demographic subgroup
• Recommended use boundaries
• Human oversight design rationale

Article 9 — Risk Management

Article 9 requires a continuous risk management process integrated into the development lifecycle — not a one-time assessment. For GovTech AI:

• Risks must be identified and analysed at each stage from design to post-market monitoring
• Residual risks after mitigation must be acceptable relative to expected benefits
• Post-deployment feedback loops must be established to identify emerging risks

Public-sector deployers frequently work with procurement cycles that span multiple years. Risk management documentation must remain current throughout — a risk assessment conducted in 2024 for a system deployed in 2026 needs updating.

Article 10 — Data Governance

Article 10 data governance requirements are particularly consequential in GovTech contexts because:

• Training data for public-sector AI often reflects historical patterns of systemic inequality
• Bias in training data for eligibility scoring or recidivism prediction directly produces discriminatory outcomes
• Government data sources may include special-category personal data (criminal records, health, ethnic origin) with additional GDPR protections

Article 10 requires bias examination in training and test data, and measures to address identified biases. For GovTech systems, this means demographic subgroup performance analysis is mandatory — not optional.

Article 13 — Transparency Toward Citizens

Article 13 requires that high-risk AI systems be transparent enough that deployers can understand what the system does and communicate this appropriately to affected persons.

For GovTech, this translates into citizen-facing transparency obligations: individuals whose access to benefits, migration status, or legal treatment is affected by an AI system have a right to know that AI was used and to understand the basis for any adverse decision. This intersects directly with GDPR Article 22 rights around automated decision-making.

Article 14 — Human Oversight

Article 14 requires that high-risk AI systems be designed to allow appropriate human oversight during operation. For public-sector systems where adverse decisions have severe consequences, the human oversight requirement must be genuinely meaningful — not a nominal "human in the loop" who cannot practically review AI outputs at the required throughput.

GovTech developers should document:

• The specific human oversight mechanisms built into the system
• The expected caseworker review time per decision
• What information is surfaced to the human overseer
• The mechanism for overriding AI recommendations

Article 17 — Quality Management System

A documented quality management system (QMS) is required for providers of high-risk AI. For GovTech providers, the QMS must cover strategy, governance, development, deployment, post-market monitoring, and documentation retention.

Many GovTech system integrators and software vendors serving the public sector already operate under ISO 9001 or sector-specific quality frameworks. The AI Act's QMS requirements can generally be integrated into existing frameworks rather than built from scratch.

Articles 43 and 49 — Conformity Assessment and Registration

Most Annex III high-risk AI systems undergo self-assessment conformity (Article 43), but systems involving real-time biometric identification and some law enforcement applications require third-party notified body assessment.

All high-risk AI systems must be registered in the EU AI Act database before they are placed on the market or put into service (Article 49). For GovTech systems deployed by public authorities, this obligation falls on the provider — but the deployer (public authority) must conduct and register the FRIA separately.

Key Differences: GovTech vs Private-Sector High-Risk AI

30-Step GovTech AI Act Compliance Checklist

Classification and Scope (Steps 1–6)

1. Map all AI components in your system against Annex III Points 1, 5, 6, 7, and 8
2. Document the intended purpose and deployer type (public authority vs private body providing public services)
3. Identify whether any component falls under Article 5 prohibited practices (real-time biometric ID in public spaces)
4. Confirm whether Art.6 exclusions apply (safety components of non-AI products, narrow-purpose tools)
5. Map downstream use cases — if your system is a general-purpose tool that public authorities use for high-risk decisions, re-assess scope
6. Document the Article 7 risk register: could future Annex III amendments affect your product?

Risk Management (Steps 7–10)

1. Establish Article 9 risk management as a continuous process with documented reviews at each development phase
2. Identify and document known risks, residual risks after mitigation, and acceptable risk thresholds
3. Design post-deployment feedback mechanisms for emerging risk identification
4. Establish incident escalation protocols and assign accountability

Data Governance (Steps 11–15)

1. Document training data sources, collection methodology, and applicable licences
2. Conduct bias analysis across relevant demographic subgroups — document results and remediation actions
3. If special-category personal data (health, ethnic origin, criminal records) is in the training set, document legal basis under GDPR
4. Implement data quality checks and document validation datasets
5. Establish data retention and deletion schedules consistent with GDPR requirements

Technical Documentation (Steps 16–19)

1. Prepare Annex IV technical documentation package (system description, architecture, training data details, validation results)
2. Document intended purpose, use conditions, and foreseeable misuse scenarios
3. Record system performance metrics by subgroup
4. Establish version control and document update procedures

Human Oversight Design (Steps 20–22)

1. Design Article 14 human oversight mechanisms that are genuine — account for expected decision throughput per human overseer
2. Document what information is surfaced to the human reviewer and in what format
3. Build and test AI recommendation override flows

Conformity Assessment (Steps 23–25)

1. Determine whether self-assessment or third-party notified body assessment applies under Article 43
2. Complete internal conformity assessment with documentation package
3. Issue EU Declaration of Conformity

Registration and FRIA (Steps 26–28)

1. Register the system in the EU AI Act database under Article 49 before deployment
2. If deployer is a public authority: coordinate FRIA preparation (provide deployer with bias data, performance limitations, oversight design documentation)
3. If you are both provider and deployer (in-house GovTech build): complete and register the FRIA separately from the conformity assessment

Post-Market Monitoring (Steps 29–30)

1. Establish post-market monitoring plan per Article 72 — define KPIs, reporting intervals, and responsible team
2. Define serious incident reporting process under Article 73 and test reporting pathways before go-live

The Public Procurement Dimension

EU member states are integrating AI Act compliance requirements into public procurement frameworks. In practice this means:

• Tender specifications increasingly require proof of AI Act conformity assessment
• Framework agreements for public-sector software may include AI Act compliance as a contract condition
• Public authorities will require FRIA-ready documentation from their AI vendors

GovTech developers who build AI Act compliance documentation into their standard sales package — covering technical docs, bias testing results, human oversight design, and FRIA support materials — are positioned to win tenders over competitors who treat compliance as an afterthought.

2026 Timeline for GovTech Compliance

The August 2027 grace period applies to AI systems that were already in use before August 2026 — not to new systems deployed after that date. If your system launches after August 2026, full compliance is required from day one.

Completing the Sector-Specific Series

This post concludes the five-part EU AI Act Sector-Specific Developer Series:

1. EdTech — AI literacy, educational outcome systems, Annex III Point 3
2. HR-Tech — recruitment AI, CV screening, Annex III Point 4 bias obligations
3. FinTech — credit scoring, loan decisions, Annex III Point 5(b) and DORA intersection
4. HealthTech — clinical AI outside MDR/IVDR, Annex III Point 5(a) social and clinical support
5. GovTech — public sector AI across four Annex III categories, FRIA obligations

Each sector carries distinct obligations shaped by the specific risks AI poses in that context. The common thread: developers who treat AI Act compliance as a product design input — not a post-launch audit — are the ones who will be ready when August 2026 arrives.

Need a sovereign EU deployment environment for your GovTech AI system? sota.io is an EU-native managed PaaS on Hetzner Germany — no US parent company, no CLOUD Act exposure, GDPR-native infrastructure. Deploy your GovTech AI stack with full EU jurisdiction from day one.