Le décret italien sur l’IA transforme la gouvernance de l’IA en preuve d’audit

Toute organisation exploitant un système d’IA à haut risque en Italie doit désormais partir du principe qu’un inspecteur peut contrôler la façon dont ce système est testé, et ce, sans préavis. Le décret législatif n° 179/2026 confère à l’agence nationale italienne de cybersécurité ce pouvoir, et les questions porteront sur les données, non sur l’architecture du modèle.

Le décret a été publié au Journal officiel le 8 octobre 2026 et est entré en vigueur le 23 octobre 2026. Il s’agit de la deuxième étape de la mise en œuvre par l’Italie de l’AI Act européen, après la loi n° 132 du 23 septembre 2025. Alessandra Tramonte, journaliste à l’IAPP, a résumé le nouveau cadre, incluant la désignation d’AgID comme autorité de notification et de l’ACN comme autorité principale de surveillance du marché et point de contact unique avec les institutions européennes.

Pour un RSSI ou un chief compliance officer, la signification pratique est simple. Les obligations de gouvernance de l’IA, autrefois consignées dans des documents internes, disposent désormais d’autorités nommées dotées de pouvoirs d’enquête. Ces autorités demanderont quelles données un système d’IA a traitées, qui a autorisé cet accès, et si vous pouvez le prouver. Il s’agit d’un problème de gouvernance des données de l’IA avant d’être un problème de modèle, et c’est la raison pour laquelle ce décret concerne toute personne qui échange du contenu sensible avec des systèmes d’IA.

Résumé de l’essentiel

1. L’Italie dispose désormais d’autorités d’application de l’AI Act.

AgID agit comme autorité de notification pour les organismes d’évaluation de la conformité, et l’ACN comme autorité principale de surveillance du marché et point de contact unique avec les institutions européennes.

2. Les inspections peuvent avoir lieu sans préavis.

L’ACN peut inspecter à distance ou sur site les tests en conditions réelles des systèmes d’IA à haut risque, sans obligation d’annoncer la visite à l’avance.

3. Le décret désigne les autorités et les procédures.

Il ne crée pas de nouvelles obligations liées à l’AI Act : les obligations de fond restent celles de l’AI Act et de la loi italienne 132.

4. Plusieurs points restent à préciser.

L’absence de délais pour les actes d’application, la constitution d’un groupe « sandbox » qui n’est pas encore opérationnel, et le calendrier du Digital Omnibus européen signifient que le cadre continuera d’évoluer.

5. La qualité des preuves détermine l’issue des audits.

Les régulateurs contrôlent les données, pas les modèles : les organisations capables de prouver qui a accédé à quelles données, sous quelle autorité et avec quel justificatif, passeront les inspections plus rapidement.

Ce que prévoit le décret législatif n° 179/2026

L’Italie a choisi de mettre en œuvre l’AI Act européen en deux étapes. La première étape fut la loi n° 132 du 23 septembre 2025, publiée au Journal officiel n° 223 le 25 septembre 2025 et entrée en vigueur le 10 octobre 2025. Cette loi a posé les principes nationaux et délégué au gouvernement l’adoption de décrets d’application. La seconde étape est le décret législatif n° 179 du 7 octobre 2026, adopté en vertu de la délégation prévue à l’article 24 de la loi 132.

Le décret compte 54 articles. Selon le texte consolidé sur Normattiva, il est paru dans la Série Générale du Journal officiel sous le numéro 234 le 8 octobre 2026, et est entré en vigueur quinze jours plus tard, le 23 octobre 2026. Un décret distinct sur l’utilisation de l’IA par la police, le décret législatif n° 160/2026, est entré en vigueur le 30 septembre 2026. Le cadre italien de l’IA se construit donc par étapes, et non en une seule loi.

Il est important de bien comprendre la portée de ce décret : il s’agit d’un instrument institutionnel et procédural. Il définit qui supervise, qui notifie, qui inspecte, qui sanctionne et comment les plaintes sont traitées. Il ne réécrit pas les obligations imposées par l’AI Act aux fournisseurs et utilisateurs. Une équipe conformité qui lirait ce décret comme un nouveau règlement pour les systèmes d’IA ferait fausse route. Celle qui le considère comme le moment où l’application nationale devient concrète aura raison.

Cette distinction est essentielle pour la planification. Vos obligations concernant les systèmes à haut risque, la transparence et la supervision humaine restent celles de l’AI Act. Ce qui a changé le 23 octobre, c’est que les autorités italiennes disposent désormais de rôles et de pouvoirs définis pour vérifier si vous les respectez.

Qui détient l’autorité : AgID et ACN

Le décret répartit la supervision entre deux organismes principaux, et comprendre cette répartition permet d’anticiper qui posera quelles questions.

L’Agence pour l’Italie numérique, dite AgID, est l’autorité de notification. Selon l’article 4, elle désigne les organismes d’évaluation de la conformité, c’est-à-dire ceux qui vérifient les systèmes d’IA à haut risque au regard de l’AI Act. L’article 13 confère à AgID un rôle de surveillance sur ces organismes. AgID peut restreindre, suspendre ou retirer une désignation : un organisme d’évaluation qui néglige ses obligations peut donc perdre son statut. Pour les fournisseurs, cela relève le niveau d’exigence des évaluations achetées, car un certificat délivré par un organisme qui perd ensuite sa désignation perd de la valeur.

L’Agence nationale de cybersécurité, ou ACN, est l’autorité de surveillance du marché selon l’article 5, et le point de contact unique avec les institutions européennes selon l’article 6. Cela confère un pouvoir important à un organisme de cybersécurité. Comme l’analyse de NicFab le souligne, ce choix rapproche la supervision de l’IA de l’appareil de cyberrésilience italien, qui collabore déjà avec les opérateurs de services essentiels dans le cadre de la directive NIS 2.

Les superviseurs sectoriels conservent un rôle. L’article 17 implique la Banque d’Italie, la CONSOB et l’IVASS pour les institutions financières, si bien qu’une banque ou un assureur peut s’attendre à ce que son superviseur habituel reste impliqué. Le régulateur de la protection des données, le Garante, se limite au champ de l’article 74(8) de l’AI Act, selon l’article 5(1)(c) du décret. Autrement dit, le Garante conserve un périmètre défini, sans devenir l’autorité générale de l’IA.

Pour une multinationale, cela signifie un point d’entrée unique en Italie pour la plupart des questions relatives à l’AI Act, avec des superviseurs sectoriels en plus pour les secteurs réglementés. Les organisations déjà engagées dans des programmes RGPD reconnaîtront le schéma d’une autorité principale complétée par des régulateurs spécialisés, et devraient cartographier chaque relation avant une inspection, et non pendant.

Inspections sans préavis et points de contrôle

La disposition la plus déterminante pour les opérateurs est l’article 15. Il donne à l’ACN le pouvoir d’effectuer des inspections à distance ou sur site, y compris sans préavis, et étend ce pouvoir aux contrôles des tests en conditions réelles des systèmes d’IA à haut risque. Le décret s’appuie sur l’article 24(2)(m) de la loi 132, qui prévoyait déjà ce pouvoir d’inspection. L’article 15(3) renvoie les modalités détaillées à un décret de la Présidence du Conseil des ministres, adopté sur proposition de l’ACN : les modalités procédurales restent donc à définir.

Concrètement, une inspection sans préavis des tests en conditions réelles signifie que des données réelles, souvent personnelles, circulent dans un système qui n’est pas encore commercialisé. Un inspecteur voudra voir le plan de test, les données utilisées, les mesures de protection appliquées et les preuves de leur efficacité. Il n’y aura pas de semaine de préparation pour réunir ces preuves : les enregistrements existent et sont accessibles, ou ils ne le sont pas.

D’autres articles précisent le déclenchement des procédures. L’article 16 définit les motifs d’ouverture, et l’article 18 prévoit un canal de réclamation, permettant à une personne concernée de déclencher un contrôle sans attendre une initiative de l’ACN. L’article 14 ajoute une obligation d’enregistrement, gérée par l’ACN, pour les systèmes à haut risque utilisés dans les infrastructures critiques (point 2 de l’annexe III de l’AI Act). Les opérateurs d’infrastructures critiques sont donc soumis à la fois à un registre national et à des pouvoirs d’inspection sur les tests de ces systèmes.

Le schéma est cohérent sur l’ensemble de ces articles : le décret donne aux autorités les moyens de poser rapidement des questions, tant que les preuves sont fraîches. Les organisations qui comptent sur la constitution d’éléments d’audit a posteriori risquent de se heurter à un modèle difficile à appliquer.

Sanctions et financement de l’application

L’article 23 fixe les plafonds des sanctions. Il reprend les montants maximaux de l’article 99 de l’AI Act : jusqu’à 35 millions d’euros ou 7 % du chiffre d’affaires mondial pour les infractions les plus graves, 15 millions d’euros pour le niveau suivant, et 7,5 millions d’euros pour la fourniture d’informations erronées. Le décret ajoute une tranche nationale : un plafond de 1 million d’euros ou 0,5 % du chiffre d’affaires pour les obligations liées aux articles 27 et 86 de l’AI Act (évaluations d’impact sur les droits fondamentaux pour certains utilisateurs et droit à une explication des décisions individuelles).

Le mode de financement mérite d’être souligné : le produit des amendes infligées par l’ACN et l’AgID est prioritairement affecté à ces agences. Un organisme d’application qui s’autofinance en partie grâce à ses propres sanctions a tout intérêt à renforcer ses capacités d’inspection. Parallèlement, l’article 54 pose le principe de neutralité financière, c’est-à-dire sans nouvelle dépense publique, ce que le Garante a signalé comme étant en tension avec l’article 70(3) de l’AI Act, qui exige que les autorités nationales disposent de ressources suffisantes. Il reste donc à voir si l’ACN et l’AgID disposeront des effectifs nécessaires pour inspecter à grande échelle.

Un point requiert de la prudence : le décret ne précise pas la date d’entrée en vigueur de ses sanctions, et il ne mentionne pas le règlement (UE) 2026/1744, le Digital Omnibus européen sur l’IA. Toute affirmation sur la date de début des amendes relève donc de l’interprétation. La lecture prudente est que les pouvoirs institutionnels sont effectifs depuis le 23 octobre 2026, et que le calendrier des sanctions pour chaque obligation dépend des dates prévues par l’AI Act.

Ce qui reste en suspens

Plusieurs éléments du cadre ne sont pas finalisés, et un plan de préparation doit en tenir compte.

Les dispositions sur le « sandbox » réglementaire (articles 26 à 31) décrivent un groupe opérationnel commun qui n’est pas encore constitué, sans délai fixé. Plusieurs actes d’application, notamment les modalités des inspections des tests en conditions réelles, n’ont pas non plus de date limite. L’article 41 rend nulles les décisions d’emploi prises uniquement par des moyens automatisés, sans exception pour le consentement : une position nationale plus stricte, à lire attentivement pour les employeurs utilisant le filtrage ou la planification automatisés.

L’enjeu principal se situe au niveau européen. Le règlement (UE) 2026/1744, le Digital Omnibus sur l’IA, a été publié au Journal officiel le 24 juillet 2026 et est entré en vigueur le 27 juillet 2026. L’analyse de Cooley explique comment il reporte les principales échéances de l’AI Act. Les obligations à haut risque pour les systèmes de l’annexe III sont reportées au 2 décembre 2027, celles pour l’annexe I au 2 août 2028, tandis que les exigences de transparence de l’article 50 s’appliquent dès le 2 août 2026.

Ces dates modifient le calendrier des obligations de fond, mais n’annulent pas le changement institutionnel en Italie. Les autorités existent, les pouvoirs d’inspection existent, et les tests en conditions réelles de systèmes à haut risque peuvent avoir lieu avant l’application formelle des obligations à haut risque sur les systèmes commercialisés. Considérez ce délai comme une occasion de renforcer vos capacités de preuve, non comme une autorisation d’attendre. Les sources qui évoquent encore une échéance à haut risque en août 2026 datent d’avant l’Omnibus et ne doivent pas servir de référence pour votre planification.

Pourquoi les régulateurs contrôlent les données, pas les modèles

Les dirigeants imaginent souvent la régulation de l’IA comme un contrôle des algorithmes. Un inspecteur dans votre bureau posera d’autres questions : quelles données personnelles et sensibles sont entrées dans le système, qui a validé cet accès, si l’accès correspondait à la finalité déclarée, et quelle preuve l’atteste. Un modèle est difficile à auditer de l’extérieur. La traçabilité des données autour du modèle ne l’est pas.

C’est pourquoi les principes de zéro trust pour l’IA générative s’appliquent si directement à la préparation des audits. Un système d’IA est, du point de vue du contrôle, un acteur supplémentaire qui demande l’accès aux données. Il lui faut une identité, un périmètre défini, une décision d’autorisation pour chaque requête, et une trace de ce qui a été fait. Les organisations qui appliquent déjà ces contrôles aux personnes et aux applications peuvent les étendre à l’IA à moindre coût. Celles qui laissent les outils d’IA accéder aux partages de fichiers, archives e-mails et référentiels via des comptes de service génériques découvrent qu’elles ne peuvent pas répondre à la première question de l’inspecteur.

La même logique explique pourquoi l’accent mis par le décret sur les tests en conditions réelles est important. C’est lors de cette phase que les équipes sont tentées d’aller vite avec des données réelles et des contrôles relâchés, puisque le système n’est pas encore en production. C’est aussi la phase qu’un inspecteur italien peut désormais contrôler sans préavis. L’environnement de contrôle autour des données de test doit répondre au même niveau d’exigence que la production, et les preuves doivent être tout aussi accessibles.

La protection des données et la gouvernance de l’IA convergent également dans la pratique. Une approche zéro trust de la confidentialité des données pour l’IA impose déjà la minimisation, la limitation des finalités et la journalisation des accès, qui sont les mêmes éléments que demanderait un contrôle au titre de l’AI Act. Une entreprise qui a fait ce travail pour le RGPD est plus prête qu’elle ne le pense. Une entreprise qui considère l’IA comme hors de son programme de gouvernance des données ne l’est pas.

Comment le décret s’applique selon les profils

Le décret n’impacte pas toutes les organisations de la même façon, et une discussion utile sur la préparation commence par situer la position de l’entreprise. Les trois scénarios ci-dessous sont donnés à titre d’exemple.

Prenons un fournisseur qui conçoit un système d’IA à haut risque pour une infrastructure critique. Cette organisation est la plus exposée. Son système peut devoir être enregistré auprès de l’ACN selon l’article 14, son organisme d’évaluation de la conformité est sous la surveillance d’AgID, et tout test en conditions réelles est susceptible d’inspection. Le fournisseur doit disposer de traces de test, de documentation de gouvernance des données et d’une justification solide du choix et du suivi de son organisme d’évaluation.

Autre cas : un utilisateur, par exemple une banque utilisant un outil d’IA pour l’octroi de crédits. Ici, la Banque d’Italie ou la CONSOB peut être le superviseur compétent selon l’article 17, et la relation de supervision existante façonne l’échange. Les questions porteront sur la façon dont la banque contrôle les données utilisées par l’outil, supervise les résultats, et si ses enregistrements prouvent qu’un humain est responsable de chaque décision. Une banque qui répond déjà à des exigences élevées en matière de preuves TIC et tierces parties part avec un avantage, à condition que ces preuves couvrent aussi l’outil d’IA.

Dernier exemple : un employeur qui utilise le filtrage ou la planification automatisés. L’article 41 rend nulles les décisions d’emploi prises uniquement par des moyens automatisés, sans que le consentement ne puisse y déroger. C’est une règle nationale stricte, qui fait de la revue humaine une obligation légale et non une simple formalité. Un employeur dans ce cas doit s’assurer qu’une personne réellement habilitée examine chaque décision, et conserver la preuve de cette revue. La traçabilité de cette validation est elle-même un élément de gouvernance des données.

Dans les trois scénarios, la même base s’applique : connaître les données auxquelles vos systèmes d’IA accèdent, relier chaque accès à une personne responsable, et conserver une trace qui résiste à un contrôle externe.

Pourquoi la qualité des preuves compte plus que la quantité de politiques

Beaucoup de programmes de conformité mesurent leurs progrès au nombre de politiques rédigées. Les régimes d’inspection en ont une autre lecture. Un inspecteur qui lit une politique IA bien formulée posera la question suivante : comment savez-vous qu’elle a été appliquée ? La réponse se trouve dans les traces opérationnelles, pas dans la politique.

C’est dans cet écart entre politique écrite et preuve opérationnelle que la plupart des organisations sont vulnérables. Une politique peut stipuler que les outils d’IA n’accèdent qu’à des référentiels approuvés, alors que la configuration technique autorise un accès large via un identifiant partagé. Une politique peut exiger une validation humaine pour les données sensibles, sans qu’aucun système n’enregistre qui a validé quoi. Quand un inspecteur confronte la déclaration à la réalité, l’écart devient une non-conformité.

Combler cet écart suppose des contrôles qui appliquent la politique automatiquement et enregistrent la décision. Quand les règles d’accès sont appliquées par le système à chaque requête, le journal montre à la fois la règle et son application, et la politique cesse d’être théorique. C’est la logique de la gouvernance des données pilotée par la politique, où l’approche Data Policy Engine applique les règles aux échanges de contenu de façon cohérente et laisse une trace de chaque décision.

Cela change aussi l’économie de la préparation aux audits. Si la preuve est un sous-produit du fonctionnement normal, une demande d’inspection devient une simple extraction. Si la preuve doit être reconstituée à partir de systèmes dispersés, chaque inspection devient un projet. Avec des pouvoirs d’inspection sans préavis désormais en vigueur en Italie, la différence entre ces deux situations est celle entre un après-midi serein et une crise.

Les preuves qu’un inspecteur demandera

Si un inspecteur de l’ACN demandait aujourd’hui à examiner les tests d’un système d’IA à haut risque, la requête se traduirait probablement par quelques grandes catégories de preuves. Préparer ces éléments à l’avance transforme une inspection stressante en simple échange documentaire.

• Identité de l’acteur. Quel système d’IA, agent ou intégration a accédé aux données, et quel humain ou responsable métier l’a autorisé.
• Périmètre d’accès. Quels référentiels, dossiers et enregistrements le système pouvait atteindre, et lesquels il a atteints, avec la règle ayant permis chaque opération.
• Classification des données. Si des données personnelles, confidentielles ou réglementées étaient concernées, et comment le système les a traitées.
• Chaîne de traçabilité. Un enregistrement montrant ce qu’il est advenu des données après leur traitement par l’IA, y compris tout partage ultérieur. Une chaîne de traçabilité documentée transforme la reconstitution en simple consultation.
• Preuve d’intégrité. Preuve que les journaux n’ont pas été modifiés a posteriori. Des journaux modifiables par un administrateur ont peu de valeur pour un inspecteur.
• Gestion des incidents. Comment les anomalies ont été détectées et remontées, avec un processus de réponse couvrant les événements liés à l’IA.

La plupart des organisations peuvent produire certains de ces éléments pour les personnes et les applications, mais beaucoup moins pour les systèmes d’IA, et encore moins sous une forme unifiée. Des preuves dispersées entre la plateforme d’IA, le système de fichiers, le fournisseur d’identités et un SIEM nécessitent un travail manuel de consolidation, qui prend des jours. Une inspection sans préavis ne laisse pas ce temps.

La qualité compte autant que l’exhaustivité. Un journal d’audit unifié qui enregistre chaque opération avec l’identité, la décision de politique et le résultat constitue une preuve plus solide qu’un ensemble de traces propres à chaque plateforme, avec des horodatages et des noms discordants. Les inspecteurs privilégient les preuves vérifiables et cohérentes. Ils dévalorisent celles qui arrivent tard, incomplètes ou dans des formats contradictoires.

Comment intégrer les agents IA dans ces contrôles

Les agents IA ajoutent une complexité. Un agent peut enchaîner des actions, appeler des outils et extraire des données à une vitesse qu’aucun humain ne peut contrôler étape par étape. La bonne réponse n’est pas un régime distinct et plus souple pour les agents. Ils doivent être régis comme les utilisateurs humains, selon le même modèle d’identité, d’autorisation et d’audit, avec la règle supplémentaire que chaque action d’agent soit rattachée à un humain responsable.

Ce principe correspond à l’adoption du Model Context Protocol (MCP). MCP relie les assistants IA aux sources de données et outils d’entreprise, ce qui est utile mais crée aussi une nouvelle voie d’accès au contenu sensible. Sans contrôle, une intégration MCP peut permettre à un assistant de lire des contenus qu’un utilisateur ne devrait jamais voir. Le Kiteworks Secure MCP Server répond à ce risque en appliquant un contrôle d’accès basé sur les rôles et les attributs, ainsi qu’une authentification OAuth aux requêtes MCP, chaque requête étant journalisée dans la console de contrôle Kiteworks.

La parité humaine est le critère à appliquer à chaque déploiement d’agent. Si un collaborateur ne peut pas ouvrir un fichier, l’agent agissant pour lui ne doit pas pouvoir le faire non plus. Si une action humaine est journalisée avec identité et horodatage, il en va de même pour l’agent. Si une justification métier est requise pour exporter un enregistrement, l’agent doit en fournir une aussi. Selon ce modèle, un inspecteur qui interroge l’accès d’un agent aux données reçoit la même réponse que pour un collaborateur.

Cette approche limite aussi le coût de conformité lié à l’adoption des agents. Plutôt que de bâtir un cadre de contrôle sur mesure pour chaque nouvel outil d’IA, les équipes sécurité étendent les contrôles existants sur la couche données, en utilisant le contrôle d’accès basé sur les rôles et le contrôle d’accès basé sur les attributs, pour couvrir cette nouvelle catégorie de requérants.

Comment Kiteworks contribue à la préparation des audits pour l’accès aux données par l’IA

Kiteworks ne détient pas de certification AI Act européenne, et aucun éditeur ne peut rendre une organisation conforme au décret. Ce que propose Kiteworks, c’est le contrôle et la preuve de la façon dont les systèmes d’IA accèdent au contenu sensible, c’est-à-dire la couche que les inspecteurs examineront.

Kiteworks Compliant AI régit l’accès de l’IA à la couche données. Chaque requête IA est authentifiée via OAuth 2.0 avec une identité liée à l’humain autorisant l’accès, pour garantir la traçabilité et éviter la dilution dans un compte de service partagé. Le contrôle d’accès basé sur les attributs est évalué au niveau de chaque opération, ce qui signifie que la décision de politique s’applique à l’action sur un contenu précis, et pas seulement à la connexion. Le contenu est protégé par un chiffrement validé FIPS 140-3, et l’activité est enregistrée dans un journal d’audit infalsifiable, exportable vers un SIEM pour corrélation avec d’autres événements de sécurité. Pour en savoir plus sur la conformité FIPS 140-3 et son application à la protection des données.

Comparé aux catégories de preuves ci-dessus, ce dispositif permet de démontrer l’identité de l’acteur, le périmètre d’accès et les décisions opérationnelles à partir d’une trace unique. Le journal infalsifiable répond à la question d’intégrité, et l’intégration SIEM à celle de la gestion des incidents. Comme le contrôle s’applique sur le chemin d’échange des données et non dans chaque produit IA, la même trace peut couvrir plusieurs outils IA, ce qui est utile pour les organisations multi-outils.

Les organisations du secteur financier, où la Banque d’Italie, la CONSOB et l’IVASS gardent un rôle de supervision selon le décret, constateront que DORA et d’autres cadres exigent déjà des preuves solides concernant les tiers et les TIC. Une couche de données commune pour l’accès IA permet à un même ensemble de traces de répondre à plusieurs régulateurs. Les organismes publics qui déploient l’IA peuvent appliquer la même logique côté échanges de données.

La limite honnête, c’est que les contrôles produits ne remplacent pas les choix de gouvernance. Vous devez toujours classifier vos systèmes d’IA, décider lesquels sont à haut risque, définir les usages autorisés et désigner des responsables. La technologie rend ces décisions applicables et vérifiables, mais ne les prend pas à votre place.

Plan de préparation concret pour RSSI et CCO

Un décret qui entre en vigueur alors que des actes d’application clés restent à écrire favorise les organisations qui anticipent la nature du contrôle plutôt que d’attendre chaque détail. La séquence suivante fonctionne quels que soient les points en suspens.

1. Recenser les systèmes d’IA et leurs flux de données. Listez chaque système d’IA, agent et intégration en usage ou en test, y compris ceux introduits par les métiers. Pour chacun, notez les données accessibles et la voie d’accès.
2. Classer selon l’AI Act. Déterminez quels systèmes sont potentiellement à haut risque, notamment ceux relevant de l’annexe III point 2, soumis à une obligation d’enregistrement national via l’ACN (article 14).
3. Lier chaque acteur IA à un humain responsable. Remplacez les comptes de service partagés par des identités liées à un autorisateur nommé, pour que chaque action soit traçable jusqu’à une personne capable de s’expliquer.
4. Déplacer les décisions d’accès sur la couche données. Appliquez la politique à chaque opération sur du contenu sensible, pas seulement à la frontière applicative, et appliquez la même politique aux agents et aux humains.
5. Unifier la traçabilité. Centralisez les traces d’accès IA dans un journal infalsifiable, et exportez-le vers votre SIEM pour que les inspecteurs et vos propres équipes disposent de la même trace.
6. Simuler une demande sans préavis. Organisez un exercice où un inspecteur demande dans la journée les preuves de test d’un système à haut risque. Mesurez le délai de réponse et corrigez les lacunes révélées.
7. Cartographier les régulateurs et suivre les points ouverts. Documentez quelle autorité ou superviseur sectoriel s’applique, et surveillez le décret sur les modalités d’inspection, le groupe sandbox et toute consigne issue de l’Omnibus.

Pour les organisations qui transfèrent des données à l’international, une revue de la souveraineté des données s’impose dès la première étape, car des tests IA impliquant des données italiennes hébergées ailleurs soulèvent des questions à la fois au titre de l’AI Act et des transferts.

L’Italie a fait de l’application de l’IA une question d’autorités nommées, de pouvoirs d’inspection et de sanctions, et les preuves recherchées se trouvent dans votre couche données. Pour découvrir comment une traçabilité unifiée et infalsifiable des accès IA peut renforcer votre préparation, réservez votre démo avec Kiteworks.

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour une protection abordable de la confidentialité IA
• Article de blog
  Pourquoi 77 % des organisations échouent sur la sécurité des données IA
• eBook
  Écart de gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.