Speaker 2: Caffè 2.0, dal 2008 il podcast per scoprire internet con Valentino Spataro.
Speaker 2: Iscriviti per ascoltare in anteprima e senza promo. Vai su caffè20. it
Speaker 2: slash membri.
Speaker 3: Buongiorno a tutti. Due esempi di caccia alle streghe molto interessanti.
Speaker 3: Uno riguarda il mondo assicurativo e l'altro quello che riguarda
Speaker 3: il mondo degli sviluppatori. Si discute, partiamo dagli sviluppatori. si
Speaker 3: discute ampiamente di un post di Kodeberg che dice sostanzialmente
Speaker 3: che noi non accetteremo mai né di farci scandagliare dall'intelligenza
Speaker 3: artificiale né di pubblicare nei nostri repository software generato con
Speaker 3: l'intelligenza artificiale. Tutto questo perché l'intelligenza artificiale abusa dei nostri
Speaker 3: contenuti e ci guadagnano solo loro. Di fronte a questa
Speaker 3: affermazione mi piace ricordare quello che dice San Filippo, Salvatore
Speaker 3: San Filippo, che ha già spiegato la posizione. Nel momento
Speaker 3: in cui noi diamo il codice in giro pubblicamente, lo
Speaker 3: diamo proprio in pubblico perché se ne possa rifare tutti
Speaker 3: gli usi che se ne vogliono. Sicuramente c'è un problema
Speaker 3: di licenze, per cui un conto è metterlo MIT, un
Speaker 3: conto è GPL. quel codice messo in GPL dovrebbe essere
Speaker 3: in GPL, pure ridistribuito e alterato. Però, come dico sempre,
Speaker 3: l'intelligenza artificiale e i modelli non ripetono le cose così
Speaker 3: come sono, ma le rielaborano, perché nascono per rielaborare nozioni
Speaker 3: e correlazioni tra le nozioni. Una volta nei primi rastrellamenti
Speaker 3: di codice, Github ha messo a disposizione solo quelle MIT,
Speaker 3: poi la cosa si è stesa e si è perso
Speaker 3: il controllo, siamo d'accordo. Però l'atto programmatore che mette qualcosa
Speaker 3: su Github sa che ne perde il controllo e lo
Speaker 3: fa per contribuire alla innovazione del mondo del software, dello sviluppo.
Speaker 3: E anche per interesse personale, l'idea di poter essere corretto
Speaker 3: da chiunque perché ha scritto qualcosa è utile. se il
Speaker 3: codice finisce dentro l'intelligenza artificiale che anzi verrà portata poi
Speaker 3: altrove e riutilizzata altrove esattamente come lo farebbe qualsiasi programmatore.
Speaker 3: C'è un problema di licenza, sono d'accordo, potremmo persino dire
Speaker 3: che nel momento in cui si dimostra che un certo
Speaker 3: codice GPL viene replicato continuamente così com'è da un'intelligenza artificiale,
Speaker 3: allora potremmo dire che probabilmente quel modello di intelligenza artificiale
Speaker 3: e soggetto alle licenze GPL. Ma, ripeto, questo è tutto
Speaker 3: un discorso da costruire, ovviamente, non è che lo possiamo
Speaker 3: dare così semplice come ho fatto adesso, lo sto buttando
Speaker 3: proprio come provocazione. In tutto questo, ripeto, ci sono delle
Speaker 3: ampie comunità di sviluppatori in Italia che si fanno forte,
Speaker 3: leoni da tastiera, che gridano che se il codice open
Speaker 3: source non deve essere toccato dall'intelligenza artificiale, non deve essere
Speaker 3: la base dell'addestramento di nessun LLM. Ma al tempo stesso
Speaker 3: vietano ai programmatori di pubblicare codice generato con l'intelligenza artificiale,
Speaker 3: perché è una porcata. La mia risposta, che è stata
Speaker 3: veramente violenta, perché non accetto più un'affermazione del genere, ha detto, signori,
Speaker 3: questa cosa è una stronzata perché... Chiunque pubblica un codice
Speaker 3: open source può commettere degli errori. Allora, se io lo riutilizzo,
Speaker 3: me lo devo leggere tutto, sia ai fini dell'AI Act,
Speaker 3: sia ai fini della responsabilità del software, di più per
Speaker 3: il regolamento sulla responsabilità del software. Però, anche ai fini
Speaker 3: dell'AI Act, diciamo che, facevo questa citazione perché se è
Speaker 3: generato con l'AI, devo dichiarare che è stato generato con l'AI. Ecco,
Speaker 3: questo interviene l'AI Act nella pubblicazione. Però dico, nel momento
Speaker 3: in cui riutilizzo un software, devo fare gli stessi controlli
Speaker 3: che si fanno per il mondo dell'open source. Non è
Speaker 3: che perché lo usano tutti allora sto tranquillo, me lo
Speaker 3: devo guardare ugualmente, così come se mi arriva dall'intelligenza artificiale
Speaker 3: lo devo guardare ugualmente. Io aggiungo, Wordpress ha insegnato a
Speaker 3: mischiare codice HTML con PHP, logica a mischiare proprio back- end, comfort- end,
Speaker 3: un casino incredibile, per cui viene fuori un codice osceno.
Speaker 3: Se però alla macchina, diciamo, separa le due cose, MVP,
Speaker 3: allora semplicemente avrai un codice molto più facile da leggere. Però, ripeto,
Speaker 3: un codice che è pubblicato dopo essere stato generato e
Speaker 3: va in coding, non significa che non abbia alcun valore,
Speaker 3: significa che avrà lo stesso valore un codice open source,
Speaker 3: che deve essere controllato e perché no potrebbe essere corretto
Speaker 3: non solo da una persona ma da più persone contemporaneamente
Speaker 3: ovvio bisogna dire sempre usato l'AI perché così uno capisce
Speaker 3: che ci può essere un certo tipo di errori molto
Speaker 3: più facilmente che andandosi a vedere un codice scritto da
Speaker 3: un essere umano il tipo di errori che fanno le
Speaker 3: macchine sono abbastanza diversi da quelli che fanno gli esseri
Speaker 3: umani poi alcuni sono comuni però sono diverse. Quindi questo
Speaker 3: è previsto all'AI Act, applichiamocelo, punto e basta. In ogni
Speaker 3: caso andare a dire non voglio che ci sia in
Speaker 3: un repository del codice generato con l'AI perché potrebbe essere dannoso,
Speaker 3: sbagliato e di seguito, è una stronzata colossale perché la
Speaker 3: stessa cosa riguarda qualsiasi software open source. Portiamocela a casa
Speaker 3: e vediamo, non fa riguere l'estere che nemmeno tra di noi.
Speaker 3: Perché parlavo, qui ho parlato solamente del mondo del del software. Vabbè,
Speaker 3: velocemente parliamo del mondo dell'assicurazione, il mondo dell'assicurazione si è
Speaker 3: spaventato del livello di capacità di penetrazione che ha l'intelligenza artificiale.
Speaker 3: E allora che cosa hanno pubblicato quelli dell'Ivas? Hanno inviato
Speaker 3: una comunicazione in materia di resilienza operativa digitale e modelli
Speaker 3: avanzati di intelligenza artificiale. Sostanzialmente hanno previsto che i consigli
Speaker 3: di amministrazione devono riunirsi attorno a queste indicazioni inserite in
Speaker 3: questo documento per produrre una relazione che deve essere presentata
Speaker 3: il 31 dicembre 2026. Cioè si cerca di avere una presa di
Speaker 3: coscienza obbligatoria obbligando il consiglio di amministrazione in corso, seduta, congiunta,
Speaker 3: il collegio sindacale di prendere atto di tutti gli elementi
Speaker 3: che costituiscono la cyber security, come se questo potesse essere
Speaker 3: un momento formativo. In questi si dice che deve esserci
Speaker 3: la relazione con l'indicazione delle aree richiamate nella guida, il
Speaker 3: livello attuale di esposizione al rischio e l'adeguatezza dei presidi esistenti.
Speaker 3: Tutte affermazioni programmatiche meravigliose che non servono a niente se
Speaker 3: uno poi non fa un lavoro veramente di mappatura, di
Speaker 3: ricerca e poi soprattutto coinvolge il consiglio in quello che
Speaker 3: c'è e quello che non c'è. Più che dire stiamo tranquilli.
Speaker 3: Individui le principali carenze e le relative priorità di intervento.
Speaker 3: Cioè se si trova delle lacune in qualcosa, allora il
Speaker 3: consiglio di amministrazione deve provvedere immediatamente definendo un piano di
Speaker 3: lavori con azioni, tempi e investimenti. proporzionato al profilo di rischio,
Speaker 3: alla complessità dei servizi, attività e operatività dell'impresa. Quarto punto,
Speaker 3: definisca le modalità con cui il consiglio di amministrazione verificherà
Speaker 3: l'avanzamento dello stesso. Il tutto da comunicare, ripeto, all'Ivas entro
Speaker 3: il 31 dicembre 2026. Andiamo a vedere che cosa devono fare sostanzialmente
Speaker 3: poi le assicurazioni e comunque all'interno Possiamo portarla avanti sia
Speaker 3: per modulare le banche, le situazioni, le imprese e sono
Speaker 3: consigli utili in generale, ma molto astratti. Quindi si deve
Speaker 3: determinare la propensione al rischio, RAF, per incorporare rischi derivanti
Speaker 3: alle tecnologie di frontiera. Primo punto, questo è un mio
Speaker 3: aspetto che mi interessa molto, sono verificare che siano adeguati
Speaker 3: i requisiti contrattuali per assicurare efficaci misure in monitoraggio della
Speaker 3: sicurezza e di gestione degli aggiornamenti. Cioè, ancora si parla
Speaker 3: di aggiornamenti, si mettono sullo stesso piano. Guardate che un
Speaker 3: aggiornamento rapidissimo può essere pericoloso quanto un aggiornamento ritardato per
Speaker 3: valutarne l'efficacia. Quindi, Ancora questo mito dell'aggiornamento c'è, è giusto
Speaker 3: che ci sia, ma va valutato volta per volta. Le
Speaker 3: misure di monitoraggio si dice che bisogna andare a monitorare
Speaker 3: in tempo reale. Ovviamente si monitora in tempo reale quello
Speaker 3: che si conosce. Quello che non si conosce sono degli indici,
Speaker 3: dei sensori, delle sentinelle che possono avvisarmi se c'è qualcosa
Speaker 3: di strano. E quindi quanto più sono grandi dati, tanto
Speaker 3: più bisogna fare controllo. E dice, mi raccomando, utilizzate criteri
Speaker 3: rigorosi per la valutazione ex ante e la selezione dei fornitori.
Speaker 3: Anche questo è un tema ripetuto mille volte, ci sono
Speaker 3: ormai delle checklist che portano sostanzialmente a coinvolgere in modo
Speaker 3: negativo tutti i fornitori di banche, assicurazioni e servizi di
Speaker 3: questo genere, che ormai bisognerebbe ritenere tranquillamente soggetti all'ANIS 2, no?
Speaker 3: Quindi anche il fornitore dovrebbe avere requisite e dovrebbe iscriversi
Speaker 3: anche lui tra i fornitori di S2. Questo avviene raramente
Speaker 3: perché le competenze in Italia non sono così diffuse. Quindi
Speaker 3: alla fine si dovrebbero rivolgersi tutti alle solite aziende certificate.
Speaker 3: Igiene informatica, processi di autenticazione rigorosi, gestione granulare degli accessi,
Speaker 3: monitoraggio costante. Gestione delle risorse informatiche per verificare il perimetro d'attacco.
Speaker 3: e le vulnerabilità, mapparle e indicare le soluzioni. Abbiamo visto
Speaker 3: alcuni provvedimenti del garante dove l'ultima ruota del carro aveva
Speaker 3: indicato che cosa fare e poi questo messaggio non è
Speaker 3: arrivato al decisore, quindi attenzione. Gestione delle vulnerabilità degli aggiornamenti,
Speaker 3: l'abbiamo già detto. È prevista anche la possibilità che ci
Speaker 3: si possa difendere con strumenti basati sull'intelligenza artificiale, che dovranno
Speaker 3: essere coerenti con la strategia, accompagnata da un'adeguata valutazione dei
Speaker 3: rischi specifici e l'adozione idonei presidi, cioè controllare che l'AI
Speaker 3: che controlla, controlla bene. Supervisionare quello che fa l'AI. Questo sì,
Speaker 3: ha un senso ovviamente, ma ormai... Serve da prevedere che,
Speaker 3: proprio per progettazione, il monitoraggio sia possibile. Di che cosa? Ecco,
Speaker 3: nel momento in cui si vanno a toccare dati personali,
Speaker 3: il garante potrebbe dire, no, per la sicurezza questo non
Speaker 3: è adeguato, quindi comunque non devi trattare questo dato in
Speaker 3: quanto personale. O si può rifarlo diventare personale, re- identificando il
Speaker 3: dato trattato. Poi abbiamo, quindi restano i punti di dubbio, monitoraggio, rilevazione,
Speaker 3: misure di difesa, attività di test, fare anche dei test
Speaker 3: di penetrazione periodici, ma questi sono già previsti, infatti, lo
Speaker 3: dicono anche loro dalla Dora, e simulare degli scenari realistici
Speaker 3: più complessi. E qui la fantasia di farsi attaccare per
Speaker 3: vedere cosa c'è che non va. sottolineano ancora una volta
Speaker 3: di controllare i fornitori esterni in modo tale da avere
Speaker 3: una catena di formatura articolata e prevedere una serie e
Speaker 3: poi l'elenco degli addempimenti che vi ho detto, sostanzialmente questa
Speaker 3: relazione che dovrà essere approvata con questi elementi e addirittura
Speaker 3: trasmessa poi all'Ivas entro il 31 dicembre 2026. Capite che è un
Speaker 3: momento di panico sostanzialmente, questa Queste indicazioni sono state date
Speaker 3: pure dall'ABI per le banche e poi anche in altri
Speaker 3: enti pubblici. E che cosa vengono a dire? Vengono a dire, signore,
Speaker 3: è il momento di spendere per tracciare le attività che
Speaker 3: subiamo da parte dell'intelligenza artificiale o che vengono realizzate insieme
Speaker 3: all'intelligenza artificiale. E questa cosa però gli sviluppatori, alcuni
Speaker 3: la vedono come un blocchiamo tutto... ridicolo, e dall'altra parte
Speaker 3: le banche e le assicurazioni che dicono scriviamo tutto quello
Speaker 3: che c'è che sappiamo che potrebbe essere pericoloso. Diciamo, questo
Speaker 3: non è cambiato rispetto ad anni fa. Quello che deve
Speaker 3: cambiare è il modo in cui noi consideriamo i rischi.
Speaker 3: Da una parte possiamo considerare proprio dei rischi operativi, quindi
Speaker 3: un banalissimo bug, dall'altra proprio dei problemi funzionali. e sugli
Speaker 3: aspetti funzionali ovviamente da esseri umani possiamo vederli. Sotto profilo
Speaker 3: dei bug, andarle a rilevare tutti, bisogna prendere atto che
Speaker 3: non basta rivelare un bug per dire ok, adesso lo risolvo,
Speaker 3: perché spesso il bug viene segnalato come tale in mancanza
Speaker 3: di una visione del contesto di tutti gli altri sistemi informatici.
Speaker 3: A meno che non si fa come la gente di
Speaker 3: OpenAI che poi è scappato è andato a trovare proprio
Speaker 3: tutte le attività per andare a trovare i bug e
Speaker 3: infiltrarsi in altri servizi quindi capite che è un qualcosa
Speaker 3: è molto delicato non c'è una risposta certa c'è l'indicazione
Speaker 3: semplicemente del dire guardate è il caso di fare nuovi
Speaker 3: test con nuove logiche e andare a verificare la cyber
Speaker 3: security con delle visioni di insieme molto più ampie di
Speaker 3: una volta Il consiglio principale è avere una rigorosa gestione
Speaker 3: della granularità, separazione dei dati il più possibile e poi
Speaker 3: tanto tanto monitoraggio che sia in grado di rendersi conto
Speaker 3: quando c'è qualcosa di eccessivo o di inusuale, quindi o
Speaker 3: di troppo usuale o di troppo usuale. Un
Speaker 2: caro saluto a tutti e alla prossima! Caffè 2.0.it è
Speaker 2: il podcast per imprese e professionisti che vogliono capire Internet
Speaker 2: dal punto di vista tecnico e da quello legale. Ascolta
Speaker 2: gli episodi in anteprima e senza pubblicità. Iscriviti a partire
Speaker 2: da 5 euro al mese. Vai su www. caffè2. 0. it slash membri.