“Self-hosted AI” è diventata una delle espressioni più utilizzate nel mercato dell’intelligenza artificiale aziendale. Spesso viene interpretata come sinonimo di “tutto gira nei nostri server” oppure “nessun dato esce dall’azienda”.
In realtà, le architetture moderne sono molto più sfumate e il nuovo modello presentato da Cursor è un ottimo esempio per capire perché.
Il 2 settembre 2026 Cursor ha annunciato Self-Hosted Machines per i propri Cloud Agents. La fonte ufficiale Cursor descrive un’architettura nella quale la parte operativa dell’agente può essere eseguita su macchine controllate direttamente dall’organizzazione.
Il worker può trovarsi su un laptop, una VM, un server interno o un pool dinamico di macchine. È quella macchina a contenere la working copy del repository, modificare i file, eseguire comandi e accedere ai servizi interni autorizzati.
Per molte organizzazioni è un cambiamento importante: l’agente può lavorare vicino al codice, ai sistemi interni e alle pipeline già esistenti senza richiedere che l’intero ambiente di esecuzione venga trasferito in una macchina del provider.
Ma la parte più interessante dell’annuncio è un’altra: Self-Hosted Machines non equivale a un’architettura completamente on-premise.
Tool locali, modello e orchestrazione nel cloud
Con Self-Hosted Machines, l’ambiente di esecuzione si sposta nell’infrastruttura del cliente, mentre agent loop, inference e planning restano nel cloud Cursor.
Il funzionamento descritto da Cursor è relativamente semplice:
- un worker installato sulla macchina aziendale apre una connessione in uscita verso il servizio;
- quando l’agente deve compiere un’azione, il sistema cloud invia la chiamata al worker locale;
- il worker modifica file, esegue comandi o interagisce con gli strumenti autorizzati e restituisce il risultato al cloud, dove il modello decide il passaggio successivo.
Cursor segnala inoltre che questi output possono contenere codice.
Questo non rende l’architettura intrinsecamente negativa o insicura. Al contrario, può offrire vantaggi concreti rispetto a un agente eseguito interamente nell’infrastruttura del provider: accesso più diretto a servizi interni, possibilità di utilizzare hardware personalizzato, integrazione con pipeline difficili da riprodurre nel cloud e maggiore controllo sull’ambiente nel quale vengono eseguiti i comandi.
Il punto è architetturale: esecuzione self-hosted non significa necessariamente inference self-hosted, né significa automaticamente che tutti i dati rimangano nel perimetro aziendale.
La domanda giusta non è “cloud o locale?”
Per un Direttore IT o per chi deve valutare una piattaforma AI, la distinzione binaria tra cloud e locale sta diventando insufficiente.
Un sistema moderno può essere composto da molti livelli differenti:
- applicazione e interfaccia,
- knowledge base,
- database vettoriale,
- retrieval,
- modello generativo,
- orchestratore degli agenti,
- tool,
- log,
- conversazioni
- e infrastruttura di esecuzione.
Ognuno di questi livelli può essere locale oppure remoto.
Un’azienda potrebbe mantenere database e documenti on-premise, eseguire il retrieval nella propria rete e usare un modello esterno soltanto per la generazione. Un altro sistema potrebbe mantenere il modello nel cloud ma eseguire i tool localmente. Una terza organizzazione potrebbe decidere di portare anche il modello su hardware interno.
Per questo è più utile parlare di architettura ibrida e mappare i flussi reali.
La domanda diventa: quali dati attraversano quali confini?
È una domanda molto più concreta di “il prodotto è self-hosted?”.
Un agente aumenta l’importanza dei confini
Il problema diventa ancora più rilevante con gli AI Agent.
Un chatbot tradizionale riceve un prompt e genera una risposta. Un agente può invece modificare file, eseguire codice, usare browser, chiamare API, interrogare database e interagire con applicazioni interne.
Questo aumenta sia il valore potenziale sia la superficie di controllo necessaria.
Se un agente può accedere al repository aziendale, bisogna sapere quali directory può leggere. Se può collegarsi a un database, le credenziali dovrebbero essere proporzionate al task. Se può usare un browser, è necessario decidere quali destinazioni siano raggiungibili. Se i risultati dei tool vengono inviati a un modello esterno, bisogna comprendere quali informazioni potrebbero essere contenute in quegli output.
Il system prompt non è sufficiente a definire questi limiti, servono:
- autorizzazioni tecniche,
- segmentazione,
- logging
- e policy di rete.
La possibilità di eseguire i tool nella rete interna mostra come gli agenti stiano iniziando a essere trattati come workload infrastrutturali e non soltanto come funzionalità dell’interfaccia.
Self-hosted non è sinonimo di sovranità completa
Per le aziende è importante evitare anche un secondo equivoco: self-hosting e sovranità del dato non coincidono automaticamente.
Se il modello è esterno, una parte del contesto deve necessariamente essere inviata al provider per ottenere una risposta. Se i tool producono output che vengono restituiti al modello, anche quegli output fanno parte del flusso informativo.
Ciò non significa che un’architettura ibrida sia da evitare. Può anzi rappresentare un compromesso molto efficace tra controllo e capacità.
La differenza sta nella minimizzazione.
Un sistema ben progettato può evitare di inviare interi archivi quando bastano pochi frammenti selezionati. Il retrieval può avvenire localmente e costruire un contesto strettamente necessario al task. Le credenziali possono restare nell’ambiente locale. I tool possono applicare filtri e limitazioni prima di restituire informazioni al modello.
In altre parole, non serve necessariamente scegliere tra “tutto locale” e “tutto cloud”. Serve sapere quale parte del processo debba rimanere sotto il controllo diretto dell’organizzazione.
Questa architettura non garantisce automaticamente conformità a GDPR, AI Act o altri obblighi. La conformità dipende dal caso d’uso, dal ruolo dell’organizzazione, dai dati trattati e dalle misure applicabili. Tuttavia, una mappa chiara dei flussi è una condizione importante per poter valutare correttamente rischi e responsabilità.
Perché interessa anche PMI e studi professionali
Il tema può sembrare molto tecnico, ma riguarda direttamente anche PMI e studi professionali.
Queste realtà spesso non vogliono costruire grandi infrastrutture AI interne, ma allo stesso tempo gestiscono documenti, clienti e informazioni che non possono essere trattati senza criteri chiari.
Una soluzione ibrida può permettere di utilizzare la capacità di modelli esterni senza trasferire necessariamente l’intera knowledge base.
Per esempio, documenti e indice vettoriale possono restare su un server dell’organizzazione. Una domanda viene analizzata localmente, il retrieval recupera soltanto i passaggi pertinenti e al modello esterno viene inviato quel contesto limitato. L’output torna poi nell’applicazione aziendale.
In altri casi, soprattutto con pochi utenti e workload prevedibili, anche il modello può essere eseguito localmente attraverso strumenti open source.
La scelta non dovrebbe essere ideologica. Dovrebbe dipendere da costo, prestazioni, sensibilità dei dati e complessità del task.
Gol-IA: separare knowledge base e motore AI
Questo è uno dei principi alla base di Gol-IA.
Gol-IA nasce come hub AI locale e ibrido per aziende, studi professionali e PA. L’obiettivo è mantenere sotto il controllo dell’organizzazione applicazione, documentazione, knowledge base, retrieval, utenti e workflow e trattare il modello come una componente selezionabile.
Per una realtà con pochi utenti il sistema può funzionare completamente on-premise utilizzando modelli locali e open source.
Per esigenze più complesse può invece adottare un modello ibrido: la conoscenza resta nell’infrastruttura aziendale, il retrieval seleziona le informazioni rilevanti e a un modello esterno viene inviato soltanto il contesto necessario.
Lo stesso principio vale per gli agenti.
Prima di collegare un agente a email, database, filesystem o applicazioni è necessario stabilire quali strumenti può utilizzare, quali informazioni può leggere e quali azioni richiedono una conferma.
Contattaci per avere informazioni in anteprima su Gol-IA:
Una Consulenza AI può aiutare proprio a costruire questa mappa: quali componenti devono restare locali, quali possono utilizzare servizi esterni, quali dati attraversano il confine, quali log devono essere conservati e quali permessi concedere a ogni workflow.
La novità di Cursor è quindi interessante anche oltre il mondo dello sviluppo software. Mostra che il mercato sta andando verso architetture sempre più ibride e modulari.
E rende evidente un principio destinato a diventare centrale per l’AI enterprise: non basta sapere dove gira l’agente. Bisogna sapere dove gira ogni parte dell’agente e quali dati attraversano ciascun confine.
Lascia un commento