AI Act dans l’industrie : sécuriser les systèmes qui influencent la production.
Dans l’industrie, un même système peut optimiser un flux, aider un opérateur ou devenir un composant de sécurité d’un produit réglementé. La qualification dépend de cette fonction réelle, de la chaîne de valeur et de la manière dont les décisions sont prises.
Pour un système industriel, décrivez la fonction, le produit concerné, la décision influencée et les responsabilités de chaque acteur. Vérifiez ensuite l’annexe I, l’annexe III, les exigences de sécurité, la documentation, la surveillance et la gestion des changements.
Cluster éditorial : AI Act par secteur · Intention : Appliquer l’AI Act aux systèmes industriels et de production
En bref
L’essentiel à retenir
01
Cartographier les systèmes et leurs fonctions réelles
02
Vérifier le lien avec un produit de l’annexe I
03
Relier qualité, sécurité et preuves AI Act
04
Tester les changements et les incidents avant production
01
Décrire le système dans son environnement
Commencez par les fonctions réellement activées : maintenance prédictive, contrôle qualité, détection d’anomalies, optimisation énergétique, planification ou assistance opérateur. Notez les capteurs, les données, les modèles, les interfaces, les seuils et les personnes qui prennent la décision finale. Un système installé dans une ligne ne se qualifie pas indépendamment de son environnement.
Identifiez la version, les dépendances, les fournisseurs et les changements prévus. Les fonctions disponibles mais désactivées doivent être distinguées des fonctions en production. Cette fiche devient la base de la qualification, des tests et de la documentation transmise aux équipes.
L’article 6 prévoit une voie de qualification lorsque le système est un composant de sécurité d’un produit, ou lorsqu’il est lui-même un produit, couvert par la législation d’harmonisation de l’Union mentionnée à l’annexe I et soumis à une évaluation de conformité par un tiers. Cette analyse doit être menée avec les équipes produit, qualité et affaires réglementaires.
Ne confondez pas un logiciel d’aide à la production avec un composant de sécurité sans examiner le produit, la fonction et les conséquences d’une défaillance. Lorsque l’annexe I ne s’applique pas, les catégories de l’annexe III et les autres obligations du règlement restent à examiner selon le contexte.
Relier gestion des risques, qualité et cybersécurité
Les risques AI Act doivent être reliés aux processus déjà utilisés pour la qualité, la sûreté, la sécurité des produits et la cybersécurité. Pour chaque risque, identifiez la mesure, le seuil, le test, le responsable et la preuve attendue. Une procédure générale qui ne précise pas la version du système ou la situation de test laisse un angle mort.
Les données d’entraînement, de validation et de fonctionnement sont décrites avec leur provenance, leurs limites et leurs conditions d’utilisation. Les dérives, erreurs et changements de population doivent être observables. Les résultats de test sont conservés avec la configuration qui les a produits.
La supervision humaine doit être conçue dans l’interface et dans l’organisation du travail. L’opérateur doit savoir quand faire confiance à la sortie, quand demander une vérification et quand interrompre ou limiter l’usage. Les alertes, les seuils et les possibilités de reprise manuelle sont testés sur des scénarios représentatifs.
Les formations ne se limitent pas à une présentation du modèle. Elles montrent les erreurs possibles, les conditions d’arrêt, les escalades et la manière de documenter une décision. Les supports et évaluations deviennent des éléments du dossier de maîtrise de l’IA.
Définissez ce qui constitue une dérive, une défaillance, un incident ou une sortie dangereuse. Les canaux de signalement, les délais, la conservation des journaux et les responsables d’analyse doivent être connus avant la mise en production. Une alerte technique non reliée à une décision métier ne permet pas de piloter le risque.
La surveillance après commercialisation et le suivi en production alimentent la requalification. Un changement de modèle, de fournisseur, de capteur, de seuil ou de finalité peut modifier le risque. Le processus de changement doit donc déclencher une analyse et un nouveau test lorsque cela est nécessaire.
Classez les systèmes selon leur criticité, leur échéance, leur dépendance fournisseur et la maturité des preuves. Commencez par les usages qui peuvent affecter la sécurité, la continuité d’activité ou les personnes. Affectez un propriétaire produit, un responsable qualité et une date de décision.
La direction doit voir les écarts bloquants, les tests terminés, les versions couvertes et les décisions en attente. Une feuille de route distingue les obligations en vigueur, les travaux préparatoires et les hypothèses à confirmer avec les équipes produit ou l’organisme d’évaluation.
Non. Il faut examiner la fonction réelle, le produit, les conséquences d’une défaillance et les conditions de l’article 6. L’annexe I et l’annexe III ouvrent des voies distinctes.
Non. Elle peut fournir des éléments utiles, mais le dossier AI Act doit couvrir les exigences et responsabilités applicables au système et à son rôle dans la chaîne de valeur.
Le propriétaire du système coordonne la requalification avec la qualité, la technique, la sécurité, les métiers et le fournisseur selon la nature du changement.
Avant la mise en production, après un changement significatif et selon la criticité du système pendant son fonctionnement.
