Azienda Pubblicato il 2026-06-15 · 5 min di lettura

Perché distribuiamo l'AI come binari installabili, non come SaaS cloud

Inferenza locale, audit controllato dal cliente e una procedura di procurement che esiste già. Tre ragioni strutturali per cui i prodotti AI di Software Tailor sono installer desktop, non tenant nel nostro cloud.

La maggior parte della gamma AI Suite viene installata sulla macchina dell'utente. Non esiste un tenant. Non esiste un login cloud che dia accesso al motore di inferenza. Le app desktop dialogano con un processo locale aisuite-server che, a sua volta, dialoga con un modello on-device o con un AI Server controllato dal cliente in esecuzione all'interno della rete del cliente. Quella scelta — installer desktop, non SaaS — è deliberata, e le ragioni meritano di essere messe per iscritto.

Motivo 1: gli acquirenti regolamentati non possono mettere prompt di produzione nel cloud di qualcun altro

L'EU AI Act, in vigore dal 2024, classifica un insieme sostanziale di workflow aziendali come "ad alto rischio" e impone al deployer obblighi di conservazione dei registri, supervisione umana e gestione dei dati ^[1]. Quadri equivalenti o paralleli esistono in tutti gli Stati membri dell'OECD ^[2], e le agenzie federali statunitensi operano in base al NIST AI Risk Management Framework quando acquistano sistemi di AI ^[3]. Nessuno di questi quadri vieta l'AI cloud; richiedono al deployer di poter dimostrare, contestualmente e per ogni richiesta, cosa sia stato inviato dove e cosa sia tornato indietro.

In pratica, quel requisito si scontra con il funzionamento odierno delle API LLM cloud. Un responsabile compliance nel farmaceutico non può estrarre un audit trail per singolo prompt da un SaaS di terzi per un workflow che tratta identificativi dei pazienti, anche quando il SaaS è contrattualmente allineato al GDPR. Hanno bisogno che il prompt e la risposta non lascino mai una rete di loro proprietà. Il modo più pulito per dargli questo è distribuire l'AI come un binario che il cliente esegue all'interno del proprio perimetro — che è ciò che facciamo.

Non è un acquirente ipotetico. La coorte di clienti a cui distribuiamo dal 2007 comprende sei organizzazioni Fortune Global 500 nei settori farmaceutico, finanziario, pubblico, legale, della difesa e dell'energia ^[4]. Ognuno di quei settori ha almeno un workflow in cui la risposta alla domanda "dove avviene l'inferenza?" decide se la conversazione di procurement abbia inizio.

Motivo 2: un binario installabile rispecchia il modo in cui le aziende acquistano effettivamente il software

La procedura di acquisto di un'applicazione desktop è ben compresa nelle grandi organizzazioni IT. L'applicazione viene pacchettizzata, distribuita tramite SCCM o Intune o Jamf, governata dalle stesse group policy di Microsoft Office, rimossa quando il laptop viene dismesso. Procurement, security review ed end-user-computing hanno tutti processi consolidati da decenni per questo. AI Suite si inserisce direttamente.

Il SaaS cloud, al contrario, richiede una procedura parallela: una vendor-risk review su base per-tenant, una conversazione di identity federation, audit continui sulla postura del fornitore e una negoziazione costante su quali obblighi coprano cosa in caso di incidenti. Utile per alcuni tipi di software. Non adatto al tipo di workflow AI che i nostri clienti stanno costruendo.

Distribuendo app installabili che si autenticano verso l'identity provider del cliente — Microsoft Entra ID o Google Workspace tramite OpenID Connect — e che non memorizzano nulla sui nostri server oltre al roster dell'organizzazione e al log di audit delle azioni amministrative, collochiamo la conversazione di procurement nella casella che già sa come gestire.

Motivo 3: zero progetti falliti dal 2007 dipende dal non dipendere dall'uptime di qualcun altro

Distribuiamo software personalizzato da diciannove anni con un record di zero progetti falliti dal 2007 ^[4]. Quel record esiste perché il team controlla ogni livello della delivery: codice, build, test, artefatto di deployment. Nel momento in cui rendiamo il workflow di produzione di un cliente dipendente dalla disponibilità del cloud di un'altra azienda, quel record cessa di essere nostro da difendere.

I fornitori di AI cloud hanno outage. Effettuano throttling. Modificano i prezzi. Ritirano modelli. Ritirano intere API. I clienti che serviamo nel farmaceutico e nella difesa non possono permettersi che il loro dossier normativo annuale si blocchi perché un endpoint di modello che non possiedono è stato migrato. Quindi non li mettiamo su uno. Il modello vive sulla macchina del cliente, l'inferenza avviene sulla macchina del cliente, e l'unica cosa sulla nostra infrastruttura è la leggera superficie di amministrazione che utilizzano per gestire il proprio deployment.

Cosa significa per la valutazione

Se sei un responsabile compliance, un CIO o un CTO che valuta l'AI locale per un deployment aziendale, le domande pertinenti hanno un aspetto diverso rispetto a una valutazione SaaS cloud:

Dove avviene l'inferenza? Sul dispositivo dell'utente, o su un server che il cliente controlla. Non sul nostro.
Cosa esce dal perimetro? Solo il roster dell'organizzazione e le azioni amministrative. Nessun prompt, nessuna risposta, nessun contenuto di documenti.
Qual è l'audit trail? JSONL privo di contenuto, memorizzato localmente, esportabile. Il modello non vede mai contenuti su cui non gli sia stato detto di agire, e la riga di audit non vede mai alcun contenuto.
Cosa succede quando il fornitore esce di scena? I binari che il cliente ha installato continuano a funzionare. L'AI Server locale che hanno arruolato continua a servire. Non è richiesto alcun re-platforming.

Queste sono le quattro domande per cui abbiamo costruito AI Admin Console e Local AI Suite per rispondere in modo pulito. L'articolo su EU AI Act compliance e deployment on-prem tratta il lato regolamentare con maggiore profondità.

Riferimenti

European Commission. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Consultato il 2026-06-15.
OECD AI Policy Observatory. "National AI policies." oecd.ai. Consultato il 2026-06-15.
NIST. "AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Consultato il 2026-06-15.
Software Tailor. "Past clients." softwaretailor.com/past-clients.htm. Consultato il 2026-06-15.

Valuta lo stesso approccio su un carico di lavoro reale.

Un pilot gratuito di 1 settimana percorre un autentico lavoro del cliente — inferenza locale, identità controllata dal cliente, audit controllato dal cliente.

Avvia un pilot gratuito di 1 settimana