Chi risponde se l’IA sbaglia? Cosa ha lasciato fuori la fantascienza

Chi risponde se l’IA sbaglia? Non il modello. La responsabilità resta a persone e organizzazioni: lo sviluppatore che ha costruito il sistema, l’organizzazione che lo ha adottato, l’operatore che lo gestisce e, entro certi limiti, l’utente che agisce sul suo output. Dare un nome a questi ruoli è facile. La parte difficile è decidere, prima del lancio, a chi spetta quale decisione.

La fantascienza ha passato ottant’anni a descrivere macchine che costruiscono, calcolano e parlano. Quasi tutto è arrivato: il computer che risponde alle domande, l’assistente che scrive codice, l’agente che esegue un flusso di lavoro durante la notte. Il genere aveva ragione sulla capacità e taceva sulla responsabilità. Nel 2026 la capacità costa poco, quindi la responsabilità è la parte che chi guida un’azienda deve progettare.

Le regole di Asimov (1942)

Nel 1942, nel racconto «Runaround», Isaac Asimov scrisse tre regole per i robot. I racconti classici che seguirono ruotano attorno a una regola che incontra una situazione non prevista. Il robot obbedisce alla lettera, manca lo scopo, e nessuno ha stabilito chi risponde di ciò che accade dopo. Le regole esistevano. Un responsabile, no.

HAL (1968)

HAL, il computer di 2001: Odissea nello spazio (1968), parla, pianifica e governa un’astronave. Non ha un titolare che firmi per lui. Quando il suo giudizio e gli interessi dell’equipaggio divergono, non c’è un audit trail che qualcuno legga, né una condizione di arresto concordata, né una via di escalation. L’unica supervisione umana rimasta è un membro dell’equipaggio che lo disconnette a mano. La capacità è arrivata per prima; la responsabilità, mai.

Le persone che costruiscono, adottano e gestiscono il sistema, ciascuna per ciò che controllava. Lo sviluppatore risponde di come sono stati realizzati il modello e il software. L’organizzazione che lo adotta risponde ai propri clienti di aver messo l’IA nel suo prodotto. L’operatore risponde della sua gestione. L’utente finale risponde di aver agito su un output che avrebbe potuto verificare.

Questa non è una consulenza legale. La responsabilità per l’IA dipende dalla giurisdizione, dal contratto e dai fatti, e una pretesa può fondarsi sul contratto, sulla colpa o sulla responsabilità da prodotto; rivolgetevi a un avvocato prima di farvi affidamento. I quadri di riferimento pubblici vanno nella stessa direzione: i Principi dell’OCSE sull’IA ritengono gli attori dell’IA responsabili in base al loro ruolo, il NIST AI Risk Management Framework chiede alle organizzazioni di rendere team e persone con un nome responsabili del rischio legato all’IA, e l’AI Act dell’UE ripartisce gli obblighi tra fornitori e deployer.

I vuoti compaiono dove i ruoli si sovrappongono. Un’azienda che costruisce il proprio strumento di IA e lo usa con i clienti è allo stesso tempo sviluppatore, organizzazione che lo adotta e operatore, e ogni team presume che il rischio sia in capo a un altro. Allora, in quel caso, chi risponde quando l’IA fallisce? Chi è stato nominato in anticipo, oppure nessuno.

La parte economica

Una piattaforma di IA può produrre un prototipo funzionante in una sera. Usiamo noi stessi quegli strumenti, nella nostra ingegneria e dentro Vendo AI, il nostro prodotto di vendita. L’output va comunque verificato: il 2026 GenAI Code Security Report di Veracode ha rilevato un tasso di superamento dei controlli di sicurezza del 56% su oltre 100 modelli, e nello Stack Overflow Developer Survey la fiducia degli sviluppatori nell’accuratezza dell’output dell’IA è scesa dal 40% al 29%. Niente di tutto questo rende gli strumenti cattivi. Li rende strumenti.

La parte costosa

Ciò di cui un’azienda ha bisogno dopo il prototipo è un sistema che continui a funzionare: un’architettura che regga la crescita, dati trattati correttamente, una sicurezza verificata e non presunta, e una persona con un nome che risponda quando qualcosa si rompe alle due di notte. Per chi ha la titolarità di un prodotto, la governance dell’IA si riduce a quattro decisioni, messe per iscritto prima del lancio:

• →Un responsabile con un nome: una persona, non un comitato, che può fermare il sistema e risponde del risultato.
• →Un audit trail: che cosa il sistema ha ricevuto, che cosa ha prodotto e chi lo ha approvato, conservato per la tracciabilità e la spiegabilità.
• →Condizioni di arresto: dove l’IA non deve agire da sola, come nei pagamenti, nelle decisioni automatizzate che riguardano persone o in tutto ciò che esce dal suo perimetro documentato.
• →Un percorso di escalation: chi viene chiamato, con quale rapidità e che cosa vede l’utente mentre una persona subentra.

Nessuna di queste è una clausola che un avvocato aggiunge alla fine. Ognuna cambia l’architettura, l’interfaccia, la documentazione e il costo di esercizio, quindi ognuna appartiene alla logica di prodotto fin dall’inizio. «Human in the loop» significa qualcosa solo quando quella persona ha l’autorità, le informazioni e il tempo per scavalcare la decisione della macchina.

La nostra regola è breve: nessuno sviluppo senza logica di prodotto. Un operatore di prodotto decide cosa merita di essere costruito, lo costruisce per essere operato e risponde del risultato. Per un nuovo prodotto, la responsabilità comincia prima della prima riga di codice.

Il Leadership Gate è il punto in cui la responsabilità diventa una decisione. Ha un solo titolare, il CEO, e si chiude con delle motivazioni: procedere, rimodellare o rifiutare. Rifiutiamo quando la logica di prodotto non regge, quando il modello commerciale non può sostenere l’operatività, o quando non potremmo assumerci la responsabilità del risultato. La sequenza completa è descritta in come funziona il nostro processo.

Applichiamo le stesse regole alla nostra IA. Il case study di Vendo AI mostra un prodotto di IA responsabile in produzione: ogni fonte di segnali è un modulo separato ad attivazione volontaria, con i propri analytics, e una conversazione può passare a una persona in tempo reale. Su questo sito Vendo AI raccoglie il contesto e aiuta a organizzare una call; non prende decisioni commerciali né emette offerte.

Ponetele al vostro team, a ogni fornitore e a ogni costruttore di app con IA che state confrontando. Le risposte vanno messe per iscritto.

• →Chi è il responsabile con un nome di questo sistema in produzione?
• →Quali decisioni può prendere l’IA da sola, e quali richiedono l’approvazione di una persona?
• →Che cosa viene registrato, per quanto tempo, e chi lo legge quando qualcosa va storto?
• →Quali condizioni fermano il sistema, e chi viene chiamato quando succede?
• →Se state scegliendo tra un costruttore di app con IA e un team: chi risponde del sistema dopo il lancio?

Se nessuno sa rispondere alla prima domanda, il progetto finisce al prototipo, per quanto in fretta sia stato fatto. Se un prodotto costruito con l’IA è già live, ha utenti e si è fermato, Existing Product Review è il percorso in cui esaminiamo il codice, la logica di business e il mercato, e decidiamo se investire.

La fantascienza ha previsto le macchine. Le regole per le persone intorno a loro sono sempre state la parte difficile.