Due giorni per costruirlo, un mese per darlo a tutti

Capita sempre più spesso, nelle aziende che stanno portando l'AI generativa nel lavoro quotidiano: qualcuno nel team costruisce in due giorni uno strumento che cambia il modo di lavorare con i documenti aziendali. Poi scopre che per darlo ai colleghi servirà un mese. Vale la pena raccontare perché, e capire se è giusto così.

La risposta breve: buona parte di quel mese è legittima, ma non tutta. Il problema non è la burocrazia in sé. È che il processo è tarato su un mondo in cui costruire software costava molto più che adottarlo — e quel mondo, con l'AI, non esiste più.

Il caso: uno strumento nato in due giorni

L'idea, in un caso che si vede sempre più spesso in questi mesi, è semplice. Un'estensione per un assistente AI, con una skill dedicata, che attraverso le API del sistema documentale interno scarica in locale i documenti e le pagine wiki che servono. A quel punto l'assistente può leggerli, incrociarli, riassumerli e analizzarli come farebbe un collega che ha letto tutto.

Il risultato è potente. Domande che prima richiedevano ore di ricerca tra cartelle e pagine wiki richiedono ora minuti. Codice scritto, test fatti sui documenti reali, due o tre casi limite sistemati. Due giorni, appunto.

Poi la domanda naturale: perché non darlo a tutti? Ed ecco la lista che attende chi lo propone:

• censire lo strumento nel registry aziendale
• descrivere il caso d'uso e aprire un progetto
• scrivere i requisiti, funzionali e non funzionali
• passare le revisioni di sicurezza e privacy
• preparare un installer e un piano di deployment
• definire chi lo supporta e come si aggiorna

Un caso d'uso da due giorni diventa un progetto da un mese.

Cosa cambia quando lo strumento non è più di uno solo

Finché lo usa chi l'ha costruito, lo strumento eredita il suo contesto: sa cosa fa, sa quali documenti può vedere, riconosce una risposta sbagliata, e se si rompe lo sistema. Quando lo usa una persona, il rischio è di quella persona. Quando lo usano in cento, il rischio è dell'azienda.

Ecco le domande che il processo pone, e che in due giorni raramente qualcuno si è fatto:

Nessuna di queste domande è burocrazia. Sono le domande che separano un prototipo da un servizio.

Il paradosso: costruire costa poco, adottare no

Per anni il rapporto è stato stabile: tre mesi per sviluppare, un mese per mettere in produzione. Il processo di governance era una frazione ragionevole del totale, e nessuno lo percepiva come un freno.

Con gli assistenti AI capaci di scrivere skill ed estensioni, la parte di costruzione è crollata da mesi a giorni. La parte di adozione no: le domande sulla sicurezza, sui dati e sul supporto sono rimaste identiche. Così il rapporto si è ribaltato. Due giorni di sviluppo, un mese di processo: il 95% del tempo va nel far arrivare lo strumento alle persone.

È questo che genera la frustrazione diffusa in tante organizzazioni in questi mesi. Non è che il processo sia peggiorato. È che prima era nascosto dietro il costo dello sviluppo, e ora è rimasto solo, in piena vista.

È giusto così?

In parte sì. Le domande della tabella vanno fatte, e farle dopo un incidente costa molto più di un mese. Uno strumento che porta documenti riservati fuori dal sistema che li governa merita attenzione, per quanto sia stato veloce costruirlo.

In parte no. Il processo tipico ha tre difetti:

• È uguale per tutto. Una skill che riassume pagine pubbliche della wiki e un'estensione che scarica contratti passano dallo stesso imbuto. Il rischio è diverso, il percorso dovrebbe esserlo.
• È sequenziale. Registry, requisiti, sicurezza, packaging: ogni passo aspetta il precedente. Molte di queste verifiche potrebbero correre in parallelo.
• Rifà ogni volta lo stesso lavoro. Autenticazione, distribuzione, aggiornamenti, log: se ogni caso d'uso deve risolverli da zero, ogni caso d'uso costa un mese.

E spesso, onestamente, qualcosa si sbaglia anche a monte. Si progetta pensando solo a sé — copia locale, credenziali proprie, nessun log — e poi si chiede di dare lo strumento a tutti così com'è. Il mese di processo sta in parte rimediando a scelte di design che si potevano fare diversamente fin dal primo giorno.

Il mese non nasce dalla burocrazia. Nasce da uno strumento progettato per uno solo e poi chiesto per cento.

Come accorciare la strada

La soluzione non è saltare il processo, ma renderlo proporzionato e riusabile. Quattro mosse, alcune per chi costruisce, altre per chi governa.

1. Progettare per gli altri fin dal primo giorno. Invece di scaricare documenti in locale con credenziali personali, interrogarli al momento tramite un connettore centrale (per esempio un server MCP) che usa l'identità di chi chiede. Niente copie sparse, permessi rispettati, un solo punto da aggiornare. Metà delle domande della tabella sopra spariscono da sole.

2. Livelli di rischio, non un imbuto unico. Un percorso leggero per ciò che legge contenuti già accessibili a tutti, uno pieno per ciò che tocca dati riservati o scrive nei sistemi.

3. Un pilota prima di “tutti”. Dieci colleghi per due settimane, con un perimetro dichiarato. Si impara cosa serve davvero, e i requisiti si scrivono su dati veri invece che su ipotesi.

4. Una strada asfaltata. Se l'azienda offre una volta per tutte autenticazione, catalogo interno di skill e connettori, distribuzione e log, ogni nuovo caso d'uso eredita quelle risposte. Il mese si paga una volta sola, non a ogni idea.

Conclusione

I due giorni non sono una bugia e il mese non è un capriccio. Misurano due cose diverse: quanto costa far funzionare un'idea per una persona, e quanto costa renderla sicura e affidabile per tutti.

L'AI ha abbattuto la prima. La seconda la abbatteremo solo smettendo di trattare ogni skill come un progetto nuovo: chi costruisce progettando per gli altri dal primo giorno, chi governa costruendo una strada asfaltata che si percorre in giorni. Chi ci arriva per primo non avrà solo prototipi brillanti. Avrà colleghi che li usano.