La maggior parte della linea AI Suite si installa sulla macchina dell'utente. Non esiste un tenant. Non c'è un login cloud che limita l'accesso al motore di inferenza. Le app desktop comunicano con un processo locale aisuite-server che a sua volta comunica con un modello on-device o con un AI Server controllato dal cliente e in esecuzione all'interno della rete del cliente. Questa scelta — installer desktop, non SaaS — è deliberata, e le ragioni meritano di essere annotate.

Ragione 1: gli acquirenti regolamentati non possono mettere prompt di produzione nel cloud di terzi

Il Regolamento UE sull'AI, in vigore dal 2024, classifica un insieme sostanziale di flussi di lavoro aziendali come «ad alto rischio» e impone obblighi di registrazione, supervisione umana e gestione dei dati al deployer [1]. Quadri equivalenti o paralleli esistono negli stati membri OCSE [2], e le agenzie federali USA operano secondo il NIST AI Risk Management Framework nell'acquisto di sistemi AI [3]. Nessuno di questi quadri vieta l'AI cloud; richiedono che il deployer possa dimostrare, contemporaneamente e su richiesta, cosa è stato inviato dove e cosa è tornato.

In pratica, questo requisito si scontra con il funzionamento attuale delle API LLM cloud. Un responsabile compliance farmaceutica non può estrarre una traccia di audit per prompt da un SaaS di terzi per un flusso di lavoro che elabora identificativi pazienti, anche se il SaaS è contrattualmente conforme al GDPR. Potrebbe essere necessario che prompt e risposta non escano mai da una rete di sua proprietà. Il modo più pulito per garantire questa possibilità è distribuire l'AI come binario che il cliente esegue all'interno del proprio perimetro — ed è ciò che facciamo.

Questo non è un acquirente ipotetico. La coorte di clienti a cui distribuiamo dal 2007 include sei organizzazioni Fortune Global 500 nei settori farmaceutico, finanziario, governativo, legale, difesa ed energia [4]. Ognuno di questi settori ha almeno un flusso di lavoro in cui la risposta a «dove avviene l'inferenza?» decide se la conversazione di acquisto inizia o meno.

Ragione 2: un binario installabile corrisponde al modo in cui le aziende acquistano realmente software

Il processo di acquisto di un'applicazione desktop è ben compreso all'interno delle grandi organizzazioni IT. L'applicazione viene confezionata, distribuita tramite SCCM o Intune o Jamf, gestita con le stesse policy di gruppo di Microsoft Office, rimossa quando il portatile viene dismesso. Acquisti, revisione sicurezza e end-user computing hanno processi consolidati da decenni per questo. AI Suite si integra perfettamente.

Il SaaS cloud, al contrario, richiede un processo parallelo: revisione del rischio fornitore per tenant, conversazioni di federazione identità, audit continui della postura del fornitore e negoziazioni costanti su chi copre quali obblighi in caso di guasti. Utile per alcuni tipi di software. Non adatto ai flussi AI che i nostri clienti stanno costruendo.

Distribuendo app installabili che possono autenticarsi con il provider di identità del cliente — Microsoft Entra ID o Google Workspace tramite OpenID Connect — manteniamo i contenuti di inferenza fuori dal piano di controllo di Software Tailor. I servizi organizzativi elaborano comunque i record necessari per gestire il deployment: elenco e ruoli, autorizzazioni, policy e stato server, uso aggregato, audit amministrativo, licenze e supporto. Questi sono veri record lato fornitore, ma sono separati da prompt, risposte e documenti cliente nel percorso locale o ospitato dal cliente.

Motivo 3: zero fallimenti di progetto dal 2007 dipende dal non dipendere dalla disponibilità altrui

Abbiamo consegnato software personalizzato per diciannove anni con un record di zero fallimenti di progetto dal 2007 [4]. Questo record esiste perché il team controlla ogni livello della consegna: codice, build, test, artefatto di distribuzione. Nel momento in cui rendiamo il flusso di lavoro di produzione di un cliente dipendente dalla disponibilità del cloud di un'altra azienda, quel record smette di essere nostro da difendere.

I fornitori di AI cloud hanno interruzioni. Limitano le risorse. Cambiano i prezzi. Ritirano modelli. Ritirano intere API. I clienti che serviamo nei settori farmaceutico e della difesa non possono permettersi che il loro caso regolatorio durato un anno si blocchi perché un endpoint modello che non possiedono è stato migrato. Perciò non mettiamo il loro percorso di modello locale su uno di questi. Il modello risiede sulla macchina del cliente e l'inferenza avviene sulla macchina del cliente. La nostra infrastruttura fornisce i servizi del piano di controllo necessari per identità, diritti, policy, stato della flotta, uso aggregato, amministrazione e supporto; non è il runtime di inferenza e non riceve contenuti di prompt o risposta su quel percorso.

Cosa significa questo per la valutazione

Se sei un responsabile della conformità, un CIO o un CTO che valuta l'AI locale per un'implementazione aziendale, le domande rilevanti sono diverse rispetto a una valutazione SaaS cloud:

  • Dove avviene l'inferenza? Sul dispositivo dell'utente, o su un server controllato dal cliente. Non sul nostro.
  • Cosa esce dal perimetro? Nel percorso di inferenza locale o ospitato dal cliente, nessun prompt, risposta o contenuto di documento va a Software Tailor. I dati di controllo, licenza, sicurezza, telemetria (quando abilitata) e supporto hanno percorsi dati documentati separati.
  • Qual è la traccia di audit? JSONL senza contenuti, memorizzato localmente, esportabile. Il modello non vede mai contenuti su cui non è stato istruito ad agire, e la riga di audit non vede mai contenuti.
  • Cosa succede quando il fornitore scompare? I binari installati e il runtime locale gratuito non dipendono da un tenant di inferenza ospitato. Abbonamento, organizzazione e funzionalità Pro gestite centralmente possono ancora dipendere da diritti validi e servizi del piano di controllo, quindi un piano di uscita deve tenerne conto.

Queste sono le quattro domande a cui abbiamo costruito AI Admin Console e la Local AI Suite per rispondere in modo chiaro. L'articolo su conformità al EU AI Act e implementazione on-premise tratta il lato regolatorio in modo più approfondito.

Riferimenti

  1. Commissione Europea. "AI Act — Quadro normativo sull'IA." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Consultato il 15-06-2026.
  2. Osservatorio Politiche IA OCSE. "Politiche nazionali sull'IA." https://oecd.ai/. Consultato il 15-06-2026.
  3. NIST. "AI Risk Management Framework (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Consultato il 15-06-2026.
  4. Software Tailor. "Clienti passati." https://softwaretailor.com/past-clients.htm. Consultato il 15-06-2026.