Classification des systemes AI: Guide pratique pour les equipes SaaS

La classification des systemes AI est l'etape operationnelle qui determine quelles regles, quels controles, quelles preuves et quel circuit de revue s'appliquent a une fonctionnalite AI, a un workflow interne ou a un outil tiers. Pour une equipe SaaS, le resultat utile n'est pas une note avec une etiquette. C'est une decision documentee que produit, engineering, juridique, securite et compliance peuvent utiliser pour construire, acheter, lancer, surveiller et expliquer le systeme.

Le EU AI Act rend cette classification importante parce que differentes categories de systemes AI peuvent declencher differentes obligations. Pour les systemes a haut risque, des exigences liees au risk management, a la gouvernance des donnees, a la documentation technique, aux logs, a la transparence, a la supervision humaine, a la precision, a la robustesse, a la cybersecurite et au monitoring peuvent s'appliquer.

Pourquoi cela compte

Sans classification, l'equipe ne sait pas quels controles appliquer, qui doit approuver le lancement, quelles preuves conserver ni comment repondre aux clients. En SaaS, le sujet apparait souvent par petites touches: resumes dans le support, copilotes internes, scoring fourni par un vendor ou modeles ajoutes a un workflow existant.

La classification soutient aussi la readiness commerciale. Les clients enterprise demandent ou l'AI est utilisee, quelles donnees elle touche, si les outputs influencent des utilisateurs et quels controles limitent une automatisation inappropriee. Une decision documentee permet de repondre avec des preuves.

Ce qu'il faut classifier

Commencez par un inventaire large: fonctionnalites produit, workflows internes, services vendors, integrations de modeles, automatisations et decision support utilisant AI ou machine learning. Incluez les usages visibles, mais aussi classification, recommandation, priorisation, extraction, scoring, prediction, moderation, personnalisation et synthese.

Pour chaque systeme, notez ce qu'il fait, s'il est interne ou fourni par un vendor, quelles donnees il traite, qui est affecte, si l'output informe, recommande ou decide, si un humain le revoit, ou il est utilise et s'il touche un contexte sensible ou regule.

Workflow pratique

Definissez les declencheurs de revue: nouvelle fonctionnalite AI, changement de finalite, nouvelle source de donnees, nouveau vendor AI, changement de supervision humaine, nouveau marche ou question client montrant que la classification precedente est incomplete.

Collectez ensuite les faits minimums dans un intake court: finalite, donnees, personnes affectees, workflow, revue humaine, vendor ou modele, geographie et owner produit. La premiere classification sert a router le systeme: hors analyse approfondie, aide de productivite ordinaire ou revue plus poussee pour domaine sensible, utilisateurs vulnerables ou possible haut risque.

Documentez le raisonnement. Une etiquette seule est fragile. Une bonne decision explique les faits, les sources, les reviewers et la date de reevaluation. Reliez ensuite la classification aux controles: risk assessment, data governance, vendor review, supervision humaine, logging, tests, notices, documentation client et monitoring.

Quand examiner le haut risque

Toutes les fonctionnalites AI SaaS ne sont pas a haut risque. Mais une equipe ne doit pas ignorer la question parce qu'il s'agit de logiciel. L'Article 6 du AI Act decrit les chemins de classification haut risque, notamment pour certains produits et les domaines de l'Annex III. Une attention particuliere est necessaire pour emploi, gestion des travailleurs, services essentiels, education, credit, law enforcement, migration, justice, processus democratiques, usages biometriques et composants de securite.

La reponse depend du systeme, de la finalite, du contexte et du role de l'organisation. Un outil interne de redaction est different d'un systeme qui classe des candidats ou influence l'acces a un service important.

Preuves a conserver

Conservez l'entree d'inventaire AI, l'intake, la decision, le raisonnement, owner et approver, sources consultees, risk assessment, vendor review, controles declenches et prochaine date de revue. Ces preuves aident les audits, reviews clients et mises a jour futures.

Erreurs frequentes

Classifier trop tard est le premier probleme. Le deuxieme est de traiter l'AI d'un vendor comme un probleme externe. L'equipe SaaS doit comprendre son propre usage, les donnees, l'impact et les controles. Les autres erreurs sont les labels vagues, l'absence de lien avec le change management et un processus separe des revues securite, privacy, vendor risk, lancement, incident response et customer trust.

FAQ

Quel est le but pratique?

Determiner le chemin de gouvernance applicable et creer des preuves pour cette decision.

Quand cela s'applique-t-il?

Quand une equipe SaaS construit, achete, integre, vend ou utilise materiellement un systeme AI dans le produit ou les operations.

Que documenter d'abord?

Finalite, donnees, personnes affectees, impact, revue humaine, vendor, geographie, owner, resultat, raisonnement et controles declenches.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidance on high-risk AI systems.
• NIST Artificial Intelligence Risk Management Framework.