Checklist des pratiques d'IA interdites pour fondateurs et responsables conformite

Les pratiques d'IA interdites sont des usages qui doivent etre bloques, reconcus ou escalades avant la production. Pour une equipe SaaS, la bonne question n'est pas seulement de savoir si l'article 5 de l'AI Act s'applique. Il faut surtout savoir si l'entreprise peut detecter tot un usage inacceptable, l'arreter et documenter la decision avant lancement, deploiement fournisseur ou revue client.

Utilisez cette checklist pour les fonctionnalites d'IA, l'IA tierce integree, les outils internes, les clients reglementes et toute modification de l'effet d'une sortie d'IA sur des personnes.

1. Confirmer le cas d'usage

Documentez le systeme, le produit, le flux, le proprietaire, le fournisseur, le modele ou service, la finalite, les utilisateurs, les personnes affectees, les categories de donnees, la geographie et l'influence eventuelle sur une decision.

Demandez si l'entreprise construit, achete, integre, configure ou utilise le systeme; s'il est interne ou client; s'il influence, evalue ou classe des personnes; s'il traite des donnees biometriques; et s'il peut toucher des utilisateurs, salaries, candidats, apprenants ou clients dans l'UE.

Si le cas est clairement hors perimetre, gardez la justification. Sinon, poursuivez l'ecran des pratiques interdites.

2. Examiner manipulation et tromperie

L'article 5 vise certains systemes utilisant des techniques subliminales, manipulatrices ou trompeuses qui distordent substantiellement le comportement, nuisent a la decision informee et causent ou risquent de causer un prejudice significatif.

En pratique, relisez le parcours utilisateur, la personnalisation, les recommandations et les nudges. Le systeme cache-t-il une information importante? Adapte-t-il une pression a une personne? Pousse-t-il vers une decision dommageable? L'usage de l'IA est-il intelligible pour les personnes concernees?

Conservez captures, logique de personnalisation, groupes affectes, analyse du prejudice et decision de mitigation. En cas d'influence cachee ou trompeuse, le lancement doit attendre la revue.

3. Ecarter l'exploitation de vulnerabilites

L'AI Act vise aussi l'exploitation de vulnerabilites liees a l'age, au handicap ou a une situation sociale ou economique specifique lorsque le comportement est substantiellement distordu et qu'un prejudice significatif est probable.

Verifiez si la fonction cible, profile ou exerce une pression sur des personnes vulnerables: enfants, patients, etudiants, travailleurs, consommateurs en difficulte, personnes handicapees ou utilisateurs de services essentiels. Une revue dediee est necessaire si le systeme personnalise persuasion, priorisation, eligibilite, prix, support ou enforcement.

4. Exclure social scoring et traitement disproportionne

Le risque de social scoring apparait lorsqu'un systeme evalue des personnes dans le temps a partir d'un comportement social ou de caracteristiques personnelles et produit un traitement defavorable dans un contexte sans lien ou disproportionne.

Le motif peut exister dans la fraude, la confiance, la securite, les RH, l'education, les communautes ou les marketplaces. Notez l'usage du score, les personnes affectees, le lien avec le contexte initial des donnees et la proportionnalite du resultat.

5. Escalader biometrie, emotions et risque penal

Escaladez si le systeme evalue le risque d'infraction uniquement par profilage ou traits de personnalite, cree des bases de reconnaissance faciale par scraping non cible, infere des emotions au travail ou dans l'education hors raisons medicales ou de securite, utilise la biometrie pour inferer des traits sensibles, ou soutient l'identification biometrique a distance en temps reel dans des espaces publics pour la police.

Les fournisseurs peuvent appeler cela engagement, insight, safety ou identity. Analysez la fonction reelle.

6. Nommer proprietaire et reviewer

Le proprietaire met les faits sur la table. Le reviewer decide si l'usage continue, change ou s'arrete. Le dossier doit inclure nom du systeme, finalite, personnes affectees, fournisseur, questions traitees, conclusion, raisonnement, changements requis, approbateur et declencheur de nouvelle revue.

7. Relier aux gates de lancement et fournisseurs

Ajoutez ces questions au product intake, security review, privacy review, onboarding fournisseur, validation des outils internes et documentation IA client. Aucun usage IA ne devrait demarrer sans ecran complete ou confirmation que l'ecran n'est pas requis.

8. Definir les re-revues

Reouvrez la decision si changent finalite, marche, population, fournisseur, donnees, automatisation, configuration client ou nouvelles lignes directrices europeennes.

FAQ

Quel est le but pratique?

Empecher un usage d'IA inacceptable d'entrer dans un produit, un fournisseur, un flux interne ou un engagement client.

Quand est-ce pertinent pour SaaS?

Quand l'equipe construit, achete, integre, vend, configure ou utilise une IA pouvant manipuler, exploiter une vulnerabilite, scorer des personnes, traiter la biometrie, inferer des emotions ou soutenir certains usages biometricques policiers.

Que documenter d'abord?

Un intake, un proprietaire, un reviewer, une conclusion courte et un gate de lancement, relies aux preuves fournisseur, 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 established by Regulation (EU) 2024/1689.