Dans cet article nous allons voir comment adapter notre workflow Data Science pour être conforme à l’AI Act.

Nous suivrons chaque étape du cycle de développement d’un système d’IA, de la phase de cadrage initial jusqu’à l’industrialisation et au monitoring, en passant par la phase de preprocessing des données et d’entraînement des modèles.

Pour cela, nous nous mettrons dans la peau d’un provider travaillant sur un système d’IA classé à haut risque. En effet, en tant que Data Scientists, nous endossons souvent ce rôle dès lors que nous concevons, entraînons ou déployons des systèmes d’IA destinés à un usage interne ou à une commercialisation (voir Partie III de l’article précédent).

Il est important de garder à l’esprit que les obligations réglementaires et donc les méthodes de travail et les best practices qui en découlent varient selon la catégorie de risque du système. Si le système que vous développez est à risque faible ou modéré, le niveau d’exigence sera différent.

Enfin, pour garder une lecture claire, nous nous concentrerons ici sur le cas général. Pour autant, il existe de nombreuses situations particulières, par exemple l’utilisation d’un modèle pré-entraîné que l’on fine-tune. Dans un tel cas, il faudra à la fois vérifier la conformité du modèle initial pré-entraîné, puis appliquer toutes les exigences du provider sur le nouveau modèle fine-tuné.

I. Cadrage du projet

Comme pour tout projet d’IA, la première étape est celle du cadrage. Il s’agit de bien définir les besoins et contraintes métiers, les contraintes techniques, budgétaires, de cybersécurité, ainsi que les modalités d’usage du système par les utilisateurs finaux. Avec l’entrée en vigueur de l’AI Act, cette phase prend une dimension supplémentaire : l’évaluation du risque réglementaire et la détermination de notre rôle dans la chaîne de conformité.

1. Identification du niveau de risque du système

L’AI Act classe les systèmes d’IA selon leur niveau de risque. Comme ce niveau dépend du cas d’usage et non de la technologie employée, il peut (et doit) être défini dès la phase de cadrage. De plus, cette identification est cruciale pour connaître les obligations réglementaires à respecter dans la suite du développement du système.

2. Détermination de notre rôle vis-à-vis de l’AI Act

Pour rappel, l’AI Act définit plusieurs rôles réglementaires (provider, deployer, importer, distributeur). Il est fondamental d’identifier le rôle que l’on a, car ce rôle détermine l’ensemble des obligations à respecter. La plupart du temps, un Data Scientist développe un système d’IA et l’entreprise responsable du projet est donc un provider.

Mais certaines situations sont plus nuancées. Prenons le cas d’une ESN qui développe un système d’IA pour le compte d’un client. Le système d’IA étant utilisé ou commercialisé sous la marque du client, c’est ce dernier qui est provider. Le rôle joué par l’ESN peut donc porter à confusion, mais concrètement :

• Tant que le projet est en cours de développement, l’ESN agit comme provider et doit se conformer aux exigences associées.
• Une fois le projet livré, le client devient le provider officiel, responsable des obligations liées à l’industrialisation, à la maintenance ou aux mises à jour et garant des obligations des phases précédentes.

Bien sûr, ce cas est un cas général et il faudra s’assurer de clairement identifier ce transfert de responsabilité, car il a un impact direct sur la manière dont on structure la documentation, les livrables, et les processus de conformité.

3. Mise en place d’un Risk Management System – RMS

L’une des principales obligations des systèmes d’IA à risque élevé est la mise en place d’un système de gestion des risques. En effet, comme nous savons que notre système d’IA représente un fort risque, il faut tout mettre en œuvre pour identifier, évaluer et mitiger ce risque afin qu’il soit maîtrisé. Les risques concernés sont toujours ceux liés à la santé, à la sécurité ou aux droits fondamentaux.

À ce jour, l’AI Act ne fournit pas de framework précis sur la manière dont ce RMS doit être mis en œuvre, mais l’article 9 du texte de loi liste un ensemble de guidelines à suivre. Les différentes instances de gouvernance de la loi viendront préciser ces guidelines officielles avant l’entrée en application complète du texte en août 2027.

Dès la phase de cadrage, nous pouvons réaliser une première itération du RMS en nous concentrant sur les points suivants :

• Identifier les risques liés à l’utilisation normale du système, mais aussi ceux liés à des usages détournés ou incorrects. Par exemple, pour un système dont l’output doit être évalué par un humain avant d’être utilisé, il faut penser à évaluer le risque qui survient si cette supervision humaine n’est plus assurée. Toutes les possibilités doivent être envisagées et il faut donc se poser les questions suivantes : Quelles sont les conditions normales d’utilisation du système et quelles sont les possibles utilisations incorrectes que l’on peut raisonnablement envisager ? Pour chacune d’elles, quels risques peuvent survenir (santé, sécurité et droits fondamentaux des citoyens) ? Pour chaque risque identifié, quelle est la probabilité qu’il survienne et quelle est la gravité de la survenue de ce risque ? Existe-t-il des indicateurs permettant de surveiller ou d’anticiper ces risques ?
• Commencer à réfléchir aux mesures de mitigation : à quel niveau (données, modèle, interface, supervision humaine…) et avec quelles solutions ? Parfois, il faudra attendre la phase de développement pour avoir une meilleure vision de l’aspect technique du système et pour pouvoir y intégrer les meilleurs moyens de mitigation.

Il est essentiel de concevoir le RMS comme un processus vivant et continu, mis à jour à chaque étape du développement et du cycle de vie du système. Nous reviendrons donc sur ce point dans les phases suivantes du workflow Data Science.

II. Ingestion et preprocessing des données

Maintenant que notre projet est bien cadré et que l’on sait où l’on va, nous pouvons passer à l’étape suivante : la sélection, l’ingestion, le prétraitement et l’analyse des données qui serviront à alimenter notre système d’IA. Cette phase est critique car de la qualité des données dépendra directement la performance et la robustesse du modèle entraîné et donc la qualité de notre système d’IA dans son entièreté.

1. Gouvernance des données et rigueur dans la sélection

Avant toute chose, les données doivent naturellement respecter les exigences du RGPD et s’inscrire dans une gouvernance maîtrisée : traçabilité, documentation, accessibilité, droits d’usage.

Dans les grandes structures où plusieurs versions d’un même jeu de données peuvent coexister et où l’on fait face à de très grandes quantités de data, il n’est pas rare de retrouver :

• Des variables similaires représentant des réalités différentes,
• Des granularités hétérogènes,
• Ou des logiques métiers divergentes.

Il est donc essentiel d’opérer un travail de sélection rigoureux avant ingestion, en collaboration étroite avec les experts métier et les responsables des différents périmètres data.

2. Qualité des données : exigences de l’AI Act

L’AI Act porte une attention particulière à la qualité des données utilisées pour l’entraînement des systèmes à haut risque. Plusieurs axes clés doivent être traités à cette étape :

• Biais

Il faudra s’assurer que les biais dans nos data peuvent être monitorés afin de pouvoir les détecter. On veillera à :

• Identifierles biais potentiels dans chaque variable (ex : biais liés au genre, à l’âge, à la localisation…).
• Se demander : s’agit-il d’un biais représentatif de la réalité (ex : disparité naturelle liée au métier) ou d’un biais induit et indésirable (ex : discrimination historique) ?
• Monitorerces biais dans le temps et prévoir des indicateurs pour les suivre.
• Appliquer des stratégies de mitigation adaptées : techniques de rééchantillonnage, de repondération, ou de débiaisement algorithmique. On choisira la méthode la mieux adaptée à notre cas d’usage.

• Représentativité

Il faudra s’assurer que les data utilisées sont bien représentatives de la réalité métier et que les méthodes de mesures et d’échantillonnage n’aient pas biaisé ces données. Pour cela, il faudra donc s’intéresser à la manière dont les données ont été récoltées.

• Complétude

L’absence de données peut fausser l’analyse. On identifiera les champs manquants, et évaluera l’impact de ces absences. On pourra alors choisir la meilleure stratégie de traitement (imputation, exclusion, collecte complémentaire…).

• Précision et erreurs

Il faudra là aussi, autant que possible, disposer d’un dataset sans erreurs. La compréhension du processus de récolte des données nous permettra d’estimer le taux d’erreur du dataset et des mesures possibles pour les détecter et les éliminer.

• Drift

Parfois, la réalité peut évoluer et les distributions des données qui la reflètent vont donc, elles aussi, évoluer au cours du temps. Il est important de suivre ces changements de distribution car le modèle entraîné sur ces données peut ne plus être le meilleur pour identifier les tendances et relations dans les données. On détectera tout drift de data (concept drift ou data drift) et on anticipera le besoin de réentraînement du modèle pour rester aligné avec l’environnement actuel.

• Versioning

Les datasets pouvant être modifiés, il est indispensable d’avoir un système de versionning de données afin de savoir exactement quelles data ont été utilisées pour quelle analyse et d’être en capacité de reproduire les analyses menées.

3. Adapter ses pratiques aux cas d’usage

Il n’existe pas de méthode unique pour garantir la qualité des données : chaque projet, chaque domaine, chaque dataset demande une approche spécifique. On devra donc mettre en place une stratégie sur-mesure, alignée avec les exigences de l’AI Act tout en restant cohérente avec les contraintes métier et techniques.

Et surtout : tout doit être documenté. Chaque choix méthodologique ou technique concernant les données doit être justifié, traçable et mis à disposition pour l’auditabilité et la conformité.

III. Expérimentation et entraînement de modèle

Une fois la qualité des données validée, nous pouvons passer à l’étape centrale du développement : la conception et l’entraînement du modèle, cœur de la majorité des systèmes d’IA.

Les configurations possibles pour un système d’IA sont quasi infinies, de l’enchaînement de modèles aux pipelines conditionnelles mêlant règles métier et modèles de ML, en passant par les systèmes utilisant des LLM fine-tuné ou non, etc.

Pour simplifier l’analyse, nous nous plaçons ici dans un cas général : un modèle unique, entraîné à 100 % sur nos propres données, à l’aide d’une librairie classique (comme scikit-learn, XGBoost, etc.).

Pour les architectures plus complexes, il conviendra d’adapter les principes présentés ici aux spécificités de votre système.

Dans ce cadre, une bonne analyse exploratoire des données permet d’orienter le choix du modèle. Différents modèles peuvent être testés avec une optimisation des hyperparamètres, et le ou les modèles les plus performants sur le dataset de test sont retenus.

Ce modèle sera intégré dans une pipeline complète, avec :

• Un prétraitement des entrées,
• Un post-traitement des sorties,
• Et éventuellement, d’autres logiques métiers.

1. Risk Management System (RMS)

À ce stade, les mesures de mitigation des risques identifiés lors du cadrage doivent être intégrées dans le système. Il est aussi possible que de nouveaux risques émergent au moment de la conception ou de l’entraînement du modèle. On appliquera alors la même procédure d’identification, d’analyse et de mitigation du risque, sans oublier de les documenter.

On devra expérimenter plusieurs méthodes de mitigation et évaluer leur efficacité en conditions réalistes : tests sur jeux de données simulant des cas d’usage typiques ou extrêmes. On pourra alors sélectionner la méthode la plus pertinente en fonction de son impact réel. Cette démarche fait partie intégrante du RMS, qui doit être vivant, évolutif et documenté à chaque itération.

2. Transparence & Supervision Humaine

L’exigence de transparence est l’un des piliers de l’AI Act.

Cela implique que le système doit permettre une bonne interprétation des résultats : l’utilisateur (ou l’auditeur) doit pouvoir comprendre pourquoi une prédiction a été faite. Le système doit aussi permettre unesupervision humaine effective : un humain doit pouvoir surveiller le comportement du système et, si besoin, annuler ou corriger ses décisions.

Le règlement laisse liberté d’implémentation technique sur ces points. À chaque équipe d’adapter les solutions en fonction de son cas d’usage.

Quelques pistes :

• Pour l’explicabilité : on pourra utiliser des librairies comme SHAP, LIME, les visualisations de feature importance, le scoring de confiance…
• Pour la supervision : on pourra mettre en place un workflow de validation humaine, un « bouton d’arrêt », ou des seuils déclenchant des alertes…

Tous ces choix d’implémentation devront être justifiés, tracés et documentés pour garantir la conformité.

3. Cybersécurité

Enfin, l’AI Act rappelle que les best practices en matière de cybersécurité doivent bien évidemment être appliquées à tous les systèmes à haut risque.

IV. Industrialisation du système

Une fois le système conçu et le modèle entraîné, on peut enfin passer à la phase de mise en production de la solution. Peu importe les choix techniques de déploiement (cloud, edge, API, application embarquée, etc.), tout système d’IA à haut risque est soumis à un certain nombre d’obligations préalables avant sa mise en service.

1. Supervision humaine

Il est impératif de s’assurer que la solution de supervision humaine envisagée est compatible avec le mode de déploiement et puisse être maintenue au cours du cycle de vie du système.

Quelques questions à adresser :

• Les référents responsables de la supervision ont-ils été désignés ?
• Existe-t-il un processus clair de désignation ou de remplacement en cas d’absence (vacances, changement de poste, etc.) ?
• Le mécanisme de supervision est-il maintenu tout au long du cycle de vie du système, y compris en phase de scaling ou de réentraînement ?

Tout cela doit être défini et validé en amont du lancement pour garantir une supervision continue et efficace.

2. Notice d’utilisation

Une notice d’utilisation claire et accessible doit être mise à disposition des utilisateurs finaux ou des potentiels deployer.

Elle doit contenir :

• Les instructions d’utilisation du système (ce qu’il fait et ce qu’il ne doit pas faire),
• Une description synthétique de son fonctionnement dans un souci de transparence,
• Les modalités d’interprétation des sorties du système,
• Les risques identifiés ainsi que les mesures de mitigation mises en place.

Cette notice est essentielle pour garantir une utilisation responsable du système d’IA.

3. Documentation technique et réglementaire

Une documentation complète retraçant l’ensemble des analyses, des décisions de conception et des choix techniques doit être élaborée.

Ses deux objectifs :

• Démontrer la conformité au regard de l’AI Act, en prouvant que toutes les mesures raisonnables ont été prises pour prévenir et atténuer les risques identifiés.
• Assurer la maintenabilité du système.

Cette documentation doit être complétée avant le déploiement de la solution et accessible aux différents acteurs concernés.

4. Enregistrement du système

Selon l’article 49 de l’AI Act, tout système à haut risque ainsi que l’entité provider doivent être enregistrés dans une base de données européenne dédiée avant leur mise en service.

Les modalités précises de cette base sont décrites à l’article 71. À ce jour, la plateforme n’est pas encore opérationnelle, mais sa création est prévue par l’AI Office dans les mois précédant l’entrée en vigueur des obligations des systèmes à haut risque.

Il est donc conseillé de préparer l’ensemble des informations nécessaires à cet enregistrement dès maintenant.

5. Marquage CE

Avant toute mise en service ou commercialisation, le système doit également obtenir un marquage CE, preuve de sa conformité réglementaire.

Cela implique :

• La réalisation d’une évaluation de conformité complète,
• La rédaction d’une déclaration de conformité à l’AI Act, à conserver à disposition des autorités nationales,
• L’obtention du marquage CE auprès d’un organisme notifiéempoderado.

Até o momento, o processo oficial de premiação e os órgãos notificados responsáveis pela emissão da marca CE ainda não foram designados. Quando estiverem, podemos consultar a lista de organismos notificados para legislação (2024/1689).

Depois que todas essas obrigações forem cumpridas, o sistema poderá ser colocado em produção e disponibilizado aos usuários finais.

V. Monitoramento pós-implantação

A implantação do sistema não é o fim do trabalho. Pelo contrário, A Lei de IA exige monitoramento rigoroso durante a fase operacional, para garantir que o sistema permaneça compatível, confiável e seguro durante todo o ciclo de vida.

Modelo de drift

É importante detectar mudanças na distribuição dos dados de entrada ou saída ao longo do tempo. Na verdade, isso pode indicar uma mudança no ambiente real ou uma deterioração gradual no desempenho do modelo. Em caso de deriva comprovada, uma reciclagem, uma atualização do modelo ou uma adaptação do projeto podem ser consideradas.

Retenção de registros operacionais

Outro requisito essencial: manutenção de registros operacionais. Esses registros, registrados automaticamente, devem possibilitar a análise do comportamento do sistema, em particular no caso de uma auditoria ou da ocorrência de um risco. Eles desempenham um papel central na rastreabilidade e análise de incidentes.

Sistema de Gestão de Riscos

Nosso RMS agora chega após a implantação do nosso sistema. É sobre ficar atento asurgimento de novos riscos não identificado durante o desenvolvimento inicial. A análise do feedback de campo e dos registros operacionais possibilita a detecção desses novos riscos. Qualquer nova ameaça deve ser analisada, avaliada e documentada, e novas medidas de mitigação devem ser integradas a uma atualização corretiva do sistema.

Monitoramento e relatórios de incidentes

Finalmente, apesar de todos os esforços feitos para eliminar ou minimizar o risco, incidentes ainda podem acontecer. Estamos falando aqui de incidentes relacionados a riscos à saúde, segurança e direitos fundamentais dos cidadãos e não de incidentes puramente técnicos (embora uma interrupção do sistema possa, em alguns casos, representar um incômodo para os usuários). Para cada incidente, será necessário:

• garantir que exista um nexo causal comprovado ou provável entre o evento e o sistema de IA,
• comunicá-lo às autoridades competentes no prazo de 15 dias a contar da sua descoberta,
• realizar uma investigação interna para entender as causas do incidente e implementar as medidas corretivas necessárias.

Mais detalhes sobre esse procedimento são esperados dos órgãos de governança da Lei de IA.

Em resumo, o monitoramento pós-implantação não é uma simples formalidade: é uma abordagem proativa, contínua e documentada, essencial para garantir a confiabilidade, transparência e conformidade dos sistemas de IA de alto risco ao longo do tempo.

VI. Sistema de Gestão da Qualidade (QMS)

Como acabamos de ver, o cumprimento da Lei de IA envolve inúmeras obrigações que podem, à primeira vista, parecer complexas de orquestrar como um todo.

Para garantir que cada requisito regulatório seja devidamente levado em consideração durante todo o ciclo de vida de um sistema de IA, a Lei de IA exige o estabelecimento de um Sistema de Gestão da Qualidade (QMS). O objetivo dessa estrutura metodológica é estruturar as práticas internas centralizando os procedimentos, políticas e instruções necessárias para cumprir os requisitos do regulamento.

Em particular, o QMS deve conter:

• Uma estratégia de conformidade global para todos os sistemas de IA desenvolvidos ou usados pela empresa.
• A integração sistemática de todas as etapas descritas neste artigo, desde a fase de definição do escopo até o monitoramento pós-implantação.
• Um lembrete dos padrões e das melhores práticas a serem respeitados no desenvolvimento.
• Protocolos para testar e validar métodos de redução de risco.
• A inclusão do Sistema de Gestão de Riscos, bem como dos processos associados de monitoramento e revisão de riscos.
• Procedimentos de notificação de incidentes, em colaboração com as autoridades competentes.
• Coordenação com ferramentas de monitoramento e alerta, a fim de monitorar a operação em tempo real.
• Gerenciamento de documentação: manuais do usuário, históricos de decisões técnicas, registros operacionais.
• Um processo para gerenciar atualizações do sistema, garantindo que qualquer alteração acione automaticamente os testes, verificações, medidas de mitigação e ações de monitoramento necessários.
• Gestão e monitorização da comunicação com os vários atores relacionados com o sistema de IA, bem como com as autoridades nacionais competentes e os organismos notificados.
• Uma definição clara de governança em torno de sistemas, especificando as funções, responsabilidades e processos para designar referentes.

Aqui também, o regulamento não define um formato único para esse sistema de qualidade, deixando as empresas com liberdade de implementação proporcional ao seu tamanho e recursos (conforme especificado emSeção 17). Portanto, cabe a cada estrutura definir uma solução adaptada ao seu contexto.

Em conclusão

A Lei de IA está transformando profundamente as práticas de ciência de dados, especialmente para sistemas de alto risco. Mais do que uma restrição, oferece uma oportunidade de reforçar o rigor e a transparência dos modelos.

Adaptar fluxos de trabalho significa profissionalizar a IA, simplificar a colaboração entre equipes e se preparar para um futuro em que a conformidade será uma alavanca de confiança e uma vantagem competitiva.

O caminho não é fácil: será necessário repensar certas etapas do ciclo de vida do modelo, implementar novas ferramentas de governança e, acima de tudo, criar um diálogo fluido entre as equipes técnicas, jurídicas e comerciais. Mas as organizações que fizerem essa transição com sucesso terão uma clara vantagem estratégica: a possibilidade de implantar sistemas de IA responsáveis e compatíveis em um cenário regulatório cada vez mais exigente.

Em um artigo futuro, exploraremos como configurar um sistema de governança de IA em uma organização para garantir a qualidade e a conformidade de nossos sistemas.