Prima di comprare un server per l'AI, verificate cinque cose: qualità sul lavoro da svolgere, dati e permessi, carico, gestione e costo completo. Il locale è una possibilità da confrontare con cloud e soluzioni ibride sullo stesso risultato richiesto. La configurazione viene dopo: senza quei requisiti, anche un preventivo molto dettagliato risponde alla domanda sbagliata.
Questa guida è per chi deve decidere un investimento aziendale: imprenditore, responsabile IT, tecnico o operations. Il punto di partenza può essere un archivio di manuali, l'estrazione di dati dai documenti o un'integrazione con il gestionale. Se dovete ancora scegliere il processo, partite dalla guida sull'AI nei processi delle PMI. Qui affrontiamo la decisione successiva: dove e a quali condizioni far funzionare quel progetto.
Avete già un progetto da valutare?
Raccontatemi attività, persone coinvolte e tipi di dati, senza inviare documenti riservati. Il primo confronto gratuito serve a chiarire quale decisione dovete affrontare.
Valutiamo il vostro progetto AI01 ·Cosa significa davvero AI locale
Conviene precisare il perimetro prima di discutere di prodotti. In questa guida uso quattro definizioni operative.
| Soluzione | Dove lavora | Cosa resta da verificare |
|---|---|---|
| Inferenza locale | Il modello genera risposte su una macchina aziendale. | Dove passano documenti, ricerca, log e servizi collegati. |
| Pipeline locale | Le fasi concordate del trattamento lavorano nell'infrastruttura aziendale. | Il perimetro effettivo e le eccezioni: assistenza, aggiornamenti, backup, eventuali chiamate esterne. |
| Cloud dedicato | Il servizio è ospitato all'esterno, con isolamento e risorse definiti nell'offerta. | Contratto e configurazione: “dedicato” non dimostra, da solo, hardware fisico esclusivo. |
| Soluzione ibrida | Alcune fasi sono locali e altre esterne. | Quali informazioni attraversano il confine, perché e con quali controlli. |
Un server in un datacenter del fornitore non è nei locali dell'azienda. Allo stesso modo, un modello installato in ufficio non rende automaticamente locale tutto ciò che lo circonda. Una pipeline documentale può comprendere acquisizione, OCR, suddivisione dei testi, embedding, indice, ricerca e generazione. La documentazione Microsoft sull'architettura RAG descrive fasi separate: da questa separazione deriva la necessità di censire la collocazione di ciascuna fase, comprese quelle accessorie effettivamente presenti.
RAG significa recuperare informazioni da fonti selezionate e fornirle al modello come contesto per la risposta. Non coincide con riaddestrare il modello sui vostri documenti. Per capire se il sistema rimane locale bisogna seguire i dati lungo il percorso, inclusi cache, log e backup, invece di fermarsi alla posizione del modello.
02 ·Quando valutare il locale e quando fermarsi prima
Il locale merita un confronto quando avete vincoli documentati sui flussi dei dati, necessità operative legate alla connettività, integrazioni vicine agli impianti oppure un carico per cui volete verificare un'infrastruttura gestita da voi. Sono ragioni per svolgere un'analisi, non prove che quella soluzione sia già la migliore.
Se il processo cambia continuamente, i documenti non hanno un responsabile o nessuno può gestire il servizio, l'acquisto anticipa problemi ancora irrisolti. Lo stesso vale se una ricerca documentale tradizionale, una regola nel gestionale o uno strumento già disponibile possono soddisfare il bisogno. Queste alternative devono entrare nel confronto.
Il cloud non ha un'unica politica dei dati. Uso per addestramento, conservazione, luogo di elaborazione e accessi del fornitore sono domande distinte. Per esempio, la documentazione dei modelli venduti da Azure in Microsoft Foundry distingue funzionalità che conservano stato e tipi di deployment, fra cui Global e DataZone, con perimetri differenti per l'elaborazione. Quelle condizioni riguardano quel servizio e quella configurazione: non si trasferiscono a qualsiasi chatbot.
Nemmeno la collocazione locale dimostra conformità automatica. Gli articoli 5, 25 e 32 del GDPR richiedono, fra l'altro, finalità definite, minimizzazione e misure di sicurezza adeguate. La scelta architetturale va accompagnata dalla valutazione del trattamento concreto.
03 ·Tre scenari aziendali ipotetici
Gli esempi seguenti sono ipotetici: non sono casi cliente, configurazioni raccomandate o risultati misurati.
Un assistente per manuali e procedure
Un'azienda manifatturiera vuole aiutare l'assistenza tecnica a trovare istruzioni nei manuali. Il requisito utile è una risposta verificabile, collegata alla revisione corretta del documento e accessibile soltanto a chi ha i permessi. Mancano ancora un inventario delle versioni, domande rappresentative e una regola per i casi in cui la fonte non risponde.
La prova deve includere codici simili, procedure superate e domande senza risposta. Prima di parlare di memoria GPU, bisogna capire se la ricerca recupera il documento giusto e se il tecnico può controllare la fonte. Il confronto può includere anche un motore di ricerca senza generazione.
Estrazione di dati per il gestionale
L'ufficio acquisti vuole trasformare documenti ricevuti in bozze da controllare prima di inserirle nell'ERP. I requisiti riguardano campi corretti, formati diversi, duplicati e gestione delle eccezioni. Un OCR esterno, se presente, cambia il perimetro anche quando il modello è locale.
Servono campioni autorizzati, regole di validazione e un ambiente di prova dell'integrazione. Un risultato plausibile non basta: quantità, codici e unità devono essere controllabili. L'eventuale vantaggio si misura includendo correzioni e attività residue, senza attribuire all'AI tutto il tempo del processo precedente.
Supporto alle risposte commerciali
Un team vuole preparare bozze usando cataloghi e condizioni approvate. I requisiti sono separare listini e clienti, usare contenuti aggiornati e lasciare l'approvazione al referente commerciale. Restano da chiarire i permessi, il collegamento al CRM e le informazioni che possono essere inviate a servizi esterni.
Una soluzione ibrida è una candidata da valutare solo dopo aver definito quei flussi. Nella prova devono comparire condizioni scadute, richieste ambigue e documenti non autorizzati. Il successo è una bozza utilizzabile e controllabile nel processo concordato, non una risposta che sembra ben scritta.
04 ·Le cinque verifiche prima dell'investimento
1. Qualità sul compito
Preparate domande e documenti rappresentativi del lavoro, includendo errori di origine, eccezioni e casi senza soluzione. Affidate la valutazione a persone che conoscono quel processo. Registrate cosa rende una risposta corretta e quanto lavoro serve per controllarla o correggerla.
Per un assistente documentale, recupero delle fonti, correttezza della risposta e sostegno delle citazioni vanno misurati separatamente. Lo studio ALCE, pubblicato a EMNLP 2023, distingue proprio correttezza e qualità delle citazioni. Qui ne riprendo il criterio metodologico, senza trasferire i risultati sperimentali a modelli o documenti aziendali diversi. Una citazione presente può essere sbagliata o non sostenere tutta la risposta.
2. Dati, accessi e integrazioni
Per ogni fase annotate dati in ingresso, destinazione, conservazione, persone autorizzate e responsabile. Chiarite chi aggiorna i documenti, come si eliminano le versioni superate e cosa succede dopo la revoca di un permesso. Verificate anche cache e citazioni già prodotte.
I permessi devono essere applicati prima che i contenuti entrino nel contesto del modello, usando l'identità verificata dall'applicazione. Non basta chiedergli di “non mostrare dati riservati”. È il principio architetturale descritto dalla guida Microsoft sul RAG multitenant sicuro; la sua effettiva applicazione resta da collaudare nel progetto.
I documenti recuperati possono contenere istruzioni ostili. OWASP LLM01:2025 descrive la prompt injection indiretta anche attraverso file e repository RAG. Per questo occorrono limiti applicativi agli accessi e alle azioni, prove dedicate e supervisione dove prevista: l'aggiunta della ricerca documentale non elimina il rischio.
3. Carico e tempi di risposta
Contate le richieste da elaborare contemporaneamente, non soltanto gli utenti abilitati. Raccogliete frequenza, lunghezza dei documenti e delle risposte, fasce di picco e attesa accettabile. Un'elaborazione notturna e una domanda durante una telefonata hanno esigenze diverse.
La configurazione va provata con il carico concordato, includendo code, errori e richieste lente. Il tempo al primo testo e il tempo alla risposta completa sono misure diverse. Anche un contesto massimo dichiarato molto ampio non dimostra che il modello usi correttamente tutte le informazioni: serve una prova di qualità sui vostri casi.
4. Gestione e continuità
Definite chi controlla il servizio, installa aggiornamenti, gestisce vulnerabilità e risponde agli incidenti. Servono procedure per ripristinare dati e configurazioni, verificare i backup e tornare alla versione precedente quando un aggiornamento peggiora il risultato.
Concordate come continua il lavoro durante un fermo. Può essere una procedura manuale; un eventuale servizio cloud di riserva deve rispettare i vincoli già definiti. Il guasto non autorizza a spostare automaticamente dati altrove. Queste responsabilità hanno un costo anche quando il software non richiede un abbonamento.
5. Costo completo
Confrontate alternative che soddisfano gli stessi requisiti di qualità, dati, integrazione e tempi. Separate acquisto hardware, configurazione, sviluppo delle integrazioni, licenze, servizi esterni, energia, assistenza, formazione e lavoro interno. Includete il controllo degli output e la manutenzione della base documentale.
Scegliete lo stesso orizzonte temporale e indicate cosa è un preventivo, cosa è una stima e cosa rimane sconosciuto. Dichiarate se il confronto considera gli esborsi di cassa o una ripartizione del costo dell'hardware nel tempo. L'esborso registra il pagamento; le quote di ammortamento ripartiscono il costo su un periodo. Indicate periodo e quote usati nel confronto, applicate la stessa convenzione alle alternative e non sommate l'intero acquisto alle sue quote di ammortamento. Per l'energia distinguete una stima con ipotesi dichiarate dai consumi effettivamente misurati sul sistema. Agevolazioni eventuali richiedono una verifica separata sul progetto e non devono far apparire sostenibile un impiego che non lo è.
05 ·Hardware: caricare un modello non basta
Chiedete che la proposta identifichi modello e versione, licenza d'uso, formato dei pesi, runtime, contesto e carico previsto. La memoria richiesta dai pesi è solo una parte. La documentazione di vLLM v0.10.2 mostra che contesto, sequenze elaborate e CUDA Graph incidono sulla memoria. Le strategie di cache in Transformers v4.50.0 variano con implementazione e architettura. Sono riferimenti a versioni precise, non una prescrizione delle versioni da installare.
Un solo esempio, puramente teorico. Immaginiamo 8 miliardi di parametri totali, tutti rappresentati uniformemente a 4 bit. Il payload ideale dei soli pesi è: 8.000.000.000 × 4 ÷ 8 = 4.000.000.000 byte, cioè 4 GB decimali, circa 3,73 GiB.
Questo calcolo esclude metadati della quantizzazione, eventuali tensori a precisioni diverse, cache, allocazioni del runtime e altro software. Non descrive un modello reale né la memoria necessaria durante l'esecuzione.
Da quel numero non deriva una GPU da acquistare, una velocità o una qualità garantita. Serve una configurazione completa con una prova pertinente. Tenete poi distinti il costo dell'infrastruttura e il compenso per analisi, progettazione e implementazione: chiedete che il preventivo espliciti inclusioni, esclusioni e costi di terzi.
06 ·Preparare una prova di accettazione
Un'installazione riuscita dimostra che il sistema parte. Una demo riuscita mostra alcuni esempi. Per decidere se estendere il progetto bisogna verificare il servizio nelle condizioni concordate.
Prima della prova fissate corpus e versioni, identità e permessi, modello e configurazione, casi da valutare e criteri di giudizio. Tenete un insieme di casi separato da quelli usati per mettere a punto il sistema. Definite chi approva il risultato e le soglie richieste dal processo, senza adottare percentuali universali.
Il verbale dovrebbe distinguere almeno questi esiti:
- Utilità: risposte e campi corretti, fonti pertinenti, tempo di verifica e correzione.
- Limiti: capacità di astenersi quando manca la fonte, gestione di ambiguità e documenti superati.
- Accessi: tentativi di leggere dati vietati, revoche dei permessi e istruzioni ostili nei documenti.
- Servizio: attese, code, errori e comportamento sotto il carico previsto.
- Continuità: aggiornamento dei contenuti, ripristino e procedura durante un fermo.
Non fondete tutto in uno score di readiness: una buona media sulla qualità non compensa un accesso non autorizzato. Concordate prima anche i criteri di arresto, per esempio un'esposizione di dati vietati o un errore critico ripetuto. Un collaudo favorevole documenta i casi e le condizioni verificati, non prova l'assenza di ogni errore futuro.
Un kit · due risorse
AI in azienda: kit per valutare l’investimento e preparare le prove
Guida operativa in PDF e template modificabile in Word, nello stesso invio.
07 ·La scheda per preparare il progetto
Potete copiare e compilare questa scheda senza lasciare un'email. “Non lo sappiamo ancora” è una risposta utile: rende visibile il lavoro da fare prima di scegliere una macchina.
| Campo | Cosa annotare |
|---|---|
| Attività | Un processo circoscritto, chi lo svolge e come funziona oggi. |
| Risultato atteso | L'output utilizzabile e chi lo approva. |
| Errore inaccettabile | Cosa non deve accadere e cosa obbliga a fermare la prova. |
| Persone coinvolte | Referente del processo, IT, utenti della prova e responsabili dei dati. |
| Dati e permessi | Tipi di documenti, versioni, aggiornamento e chi può vedere cosa. |
| Integrazioni | Sistemi da consultare o aggiornare, con quali autorizzazioni. |
| Tempi e carico | Frequenza, simultaneità, picchi, attesa tollerabile e continuità richiesta. |
| Vincoli economici | Budget da valutare, lavoro interno disponibile e voci ancora senza stima. |
| Informazioni mancanti | Campioni, misure, permessi o condizioni contrattuali da verificare, con un responsabile. |
Per un primo contatto bastano una descrizione del processo e le categorie dei dati. Non inviate archivi, credenziali, documenti riservati o dati personali dei vostri clienti.
08 ·Cosa potete affidare a ContinDigital
Avete individuato un'attività, ricevuto una proposta per un server o avete alternative cloud e locali da confrontare. La decisione è capire quale soluzione risponda ai requisiti del processo e con quale investimento. Lavoro con PMI manifatturiere per costruire questa base prima di impegnare il budget.
Per prendere quella decisione servono priorità definite, un'architettura di riferimento, scelta dei modelli, dimensionamento hardware, costo totale a tre anni e piano operativo. Sono i deliverable previsti da AI Roadmap nell'offerta AI Readiness. Il lavoro riguarda analisi e progettazione: documentazione, requisiti e ipotesi del confronto devono essere riconoscibili. Il dimensionamento progettato non dimostra tempi di risposta o qualità misurati sul vostro sistema; una roadmap non è un collaudo eseguito.
Se manca ancora un caso d'uso su cui investire, il punto di partenza è diverso: interviste, mappatura delle fonti e della qualità dei dati, individuazione delle possibili applicazioni e valutazione dei rischi. Questo orientamento è previsto da AI Scan; dimensionamento e TCO appartengono al livello Roadmap.
Per passare al sistema funzionante, l'offerta AI Pilot comprende un proof of concept su un caso, un'integrazione con un sistema esistente e il passaggio al team IT. Il perimetro e le prove da svolgere vanno concordati; i risultati effettivamente osservati devono rimanere distinti dalle stime. Il PoC non equivale da solo all'estensione in produzione di tutti i processi aziendali. Prezzi, tempi e deliverable restano sulla landing del servizio, così avete un unico riferimento commerciale.
Il primo confronto gratuito di 30 minuti serve a inquadrare la decisione e il percorso. Analisi, dimensionamento, TCO e piano di implementazione fanno parte dell'incarico previsto dall'offerta, secondo il pacchetto concordato. Il metodo e la scheda sono pubblici: il lavoro consiste nell'applicarli al vostro contesto. Anche rinviare l'investimento può essere una conclusione dell'analisi.
09 ·Metodo e fonti
Questa guida usa documentazione primaria di prodotto, indicazioni architetturali, la scheda OWASP citata e gli articoli del GDPR indicati. Lo studio ALCE sostiene una distinzione metodologica: non ne riporto benchmark numerici. Le fonti collegate ai passaggi pertinenti sono state consultate il 23 settembre 2026; i riferimenti vLLM e Transformers sono fissati alle versioni dichiarate.
L'esempio di memoria è un calcolo teorico con assunzioni esplicite. I tre scenari sono ipotetici. Non abbiamo svolto benchmark hardware o prove comparative proprietarie di inferenza per questo articolo. Prestazioni, qualità, consumi e convenienza del vostro progetto restano da misurare con un protocollo concordato. La parte normativa chiarisce il limite della collocazione locale e non sostituisce la valutazione del trattamento concreto.