Les services numériques doivent non seulement être rentables, mais également robustes : ils doivent continuer à fonctionner si certains fournisseurs ou éléments de base font défaut pour une raison quelconque. Il ne s’agit pas uniquement d’une question purement technique, d’un enfermement propriétaire (vendor lock-in) ou d’architecture multicloud. Nous assistons une fois de plus à l’émergence de questions fondamentales d’indépendance, de sécurité et d’autonomie stratégique : la souveraineté numérique est tendance.

On comprend aisément pourquoi : avec un revirement politique d’une ampleur sans précédent, la réputation des États-Unis en tant que partenaire commercial fiable s’est volatilisée en un temps record. Du jour au lendemain, un service peut être interrompu ou des droits de douane peuvent être introduits sans raison valable. Quiconque développe ou gère des infrastructures IT critiques en tremble rien qu’à l’idée. Et l’autonomie vaut soudain à nouveau son pesant d’or.

Piliers stratégiques

Le cœur de la souveraineté numérique réside dans la capacité à choisir, déployer et gérer des solutions technologiques sans dépendances externes étendues. Ces dépendances sont souvent plus profondes que nous ne le pensons, comme l’a démontré une expérience intéressante du journaliste de Gizmodo, Kashmir Hill, il y a quelques années. La dépendance technologique représente toujours un risque. Afin de le minimiser, nous pouvons entre autres :

• Investir dans le développement local et open source des technologies
• Construire nous-même des infrastructures robustes et décentralisées
• Développer nos propres compétences et capacités technologiques
• Inclure des conditions d’interopérabilité, de migration de données, de flexibilité, d’interruption, etc. dans des clauses contractuelles et les marchés publics.
• …

En matière de développement logiciel pratique également, les choix qui favorisent l’agilité technologique présentent un avantage :

• Choisir des normes ouvertes et des API robustes et standardisées
• Développer des solutions non seulement modulaires et évolutives, mais également agnostiques vis-à-vis du cloud
• Implémenter des middleware capables de relier différentes technologies
• Prêter attention à la portabilité, à la compatibilité multiplateforme et à la compatibilité entre navigateurs
• …

La souveraineté sur les données est également très importante. Une souveraineté numérique exige de conserver un contrôle maximal sur la collecte, le stockage, le traitement et la protection des données. Cela peut se faire en organisant le stockage et le traitement des données localement, de préférence en appliquant des mécanismes solides de gouvernance des données, ou en les confiant à un tiers qui offre les garanties nécessaires et opère dans le cadre d’une législation compatible.

La Belgique se débrouille plutôt bien en matière d’autonomie infrastructurelle, avec le cloud gouvernemental G-Cloud et le réseau Belnet, entre autres.

Le rôle de l’open source

Les technologies open source, en tant que vecteurs d’indépendance technologique, sont des éléments fondamentaux de la souveraineté numérique. Elles offrent une totale transparence du code, permettent la modification ou le propre développement, et diminuent la dépendance vis-à-vis des géants technologiques étrangers.

Cependant, cela a également un coût. L’utilisation de logiciels open source et de normes ouvertes implique de fournir soi-même l’ensemble du support, de la formation, des mises-à-jour, de la compatibilité, du débogage, etc. En échange de l’autonomie, il faut inclure un éventail de tâches connexes. Cela implique notamment un investissement dans la gestion active, ainsi que la maintenance et le développement des connaissances. Les acteurs commerciaux proposant des solutions propriétaires s’en chargent généralement.

Devenir totalement autonome est donc généralement impossible. Il existe un cas d’étude bien connu, celui de la ville de Munich, qui a ambitieusement basculé en 2006 vers un environnement Linux développé en interne, mais qui, en raison de problèmes persistants de compatibilité et de l’augmentation des coûts de gestion qui en découle, a mis fin au programme en 2017 pour revenir à un environnement Microsoft standardisé.

Chez nos voisins

L’Allemagne est une fervente partisane de la souveraineté numérique depuis longtemps. L’Open Source Business Alliance allemande utilise même le terme dans son slogan. L’expérience munichoise a donné naissance à l’actuel Open Source Programme Office de la ville. Le niveau fédéral allemand encourage également l’indépendance technique, notamment :

• Des projets propres tels que Sovereign Cloud Stack (actuellement en transformation après la fin du financement),
• Le Sovereign Tech Fund, qui fournit des fonds pour maintenir les composants open source essentiels,
• Le Zentrum Digitale Souveränität (ZenDis), qui aide les gouvernements à réduire leurs dépendances technologiques.

Ce dernier investit également avec succès dans deux projets propres :

• La plateforme OpenCode, où les services publics peuvent publier et partager leur code avec d’autres,
• L’environnement de travail administratif OpenDesk, qui inclut également des options typiques pour les entreprises telles que l’authentification unique et les intégrations entre les réunions, les « chats », le calendrier et les courriers électroniques.
  

La France n’est pas en reste non plus. Plusieurs initiatives en faveur de la souveraineté numérique sont menées par la Direction interministérielle du Numérique (DINUM). Ils comptent également leur propre dépôt sous la forme de code.gouv.fr. En outre, ils développent de manière proactive de nouvelles applications dans leur propre incubateur. Cela a donné naissance à des projets tels que La Suite Numérique, une suite enterprise level de bureautique qui offre des fonctionnalités telles que le chat vidéo, les webinaires et le transfert de fichiers, et qui est en cours d’extension pour inclure des traitements de texte et des tableurs. La France s’est également engagée dans une stratégie de cloud computing la plus indépendante possible et, tout aussi important, elle s’efforce de motiver et de former ses fonctionnaires par le biais de la communauté des Blue Hats. Du côté des entreprises, l’union des entreprises du logiciel libre et du numérique ouvert (CNLL) s’est engagé en faveur de la souveraineté numérique.

Ce qui est frappant à la fois avec l’OpenDesk allemand et La Suite Numérique française, c’est qu’ils sont tous deux également disponibles en anglais. Même dans le contexte gouvernemental, on prend de plus en plus conscience que les initiatives open source ont de meilleures chances de succès si l’on investit de manière proactive dans l’internationalisation. Plus prometteur encore, DINUM et ZenDis ont commencé une collaboration concrète avec une application de prise de notes développée conjointement. Cette dernière a été présentée lors du dernier FOSDEM, la grand-messe annuelle des développeurs open source à Bruxelles, où les collaborations gouvernementales étaient à l’honneur.

Le tandem franco-allemand est un signe prometteur de la volonté de l’Europe de s’unir pour promouvoir la souveraineté numérique. Nous savons déjà que les Pays-Bas souhaitent se joindre à cette collaboration. En effet, le débat social y est également bien vivant, même à la Seconde Chambre, avec des discussions sur les services cloud ou le DNS. L’Organisation néerlandaise pour la recherche scientifique appliquée (TNO) a publié un long rapport sur la souveraineté numérique, les universités en font un sujet de discussion et le monde des affaires y prête également attention. La souveraineté numérique est à l’ordre du jour à tous les niveaux de gouvernement.

Le rôle de l’Europe

L’Union européenne a un intérêt stratégique évident dans la souveraineté (numérique). Les éléments clés à cet égard sont le récent Digital Markets Act (DMA) et le Digital Services Act (DSA). Ces deux cadres législatifs visent à limiter le pouvoir des géants technologiques étrangers et à rendre le « terrain de jeu » plus équitable et transparent pour les entreprises européennes. L’UE souhaite ainsi renforcer son autonomie stratégique en établissant des règles claires en matière de gestion des données et des plateformes, rendant les États membres européens moins vulnérables aux dépendances extérieures. Le Cybersecurity Act et la directive NIS2 devraient garantir que la sécurité et la fiabilité ne soient pas compromises.

L’UE entreprend également de nombreuses initiatives pertinentes, mais toutes ne décollent pas tout aussi facilement. La fragmentation européenne est une vieille plaie. Les petits projets restent souvent petits et, une fois le financement terminé, ils se transforment en abandonware. Par exemple, il est impossible de savoir si la nouvelle European Open Source Academy survivra à la fin de son cycle de financement en 2027. D’autre part, les consortiums à grande échelle ont de nombreux problèmes de coordination et de contrôle. Le projet GAIA-X a ainsi acquis la réputation d’être plus une histoire de mémos que de démos, si bien que les nouveaux projets tels qu’OpenEuroLLM sont également accueillis avec un certain scepticisme. Le déploiement des European Data Spaces dans divers domaines devrait favoriser la souveraineté sur les données. Cela deviendra obligatoire pour la santé (EHDS), qui pourrait insuffler un nouvel élan. Cela ne suffit cependant pas à apaiser les inquiétudes : le rapport complet EuroStack de la Bertelsmann Stiftung présente même à l’UE une vision plus ambitieuse sur un plateau d’argent.

Sous l’égide de l’Europe Interopérable, on retrouve l’Open Source Observatory and Repository (OSOR), en plus de Public Sector Techwatch et GovTech Connect. Ils surveillent l’utilisation de l’open source dans les administrations gouvernementales européennes depuis plus de 15 ans maintenant, et encouragent les partenariats et la réutilisation. L’Open Source Solutions Catalogue récemment lancé devrait permettre aux pays de réutiliser plus facilement les solutions des uns et des autres. Ils publient également des rapports, des études de cas, des catalogues nationaux (dans lesquels nous trouvons ict-reuse.be) et une lettre d’information. Les gouvernements qui souhaitent mettre en place leur propre Open Source Program Office (OSPO) afin de contribuer activement aux projets open source tels que celui de l’UE, y trouvent le soutien nécessaire. Les Pays-Bas sont déjà convaincus. Si les autorités belges veulent contribuer visiblement à la souveraineté numérique, voilà une excellente occasion.

Conclusion

La souveraineté numérique est plus qu’un choix technique. C’est une stratégie continue pour retrouver un pouvoir d’agir dans un monde numérique hautement interconnecté où les éléments fondamentaux peuvent soudainement changer. Nous ne voulons pas nous contenter de consommer la technologie, mais aussi la façonner, la comprendre et la contrôler activement. Cela nous permettrait de réduire les dépendances externes et les risques qui en découlent. La pensée et la coopération européennes offrent des possibilités de synergies.

L’autonomie technologique nécessite un écosystème technologique sain. Une attention constante au capital humain et au développement des connaissances est indispensable. Pour y parvenir de manière durable, les initiatives de soutien doivent bénéficier des ressources nécessaires :

• Développer de manière proactive des alternatives technologiques, qui anticipent la demande,
• Participer à l’échange de connaissances, à des évènements et réseauter, avec des pairs, des institutions du savoir, des pays voisins, avec l’UE, etc.
• Investir ou participer activement aux solutions open source existantes que l’on réutilise,
• Construire des communautés autour de projets propres,
• Investir dans un design attrayant et l’intuitivité des solutions propres,
• Rendre sa propre solution disponible en dehors de ses murs : publier en open source, intégrer dans des catalogues, ajouter une documentation et une traduction anglaise, etc.
• Travailler sur la notoriété de la marque : sites web, promotion, marketing, salons professionnels, médias (sociaux), etc.
• …

Les personnes intéressées par ce thème peuvent suivre les organisations et les initiatives mentionnées dans cet article sur les médias sociaux ou à travers leurs lettres d’information. Pour une analyse approfondie, le rapport EuroStack mentionné ci-dessus est intéressant. Si vous cherchez des alternatives pour les dépendances dans vos propres projets, european-alternatives.eu, euro-stack.com ou alternativeto.net sont de bons points de départ. Enfin, la souveraineté numérique est un effort d’équipe, n’hésitez donc surtout pas à partager d’autres sources, projets ou liens intéressants dans les commentaires ci-dessous !

______________________

Ce post est une contribution de Joachim Ganseman, consultant IT chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Digitale dienstverlening moet niet alleen kostenefficiënt zijn, maar ook robuust: het moet blijven werken als bepaalde toeleveranciers of bouwblokken het laten afweten, om welke reden dan ook. Dat is niet alleen een louter technisch vraagstuk van vendor lock-in of multicloud architectuur. We zien fundamentele kwesties rond onafhankelijkheid, veiligheid en strategische autonomie opnieuw ter sprake komen: Digitale Soevereiniteit is hot.

De aanleiding is niet ver te zoeken: met een beleidsomslag van jewelste is de reputatie van de VS als betrouwbare handelspartner in recordtempo verdampt. Zonder aanleiding kan van de ene dag op de andere een dienstverlening stopgezet, of een handelstarief ingevoerd worden. Wie kritische infrastructuur en IT ontwikkelt of beheert, trekt lijkbleek weg van het idee alleen al. En zo is zelfredzaamheid plots weer goud waard.

Strategische pijlers

De kern van digitale soevereiniteit ligt in het kunnen kiezen, implementeren en beheren van technologische oplossingen zonder verregaande externe afhankelijkheden. Die afhankelijkheden zitten dieper dan we vaak denken, zoals enkele jaren geleden nog gedemonstreerd in een interessant experiment van Gizmodo journaliste Kashmir Hill. Technologische afhankelijkheid vormt altijd een risico. Om dat te minimaliseren kunnen we onder andere:

• Investeren in lokale en open-source technologie-ontwikkeling
• Zelf robuuste, gedecentraliseerde infrastructuren opbouwen
• Eigen technologische vaardigheden en capaciteiten uitbouwen
• Voorwaarden qua interoperabiliteit, data-migratie, flexibiliteit, stopzetting, … opnemen in contractuele clausules en openbare aanbestedingen
• …

Ook bij praktische software-ontwikkeling hebben keuzes die technologische wendbaarheid bevorderen een streepje voor:

• Verkies open standaarden en robuuste, gestandaardiseerde APIs
• Ontwikkel niet alleen modulair en schaalbaar maar ook cloud-agnostisch
• Implementeer eventueel middleware die verschillende technologieën kan overbruggen
• Besteed aandacht aan portabiliteit, cross-platform en cross-browser compatibiliteit
• …

Daarnaast is ook data-autonomie van groot belang. Zo vereist digitale soevereiniteit dat men maximale controle over data-verzameling, -opslag, -verwerking en -bescherming behoudt. Dat kan door de data-opslag en -verwerking lokaal te organiseren, liefst met toepassing van degelijke data governance mechanismes, of door ze bij een derde partij onder te brengen die de nodige garanties biedt en tenminste onder een compatibele wetgeving opereert.

Het mag gerust gezegd worden dat België het op het vlak van infrastructurele autonomie, met onder andere de overheidscloud Gcloud en Belnet, best goed doet.

De rol van open-source

Open-source technologieën zijn, als enablers van technologische onafhankelijkheid, fundamentele bouwstenen voor digitale soevereiniteit. Ze bieden volledige transparantie van code, geven de mogelijkheid tot aanpassing of eigen ontwikkeling, en ze verminderen de afhankelijkheid van buitenlandse technologiereuzen.

Dat heeft echter ook een kostenplaatje. Wie in eigen beheer open-source software en open standaarden wil aanwenden, moet ook zelf voorzien in alle ondersteuning, opleiding, upgrades, compatibiliteit, eventueel debuggen, etc. In ruil voor autonomie moet je een heel takenpakket mee opnemen in de marge. Dat impliceert dat je moet willen investeren in actief beheer, onderhoud en kennisopbouw. Commerciële spelers met bedrijfseigen oplossingen ontzorgen je daar meestal van.

“All the way” zelfvoorzienend worden is daarom meestal onhoudbaar. Een bekende case studie is die van de stad München, die vanaf 2006 ambitieus overschakelde naar een zelf ontwikkelde Linux-omgeving, maar omwille van aanslepende compatibiliteitsproblemen en de daarmee gepaard gaande oplopende beheerskosten, in 2017 de stekker uit het programma trok en opnieuw voor een gestandaardiseerde Microsoft-omgeving koos.

In de buurlanden

Duitsland draagt het idee van digitale soevereiniteit dus al langer een warm hart toe. De Duitse Open Source Business Alliance zet de term zelfs in hun slogan. De ervaring van München evolueerde naar het huidige Open Source Programme Office van de stad. Het Duitse federale niveau moedigt technische onafhankelijkheid ook aan, met onder andere:

• Eigen projecten zoals Sovereign Cloud Stack (lijkt momenteel in transformatie na afloop financiering),
• Het Sovereign Tech Fund, dat financiering voorziet om kritische open-source componenten te onderhouden,
• Het Zentrum Digitale Souveränität (ZenDis), dat overheden ondersteunt bij de afbouw van technologische afhankelijkheden.

Die laatste investeert ook met succes in 2 eigen projecten:

• Het platform OpenCode waar overheidsdiensten hun code kunnen publiceren en delen met anderen,
• De administratieve werkomgeving OpenDesk , die ook typische enterprise-opties omvat zoals Single Sign-on en integraties tussen meetings, chats, kalender, en email.

Frankrijk zit evenmin stil. Verschillende initiatieven voor digitale soevereiniteit worden bij onze zuiderburen getrokken door DINUM, de centrale interministeriële dienst voor digitalisering. Met code.gouv.fr hebben zij ook hun eigen code repository. Daarnaast ontwikkelen ze zelf proactief nieuwe toepassingen in een eigen incubator. Dat resulteerde onder andere in La Suite Numérique, een enterprise-level kantoorsuite die functionaliteiten zoals videochat, webinars, en file transfer aanbiedt, en nu wordt uitgebreid met tekstverwerkers en spreadsheets. Frankrijk zet eveneens in op een maximaal onafhankelijke cloud-strategie, en minstens zo belangrijk, werken ze aan motivatie en kennis bij hun overheidsmedewerkers via de Blue Hats community. Vanuit het bedrijfsleven zet CNLL zich in voor digitale soevereiniteit.

Opvallend aan zowel het Duitse OpenDesk als het Franse La Suite Numérique, is dat beide ook beschikbaar zijn in het Engels. Zelfs in overheidscontext is dus ondertussen het bewustzijn gegroeid dat open-source initiatieven betere slaagkansen hebben als men proactief investeert in internationalisering. Nog hoopgevender is dat DINUM en ZenDis concreet zijn beginnen samenwerken. Op het laatste FOSDEM evenement, de jaarlijks weerkerende hoogmis voor open-source developers in Brussel, stonden overheidssamenwerkingen in de kijker en presenteerden ze een tesamen ontwikkelde notitie-app.

Deze Duits-Franse tandem is een veelbelovend teken dat, als het gaat over het bevorderen van digitale soevereiniteit, de wil alleszins bestaat om Europese krachten wat te bundelen. Er is alvast bekend dat Nederland wil aansluiten bij hun samenwerking. Daar leeft de maatschappelijke discussie immers ook, tot in de Tweede Kamer, met debatten over clouddiensten of DNS. Het onderzoeksinstituut TNO publiceerde er een lijvig rapport over digitale soevereiniteit, de universiteiten agenderen het, en ook het bedrijfsleven besteedt er aandacht aan. Op alle bestuursniveaus ligt digitale soevereiniteit er op tafel.

De rol van Europa

De EU heeft een evident strategisch belang bij (digitale) soevereiniteit. Centrale elementen hierin zijn de recente Digital Markets Act (DMA) en Digital Services Act (DSA). Beide wetgevende kaders hebben tot doel om de macht van buitenlandse technologiereuzen te beperken en het speelveld voor Europese bedrijven gelijkwaardiger en transparanter te maken. Hiermee wil Europa haar strategische autonomie versterken door duidelijke regels te stellen rondom data- en platformbeheer, waardoor Europese lidstaten minder kwetsbaar worden voor externe afhankelijkheden. De Cybersecurity Act en de NIS2-richtlijn moeten erover waken dat daarbij niet aan veiligheid en betrouwbaarheid wordt ingeboet.

Ze onderneemt daarnaast tal van relevante initiatieven, maar die komen niet allemaal even vlot van de grond. De Europese versnippering is een oud zeer. Kleine projecten blijven vaak klein, en eens de financiering afloopt, verworden ze tot abandonware. Zo is het onvoorspelbaar of het net gestarte European Open Source Academy het einde van haar financieringsronde in 2027 zal overleven. Grootschalige consortia kennen dan weer heel wat problemen met coördinatie en sturing. Het GAIA-X project heeft zo enigszins de reputatie gekregen als een verhaal van meer memo’s dan demo’s, wat maakt dat ook nieuwe projecten zoals OpenEuroLLM met enige scepsis onthaald worden. De uitrol van de Europese Data Spaces in verschillende domeinen moet data-autonomie bevorderen. Voor gezondheid (EHDS) wordt deze verplicht, wat misschien voor nieuw momentum kan zorgen. Maar dat is niet genoeg om de bezorgdheden weg te nemen: het lijvige EuroStack rapport van de Bertelsmann Stiftung stelt de EU zelfs op een dienblaadje een ambitieuzere visie voor.

Onder de paraplu van Interoperable Europe vinden we naast Public Sector Techwatch en GovTech Connect ook OSOR, het Open Source Observatory and Repository, terug. Zij monitoren ondertussen al meer dan 15 jaar het gebruik van open-source in Europese overheidsadministraties, en moedigen samenwerkingsverbanden en hergebruik aan. Met de recent gelanceerde Open Source Solutions Catalogue moet het gemakkelijker worden voor landen om elkaars oplossingen te hergebruiken. Daarnaast publiceren ze rapporten, case studies, nationale catalogi (waarin we ict-reuse.be terugvinden) en een nieuwsbrief. Overheden die zelf een Open Source Program Office (OSPO) willen oprichten om actief bij te dragen aan open-source projecten, net zoals de EU er een heeft, vinden bij hen steun. Nederland is alvast overtuigd. Als Belgische overheden zichtbaar willen bijdragen aan digitale soevereiniteit, ligt hier nog een uitgelezen kans.

Conclusie

Digitale soevereiniteit is meer dan een technische keuze. Het is een continue strategie om agency terug te winnen in een sterk geïnterconnecteerde digitale wereld waarvan fundamentele bouwblokken plots kunnen verschuiven. We willen niet alleen technologie consumeren, maar deze ook actief vormgeven, begrijpen en controleren. Zo beperken we externe afhankelijkheden en de risico’s die daarmee gepaard gaan. Europees denken en samenwerken biedt daarbij opportuniteiten voor synergieën.

Technologische autonomie vereist een gezond technologisch ecosysteem. Permanente aandacht voor menselijk kapitaal en kennisopbouw zijn een must. Om dat te doen slagen op een duurzame manier, verdienen ondersteunende initiatieven de nodige middelen:

• Proactief technologische alternatieven ontwikkelen, anticiperend op de vraag,
• Participeren in kennisuitwisseling, evenementen en netwerken, met vakgenoten, kennisinstellingen, buurlanden, EU, …
• Actief meewerken aan, of investeren in, bestaande open-source oplossingen die je zelf hergebruikt,
• Communities uitbouwen rondom eigen projecten,
• Investeren in aantrekkelijke vormgeving en gebruiksgemak van de eigen oplossingen,
• Eigen oplossingen inzetbaar maken buiten de eigen muren: publiceren als open-source, integreren in catalogi, een Engelse vertaling en documentatie toevoegen,
• Werken aan naambekendheid: websites, promotie, marketing, vakbeurzen, (social) media, …
• …

Wie interesse heeft om dit thema verder op te volgen, kan de in dit artikel vermelde organisaties en initiatieven volgen op sociale media of via hun nieuwsbrieven. Voor een deep dive is het bovenvermelde EuroStack rapport interessant. Om alternatieven te zoeken voor afhankelijkheden in je eigen projecten, zijn european-alternatives.eu, euro-stack.com, of alternativeto.net goede startpunten. Tot slot: digitale soevereiniteit is een team effort, voel je daarom vrij om andere bronnen, projecten, of interessante links te delen in de commentaren hieronder!

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Avec la popularité des applications d’IA dotées d’une interface conversationnelle, un “vieux casse-tête” refait surface : comment protéger les données personnelles communiquées, souvent sans méfiance, à un système automatisé de conversation ? Par extension, cette question se pose pour toute application où des données personnelles doivent être partagées avec des tiers. Les dépendances externes d’une application peuvent toutefois constituer un enchevêtrement complexe. Il n’est pas non plus toujours possible (ou économiquement viable) d’éviter les grands acteurs d’infrastructures informatiques d’IA – du moins pas si vous souhaitez rester à jour avec les dernières capacités de manière rentable.

Une solution possible est connue sous le nom de PII Filtering. En l’occurrence, PII est l’acronyme anglais de Personal(ly) Identifiable/Identifying Information, c’est-à-dire les informations par lesquelles une personne peut être identifiée. L’idée est assez simple : un filtre supplémentaire est placé devant l’application, qui élimine les informations à caractère personnel des données d’entrée, avant que celles-ci ne soient transmises à l’application. Si cela fonctionne bien, alors ce que l’application fait de ces données en coulisses n’a pas d’importance.

PII vs. Personal Data

Avant toute chose, il est crucial de comprendre que les PII ne peuvent être assimilées à des “Personal Data” telles que définies par le RGPD et d’autres législations européennes. Les PII sont un concept ancré dans le droit états-unien. Elles font généralement référence à un ensemble fini d’informations d’identification qui peuvent être utilisées dans le but de distinguer ou de confirmer l’identité d’un individu, comme les numéros de registre national, les adresses et les numéros de téléphone. Aux États-Unis, les réglementations sont souvent prescriptives à cet égard : par exemple, HIPAA (réglementation sur la protection des données relatives à la santé) comprend une liste de 18 identifiants définis comme PII. Cela présente le grand avantage d’être relativement facile à implémenter : une fois que la liste est entièrement cochée, il n’y a plus guère de débat juridique possible.

En revanche, la RGPD européenne adopte une approche de principe : elle définit un concept plus large de Personal Data (données à caractère personnel). Ce concept englobe “toute information se rapportant à une personne physique identifiée ou identifiable”. Cela signifie que même des informations en apparence anodines, comme la couleur “rouge”, peuvent être considérées comme des données à caractère personnel si elles se rapportent, par exemple, à la couleur préférée d’une personne. Cette définition des données à caractère personnel dépendante du contexte rend toutefois pratiquement impossible le développement de détecteurs ou de filtres génériques et polyvalents pour ces données. Ce qui est considéré comme des données personnelles ou non doit être évalué au cas par cas. Les développeurs sont donc confrontés à une personnalisation plus importante qu’ils ne le souhaiteraient, mais les juristes, les DPO et les autorités de protection des données ont également fort à faire avec de telles évaluations dans chaque pays de l’UE.

Ainsi, les solutions de filtrage des PII considérées comme conformes aux États-Unis risquent toujours de ne l’être que partiellement dans l’Union européenne. Étant donné que le terme PII semble s’être imposé sur le marché mondial, nous ferons dans le présent article uniquement référence aux PII. Gardez toujours à l’esprit que le Personal Data doit être le point de départ dans le contexte de l’UE.

Détection et filtrage des PII

Afin de filtrer des informations textuelles, nous utilisons généralement des modèles techniques de reconnaissance de formes et de traitement automatique des langues (Natural Language Processing ou NLP). Ces modèles analysent les données non structurées, à la recherche de formes telles que des formats d’adresses e-mail ou des chaînes numériques similaires à un registre national ou encore à des numéros de téléphone, afin de les modifier ou de les anonymiser par la suite. En outre, des formes d’expression régulières (regex) personnalisées sont souvent ajoutées afin de reconnaître les formes d’informations sensibles spécifiques à l’application en question.

Un filtrage efficace des PII repose en grande partie sur la reconnaissance d’entités nommées (Named Entity Recognition ou NER), une méthode NLP qui identifie les entités telles que les noms, les dates et les lieux dans un texte. Nous avons déjà publié des articles plus détaillés à ce sujet – voir les articles sur NLP et NER.  L’essor de l’IA générative n’a pas encore changé grand-chose à la conception des techniques de NER. Aujourd’hui encore, de nombreux outils de filtrage de PII utilisent des outils NLP sous-jacents bien développés tels que NLTK, SpaCy ou Flair.

Toutefois, les PII peuvent également apparaître dans des images : scans de documents, photos de visages ou de plaques d’immatriculation, … Le filtrage de ces images nécessite une approche plus sophistiquée, car les données sensibles peuvent apparaître sous diverses formes, de notes écrites à la main à des reflets sur des photos. La reconnaissance optique de caractères (Optical Character Recognition ou OCR) permet d’extraire le texte des images et de le convertir dans un format qui peut être analysé de la même manière que des données textuelles. Une fois le texte extrait, il est soumis au même processus de filtrage des PII à l’aide de techniques NLP. Des algorithmes de reconnaissance d’objets sont utilisés pour reconnaître les éléments visuels sensibles (tels que des visages ou des documents personnels) contenus dans l’image elle-même.

Une fois identifiées, vous devez décider de ce qu’il convient de faire avec les PII détectées. Les options possibles sont les suivantes :

• Remplacement/substitution par une autre valeur. Celle-ci peut éventuellement être créée à l’aide d’un outil de génération de données synthétiques, de sorte que l’original est remplacé par une alternative d’apparence réaliste.
• Masquage / obfuscation : remplacement par un caractère ou une barre. Cela peut être partiel, afin de ne pas perdre des informations plus générales utiles : par exemple, nous pouvons toujours voir que +32********* est un numéro de téléphone belge.
• Suppression
• Hashage (mieux encore avec salage en prévention des attaques par force brute)
• Chiffrement, éventuellement préservant le format des données
• …

D’autres fonctions sont possibles pour les images, notamment :

• Flouter (blurring) ou d’autres filtres. Il convient de noter ici que certains filtres sont réversibles.
• Couvrir ou écraser, par exemple avec un rectangle noir.
• …

Le remplacement par une valeur alternative du même type peut toutefois créer des effets étranges, parce que l’entité n’est pas toujours estimée correctement ou parce que trop peu ou pas de contexte peut être pris en compte. Certains outils peuvent ainsi ne pas tenir compte du genre si un nom aléatoire doit être choisi pour remplacer un nom réel, alors qu’il peut être nécessaire de rester cohérent sur le plan grammatical ou sur celui du contenu. Il arrive également que des noms de lieux comme Saint-Nicolas soient anonymisés en Saint-Kevin, par exemple, parce que Nicolas est considéré comme un prénom. Les modèles de langage utilisés pour la NER ne sont donc certainement pas sans faille.

En théorie, il devrait être possible d’obtenir de meilleurs résultats en activant des LLM modernes comme le GPT-4 avec des requêtes construites de manière intelligente. Des mesures dans ce sens verront probablement le jour sous peu, mais aujourd’hui, les besoins en puissance de calcul, la consommation d’énergie et le coût sont encore trop élevés, et le temps de réponse trop lent, pour que l’on puisse également faire évoluer cette méthode.

Outils courants

Les personnes qui recherchent des systèmes de filtrage de PII à grande échelle, et qui souhaitent pouvoir analyser des bases de données, des réseaux ou des systèmes de fichiers entiers, se retrouvent avec des outils du domaine de Data Loss Prevention. Ceux-ci devraient empêcher les PII de quitter l’entreprise sans les autorisations nécessaires. Vous trouverez une vue d’ensemble du marché en consultant Gartner. Les géants de l’internet proposent également des solutions à cette fin, telles que Amazon Macie, Google SDP, ou IBM Guardium. Les techniques utilisées dans ces outils sont quelque peu liées à celles utilisées dans les enquêtes judiciaires – ce que l’on appelle l’eDiscovery, que nous avons déjà évoquée.

Les créateurs d’applications sont plus susceptibles d’être intéressés par des outils sous forme de bibliothèques, de SDK ou d’API. Les projets intéressants sont les suivants :

• Pour le texte :
  • Microsoft Presidio (démo) (également disponible sous la forme de Docker containers), ou le service PII detection sur Azure
  • Amazon Comprehend (démo)
  • Les EU Language Services pour NLP (login requis) : pour l’anonymisation des documents dans les langues de l’UE, basé sur le projet MAPA-EU, qui peut également être utilisé via Docker Compose.
  • PIICatcher (pour les bases de données et les systèmes de fichiers)
• Pour les images :
  • Google Magritte (pour les visages)
  • Meta Research EgoBlur (Pour les visages et les plaques d’immatriculation)
  • OctoPII (Uniquement la détection, pas la modification. Pour les documents et les systèmes de fichiers, avec Tesseract pour OCR engine)

De nouvelles recherches sont également en cours dans les universités. Par exemple, PII-Codex est le résultat d’un projet universitaire qui présente une caractéristique intéressante : il utilise Presidio ou Comprehend, mais ajoute également son propre score de risque, qui devrait être en mesure d’indiquer dans quelle mesure la non modification des PII reconnues pourrait poser un risque (pour la protection de la vie privée). En outre, la plupart des outils permettent d’utiliser vos propres modèles ou ceux des autres. Vous pouvez éventuellement les peaufiner vous-même pour la détection personnalisée d’entités, si vous disposez des données d’entraînement nécessaires à cet effet.

Si nous nous appuyons sur la NER ou la reconnaissance d’images pour la détection des PII, il est certain que certaines PII ne seront pas détectées et qu’à l’inverse, des éléments non PII pourraient également être classés à tort comme des PII. En effet, aucune de ces technologies ne garantit une précision de 100 %. Le taux de réussite variera également en fonction de la langue et du type d’entité que l’on tente de détecter. Il n’est jamais possible de garantir complètement le remplacement ou la suppression de chaque entité dans un document. Il est donc préférable de vérifier le résultat dans les cas où cela s’avère crucial.

Conclusion

Les solutions de filtrage de PII peuvent certainement contribuer à la protection de données à caractère personnel dans un contexte européen. Les techniques sont simples à comprendre et faciles à mettre en œuvre. Cependant, il n’y a jamais de garantie de détection totalement précise de toutes les données à caractère personnel et, dans la plupart des cas, leur utilisation devra donc faire partie d’un éventail plus large de mesures visant à promouvoir la conformité avec la RGPD et d’autres législations.

La technologie sous-jacente est “classique”, en ce sens que la NER et la reconnaissance d’images existent depuis longtemps et sont désormais bien développées. Aujourd’hui, elles bénéficient de l’attention portée à l’intelligence artificielle, et toutes sortes d’étalons leur permettent de rester à la pointe du progrès. Dans la pratique, nous constatons que le texte anonymisé qui en résulte peut parfois sembler un peu aliénant, car certains problèmes tout aussi classiques auxquels la NER est généralement confrontée ne sont pas encore totalement écartés.

______________________

Cette contribution a été soumise par Joachim Ganseman, consultant IT chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

De populariteit van AI-toepassingen met chat-interface, doet een “oud zeer” opnieuw bovendrijven: hoe beschermen we persoonsgegevens die, vaak nietsvermoedend, via chat worden meegedeeld aan een geautomatiseerd systeem? Bij uitbreiding stelt zich deze vraag voor elke toepassing waar persoonsgebonden gegevens gedeeld moeten worden met derde partijen. De externe afhankelijkheden van een toepassing kunnen echter een ingewikkeld kluwen zijn. Het is ook niet altijd mogelijk (of economisch haalbaar) om de grote spelers op het vlak van cloud- en AI-diensten te ontwijken – toch niet als je mee wil zijn met de nieuwste mogelijkheden op een kostenefficiënte manier.

Een mogelijke oplossing staat bekend als PII Filtering. PII is daarbij het Engels acroniem voor Personal(ly) Identifiable/Identifying Information, i.e. de informatie waarmee iemand geïdentificeerd kan worden. Het idee is eenvoudig genoeg: we plaatsen een extra filter voor de applicatie, die de persoonlijke gegevens uit de input filtert, voordat die input aan de applicatie wordt doorgegeven. Als dat goed lukt, dan maakt het in principe niet meer uit wat de applicatie achter de schermen met die gegevens doet.

PII vs. Personal Data

Het is allereerst cruciaal om te begrijpen dat “PII” niet gelijkgesteld kan worden aan “Personal Data” zoals de GDPR en andere Europese wetgeving die definieert. PII is een concept dat geworteld is in Amerikaanse wetgeving. Het doelt meestal op een eindige set identificatiegegevens die kunnen worden gebruikt om de identiteit van een individu te onderscheiden of te achterhalen, zoals rijksregisternummers, adressen en telefoonnummers. Amerikaanse regelgeving is op dat vlak vaak prescriptief van aard: zo bevat de HIPAA (privacywetgeving m.b.t. gezondheidsgegevens) een lijst met 18 identifiers die als PII worden gedefinieerd. Dat heeft als groot voordeel dat het relatief gemakkelijk te implementeren is: wanneer het lijstje helemaal afgevinkt kan worden, is er ook juridisch weinig discussie meer.

Daarentegen hanteert de Europese GDPR (AVG) een principiële benadering: ze definieert een breder concept van Personal Data (persoonsgegevens). Dat omvat “alle informatie met betrekking tot een geïdentificeerde of identificeerbare natuurlijke persoon”. Dit betekent dat zelfs schijnbaar onschuldige informatie, zoals de kleur “rood”, beschouwd kan worden als persoonsgegeven, als deze bijvoorbeeld betrekking heeft tot iemands lievelingskleur. Deze contextafhankelijke definitie van persoonsgegevens, maakt het echter ook nagenoeg onmogelijk om generieke, algemeen inzetbare detectoren of filters ervoor te ontwikkelen. Wat beschouwd wordt als persoonsgegeven of niet, moet geval per geval beoordeeld worden. Niet alleen ontwikkelaars worden daardoor geconfronteerd met meer maatwerk dan hen lief is, ook juristen, DPO’s en Gegevensbeschermingsautoriteiten hebben met zulke beoordelingen in elk EU-land de handen vol.

Oplossingen voor PII-filtering die voldoen voor gebruik in de VS, lopen dus altijd een risico om in de EU slechts gedeeltelijk tegemoet te komen aan de vereisten. Omdat de term PII echter algemeen ingang gevonden lijkt te hebben in de globale markt, spreken we verder in dit artikel enkel nog over PII. Houd wel permanent in het achterhoofd dat Personal Data altijd het uitgangspunt moet zijn in EU-context.

PII Detectie en Filtering

Om tekstuele input te filteren gebruiken we doorgaans patroonherkenningstechnieken en Natural Language Processing (NLP)-modellen. Deze modellen scannen ongestructureerde gegevens, op zoek naar patronen zoals e-mailformaten of numerieke reeksen die lijken op rijksregister- of telefoonnummers, om deze nadien te kunnen redigeren of anonimiseren. Daarnaast worden aangepaste regex-patronen vaak toegevoegd om vormen van gevoelige informatie te herkennen die specifiek zijn voor de betrokken toepassing.

Effectieve PII-filtering steunt sterk op Named Entity Recognition (NER), een NLP-methode die entiteiten zoals namen, data en locaties in een tekst identificeert. We publiceerden daar eerder al over in meer detail – zie deze artikels over NLP en NER. De opkomst van generatieve AI heeft aan de opzet van NER-technieken nog niet veel veranderd. Ook vandaag gebruiken veel PII filtering tools achterliggend goed ontwikkelde NLP-toolkits zoals NLTK, SpaCy of Flair.

PII kan echter ook in afbeeldingen opduiken: scans van documenten, foto’s van gezichten of nummerplaten, … Om dat weg te filteren is een geavanceerdere aanpak vereist, omdat de gevoelige gegevens kunnen verschijnen in uiteenlopende vormen, van handgeschreven notities tot reflecties in foto’s. Optical Character Recognition (OCR) wordt gebruikt om tekst uit afbeeldingen te extraheren en deze om te zetten in een formaat dat op dezelfde manier kan worden geanalyseerd als tekstuele gegevens. Zodra de tekst is geëxtraheerd, ondergaat deze hetzelfde PII-filterproces met behulp van NLP-technieken. In gevallen waarin de afbeelding zelf gevoelige visuele elementen bevat (zoals gezichten of persoonlijke documenten), worden algoritmen voor beeldherkenning gebruikt om dergelijke inhoud te herkennen.

Eenmaal geïdentificeerd, moet je besluiten wat er dient te gebeuren met de gedetecteerde PII. Opties kunnen zijn:

• Vervanging / substitutie door een andere waarde. Deze kan eventueel aangemaakt worden met een synthetic data tool, zodat het origineel vervangen wordt door een realistisch ogend alternatief.
• Masking / obfuscation: vervang door een karakter of balkje. Dit kan eventueel gedeeltelijk, om nuttige algemenere info niet te verliezen: zo zien we nog dat +32********* een Belgisch telefoonnummer is.
• Verwijdering
• Hashing (best met salt ter preventie van brute-force attacks)
• Encryptie, eventueel formaat-behoudend
• …

Voor afbeeldingen zijn andere functies mogelijk, waaronder:

• Vervagen (blurring) of andere filters. Hierbij moet men er wel op letten dat sommige filters omkeerbaar zijn.
• Bedekken of overschrijven, bijvoorbeeld met een zwarte rechthoek.
• …

De vervanging door een alternatieve waarde van dezelfde soort kan echter soms ook voor vreemde effecten zorgen, omdat de entiteit niet altijd correct wordt ingeschat of omdat er te weinig of geen rekening gehouden kan worden met de context. Zo kan het zijn dat sommige tools geen acht slaan op het geslacht als een willekeurige naam moet worden gekozen om een echte naam te vervangen, terwijl dat wel nodig kan zijn om grammaticaal of inhoudelijk consistent te blijven. We zien soms ook plaatsnamen zoals Sint-Niklaas geanonymiseerd worden als pakweg Sint-Kevin, omdat Niklaas als naam werd aanzien. De taalmodellen gebruikt voor NER zijn dus zeker niet feilloos.

Het zou in theorie mogelijk moeten zijn om betere resultaten te halen door recente LLMs zoals GPT-4 in te schakelen met slim geconstrueerde prompts. Waarschijnlijk zullen er binnenkort wel stappen in die richting worden gezet, maar vandaag zijn de rekenkrachtvereisten, energieconsumptie en kostprijs daarvan nog te hoog, en de responstijd te traag, om dat ook schaalbaar te maken.

Tools of the trade

Wie op zoek gaat naar grootschalige PII Filtering systemen, en volledige databases, netwerken of filesystems wil kunnen scannen, komt terecht bij Data Loss Prevention tools. Deze moeten verhinderen dat PII het bedrijf verlaat zonder de nodige toelatingen. Voor een marktoverzicht verwijzen we naar Gartner. Ook de internetgiganten bieden daarvoor oplossingen aan, zoals Amazon Macie, Google SDP, of IBM Guardium. De daarbij gebruikte technieken zijn enigszins verwant met diegene gebruikt bij forensisch onderzoek – de zogenaamde eDiscovery, waarover we ook al eerder schreven.

Applicatiebouwers zijn waarschijnlijk eerder geïnteresseerd in tools in de vorm van bibliotheken, SDK’s of API’s. Interessante projecten zijn:

• Voor tekst:
  • Microsoft Presidio (demo) (ook beschikbaar als Docker containers), of de PII detection dienst op Azure
  • Amazon Comprehend (demo)
  • De EU Language Services voor NLP (inloggen vereist): voor anonymisering van documenten in EU-talen, gebaseerd op het MAPA-EU project dat ook via Docker Compose gebruikt kan worden.
  • PIICatcher (voor databases en filesystems)
• Voor afbeeldingen:
  • Google Magritte (voor gezichten)
  • Meta Research EgoBlur (voor gezichten en nummerplaten)
  • OctoPII (enkel detectie en geen redactie. Voor documenten en filesystems, met Tesseract als OCR engine)

Ook in academia wordt er verder onderzoek gedaan. Zo is PII-Codex het resultaat van een universitair project, met een interessante feature: achterliggend maakt het gebruik van Presidio of Comprehend, maar het voegt ook een eigen risico-score toe, die moet kunnen aangeven in welke mate het niet-redigeren van de herkende PII een (privacy-)risico zou kunnen inhouden. Daarnaast laten de meeste tools ook toe om andere of eigen modellen in te pluggen. Deze kan je eventueel zelf gefinetuned hebben voor detectie van custom entiteiten, als je daarvoor de nodige trainingsdata hebt.

Als we vertrouwen op NER of beeldherkenning voor PII-detectie, dan kunnen we er zeker van zijn dat sommige PII niet gedetecteerd zal worden, en dat ook andersom niet-PII foutief als PII aangemerkt kan worden. Geen van deze technologieën garandeert immers 100% accuraatheid. Het succespercentage zal ook variëren afhankelijk van de taal en het entiteitstype dat men probeert te detecteren. Volledige vervanging of verwijdering van elke entiteit in een document kan nooit worden gegarandeerd. Daar waar dat cruciaal is, wordt het resultaat achteraf dus best nog gecontroleerd.

Conclusie

Oplossingen voor PII-filtering kunnen in Europese context zeker bijdragen aan de bescherming van persoonsgegevens. De techniek is eenvoudig te begrijpen en gemakkelijk inzetbaar. Er is echter nooit een garantie op volledige accurate detectie van alle persoonsgegevens, en dus zal hun gebruik in de meeste gevallen een onderdeel moeten zijn van een ruimere waaier aan maatregelen om compliance met GDPR en andere wetgeving te bevorderen.

De achterliggende technologie is “klassiek”, in de zin dat NER en beeldherkenning al lang bestaan en ondertussen goed ontwikkeld zijn. Vandaag profiteren ze mee van de aandacht voor artificiële intelligentie, en allerlei benchmarks laten toe om de state-of-the-art op te volgen. In de praktijk merken we wel dat de resulterende geanonymiseerde tekst soms wat bevreemdend kan overkomen, omdat enkele al even klassieke problemen waar NER typisch mee kampt, nog altijd niet helemaal van de baan zijn.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Note : il s’agit d’un article de vulgarisation consacré à une réglementation future, basé sur la publication officielle du 12/07/2024. Adressez-vous toujours à un·e juriste pour obtenir un avis juridique professionnel.

L’AI Act européen (en français le règlement sur l’intelligence artificielle) est une des pierres angulaires d’une série d’initiatives législatives à grande échelle destinées à réglementer l’économie numérique en Europe. Il vient ainsi compléter la législation antérieure relative à certains aspects de l’intelligence artificielle, comme le RGPD, le Digital Services Act (DSA) et le Digital Markets Act (DMA), le Data Act, le Data Governance Act, le CHIPS Act et le Cyber Resilience Act en cours d’élaboration. Après de longues négociations, l’AI Act a été approuvé par le Parlement européen en mars 2024 et par le Conseil européen en mai 2024. La publication au Journal officiel de l’Union européenne, que l’on peut appeler Moniteur européen, a eu lieu le 12 juillet 2024. Les premières règles entreront en vigueur début 2025. Vous pouvez également consulter cette chronologie.

Un RGPD bis ?

Le texte intégral de l’AI Act, y compris l’ensemble des préliminaires et annexes, comprend 144 pages. Fort heureusement, de bons résumés sont déjà disponibles ici et là. Il est ainsi presque deux fois plus long que le RGPD qui ne fait, lui, “que” 88 pages. L’impact de ce dernier est énorme : toutes les organisations traitant des données à caractère personnel – il suffit d’avoir une administration du personnel ou un fichier de clients – se sont en effet vues confrontées aux exigences relatives aux délégués à la protection des données, aux registres de traitement et aux bases juridiques du traitement des données. Chaque pays a également dû mettre en place une  Autorité de protection des données habilitée à infliger des amendes en cas d’infraction.

Le RGPD s’est également accompagné d’une certaine confusion, notamment par son utilisation fréquente de termes ouverts à l’interprétation (“approprié”, “adéquat”, “adapté”, “suffisant”…).
La nécessité de les concrétiser à nouveau pour chaque cas d’espèce alimente ce que l’on peut aujourd’hui appeler une petite industrie juridique. L’AI Act vise à fournir un peu plus d’indications, en revêtant une forme plus technique. Il comporte ainsi une liste d’annexes avec des énumérations pratiques des attentes en matière de documentation, de conformité, de transparence, etc.

L’AI Act est parti d’une proposition plus compacte de 125 pages (annexes incluses). Au cours des négociations cependant, on a assisté à l’essor fulgurant de l’IA générative et des grands modèles de langage. Cette nouvelle donne a nécessité la révision et l’ajout de certains éléments, tels qu’un nouveau chapitre (5) entièrement consacré aux modèles d’IA à usage général, parmi lesquels on compte les grands modèles de langage. Quant à certaines sections, on peut se demander ce qu’elles viennent faire dans l’AI Act, notamment un système de “bacs à sable réglementaires de l’IA” (article 57) qui doit permettre aux régulateurs de faciliter l’innovation. Certains articles sont formulés de manière plutôt énigmatique, comme la section dédiée aux “organismes d’évaluation de la conformité notifiés” (article 29), qui ne sont ni plus ni moins que des auditeurs. Des voix critiques se font donc entendre, craignant que la somme de mesures qui en résulte ne débouche avant tout sur un véritable imbroglio.

AI Act – Fondamentaux

L’AI Act s’adresse aux développeurs et aux fournisseurs d’IA, et ce uniquement lorsqu’ils publient des systèmes d’IA et les mettent à la disposition de tiers. Tous les développements et tests internes préalables sont explicitement exemptés (article 2 §8). L’AI Act ne s’applique pas non plus aux activités personnelles auxquelles vous vous adonnez dans un contexte non professionnel (article 2 §10). De même, la recherche scientifique (article 2 §6) et les applications militaires (article 2 §3) ne sont pas concernées. Bien évidemment, cela ne signifie pas que tout est permis dans tous ces cas.
Il va de soi que d’autres législations existantes restent en vigueur. Les droits des citoyens étaient déjà protégés par l’article 22 du RGPD entre autres, tandis que la législation sur les droits d’auteur continue de protéger les auteurs.

Par ailleurs, la définition de l’IA utilisée est particulièrement large et empruntée à l’OCDE : en résumé, “un système IA […] déduit, à partir des entrées, la manière de générer des sorties […]” (article 3 + considérant 12). La quasi-totalité de l’apprentissage automatique entre dans ce cadre. Dans d’autres définitions, on lit parfois que l’IA comporte un aspect cognitif (quelque chose doit être “reconnu”), mais il n’en est pas fait mention ici. Il n’est pas non plus fait mention de techniques spécifiques : tout ce qui apprend de manière adaptative ou peut réagir de manière quelque peu autonome à l’environnement est presque toujours inclus. Il s’agit donc également des systèmes que vous connaissez depuis des années, sans vous rendre compte qu’ils reposent sur l’intelligence artificielle, tels que les filtres antispam, les recommandations sur les sites web, voire les prévisions météorologiques.

L’AI Act définit d’abord et surtout une liste de pratiques interdites (article 5), qui prendra effet dès le début de l’année 2025. Cette liste est exhaustive, ce qui signifie en principe que tout ce qui n’est pas explicitement interdit est autorisé (sauf dispositions contraires prévues par d’autres lois). Aussi est-il intéressant d’examiner ce qui figure et ce qui ne figure pas dans cette liste d’interdictions, ainsi que les dispositions supplémentaires qui s’y rapportent. On découvre ainsi que :

• §1(f) : L’interdiction de la reconnaissance des émotions ne mentionne que le lieu de travail et l’enseignement.
• §1(g) : L’interdiction des systèmes d’IA biométriques ne mentionne que la déduction automatique concernant la race, la sexualité, l’affiliation à une organisation syndicale, la religion, les convictions politiques et philosophiques.
• §1(e) : L’interdiction de la reconnaissance faciale ne concerne que les systèmes basés sur ce qu’on appelle “moissonnage non ciblé”.

Elle est donc plus nuancée qu’une liste d’interdictions générales, car le contexte et l’objectif interviennent également. La reconnaissance des émotions dans les jeux vidéo, par exemple, reste ainsi autorisée. Les considérants 15 à 17 précisent que l’IA biométrique reste autorisée pour la vérification d’identité et l’authentification. Parallèlement, des exceptions sont prévues entre autres pour l’assistance médicale et la lutte contre la criminalité, bien que ces exceptions soient soumises à un contrôle strict (article 5, §2-§7), y compris une liste des infractions pénales qui entrent en ligne de compte (annexe 2).

Les systèmes qui assurent la sécurité des utilisateurs ou qui sont énumérés à l’annexe 3 sont des systèmes à haut risque (article 6). Il s’agit principalement de systèmes susceptibles d’avoir un impact majeur sur les libertés, la vie, la carrière ou la santé d’un individu. Bien que cette section de l’AI Act n’entrera en vigueur qu’à l’été 2026, il convient de noter qu’il subsiste des lacunes à combler. Par exemple, la Commission doit encore fournir des lignes directrices précisant l’interprétation de cet article (article 6 §5) et se réserve le droit d’apporter des modifications même après coup (article 6 §6-§8, article 7).

AI Act – Obligations

Quiconque souhaite construire ou a construit un système à haut risque devra se conformer à une série d’obligations, qui doivent notamment permettre aux autorités compétentes d’intervenir en cas de non-respect. Les développeurs de systèmes à haut risque devront adopter certaines pratiques, notamment :

• Un système itératif de gestion des risques (article 9), qui doit permettre d’identifier et d’évaluer les risques et d’atténuer les abus potentiels à l’avance. Le texte est relativement peu concret : il parle de “risques raisonnablement prévisibles” et de “mesures appropriées” sans autre précision. Ceci fera donc encore l’objet de discussions, mais dans la pratique, on peut déjà aujourd’hui se contenter en partie des normes récemment élaborées à cette fin, telles que la norme ISO/IEC 42001. Étant entendu qu’elle n’est pas explicitement conçue pour la loi sur l’IA Act, des mesures supplémentaires peuvent s’imposer.
• La gestion de données de qualité (article 10), qui se résume en grande partie à la transparence sur l’origine, les limites, les marges d’erreur et la représentativité. L’utilisation de Data Sheets (fiches de données), dont c’est l’objectif, est devenue populaire dans le secteur au cours des dernières années.
• Fournir une documentation technique conforme aux exigences de l’annexe 4 (annexe 11 pour l’IA à usage général). Ceci est quelque peu analogue aux Model Cards (cartes modèles) que l’on peut trouver sur le HuggingFace Hub, bien que la Commission européenne ne se contente pas de listes cochées et exige plus de détails, y compris sur la surveillance et le contrôle pendant la durée de vie du système.
• L’enregistrement (article 12) ainsi que la transparence et la fourniture d’informations aux utilisateurs (article 13).
• Le contrôle humain pendant la durée de vie du système (article 14). Si l’article 22 du RGPD en faisait déjà un droit civil, l’AI Act impose aux développeurs de prendre les mesures nécessaires à cette fin. Par exemple, il devra toujours être possible d’ignorer, de remplacer ou d’arrêter le système d’IA (article 14 §4 (d-e)).
• Prendre des mesures “appropriées” en matière de cybersécurité, de robustesse et d’exactitude (article 15). Cet article reste lui aussi relativement vague à l’heure actuelle et fait référence à l’intention de la Commission de soutenir le développement des étalonnages nécessaires.

Quiconque publie, met à disposition, incorpore dans son propre produit, importe ou distribue un système à haut risque devra prendre des mesures similaires, notamment :

• Vérifier et prouver la conformité du système (article 16 §e-l, articles 40-47), établir une déclaration de conformité (annexe 5) et obtenir le marquage CE (article 48). 
• Utiliser un système de gestion de la qualité (article 17).
• Conserver la documentation nécessaire pendant 10 ans après la mise en service (article 18).
• Coopérer avec les autorités compétentes (article 21).
• Enregistrer le système (article 49) dans une base de données européenne dédiée (article 71).
• Désigner une personne de contact ou un représentant pour tout ce qui précède (article 22).
• Mettre en place la surveillance nécessaire et agir en cas de problème (article 26 §5 et articles 72-73), notamment en informant l’autorité compétente.

Par analogie avec l’analyse d’impact relative à la protection des données du RGPD, certaines organisations, dont toutes les autorités publiques et les organisations de service public, devront réaliser une analyse d’impact sur les droits fondamentaux (Fundamental Rights Impact Assessment ou FRIA) dont les résultats devront être communiqués aux régulateurs du marché compétents (article 27). L’AI Office européen est déjà chargé de développer les questionnaires automatisés nécessaires à l’acquittement de cette obligation (article 27 §5).

On en oublierait presque que la grande majorité des systèmes d’IA sont simplement des systèmes à faible risque. À cet égard, l’AI Act est assez succinct : ils doivent satisfaire à des exigences minimales de transparence uniquement pour des applications spécifiques (article 50). Ainsi, l’utilisateur final doit toujours savoir qu’il interagit avec un système d’IA, et les résultats générés artificiellement doivent être clairement identifiés comme tels. La mainmise redoutée sur l’ensemble de l’industrie de l’IA est donc toute relative.

IA à usage général

Le développement récent de l’IA générative à usage général pour le texte et les images a nécessité l’ajout d’une catégorie distincte de systèmes, à savoir l’IA à usage général. La Commission européenne considère que ce type d’IA, indépendamment d’un éventuel risque élevé en matière de droits civils, peut également présenter un risque systémique (article 51). Le bien-fondé ou non de cette position fait l’objet d’un débat acharné dans les cercles techniques et philosophiques, mais l’UE adopte une approche prudente et prévoit un bâton juridique.

La Commission européenne se donne la liberté de déterminer les systèmes qui présentent un tel risque (article 51 §1). Bien qu’elle affirme appliquer des critères objectifs pour ce faire (annexe 13), il n’y a pas de véritable formule. Néanmoins, l’article 51 §2 fixe étonnamment une limite très concrète, à savoir qu’à partir du moment où son entraînement requiert une puissance de calcul de 10²⁵ FLOPS, un modèle d’IA à usage général est par définition considéré comme présentant un risque systémique. Cela correspond approximativement à un temps d’entraînement d’un an sur un cluster de 4000 GPU de type Nvidia RTX4090 (avec une puissance de calcul de 82×10¹² FLOPS). Pour éviter que tout cela ne devienne obsolète demain, la Commission se réserve le droit d’adapter ces valeurs à l’avenir en fonction des évolutions du domaine (article 51 §3).

Outre les exigences minimales de l’article 50 et indépendamment de la classification des risques, l’IA à usage général est soumise à son propre ensemble d’exigences en matière de documentation technique (article 53, annexe 11), qui seront un peu élargies en présence d’un risque systémique (article 55). Les constructeurs de modèles d’IA à usage général sans risque systémique publiés sous licence libre sont exemptés de certaines obligations (article 53 §2, voir également les considérants 102 à 104) et ne sont pas non plus tenus de désigner une personne de contact ou un représentant (article 54 § 6).

AI Office (Bureau de l’IA)

L’AI Act devra également être appliqué. Un rôle majeur dans ce cadre sera joué par l’AI Office (Bureau de l’IA, article 64), qui devrait être à l’AI Act ce que le Contrôleur européen de la protection des données est au RGPD. L’AI Office est actuellement mis en place à grande vitesse, les premières dispositions entrant en vigueur début 2025. Outre la responsabilité de compléter une série d’articles en suspens de l’IA Act, l’AI Office se verra confier la compétence exclusive de la surveillance de l’IA à usage général (article 75).

En pratique, l’AI Office fera partie de la DG CONNECT, commencera avec 140 collaborateurs et sera dirigé par Lucilla Sioli. Il sera soutenu dans son fonctionnement par le Centre européen pour la transparence algorithmique (ECAT), un Comité AI (article 65), un forum consultatif des parties prenantes (article 67) et un groupe scientifique d’experts indépendants (article 68).

Des régulateurs doivent également être désignés au niveau national (article 70). Ils devront travailler en étroite collaboration avec l’AI Office de l’UE et avec les régulateurs industriels et sectoriels existants, qui aujourd’hui sont déjà responsables du marquage CE, par exemple. Aux Pays-Bas, l’Autoriteit Persoonsgegevens joue clairement un rôle de pionnier dans la mise sur pied d’une autorité néerlandaise de l’IA, qui sera probablement établie dans le giron de l’Autoriteit Persoonsgegevens. En Belgique, la situation reste calme, même si le temps presse. En effet, on ne peut pas non plus engager n’importe qui pour occuper ces fonctions assez spécialisées.

Conclusion

Il est important de retenir que l’AI Act n’impose aucune restriction aux systèmes d’IA à faible risque, à l’exception de l’IA à usage général qui requiert la transparence nécessaire. Ce n’est que pour les systèmes à risques élevés ou systémiques et mis en production qu’interviennent des exigences strictes et la nécessité de se conformer aux réglementations pertinentes. Même dans ce cas, de nombreuses mesures d’atténuation offrent une marge de manœuvre supplémentaire au développement interne, aux initiatives open source, à la science, à la défense, etc.

Dans une certaine mesure, l’AI Act se veut concret, par une énumération détaillée des attentes et la mention de diverses précisions dans les considérants et les annexes. Il y parvient en partie et devient ainsi assez technique, de sorte qu’un juge concerné devra apprendre ce que sont les FLOPS. Parallèlement, il subsiste de nombreuses lacunes à combler et il reste à voir où le nouvel AI Office placera la barre dans les futures Commissions. La possibilité de modifier ultérieurement l’IA Act a été envisagée ici et là. La version actuelle de l’IA Act ne sera donc certainement pas la dernière.

Enfin, en Belgique, il ne s’agit pas d’attendre trop longtemps pour désigner et organiser le(s) régulateur(s) national(aux) pour l’AI Act si l’on veut être un tant soit peu en phase avec le reste de l’Europe. Pour obtenir des outils pratiques qui peuvent, entre autres, vous aider à vous mettre en conformité, vous pouvez d’ores et déjà consulter la base de données du Kenniscentrum Data & Maatschappij. De nombreux autres documents y seront certainement publiés lorsque l’AI Act entrera effectivement en vigueur.

______________________

Cette contribution a été soumise par Joachim Ganseman, consultant IT chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

Noot: dit is een populariserend artikel over toekomstige regelgeving, gebaseerd op de officiële publicatie dd. 12/07/2024. Wend u steeds tot een jurist voor professioneel juridisch advies.

De Europese AI Act (in het Nederlands de verordening artificiële intelligentie) is een hoeksteen van een reeks grootschalige wetgevende initiatieven die de digitale economie in Europa in een gereguleerd framework moeten gieten. Ze is daarmee complementair met eerdere wetgeving die bepaalde aspecten van het AI-gebeuren beïnvloedt, zoals de GDPR (AVG), de Digital Services Act (DSA) en Digital Markets Act (DMA), de Data Act, de Data Governance Act, de CHIPS Act en de voorgestelde Cyber Resilience Act . Na lang onderhandelen werd de AI Act in maart 2024 goedgekeurd door het Europees parlement en in mei door de Europese raad. De publicatie in het Official Journal of the European Union, zeg maar het Europese Staatsblad, vond plaats op 12 juli 2024, waarna de eerste regels begin 2025 van kracht worden – zie ook deze tijdslijn.

GDPR bis?

De volledige (Engelstalige) tekst van de AI Act, inclusief alle voorbeschouwingen en bijlagen, is een fenomenale 144 bladzijden lang – gelukkig zijn er her en der al goede samenvattingen te vinden. Daarmee is ze bijna 2 keer langer dan de “slechts” 88 pagina’s tellende GDPR. Van die laatste is de impact enorm: elke organisatie die persoonsgegevens verwerkt – een personeelsadministratie of klantenbestand hebben is voldoende – kreeg te maken met DPO’s, verwerkingsregisters, en rechtsgronden voor gegevensverwerking. Elk land moest ook een Gegevensbeschermingsautoriteit opzetten met de bevoegdheid om inbreuken te beboeten.

De GDPR bracht ook heel wat onzekerheid met zich mee, met name door haar veelvuldig gebruik van termen die voor interpretatie vatbaar zijn (“appropriate”, “adequate”, “suitable”, “sufficient”, …). De nood om die opnieuw te concretiseren voor elke voorliggende zaak, is de voedingsbodem voor wat ondertussen een kleine juridische industrie kan genoemd worden. De AI Act poogt om iets meer houvast te geven, door een meer technische toer op te gaan. Zo bevat ze een lijst Annexen met praktische opsommingen over wat verwacht wordt als gevraagd wordt naar documentatie, conformiteit, transparantie e.d.

De AI Act begon met een compacter voorstel van 125 bladzijden (inclusief bijlagen). Tijdens de onderhandelingen zagen we echter de razendsnelle opkomst van generatieve AI en de Large Language Models. Dat noodzaakte om een en ander te herzien en toe te voegen, zoals een nieuw hoofdstuk (5) over General Purpose AI, waartoe LLMs gerekend kunnen worden. Van andere onderdelen kan men zich dan weer afvragen wat ze in de AI Act komen doen, zoals een systeem van “Regulatory Sandboxes” (Art.57) dat regulatoren moet toelaten om innovatie te faciliteren. Sommige artikels zijn wel erg cryptisch verwoord, zoals de sectie over “Notified Conformity Assessment Bodies” (Art.29), waarmee men eigenlijk gewoon auditors bedoelt. Er zijn dan ook kritische stemmen te horen, die vrezen dat de resulterende optelsom aan maatregelen vooral een ingewikkeld kluwen is geworden.

De AI Act – basics

De AI Act is gericht op AI-ontwikkelaars en -aanbieders, en dat eigenlijk pas zodra ze AI-systemen publiceren en ter beschikking stellen van derden. Alle in-house ontwikkeling en testing die daaraan vooraf gaat, is expliciet uitgezonderd (Art.2§8). De AI Act grijpt ook niet in op wat je persoonlijk in niet-professionele context doet (Art.2§10). Wetenschappelijk onderzoek (Art.2§6) en militaire toepassingen (Art.2§3) tellen ook niet mee. Dat betekent natuurlijk niet dat in al die gevallen alles mag: uiteraard blijft andere bestaande wetgeving gewoon van kracht. De rechten van burgers werden al beschermd door de GDPR met o.a. haar Art.22, en de auteursrechtenwetgeving blijft auteurs beschermen.

De gehanteerde definitie van AI is dan weer opvallend breed, en is geleend van de OESO: samengevat, “AI systems infer, from their input, how to generate outputs” (Art.3 + Overweging 12). Zowat alle machine learning valt daaronder. In andere definities leest men al eens dat er een cognitief aspect aan AI verbonden is (er moet iets “herkend” worden), maar daar is hier geen sprake van. Ook over specifieke technieken wordt met geen woord gerept: al wat adaptief leert of enigszins autonoom kan reageren op de omgeving, valt er haast altijd onder. Dit gaat dus ook over systemen die je al jarenlang kent, zonder er bij stil te staan dat er AI achter zit: spamfilters, aanbevelingen op websites, zelfs weersvoorspellingen.

De AI Act definieert eerst en vooral een lijst met verboden toepassingen (Art.5), die begin 2025 al van kracht zal worden. Deze lijst is een limitatieve opsomming, wat in principe ook betekent dat wat niet expliciet verboden is, toegelaten is (tenzij verhinderd door andere wetten). Het is daarom interessant om in detail te kijken wat wel en niet in die lijst staat, en met welke bijkomende bepalingen. Zo lezen we:

• §1(f): Het verbod op emotieherkenning vermeldt enkel de werkvloer en het onderwijs,
• §1(g): Het verbod op biometrische AI-systemen vermeldt enkel de automatische afleiding van ras, seksualiteit, vakbondslidmaatschap, religie, politieke en filosofische overtuiging,
• §1(e): Het verbod op gezichtsherkenning heeft het enkel over systemen op basis van “untargeted scraping”,

Het is genuanceerder dan een lijstje algemene verbodsbepalingen, want ook context en doel spelen een rol. Emotieherkenning in bijvoorbeeld computergames blijft op die manier dus toegelaten. Overwegingen 15-17 preciseren dat biometrische AI toegelaten blijft voor identiteitsverificatie en authenticatie. Daarnaast zijn er ook enkele uitzonderingen ingebouwd voor o.a. de medische hulpverlening en de criminaliteitsbestrijding – al worden die uitzonderingen wel onder een streng toezicht geplaatst (Art.5§2-§7), inclusief een lijst van criminaliteit die ervoor in aanmerking komt (Annex 2).

Systemen die instaan voor de veiligheid van gebruikers, of die opgesomd zijn in Annex 3, zijn hoogrisico-systemen (Art.6). Het gaat hierbij vooral om systemen die een grote impact kunnen hebben op iemands vrijheden, levensloop, carrière of gezondheid. Hoewel dit onderdeel van de AI Act pas in voege zal treden in de zomer van 2026, valt het op dat er nog verschillende gaten in te vullen zijn. Zo moet de Commissie nog met een reeks verduidelijkende richtlijnen komen voor de interpretatie van dit artikel (Art.6§5), en behoudt ze zich het recht voor om ook achteraf nog wijzigingen aan te brengen (Art.6§6-§8, Art.7).

AI Act – verplichtingen

Wie een hoogrisicosysteem wil bouwen of gebouwd heeft, zal aan een reeks verplichtingen moeten voldoen, die o.a. moeten toelaten dat de bevoegde autoriteiten kunnen ingrijpen als het ontspoort. Ontwikkelaars van hoogrisicosystemen zullen bepaalde praktijken moeten adopteren, waaronder:

• Een iteratief risicobeheerssysteem (Art.9), dat moet toelaten de risico’s te inventariseren, in te schatten, en potentieel misbruik op voorhand te mitigeren. Concreter dan dat wordt het niet gemaakt: de tekst spreekt van “reasonably foreseeable risks” en “appropriate measures” zonder verdere specificatie. Dit zal dus nog voor wat discussie zorgen, maar in de praktijk kan men zich vandaag al deels behelpen met standaarden die recent voor dit doel ontwikkeld zijn, zoals ISO/IEC 42001 – met dien verstande dat die niet expliciet voor de AI Act is gemaakt en bijkomende maatregelen nodig kunnen zijn.
• Kwalitatief databeheer (Art.10), wat er grotendeels op neerkomt dat er transparantie moet zijn over de oorsprong, beperkingen, foutenmarges en representativiteit. Het gebruik van “Data Sheets“, die dit beogen, was de laatste jaren in de sector sowieso al populair geworden.
• Het voorzien van technische documentatie volgens de vereisten in Annex 4 (Annex 11 voor General Purpose AI). Dit is enigszins analoog met de Model Cards zoals men die kan vinden op de HuggingFace Hub, al neemt de Europese Commissie geen genoegen met afgevinkte lijstjes en vraagt ze meer detail, onder andere over monitoring en controle tijdens de levensduur van het systeem.
• Het voorzien van logging (Art.12) en transparante informatievoorziening naar de gebruikers toe (Art.13)
• Menselijk overzicht tijdens de levensduur van het systeem (Art.14). Waar GDPR art.22 daar al een burgerrecht van maakte, verplicht de AI Act aan de ontwikkelaars om de nodige maatregelen daartoe te nemen. Er zal bijvoorbeeld altijd de mogelijkheid moeten zijn om het AI-systeem te negeren, te overrulen, of te stoppen (Art.14§4(d-e)).
• Het nemen van “appropriate” maatregelen inzake cybersecurity, robuustheid en accuraatheid (Art.15). Ook dit artikel blijft momenteel nog relatief vaag en verwijst naar de intentie van de Commissie om de ontwikkeling van de nodige benchmarks te ondersteunen.

Wie een hoogrisicosysteem publiceert, ter beschikking stelt, verwerkt in een eigen product, importeert of distribueert, zal gelijkaardige maatregelen moeten nemen, waaronder:

• De conformiteit van het systeem controleren en bewijzen (Art.16§e-l, Art. 40-47), een conformiteitsverklaring opstellen (Annex 5), en CE markering bekomen (Art.48)
• Een kwaliteitsmanagementsysteem benutten (Art.17)
• De nodige documentatie tot 10 jaar na ingebruikname bijhouden (Art.18)
• Samenwerken met de bevoegde autoriteiten (Art.21)
• Het systeem registreren (Art.49) in een speciaal daartoe opgezette EU database (Art.71)
• Voor al het bovenstaande een contactpersoon of vertegenwoordiger aanduiden (Art.22)
• De nodige monitoring opzetten en actie ondernemen wanneer het misloopt (Art.26§5, Art.72-73), waaronder het inlichten van de bevoegde autoriteit.

Naar analogie met Gegevensbeschermingseffectbeoordeling (Data Protection Impact Assessment – DPIA) uit de GDPR, zullen sommige organisaties, waaronder alle overheidsinstanties en organisaties van publieke dienstverlening, een Fundamental Rights Impact Assessment of FRIA moeten uitvoeren, waarvan de resultaten aan de bevoegde marktregulatoren meegedeeld moeten worden (Art. 27). Het Europese AI Office krijgt alvast de taak om voor deze verplichting de nodige geautomatiseerde vragenlijsten te ontwikkelen (Art. 27§5).

Men zou bijna vergeten dat verreweg de meeste AI-systemen gewoon laag-risico systemen zijn. Daarover is de AI Act vrij kort: die moet enkel voor specifieke toepassingen voldoen aan minimale transparantievereisten (Art.50). Zo moet de eindgebruiker altijd weten wanneer die met een AI-systeem interageert, en moet artificieel gegenereerde output duidelijk als dusdanig gemarkeerd worden. Met die gevreesde wurggreep rond de gehele AI-industrie valt het dus eigenlijk best wel mee.

General purpose AI

De recente ontwikkeling van algemeen inzetbare generatieve AI voor tekst en afbeeldingen noopte tot de toevoeging van een aparte categorie aan systemen: General Purpose AI (GPAI). De Europese Commissie is van mening dat dit soort AI, onafhankelijk van een eventueel hoog risico inzake burgerrechten, ook een systemisch risico met zich mee kan brengen (Art.51). Of dat gegrond is of niet, is in zowel technische als filosofische kringen onderwerp van fel debat, maar de EU neemt het zekere voor het onzekere en voorziet een juridische stok achter de deur.

De Commissie geeft zichzelf de vrijheid om te beslissen welke systemen zo’n risico manifesteren (Art.51§1). Hoewel ze zich voorneemt daarvoor objectieve criteria te benutten (Annex 13), is er geen vaste formule. Of toch: er is verrassend genoeg 1 opvallend concrete grenswaarde vastgelegd in Art.51§2: vanaf dat de training 10²⁵ FLOPs aan rekenkracht vergt, wordt een GPAI per definitie aanzien als systemisch risicovol. Dit komt ongeveer overeen met een trainingstijd van 1 jaar op een cluster van 4000 GPUs van het type Nvidia RTX4090 (met 82*10¹² FLOPs aan rekenkracht). Om te vermijden dat dit alles morgen al achterhaald is, behoudt de Commissie zich het recht voor om deze waarden in de toekomst aan te passen aan de evoluties in het domein (Art.51§3).

General Purpose AI wordt, naast de minimale vereisten van Art.50, en ongeacht de risicoclassificatie, onderworpen aan een eigen reeks technische documentatieverplichtingen (Art. 53, Annex 11), die nog wat uitgebreid worden wanneer een systemisch risico aanwezig is (Art. 55). Bouwers van GPAI modellen zonder systemisch risico die onder vrije (¹) open-source licenties worden vrijgegeven, zijn van sommige verplichtingen uitgezonderd (Art.53§2, zie ook Overwegingen 102-104), en hoeven ook geen contactpersoon of vertegenwoordiger aan te duiden (Art.54§6).

Het AI Office

De AI Act zal ook afgedwongen moeten worden. Een grote rol daarbij is weggelegd voor het Europese AI Office (NL: AI-bureau, Art.64), dat voor de AI Act moet zijn wat de European Data Protection Supervisor is voor de GDPR. Het AI Office wordt momenteel aan sneltempo in de steigers gezet, want begin 2025 treden de eerste bepalingen in voege. Naast de verantwoordelijkheid om nog een reeks openstaande onderdelen van de AI Act in te vullen, zal ze ook exclusief bevoegd worden voor het toezicht op General Purpose AI (Art.75).

Het AI Office wordt in de praktijk onderdeel van DG CONNECT, zal van start gaan met 140 medewerkers en geleid worden door Lucilla Sioli. Het zal voor haar werking ondersteund worden door het Centrum voor Algoritmische Transparantie (ECAT), een AI Board (Art.65), een adviserend forum van belanghebbenden (Art.67), en een panel van onafhankelijke wetenschappers (Art.68).

Ook nationaal moeten er regulatoren worden aangeduid (Art.70). Deze zullen nauw moeten samenwerken met het EU AI Office en met de reeds bestaande industriële en sectorale regulatoren, die bijvoorbeeld vandaag al voor CE-markeringen bevoegd zijn. In Nederland speelt de Autoriteit Persoonsgegevens een duidelijke voortrekkersrol in de uitwerking van een Nederlandse AI-autoriteit, die daar waarschijnlijk in de schoot van de Autoriteit Persoonsgegevens zal worden opgericht. In België blijft het ondertussen stil, hoewel de tijd dringt – je kan immers ook niet eender wie aanwerven om die vrij gespecialiseerde rollen in te vullen.

Conclusie

Het is belangrijk om te onthouden dat de AI Act geen beperkingen oplegt aan AI-systemen die weinig risico inhouden – met uitzondering van General Purpose AI waarvan de nodige transparantie wordt gevraagd. Alleen voor systemen die hoge of systemische risico’s met zich meebrengen en in productie worden gezet, komen er strikte vereisten en de noodzaak tot conformiteit met relevante reguleringen. Ook dan zijn er heel wat verzachtende maatregelen die de interne ontwikkeling, open source initiatieven, wetenschap, defensie enz. extra ademruimte geven.

Tot op zekere hoogte probeert de AI Act concreet te zijn, door in detail op te sommen wat er verwacht wordt en een resem verduidelijkingen in de Overwegingen en Annexen op te nemen. Ze slaagt daar deels in en wordt zo nogal technisch – een betrokken rechter zal moeten leren wat FLOPs zijn. Tegelijk zijn er nog heel wat gaten in te vullen, waarbij het afwachten wordt waar het nieuwe AI Office onder toekomstige Commissies de lat zal leggen. Op verschillende plekken werd de mogelijkheid voorzien om de AI Act later te amenderen. De huidige versie van de AI Act zal dus zeker niet de laatste zijn.

Tenslotte mogen we in België zeker niet te lang meer wachten met het aanduiden en organiseren van de nationale toezichthouder(s) voor de AI Act, als we enigszins mee willen zijn met de rest van Europa. Voor praktische tools die o.a. kunnen helpen om conform te zijn, kan je vandaag al zoeken in de database van het Kenniscentrum Data & Maatschappij. Daar zal zeker nog veel meer materiaal verschijnen eens de AI Act effectief in werking treedt.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

1. In de ontwerptekst was het Engelse “free” oorspronkelijk foutief vertaald als “gratis”. In de publicatie in het Official Journal is deze vertaalfout alsnog gecorrigeerd en staat er “vrij”. ︎

Wat is blockchain?

Een blockchain is een steeds aangroeiende gegevensstructuur. Het is een sequentie van blokken, zoals een logboek, waarbij het netwerk met een vaste frequentie nieuwe blokken creëert en ze achteraan de blockchain toevoegt. Voor Bitcoin is die frequentie bijvoorbeeld een kleine 10 minuten. Het meest recente blok bevat bijgevolg de meest recente informatie. Heel wat deelnemers op het blockchain-netwerk houden lokaal een kopie van de blockchain bij en dragen bij aan de veilige en correcte werking van het geheel, zelfs wanneer een deel van het netwerk malafide is. Essentieel in een blockchain-netwerk is het consensusmechanisme. Dat zorgt ervoor dat alle deelnemers over exact dezelfde versie van de blockchain beschikken.

Om bitcoins te transfereren naar Alice, zal Bob met zijn geheime sleutel een transactie creëren die alle nodige informatie bevat. Die transactie zal Bob publiceren op het Bitcoin-netwerk. Enkel indien ze geldig is, aanvaardt het netwerk de transactie, die dan achteraan de blockchain terechtkomt. Een geldige transactie betekent onder meer dat Bob geen bitcoins transfereert die hij niet, of niet meer, bezit. We geven ter volledigheid nog mee dat Bob en Alice op de blockchain niet onder hun echte namen gekend zijn, maar onder pseudoniemen die niet zomaar aan hen gelinkt kunnen worden.

Een blockchain-transactie hoeft niet per se een financiële transfer te bevatten. Het kan om het even welke data bevatten, waardoor de technologie ook voor andere toepassingen gebruikt kan worden. Enkele typische voorbeelden zijn de transfer van vastgoed zonder vertrouwde partij, het registreren van alle stappen in de toeleveringsketen bij de productie van een wagen, of de registratie van diploma’s.

Blockchain & Audit

Data in de blockchain hebben een aantal eigenschappen, die vanuit een audit-standpunt interessant zijn. De integriteit van de data is cryptografisch beschermd. Met andere woorden zijn we er zeker van dat niemand de data gewijzigd heeft of kan wijzigen. Ook het verwijderen van de data uit de blockchain is onmogelijk. Tot slot heeft elk blok een onwijzigbare datumstempel (timestamp), en aangezien elke transactie zich in één specifiek blok bevindt, weten we dus bij benadering wanneer de transactie op het blockchain-netwerk gepubliceerd werd.

Publieke blockchain-netwerken zoals Bitcoin zijn doorgaans volledig transparant. Iedereen kan de correctheid van de blockchain nagaan. Iedereen kan verifiëren dat er geen data gewijzigd of verwijderd werden. Iedereen kan nagaan wanneer een transactie in de blockchain aanvaard is. En iedereen kan de geldigheid van elke transactie checken. Bovendien bevat de Bitcoin-blockchain de volledige historiek van alle bitcoins. Iedereen kan dus bekijken welke weg een bitcoin afgelegd heeft vanaf zijn creatie tot de meeste recente transactie.

Zoals gezegd kan een transactie ook andere dan financiële informatie bevatten. Telkens wanneer een huis van eigenaar verandert, kan een transactie in een blockchain-netwerk gepubliceerd worden. Zo hebben we dus de volledige historiek van het vastgoed en kan de huidige eigenaar ook bewijzen dat hij de rechtmatige eigenaar is. Of voor elk medisch record dat gecreëerd wordt, kan een unieke fingerprint (hash) op de blockchain geregistreerd worden. Zo kan een wijziging of ontbreken van een medisch record in een patiëntendossier gedetecteerd worden en hebben we een bewijs van het moment van creatie van het record. Een derde en laatste voorbeeld is supply chain management. Elke entiteit betrokken in de toeleveringsketen voor de creatie van een product, registreert in de blockchain welk onderdeel het wanneer en waar geproduceerd heeft. Zo heeft de koper transparantie in dit proces; Hij heeft heel wat informatie over de geschiedenis van het product. Dit alles is dus mogelijk zonder centrale vertrouwde partij.

Blockchain-technologie combineert dus twee moeilijk te combineren eigenschappen: er is enerzijds niet langer nood aan een vertrouwde centrale partij, en anderzijds zit alle relevante informatie samen in één, fraude-resistente blockchain. Dit laatste maakt het een stuk makkelijker om een audit te doen. Data afkomstig van verschillende bronnen hoeft niet langer, in verschillende formaten, gecombineerd en vergeleken te worden door de auditor. Niet alleen garandeert de blockchain-technologie de correctheid en volledigheid van de data. Het dwingt ook een eenvormigheid – zeg maar standaardisatie – van de data af.

Smart contracts

Elke transactie moet aan een aantal voorwaarden voldoen voordat het door het bitcoin-netwerk aanvaard wordt in de blockchain. Dit zijn Bitcoin-specifieke regels die zijn ingebakken in de Bitcoin-toepassing. Daardoor zijn de mogelijkheden om het Bitcoin-netwerk in andere domeinen te gebruiken eerder beperkt.

Blockchain technologieën die ‘smart contracts’ ondersteunen, zoals Ethereum en Hyperledger, brengen daar verandering in. Op een applicatie-agnostisch blockchain-netwerk kunnen gebruikers applicatie-specifieke code publiceren onder de vorm van een smart contract. Deze code zal doorgaans een vertaling zijn van business-regels. Dankzij de blockchain technologie kunnen we erop vertrouwen dat deze code op een correcte manier gedistribueerd wordt uitgevoerd door het netwerk, en daarmee worden ook de business-regels op een correcte manier afgedwongen.

Laat ons kijken naar een concreet voorbeeld; een smart contract voor een veiling. Iedereen op het netwerk kan vragen aan het smart contract om een bod te registreren, wat gebeurt door het aanroepen van een functie in het contract. Het geboden bedrag wordt daarbij onmiddellijk getransfereerd naar en geblokkeerd door het contract. Het smart contract aanvaardt enkel biedingen die hoger zijn dan het vorige bod. Wanneer het smart contract vervolgens dit hogere bod registreert, betaalt het ook direct de vorige bieder terug. Dit zijn twee voorbeelden van business-regels die in het smart contract in code uitgedrukt zijn.

Om een bod te plaatsen ondertekent de bieder met zijn of haar private sleutel een set van informatie: over welk smart contract gaat het, welke functie wordt opgeroepen, en welk bedrag wordt daarbij naar het smart contract getransfereerd? Deze ondertekende data is eveneens een transactie die door de bieder op het netwerk geplaatst wordt en daarna op de blockchain terechtkomt. Vervolgens wordt de functie door het netwerk correct uitgevoerd, waardoor het bod geregistreerd wordt.

Wat voor een auditor interessant is in dit verhaal, is dat hij dankzij smart contracts er steeds op kan vertrouwen dat de code – die business logica bevat – correct uitgevoerd werd. Als hij toegang heeft tot de relevante transacties in de blockchain kan de auditor met zekerheid weten wanneer welke functie uitgevoerd werd en welk effect dit had. Hij kan dus m.a.w. de volledige geschiedenis van het smart contract opnieuw afspelen, zonder enige twijfel over de correctheid of volledigheid ervan.

Enterprise context

Publieke blockchain-netwerken zoals Bitcoin en Ethereum zijn extreem open en transparant. Iedereen kan transacties publiceren en de volledige inhoud van de blockchain zien. En in het geval van Ethereum kan iedereen dus smart contracts publiceren en smart contract functies aanroepen. Het Bitcoin-netwerk en het Ethereum-netwerk zijn daarmee de gekendste voorbeelden van wat we een unpermissioned of ook wel permissionless blockchain-netwerk noemen. Het vertrouwen in dergelijke netwerken is gedistribueerd over duizenden nodes over de hele wereld.

Hoewel een dergelijke openheid zeer nuttig kan zijn, is soms meer controle wenselijk. Bijvoorbeeld wanneer concurrerende banken gebruik willen maken van een gedeelde blockchain voor de registratie van inter-bank overschrijvingen. De rest van de wereld hoeft zich hier niet in te moeien. Blockchain-technologieën die dergelijke controle toelaten worden permissioned genoemd en hebben een extra laag voor toegangscontrole. Zo kan de mogelijkheid om een bepaalde contractfunctie op te roepen worden beperkt tot een bepaalde groep deelnemers. Sommige technologieën laten bovendien toe om veel beter zowel de privacy van betrokken burgers als de confidentialiteit van bedrijfsgegevens te beschermen. Zo kunnen bijvoorbeeld smart contracts en de gerelateerde transacties geëncrypteerd worden zodat enkel een selecte groep de inhoud kan zien.

Audit kan in dit geval een onmogelijke opdracht lijken. Gelukkig kan de toegangscontrolelaag aan de auditor de mogelijkheid bieden om bijvoorbeeld alle transacties van een bepaalde gebruiker te kunnen zien, of om bepaalde informatie in bepaalde transacties te kunnen lezen.

Conclusie

De blockchain-technologie is nog in volle ontwikkeling. Zo is bijvoorbeeld de audit functionaliteit in de huidige permissioned blockchain technologieën nog beperkt. De blockchain technologie kent ook nog een aantal uitdagingen. Zo is het bijvoorbeeld noodzakelijk dat de geheime sleutel van elke deelnemer voldoende beschermd wordt tegen verlies en diefstal, wat dramatische gevolgen kan hebben.

Voor een auditor is blockchain in elk geval een veelbelovende technologie. De technologie kan heel wat garanties bieden, zonder dat daarbij een centrale partij vertrouwd moet worden. Zo kan de auditor erop vertrouwen dat de historiek in de blockchain volledig en correct is en dat business-regels gerespecteerd werden. Bovendien is het niet langer nodig om meerdere gegevenssets met elkaar te gaan vergelijken. Als auditor volgt u dus misschien toch maar beter de evoluties.