Cara AI, ma sei sicura che mi puoi sostituire? Cosa NON PUO' FARE l'AI - Parte 1.

Da almeno 3 o 4 anni è esploso l'hype sulla Intelligenza Artificiale Generativa (AI Gen).

E uso l'aggettivo "Generativa" non a caso, perchè quando si parla di AI dobbiamo tener conto di tante aree di ricerca e sviluppi diversi. E la AI Gen e i Large Language Model (LLM) sono solo "un pezzetto" del tutto.

Chi mi segue su Linkedin conosce la mia posizione di base: l'AI è uno strumento, può essere molto utile in molti casi, ma non è "l'arma fine di mondo" o la soluzione di ogni problema dell'umanità.

Ci sono già droni da guerra governati dall'AI, ma pur essendo armi molto efficaci e mortali, sono lontanissime dal Terminator cinematografico.

L'AI Gen non può prendere il potere e governare sull'umanità.

E non può perchè STRUTTURALMENTE non può, perchè STRUTTURALMENTE l'AI Gen NON E' INTELLIGENTE.

E questo con buona pace di tutti i "Fuffa-Guru" che devono vendervi qualcosa.

Non vi voglio annoiare con una disamina filosofica o tecnica, ci sono persone più in gamba di me che si occupano di questa nobile missione; vi segnalerò i loro profili Linkedin alla fine del post. E poi ci sono paper scientifici che stanno smontando pezzo per pezzo la "narrazione" dei padroni dell'AI. E nemmeno vi voglio tediare con considerazioni ecologiste sulla sostenibilità ambientale. E men che meno sulla validità di un modello di business che ad oggi non sta in piedi, in futuro si vedrà.

Voglio solo farvi vedere come sto usando io l'AI Gen e cosa l'AI Gen NON PUO' FARE per aiutarmi nel mio lavoro.

COME USO L'AI

RISCRIVERE TESTI

Scrivo documentazione direttamente li lingua Inglese dal 2008, ma non sono un "English native speaker", quindi ho sempre il sano timore di fare qualche errore. Poi nella mia azienda lo standard è English-US, quindi a volte non ho la sensibilità giusta per capire se i miei testi sono conformi all'Inglese americano.

L'AI Gen in questo compito è molto utile e veloce.

RIASSUMERE TESTI

A volte capita di ricevere della documentazione "grezza", delle bozze anche articolate e voluminose, scritte da esperti/colleghi/consulenti esterni, in un Inglese a volte "naive". In tal caso, può essere utile usare un prompt che istruisce l'AI Gen ad estrarre "il senso" della bozza, secondo determinati criteri. 

Può essere utile anche per fare una sintesi di massima di N testi, tutti più o meno correlati allo stesso contesto.

Il risultato finale diventa una "prima stesura", tutta da verificare e ri-sagomare. Ma è un buon modo per isolare le idee chiave e poi costruire ulteriormente

ESTRARRE INFORMAZIONI DA UN TESTO STRUTTURATO

Recentemente, una mia collega doveva analizzare un lungo file XSD (più di 200 KB) ed estarre da questo tutte le coppie ATTRIBUTO-DESCRIZIONE e riportarle in una tabella. Con un semplice prompt, l'AI engine che possiamo usare in azienda ha tirato fuori la tabella in meno di 20 secondi.

Ogni volta che avete un file che contiene una qualche struttura e volete estrarre i dati per collocarli in un'altra struttura, l'AI Gen può essere molto utile, a patto che sappiate spiegare cosa cercare nella struttura di partenza e come è fatta la struttura d'arrivo.

DEFINIRE UN TEMPLATE

Molti tipi di documentazione tecnica rispondono a criteri ben definiti ma a volte ci troviamo in una situazione di incertezza e vorremmo capire esattamente quale potrebbe essere il template più efficace per un certo uso.

In questo caso i suggerimenti dell'AI Gen possono essere molto efficaci.

VERIFICARE CHE UN TESTO SIA CONFORME AD UNA GUIDA DI STILE

Nell'azienda in cui lavoro devo attenermi alla Microsoft Style Guide, ma a volte anche un writer esperto non ricorda esattamente l'indicazione della guida da applicare in un certo frangente. 

In questo caso l'AI Gen ti aiuta a verificare dove hai operato esattamente o dove intervenire per una correzione.

----

Come vedete, in tutti questi casi d'uso, al netto del livello di eventuale automazione che potete/volete raggiungere, state usando l'AI Gen sfruttando le sue migliori qualità: struttura, grammatica e sintassi di un testo sono il "pane e burro" degli LLM. 

Ovviamente, in ognuno di questi casi dovete struttare dei prompt più o meno efficaci.

E ogni volta che ottenete un risultato, dovete comunque "rimetterci le mani", verificare, aggiustare un prompt, spesso aggiustarlo 4 o 5 volte prima di ottenere un rislutato "accettabile". Non ci sono pasti gratis!

Al prossimo post, in cui vi farò vedere COSA L'AI NON PUO' FARE e perchè i Technical Writer non devono avre paura che l'AI possa sostituirli.

Stay tuned!

E se volete approfondire ed aprire gli occhi sull'AI Gen (e dintorni), vi invito a seguire alcuni profili Linkedin degni di attenzione (ma ovviamente ce ne sono molti altri):

https://www.linkedin.com/in/walterquattrociocchi/

https://www.linkedin.com/in/parisialessandro/

https://www.linkedin.com/in/luciano-floridi/

https://www.linkedin.com/in/antoniodina/

Leggi questo articolo...

Diàtaxis: un framework per la Comunicazione Tecnica

Nel mio continuo lavoro di ricerca nel campo della Com Tecnica, sono capitato per caso sul sito di Canonical e da lì mi sono imbattuto in Diátaxis, un framework per la realizzazione della documentazione di prodotto ideato da Daniele Procida. Questo il suo sito.

Diátaxis è un termine che deriva dal greco antico: dia (“attraverso”) + taxis (“disposizione, ordine”). L’idea di base è che la documentazione deve essere organizzata in modo che gli utenti trovino ciò di cui hanno bisogno in funzione del loro scopo.

Diátaxis divide la documentazione in quattro tipi:

• Tutorial: guide per apprendere facendo, passo dopo passo.
• How-to: contenuti focalizzati sulla risoluzione di use case specifici.
• Reference: descrizioni tecniche, specifiche, tabelle, parametri, API, etc.
• Explanation: contenuti concettuali, background, contesto, per aiutare a comprendere più a fondo.

Diátaxis si pone l’obiettivo di aiutare gli utenti a trovare più facilmente ciò che cercano, perché l’organizzazione dei contenuti è basata sui loro obiettivi.

Quindi possiamo dire che il framework cerca di assumere “il punto di vista dell’utente”, e questa è una tendenza conforme ad altre discipline che si sono imposte negli ultimi 25 anni (vedi Design Thinking).

I principi di fondo che possiamo individuare sono sostanzialmente 2:

1. Fornire un modello coerente per organizzare la documentazione di prodotto.
2. Netta separazione di contenuti diversi, finalizzati per utenti diversi che le utilizzano in momenti diversi: le spiegazioni concettuali (Explanation) servono per dare una base ed un contesto, ma gli How To sono le vere procedure operative per risolvere problemi specifici.

Analizziamo sinteticamente le 4 tipologie di documentazione.

TUTORIAL

Sono finalizzati ad insegnare attraverso la pratica. L’obiettivo è “imparare facendo”, non “capire leggendo”.

Guidano l’utente passo dopo passo nel completamento di un compito, per acquisire nuove abilità in modo esperienziale. Un buon tutorial porta l’utente a fare un percorso di apprendimento, in cui ogni passaggio costruisce comprensione e fiducia.

Non confondete il Tutorial con l’How To:

• Secondo Diàtaxis, un Tutorial guida l’utente per imparare (la definizione di una configurazione, il disegno di un modello, etc)
• Un How To aiuta a risolvere uno specifico use-case (come faccio a fare QUESTA cosa?)

Un Tutorial efficace dovrebbe:

1. Dichiarare l’obiettivo: cosa avrò imparato al termine?
2. Prerequisiti: cosa serve sapere prima di iniziare.
3. Istruzioni passo passo:  ogni passo, istruzioni brevi e una sola azione (un solo verbo) per ogni passo.
4. Un risultato tangibile: qualcosa di concreto da mostrare. 
5. Un riepilogo e i prossimi passi: come continuare a imparare o approfondire.

EXPLANATION (concetti e spiegazioni)

Le spiegazioni servono a fornire contesto, comprensione e concetti, al fine di rispondere alla domanda: “Perché funziona così? In base a quali concetti o principi?”

A differenza dei Tutorial, le spiegazioni non sono istruzioni. Il loro scopo è aiutare il lettore a capire, non a fare.

Un Explanation efficace include:

1. La definzione del concetto: cosa si sta spiegando e perché è rilevante.
2. Principi chiave: le definizioni.
3. Contesto e background: come si collega ad altre parti del sistema o della Teoria.
4. Dettagli, esempi e controesempi: per chiarire il funzionamento e i limiti.
5. Collegamenti ad altri concetti o decisioni progettuali: come si è arrivati a una certa scelta?
6. Riepilogo finale e suggerimenti per approfondire: testi, documenti o sezioni correlate.

In Diàtaxis, le spiegazioni non vanno messe nel Tutorial o nell’How To. 

Se un Tutorial inizia a spiegare teoria, o un How To si dilunga in riflessioni, significa che quelle parti dovrebbero essere spostate nella sezione Explanation.

REFERENCE (riferimenti tecnici)

I documenti di riferimento sono la parte più tecnica e dettagliata della documentazione. Servono a descrivere in modo preciso e completo come funziona il sistema o il prodotto. Non insegnano, non spiegano concetti e non risolvono problemi concreti: descrivono. 

Una Reference ben fatta è esaustiva e facilmente consultabile. È utile per chi sa già cosa vuole fare, ma ha bisogno di conoscere i dettagli esatti per riuscirci.

Elementi tipici di una buona Reference includono:

1. Descrizioni complete di funzioni, comandi, classi o API.
2. Tabelle di parametri, argomenti, tipi di dati e valori di ritorno.
3. Esempi per illustrare come utilizzare correttamente una funzione o un’opzione.
4. Diagrammi o schemi strutturali, per capire la relazione tra elementi.
5. Collegamenti incrociati verso sezioni correlate (es. verso guide o spiegazioni).

La Reference deve essere organizzata in modo coerente ed ogni elemento documentato (una funzione, un comando, un endpoint API, ecc.) dovrebbe seguire lo stesso schema informativo.

Essa richiede un approccio descrittivo e non dovrebbe essere presente all’interno di un Tutorial o di un Explanation.

HOW TO

Servono a completare un compito specifico e rispondono alla domanda: come faccio a fare QUESTA cosa? 

Un How To definisce una procedura specifica che consente di ottenere un risultato preciso.

Un How To deve:

1. Definire l’obiettivo: cosa si otterrà al termine della procedura.
2. Elencare i prerequisiti.
3. Fornire istruzioni step-by-step.
4. Includere esempi concreti.
5. Concludere con un riepilogo e collegamenti utili (ad esempio ad altre guide o sezioni di riferimento).

----

Potrebbe essere interessante valutare l'eventuale correlazione tra Diàtaxis e altri standard/framework/metodi per la documentazione tecnica, quali DITA, S1000D e Information Mapping.

DITA vs Diàtaxis

DITA è uno standard aperto basato su XML per strutturare, creare e pubblicare contenuti modulari che possono essere facilmente riutilizzati su piattaforme diverse, consentendo una gestione efficiente della documentazione tecnica, attraverso la creazione di contenuti basati sulla specializzazione dei contenuti. 

E' forse lo standard tecnico più utilizzato nel mondo, e non solo per la documentazione dei prodotti software come erroneamente molti pensano.

DITA organizza le informazioni in piccoli “topic” autonomi tipizzati per Concept-Task-Reference-Troubleshooting.

Tali topic sono assemblati utilizzando un organizzazione gerarchica (DITA Maps), promuovendo la coerenza, la scalabilità e la riduzione dei costi nella gestione di grandi volumi di documentazione. 

Qulcuno intuisce un qualche punto di contatto?

"Concettualmente" si. Analizziamo la seguente tabella.

Ma è importante capire che queste "similitudini" sono solo apparenti.

DITA lavora a livello di "topic" che può essere un frammento di informazione "piccolo a piacere", da poche righe a pochi pararagrafi. Inoltre, ogni elemento della struttura del topic è associato ad un tag XML preciso. E ci sono topic che possono contenere solo un certo insieme di DITA tag e non altri.

Invece in Diàtaxis un How To può essere un documento anche molto esteso, purchè coerente con i principi sopra indicati. Gli elementi informativi di un How To in Diàtaxis non sono legati a nessuno tipo di tag XML e quindi non presentano una struttura pre-definita.

DITA parte con l'idea di organizzare i contenuti dal punto di vista della loro "struttura tecnica interna".

Diàtaxis parte del punto di vista dell'utente che deve consultare i documenti.

Quindi la tabella è un classico caso di "correlazione ingannevole": sia DITA che Diàtaxis indicano alcune "tipologie" di contenuto, ma la correlazione è debolissima, perchè la classificazione tipologica si applica ad oggetti diversi.

S1000D vs Diàtaxis

S1000D è anch'esso uno standard tecnico XML largamente utilizzato in tutto il mondo, in special modo nell'industria navale (civile e militare), in quella ferroviaria e in quella avionica/aeronautica (civile e militare). La sua "tipizzazione" è molto più dettgliata e raffinata di quella di DITA.

Un oggetto S1000D è definito da una specifica estremamamente precisa in ogni dettaglio informativo.

Direi che possiamo certamente concludere che S1000D e Diàtaxis sono imparagonabili.

Information Mapping vs Diàtaxis

Information Mapping (IM) è un metodo strutturato e modulare per scrivere contenuti in modo che siano facilmente comprensibili e riutilizzabili, concentrandosi sulla granularità e sull'uso di elementi visivi come le "mappe di contenuto" (content maps).

IM si focalizza sulla struttura fisica del contenuto (blocchi di testo, dati, immagini) che sono auto-contenuti, coerenti e riutilizzabili (tabelle, liste).

IM prescrive la rigorosa modularità dei contenuti, utilizzando principi di design per creare blocchi di informazione che possono essere riassemblati.

IM non è uno standard XML aperto.

Diàtaxis, come abbiamo visto, è un framework molto più incentrato sul COSA e sul PERCHE', che parte dal puntoi di vista dell'utente: non prescrive regole rigide sulla struttura fisica dei contenuti, e nemmeno sui blocchi informativi da presentare all'utente.

Tuttavia, sia IM che Diàtaxis hanno in comune l'aspirazione di promuovere l'organizzazione logica dei contenuti e la scomposizione di informazioni complesse, al fine di migliorare la comprensione e ridurre il carico cognitivo per chi legge. 

IN CONCLUSIONE

Diàtaxis è un framework interessante, con pochissimi punti di contatto con gli standard tecnici XML più usati nel mondo (DITA ed S1000D), mentre presenta qualche affinità con una metodologia come IM.

Come sempre, non esiste la soluzione perfetta per ogni contesto.

Pe grandi volumi di dati, che devono essere aggiornati di frequente, customizzati in N modi diversi e tradotti in dozzine di lingue, la potenza tecnico-organizzativa di DITA è difficilmente contrastabile. 

S1000D lo potete pensare come DITA elevato all'ennesima potenza, non a caso si usa in contesti e per prodotti spesso "mission-critical" dove la standardizzazione e la precisione dei contenuti sono imprescindibili.

Ma per altri contesti, adottare DITA ed S1000D potrebbe essere paragonabile ad andare a caccia di fagiani con un missile terra-aria.

Diàtaxis ha il grande pregio di essere focalizzato sulle esigenze degli utenti, con un'organizzazione semplice ed elegante. E non è un pregio trascurabile.

Leggi questo articolo...

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?

1. Perchè sulla gestione e costruzione dei contenuti ne so più di loro.
2. Perchè io non vi devo vendere nessuna soluzione miracolosa.
3. Perchè quando vi descrivono la loro soluzione miracolosa, non fanno cenno alla "fatica" che bisogna fare per definire una corretta gestione dei contenuti.

E "il percorso della fatica" è proprio quello che vedete visualizzato nel diagramma: dalla cerchia più interna a quella più esterna.

Il Gatto e la Volpe dell'AI vogliono convicervi a sotterrare le vostre monete d'oro nel Campo dei Miracoli: ma voi potete evitare di fare i Pinocchi.

I consulenti bravi sono quelli che verrano nella vostra azienda e prima di proporvi una soluzione AI-based, studieranno i vostri contenuti e metteranno in evidenza tutti i punti deboli e i difetti che possono essere corretti, proprio attraverso "il percorso della fatica": perchè a questo mondo non esistono pasti gratis. Poi, quando avranno messo in ordine i contenuti, li daranno in pasto all'AI e in quel caso si potranno avere risultati davvero utili.

Prima dell'AI, ci sono i dati di cui l'AI si nutre: dovete assumere la governance dei vostri dati. 

Declinando questo concetto nel campo della Comunicazione Tecnica, significa sviluppare tutte le competenze ed utilizzare tutti gli strumenti indicati nel diagramma... e forse anche qualcosa che nel diagramma non ha trovato posto.

---

Detto questo, ancora un grazie a Steev per lo spunto.

E in quanto a voi, quante delle competenze presenti nel diagramma ritenete di possedere?

Può essere un modo interessante per fare un rapido auto-test e iniziare l'anno col piede giusto.

E quindi... un grande 2026 per tutti voi!

Leggi questo articolo...

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

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

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

Mai smettere di imparare: ho fatto un corso su S1000D

Mi sono preso due giorni di ferie e ho chiesto al mio amico Antonio Murro di poter fare un corso su S1000D presso SeTeL.

Antonio mi ha affidato alla straordinaria competenza di Barbara Predonzani, una delle sue collaboratrici più brillanti ed esperte di S1000D.

Barbara mi ha condotto con efficacia e in profondità negli aspetti fondamentali di uno standard largamente utilizzato per scrivere documentazione tecnica in ambito navale, ferroviario, ed aereonautico.

Io ho lavorato per quasi 4 anni in IBM con lo standard DITA, che per alcuni versi ha molti punti in comune con S1000D. Questo mi ha aiutato nella comprensione della struttura di S1000D e del processo di definizione dei Data Module. Ma Barbara è stata estremamente chiara anche nell'illustrare gli aspetti più complessi dello standard.

Chi volesse approfondire la specifica S1000D, può seguire questo link.

S1000D è un sistema internazionale di specifiche per la creazione, gestione e distribuzione di documentazione tecnica e mira a migliorare l'efficienza, la coerenza e la riutilizzabilità delle informazioni tecniche.

Di seguito, le sue principali caratteristiche:

• Standard aperto: Favorisce l'adozione e la collaborazione tra diverse organizzazioni.
• Struttura modulare: Consente la creazione di contenuti riutilizzabili e facilmente aggiornabili. Le informazioni sono suddivise in unità chiamate Data Modules, che rappresentano le unità di contenuto riutilizzabile.
• XML: Le pubblicazioni sono basate su XML, che permette una gestione flessibile, interoperabile e facilmente aggiornabile delle informazioni.
• XML Schema Definition (XSD): Ogni Data Module, per essere validato, deve rispettare le regole e la struttura definite nell'XSD.
• eXtensible Stylesheet Language Transformation (XSLT): Definisce le regole di visualizzazione da applicare al Data Module.
• Gestione centralizzata: Supporta sistemi di gestione delle informazioni che facilitano l'aggiornamento e la distribuzione delle pubblicazioni.
• Output multi-canale: Può generare documentazione in vari formati, come PDF, HTML, eBook, ecc.
• Versioning e controllo delle revisioni: Include meccanismi per tracciare le revisioni e garantire che le informazioni siano aggiornate e coerenti.
• Interoperabilità: Progettato per integrarsi con altri sistemi di gestione delle informazioni e di manutenzione.

E come si dice ... never stop learning... because life never stops teaching!

Leggi questo articolo...

EU AI Act: consultazione pubblica per la definizione delle regole inerenti ai sistemi AI ad altro rischio

Ci sono molti aspetti critici inerenti alla documentazione tecnica che deve accompagnare i sistemi AI ad alto rischio. Tra i diversi articoli che vi ho proposto fino ad ora, il primo lo trovate qui, e l'ultimo qui.

Di fatto, ho interrotto la mia analisi (che riprenderò presto) perchè man mano che procedevo mi rendevo conto di alcuni nodi difficili da sciogliere.

Come già spiegato nel primo articolo, dobbiamo aspettare la definizione degli standard armonizzati per sapere COME implementare i principi indicati nell'EU AI Act (che prescrive il COSA va fatto).

Mi risulta che ci sia qualche difficoltà nella definizione di questi standard armonizzati e la data inizialmente ipotizzata (Agosto-Settembre 2025) potrebbe "scivolare" in avanti.

Questo non deve stupire: la materia è concettualmente molto potente, con dei passaggi veramente complessi da risolvere nel momento in cui si deve passare dal COSA al COME. In paralleo, ci sono forti interessi che spingono in direzioni diverse.

Del resto, l'argomento AI invade ogni giorno la nostra agenda e, al netto dell'hype alimentato dal marketing, è indubbio che siamo dentro una rivoluzione che sarebbe bene poter gestire e non subire passivamente.

Proprio per tale motivo, ora potete partecipare ad una consultazione pubblica relativa alla definizione delle regole espresse nell'AI Act in merito ai sistemi AI ad alto rischio.

Se andate su questo link trovate tutte le informazioni per partecipare.

Tenete presente che l'AI Act definisce 6 ruoli sui quali insistono le diverse obbligazioni:

• Provider
• Deployer
• Distributor
• Importer
• Authorized Representative
• Consumer

Dal punto di vista degli obblighi inerenti alla documentazione tecnica, le figure più coinvolte sono il Provider, il Deployer, il Distributor e l'Importer.

Prossimamente, un post sull'argomento.

A presto.

Leggi questo articolo...

The Double D(avide) format: quello che dovreste sapere...

Ieri ho assistito alla diretta Youtube organizzata da because.

In questo evento Davide Bin ha intervistato Davide Osta (da qui il titolo del post) in merito al suo ultimo libro: 

Manuali a norma per il mercato estero: quanti rischi con le agenzie di traduzione?

Davide Osta ha messo in luce tutta una serie di scabrose e ben note verità (quanto meno ben note “a chi è del mestiere”), che però le associazioni professionali si guardano bene dall’evidenziare e far emergere, per motivi abbastanza discutibili, nella maggior parte dei casi. 

Fra le tante, magistrale la citazione relativa alla COM&TEC che mi riguardava direttamente: il VP indebitamente allontanato e poi riammesso con relative pubbliche scuse ero io.

Ma al netto di questo irrilevante dettaglio autobiografico, vi invito a guardare le registrazione dell’evento.

Se fate parte del nostro contesto professionale, vi riconoscerete senza sforzo in molte delle dinamiche illustrate.

Ma c’è comunque da imparare.

Oggi siamo tutti immersi in un hype “fuffa-marketing driven” su tutte le tematiche relative alla AI generativa. Ovviamente c’è un motivo: la distanza fra i risultati verificati sul campo e i faraonici investimenti che vengono fatti da almeno 4 anni in questo settore, sta diventando sempre più devastante. 

Per chi ha investito miliardi di dollari in un giocattolo così potente, in assenza di un solido modello di business (andatevi a leggere i dati sul rosso in bilancio di alcuni dei maggiori AI player), l’unica possibiltà è rilanciare.

OKKIO! Non sto dicendo che l’AGI non vale niente, non serve o non possa essere utilmente utilizzata. Sto dicendo che vi stanno vendendo soluzioni “miracolistiche” o “a costo zero”, mentre la realtà è un’altra: l’AI generativa può fornire un boost non banale nella vostra logica di business.

Ma dovrete affrontare tutta una serie di passaggi, non gratuiti e non semplicemente delegabili a terzi. Dovrete far crescere la qualità intrinseca dei vostri processi aziendali. Perchè a questo mondo non esistono pasti gratis. E vi dovrete affidare a chi “conosce il mestiere”. 

Ed è proprio il senso che Davide Osta ha fatto emergere, grazie anche alle acuminate domande dell’altro Davide.

P.S.

Ho partecipato anche io a questo ciclo di eventi. Qui potete vedere la registrazione in cui con Davide Osta abbiamo provato a fornire una bussola sugli obblighi di documentazione tecnica relative all’AI Act.

Leggi questo articolo...

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

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

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

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

Ora fissiamo l'attenzione sul IV.3.

IV.3

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

E' una prescrizione molto impegnativa.

Proviamo a tirare fuori "il succo".

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

Di quale "livello di dettaglio" stiamo parlando?

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

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

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

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

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

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

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

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

...for specific persons or groups of persons on which the system is intended to be used and the overall expected level of accuracy in relation to its intended purpose...

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

...the foreseeable unintended outcomes and sources of risks to health and safety, fundamental rights and discrimination in view of the intended purpose of the AI system

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

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

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

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

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

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

72.2 

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

Come vedete, ogni passaggio necessita di attente valutazioni.

...the human oversight measures needed in accordance with Article 14, including the technical measures put in place to facilitate the interpretation of the outputs of AI systems by the deployers; specifications on input data, as appropriate

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

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

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

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

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

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

Leggi questo articolo...