Public sector AI
that shows its work.

Public bodies sit under the general AI rules and under a set of additional ones aimed specifically at them. How these apply to a particular system is a determination for your own legal service; what follows is how they change the engineering.

Prohibited practices bind everyone. The EU AI Act’s prohibitions — social scoring of natural persons leading to detrimental treatment in unrelated contexts among them — apply to public and private actors alike. The prohibition on social scoring is often described as an administration-specific rule; it is not, and reading it that way is how a well-meaning risk-stratification project ends up on the wrong side of a line.

Several Annex III categories cover public services. The high-risk list includes systems used by, or on behalf of, public authorities to evaluate eligibility for essential public assistance benefits and services, and to evaluate and classify emergency calls and dispatch emergency services, alongside categories covering law enforcement, migration and asylum, and the administration of justice. If a system you are commissioning sits in one of those, the obligations are substantial and they land on the engineering: risk management, data governance, logging over the lifetime of the system, technical documentation, human oversight and demonstrated robustness.

Deployers who are public bodies carry extra duties. Public authorities deploying a high-risk system face obligations beyond those of a private deployer, including registration in the EU database and, for the relevant categories, a fundamental rights impact assessment carried out before the system is put into use. A fundamental rights impact assessment is not a document a supplier can write for you — it is an assessment of your process, your population and your safeguards. What we can do is supply the artefacts it needs: what the system does, on what data, with what human involvement, what happens when it is wrong, and what the affected person can do about it. The EU AI Act page covers the classification questions in more detail.

Transparency, records and accessibility. Assume every interaction may be disclosed. That means the log has to be complete enough to answer a question about a specific case months later, and readable by someone who was not there. It also means the citizen-facing surface has to be accessible in earnest — the EU Web Accessibility Directive obligations do not pause because the interface now has a language model behind it. Our approach to that is set out on the accessibility page.

Public procurement favours suppliers who can evidence controls, and it is worth being direct about where that leaves us. QQuantum.ai holds no security certifications. Not ISO 27001, not anything else. If your framework requires a certified supplier of record for this scope, we are not it, and we would rather say so in the first conversation than in the tender response.

What we do instead is make the controls inspectable rather than attested. The system runs in your infrastructure under your identity provider. The code is in your repositories from the first commit. The architecture document states where every category of data goes and which model sees it. The evaluation harness and its method are handed over with the system. Access is scoped to what the triggering official already holds. Every prompt, retrieval and action is logged with an identity. Your auditor tests those directly, which is a stronger position than reading our certificate — and we say that knowing it does not always satisfy a scoring matrix.

Two other patterns are worth naming. Working as a subcontractor to a certified prime is a normal arrangement and one we are comfortable with. And a small, scoped first engagement — one workflow, evaluated, handed over — usually tells a procurement team more about a supplier than any framework can, and it is easier to place under most thresholds. The procurement and security review page sets out what we can answer and what we cannot.