Impatto dell'AI Act sulla documentazione di processi/servizi/prodotti AI-based: analisi dell'Allegato IV (parte seconda)

Andiamo avanti nell'analisi dell'Allegato IV dell'AI Act.

Ricordiamo che l'Art. 11 è uno degli articoli fondamentali dell'AI Act per quanto riguarda la documentazione tecnica che deve essere redatta per accompagnare un prodotto che integra un sistema AI ad alto rischio, ma l'Art. 11 è, di fatto, un articolo "contenitore" che rimanda all'Allegato IV.

Nel post precedente abbiamo parlato del IV.2, una delle sezioni più critiche dell'Allegato IV.

Ora fissiamo l'attenzione sul IV.3.

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

E' una prescrizione molto impegnativa.

Proviamo a tirare fuori "il succo".

Detailed information about the monitoring, functioning and control of the AI system

Di quale "livello di dettaglio" stiamo parlando?

Facciamo un esempio e parliamo di una soluzione basata sul Machine Learning: cosa dobbiamo dettagliare?

I dati che diamo in pasto al motore di ML? O "la struttura dei dati"? A volte i dati si acquistano da aziende che li raccolgono e li compongono nei modi più opportuni per determinati usi. Nei contratti d'acquisto dei dati ci sono anche dei vincoli di riservatezza rispetto alla loro divulgazione.

Quindi, il "livello di dettaglio" dovrebbe intendersi come il livello "intrinsecamente consentito" dai contratti di fornitura dei dati... O NO?

Oppure, oltre ai dati, dobbiamo documentare anche gli strumenti (ad esempio, le API) che utilizziamo per accedere ai dati?

Oppure dobbiamo documentare in che modo li persistiamo nel sistema che dovrà utilizzarli?

E se i dati sono acquisiti in tempo reale, attraverso un flusso continuo, da sistemi esterni?

E in tutto questo, dovremo eventualmente tener conto di ciò che prescrive il Data Act?

Vedete quante domande, solo inerentemente AD UN SINGOLO ASPETTO (i dati in ingresso) di una particolare soluzione di AI, il ML?

...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...

Qui invece la risposta è semplice: lo standard ISO 26514 ci fornisce i principi di Audience & Task Analysis (clause 6.2), che possiamo utilizzare a supporto di questa attività.

...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

Questo passaggio suona abbastanza simile al concetto di "rischio ragionevolmente prevedibile" per un sistema di AI (già ben noto, ad esempio, nella vecchia Direttiva Macchine). Ma anche qui, come va declinato il concetto di "intended purpose"?

Posso definire la "finalità prevista", ma posso assicurare che si mantenga tale per tutto il ciclo di vita del prodotto che ospita il sistema AI?

Immaginiamo una rete stradale, gestita da un sistema di semafori programmabili ed intelligenti, che possono auto-modificare la programmazione semaforica in base ai dati di traffico, con un sistema AI integrato che prende decisioni autonome "imparando" dai dati di traffico.

In questo caso, se la descrizione della "finalità prevista" dovesse includere (perchè devo fornire informazioni "dettagliate"... ricordate il primo capoverso?) anche la descrizione dei piani semaforici, è evidente che tali informazioni sarebbero valide SOLO ALL'INIZIO della messa in produzione del sistema. 

Nel "day-by-day", i piani semaforici potrebbero cambiare.

A quel punto che facciamo? Alleghiamo alla documentazione, giorno per giorno, i piani semaforici via via aggiornati dall'AI? E' una soluzione ragionevole? In base alla prescrizione dell'Art. 72.2, sembrerebbe proprio questa la soluzione. 

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 ...

Come vedete, ogni passaggio necessita di attente valutazioni.

...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

E qui un altro passaggio fondamentale: le misure di supervisione umana, in accordo all'Art. 14.

Il concetto generale è abbastanza "gassoso": l'attività di supervisione umana è sicuramente necessaria ma occorrono criteri più "solidi" per poter disegnare questa attività. Nella stessa prescrizione è presente un'indicazione più precisa: including the technical measures put in place to facilitate the interpretation of the outputs of AI systems by the deployers

Quindi si presuppone che vi siano "misure tecniche" in grado di "visualizzare" l'output del sistema AI e che possa abilitare "opportune azioni di controllo"? Questo è di fatto quanto definito proprio nell'Art. 14.

Come vedete, la complessità di questo IV.3 non è di molto inferiore al IV.2.

Pezzo per pezzo, cerchiamo di capire tutte gli aspetti che devono essere indirizzati per i nostri scopi.

Ma ribadisco: chi si sta occupando di definire gli standard armonizzati, deve fare un lavoro ENORME per dare la ricetta del COME vanno indirizzati tutti questi vincoli.

Leggi questo articolo...

Impatto dell'AI Act sulla documentazione di processi/servizi/prodotti AI-based: analisi dell'Allegato IV (parte prima)

Nel post del 9 Febbraio vi ho proposto il testo integrale dell'Allegato IV.

Ora provo a far emergere alcuni passaggi chiave, trascurando i passaggi più ovvi e sottolineando anche alcune "disordinate ridondanze", che di certo non aiutano la comprensione del lettore.

Nell'Allegato IV ci sono 9 articoli.

• IV.1 - Riguarda il "primo livello" di documentazione da associare al sistema AI ad alto rischio che vogliamo integrare nel nostro processo/servizio/prodotto
• IV.2 - Riguarda un "secondo livello" di documentazione, molto più dettagliato.
• IV.3 - Riguarda la documentazione delle attività di monitoring inerenti al sistema AI, anche in relazione a quanto stabilito dall'Articolo 14 (di cui ancora non abbiamo parlato).
• IV.4 - Riguarda la documentazione delle metriche di performance del sistema di AI.
• IV.5 - Riguarda la documentazione del sistema di gestione dei rischi associato al sistema AI.
• IV.6 - Riguarda la documentazione delle modifiche implementate dal fornitore del sistema AI durante il suo ciclo di vita.
• IV.7 - Riguarda l'elenco delle norme armonizzate applicate in tutto o in parte i cui riferimenti sono stati pubblicati nella Gazzetta ufficiale dell'Unione europea; se non sono state applicate tali norme armonizzate, una descrizione dettagliata delle soluzioni adottate per soddisfare i requisiti di cui al capitolo III, sezione 2, compreso un elenco di altre norme e specifiche tecniche pertinenti applicate.
• IV.8 - Riguarda la copia (che immagino vada inteso come allegato) della dichiarazione di conformità UE indicata nell'artcolo 47.
• IV.9 - Riguarda una descrizione dettagliata per valutare le prestazioni del sistema di IA nella fase successiva all'immissione sul mercato, in conformità all'articolo 72, compreso il piano di monitoraggio 72.3.

AVETE CAPITO BENE?

Allora, proviamo a procedere con quel sano senso di pragmatismo che mi è congeniale.

LA ROBA FACILE (quella che si capisce ed è abbastanza semplice da fare)

Direi sicuramente l'articolo IV.1 (anche se il IV.1.g ed il IV.1.h sono inerenti allo stesso concetto e mi sembra che qui il legislatore sia incorso in un'inutile ridondanza che potrà essere emendata in futuro).

Anche gli articoli IV.5, IV.6, IV.7 e IV.8 sono abbastanza chiari rispetto al COSA DEVO FARE e si possono indirizzare abbastanza agevolmente, a patto di disporre di processi e metodologie collaudati.

LA ROBA DIFFICILE (che si capisce poco o che può essere affrontata con grandi difficoltà)

Calma e gesso, e procediamo punto per punto.

IV.2

Iniziamo con il IV.2.a ed il IV.2.b, citando il testo originale integrale:

• (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;

Stiamo scherzando vero?

Cioè se io voglio integrare nel mio prodotto un sistema AI ad alto rischio, il fornitore a cui mi rivolgo mi deve fornire informazioni che, sostanzialmente, sono informazioni DI PROGETTAZIONE del sistema AI? Quindi il fornitore deve investire per produrre un sistema AI e poi deve rivelare al mondo TUTTI I DETTAGLI di progettazione del sistema?

Allora, questi 2 articoli significano solo una cosa: che il sistema AI che voglio integrare DEVE ESSERE un sistema Open Source. Perchè, in caso contrario, mi risulta molto difficile immaginare di poter applicare le suddette prescrizioni. 

Se qualcuno non è d'accordo, accetto obiezioni.

Peraltro c'è un passaggio specifico molto "criptico": 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;

Cosa si intende per "any possible trade-off"? A me non è chiaro. Ma andiamo avanti.

Per quanto riguarda IV.2.c e IV.2.d:

• (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);

..siamo in un ambito più gestibile, perchè se parliamo dell'architettura generale del sistema, dei dati usati per il training, della loro provenienza e delle metodologie di training e data cleaning, siamo dentro un perimetro metodologico che va documentato e tale richiesta è da ritenersi del tutto logica.

L'unico punto realmente "oscuro" si racchiude in una parolina apparentemente innocua: "test"!

the computational resources used to develop, train, test and validate the AI system;

Ad oggi, non esistono metodologie standardizzate e tanto meno "scientifiche" per il test di un sistema AI.

Questo dato è ben noto a tutti coloro che almeno una volta nella vita hanno progettato un chatbot basato sulla AI generativa.

In ogni punto dell'AI Act in cui troverete delle prescrizioni relative "al test del sistema AI", sappiate che state per aprire il vaso di Pandora.

Se dovessi fare una richiesta pressante a coloro che scriveranno gli standard armonizzati a sostegno dell'AI Act, direi che questo punto dovrebbe essere in cima alla lista.

Nessun sistema AI, e sottolineo NESSUNO, può essere testato con i criteri che applichiamo oggi al test dei prodotti software. E questo accade per 2 motivi banali:

1. Il comportamento di un sistema AI (di QUALSIASI sistema AI) dipende dai dati che gli vengono forniti in ingresso, e la dipendenza è NON DETERMINISTICA.
2. Un sistema AI può imparare e quindi, a distanza di tempo, lo stesso input può produrre risultati diversi.

Rispolverando i miei studi di Ingegneria, il punto 1 potrebbe essere riformulato dicendo che la funzione di trasferimento di un sistema AI è variabile e la sua variabilità è non nota. Mentre il punto 2 è una caratteristica intrinseca e molto desiderabile di un sistema AI.

Ad oggi, nell'ambito del gruppo degli standard dell'area ISO 42000, il cui capostipite è lo standard 42001, è in via di sviluppo uno standard specifico per il test dei sistemi AI-based. Ma ad oggi, testare un sistema AI è un'attività empirica, che si basa su alcune best practice; tuttavia, non disponiamo ancora di nessuno standard.

A mio avviso, anche il IV.2.e (legato agli articoli 13 e 14, di cui parleremo nei prossimi giorni) è associabile all'attività di test del sistema, quando esplicitamente viene indicato:

including an assessment of the technical measures needed to facilitate the interpretation of the outputs of AI systems

Ma è l'articolo IV.2.g che è quello ESPLICITAMENTE dedicato all'attività di test:

• (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);

Come vedete, anche questo articolo non è nemmeno lontanamente risolutivo rispetto all'esigenza di un'azienda nel determinare il COME DEVO FARLO, ma indica solo il COSA DEVO FARE.

Peraltro, anche in modo abbastanza ridondante e confuso, visto che l'argometno "test" viene declinato in maniera diretta o indiretta attraverso IV.2.c, IV.2.d, IV.2.e, e soprattutto IV.2.g.

Infine, il IV.2.f che richiama i contenuti del IV.7 (anche qui, caro legislatore, siamo certi che non si potesse fare uno sforzo di maggiore chiarezza?):

• (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;

Un articolo che inizia con un cauto where applicable mette già in conto che certe prescrizioni non siano applicabili. Poi, vorrei essere rassicurato sul significato di questa frase:

to ensure continuous compliance of the AI system with the relevant requirements set out in Chapter III, Section 2;

Abbiamo detto che i sistemi AI, per loro natura, possono variare il proprio comportamento nel tempo, perchè sono "sistemi che imparano".

Quindi, posso forse garantire che il mio sistema abbia certe caratteristiche ORA ma faccio fatica a immaginare come poter esprimere la stessa garanzia nel futuro. Infatti, per questo motivo esiste l'attività di risk management, monitoring e controllo in fase di produzione, e armonizzazione (IV.3, IV.5, IV.6, e IV.7). 

Quindi perchè puntualizzare ancora questo elemento nel IV.2.f, salvo poi premettere un where applicable?

Come vi avevo scritto nel post del 9 Febbraio, l'Allegato IV non aveva risolto i miei dubbi che erano stati sollevati dalla lettura dell'Art. 11. 

E spero di avervi mostrato in questo post quanto meno i punti meno chiari del IV.2, che è una delle sezioni chiave dell'Allegato IV.

Il viaggio nell'AI Act non è finito, alla prossima tappa.

Leggi questo articolo...

Un articolo illuminante sull'AI Act e sugli standard armonizzati associati

Vi segnalo questo articolo di Piercosma Bisconti Lucidi e Daniele Nardi, che mette in luce alcune criticità dell'AI Act.

Come sa chi mi segue, sto analizzando l'AI Act dal punto di vista degli obblighi di produzione della documentazione tecnica che dovrà accompagnare i prodotti che integrano, al loro interno, sistemi AI.

Le mie prime perplessità sono confermate da questo articolo.

A presto per analizzare nei dettagli l'Allegato IV.

Leggi questo articolo...

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 IV, 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 modificarlo, 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 IV.

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 IV 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...

Prima bozza del General-Purpose AI Code of Practice

E' stata pubblicata la prima bozza del General-Purpose AI Code of Practice.

Questo documento nasce dalla collaborazione di numerosi esperti indipendenti e sarà presto discusso con circa 1000 stakeholder.

Il Codice di Condotta Generale sull'IA si pone l'obiettivo di facilitare la comprensione dell'AI Act con domande e risposte dedicate alle parti interessate.

Potete scaricare la bozza da qui.

Come vi ho segnalato, in UNINFO è già in piedi un'iniziativa italiana rivolta a produrre un mapping fra EU AI Act e le best practice già definite in ambito ISO.

Se volete approfondire vi segnalo questo link principale, all'interno del quale potete trovare molti altri link verso risorse che sono finalizzate a questo lavoro di mapping.

Io mi occuperò presto, in maniera specifica, dei numerosi riferimenti presenti nell'AI Act  relativi alla documentazione di prodotti, servizi e processi basati sull'AI, e scriverò alcuni articoli su questo blog.

Stay tuned!

Leggi questo articolo...

Pubblicato lo standard CEN/CLC/TR 18115:2024 - “Data Governance and Quality for AI within the European Context”

E' stato pubblicato lo standard CEN/CLC/TR 18115:2024 - “Data Governance and Quality for AI within the European Context”.

E' uno standard che fornisce una panoramica sugli standard relativi all'IA, con particolare attenzione ai dati e al ciclo di vita dei dati.

Lo standard è rivolto ad organizzazioni, agenzie, imprese, sviluppatori, università, ricercatori, gruppi di discussione, utenti e altre parti interessate.

In particolare, descrive i collegamenti tra i numerosi standard e regolamenti internazionali pubblicati o in fase di sviluppo, focalizzando le seguenti aree:

• Governance dei dati
• Qualità dei dati
• Elementi per i dati
• Proprietà dei data set
• Informazioni per i test

Per chi ha iniziato ad integrare alcuni aspetti della AI nei processi aziendali (Machine Learning, Generative AI, etc.) è assolutamente chiaro che uno dei primi problemi da affrontare sta nell'analisi della qualità dei dati.

Nella stragrande maggioranza dei casi, i dati che abbiamo già pronti in azienda NON SONO ADATTI ad essere integrati in nessun tipo di motore basato sulla IA.

Nei prossimi post tornerò su questo punto.

Per questo motivo sono utili gli standard: perchè suggeriscono buone pratiche che possono essere applicate in diversi contesti e per diversi business case.

Per ulteriori dettagli, ecco il post già pubblicato su Linkedin da CyberEthics Lab.

Un ringraziamento per questo risultato va indirizzato a tutti gli esperti che hanno collaborato ma in particolare a Domenico Natale, che è stato l'ispiratore dell'attività che ha condotto a questo standard.

Leggi questo articolo...