Episodio 2/7. Dal monopolio tecnico alla possibilità di costruire
Per anni, in azienda, chi vedeva un’opportunità non poteva agire direttamente. Doveva passare da IT, sviluppo, data team, automazione, procurement tecnologico. Prima ancora di capire se un’idea fosse buona, che si parlasse di ottimizzazione del lavoro o di un nuovo servizio da proporre ai clienti, bisognava capire se qualcuno con le chiavi del sistema fosse disposto a farla entrare nel mondo reale.
Il potere stava in chi conosceva strumenti, codice, integrazioni, infrastruttura. E questo potere, diciamolo chiaramente, veniva spesso esercitato con una dose non trascurabile di “ti spiego perché non si può fare”. Per anni molte aziende hanno scambiato la complessità tecnica con un diritto feudale: chi possedeva il linguaggio dei sistemi decideva anche il perimetro del possibile.
E quel potere non viveva solo dentro l’azienda. Viveva anche fuori, nei vendor, nelle piattaforme, negli integratori, nei sistemi gestionali, nei software “customizzabili” che promettevano flessibilità e spesso consegnavano dipendenza. Per anni il software non è stato solo uno strumento: è stato un recinto. Decideva quali processi erano possibili, quali modifiche costavano troppo, quali personalizzazioni richiedevano mesi, quali dati potevano uscire e quali invece restavano imprigionati nell’ennesimo ecosistema proprietario. Il lock-in non era un effetto collaterale. Era una forma di potere.
L’AI generativa, il low-code e gli agenti stanno smontando questo monopolio. Non perché trasformino tutti in ingegneri, e nemmeno perché rendano irrilevante la competenza tecnica. Sarebbe una sciocchezza, e anche abbastanza pericolosa. Il punto è un altro: abbassano la soglia tecnica necessaria per “prototipare”.
Oggi una persona di business, di operations, di marketing, di HR o di produzione può costruire una prima automazione, simulare un processo, generare una dashboard, disegnare un workflow, prototipare un assistente interno, interrogare dati, testare un’idea e arrivare alla conversazione non più con una richiesta astratta, ma con una prima evidenza prototipata.
Prima dicevi: “avrei un’idea”. Adesso puoi dire: “l’ho provata, funziona così, qui sono i limiti, qui serve aiuto tecnico”.
È un cambio politico enorme: l’AI non sta solo potenziando i team tecnici. Sta distribuendo capacità operative a funzioni che prima dovevano sempre aspettare qualcuno per passare dall’intuizione all’azione.
Non sparisce la competenza tecnica. Sparisce il monopolio dell’esecuzione. È una cosa molto diversa.
Anzi, il ruolo tecnico diventa più importante, ma cambia natura. Non è più solo il custode del fare. Diventa il progettista delle piattaforme, delle regole, degli ambienti sicuri, dei guardrail e delle architetture che permettono a molti più attori di costruire senza creare disastri. Meno “vieni da me se vuoi fare qualcosa”. Più “ti metto nelle condizioni di fare bene, in sicurezza, dentro un sistema governato”.
E cambia anche il rapporto con il software enterprise. L’obiettivo non è sostituire ogni sistema o dichiarare guerra ai vendor, che sarebbe un’altra forma di ingenuità. Il punto è costruire layer intelligenti sopra, dentro e tra i sistemi esistenti: agenti, micro-tool, interfacce, workflow e automazioni capaci di ridurre tempi di customizzazione, dipendenza dai fornitori e rigidità dei processi. Il software smette di essere sempre il confine ultimo del possibile e diventa una base su cui innestare nuove capacità.
Il nuovo modello operativo. Qui bisogna evitare due errori speculari, entrambi molto aziendali. Il primo: il vecchio mondo in cui tutto passa da pochi specialisti, con code infinite, priorità opache e la sensazione meravigliosa di avere un’idea oggi e rivederla in un comitato tra sei mesi. Il secondo: il caos totale, in cui chiunque costruisce qualsiasi cosa con dati sensibili, strumenti non approvati e zero governance, cioè la versione corporate del “vediamo cosa succede”. Di solito succede qualcosa di costoso.
Il modello giusto è un federated operating model: capacità distribuita, ma su piattaforme, regole e guardrail centrali. Non tutti fanno tutto. Ma molti più attori possono iniziare, testare, prototipare e migliorare, dentro un perimetro tecnico e normativo chiaro.
Questo modello serve anche a ridurre il lock-in: non perché elimina la necessità di software solidi, ma perché evita che ogni miglioramento diventi automaticamente un progetto infinito di customizzazione, consulenza e dipendenza tecnica.
Cinque principi: piattaforme pre-approvate, privacy by design, classificazione del rischio dei casi d’uso in linea con l’AI Act, supervisione umana tracciabile, e un AI/Data Governance Office leggero che definisce policy, guardrail e standard invece di costruire tutto da zero.
Formula finale: non caos aperto, ma libertà governata.