Dopo oltre vent’anni trascorsi tra infrastrutture, networking, Unified Communication, sicurezza, processi aziendali e trasformazione digitale, ho imparato una cosa: i progetti tecnologici raramente falliscono perché manca la tecnologia.
Falliscono perché non sono stati definiti correttamente confini, responsabilità e obiettivi.
Con l’intelligenza artificiale rischiamo di ripetere lo stesso errore, ma a una velocità molto maggiore.
La domanda sbagliata da cui partono molte aziende
Oggi molti progetti iniziano con domande come:
Quale modello dobbiamo scegliere? È meglio utilizzare il cloud o installare l’AI localmente? Possiamo collegarla al CRM, alla posta elettronica e ai documenti aziendali?
Sono domande legittime. Ma non sono le prime domande da fare.
Prima dovremmo chiederci:
- quali dati siamo disposti ad affidare all’AI;
- quali decisioni può suggerire;
- quali azioni può eseguire;
- quale controllo non siamo disposti a perdere.
Il modello non sarà il vero vantaggio competitivo
L’adozione crescerà rapidamente. Presto quasi tutte le organizzazioni avranno accesso a modelli molto potenti, economici e progressivamente simili tra loro.
Quando tutti possono acquistare la stessa tecnologia, quella tecnologia smette di essere un elemento differenziante.
Il vantaggio competitivo non sarà quindi possedere il modello migliore. Sarà avere:
- dati affidabili;
- processi comprensibili;
- integrazioni controllate;
- responsabilità definite;
- persone capaci di verificare;
- un’architettura che sappia distinguere opportunità e rischio.
Il modello potrà essere sostituito. L’organizzazione costruita intorno al modello sarà molto più difficile da replicare.
L’AI non è più soltanto un’applicazione
Nel mio lavoro di Solution Engineer mi occupo di comprendere requisiti, analizzare processi e progettare architetture tecnologiche integrate.
Osservando l’evoluzione attuale, vedo l’AI trasformarsi da semplice strumento di produttività a nuovo livello dell’infrastruttura aziendale.
Un assistente che riassume un documento è un’applicazione. Un agente che può consultare database, leggere email, interrogare il CRM, generare offerte e modificare sistemi aziendali è parte dell’infrastruttura operativa.
E deve essere progettato come tale.
Servono identità, autorizzazioni, registrazione delle attività, separazione degli ambienti, continuità operativa e procedure di ripristino.
Non concederei mai a un nuovo collaboratore accesso indiscriminato a posta, documenti, clienti e sistemi. Perché dovremmo concederlo a un agente AI?
Cloud e AI locale non sono avversari
Spesso la discussione viene ridotta a una contrapposizione: AI cloud contro AI locale.
Ritengo che la vera risposta sia quasi sempre un’architettura ibrida.
- Un contenuto pubblico può essere elaborato nel cloud.
- Un contratto riservato potrebbe richiedere un ambiente privato.
- Una procedura interna può essere interrogata attraverso un sistema RAG controllato.
- Una password non dovrebbe raggiungere nessun modello.
- Una risposta commerciale può essere preparata dall’AI, ma approvata da una persona.
- Un’azione infrastrutturale dovrebbe richiedere autorizzazioni precise e tracciabilità completa.
La scelta dell’ambiente dovrebbe dipendere dal dato, dal rischio e dall’effetto prodotto dall’azione. Non dall’entusiasmo per una determinata tecnologia.
Il vero tema è il livello di autonomia
Non tutte le automazioni AI devono arrivare allo stesso livello. Possiamo immaginare cinque passaggi:
- l’AI osserva;
- l’AI suggerisce;
- l’AI prepara una bozza;
- l’AI esegue dopo un’approvazione;
- l’AI agisce autonomamente entro limiti prestabiliti.
Uno degli errori più frequenti è considerare il quinto livello come l’obiettivo naturale di ogni progetto. Non lo è.
In alcuni processi il massimo valore si ottiene al terzo livello: l’AI analizza, organizza e prepara, mentre una persona mantiene la decisione finale.
La soluzione più evoluta non è sempre quella con maggiore autonomia. È quella che assegna il livello di autonomia corretto al rischio del processo.
La responsabilità non può essere delegata al modello
Quando una risposta generata dall’AI è sbagliata, non possiamo limitarci a dire: “Ha sbagliato l’algoritmo”.
Qualcuno ha scelto il modello, deciso quali dati rendergli disponibili, scritto le istruzioni, autorizzato gli strumenti e stabilito se la risposta dovesse diventare automaticamente un’azione.
La responsabilità rimane dell’organizzazione.
Anche l’AI Act europeo, pur con le semplificazioni e le proroghe introdotte dall’AI Omnibus, non elimina la necessità di classificare i sistemi, governare i dati e mantenere un controllo proporzionato.
La conformità dovrebbe essere la conseguenza di una buona progettazione. Non l’unico motivo per iniziare a progettare bene.
La domanda da cui partire
L’AI rappresenta una straordinaria opportunità. Può ridurre attività ripetitive, rendere accessibile la conoscenza aziendale, accelerare l’analisi e migliorare la qualità di molti processi.
Ma introdurre l’AI non significa semplicemente aggiungere un chatbot. Significa ridisegnare il rapporto tra persone, dati, applicazioni e decisioni.
Per questo credo che la domanda iniziale non dovrebbe essere:
Come introduciamo l’AI in azienda?
Dovrebbe essere:
Quali decisioni vogliamo migliorare, quali dati siamo disposti ad affidarle e dove vogliamo che l’AI si fermi?
È da questa risposta che nasce una vera strategia AI. Tutto il resto è tecnologia.
Articoli correlati
- AI Act 2026: cosa cambia per aziende e professionisti
- Come progettare una soluzione di AI locale
- RAG: collegare l’AI ai documenti aziendali
- Checklist di sicurezza per agenti AI e automazioni
Fonti
Vuoi seguire l’evoluzione dell’AI senza perdere di vista infrastrutture, sicurezza e impatto reale? Iscriviti gratuitamente alla newsletter di Basi di AI.
