Acceptance Testing Checklist for AI Models in Public Administration

Why an AI-specific acceptance test

AI models are more than code: they are systems that combine data, models and operational processes. Traditional acceptance testing (UAT) typically validates functionality; for AI you must also verify robustness, explainability, privacy and regulatory controls (ENS RD 311/2022, GDPR, EU AI Act). Without clear tests, deploying in a municipal environment can create legal, operational and reputational risks.

Below is an operational, reproducible checklist to decide whether an AI model is ready for production in a public entity.

Actors and minimum deliverables before starting tests

• Responsible team: service owner (public official), technical lead, security officer (ENS), Data Protection Officer (DPO), legal representative.
• Prior deliverables: functional and non-functional requirements document, model card and data sheet, test plan, risk matrix and mitigation plan, contract/SLA with provider if applicable.
• Record of decisions: UAT kick-off minutes with quantified acceptance criteria.

Test checklist (minimum mandatory)

1. Functionality and expected behavior

• Key use cases: run all critical paths (e.g., bid evaluation, case classification) with representative data.
• Measurable criteria: accuracy, recall, F1, acceptable error rates defined by the service.
• Regression tests: ensure new models do not degrade existing processes.

2. Robustness and performance

• Load and latency tests: defined SLOs/SLAs (e.g., 95% of responses < X ms).
• Resilience to adversarial inputs: incomplete inputs, unexpected formats, malicious text.
• Out-of-distribution (OOD) behavior: measure performance on data different from the training set and document mitigations.

3. Bias and fairness

• Test sets for relevant subgroups (age, gender, neighborhood, etc.) to detect disparities.
• Rejection criteria: allowed thresholds for differences between groups and corrective measures (retraining, business rules).
• Record fairness metrics as part of acceptance.

4. Explainability and documentation

• Explainable outputs: the system must provide understandable justifications for automated or assisted decisions.
• Deliverables: updated model card, documentation of influential variables, example explanations for non-technical staff.
• Procedure for responding to citizen information requests (GDPR rights).

5. Privacy and data protection (GDPR)

• DPO review: analysis of personal data processing, legal bases and minimization.
• Tests for anonymization/synthesis if test data are used in non-production environments.
• Verification of mechanisms to address rights of access, rectification, erasure and restriction.

6. Security and ENS compliance

• Security tests: access controls, encryption in transit and at rest, pentesting of interfaces and APIs.
• ENS classification: check that infrastructure and service align with RD 311/2022 according to the required protection level.
• Controls for segregation between environments (dev/test/prod) and credential management.

7. Compliance with the EU AI Act (if applicable)

• Determine the system's risk classification (low, high, prohibited).
• For high‑risk systems: technical documentation, log registration, evaluation procedures and proof of mitigations.
• Verification of transparency requirements and notices to citizens when applicable.

8. Monitoring, traceability and governance

• Logging tests: traceability of inputs, outputs, model versions and human decisions.
• Alerts and dashboards: degradation thresholds and escalation procedures.
• Maintenance and periodic review plan (retraining, recalibration).

9. Integration and operations testing

• End-to-end tests in an environment that replicates production: orchestration, queues, integrations with legacy systems.
• Documented and tested rollback plan (perform a simulated rollback).
• Validation of SLAs and contractual clauses with providers.

10. Operational training and manuals

• Usability tests for staff: operational guides, human intervention flows and criteria to override/replace automated outputs.
• Incident drill: how to respond to incorrect decisions or security incidents.

Acceptance criteria and final delivery

• Acceptance document signed by the service owner, DPO and security officer.
• Technical report including: results of all tests, metrics, open incidents with mitigation plans, approved model version, and post‑deployment monitoring plan.
• Launch checklist with dates and responsible parties for 30, 90 and 180 day reviews.

Quick example of a verdict

• If more than 80% of critical tests pass and open incidents are not high legal/security risks, authorize a controlled deployment with intensive monitoring for 30 days. Otherwise, block production until mitigations are implemented.

Takeaway / Recommended action

Before deploying an AI model to production, run this checklist adapted to your context, produce an acceptance report signed by the DPO and security officer, and schedule periodic reviews. At OptimTech we recommend turning the checklist into a mandatory form within the municipality's AI governance procedure to ensure traceability and compliance.