Erreurs courantes sur les systemes d'IA a haut risque que les equipes SaaS font encore

L'erreur la plus frequente consiste a traiter la classification comme une reponse juridique ponctuelle. L'equipe demande si une fonctionnalite est a haut risque au sens de l'EU AI Act, obtient un premier avis, puis laisse la conclusion dans un document que product, engineering, security, sales et customer success utilisent peu.

C'est fragile. L'analyse depend de la finalite, du contexte de deploiement, de la configuration client, des personnes affectees, de la repartition des roles et de l'utilisation de l'output. Ces faits changent quand le produit entre sur un nouveau marche, ajoute un workflow, signe un autre type de client, integre un modele vendor ou reduit la revue humaine.

Erreur 1: partir du modele au lieu du use case

Demander "ce modele est-il a haut risque?" est rarement suffisant. La meme famille de modeles peut servir un assistant interne, un resume support, un workflow d'evaluation des travailleurs ou un ranking de candidats. La finalite et le contexte priment.

Commencez par le use case: que fait le systeme, qui est affecte, l'output classe-t-il, note-t-il, filtre-t-il, recommande-t-il, surveille-t-il ou influence-t-il des decisions concernant des personnes? Touche-t-il employment, education, essential services, biometrics, healthcare, credit, insurance, justice ou un domaine sensible?

Erreur 2: ignorer la configuration client

Les produits SaaS sont configurables. Une fonctionnalite peut etre peu risquee par defaut et sensible dans le deploiement reel d'un client. Un outil d'automatisation general peut devenir pertinent pour employment si le client l'utilise pour classer des candidats.

Ajoutez la configuration a l'intake: usages prevus, usages interdits, settings sensibles, prompts controles par le client, actions downstream, groupes affectes et triggers d'escalade. Quand une configuration risquee peut etre bloquee dans le produit, le controle technique est souvent plus fort qu'une phrase de policy.

Erreur 3: prendre la documentation vendor pour toute la reponse

La documentation vendor compte, mais elle n'est qu'une preuve. Le vendor ne connait pas toujours vos segments clients, engagements contractuels, geographie, utilisateurs affectes, human review ou decisions downstream.

Conservez model cards, description systeme, instructions for use, reponses security, termes data et declarations contractuelles. Ajoutez ensuite votre propre analyse: utilisation, personnes qui dependent de l'output, configuration possible, role AI Act attendu et triggers de re-review.

Erreur 4: ne pas clarifier les roles

Le travail devient confus si personne ne decide qui est provider, deployer, importer, distributor, product manufacturer ou autre partie. Une entreprise SaaS peut mettre un systeme sur le marche, integrer un composant AI, modifier substantiellement un systeme ou utiliser un vendor en interne.

La repartition des roles doit etre un champ explicite du record. Si c'est incertain, nommez l'incertitude et assignez un owner legal ou compliance.

Erreur 5: croire que la revue humaine suffit

Human oversight est important, mais ne retire pas automatiquement la question high-risk. Le systeme peut rester sensible meme si une personne examine l'output.

Documentez qui revoit, ce qu'il voit, s'il peut override, comment les overrides sont logs, quelle formation existe et que faire si le systeme se comporte mal. Ces details comptent plus que "human in the loop".

Erreur 6: separer classification et release gates

Une spreadsheet exacte ne suffit pas si une fonctionnalite sensible part en production sans preuves, instructions client, logs, tests ou monitoring. La classification doit alimenter les gates de release.

Reliez-la a product intake, architecture review, privacy review, vendor onboarding, security review, release approval et documentation client. Une classification manquante doit bloquer les AI features dans les domaines sensibles jusqu'a decision.

Erreur 7: sous-estimer la qualite des preuves

Une conclusion sans preuve est faible. Les preuves utiles incluent inventory AI, intended purpose, analyse des personnes affectees, data flow, role analysis, screening Annex I ou Annex III, evidence vendor, human oversight design, logging, tests, monitoring, reviewer, date, rationale et triggers.

Stockez les preuves la ou le travail se fait: tickets product, architecture records, privacy assessments, vendor records, release checklists et trust-center materials.

Erreur 8: oublier le changement apres lancement

La classification peut vieillir. Elle doit etre rouverte si la finalite, les personnes affectees, les donnees, la geographie, l'automatisation, la revue humaine, le vendor, les usages clients ou la guidance changent.

Que faire ensuite

Passez en revue tous les systemes AI deja utilises: features client, outils internes, vendors, pilots et workflows configurables. Pour chacun, notez owner, finalite, personnes affectees, categories de donnees, usage de l'output, configuration client, vendor, hypothese de role et lien eventuel avec produits reglementes ou Annex III.

Ensuite, decidez quelles preuves manquent et quel gate doit s'appliquer avant le prochain lancement ou engagement client.

FAQ

Que doivent comprendre les equipes?

L'analyse high-risk est un workflow, pas une etiquette. Elle relie finalite, roles, configuration, preuves, controles et decisions de lancement.

Pourquoi est-ce important?

La classification peut declencher des obligations plus fortes et plus de scrutiny client. Decider tot evite les surprises tardives.

Quelle est la plus grande erreur?

Traiter la classification comme un memo juridique unique au lieu d'un controle repetable avec intake, reviewer, decision record, release gate et re-review triggers.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidance for providers and deployers of high-risk AI systems.
• European Commission AI Act FAQ.
• AI Act Service Desk guidance on Annex III high-risk AI systems.