Impatto dell'AI Act sulla documentazione di processi/servizi/prodotti AI-based: articolo 11

Abbiamo già visto che gli articoli 8,9 e 72 dell’AI Act (AIA) danno indicazioni importanti rispetto agli obblighi di produzione della documentazione tecnica che deve accompagnare un sistema AI ad alto rischio.

Riprendendo la parte finale del post precedente, sono emerse le seguenti necessità:

• Produrre della documentazione specifica ed aggiuntiva relativa al sistema AI integrato nel nostto processo/servizio/prodotto.
• Produrre della documentazione d’integrazione laddove il sistema AI vada a modificare funzioni pre-esistenti (e quindi già documentate).
• Definire un sistema di valutazione dei rischi relativi all’integrazione del sistema AI e documentare il sistema stesso.
• Definire anche un sistema di analisi post-vendita per migliorare il sistema di valutazione dei rischi; la documentazione del sistema di monitoraggio post-vendita è parte integrante della documentazione indicata nell’allegato IV.
• Aggiornare il sistema di valutazione dei rischi lungo l’intero ciclo di vita del medesimo e, implicitamente, aggiornare la documentazione relativa.
• Definire quali sono i rischi “ragionevolmente”prevedibili e, qualora non eliminabili, fornire documentazione adatta alla eliminazione o mitigazione di questi rischi.

Queste indicazioni emergono all’interno di articoli che non sono specificamente dedicati alla documentazione tecnica, mentre oggi ci focalizziamo sull’articolo 11 che è il primo articolo dedicato “esplicitamente” a questo aspetto.

Per la formulazione esatta dell’Articolo 11, vi rimando all’AIA.

Nell’articolo 11 si evidenzia, principalmente:

• Che la documentazione tecnica di processo/servizio/prodotto che integra un sistema AI ad alto rischio va definita prima di immettere sul mercato il suddetto processo/servizio/prodotto e va mantenuta costantemente aggiornata (11.1).
• Che i contenuti da inserire nella documentazione sono almeno tutti quelli indicati nell’Allegato IV e che le “Small-Medium Enterprises (SMEs)” possono adempiere a questo compito in un formato “semplificato”, che sarà stabilito dalla Commissione Europea (11.1).
• Se il sistema AI ad alto rischio viene integrato in una delle aree tecnologiche elencate nell’Allegato I, viene redatta un’unica documentazione tecnica contenente tutte le informazioni indicate in 11.1 nonchè la informazioni implicate dall’Allegato I (11.2).
• La Commissione Europea, in corrispondenza all’evoluzione tecnica, si riserva (vedi Articolo 97) di modificare l’Allegato IV ogni qualvolta sarà necessario (11.3).

Il legislatore mi perdonerà se sottolineo l’irritante “vaghezza” di questo articolo.

In questa sede si stabiliscono i PRINCIPI GENERALI e dobbiamo aspettare le linee guida e poi gli standard armonizzati.

Ma in questo articolo non c’è scritto veramente NULLA DI UTILE, che non sia men che ovvio. Mi sono sembrati molto più chiari gli articoli 8,9 e 72.

Ma andiamo a vedere cosa viene specificato nell’Allegato 4, a cui l’articolo 11 rimanda.

ALLEGATO IV

Technical documentation referred to in Article 11(1)

The technical documentation referred to in Article 11(1) shall contain at least the following information, as applicable to the relevant AI system:

IV.1

• A general description of the AI system including:
• (a) its intended purpose, the name of the provider and the version of the system reflecting its relation to previous versions;
• (b) how the AI system interacts with, or can be used to interact with, hardware or software, including with other AI systems, that are not part of the AI system itself, where applicable;
• (c) the versions of relevant software or firmware, and any requirements related to version updates;
• (d) the description of all the forms in which the AI system is placed on the market or put into service, such as software packages embedded into hardware, downloads, or APIs;
• (e) the description of the hardware on which the AI system is intended to run;
• (f) where the AI system is a component of products, photographs or illustrations showing external features, the marking and internal layout of those products;
• (g) a basic description of the user-interface provided to the deployer;
• (h) instructions for use for the deployer, and a basic description of the user-interface provided to the deployer, where applicable;

IV.2

• A detailed description of the elements of the AI system and of the process for its development, including:
• (a) the methods and steps performed for the development of the AI system, including, where relevant, recourse to pre-trained systems or tools provided by third parties and how those were used, integrated or modified by the provider;
• (b) the design specifications of the system, namely the general logic of the AI system and of the algorithms; the key design choices including the rationale and assumptions made, including with regard to persons or groups of persons in respect of who, the system is intended to be used; the main classification choices; what the system is designed to optimise for, and the relevance of the different parameters; the description of the expected output and output quality of the system; the decisions about any possible trade-off made regarding the technical solutions adopted to comply with the requirements set out in Chapter III, Section 2;
• (c) the description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing; the computational resources used to develop, train, test and validate the AI system;
• (d) where relevant, the data requirements in terms of datasheets describing the training methodologies and techniques and the training data sets used, including a general description of these data sets, information about their provenance, scope and main characteristics; how the data was obtained and selected; labelling procedures (e.g. for supervised learning), data cleaning methodologies (e.g. outliers detection);
• (e) assessment of the human oversight measures needed in accordance with Article 14, including an assessment of the technical measures needed to facilitate the interpretation of the outputs of AI systems by the deployers, in accordance with Article 13(3), point (d);
• (f) where applicable, a detailed description of pre-determined changes to the AI system and its performance, together with all the relevant information related to the technical solutions adopted to ensure continuous compliance of the AI system with the relevant requirements set out in Chapter III, Section 2;
• (g) the validation and testing procedures used, including information about the validation and testing data used and their main characteristics; metrics used to measure accuracy, robustness and compliance with other relevant requirements set out in Chapter III, Section 2, as well as potentially discriminatory impacts; test logs and all test reports dated and signed by the responsible persons, including with regard to pre-determined changes as referred to under point (f);
• (h) cybersecurity measures put in place;

IV.3

Detailed information about the monitoring, functioning and control of the AI system, in particular with regard to: its capabilities and limitations in performance, including the degrees of accuracy for specific persons or groups of persons on which the system is intended to be used and the overall expected level of accuracy in relation to its intended purpose; the foreseeable unintended outcomes and sources of risks to health and safety, fundamental rights and discrimination in view of the intended purpose of the AI system; the human oversight measures needed in accordance with Article 14, including the technical measures put in place to facilitate the interpretation of the outputs of AI systems by the deployers; specifications on input data, as appropriate;

IV.4

A description of the appropriateness of the performance metrics for the specific AI system;

IV.5

A detailed description of the risk management system in accordance with Article 9;

IV.6

A description of relevant changes made by the provider to the system through its lifecycle;

IV.7

A list of the harmonised standards applied in full or in part the references of which have been published in the Official Journal of the European Union; where no such harmonised standards have been applied, a detailed description of the solutions adopted to meet the requirements set out in Chapter III, Section 2, including a list of other relevant standards and technical specifications applied;

IV.8

A copy of the EU declaration of conformity referred to in Article 47;

IV.9

A detailed description of the system in place to evaluate the AI system performance in the post-market phase in accordance with Article 72, including the post-market monitoring plan referred to in Article 72(3).

Avete la mia stessa sensazione?

L’Allegato 4 descrive TUTTO L’UNIVERSO della documentazione tecnica possibile e immaginabile, per qualsiasi tipo di area tecnologica dove si possa andare ad integrare un sistema di AI ad alto rischio.

Non credo che in futuro ci sarà un gran bisogno di modificare l’Allegato 4, perchè già contiene una larga “fenomenologia” di tutte le esigenze di documentazione tecnica ragionevolmente prevedibili.

A questo punto, vi rimando ai prossimi post per entrare un poco più in profondità nell'Allegato 4.

E vi anticipo 2 notizie, una BUONA e una CATTIVA.

NOTIZIA BUONA

Per me e per i miei colleghi si annuncia un future roseo.

Aprire il “vaso di Pandora” dell’Allegato 4 e definire tutta la documentazione necessaria per integrare un sistema AI ad alto rischio in un processo/servizio/prodotto aziendale, sarà il nostro “pane e burro” per molti anni.

NOTIZIA CATTIVA

L’Allegato 4 non è, a sua volta, particolarmente chiaro per molti aspetti. Quindi se l'Articolo 11 era estremamente vago, la mia speranza di trovare ogni risposta nell'Allegato IV è andata in parte delusa.

Ma ne riparleremo presto.

Leggi questo articolo...

Pubblicate 140 pagine di linee guida per l'articolo 5 dell'AI Act: Houston, abbiamo un problema...

Qui trovate le linee guida per l'applicazione dell'Art. 5 dell'EU AI Act.

Ho visto che ci sono alcune (poche) indicazioni inerenti alla documentazione tecnica coinvolta in alcuni aspetti, ma mi riservo una lettura più attenta.

Dico solo una cosa: se abbiamo bisogno di 140 pagine di linee guida per UN SOLO articolo... il cammino si fa molto più duro di quanto immaginavo... OKKIOOO!!!

E lo dico alle aziende, ovviamente.

A presto.

Leggi questo articolo...

Impatto dell'AI Act sulla documentazione di processi/servizi/prodotti AI-based: articoli 8,9 e 72

Nel post precedente abbiamo introdotto i concetti di base relativi ai “sistemi ad alto rischio” secondo la definizione dell’AI Act (AIA).

Ora proviamo ad analizzare quali sono gli obblighi di un’azienda che definisce un processo/servizio/prodotto contenente un sistema AI ad alto rischio, dal punto di vista della documentazione tecnica associata.

In primo luogo, gli articoli che definiscono i requisiti da soddisfare per i sistemi ad alto rischio sono quelli che vanno dall’articolo 8 all’articolo 15 (Sezione 2).

Tra questi articoli, l’articolo 11 è dedicato esplicitamente alla documentazione tecnica, ma anche in altri articoli ci sono indicazioni esplicite che ci interessano.

ARTICOLO 8

8.2

Where a product contains an AI system, to which the requirements of this Regulation as well as requirements of the Union harmonisation legislation listed in Section A of Annex I apply, providers shall be responsible for ensuring that their product is fully compliant with all applicable requirements under applicable Union harmonisation legislation. In ensuring the compliance of high-risk AI systems...

...providers shall have a choice of integrating, as appropriate, the necessary testing and reporting processes, information and documentation they provide with regard to their product into documentation and procedures that already exist and are required under the Union harmonisation legislation listed in Section A of Annex I.

L’articolo 8.2 ci dice che se integriamo un componente AI ad alto rischio, è nostra responsabilità integrare tutte le informazioni necessarie in aggiunta a quelle già previste, in base agli standard armonizzati eventualmente già esistenti per le aree elencate negli Allegati I e III.

Questo articolo ci dice chiaramente che dobbiamo produrre della documentazione AGGIUNTIVA e SPECIFICA, rispetto a quella che già forniamo.

Ma non solo: a mio avviso il concetto di INTEGRAZIONE va interpretato anche nel senso che, qualora il componente AI vada a modificare sostanzialmente il comportamento di una funzione pre-esistente del prodotto, anche la documentazione di quella funzione VA AGGIORNATA.

ESEMPIO

Facciamo l’esempio di un controllo di qualità basato sulle immagini di una videocamera che “fotografa” il prodotto che esce dalla linea di produzione (LINEA 1). Ipotizziamo che vi sia un AI che, sulla base delle immagini, prende decisioni autonome per scartare un singolo pezzo o inviarlo alla linea successiva (LINEA 2).

Questa integrazione, se classificata ad alto rischio, si presenta come funzione AGGIUNTIVA della linea e ovviamente va documentato tutto ciò che è relativo a tale funzione aggiuntiva.

Ma se invece l’AI non si limita a scartare un pezzo difettoso, ma va eventualmente anche a “riconfigurare” i parametri di produzione della LINEA 1 (controreazione della linea) per ottimizzare la produzione del singolo pezzo, allora questo comportamento potrebbe modificare nel tempo il comportamento della LINEA 1 (e in tal caso sarebbe da considerare un effetto voluto) che potrebbe comportare anche L’AGGIORNAMENTO della documentazione della LINEA 1.

L’esempio proposto è un esempio di pura fantasia, ma serve a far capire che un componente AI implica considerazioni relative:

• alla documentazione AGGIUNTIVA e SPECIFICA del componente AI
• ALL’AGGIORNAMENTO di parti/funzioni pre-esistenti del prodotto che possono essere influenzate dal sistema AI.

Nell’articolo 8.2  tocchiamo con mano il fatto che l’AIA ci dice COSA FARE ma non ci dice COME: ho già spiegato il perchè nel primo post di questa serie e  vedremo che questo tema sarà ricorrente.

ARTICOLO 9

9.1

A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems.

9.2

The risk management system shall be understood as a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating. It shall comprise the following steps:...

9.2.(c)

the evaluation of other risks possibly arising, based on the analysis of data gathered from the post-market monitoring system referred to in Article 72;

9.3

The risks referred to in this Article shall concern only those which may be reasonably mitigated or eliminated through the development or design of the high-risk AI system, or the provision of adequate technical information.

Fermiamoci qui.

L’articolo 9 si occupa di definire le policy per la gestione dei rischi legati all’utilizzo di un sistema AI ad alto rischio integrato all’interno di un processo/servizio/prodotto e stabilisce, sostanzialmente, che:

• Bisogna definire un sistema di gestione dei rischi, al fine di minimizzarli per quanto possibile.
• Che tale sistema, in se, va documentato (9.1) e deve essere iterativamente aggiornato durante il ciclo di vita del sistema AI (9.2). Ovviamente, mi permetto di asserire che anche l’eventuale documentazione va aggiornata, anche se non è scritto esplicitamente.
• Che deve esistere un analisi di post-vendita per una valutazione dei rischi eventualmente non considerati in precedenza e che le regole per tale attività sono indicate nell’articolo 72, il quale afferma:

72.1 

Providers shall establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system.

72.2 

The post-market monitoring system shall actively and systematically collect, document and analyse relevant data which may be provided by deployers or which may be collected through other sources on the performance of high-risk AI systems ...

72.3 

The post-market monitoring system shall be based on a post-market monitoring plan. The post-market monitoring plan shall be part of the technical documentation referred to in Annex IV...

•  Che i rischi “ragionevolmente prevedibili” devono essere mitigati o eliminati attraverso 2 attività:

a)      La progettazione del sistema AI, oppure...

b)      La fornitura di adeguata informazione tecnica

Per quest’ultima opzione b, osservo che non viene utilizzata esplicitamente la locuzione documentazione tecnica.

E’ una svista del legislatore? Non credo.

L’informazione tecnica potrebbe essere costituita da una sessione di training, da un video, da qualsiasi altra modalità, ma è evidente che il modo più comune di fornire tale informazione tecnica è legata alla documentazione di cui al punto 9.1.

Il punto b è molto potente e si ispira a quanto stabilito in altri Regolamenti e Direttive: il “rischio ragionevolmente prevedibile” può essere gestito anche dalla sola attività di documentazione.

Volendo sintetizzare le indicazioni dell’articolo 8, 9 e 72 (richiamato all’interno dell’articolo 9), possiamo a mio avviso ragionevolmente concludere  che se integriamo un sistema AI ad alto rischio dentro ad un nostro processo/servizio/prodotto, dobbiamo:

• Produrre della documentazione specifica ed aggiuntiva relativa al sistema AI integrato nel nostto processo/servizio/prodotto.
• Produrre della documentazione d’integrazione laddove il sistema AI vada a modificare funzioni pre-esistenti (e quindi già documentate).
• Definire un sistema di valutazione dei rischi relativi all’integrazione del sistema AI, e documentare il sistema stesso.
• Definire anche un sistema di analisi post-vendita per migliorare il sistema di valutazione dei rischi; la documentazione del sistema di monitoraggio post-vendita è parte integrante della documentazione indicata nell’allegato IV.
• Aggiornare il sistema di valutazione dei rischi lungo l’intero ciclo di vita del medesimo e, implicitamente, aggiornare la documentazione relativa.
• Definire quali sono i rischi “ragionevolmente”prevedibili e, qualora non eliminabili, fornire documentazione adatta alla eliminazione o mitigazione di questi rischi.

Ora capite perchè sostengo che le aziende debbano "metterci la testa" con ampio anticipo su tutto ciò che concerne i processi di documentazione indicati nell'AIA?

E non è finita qui... al prossimo post!

Leggi questo articolo...

Impatto dell'AI Act sulla documentazione di processi/servizi/prodotti AI-based: i sistemi ad alto rischio

Il primo articolo di questa serie lo trovate qui.

Qui invece trovate il testo dell'AI Act.

Oggi iniziamo ad esplorare l’EU AI Act (AIA) con un focus specifico relativo alla materia che ci interessa, cioè alla produzione della documentazione tecnica che deve accompagnare un processo/servizio/prodotto AI-based.

Uno dei pilastri dell’AIA è costituito dalla classificazione di 4 livelli di rischio associato ad un sistema AI.

1. Rischio inaccettabile: I sistemi di IA che presentano rischi inaccettabili sono vietati.
2. Rischio alto: i sistemi ad alto rischio sono soggetti a requisiti normativi rigorosi.
3. Rischio limitato: i sistemi di questa categoria sono soggetti a specifici obblighi di trasparenza.
4. Rischio minimo o nullo: sono sistemi che non hanno restrizioni normative ai sensi dell'AIA.

Escludiamo dalla nostra analisi i sistemi “proibiiti”, cioè quelli quelli del punto 1, che possono presentare una rischio inaccettabile e che in quanto tali non possono essere integrati in processi/servizi/prodotti che devono arrivare sul mercato.

Tali sistemi ricadono in primo luogo sotto le indicazioni dell’Articolo 5 dell’AI Act.

I divieti di cui all'articolo 5 si applicano a partire dal 2 febbraio 2025 e sono quindi le prime disposizioni a entrare in vigore.

Ma iniziamo invece a ragionare sui sistemi del punto 2, quelli ad alto rischio.

Quali sono questi sistemi?

Tutti quelli che sono definiti attraverso:

• Articolo 6
•  Articolo 7
• Allegati I e III

In particolare, si opera opera una distinzione tra due categorie di sistemi, regolamentati in modo diverso:

• Sistemi di AI utilizzati come prodotto o componente di sicurezza di un prodotto coperto dalla legislazione di armonizzazione dell'UE. In questa categoria (vedi allegato I per l’elenco completo) rientrano, tra le altre, aree come:
• Macchinari
• Giocattoli
• Aviazione civile
• Sicurezza dei veicoli
• Ascensori
• Dispositivi medici
• Dispositivi di protezione personale.

• Sistemi di AI elencati nell'Allegato III, e relativi all’articolo 6.2.Rientrano in questa categoria, ad esempio, i sistemi AI utilizzati:
• Come componente di sicurezza nelle infrastrutture critiche (reti di traffico stradale, reti elettriche, etc).
• Nell'applicazione della legge
• Nella gestione dell’immigrazione
• Nei sistemi di identificazione biometrica a distanza

Questo elenco potrà essere in futuro modificato dalla Commissione.

I sistemi ad alto rischio sono quelli che presentano i requisiti più stringenti nell'ambito della documentazione tecnica da fornire a corredo di processi/servizi/prodotti AI-based.

Ma inizieremo a parlarne nel prossimo articolo.

A presto.

Leggi questo articolo...

Impatto dell'AI Act sulla documentazione di processi/servizi/prodotti AI-based: una panoramica

Nel EU AI Act (AIA) ci sono moltissimi riferimenti alla documentazione tecnica che deve accompagnare un processo/servizio/prodotto integrato da funzionalità AI.

Ad esempio, il temine documentation è presente 124 volte, mentre il termine information è presente 268 volte.

Di seguito, una breve e incompleta statistica:

• documentation = 124 istanze
• information = 268 istanze
• instructions = 31 istanze
• instructions for use = 20 istanze
• technical documentation = 60 istanze
• report = 79 istanze

Questo vi da un’idea di quanto sia pervasivo il concetto “documentazione di processi/servizi/prodotti integrati con funzionalità AI”.

Le aziende che costruiranno processi/servizi/prodotti con funzionalità AI-based dovranno provvedere alla gestione di processi di documentazione tecnica molto efficienti:

• sia per scopi interni, cioè per informare ed istruire i propri dipendenti
• sia per i propri clienti, che utilizzeranno i suddetti processi/servizi/prodotti

In questo scenario dobbiamo aggiungere altri elementi che contribuiranno a definire vincoli ed obbighi in tal senso.

Ad esempio il Data Act (DA), che definisce i principi di gestione da implementare nell’uso dei dati.

I dati sono il carburante necessario per l’AI e quindi andrà verificato:

• quali vincoli potrebbero derivare dall’uso dei dati aziendali rispetto alle prescrizioni del DA
• se ci sono aree di sovrapposizione con i principi indicati nell’AIA

E anche il nuovo Regolamento Macchine (RM), che ha previsto lo scenario di macchine con software a bordo eventualmente integrato con funzionalità AI. 

Il RM indica i criteri per la documentazione delle macchine specifici del Regolamento, ma vanno verificate eventuali sinergie con i principi indicati nell'AIA.

Queste osservazioni vanno in un’univoca direzione: le aziende devono DA SUBITO mettere la testa su una materia che non potranno eludere, cioè la produzione, l’aggiornamento e la distribuzione di informazioni legate ai propri processi (prevalentemente per uso interno) e ai servizi/prodotti (prevalentemente rivolti ai clienti esterni) che integreranno funzionalità di AI.

Questo è il primo di una serie di articoli in cui cercherò di darvi delle informazioni utili in tal senso.

Ovviamente lo farò dal mio punto di vista, cioè dal punto di vista di un esperto dei processi e degli standard della comunicazione tecnica che potrebbero essere utili per implementare gli obblighi normativi.

Come sapete:

• I Regolamenti Europei (ad esempio, il Regolamento Macchine, l’AI Act, il Data Act, etc.) sono “leggi Europee” di applicabilità immediata (al netto di un eventuale periodo transitorio, in cui continua a valere ANCHE la normativa prcedente) e che non devono, come le Direttive Europee, essere “recepite” dagli stati nazionali.
• Gli standard ISO sono standard di adozione volontaria, che vengono sviluppati secondo un processo democratico da una comunità internazionale di esperti che rappresentano gli enti normativi nazionali, le associazioni professionali specifiche di ogni settore e le aziende che vogliono concorrere al processo di definizione degli standard.
• Gli “standard armonizzati” sono invece elaborati per fornire alle aziende gli strumenti necessari a rispettare le leggi Europee. Il New Legislative Framework (NLF) prevede che la legislazione definisca i requisiti essenziali che la tecnologia deve soddisfare, mentre le norme armonizzate, sviluppate dagli Enti di Normazione europei su richiesta della Commissione Europea, rendono operativi questi requisiti.

Un’azienda che dichiara di implementare lo standard armonizzato X, AUTO-DICHIARA di essere conforme ai vincoli indirizzati da tale standard (al netto di eventuali audit esterni che possono intervenire per verificarne l’effettiva conformità).

In attesa degli standard armonizzati, oggi potremmo iniziare a "testare" la capacità di un'azienda  nell'adottare i principi dell'AIA tenendo conto di quanto indicato negli standard ISO già disponibili. 

Sarebbe auspicabile che gli standard armonizzati tengano in conto quanto già definito negli standard ISO, proprio per ri-utilizzare un enorme volume di elaborazione intellettuale già ben formalizzata.

In tal senso, in ambito UNINFO è già in piedi un progetto i cui dettagli sono disponibili qui.

Se volete una panoramica completa dell'attività della commissione UNI/CT 533, potete scaricare questo file.

Stay tuned!

Leggi questo articolo...