L'AI che ti fanno usare esce dal tuo perimetro. La nostra no.
Immagina la scena. Un fornitore ti mostra la sua nuova piattaforma di gestione cloud, e a un certo punto arriva il momento che serve a chiudere la vendita: apre l'assistente, scrive in linguaggio naturale "creami un ambiente di collaudo con tre macchine e un database", e in pochi secondi l'ambiente compare. Applausi. È effettivamente notevole.
Poi qualcuno in fondo alla sala, di solito quello che dovrà firmare, fa la domanda giusta: dove gira quel modello?
Nella maggior parte dei casi la risposta, tradotta dal linguaggio commerciale, è questa: il modello gira da qualche parte fuori. Quando scrivi la tua richiesta, la descrizione del tuo ambiente — quante macchine hai, come si chiamano, come sono configurate, a volte cosa contengono — esce dalla tua infrastruttura, attraversa la rete e arriva a un servizio di intelligenza artificiale che non è tuo, spesso nemmeno europeo. Torna indietro con un piano, e l'ambiente viene creato.
Per molte aziende questo va benissimo. Per una parte crescente, invece, è esattamente il punto in cui la demo smette di essere una buona notizia.
Perché "dove gira il modello" non è un dettaglio tecnico
C'è la tentazione di trattare questa domanda come una pignoleria da addetti ai lavori. Non lo è. È il punto in cui una scelta di prodotto diventa una scelta di rischio, e chi deve rispondere di quel rischio lo sa.
Quando la descrizione della tua infrastruttura esce dal perimetro, escono tre cose insieme, e vale la pena separarle perché hanno pesi diversi.
Esce la mappa di come sei fatto. Non i dati degli utenti, spesso, ma qualcosa che in certi contesti conta quanto i dati: la topologia, i nomi degli ambienti, la dimensione delle risorse, la struttura di chi accede a cosa. È l'informazione che serve a qualcuno per capire dove sei fragile.
Esce il controllo su dove finisce quell'informazione. Un servizio esterno ha i suoi termini, la sua giurisdizione, la sua politica di conservazione. Puoi leggerli, puoi fidarti, ma non li governi. E se cambiano, lo scopri dopo.
Ed esce, soprattutto, la possibilità di dire con certezza dove sono i tuoi dati. Che è precisamente la cosa che a un operatore di servizi pubblici, a una pubblica amministrazione, a un'azienda in un settore regolato viene chiesto di garantire — non di sperare, di garantire.
Per un'azienda privata senza vincoli particolari, tutto questo è una valutazione costi-benefici che spesso si chiude a favore della comodità. Per chiunque risponda a requisiti di sovranità del dato, non è una valutazione. È un muro.
Il bivio che il mercato ti mette davanti
Il risultato è che, in Europa, chi vuole portare l'automazione intelligente sulla propria infrastruttura si trova quasi sempre davanti a due porte, e nessuna delle due è quella giusta.
Dietro la prima porta c'è la rinuncia. Tieni l'AI fuori, resti sui processi manuali, accetti che ogni ambiente da creare sia giorni di lavoro specialistico e che ogni diagnosi di un guasto complesso sia ore di una persona rara. Sei sovrano, ma sei lento, e la lentezza in infrastruttura ha un costo che si accumula silenziosamente.
Dietro la seconda porta c'è la resa. Prendi l'automazione intelligente che il mercato offre, ottieni la velocità, e accetti che una parte del tuo perimetro non sia più davvero tua. Sei veloce, ma hai firmato una dipendenza che, il giorno in cui un auditor te la chiede, non sai come sciogliere.
La maggior parte delle piattaforme di gestione cloud commerciali, comprese alcune molto valide, ti fa scegliere tra queste due porte — perché sono costruite così. L'AI è un servizio esterno che integrano, non un componente che vive dentro la tua infrastruttura. È una scelta ragionevole dal loro punto di vista: integrare un'API di terzi costa una frazione di quello che costa portare i modelli dentro il perimetro e tenerli lì. Ma il costo che loro risparmiano lo paghi tu, sotto forma di quella dipendenza.
Abbiamo costruito la nostra automazione perché eravamo convinti che esistesse una terza porta. E che valesse la fatica di aprirla.
Cosa vuol dire, in concreto, "dentro il perimetro"
La terza porta è un'AI che opera interamente all'interno dell'organizzazione, su una catena tecnologica interamente open source. Detta così suona come uno slogan, quindi conviene smontarla nei pezzi che la rendono vera, perché è nei pezzi che si vede la differenza.
Il modello gira on-premise. L'elaborazione avviene nell'infrastruttura del cliente. La descrizione dell'ambiente, le richieste, il contesto operativo non attraversano la rete verso un servizio esterno, per il semplice fatto che il servizio esterno non c'è. Non è "i dati sono cifrati in transito verso un fornitore fidato": è che non c'è transito.
La catena è open source e reversibile. Non c'è un componente proprietario chiuso al centro dell'automazione, di cui non sai cosa fa e che non puoi sostituire. L'intera catena è ispezionabile e, il giorno in cui vuoi cambiare, sostituibile. Non c'è un'uscita da negoziare, perché non c'è un lucchetto.
Il modello propone, il motore di automazione esegue. Questo è il principio che regge tutto, ed è quello che rende la cosa difendibile in un audit. L'AI non tocca mai direttamente l'infrastruttura. Produce un piano — la sequenza di operazioni che intende compiere — e quel piano viene mostrato per verifica e approvazione. Solo dopo, un motore di automazione tradizionale, basato su Ansible e AWX con i playbook versionati sul repository dell'organizzazione, lo esegue in modo tracciato. Nessuna risorsa viene creata senza un'approvazione esplicita.
Quest'ultimo punto merita una sottolineatura, perché è dove l'AI on-premise smette di essere solo una questione di sovranità e diventa una questione di affidabilità operativa. Un'automazione che propone e attende conferma è un'automazione che puoi lasciare in mano a chi non è uno specialista, senza che un errore di comprensione diventi un errore di produzione. E ogni operazione, essendo eseguita dal motore di automazione e non dal modello, lascia una registrazione completa: chi ha chiesto cosa, cosa è stato proposto, cosa è stato approvato, cosa è stato fatto. Non come funzione aggiunta dopo, ma come conseguenza naturale di com'è costruita.
La normativa sta andando in questa direzione, non nell'altra
Vale la pena guardare dove sta andando il quadro europeo, perché aiuta a capire se questa è un'ossessione da puristi o una direzione di marcia.
Dal 2 agosto 2026 è in applicazione generale l'AI Act, il primo regolamento organico al mondo sull'intelligenza artificiale. Gli obblighi più stringenti sui sistemi ad alto rischio sono stati posticipati — la maggior parte arriverà a fine 2027 — ma la direzione è già leggibile, ed è la stessa che i responsabili di infrastruttura conoscono da GDPR e NIS2: tracciabilità, spiegabilità, sorveglianza umana, capacità di dimostrare cosa fa un sistema e perché.
Un'automazione in cui il modello propone e un motore tracciato esegue, dentro un perimetro che non lascia, non è un modo per aggirare quei requisiti. È il modo più diretto per soddisfarli — perché la tracciabilità non è un layer aggiunto sopra, è il funzionamento stesso del sistema. Chi ha scelto la seconda porta, l'AI-come-servizio-esterno, quei requisiti dovrà rincorrerli. Chi ha costruito dentro il perimetro se li ritrova già in casa.
Non è una rinuncia alla potenza
C'è un'obiezione onesta a tutto questo, e va affrontata invece di aggirarla: un modello che gira dentro il mio perimetro non sarà meno potente di quello enorme che gira nei data center di un hyperscaler?
La risposta è che dipende da cosa gli chiedi di fare, e che per il lavoro di cui stiamo parlando la domanda è meno decisiva di quanto sembri. Qui il modello non deve scrivere poesie né ragionare su qualsiasi cosa esista: deve capire una richiesta operativa circoscritta — creare un ambiente, aggiungere spazio, aprire una porta, diagnosticare uno scostamento — e tradurla in un piano su un catalogo di operazioni note. È un compito specializzato, e su un compito specializzato un modello che gira in casa, che conosce il contesto e opera su un dominio definito, è più che sufficiente. La potenza bruta di un modello generalista enorme, in questo scenario, in gran parte non la useresti nemmeno.
E c'è un rovescio che conta: il modello in casa impara il tuo ambiente senza che il tuo ambiente esca di casa. Le anomalie che riconosce sono le tue, il comportamento normale che apprende è quello della tua infrastruttura. Non è un modello generico a cui spieghi ogni volta chi sei. È un modello che sta dove stanno i dati.
Perché per noi non è un argomento di vendita
Abbiamo raccontato altrove perché un'infrastruttura che non puoi lasciare non è un servizio. L'AI on-premise è la stessa idea, portata sul componente più nuovo e più delicato dello stack.
Quando progettiamo un'infrastruttura per un cliente, il nostro lavoro non è renderlo dipendente da noi. È metterlo in condizione di governare quello che ha, con le persone che ha, potendo cambiare idea quando serve. Un'automazione intelligente che vive dentro il suo perimetro, su tecnologie che può ispezionare e sostituire, è coerente con quel lavoro. Un'automazione che lo costringe a esporre la propria infrastruttura a un servizio esterno per poterla usare, no — sarebbe la stessa dipendenza che passiamo il tempo a smontare, rientrata dalla finestra sotto forma di comodità.
È la differenza tra un fornitore e un partner, detta sul terreno più concreto che ci sia. Un fornitore ti vende la funzione e non si preoccupa di cosa quella funzione ti obbliga a concedere. Un partner parte da cosa puoi permetterti di concedere, e costruisce la funzione dentro quel confine.
L'AI dentro il perimetro non è la versione con un vincolo in più. È la versione senza il vincolo che conta.
Ne parliamo?
Se stai valutando come portare automazione e analisi intelligente sulla tua infrastruttura senza doverla far uscire dal tuo controllo, possiamo mostrarti come funziona la nostra — su ambienti reali, con il modello che gira dentro il perimetro — e discutere apertamente cosa è già operativo e cosa no.
Commenti