lunedì 6 luglio 2026
Law & Technology: dove il diritto e la tecnologia convergono
mercoledì 17 giugno 2026
Approvato l'AI Digital Omnibus
Se ne parlava da tempo ed è stato approvato dal Parlamento Europeo il 16 Giugno 2026, con ampia maggioranza.
Quali sono le maggiori implicazioni?
- Per i sistemi AI integrati in prodotti soggetti a normativa di sicurezza (Allegato I), i relativi obblighi slittano al 2 agosto 2028.
- Per i sistemi High-Risk AI (Allegato III), l’applicazione degli obblighi slitta al 2 dicembre 2027.
Il Digital Omnibus equivale a concedere mesi aggiuntivi per sviluppare:
- Processi di conformità
- Data governance
- Documentazione tecnica
- Sistemi di logging
- Monitoraggio post-market
Il rinvio è stato interpreatato in diversi modi.
Alcuni hanno ipotizzato la necessità di "ammorbidire" l'AI Act per non generare "eccessive frizioni" (potenziali) con i maggiori attori che producono le tecnologie AI.
In realtà, il rinvio è stato necessario perché gli standard armonizzati europei a supporto dell’AI Act sono ancora in fase di sviluppo.
Gli standard armonizzati forniscono riferimenti certi ad imprese e organismi notificati per implementare operativamente gli obblighi dell'AI Act.
Tuttavia va sottolineato che il rinvio non rappresenta una sospensione della governance. L’Europa modifica il calendario degli obblighi, non modifica l’architettura dell’AI Act.
Nuove pratiche vietate
- Sistemi per la produzione di materiale di abuso sessuale minorile.
- Sistemi per generare contenuti sessualmente espliciti di persone identificabili senza consenso.
Vengono poi rinviati al 2 Dicembre 2026 gli obblighi su:
- Watermarking
- Marcatura e rilevabilità dei contenuti sintetici
Questo avrà implicazioni per i provider di modelli generativi, che dovranno fornire soluzioni robuste per il tracciamento e l'autenticazione dei contenuti.
Cosa resta invariato
Nulla cambia per:
- Classificazione del rischio.
- Obblighi documentali.
- Sorveglianza post-market.
- Trasparenza e responsabilità dei fornitori.
Ora tutte le aziende e le organizzazioni coinvolte avranno più tempo per costruire sistemi di gestione dei dati e auditing a supporto dell'implementazione dell'AI Act.
Un'ultima nota: NON FATE CONFUSIONE tra standard armonizzati e altri standard di adozione volontaria.
Ad esempo, lo standard ISO/IEC 42001 è uno standard di adozione volontaria per la definzione dei requisiti necessari a stabilire, implementare e migliorare un Sistema di Gestione dell'Intelligenza Artificiale (AIMS). Il suo scopo è aiutare le organizzazioni a sviluppare e utilizzare l'Intelligenza Artificiale in modo responsabile, etico, sicuro e trasparentesaranno pronte; le altre avranno solo rimandato il problema.
Ma lo standard ISO/IEC 42001 NON E' UNO STANDARD ARMONIZZATO.
Solo l'adozione degli standard armonizzati vi assicurano la conformità con l'AI Act.
Gli standard armonizzati sono prodotti dal CEN-CENELEC, che coordina centinaia di esperti europei dei diversi settori normativi.
L'ISO/IEC 42001 è un ottimo contenitore di buone pratiche e, in attesa degli standard armonizzati, può essere un gran punto di partenza.
Altre risorse utili:
A presto!
Leggi questo articolo...giovedì 1 gennaio 2026
Sei un Comunicatore Tecnico? Fai un auto-test delle tue competenze
Questo mio primo post del 2026 è ispirato ad un post scritto recentemente da Steev Kundukulangara su Linkedin.
Steev ha proposto questo diagramma in cui sono elencate le competenze, organizzate per domini concentrici, che oggi deve avere un comunicatore tecnico:
FOUNDATION
Nella cerchia più interno ci sono le competenze "di base", quelle che fino agli anni 90 del secolo scorso erano più che sufficienti per identificare un professionista della scrittura tecnica. Come ho sempre sostenuto, per fare lo scrittore tecnico bisogna basicamente "saper scrivere". Tali competenze sono assolutamente necessarie, ma non sufficienti, perchè la scrittura tecnica è "un processo" (vedi gli standard IEC/IEEE 82079-1:2019 e ISO/IEC/IEEE 26514:2022).
DOCUMENT DEVELOPMENT LIFE CYCLE (DDLC)
Gli elementi essenziali che definiscono "il processo" di sviluppo della documentazione trovano una collocazione nella seconda cerchia, dove iniziamo ad isolare alcune fasi fondamentali del processo. Queste competenze possono essere supportate da altri standard (oltre all'82079-1 e al 26514) quali ad esempio:
- ISO/IEC/IEEE 26513:2017 per supportare la Quality Assurance.
- ISO/IEC/IEEE 26515:2018 per la gestione dei processi AGILE.
ADVANCED CONTENTS & TOOLS
La gestione del processo di documentazione richiede l'utilizzo di strumenti specifici per la gestione ed il riuso dei contenuti. I Component Content Management System (vedi lo standard ISO/IEC/IEEE 26531:2023) sono lo strumento principale per governare il processo di sviluppo della documentazione tecnica.
Altri strumenti utili, ma non indicati nel diagramma, sono i Learning Management System (LMS) ed i Computer Aided Translation Tools (CAT Tools). Tutti questi strumenti sono indispensabili per governare la redazione e l'aggiornamento dei contenuti: vi posso assicurare che ancora oggi ci sono aziende che ignorano tali strumenti o li utilizzano in modo inefficace.
INFORMATION ARCHITECTURE (IA) & USER EXPERIENCE
Qui arriviamo "al cuore" della professione, in una visione moderna della stessa: "l'Ingegneria dei Contenuti" in molti casi deve arrivare PRIMA e deve essere prevalente rispetto alla SCRITTURA.
Su questo concetto sto "martellando" la vostra attenzione da molti anni, spesso entrando in conflitto con colleghi "più tradizionalisti" che sostenevano che i manauli dovessero essere scritti con un focus specifico sulla lingua e la terminologia.
Come vedete dal diagramma, il governo della lingua e della terminologia sono compresi nella cerchia più interna: in qualche modo, sono "banali", nel senso che vanno dati per scontati e acquisiti. Anche l'annosa questione dei cosiddetti "linguaggi controllati" va considerata ormai una questione "di retroguardia": non è lì che si vince la battaglia della modernità.
Specialmente nell'era degli LLM e della AI Generativa, LA STRUTTURA delle informazioni (e in questo senso, standard tecnici come DITA e S1000D possono avere un ruolo dominante) e le meta-informazioni associate (il TAGGING), sono la base da cui partire per definire il dominio delle informazioni associate al prodotto.
Nel definire "l'Ingegneria dei Contenuti" i CCMS, gli LMS e i CAT Tools vi aiutano a gestire le varie fasi del processo e a "tenere insieme le cose" ma da soli non risolvono il problema: siete voi che dovete definire le relazioni che "legano" i vostri contenuti.
E se sarete in grado di farlo, l'AI vi potrà aiutare ulteriormente a far emergere relazioni "implicite" nella vostra architettura. Con l'AI potete anche velocizzare la fase di TAGGING, ma la vostra supervisione e la padronanzadegli strumenti non è sostituibile.
FUTURE & INNOVATION
Qui arriviamo nel dominio dell'AI, dei Knowledge Graphs, dei Chatbot.
Tutta roba che fallirà miseramente se non avete fatto "i compiti a casa", cioè se non avete costruito un Ingegneria dei Contenuti solida. Tutti i "fuffa Guru dell'AI", che trovate su Linkedin e che vi promettono soluzioni miracolose, vi stanno mentendo. Come faccio a dirlo?
- Perchè sulla gestione e costruzione dei contenuti ne so più di loro.
- Perchè io non vi devo vendere nessuna soluzione miracolosa.
- Perchè quando vi descrivono la loro soluzione miracolosa, non fanno cenno alla "fatica" che bisogna fare per definire una corretta gestione dei contenuti.
martedì 23 dicembre 2025
Vi segnalo la rivista STANDARD
Un breve messaggio di servizio per tutti coloro che sono sensibili all'osservanza degli standard (e coloro che non lo sono, farebbero bene a cambiare idea): la UNI pubblica STANDARD, una rivista che vi tiene aggiornati sull'evoluzione della normazione in diversi campi.
In particolare, nel numero di Dicembre, vi segnalo un articolo di Valentina Grazia Sapuppo sull'AI Act.
Valentina ormai è uno dei miei maggiori punti di riferimento nell'ambito della normazione e vi consiglio di seguirla, perchè i suoi contenuti sono sempre brillanti e "densi" di spunti che vi possono aprire una nuova visuale.
Leggi questo articolo...venerdì 17 ottobre 2025
La Single Information Platform sull'AI Act
Voglio ringraziare Andrea Broglia per aver segnalato questa piattaforma che la Commissione Europea ha appena lanciato: la Single Information Platform sull'AI Act.
Qui potete trovare degli utili strumenti per orientarvi all'interno dell'AI Act.
Nei mesi scorsi ho scritto una serie di articoli sul tema, con un particolare focus sugli obblighi di documentazione tecnica che le aziende devono affrontare quando adottano l'AI all'interno dei loro servizi e prodotti.
E mi sono espresso chiaramente sulla difficoltà di "navigare" tra i principi dell'AI Act, che è il primo regolamento al mondo (ma molti altri si sono aggiunti in seguito) che ha cercato di definire delle regole d'ingaggio per l'adozione di una tecnologia sicuramente potente e quindi rischiosa.
Questa piattaforma può essere un aiuto prezioso.
Ad esempio, andando nelle FAQ, potete isolare tutti i principali aspetti che possono riguardare il termine "documentation":
Poi potete usare l'AI Act Explorer (anche in Italiano), uno strumento che permette di navigare il testo per capitoli e allegati.
E' disponibile anche un Compliance Checker (in versione beta) che non sostituisce il lavoro di uno studio legale. ma vi può dare una prima idea di quanto le vostre inziative siano conformi all'AI Act.
In generale, uno strumento utile per prendere confidenza con una materia non semplice, ma che col passare del tempo imporrà obblighi sempre più cogenti.
Nel frattempo, aspettiamo gli standard armonizzati.
A presto.
Leggi questo articolo...lunedì 14 luglio 2025
The General-Purpose AI Code of Practice
La Commissione europea ha ricevuto ufficialmente il Codice di Condotta Generale sull'Intelligenza Artificiale.
Il quadro completo, sviluppato attraverso un processo multi-stakeholder che ha coinvolto quasi 1.000 partecipanti, stabilisce linee guida volontarie per i fornitori di modelli di intelligenza artificiale (AI) in vista dei requisiti di conformità obbligatori che entreranno in vigore il 2 agosto 2025.
E' un primo step, in attesa degli standard armonizzati, per capire come orientarsi.
E' un codice di adoziona volontaria, esattamente come gli standard ISO già presenti e disponibili.
Qui e qui altri 2 link sullo stesso tema, ma che approcciano il tema con un angolo diverso.
Come sapete, ho iniziato di analizzare l'EU AI Act dal punto di vista degli obblighi di documentazione tecnica che il regolamento impone, e non vi ho nascosto la mia opinione su alcune criticità (qui l'ultimo post sull'analisi dell'allegato IV).
Ora mi prendo il tempo di leggere le raccomandazioni indicate in questo Codice di Condotta e poi ne parleremo ancora.
Aldilà delle manovre che tenderebbero a ritardare l'applicazione dell'AI Act, ad oggi è quanto di meglio abbiamo per tentare di governare una rivoluzione tecnologica densa di potenzialità ma anche di insidie.
Non fatevi prendere in giro dai "fuffa-marketer" che prefigurano un futuro in cui l'AI risolverà ogni problema "auto-magicamente".
Bisognerà valutare ogni passaggio con attenzione, non esistono pasti gratis in natura, e nemmeno in questo caso.
A presto.
Leggi questo articolo...domenica 16 marzo 2025
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.
domenica 2 marzo 2025
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:
- Il comportamento di un sistema AI (di QUALSIASI sistema AI) dipende dai dati che gli vengono forniti in ingresso, e la dipendenza è NON DETERMINISTICA.
- 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...lunedì 24 febbraio 2025
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.
domenica 9 febbraio 2025
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...mercoledì 5 febbraio 2025
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.
domenica 2 febbraio 2025
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.
E non è finita qui... al prossimo post!
Leggi questo articolo...domenica 26 gennaio 2025
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.
- Rischio inaccettabile: I sistemi di IA che presentano rischi inaccettabili sono vietati.
- Rischio alto: i sistemi ad alto rischio sono soggetti a requisiti normativi rigorosi.
- Rischio limitato: i sistemi di questa categoria sono soggetti a specifici obblighi di trasparenza.
- 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...mercoledì 15 gennaio 2025
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!
venerdì 15 novembre 2024
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...lunedì 4 novembre 2024
Tre giorni a Roma con i colleghi del ISO/IEC JTC 1/SC 7/WG 2 - System Software Documentation
Dal 22 al 24 Ottobre si è tenuta a Roma la riunione dell’SC7/WG2, di cui faccio parte da alcuni anni rappresentando l’Italia come esperto UNINFO.
Siamo stati ospitati negli uffici della CLARITER che ci ha messo a disposizione la sua sala riunioni magnificamente attrezzata.
La CLARITER è una società che collabora attivamente ai processi di standardizzazione della ISO grazie all’operato di alcuni suoi membri, primo fra tutti Agostino Peloso, che ricopre il ruolo di Chief Operating Officer .
Molti membri del WG2 hanno partecipato da remoto, ma a Roma eravamo in 5: JoAnn Hackos, Annette Reilly, Shuwen Li, Daryil Colchoun e il sottoscritto.
Al netto del grande lavoro svolto in 3 giorni (l’agenda era estremamente densa, ma abbiamo chiuso con successo tutti i punti previsti), ho vissuto una grande esperienza di condivisone “dal vivo” con questi straordinari colleghi.
Collaboro con loro nel WG2 dal 2019, ma avevo partecipato a questi meeting sempre da remoto (ricordate gli anni del COVID?). Questa volta ho avuto modo di entrare in contatto con loro più direttamente e profondamente.
Averli a cena a casa mia, condividere tempo, cibo e il buon vino australiano gentilmente regalato da Daryl, parlare delle nostre famiglie, scoprire la passione di Daryl e Annette per l’Opera, parlare con Shuwen Li dei suoi progetti futuri, scoprire che la famiglia di origine di JoAnn è pugliese come quella di mia moglie, e molte altre piccolo cose... tutto questo (e altro ancora) è stato per me un regalo prezioso.
Quando ho iniziato la mia carriera nel campo della Comunicazione Tecnica, JoAnn è stata uno dei miei maggiori punti di riferimento.
Il suo libro “MANAGING YOUR DOCUMENTATION PROJECT” è una specie di “Bibbia del comunicatore tecnico”, che ogni professionista che fa questo lavoro dovrebbe avere sulla propria scrivania, e che è stato il mio “libro delle soluzioni” quando non sapevo come affrontare certi problemi.
Da questo libro e dagli altri che JoAnn ha scritto è partito il lavoro di standardizzazione che, nel corso di alcuni anni, ha portato alla definizione dei 5 standard principali del gruppo ISO/IEC/IEEE 265XX:
A questi 5 standard se ne stanno per aggiungere altri 2, ma non vi posso disvelare altro, ne parleremo quando saranno pubblicati.
Se oggi possiamo fare questa professione utlizzando processi collaudati, criteri affidabili e strategie efficaci, lo dobbiamo al grande lavoro di JoAnn.
JoAnn ha messo nero su bianco le sue esperienze nei libri che ha scritto, e poi ha condotto i processi di standardizzazione del SC7/WG2, con l’aiuto prezioso di tanti esperti che hanno collaborato con lei.
Se volete una lista completa degli standard inerenti alla documentazione dei prodotti software, potete aprire il primo link di questo post.
Aggiungo che nella prima giornata è intervenuto anche Domenico Natale, uno dei maggiori esperti UNINFO, molto attivo nell’ambito dell’SC7/WG6 (standard relativi alla qualità del software e dei dati) e nel comitato UNI/CT 533 sull’Intelligenza Artificiale.
Domenico ci ha illustrato l’attività di mapping tra i principi presenti nell’EU AI Act e le buone pratiche già definite in diversi standard della ISO.
Per maggiori dettagli, rimando al seguente articolo pubblicato su Economy.
Nell’ambito dell’EU AI Act, ci sono moltissimi riferimenti alla documentazione di prodotti, servizi e processi, che devono essere attentamente valutati:
• dalle aziende che si apprestano ad integrare l’AI nei propri prodotti e servizi
• dai comunicatori tecnici che devono essere pronti ad applicare i metodi e i processi propri della comunicazione tecnica in questi nuovi contesti
Prossimamente scriverò alcuni post su questo tema, proprio per far emergere i riferimenti più importanti.
Leggi questo articolo...giovedì 24 febbraio 2022
Spiegare lo standard ISO/IEEE/IEC 26514:2022 agli studenti dell'Università Rennes 2
Il prossimo 3 Marzo sarò ospite dell'Università Rennes 2.
Nell'ambito del Master's degree in Technical Communication, Project Management, Terminology and Translation, illustrerò agli studenti le caratteristiche della nuova versione dello standard ISO/IEEE/IEC 26514:2022, che è stato recentemente rilasciato nel mese di Gennaio.
Sono contento di aver dato il mio contributo all'innovazione di questo standard, sia come rappresentate UNI per l'Italia in seno alla JTC 1/SC 7/WG 2 Committee, sia come membro dell'ABLS della tekom EUROPE.
Ringrazio Katell Hernandez Morin e Nolwenn Kerzreho per l'invito, in un luogo dove tanti altri illustri colleghi hanno offerto il loro contributo sulle tematiche più avanzate della Comunicazione Tecnica.
E ringrazio la mia azienda PTV SISTeMA (PTV Group) per il supporto.
Lo standard 26514 fa parte del gruppo degli standars ISO 265XX, che identificano le best practice nella produzione delle informazoni per l'uso dei prodotti software e nella definizione e gestione di tutti i processi associati.
Per me sarà una bella esperienza, e spero anche per gli studenti!
Leggi questo articolo...domenica 23 gennaio 2022
E' stata pubblicata la nuova versione dello standard ISO/IEC/IEEE 26514:2022
Come vi avevo preannunciato alla fine di Novembre, è ora disponibile la nuova versione dello standard ISO/IEC/IEEE 26514:2022.
Tale standard è il principale standard di riferimento per la produzione delle informazioni per l'uso di un prodotto software.
Una prima osservazione: come nello standard ISO 82079, che è lo standard orizzontale di riferimento per qualsiasi tipo di prodotto (e quindi anche per i prodotti software), anche qui scompare il concetto di "documentazione/documento/manuale" ma si parla di "informazioni per l'uso/per gli utenti".
Può sembrare una banalità formale, in realtà è una conquista concettuale ottenuta dopo anni di dibattito: non esistono più i "documenti" o i "manuali", cioè i "contenitori" in cui vengono organizzate le informazioni, ma esistono fondamentalmente "le informazioni".
Il focus deve essere sulle "informazioni" ed eventualmente sui meta-dati che sono associati alle informazioni; le informazioni devono essere "modulari", di granularità abbastanza fine, devono essere i nostri "mattoncini Lego" che possiamo profilare e assemblare nei modi più opportuni in diversi contenitori, che sono ciò che chiamiamo "documenti".
Ma i documenti sono solo l'output di un processo.
Spesso tali contenitori non assumono più nemmeno una forma cartacea, ma rimangono prevalentemente in forma digitale.
Come sapete, anche il nuovo Regolamento Macchine (ancora in via di definizione) si sta orientando in tal senso, dando finalmente più spazio e libertà alla definizione delle informazioni in formato elettronico/digitale.
Ma ritorniamo allo standard 26514.
Il nuovo standard è organizzato in 64 pagine, meno della metà della versione precedente (2008, 143 pagine).
Sono state eliminate molte inutili sovrapposizioni con altri standard che nel frattempo si sono evoluti e consolidati, facendo esplicito riferimento a tali standard quando un argomento, presente nella vecchia versione 26514:2008, era meglio delineato nello standard specifico.
Molti i riferimenti allo standard 82079 ma anche agli altri standard del blocco 265xx; attraverso tali riferimenti è stato possibile "tagliare" le parti ridondanti e che potevano creare fraintendimenti.
Lo standard è sostanzialmente suddiviso in due parti.
PRIMA PARTE - Gestione del processo di sviluppo delle informazioni (Cap. 5 e 6)
Qui ci sono tutti gli aspetti di Project Management e Information Architecture applicate allo sviluppo delle informazioni. In particolare, il Cap. 6 può essere preso come punto di riferimento per la gestione del "processo redazionale" che può essere applicabile a TUTTI I TIPI DI PRODOTTO, quindi non solo ai prodotti software.
Nella precedente versione questi concetti erano diluiti in 5 capitoli (5,6,7,8,9), rendendo oggettivamente un poco troppo pesante lo sviluppo dell'argomento.
ATTENZIONE per tutti coloro che, specialmente negli ultimi due anni di pandemia, hanno scoperto la necessità di DIGITALIZZARE I PROCESSI AZIENDALI... perché non sarete mai in grado di digitalizzare nessun processo se prima non digitalizzate i vostri contenuti!
E per digitalizzare i contenuti avete bisogno di un'Architettura delle Informazioni.
Il Cap. 6 di questo standard vi fornisce le linee guida per indirizzare questo lavoro. I principi espressi si possono usare non solo per la gestione delle informazioni di uno specifico prodotto software ma, ad esempio, anche nel caso in cui vogliate strutturare una Knowledge Base aziendale.
SECONDA PARTE - Definizione delle informazioni (Cap. 7, 8, 9)
Qui trovate molte novità.
Il Cap 7. fornisce le linee guida per definire la Qualità delle informazioni; nel precedente standard questi concetti erano citati e spezzettati in diversi capitoli, ma qui è stato fatto uno sforzo di sintesi per fornire i riferimenti essenziali di base su un argomento rispetto al quale si dibatte da almeno 30 anni.
Nel Cap. 8 trovate le linee guida sulla strutturazione delle informazioni.
Inoltre trovate alcuni nuovi contenuti, completamente assenti nella versione precedente.
Ad esempio, come definire le informazioni relative alle API (vi ho già parlato dell'importanza delle API nelle moderne architetture software, presto ritorneremo a parlarne), o l'analogo per quanto riguarda i Chatbot.
Nel Cap. 9 un'estesa trattazione sui formati che potete definire per confezionare le informazioni.
Poi ci sono 2 appendici, relative agli aspetti generali più propriamente linguistici e di traduzione delle informazioni per l'uso. Ovviamente non si entra nel dettaglio perché ci sono altri standard su questi argomenti, ma si forniscono alcuni principi generali che non bisogna mai dimenticare.
A mio parere è stato fatto un gran lavoro, che si è sviluppato nell'arco di circa 30 mesi.
Sono contento di aver dato il mio contributo all'innovazione di questo standard, sia come rappresentate per l'Italia in seno alla JTC 1/SC 7/WG 2 Committee, sia come membro dell'ABLS della tekom EUROPE.
A presto!


