L’AI Act pour ceux qui construisent vraiment des produits d’IA

La première question est celle du rôle que vous occupez. Les obligations d'un fournisseur, qui développe un système et le met sur le marché sous son propre nom, ne sont pas celles d'un déployeur, qui l'utilise sous sa propre autorité. Intégrer le modèle d'un tiers dans votre produit et le proposer à des clients peut faire de vous le fournisseur du système résultant, même si vous n'avez rien entraîné.

La seconde question est celle de ce que le système fait, pas de ce avec quoi il est construit. La classification suit la finalité et le contexte d'usage. Le même modèle de langage peut se trouver dans un système à risque minimal pour un produit et à haut risque pour un autre, parce que le règlement regarde la fonction remplie, pas l'architecture.

Les équipes qui répondent tard à ces deux questions reconstruisent. Celles qui y répondent en conception découvrent en général que la classification est gérable et que le travail est borné.

Les modèles à usage général portent leur propre couche d'obligations, principalement de documentation et d'information à transmettre en aval, avec des exigences supplémentaires quand un modèle est considéré comme présentant un risque systémique. Si vous construisez sur le modèle d'un tiers, la question pratique est de savoir s'il vous donnera de quoi documenter votre propre système.

Lu comme un backlog d'ingénierie plutôt que comme un texte juridique, le régime haut risque demande un petit nombre de choses qui doivent exister et rester à jour.

Deux de ces points relèvent de la pure ingénierie et sont généralement sous-estimés. La journalisation doit être conçue, parce que « nous avons des logs applicatifs » n'équivaut pas à savoir reconstituer pourquoi une décision précise est sortie ainsi pour une personne précise un jour précis. Et la supervision humaine doit être effective, ce qui suppose que l'humain ait assez de contexte et assez d'autorité pour changer réellement le résultat. Un bouton de confirmation sur un écran qui n'affiche qu'un score est une supervision de nom seulement.

• Un processus de gestion des risques qui court sur tout le cycle de vie, pas un document écrit une fois
• Une gouvernance des données couvrant la provenance, la pertinence et les limites connues des jeux d'entraînement, de validation et de test
• Une documentation technique assez complète pour qu'un évaluateur comprenne comment le système fonctionne
• Une journalisation automatique des événements sur la durée de vie du système, suffisante pour retracer le comportement après coup
• Une notice d'utilisation qui permette au déployeur de l'exploiter correctement
• Une supervision humaine conçue dans le système plutôt que promise dans une politique
• Un niveau annoncé d'exactitude et de robustesse, avec les métriques qui l'étayent
• Un système de management de la qualité, et une évaluation de conformité avant mise sur le marché

Une supervision effective a trois propriétés. Le relecteur voit les entrées qui ont produit la sortie, pas seulement la sortie. Le relecteur peut passer outre, et ce passage outre est enregistré avec son motif. Et le taux de passages outre est suivi, parce qu'une étape de supervision à zéro pour cent de passages outre pendant des mois est soit un modèle parfait, soit un tampon, et c'est rarement le premier.

Construire le chemin de passage outre en premier, avant l'automatisation, produit en général de meilleurs systèmes. Cela force à se demander de quoi l'humain aurait besoin pour décider, ce qui est généralement le contexte que le modèle aurait dû avoir.

Le règlement est entré en vigueur en 2024 et s'applique par étapes, les interdictions d'abord, les obligations des modèles à usage général ensuite, le régime haut risque plus tard. L'échelonnement compte pour l'exposition juridique et presque pas pour la planification d'ingénierie, parce que les artefacts ci-dessus prennent plus de temps à construire que l'écart entre deux étapes.

Le conseil pratique manque de panache. Classez maintenant, par écrit, avec le raisonnement. Intégrez journalisation et supervision dès la première version. Gardez la documentation dans le dépôt à côté du code, pour qu'elle soit mise à jour par le même changement que le comportement.

Débarrassé de sa structure juridique, le règlement demande quelque chose que les ingénieurs reconnaissent déjà : savoir à quoi sert votre système, savoir de quelles données il a appris, savoir expliquer une sortie précise après coup, et faire en sorte qu'une personne puisse intervenir.

Les systèmes construits ainsi sont plus faciles à déboguer, plus faciles à vendre à des clients régulés, et plus faciles à défendre. L'argument de conformité est la plus faible des raisons de les construire.