Pourquoi l'IA est désormais une question relevant de la loi SOCI
Le Security of Critical Infrastructure Act 2018 (Cth) est le cadre australien de protection des actifs sans lesquels le pays ne peut fonctionner : électricité, eau, transports, hôpitaux, systèmes de paiement, distribution alimentaire et infrastructures de données. Il est administré par le Cyber and Infrastructure Security Centre (CISC), au sein du ministère de l'Intérieur (Department of Home Affairs), et il impose des obligations positives de sécurité aux entités responsables qui possèdent ou exploitent ces actifs.
Aucune des dispositions centrales de la loi ne mentionne l'intelligence artificielle. Ce n'est pas nécessaire. L'obligation centrale, le Critical Infrastructure Risk Management Program, est délibérément neutre sur le plan technologique : les entités responsables doivent identifier et gérer chaque risque important pesant sur la disponibilité, l'intégrité, la fiabilité et la confidentialité de leur actif d'infrastructure critique. Lorsqu'un système d'IA planifie la maintenance d'un poste électrique, trie les patients, filtre des transactions ou optimise un processus de traitement de l'eau, ce système d'IA fait partie du fonctionnement de l'actif, et les risques qu'il introduit sont des risques importants que le programme doit couvrir.
La même logique que le régulateur prudentiel australien a appliquée aux banques et aux assureurs dans sa lettre sur l'IA d'avril 2026, à savoir que les cadres existants s'appliquent déjà au risque lié à l'IA et que les conseils d'administration en sont responsables, s'applique avec la même force dans le cadre de la loi SOCI. La différence est que la SOCI couvre des secteurs que l'APRA ne couvre pas : l'énergie, l'eau, les transports, les hôpitaux, les universités, l'industrie de la défense, le spatial, et l'alimentation et l'épicerie.
Ce qu'exige la loi SOCI
La loi s'applique aux entités responsables d'actifs d'infrastructures critiques dans 11 secteurs : les communications, le stockage et le traitement des données, l'industrie de la défense, l'énergie, les services et marchés financiers, l'alimentation et l'épicerie, les soins de santé et le médical, l'enseignement supérieur et la recherche, les technologies spatiales, les transports, et l'eau et les eaux usées. Trois obligations positives de sécurité constituent l'essentiel du dispositif :
- L'enregistrement des actifs. Fournir des informations sur l'actif, ses exploitants et ses détenteurs d'intérêts directs au Register of Critical Infrastructure Assets.
- Le signalement obligatoire des cyberincidents. Les incidents critiques doivent être signalés à l'Australian Cyber Security Centre dans les 12 heures ; les autres incidents significatifs dans les 72 heures.
- Le Critical Infrastructure Risk Management Program (CIRMP). Un programme écrit, approuvé par le conseil d'administration, qui identifie et gère les risques importants selon quatre vecteurs de risque définis.
Les CIRMP Rules (LIN 23/006) sont entrées en vigueur le 17 février 2023. Les entités responsables des catégories d'actifs prescrites devaient disposer d'un programme écrit d'ici août 2023, et se conformer à un cadre de cybersécurité reconnu, tel que l'Essential Eight, l'ISO 27001, le NIST Cybersecurity Framework ou l'AESCSF pour le secteur de l'énergie, d'ici août 2024. Le régime est désormais pleinement entré dans sa phase opérationnelle et de mise en application : le CISC a adopté une posture de conformité plus ferme, a mené des audits, et des sanctions civiles s'appliquent.
Les quatre vecteurs de risque, et où l'IA s'y insère
Le CIRMP doit établir des processus permettant d'identifier et de gérer les risques importants selon quatre vecteurs de risque. L'IA dispose d'une voie d'entrée concrète dans chacun d'entre eux.
1. Les risques liés à la cybersécurité et à la sécurité de l'information
L'IA joue ici un rôle à double tranchant. Des attaquants recourant à l'IA augmentent le rythme et la sophistication des intrusions contre les infrastructures critiques, c'est le volet menace. Mais le volet exposition est celui que le responsable du CIRMP maîtrise : chaque système d'IA connecté à l'actif constitue une nouvelle surface d'attaque. Les modèles peuvent être empoisonnés, des invites peuvent être injectées, les outils d'IA agentique peuvent être manipulés pour accomplir des actions que leurs opérateurs n'avaient jamais envisagées, et les identifiants détenus par les systèmes d'IA constituent des cibles. Si un agent d'IA peut lire ou écrire dans des systèmes qui soutiennent l'actif critique, l'accès qu'il détient fait partie du profil de risque informatique de l'actif. La discipline du moindre privilège pour les identités non humaines, traitée dans notre guide sur le contrôle d'accès des agents d'IA, constitue le contrôle pratique à mettre en œuvre.
2. Les risques liés au personnel
Le vecteur personnel couvre traditionnellement les initiés de confiance : le contrôle préalable des travailleurs critiques pouvant accéder aux composants critiques. L'utilisation par le personnel d'outils d'IA non encadrés relève désormais de la même analyse. Un ingénieur qui colle des schémas de réseau dans un chatbot public, une équipe d'exploitation qui adopte un assistant d'IA non approuvé conservant les invites, ou un prestataire qui utilise un compte d'IA personnel pour établir les plannings, déplacent tous des informations sensibles sur l'actif critique hors du contrôle de l'entité. L'IA fantôme (shadow AI) est un risque lié au personnel exactement au sens envisagé par les Rules : une voie par laquelle des personnes disposant d'un accès légitime créent une exposition non autorisée.
3. Les risques liés à la chaîne d'approvisionnement
C'est le vecteur où atterrit le risque de concentration lié à l'IA. La majeure partie des capacités d'IA arrive par l'intermédiaire de fournisseurs : API de modèles de fondation, produits SaaS intégrant de l'IA, intégrateurs et prestataires de services gérés. Le CIRMP doit identifier les risques importants de perturbation et d'accès non autorisé provenant des fournisseurs, et les fournisseurs d'IA présentent précisément l'opacité que les régulateurs ne cessent de signaler : les entités ne peuvent souvent pas voir quels modèles un fournisseur utilise, où s'exécute l'inférence, quelles données sont conservées, ni à quelle vitesse une modification du côté du fournisseur peut altérer le comportement du système. Un petit nombre de fournisseurs de modèles en amont sous-tendent une large part des produits d'IA, de sorte qu'une seule défaillance ou compromission en amont peut se propager largement. Les fournisseurs d'IA soutenant l'actif critique doivent figurer dans l'évaluation des risques de la chaîne d'approvisionnement avec la même rigueur que tout autre prestataire de services important.
4. Les risques physiques et naturels
Lorsque l'IA participe à la technologie opérationnelle, en optimisant la charge, en contrôlant des processus, en planifiant la maintenance physique ou en éclairant les décisions de répartition, une défaillance du modèle peut devenir un événement physique. Un comportement imprévisible du modèle dans une boucle de contrôle n'est pas une hypothèse d'école : c'est exactement la catégorie de changement de système dynamique et difficile à valider avec laquelle la gestion traditionnelle du changement peine à composer. Si les résultats produits par l'IA alimentent des décisions relatives au fonctionnement physique de l'actif, l'analyse des risques physiques doit tenir compte des modes de défaillance de cette IA.
L'attestation du conseil d'administration, point d'atterrissage du risque lié à l'IA
En vertu de l'article 30AG de la loi, une entité responsable doit remettre au régulateur un rapport annuel sur son CIRMP dans les 90 jours suivant la fin de chaque exercice financier, et ce rapport doit être approuvé par le conseil d'administration ou l'organe de gouvernance. Le rapport doit déclarer que le programme est à jour, faire état des risques ayant eu un impact significatif au cours de l'année, consigner les modifications apportées au programme, et évaluer si le programme a été efficace.
Cette approbation constitue un moment de responsabilité personnelle pour les administrateurs. Un conseil d'administration ne peut attester honnêtement que les risques importants pesant sur l'actif sont identifiés et gérés si personne n'a dressé l'inventaire des systèmes d'IA qui touchent cet actif. La logique est identique à l'attente que l'APRA a fixée pour les conseils d'administration des services financiers : au minimum, un inventaire des outils d'IA et des cas d'usage, avec une responsabilité nommément désignée tout au long du cycle de vie. Pour les entités relevant de la SOCI, la question de l'inventaire est circonscrite par l'actif : quels systèmes d'IA, y compris l'IA intégrée par des fournisseurs, peuvent affecter la disponibilité, l'intégrité, la fiabilité ou la confidentialité de l'actif d'infrastructure critique, à quoi chacun peut-il accéder, et qui en est responsable. Notre guide sur l'inventaire de l'IA en tant qu'exigence réglementaire explique comment construire cet artefact une seule fois et le réutiliser dans plusieurs régimes.
Les réformes de 2024 et 2025 ont resserré le cadre
Le Security of Critical Infrastructure and Other Legislation Amendment (Enhanced Response and Prevention) Act 2024 a apporté trois modifications importantes pour le risque lié à l'IA. Premièrement, il a précisé que les systèmes de stockage de données contenant des données essentielles à l'activité font partie de l'actif d'infrastructure critique, ce qui fait entrer dans le périmètre protégé les plateformes de données qui alimentent et journalisent les systèmes d'IA. Deuxièmement, il a conféré au régulateur le pouvoir d'ordonner à une entité de remédier à un programme de gestion des risques déficient, transformant ainsi une obligation formelle en une norme de qualité opposable. Troisièmement, la sécurité des télécommunications a été intégrée au cadre de la SOCI, les Telecommunications Security and Risk Management Program Rules étant entrées en vigueur le 4 avril 2025.
La direction est à sens unique : des définitions d'actifs plus larges, une application plus ferme, et des attentes plus explicites voulant que le programme de gestion des risques reflète la manière dont l'actif fonctionne réellement aujourd'hui, et non la manière dont il fonctionnait lorsque le programme a été rédigé pour la première fois.
Intégrer l'IA au CIRMP : une séquence pratique
- Dresser l'inventaire de l'IA au regard de l'actif. Recenser chaque système d'IA, y compris l'IA intégrée par des fournisseurs et l'IA fantôme, susceptible d'affecter l'actif d'infrastructure critique. Consigner le responsable, la finalité, les accès et les données concernées.
- Classer selon le risque important. Pour chaque système, évaluer la gravité, l'ampleur et la réversibilité d'une défaillance au regard de la disponibilité, de l'intégrité, de la fiabilité et de la confidentialité de l'actif.
- Rattacher chaque risque lié à l'IA à un vecteur de risque. Affecter les contrôles au vecteur où réside le risque : la gestion des accès et la surveillance pour le vecteur informatique, la politique d'utilisation acceptable et le contrôle préalable pour le vecteur personnel, l'évaluation des fournisseurs et l'analyse de concentration pour le vecteur chaîne d'approvisionnement, et l'analyse des modes de défaillance pour le vecteur physique.
- Mettre à jour le registre des fournisseurs. Ajouter les fournisseurs d'IA et les dépendances aux modèles en amont à l'évaluation des risques de la chaîne d'approvisionnement, avec une visibilité contractuelle sur les modifications de modèles, le traitement des données et la notification des incidents.
- Contrôler les accès non humains. Doter les systèmes et agents d'IA de leurs propres identités, de périmètres de moindre privilège et de mécanismes de révocation. La gestion des identités et des accès conçue pour les humains ne s'applique pas automatiquement aux acteurs d'IA.
- En conserver la preuve pour le rapport annuel. Maintenir à jour l'inventaire de l'IA, les évaluations des risques et la cartographie des contrôles afin que le conseil d'administration puisse approuver l'attestation annuelle sur la base d'un dossier exact, et que les modifications apportées au programme soient documentées comme l'exige la loi.
Où cela recoupe le reste du cadre australien
La SOCI n'opère pas isolément. Une banque ou un assureur réglementé par l'APRA qui est également une entité responsable d'un actif critique de services financiers répond aux deux régimes, et les artefacts se recoupent presque entièrement : un inventaire de l'IA, une répartition claire des responsabilités, une visibilité sur le risque fournisseur et un reporting au niveau du conseil d'administration satisfont, à partir d'une seule base de preuves, à la fois la CPS 230, la lettre de l'APRA sur l'IA et l'attestation du CIRMP. Les garde-fous du Voluntary AI Safety Standard en matière de responsabilité, de gestion des risques et de tenue de dossiers décrivent le même dispositif. Le construire une seule fois, mais bien, est la voie la plus efficace, et c'est l'approche vers laquelle convergent les régulateurs : la gouvernance de l'IA conçue comme une capacité opérationnelle plutôt que comme un ensemble de documents.
Sources principales : Security of Critical Infrastructure Act 2018 (Cth) | Fiche d'information du CISC sur le CIRMP | MinterEllison sur les CIRMP Rules | KWM sur les rapports annuels du CIRMP