Prima parliamo di AI Act, governance, trasparenza, competenze e controllo umano.
Poi compare un errore che sembra uscito direttamente da un modello generativo: “Repubblica Fealiana”.
Fa sorridere. Ma secondo me è interessante soprattutto per un altro motivo: ci ricorda quanto sia facile confondere la presenza di una policy con l’esistenza di un processo realmente controllato.
Prima verifica: cosa sappiamo davvero
L’episodio è stato riportato da Byte.it, che attribuisce alla Farnesina la pubblicazione di un contenuto contenente la dicitura “Repubblica Fealiana” e collega l’errore all’utilizzo dell’intelligenza artificiale.
Al momento della pubblicazione di questo Insight non ho trovato una conferma indipendente né una nota ufficiale che permetta di ricostruire con certezza quale strumento sia stato utilizzato, chi abbia prodotto il testo o in quale passaggio sia nato l’errore.
Per questo non considero il caso una prova tecnica contro la Farnesina o contro l’AI. Lo considero uno spunto. E, a mio avviso, uno spunto molto utile.
AI literacy non significa saper scrivere un prompt
L’articolo 4 dell’AI Act rende l’alfabetizzazione in materia di IA un obbligo per provider e deployer. Le disposizioni sull’AI literacy sono applicabili dal 2 febbraio 2025 e, da agosto 2026, sono operative anche le regole di vigilanza e applicazione indicate dalla Commissione.
Ma “AI literacy” non significa soltanto insegnare alle persone a usare un chatbot.
Significa capire i limiti dello strumento. Sapere che un output può essere formalmente perfetto e sostanzialmente sbagliato. Sapere quando verificare una fonte, quando non fidarsi di una risposta e quando il contesto richiede un controllo aggiuntivo.
In altre parole: saper usare l’AI significa anche sapere quando non crederle.
Human oversight: attenzione alle semplificazioni
L’AI Act contiene un requisito esplicito di human oversight all’articolo 14, ma riguarda i sistemi classificati ad alto rischio. Sarebbe quindi scorretto sostenere che qualsiasi testo generato da un modello debba rispettare automaticamente quell’articolo.
Il principio operativo, però, rimane interessante anche fuori da quel perimetro: se una tecnologia produce un output che entra in un processo aziendale o istituzionale, dobbiamo decidere chi è responsabile della verifica e cosa significa realmente “verificare”.
Mettere un essere umano alla fine del workflow non basta se quell’essere umano si limita a fare copia-incolla o ad approvare per inerzia.
La Pubblica Amministrazione si sta già ponendo il problema
AgID sta costruendo da tempo un quadro specifico per l’adozione dell’intelligenza artificiale nella PA. I documenti e le iniziative più recenti insistono su governance, affidabilità, accountability, competenze e supervisione umana.
Un’indagine AgID pubblicata nel 2025 su 108 organizzazioni ha censito 120 progetti di IA nella PA centrale e ha evidenziato, tra le altre cose, competenze interne ancora limitate, dipendenza da consulenti esterni e una scarsa diffusione di KPI definiti.
È un dato che secondo me racconta bene il problema: adottare l’AI è relativamente facile. Costruire intorno all’AI un processo maturo è molto più difficile.
Il problema non è l’allucinazione
I modelli generativi possono inventare informazioni, confondere termini, completare pattern in modo plausibile ma falso. Non è una caratteristica misteriosa: è un limite noto della tecnologia.
Per questo la domanda più utile non è: “come facciamo a impedire all’AI di sbagliare?”.
La domanda è: come facciamo a impedire che un errore dell’AI attraversi indisturbato tutti i nostri controlli?
Quando un output sbagliato arriva in una mail, in un documento ufficiale, in un report o in una comunicazione pubblica, il problema non è più solo il modello. È l’intera catena di validazione che va analizzata.
Cosa farei in un processo reale
Non partirei da una policy di cinquanta pagine. Partirei da quattro domande operative:
- Dove utilizziamo AI generativa? Non dove pensiamo venga usata: dove viene usata davvero.
- Quali output possono uscire dall’organizzazione? Testi pubblici, documenti, email, analisi, codice, risposte ai clienti.
- Quali output richiedono verifica? E soprattutto: che tipo di verifica? Linguistica, tecnica, legale, fattuale?
- Chi risponde del risultato finale? Il modello non può essere il proprietario del processo.
Solo dopo arrivano strumenti, workflow di approvazione, logging, formazione e controlli tecnici.
La governance comincia dopo il prompt
Forse è questo il punto che rischiamo di perdere mentre discutiamo di regolamenti.
L’AI Act è importante. Le linee guida sono importanti. Le policy sono importanti.
Ma nessuna di queste cose sostituisce una persona che conosce il contesto, riconosce un output improbabile e ha un processo che le concede il tempo e la responsabilità per fermarlo.
La vera domanda non è “abbiamo regolamentato l’AI?”. È: cosa succede tra il momento in cui l’AI risponde e quello in cui noi decidiamo di fidarci?
Nota metodologica: il caso “Repubblica Fealiana” è citato come episodio riportato da Byte.it. Al momento della stesura non ho trovato una conferma indipendente o una ricostruzione ufficiale dell’origine tecnica dell’errore; l’Insight utilizza quindi il caso come spunto di governance e non come accertamento di responsabilità.