Pratiques d'IA interdites: Guide pratique pour les equipes SaaS

Les pratiques d'IA interdites sont des usages d'IA qu'une equipe SaaS doit bloquer avant qu'ils atteignent un client, un employe, un vendor workflow ou un processus interne. L'Article 5 de l'EU AI Act vise un nombre limite de pratiques jugees inacceptables: manipulation nuisible, exploitation de vulnerabilites, certaines formes de social scoring, certains usages de prediction penale, scraping non cible d'images faciales, reconnaissance des emotions au travail et dans l'education, categorisation biometrique sensible et identification biometrique a distance en temps reel dans les espaces publics a des fins repressives, sauf exceptions etroites.

La reponse operationnelle est claire: ne pas attendre qu'un juriste examine une fonctionnalite terminee. Mettez en place un filtre pre-lancement qui demande si le cas d'usage peut relever d'une categorie interdite, bloque les cas evidents, escalade les cas incertains et conserve la preuve de la decision.

Pourquoi ce controle compte

Le screening des pratiques interdites est la porte d'entree de l'AI governance. Si un usage est interdit, l'equipe ne doit pas construire des controls ordinaires autour de lui. Elle doit arreter, redesign, limiter ou escalader avant que l'usage soit integre a la roadmap ou a un engagement client.

Dans le SaaS, l'IA arrive souvent par petites touches: nudges produit, scoring de comptes, analytics RH, outils vendors ou fonctions biometriques dans une plateforme deja utilisee. Ces changements semblent parfois mineurs, mais ils peuvent modifier la position reglementaire et ethique du service.

Ce qu'il faut verifier

Transformez l'Article 5 en questions pratiques. Le systeme utilise-t-il des techniques cachees, manipulatrices ou trompeuses qui peuvent alterer une decision et causer un prejudice significatif? Exploite-t-il des vulnerabilites liees a l'age, au handicap ou a une situation sociale ou economique? Evalue-t-il des personnes entre contextes? Fait-il du social scoring, une prediction penale fondee uniquement sur du profiling, une base de reconnaissance faciale par scraping, de la reconnaissance d'emotions dans le travail ou l'education, une inference biometrique sensible ou une identification biometrique a distance?

Le nom du modele ne suffit pas. Il faut examiner l'usage, le contexte, les donnees, les personnes affectees et l'effet de l'output.

Workflow pratique

Ajoutez des questions IA au product review, vendor review, security review, privacy review et a l'approbation des outils internes. Demandez ce que fait le systeme, qui est affecte, quelles donnees sont utilisees, si le systeme influence une decision, s'il traite de la biometrie, s'il infere des emotions et si le cas touche emploi, education, credit, services essentiels, law enforcement ou securite publique.

Les non clairs peuvent aller vers la classification IA et le risk review ordinaires. Les oui clairs doivent stopper jusqu'a ce que legal et compliance approuvent un redesign ou confirment que le cas est hors interdiction. Les cas incertains doivent aller a un reviewer nomme.

La decision doit capturer systeme, owner, vendor, finalite, personnes affectees, donnees, geographie, role AI Act, questions Article 5, conclusion, justification, changements requis, approbateur et declencheur de re-review.

Preuves a conserver

Conservez l'intake, la description produit ou vendor, la note de data flow, l'analyse des personnes affectees, les screenshots ou configurations, la decision, la justification, le reviewer, la date et les actions de redesign. Avec un vendor, gardez la documentation IA, les engagements contractuels et les reponses sur biometrie, emotion recognition, profiling, entrainement des modeles et manipulation des utilisateurs.

La preuve doit aussi indiquer quand la decision sera reouverte: nouveau but, nouveau groupe d'utilisateurs, nouveau marche, nouvelles donnees, changement de revue humaine, configuration client ou nouvelle guidance.

Erreurs communes

La premiere erreur est de verifier trop tard. Quand la fonctionnalite est presque prete, le design, le contrat, le messaging et l'engineering reposent deja sur une hypothese. La deuxieme est de verifier seulement les features customer-facing. Les outils internes peuvent aussi creer du risque lorsqu'ils affectent travailleurs, candidats, formation, productivite, fraude, support ou securite.

Ne vous fiez pas non plus aux labels vendors comme insight, sentiment, safety ou personalization. La question est ce que fait le systeme en realite. Human in the loop peut aider, mais ne corrige pas automatiquement une manipulation interdite ou une inference biometrique sensible.

FAQ

Quel est l'objectif pratique?

Identifier les usages d'IA a bloquer, redesign ou escalader avant qu'ils entrent dans un produit, vendor workflow ou processus interne.

Quand cela s'applique-t-il au SaaS?

Lorsqu'une equipe construit, achete, integre, vend, configure ou utilise de l'IA pouvant toucher une categorie de l'Article 5.

Que documenter d'abord?

Un intake, un decision record, un reviewer nomme et un launch gate relie au produit, vendor, privacy, security et customer trust.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidelines on prohibited artificial intelligence practices.
• European Commission studies on Article 5 of the AI Act.