Sector
A public body does not buy a model, it buys a service it will have to explain, audit and eventually take back in house. That shapes the technical choices far more than raw performance does.
The public sector is not short of data, it is short of access. Line-of-business databases are old, reference data is fragmented and sometimes contradictory, and the data was almost always produced for a purpose other than the one you now have in mind. Obtaining a real, representative, documented extract routinely takes longer than all the modelling that follows.
Error is asymmetric here. Getting a citizen’s file wrong is not the same as a commercial mistake: it touches an entitlement, it can be challenged, and it is hard to undo. That asymmetry moves the technical dial. You favour a system that triages, prepares and documents over one that decides, and you accept sitting below the statistical optimum in order to stay above the threshold of acceptability.
Public procurement requires you to describe what you are buying before it has been built. AI projects describe badly in closed specifications: what is feasible depends on data nobody has looked at yet. Splitting the work into phases, scoping then a qualified prototype then industrialisation, serves procurement regularity as much as risk control. A contract with no exit after the prototype manufactures projects that can no longer be stopped.
Reversibility is not boilerplate. The administration has to be able to take the service back or hand it to a third party: that means source code, model weights, training and evaluation sets, operating procedures and documentation, delivered and current. Not access to a platform.
The public sector stacks frameworks. None is optional, and several close off technical options before the feasibility study begins.
AI systems intended to evaluate eligibility for essential public assistance benefits and services, or to grant, reduce, revoke or reclaim them, are high risk. A point often missed: a public body putting a third-party system into service acts as a deployer, with obligations of its own, distinct from the provider’s: human oversight, monitoring in service, informing affected persons. Buying a compliant product is not the same as being compliant.
The legal basis is usually the performance of a task carried out in the public interest. A data protection impact assessment is expected where processing is likely to result in a high risk, which is the norm for large-scale processing of citizens’ data. Article 22 governs decisions based solely on automated processing producing legal effects. In practice it is the provision that pushes designs towards assisting caseworkers rather than replacing them.
The référentiel général de sécurité governs information system security for public authorities, and ANSSI publishes the reference frameworks and qualifies providers and offerings. For an AI project this translates into concrete, checkable requirements: environment segregation, secrets management, logging, and a security accreditation of the service before it goes live. This work is planned at the start. It cannot be retrofitted.
The French state cloud doctrine makes cloud the default hosting model and requires, for the most sensitive data, an offering qualified SecNumCloud or an internal state solution. The practical consequence arrives early: it closes off calling a proprietary model through an interface hosted outside that perimeter, before any technical study. It is also why we know how to run open models on your own infrastructure.
The legal accessibility obligation for online public communication services applies to the interfaces you expose, including a conversational assistant or a results screen used by caseworkers. The RGAA provides the audit framework, with a conformity statement and a multi-year plan. The audit covers precise criteria, from keyboard navigation to contrast. An AI interface first tested for accessibility at acceptance is an interface to rebuild.
The French public procurement code governs the purchase, and the form you choose determines your room to manoeuvre. Lots or phased tranches that allow you to stop after an inconclusive prototype protect public money far better than a fixed-price commitment written against specifications drafted before anyone saw the data. The optional tranche is the most useful tool here. We prefer contracts that provide explicitly for stopping, including when stopping means stopping us.
Success criterion
Routing accuracy on a sample reviewed by the services, and above all residual misrouting category by category. A flattering average that systematically fails one sensitive category is not acceptable: the aggregate alone would hide exactly the problem that matters.
Success criterion
Share of correctly sourced answers and share of unsourced claims, evaluated on a question set written by the caseworkers themselves rather than by us. Complemented by search time before and after, timed on the same questions with the same people, at identical corpus scope.
Success criterion
Character and word error rates on a manually transcribed sample, broken down by hand type and period. And, from the user’s side, search recall on real reader queries: that last figure decides whether the project was worth doing, not the raw error rate.
Success criterion
Precision at the top of the queue at constant audit capacity, and the share of audits that conclude compared with current targeting over the same period. With selection rates tracked separately by group, to catch discriminatory drift before it settles in, documented at each model version.
Public sector AI projects seldom fail for technical reasons. Here are the real ones.
Yes, and it is sometimes a requirement before the technical study even starts. The French State’s cloud doctrine requires, for the most sensitive data, a SecNumCloud-qualified offering (the French sovereignty qualification for cloud hosting) or an in-house State solution. That closes the option of a proprietary model called through an interface hosted outside this perimeter. We can run open models on your infrastructure, which is often the shortest path to staying within the rules.
No, and we do not build a system that makes an unfavourable individual decision without real human intervention. Article 22 of the GDPR governs decisions based solely on automated processing: in practice, it means designing for decision support rather than automated decision. Our systems triage, prepare and document, the officer decides. That is a limit, not a negotiating position.
Yes, and accessibility is designed in during development, not at acceptance testing. The obligation to make online public services accessible applies to the interfaces you expose, including a conversational assistant or a screen meant for staff, and the RGAA (the French accessibility standard) provides the assessment reference. An AI interface tested for accessibility after acceptance is an interface to redo: we test it while we build it.
Yes, that is what reversibility means, and it is not a boilerplate clause. We hand over the source code, the model weights, the training sets, the operating procedures and the documentation, kept current, not access to a platform. A public body must be able to take the service back or have a third party take it over. We do not charge a licence fee, and we train your staff and technical teams with the explicit goal that you no longer need us.
An hour is enough to tell whether your subject stands up. If it does not, we will tell you then, not after three months of project.
