Le dossier des marchés publics est le système de gouvernance

Par Heather Grizzle, Novara Consulting Group

Résumé exécutif

La gouvernance de l'intelligence artificielle s'exprime de plus en plus à travers des politiques, des comités, des principes, des inventaires et des classifications de risque. Ces structures comptent. Mais lorsqu'une institution publique acquiert et déploie effectivement un système d'IA, la gouvernance doit finir par devenir quelque chose de beaucoup moins abstrait. Elle doit devenir un dossier.

Quelqu'un doit décrire ce que le système est autorisé à faire. Quelqu'un doit décider quelles preuves suffisent à étayer les affirmations du fournisseur. Quelqu'un doit identifier les personnes susceptibles d'être lésées en cas de défaillance du système. Quelqu'un doit déterminer quelles défaillances nécessitent une intervention humaine, quels changements exigent une réévaluation, et quelles conditions imposent la suspension du système. Si ces décisions ne sont pas documentées avant le déploiement, une politique de gouvernance de l'IA ne remédie pas à cette omission. Le dossier des marchés publics est l'endroit où les principes institutionnels deviennent des engagements opérationnels.

La gouvernance doit finir par atteindre la transaction

Un dispositif de repli n'est une garantie que si la personne qui en a besoin peut réellement l'utiliser.

Heather Grizzle

Les organisations mettent en place des structures de gouvernance de l'IA de plus en plus sophistiquées. Elles établissent des principes d'IA responsable, créent des comités d'examen, tiennent des inventaires et classent les systèmes selon leur niveau de risque. Elles adoptent des politiques exigeant l'équité, la transparence, la reddition de comptes, la protection de la vie privée, l'accessibilité et la supervision humaine. Puis les marchés publics commencent. Un fournisseur répond à un appel d'offres. Des démonstrations de produits sont programmées. La documentation sur l'accessibilité est recueillie. Les questionnaires de sécurité sont complétés. Les conditions juridiques sont négociées. Les responsables métier décrivent les gains d'efficacité attendus. La technologie franchit les filtres établis par l'institution et entre en service.

L'existence de ces filtres peut créer une confiance institutionnelle considérable, mais la confiance n'équivaut pas à une décision défendable. La question essentielle de gouvernance n'est pas simplement de savoir si le système a franchi le processus requis. Elle est de savoir si le dossier qui en résulte contient les preuves nécessaires pour justifier le déploiement spécifique qui a été approuvé.

Cette distinction devient particulièrement importante lorsque l'IA sert d'intermédiaire pour l'accès des personnes handicapées. Un système peut résumer des informations, communiquer avec des patients, évaluer des candidats, traduire des langues, générer du matériel pédagogique, hiérarchiser des dossiers, assister des employés, authentifier des utilisateurs, répondre à des questions ou, de plus en plus, agir au nom d'une institution. Dans chaque cas, l'accessibilité n'est pas simplement une caractéristique de l'interface. Elle fait partie de l'architecture décisionnelle. Une personne handicapée peut rencontrer un système différemment de la population pour laquelle il a été principalement conçu, testé ou validé, et une défaillance d'accessibilité peut modifier l'information que cette personne reçoit, les choix qui s'offrent à elle, sa capacité à réagir, ou l'interprétation que l'institution fait de son comportement. Le dossier des marchés publics doit donc établir plus que le simple fait que l'accessibilité a été prise en compte. Il doit établir ce qui a été examiné, ce qui a été testé, ce qui reste inconnu, et ce que l'institution a décidé de faire face à cette incertitude.

Le dossier des marchés publics comme instrument de reddition de comptes

Les dossiers des marchés publics sont souvent perçus avant tout comme des registres administratifs. Pour l'IA, ils devraient de plus en plus être compris comme des instruments de gouvernance. Un dossier mature de marché public en matière d'IA devrait permettre à un examinateur indépendant de reconstituer le raisonnement de l'institution sans devoir s'appuyer sur la mémoire institutionnelle des personnes ayant participé à l'achat. Cela signifie que le dossier doit répondre à plusieurs questions :

1. À quoi exactement le système a-t-il été acheté pour servir ?
2. Que lui était-il explicitement interdit de faire ?
3. Quelles populations étaient censées le rencontrer ?
4. Quelles preuves étayaient les affirmations sur lesquelles s'est appuyée l'approbation, et qui a produit ces preuves ?
5. Quelles limites étaient connues, et lesquelles restaient inconnues ?
6. Que se passait-il lorsque le système était incertain ou se trompait ?
7. Qui conservait l'autorité de le contourner ?
8. Comment une personne concernée pouvait-elle contester son résultat ?
9. Qu'est-ce qui amènerait l'institution à reconsidérer le déploiement ?
10. Qui avait l'autorité de l'arrêter ?

Ce ne sont pas des questions propres à l'enquête sur incident après une défaillance. Ce sont des questions de marchés publics.

1. Usage prévu et usage interdit

La première exigence est trompeusement simple : définir ce que l'institution achète. Les systèmes d'IA sont fréquemment achetés à travers des descriptions de capacités générales. Un système peut être décrit comme un assistant, un traducteur, un outil d'accessibilité, un système d'aide à la décision, un agent conversationnel, un agent, un outil de présélection ou une plateforme de productivité. Ces étiquettes constituent des spécifications de gouvernance inadéquates. Le dossier des marchés publics doit identifier la fonction institutionnelle réelle.

Un outil de communication utilisé pour aider quelqu'un à naviguer sur un site web présente un risque différent de la même technologie utilisée lors d'une admission médicale. Un système de transcription automatisée utilisé pour produire des comptes rendus de réunion présente un risque différent de celui utilisé pour créer le procès-verbal officiel d'une procédure disciplinaire. Un système de reconnaissance de la langue des signes utilisé expérimentalement par un individu n'équivaut pas à celui qu'une institution présente comme un substitut à un autre moyen d'accès à la communication. La même technologie peut donc passer d'une catégorie de risque à une autre sans aucun changement de son modèle sous-jacent, parce que le contexte de déploiement a changé.

2. Analyse des populations concernées

Les marchés publics technologiques traditionnels demandent qui utilisera le système. La gouvernance de l'IA doit également demander qui sera affecté par lui, et ces populations ne sont pas nécessairement les mêmes. Un employé peut exploiter un système d'IA tandis qu'un patient, un élève, un candidat, un résident, un client ou un bénéficiaire de prestations en subit les conséquences. Les personnes handicapées peuvent être particulièrement difficiles à identifier par une analyse conventionnelle des utilisateurs, car le handicap modifie souvent le parcours à travers un système plutôt que la catégorie nominale d'utilisateur.

Le dossier des marchés publics devrait donc identifier les interactions d'accessibilité prévisibles. Le système traite-t-il la parole ? Génère-t-il ou interprète-t-il du langage ? Dépend-il de la vision, de l'ouïe, de la dextérité, de la cognition, du minutage, de caractéristiques biométriques ou d'un mode de communication particulier ? Déduit-il l'intention ou la compétence à partir d'un comportement que le handicap peut affecter ? Un résultat inaccessible modifie-t-il la capacité d'une personne à participer à une décision ultérieure ? Ces questions transforment l'accessibilité, d'un artefact de conformité, en une enquête sur le risque systémique.

3. Le registre des affirmations du fournisseur

Chaque affirmation significative du fournisseur sur laquelle on s'est appuyé lors des marchés publics devrait avoir un statut probatoire. Toutes les affirmations n'exigent pas des tests indépendants, mais les institutions devraient distinguer au moins trois catégories. Une capacité est revendiquée lorsque le fournisseur affirme qu'elle existe. Elle est démontrée lorsque des preuves montrent qu'elle a été observée dans des conditions précisées. Elle est établie pour le déploiement lorsque des preuves étayent raisonnablement le fait de s'y fier dans le contexte visé par l'institution. Ces catégories ne sont pas interchangeables.

Une démonstration peut établir qu'un système est capable de produire un résultat. Elle n'établit pas nécessairement avec quelle fiabilité il produit ce résultat selon les populations, les environnements ou les cas d'usage significatifs. De même, la documentation peut établir ce que le fournisseur représente au sujet de son système. Elle ne peut pas établir de manière indépendante que cette représentation est exacte. Le dossier des marchés publics doit préserver cette distinction. Sans quoi, les affirmations deviennent progressivement des constatations simplement parce qu'elles ont été répétées dans suffisamment de documents.

Établie pour le déploiement

Un statut d'affirmation du fournisseur signifiant que des preuves étayent raisonnablement le fait de s'appuyer sur la capacité dans le contexte réel et prévu de l'institution, et non simplement que la capacité a été observée dans des conditions de démonstration.

4. Assurance indépendante

Vendor evidence has a legitimate role in procurement. Vendors know their systems better than purchasers do and should be expected to disclose testing, architecture, limitations, known failure conditions, and relevant performance evidence. But the commercial relationship matters. The party seeking the contract should not be the only party determining whether the evidence is sufficient to award it.

Independent assurance does not mean recreating the vendor’s engineering program. It means testing the claims that matter to the purchasing decision under conditions capable of disproving them. For accessibility-related AI, this may require evaluation involving people with the relevant disability and, where linguistic access is involved, qualified members of the language community. The objective is not ceremonial participation. It is evidentiary authority. The people capable of identifying a consequential failure must have a mechanism for causing that failure to affect the procurement decision. Otherwise, participation exists without governance.

5. Failure and Fallback Architecture

Every AI procurement should contain a written answer to a single question: what happens when the system does not work? “Human in the loop” is not an adequate answer. The record should identify the human, the trigger, the authority, the response time, and the alternative pathway available to the affected person.

For disabled users, the fallback itself must also be accessible. An AI communication system that fails and directs a Deaf person to make a telephone call has not produced a fallback. An automated digital process that becomes inaccessible and requires a blind user to complete the same inaccessible interface has not transferred the person to human oversight in any meaningful sense.

Un dispositif de repli n'est une garantie que si la personne qui en a besoin peut réellement l'utiliser.

Heather Grizzle

6. Performance Boundaries and Known Unknowns

Procurement documents tend to record what products can do. Governance records also need to state where confidence ends. AI performance is conditional. It may vary according to language, dialect, accent, signing style, lighting, camera position, disability, device, environment, domain terminology, interaction length, demographic characteristics, or countless other variables. Institutions should require vendors to disclose known performance boundaries and should separately document areas that have not been evaluated.

That distinction matters. Not evaluated is not the same finding as failed, but it is also not the same finding as safe. Uncertainty is not a procurement defect if it is recognized and governed. Undocumented uncertainty is.

7. Logging, Traceability, and Reconstruction

When an AI-mediated interaction produces harm, the institution should be able to reconstruct what happened, and that requires decisions about logging before deployment. What system version was operating? What inputs were received? What output was generated? Was the output modified? Did a human review it? What information did that reviewer see? What action followed? Can the institution reproduce the event without retaining data that should never have been retained in the first place?

Traceability and privacy can create legitimate competing requirements. That conflict should be resolved through system design and governance rather than discovered during litigation, an accessibility complaint, or an internal investigation. The procurement file should document the resolution.

8. Complaint, Contestability, and Redress

A person affected by AI needs more than a mechanism for reporting a technical problem. They may need to contest what the institution did because of the system, and that is a different function. If an AI system mistranslates communication, incorrectly characterizes behavior, produces inaccessible information, generates a false inference, or contributes to an adverse institutional action, the affected person needs a pathway to challenge the resulting decision.

The institution should know before deployment who receives the challenge, who investigates it, what evidence is preserved, whether the contested AI output remains operative during review, what remedies are available, and how quickly the institution must respond.

9. Model Change and Revalidation

AI procurement creates a problem that traditional software contracts were not designed to handle particularly well: the product that was evaluated may not remain the product that is deployed. Models are updated. Guardrails change. Training data changes. Interfaces change. Third-party dependencies change. Vendors replace underlying models. Performance can improve in one domain and degrade in another without the purchasing institution initiating any change itself.

The procurement file therefore needs a change-control rule. The relevant question is not whether the vendor is permitted to update its product. It is which changes invalidate the evidence on which the institution relied. Contracts should identify material changes requiring notice, reevaluation, renewed acceptance testing, or approval before continued use in specified contexts. Otherwise, an institution can perform rigorous assurance at acquisition and still find itself governing a materially different system six months later using evidence produced for the previous one.

10. Suspension and Exit Authority

Governance without stop authority is advisory. Someone within the institution must have the authority to restrict, suspend, or terminate an AI deployment when evidence no longer supports its use, and the triggering conditions should not have to be invented during a crisis.

The procurement record should identify both the triggers and the decision authority.

It should also address exit. Who owns or receives institutional data when the relationship ends? What records must be retained? What must be deleted? How does the institution restore the previous service pathway? What happens to people who have become dependent on the AI-mediated process? Exit planning is not merely vendor management. It is continuity-of-access planning.

From AI Policy to Institutional Evidence

The emerging challenge for AI governance is not a shortage of principles. It is translation. Fairness has to become an evaluation criterion. Transparency has to become a disclosure requirement. Human oversight has to become an assigned authority. Accessibility has to become a deployment condition. Accountability has to become a named office and a documented remedy. Monitoring has to become a trigger for action. And responsible AI eventually has to become something a procurement officer can place in a file.

This is particularly important in public institutions because procurement is where abstract institutional commitments encounter money, contracts, vendors, statutory duties, and people who cannot simply choose another government, school, hospital, court, or public service when the technology does not work for them. The procurement file therefore performs a function much larger than recordkeeping. It establishes the institution’s theory of acceptable risk.

Position politique de NCG

Novara Consulting Group holds that AI systems affecting disabled people should not be approved solely because they have satisfied an organization’s general AI governance process. The procurement record should contain sufficient evidence to reconstruct and defend the specific deployment decision.

The standard is not perfect knowledge. No procurement process can eliminate uncertainty. The standard is governed uncertainty: knowing what has been established, what has not, what evidence justified proceeding anyway, and who bears responsibility for the decision.

Closing Position

After an AI failure, institutions often ask whether the vendor should have warned them. Sometimes the answer will be yes. But public accountability requires another question: what evidence did the institution require before it agreed to proceed? That question cannot be outsourced. The vendor can supply evidence. An assessor can evaluate it. A committee can advise. Disabled stakeholders can identify failures that others cannot see. Lawyers can negotiate the allocation of contractual risk. The institution still makes the decision, and its procurement record should prove that it knew what decision it was making.

An AI system is not governed because an organization has an AI policy. It is governed when the institution can show why this system, for this purpose, affecting these people, under these conditions, was permitted to operate.

Heather Grizzle

The procurement file is where that accountability begins.