Hai comprato le licenze del copilota. C'è stata un'email di lancio, forse una formazione. E tre mesi dopo, quando guardi l'uso reale, la maggior parte non l'ha aperto questa settimana. Non sei solo: Microsoft ha riportato circa 15 milioni di utenti a pagamento di Copilot su circa 450 milioni di licenze Office commerciali —intorno al 3% di adozione reale— e nel 2026 l'uso settimanale attivo tipico si muove tra il 20 e il 30% delle postazioni con licenza. La conclusione scomoda è questa: il copilota IA interno non fallisce sul modello. Fallisce perché nessuno lo usa.
La tesi in una frase: un copilota interno muore sull'adozione, non sulla capacità. Il modello è quasi sempre abbastanza buono; ciò che fallisce è l'incastro nel flusso di lavoro reale e l'accesso ai dati che rendono la risposta utile. Senza queste due cose, la licenza cara resta chiusa —e il problema non si risolve comprando un modello migliore.
Perché il copilota IA interno resta chiuso
Lo schema di abbandono è così costante che ormai è documentato: la gente prova il copilota una o due volte, si accorge che rivedere e correggere la bozza che genera porta via più tempo che scriverla da soli, e smette di usarlo. Il calo d'uso avviene la prima settimana, non il primo anno. Non è pigrizia né resistenza al cambiamento: è una decisione razionale. Se lo strumento ti costa più di quanto ti fa risparmiare sul tuo compito preciso, abbandonarlo è la scelta giusta.
Ed ecco l'errore di diagnosi che si paga caro: quando l'adozione si arena, la reazione tipica è pensare che il modello sia insufficiente e cercarne uno migliore. Ma i dati puntano al contrario —la percezione dell'utente diverge dalla qualità del modello— il che indica l'esperienza di prodotto e l'esecuzione dell'integrazione, non la capacità. Cambiare modello quando il problema è l'incastro è spendere sulla leva sbagliata.
Le tre vere ragioni per cui l'adozione crolla
Sotto il «non lo usano» ci sono cause concrete, e nessuna si risolve con un modello più potente.
- Non si incastra nel flusso di lavoro. Il copilota vive in una scheda a parte e il lavoro vive altrove. Se usarlo obbliga a uscire dal flusso, copiare il contesto e tornare, l'attrito si mangia il risparmio. Lo strumento deve stare dove già si lavora, non in una finestra da andare a cercare.
- Non ha i dati a portata. Un copilota che non conosce le tue politiche, il tuo storico né i tuoi sistemi risponde generico —e il generico va riscritto da capo. Il salto da «assistente che redige cose plausibili» a «assistente che risponde con i tuoi dati» è ciò che separa un giocattolo da uno strumento.
- Nessuno ha mostrato che funziona su un compito reale. Senza un caso visibile nel team —qualcuno che lo usa per qualcosa di concreto e risparmia davvero— non c'è prova sociale che trascini il resto. La gente non adotta per un'email; adotta quando vede un collega risolvere in due minuti ciò che a loro ne prende venti.
Ce n'è una quarta, silenziosa: i dubbi su sicurezza e dati che nessuno ha chiarito. Se il team non sa se i suoi prompt addestrano il modello o se può inserirci dati dei clienti, molti semplicemente non lo usano —e non lo dicono. Quell'incertezza uccide l'adozione senza lasciare traccia in nessun sondaggio.
Un copilota non è un agente: la sfumatura che cambia il progetto
Parte del problema è aspettarsi dal copilota qualcosa che, per progetto, non fa. Un copilota assiste una persona: aspetta la tua istruzione, redige, riassume, cerca. Brilla nel puntuale e muore nel ripetitivo che attraversa più app —raccogliere ciò che arriva per email e lasciarlo strutturato, tenere una scheda coerente in tre posti, montare un dossier dal disperso. Questo non lo fa un copilota che aspetta ordini; lo fa un agente amministrativo che lavora da solo. Decidere quale ti serve è la prima domanda di quali processi automatizzare con l'IA: se il lavoro è assistere persone, copilota; se è togliere lavoro di tastiera ripetitivo, agente. Vendere un copilota dove serviva un agente è una garanzia di delusione, e viceversa.
Come si risolve l'adozione (e non è con un altro modello)
Se l'adozione è il problema, l'adozione è dove si investe. In pratica sono quattro mosse, nessuna sul modello:
- Mettere il copilota nel flusso reale. Dove già si lavora —il CRM, l'helpdesk, il documento— non in una scheda a parte. Se bisogna andarlo a cercare, non si usa.
- Dargli i dati a portata. Collegarlo alle tue politiche, al tuo storico e ai tuoi sistemi perché risponda con i tuoi dati e non con il generico. È qui che un copilota passa da plausibile a utile.
- Scegliere 2-3 compiti concreti e dimostrarli. Non «usate l'IA»: «per questo tipo di email, questo prompt ti fa risparmiare quindici minuti». Un caso visibile che funziona trascina più di dieci formazioni.
- Rispondere alla domanda di sicurezza prima che la facciano. Cosa succede ai dati, cosa si può inserire e cosa no. La fiducia è un prerequisito d'uso, non un extra.
È, in fondo, la stessa ragione per cui i progetti di automazione con l'IA falliscono: si compra tecnologia e si salta l'incastro con il lavoro reale e le persone che lo fanno. La tecnologia è la parte facile; che venga usata è quella difficile, ed è quella che decide il ritorno. Per questo il lavoro che sposta davvero l'ago non è scegliere un modello, è l'adozione dell'IA nei team: incastro nel flusso, dati collegati, casi dimostrati e dubbi chiariti.
La domanda da farsi prima di rinnovare le licenze
Quando arriverà il rinnovo e vedrai l'uso piatto, la tentazione sarà cambiare fornitore o modello. Prima, fatti la domanda che ordina il problema: la gente non lo usa perché il modello è scarso, o perché non si incastra nel suo lavoro e non ha i dati a portata? È quasi sempre la seconda. E non si risolve comprando —si risolve montando l'adozione come un progetto con un proprietario, non come un'email di lancio. Un copilota che nessuno usa non è un problema di IA: è una licenza cara che aspetta che qualcuno faccia il lavoro di farla usare.