Every week I meet companies telling me the same story. Someone on the team started using ChatGPT to write emails faster. Then another person found an AI plugin for Notion. Meanwhile IT blocked access to certain tools for security reasons, and the CEO announced in an all-hands that "AI is a strategic priority." The result is a chaotic accumulation of individual experiments — no shared architecture, no governance, no measurable ROI.
This article describes the path I use with my enterprise clients to move from that chaotic phase to a structured, sustainable AI adoption. It is not a linear process — organisations skip phases and circle back — but having a map helps you understand where you are and what to do next.
Phase 1 — An honest assessment of the current state
Before introducing any tool, you need to understand what is already happening. In every company I work with there is a layer of shadow AI: tools individuals use without the organisation knowing anything about it. Surfacing these practices is the first step — not to suppress them, but to understand where genuine demand exists.
The instrument I use is an informal audit in three passes: sample interviews (15–20 minutes per person, ten different profiles across functions), an anonymous survey on AI tool usage and perception, and an analysis of the most repetitive processes by department. The output is an opportunity map: where AI can remove low-value work and where, conversely, it risks creating problems if introduced carelessly.
Phase 2 — Define the security perimeter first
The IT team and the DPO must be allies, not obstacles. The problem is that they are often brought in too late — after someone has already shared sensitive data with an external model. The security conversation must happen before the first incident, not after.
For companies handling sensitive data — healthcare, finance, legal, public administration — the choice is not between using AI or not using it. It is between using it in a controlled way or using it chaotically. The concrete options are: cloud-based models with adequate Data Processing Agreements, on-premise deployment on owned infrastructure, or APIs with data non-retention clauses. Each carries different costs and constraints that need to be weighed against the specific use case.
The choice is not between using AI or not. It is between using it in a controlled way or using it chaotically.
Phase 3 — Identify two or three pilot use cases
The destination is not "the company uses AI." It is "this specific process costs 40% less and produces better results." To get there you need to start with concrete, measurable, low-risk use cases.
The best candidates for a pilot share certain characteristics: the process is repetitive and well-defined; a reference metric already exists (time, cost, quality); the required data is available and in a usable format; the team involved is willing to experiment. Typical examples include generating first drafts of documents, analysing customer feedback, automatically classifying support tickets, and summarising long reports.
What does not work as a pilot: ambiguous processes where human judgement is irreplaceable; tasks requiring implicit context that is difficult to make explicit; areas where a mistake carries immediate legal or reputational consequences.
Phase 4 — Build internal capability
A sustainable AI workflow does not depend on an external consultant keeping it alive. It requires internal people who understand how it works, how to configure it, and how to correct it when it produces wrong outputs. This competence is not acquired in a two-day course — it is built by doing, failing, and iterating on real cases.
The model that works best is the "distributed centre of competence": a small group (two to four people) with deeper expertise who act as a reference point for the rest of the organisation. Not a centralised team doing AI for everyone else, but a hub that enables others to do it themselves. The most effective training is anchored to the team's real processes, not to the generic use cases vendors put in their slide decks.
Phase 5 — Measure, communicate, and scale selectively
After three months of a pilot, the most critical moment is not deployment — it is internal reporting. Results must be communicated credibly, without inflating the numbers to justify future investment. If the pilot worked well, the data speaks for itself. If it worked partially, analysing honestly why it fell short is more useful than pretending a complete success.
Scalability is not automatic. A use case that works for the marketing team does not necessarily work for the operations team. Every expansion requires adapting the workflow, not copying and pasting it. The organisations that scale AI most effectively are those that treat every new use case with the same rigour as the first pilot: a clear hypothesis, a defined success metric, a structured feedback loop.
AI does not transform a company because it is powerful. It transforms it because someone decided how to use it, who is accountable for it, and how the outcome is measured.
The path I have described takes between six months and a year for mid-sized organisations. It is not fast. But it is the time needed to build something that outlasts the initial enthusiasm and survives the first public mistake.
If you are trying to understand which phase your organisation is in, I can help you take stock. The first conversation costs nothing.
Ogni settimana incontro aziende che mi raccontano la stessa storia. Qualcuno nel team ha iniziato a usare ChatGPT per scrivere le email più velocemente. Poi un'altra persona ha trovato un plugin AI per Notion. Nel frattempo IT ha bloccato l'accesso a certi strumenti per ragioni di sicurezza, e il CEO ha annunciato in un all-hands che "l'AI è una priorità strategica." Il risultato è un'accumulazione caotica di esperimenti individuali — nessuna architettura condivisa, nessuna governance, nessun ROI misurabile.
Questo articolo descrive il percorso che uso con i miei clienti enterprise per passare da quella fase caotica a un'adozione AI strutturata e sostenibile. Non è un processo lineare — le organizzazioni saltano fasi e tornano indietro — ma avere una mappa aiuta a capire dove si è e cosa fare dopo.
Fase 1 — Una valutazione onesta dello stato attuale
Prima di introdurre qualsiasi strumento, occorre capire cosa sta già succedendo. In ogni azienda con cui lavoro esiste uno strato di shadow AI: strumenti che i singoli usano senza che l'organizzazione ne sappia nulla. Far emergere queste pratiche è il primo passo — non per sopprimerle, ma per capire dove esiste una domanda reale.
Lo strumento che uso è un audit informale in tre passaggi: interviste campione (15–20 minuti per persona, dieci profili diversi per funzione), un sondaggio anonimo sull'uso e la percezione degli strumenti AI, e un'analisi dei processi più ripetitivi per dipartimento. L'output è una mappa delle opportunità: dove l'AI può rimuovere lavoro a basso valore e dove, al contrario, rischia di creare problemi se introdotta senza cura.
Fase 2 — Definire prima il perimetro di sicurezza
Il team IT e il DPO devono essere alleati, non ostacoli. Il problema è che vengono coinvolti troppo tardi — dopo che qualcuno ha già condiviso dati sensibili con un modello esterno. La conversazione sulla sicurezza deve avvenire prima del primo incidente, non dopo.
Per le aziende che trattano dati sensibili — sanità, finanza, settore legale, pubblica amministrazione — la scelta non è tra usare l'AI o non usarla. È tra usarla in modo controllato o usarla caoticamente. Le opzioni concrete sono: modelli cloud con adeguati Data Processing Agreement, deployment on-premise su infrastruttura propria, o API con clausole di non conservazione dei dati. Ognuna porta costi e vincoli diversi da valutare rispetto al caso d'uso specifico.
La scelta non è tra usare l'AI o non usarla. È tra usarla in modo controllato o usarla caoticamente.
Fase 3 — Identificare due o tre casi d'uso pilota
La destinazione non è "l'azienda usa l'AI." È "questo processo specifico costa il 40% in meno e produce risultati migliori." Per arrivarci occorre partire da casi d'uso concreti, misurabili, a basso rischio.
I migliori candidati per un pilota condividono alcune caratteristiche: il processo è ripetitivo e ben definito; esiste già una metrica di riferimento (tempo, costo, qualità); i dati necessari sono disponibili e in formato utilizzabile; il team coinvolto è disponibile a sperimentare. Esempi tipici includono la generazione di prime bozze di documenti, l'analisi del feedback dei clienti, la classificazione automatica dei ticket di supporto e la sintesi di report lunghi.
Cosa non funziona come pilota: processi ambigui dove il giudizio umano è insostituibile; attività che richiedono contesto implicito difficile da rendere esplicito; aree dove un errore porta conseguenze legali o reputazionali immediate.
Fase 4 — Costruire competenza interna
Un workflow AI sostenibile non dipende da un consulente esterno che lo tiene in vita. Richiede persone interne che capiscano come funziona, come configurarlo e come correggerlo quando produce output sbagliati. Questa competenza non si acquisisce in un corso di due giorni — si costruisce facendo, sbagliando e iterando su casi reali.
Il modello che funziona meglio è il "centro di competenza distribuito": un piccolo gruppo (due-quattro persone) con competenze più approfondite che funge da punto di riferimento per il resto dell'organizzazione. Non un team centralizzato che fa AI per tutti gli altri, ma un hub che abilita gli altri a farlo autonomamente. La formazione più efficace è ancorata ai processi reali del team, non ai casi d'uso generici che i vendor mettono nei loro slide deck.
Fase 5 — Misurare, comunicare e scalare selettivamente
Dopo tre mesi di pilota, il momento più critico non è il deployment — è il reporting interno. I risultati devono essere comunicati in modo credibile, senza gonfiare i numeri per giustificare investimenti futuri. Se il pilota ha funzionato bene, i dati parlano da soli. Se ha funzionato parzialmente, analizzare onestamente perché ha mancato l'obiettivo è più utile che fingere un successo completo.
La scalabilità non è automatica. Un caso d'uso che funziona per il team marketing non funziona necessariamente per il team operations. Ogni espansione richiede di adattare il workflow, non di copiarlo e incollarlo. Le organizzazioni che scalano l'AI più efficacemente sono quelle che trattano ogni nuovo caso d'uso con lo stesso rigore del primo pilota: un'ipotesi chiara, una metrica di successo definita, un feedback loop strutturato.
L'AI non trasforma un'azienda perché è potente. La trasforma perché qualcuno ha deciso come usarla, chi ne è responsabile e come si misura il risultato.
Il percorso che ho descritto richiede tra sei mesi e un anno per le organizzazioni di medie dimensioni. Non è veloce. Ma è il tempo necessario per costruire qualcosa che sopravviva all'entusiasmo iniziale e al primo errore pubblico.
Se stai cercando di capire in quale fase si trova la tua organizzazione, posso aiutarti a fare il punto della situazione. La prima conversazione non costa nulla.