ForHumanity Italy incontra Luca Nannini

Buongiorno a tutti, eccoci a questo nuovo appuntamento di For Humanity Italy con i nostri

esperti e oggi abbiamo con noi Luca Nannini al quale chiedo prima di iniziare la nostra

conversazione di fare una self introduction, di presentarsi, lascio a lui l'honore e non

ripeto quello che ho già detto negli incontri precedenti ovvero For Humanity, stiamo facendo

questo progetto per For Humanity, in particolare For Humanity Italy che è il chapter italiano di

For Humanity ma poi insomma chi ha maggiore interesse può verificare su internet, abbiamo

una pagina dedicata a For Humanity Center Italy, può verificare lì i dati del progetto. Prego Luca,

una self introduction. Ok salve a tutti grazie all'avvocato Nicola Fabiano per l'invito e sì

allora sono Luca Nannini, sono un dottore in intelligenza artificiale esplicabile in

AI presso l'università di Santiago di Compostela e a livello professionale sono un AI policy and

standards senior specialist expert presso Piccadilly Labs per il progetto europeo Nolefa

che si occupa appunto di dare una mano alle autorità di sorveglianza del mercato,

le market surveillance authorities per l'implementazione dell'AI health per quanto

riguarda la parte 1 come coeditor e la parte 2 come editor. Lo standard di trustworthiness si

articola brevemente in pratica in dare diciamo strumenti per la presunzione of compliance per

esempio uno strumento che si chiama trustworthiness che è un strumento che si utilizza per dare

presunzione of conformity da articolo 12 ad articolo 13-14 e nella parte 2 articolo 15

dell'AI health in altre parole è uno standard che dovrà aiutare l'impresa europea e non solo

per l'AI health per quanto riguarda gli aspetti di logging, di transparency, human oversight e

parte 2 specificamente per accuracy e robustness. Benissimo benissimo grazie grazie Luca era

importante comunque far sapere a chi ci ascolta o a chi ci vede chi sono i nostri interlocutori e

di che cosa si occupano perché così si ha un quadro ancora un po' più chiaro del panorama

diciamo degli ospiti di questo progetto. Allora io ho qualche domanda per te Luca la prima domanda

è questa come si integrano gli standard CNCLEC con le IACT? Allora sì in pratica per rispondere

a questa domanda dobbiamo vedere un po' a livello olistico quello che è il mandato che è stato

inviato diciamo dalla commissione europea il mandato 593 che poi è stato credo in italiano

emendato ora correggimi Nicola aiuta mi è corretto come mandato M6113 nel 2025 l'anno

passato e in pratica in questo mandato si individuano 10 aree di standardizzazione per

questa richiesta per dare standard armonizzati per le IACT in pratica abbiamo 10 aree che

coprono da risk management, data governance and quality, record keeping, transparency, human

oversight, accuracy, robustness, cyber security ma anche aree per quanto riguarda il quality management

system incluso il post market monitoring e il conformity assessment. In pratica con queste 10

standardization areas della M6113 cosa è stato fatto? In CNCLEC abbiamo risposto a questa richiesta

sviluppando draft cioè quindi bozze di standard armonizzati che dovranno appunto dare per esempio

non conformity se una volta completati si saranno citati nel gazzettino ufficiale ecco l'official

journal of european union solo il termine in inglese magari in italiano a ranco e cosa è

successo specificamente? In CNCLEC e in GTC21 abbiamo deciso di sviluppare diversi standard

dove possiamo fare un mapping più o meno diretto per quanto riguarda le bozze correnti. In altre

parole abbiamo la standardization area numero 1 quella per risk management che dovrà essere

coperta dallo standard di AI risk management il PR IAN 18228. Per quanto riguarda quello di la data

in governance standardization area 2 avremmo il 18284 l'artificial intelligence quality and

governance of data sets in AI. Incluso anche per quanto riguarda l'aspetto di identificazione e

mitigazione dei bias il PR IAN 18283 quindi l'artificial intelligence concept measures and

requirements for managing bias e via discorrendo. Ecco da standardization area numero 3 fino alla

standardization area numero 7 quindi 5 aree che coprono da record keeping, transparency, human

oversight, accuracy and robustness. Queste saranno coperte da PR IAN 18229 che è appunto lo standard di

transformation che si articola in due parti. Parte 1 per logging, transparency, human oversight

quindi da standardization area 3 ad area 5 quindi articolo in altre parole 12 e 14 dell'AI

HECT 13 incluso e per quanto riguarda la parte 2 invece per standardization area 6 e 7 quindi 6

uracy 7 e robustness stiamo parlando di articolo 15 non specifico articolo 15 1 fino ad articolo

15 4 perché se andiamo a leggere l'articolo 15 5 ovvero sia siamo nel territorio della

cyber security area numero 8 avremo lo standard di cyber security specification

free I system che corrisponde diciamo al codice PRN 18282. Questo è quanto per quanto riguarda

gli standard forse quello più avanzato che non ho ancora menzionato standardization area 9

quality management system quindi standardization area numero 9 che in pratica trova risposta nel

quality management system standard che è il 18286 che ha terminato il ballot scusatemi l'inquiry

di recente settimana scorsa e adesso si trova in fase di comment resolutions per quanto riguarda

il periodo di febbraio quindi ecco la mappatura risponde un po' a questo a dare presumption

conformity per gli articoli se non mi sbaglio del capitolo 3 sezioni 2 quindi da articolo 9

ad articolo 15 delle AI-HECT con delle eccezioni quindi articolo 17 e anche 72. Bene bene grazie

grazie per questa accurata diciamo risposta queste precisazioni sono molto molto interessanti io

ritorno un attimo sul nostro progetto di For Humanity Italy che ha un titolo e si chiama

conversazioni su AI, etica e standard e ripeto trovate informazioni sulla home page del sito di

For Humanity Italy che è forhumanity.center.it. Altra domanda per te Luca quali sono secondo te

i gap principali tra teorie e pratica nelle metriche di accuracy? Allora qui entriamo nel

dello standard che appunto sto dirigendo come project leader che è appunto tra Swarf

e Nesparte 2 cioè quindi stiamo parlando dell'articolo di una standard che dovrà dare

presumption conformity ad articolo 15 e in pratica è molto interessante quello che stiamo facendo

ed è anche molto se vogliamo ecco non vorrei usare il termine difficile però molto intraprendente

ecco perché allora per quanto riguarda le metriche di accuracy cosa cosa viene richiesto? Quando si

parla di accuracy nelle IHECT magari c'è questa misconception comune per cui si associa il concetto

di accuracy a quello di statistical accuracy però non è quello che viene realmente inteso nelle IHECT

ovvero sia non stiamo parlando di un modello stiamo parlando di un sistema che semplificando

possiamo vedere come un conglomerato di modelli che possono assolvere più task per un intended

purpose finale quindi il concetto di statistical accuracy è semplicemente come si dice un

semplicemente uno strumento in un box di strumenti meccanici che possiamo utilizzare quindi quello

che stiamo facendo nello standard di accuracy in pratica è delineare delle procedure quanto più

verificabili per un auditor per la market surveillance authorities nell'altro caso e in

pratica queste procedure devono riconnettarsi, scusatemi, devono connettarsi ai principi

dell'articolo 8 dicendo sia dato che il sistema assolve a un intended purpose il sistema deve

essere performante deve essere performante per farlo dobbiamo in pratica capire come funziona

cioè in altre parole dobbiamo fare in modo che ci siano delle metriche che ci permettono di

misurarne la l'accuratezza a livello di sistema quindi in altre parole la performance rispetta

all'intended purpose non tutte le tasks dei modelli che compongono poi un sistema possono

essere giustificate semplicemente con il concetto di statistical accuracy si pensi all'f1 score si

pensi al recall si pensi a varie metriche che si adattano sono adeguate per varie tipologie di

ecco quindi cosa stiamo facendo adesso nello standard stiamo in pratica non cercando di

replicare o esaurire tutta la letteratura accademica industriale sui concetti sull'utilizzo delle

metriche però ci stiamo ricollegando a livello normativo quindi con reference normative cioè

ovvero sia citando come necessari standard esterni al nostro gruppo di lavoro e questo

su più livelli in altre parole per quanto riguarda i standard di metriche più generali

c'è la al momento c'è pubblicato la ISO IC technical specification 4213 che è una technical

specification sviluppata in ambito ISO per dire guardate se volete fare performance cioè

measurements lo dico in inglese scusate di performance per un AI a livello di classificazioni

ci sono queste task questa 4213 adesso nel 2026 dovrà svilupparsi ulteriormente prenderà la

dicitura di ISO IC CD 4213 di committee draft cioè quindi per raggiungere uno stato più maturo di

draft per coprire ulteriori metriche cioè ovvero se non fare semplicemente classificazione però

anche regression, clustering e recommendation task e queste task sono abbastanza trasversali

sono abbastanza domain agnostic se vogliamo usare questo termine se invece entriamo nel

dominio per esempio della computer vision quello che dobbiamo vedere è quello che adesso stiamo

sviluppando in cnc nele in gtc 21 nel working group 3 per quanto riguarda le metriche di computer

vision le evaluation methods in altre parole parlo dello standard ora bozza il 18 28 1 mentre

se ci rivolgiamo in ambito language models natural language processing meglio o meglio dire

dobbiamo guardare a la joint working group della ISO IC SC 42 ovvero sia un gruppo che è condiviso

tra ISO IC e cnc nele gtc 21 joint working group 5 della sc 42 in ISO che sta sviluppando uno

standard che è in pratica lo standard della nlp evaluation methods il 23 28 2 infine un altro

standard che ci tornerà utile non per il concetto di accuracy ma per il concetto di robustness che

sta adesso approcciando appunto se non sbaglio da oggi la fase di ballot di inquiry in ISO IC è

lo standard della 24 29 in altre parole ISO IC 24 0 29 è una serie che si compone di tre standard

il cui primo è attualmente un tecnico report da un overview e gli altri due parlano di formal

methods e neural network methods metriche per la robustezza e quindi ecco da qui si vede una

diciamo un quadro scenario abbastanza sì uno scenario complesso ecco uno scenario abbastanza

complesso in cui dovremmo un po capire come come muoverci poi la per concludere in questa domanda

quando si parla di gaps cosa dobbiamo vedere cioè dobbiamo vedere se nel prossimo futuro

qualora tra sforfines part 2 verrà citato nell'official journal quando andremo quando

andremo a vedere la mappatura tra tra lo standard tra le clause cioè tra le sezioni diciamo tra le

clause dello standard e le ihecte nello specifico dovremmo vedere se in questa mappatura che riporta

il nome di annex ZA di tavola tabella annex ZA ci siano delle eccezioni ovvero sia per esempio ci

potrebbe essere la dicitura non lo sappiamo al momento che dirà ok tutte queste metriche che

sono incluse e di cui abbiamo una reference normativa nella ISO IC 42 13 nella ISO IC 28 2

18 28 1 e via discorrendo tutte queste metriche sono coperte le tasche possono essere assolte

con queste metri invece per le tasche al di fuori di queste metriche non diamo la presumption

conformity quindi ci sarà un gap che il provider dovrà giustificare altrimenti ecco benissimo e

allora io passerei subito alla domanda successiva che credo sia strettamente connessa con questo

tema di cui tu stavi parlando cioè come si possono verificare concretamente le metriche

di accuracy dei sistemi AI? Allora anche questa è una bella domanda molto molto complessa però

possiamo dire che al momento in transworthiness in parte 2 dello standard nella bozza in pratica

trattiamo di accuracy e robustness se andiamo a leggere ora la bozza corrente che appunto dovrà

raggiungere la fase di public inquiry di consultazione pubblica per commenti adesso a

febbraio in close nella clausola 6.2 parliamo del processo per verificare l'accuracy del sistema in

altre parole le prime parti le prime clausole parleranno delle definizioni del concetto che

diamo che non è come dicevo prima non è specificamente tecnico l'accuracy ma lo

definiamo functional correctness prendendo spunto da uno standard della serie square se non mi

sbaglio e in pratica poi delineiamo tutta la fase di assessment cioè ovvero sia come deve

essere condotto come deve essere riportato nella technical documentation come le metodologie

devono essere giustificate contro i rischi ogni quanto va ricondotta al reassessment e

secondo quali casistiche casi parametri cioè nuovi input riceviamo e via discorrendo ecco

quindi c'è una fase di definizione dei concetti nella clause 6.2 poi si passa alla fase di

assessment che è un po il cuore della di tutto lo standard se vogliamo e infine a corredo ci

sono altre clause poco dopo 6.4 6.26 che potrebbero cambiare ecco però diciamo che a livello high

level parlano di requisiti per i test data requisiti per i threshold requisiti per

l'identificazione dell'accuracy rispetto a domini di uso differenti ma anche rispetto a

differenti gruppi cioè per esempio a minoranze a persone più vulnerabili pensiamo fondamenta

rights pensiamo a persone in cui ecco il data set che stiamo usando potrebbe non essere abbastanza

rappresentativo quindi c'è tutto questo diciamo se vogliamo approccio non proprio life cycle però

pur sempre molto molto completo e ricollegandosi per concludere alla domanda precedente nella

fase di assessment una volta che le task l'intended purpose sono definite dobbiamo fare

uso delle metriche e qui troviamo le reference normative ai standard delle metrics che parlavo

poco fa ecco benissimo luca grazie ho un'ultima domanda per te e sostanzialmente andiamo su

un aspetto un po più pratico cioè secondo te come possono gli auditor for humanity perché

noi ovviamente abbiamo detto che stiamo conducendo questi approfondimenti nell'ambito di questo

progetto di for humanity conversazioni su ea e etiche standard quindi come possono gli auditor

for humanity utilizzare in pratica questi standard tecnici europei per valutare le conformità questa

è un'altra bella domanda molto comprensiva e allora quello che può essere fatto sì è logicamente

partire se vogliamo dalle certificazioni dal conglomerato di conoscenze che for humanity

può nella disposizione delle persone quindi logicamente informarsi con quella knowledge

base e poi vedere quello che dovrebbe essere la mia raccomandazione è vedere nel prossimo futuro

nei prossimi mesi quali standard saranno armonizzati e come cioè andare a consultare

nell'official journal european union quali standard saranno armonizzati perché questo

sarà molto interessante ed importante vedere eventuali gap vedere l'immagine e da lì provare

a partire farne uso per fare consulenza diciamo a vari providers o se vogliamo anche ad importers

che potrebbero diventare providers però in altre parole quello di cui io farei raccomandazione

innanzitutto partire da quello che adesso è già pubblico cioè quindi penso alla pr in 18 28 6

al quality management system andarlo a consultare e vedere un po quale sono i requisiti e come

possono essere traslati per far sì che le aziende dei providers siano siano pronte un altro

standard che adesso sta raggiungendo la fase di inquadri di consultazione pubblica è quello di

risk management quindi il pr in 18 22 8 e trasforma finesse anche nelle prossime settimane quindi il

pr in 18 22 9 quindi queste sono cose che un diciamo un consulente in AI government se vi

discorrendo può già da oggi vedere però nel prossimo futuro qualora tutti gli standard

armonizzati in gtc 21 saranno appunto armonizzati saranno appunto escitati la mia raccomandazione

rimane questa ovvero sia partire sempre dallo standard del quality management system associarlo

con quello di risk management come punto di partenza e poi se vogliamo usare diciamo questa

metafora questa analogia muoversi dal lato un po più da layer dallo strato un po più

organizzativo manageriale allo strato più delle tecniche specification ovvero sia penso allo

standard sotto di trasforma finesse parte 1 parte 2 allo standard di cyber security al 18 28 2 e in

18 28 4 cioè ovvero sia quello di data governance che va letto in congiunzione con il 18 28 3

logicamente questa è un'immagine molto molto articolata però penso che una volta che ci sia

il quality management system in place si abbia e anche quello di risk management si abbia davvero

una buona base di partenza per aiutare i providers. Benissimo grazie Luca tema estremamente

interessante anche se potrebbe apparire ostico in prima battuta per chi non segue questi argomenti

insomma sentire parlare di numeri sentire parlare di termini particolari ma noi poi

nell'ambito di questo progetto contiamo anche di fornire diciamo maggiori informazioni più

accessibili a chi non è proprio tra virgolette non ha detto i lavori allora ancora grazie Luca

noi di For Humanity Italy per questo progetto vi diamo appuntamento al prossimo incontro

seguiteci sui social seguiteci sulla pagina For Humanity Center Italy di For Humanity

un grazie ancora a Luca Dannini e a presto grazie Nicola