Cosa comprano davvero le aziende quando comprano agenti AI?
Le aziende che comprano agenti AI aziendali comprano software che agisce, non software che risponde: apre ticket, modifica record, invia messaggi e, nello sviluppo, cambia codice che arriva in produzione. L'acquisto di solito è impostato per funzione (supporto, vendite, operazioni, sviluppo) e prezzato a utente o a consumo. Quello che il contratto raramente copre è la responsabilità sul risultato. Gartner ha previsto il 25 giugno 2025 che oltre il 40% dei progetti di AI agentica sarà cancellato entro la fine del 2027, citando costi in aumento, valore di business poco chiaro o controlli del rischio inadeguati. Il terzo motivo è quello che chi compra può sistemare prima del pilota: decidere quali azioni l'agente può fare da solo, quali richiedono l'approvazione di una persona e quali restano solo umane, poi pretendere una traccia che mostri ogni azione e chi ha firmato. Un agente ha ricevuto un lavoro in delega solo quando qualcuno ha accettato, per iscritto, di rispondere di ciò che consegna.
Lo stesso comunicato Gartner segnala anche l'"agent washing", cioè la rimarchiatura di assistenti, RPA e chatbot come agenti, e stima che solo circa 130 dei migliaia di fornitori che dichiarano prodotti agentici lo siano davvero. Per chi compra, l'etichetta sul prodotto dice poco. La domanda utile è cosa può modificare il prodotto e cosa lascia dietro di sé quando lo fa.
Perché una delega senza responsabilità non è una delega?
Delegare a una persona funziona perché al risultato è attaccato un nome. Se un fornitore consegna una modifica sbagliata, qualcuno ne risponde e il cliente sa chi. Un agente non ha titolo per rispondere. Quando i termini del fornitore dicono che il cliente è responsabile di rivedere gli output, e il team del cliente ha approvato il pilota perché la demo era convincente, la responsabilità non sta in capo a nessuno in particolare finché qualcosa si rompe.
Nel software questo emerge tardi e costa caro. Il codice scritto da un agente viene integrato, la sessione che lo ha scritto finisce, e mesi dopo nessuno sa dire cosa l'agente poteva toccare o chi ha guardato il diff. Lo stesso schema l'abbiamo descritto per cosa lascia un agente di coding dopo la sessione, e il punto vale oltre il codice: l'output di un agente è difendibile solo quanto la traccia che lo accompagna.
Automatico, assistito, solo umano: come si traccia la linea una volta sola?
Il modo più semplice per evitare sia la fiducia cieca sia la paura generalizzata è un contratto di autonomia a tre colonne, scritto per funzione e per repository prima che parta il pilota, non dopo il primo incidente.
| Automatico | Assistito | Solo umano | |
|---|---|---|---|
| Chi agisce | L'agente, da solo | L'agente prepara, una persona decide | Una persona, con l'agente al massimo come lettore |
| Esempi tipici | Formattazione, bozze, esecuzione di controlli, riassunti | Modifiche al codice, risposte ai clienti, cambi di configurazione | Firma del rilascio, decisioni di prodotto, scelte normative, rapporto col cliente |
| Cosa va registrato | Che è stato eseguito e cosa ha toccato | La proposta, l'esito dei controlli e chi ha approvato | La decisione e la persona che l'ha presa |
| Cosa va storto se è messo nella colonna sbagliata | Errori silenziosi su larga scala | Approvazione a timbro, il clic riflesso | Lentezza, raramente un pericolo |
La regola che fa funzionare la tabella è che si sposta solo per decisione: un'azione passa da assistita ad automatica perché qualcuno lo ha scritto, non perché l'agente ha avuto ragione spesso. Anche i fornitori più spinti sull'autonomia tengono un punto di controllo, come mostra la modalità automatica di Claude Code e la firma umana: il sistema prepara, la persona firma.
Cosa chiedere a un fornitore prima del pilota?
Domande che trasformano una conversazione commerciale in qualcosa di confrontabile fra fornitori:
- Cosa può cambiare l'agente senza chiedere, e quell'elenco è configurabile per team o per repository?
- Dov'è il log di ciò che ha fatto, chi può leggerlo e quanto dura dopo la fine della sessione?
- Quale passaggio richiede l'approvazione di una persona con nome e cognome, e quell'approvazione è registrata come evento, non come casella spuntata?
- Se fra sei mesi il risultato dell'agente si rivela sbagliato, cosa posso mostrare per dire chi l'aveva autorizzato?
- Cosa succede alla traccia se cambiamo fornitore o modello?
Nessuna di queste domande richiede un background tecnico per essere posta, e nessuna richiede un pilota lungo per avere risposta. Chiedono a chi compra di trattare l'agente come un fornitore che non firmerà nulla, e di decidere prima chi, dentro l'azienda, firma al suo posto. Se il fornitore non sa dire dove passa la linea fra lavoro automatico e assistito, la linea sta dove l'agente decide di metterla.
Un fornitore che risponde bene alle prime due e schiva le ultime tre vende capacità, non delega. Lo stesso ragionamento vale per uno strumento che tiene traccia del lavoro su una kanban: seguire i compiti non equivale a dimostrare chi ha accettato il risultato.
Quale traccia rende la risposta ripetibile?
Una risposta a "chi ha firmato questo" serve solo se può essere data di nuovo, da qualcuno che non era presente. Servono tre cose conservate fuori dalla sessione dell'agente: cosa l'agente era autorizzato a fare, il controllo indipendente eseguito sul risultato (test, build, revisione del diff stesso) e la firma della persona che lo ha accettato. Ognuna costa poco da salvare nel momento della modifica ed è impossibile da ricostruire dopo.
È il livello che Detent, l'impianto di delivery end-to-end (detent-ai.com), mette sopra l'agente: ogni modifica sulla linea porta con sé autorizzazione, verifica e firma umana prima del rilascio. Come questo si distingue dagli strumenti solo-agente lo trovi nel confronto in home page.