Valutare la fattibilità di un progetto IA, prima di scegliere il modello.

Questa pagina esamina le condizioni organizzative ed economiche che possono rendere un progetto impraticabile o non sostenibile.

Per stimarle deve essere chiaro quale servizio si vuole offrire. Questa pagina non valuta la complessità tecnica di una soluzione capace di dare risposte corrette e utili alle richieste previste, né il lavoro necessario per ottenerla. Sono aspetti distinti della fattibilità, da approfondire con una valutazione tecnica separata. Superare i controlli descritti sotto non garantisce, da solo, la qualità delle risposte.

La disponibilità dei dati e delle persone che possono prepararli è un investimento iniziale da stimare.

• Dove si trovano i dati necessari e chi può autorizzarne l'accesso e l'uso?
• Sono sufficientemente completi, aggiornati e rappresentativi del lavoro previsto?
• Chi può estrarli, correggerli, organizzarli e descriverli con i metadati necessari?
• Servono esempi etichettati o risultati di riferimento? Chi può prepararli e verificarli con competenza sul dominio?
• Quali persone, tempi e costi richiede questo lavoro? Come saranno mantenuti aggiornati i dati?

L'etichettatura non è necessaria in ogni progetto IA: dipende dal compito e dall'approccio scelto. Quando serve, l'azienda deve poter produrre e verificare etichette affidabili. Anche senza etichette, preparare e mantenere i dati può assorbire una parte rilevante dell'investimento.

La prima verifica riguarda le informazioni che devono entrare nel flusso IA:

• I dati del cliente possono essere inviati a un servizio IA esterno?
• Ci sono dati personali, riservati o soggetti a vincoli contrattuali o normativi?
• Quali condizioni di trattamento, conservazione e localizzazione offre il fornitore?
• È possibile usare solo i dati necessari o renderli anonimi? Se vengono pseudonimizzati, che cosa permette ancora di ricondurli a una persona?

La pseudonimizzazione può ridurre i rischi, ma i dati ancora riconducibili a una persona restano dati personali. Se alcuni dati non possono essere inviati a un servizio esterno, il progetto resta efficace senza di essi? Si può riformulare la richiesta o tenere le informazioni sensibili in una fase separata e controllata? Se il modello ha bisogno proprio di quei dati per fornire un risultato utile, serviranno un ambiente e un flusso compatibili con i relativi vincoli.

I confini e i controlli di sicurezza dell’applicazione IA →

Definiti i vincoli sui dati, vanno stimati i requisiti pratici:

• Tempo di risposta: quanto può attendere l'utente per ogni richiesta?
• Concorrenza: quante richieste simultanee sono previste, nei momenti normali e nei picchi?
• Continuità: quali livelli di disponibilità e crescita servono?
• Costo complessivo: quanto pesa ogni richiesta al volume previsto? Quanto incidono preparazione dei dati, integrazione, verifiche umane e gestione dell'infrastruttura?
• Gestione in produzione: chi controllerà il servizio, raccoglierà le segnalazioni e rileverà eventuali cali di qualità? Con quali dati, persone e budget si interverrà?

Questi elementi vanno considerati insieme. Una soluzione può essere troppo lenta, costosa o limitata per il carico atteso, oppure incompatibile con i dati del progetto. Il lavoro non termina con il rilascio: monitoraggio e interventi successivi sono costi e responsabilità da prevedere fin dall'inizio.

La scelta dipende da dati, prestazioni, costi e capacità di gestione.

Servizi IA gestiti tramite API

Servizi come OpenRouter, le API di OpenAI o le API gestite dei provider cloud possono offrire accesso semplice ai modelli e capacità scalabile. Possono essere adatti se le condizioni di trattamento dei dati sono compatibili con il progetto e se conta ridurre il lavoro operativo.

Vanno verificati costi, conservazione e localizzazione dei dati, uso per l'addestramento e accordi applicabili. Con un intermediario come OpenRouter conta anche quale fornitore esegue il modello, soprattutto se l'instradamento può cambiare. Le API gestite in cloud possono offrire opzioni diverse di rete e area geografica: il livello di privacy non si deduce dal solo nome del servizio.

Modelli su risorse cloud dedicate

Un'altra possibilità è eseguire un modello su risorse cloud dedicate, per esempio macchine con GPU su Azure o AWS. Questo offre più controllo su modello, rete e accessi, ma richiede di gestire l'esecuzione e di sostenere i costi dell'infrastruttura. Anche qui, privacy e conformità dipendono dalla configurazione e dagli accordi applicabili.

Modelli in un ambiente locale

Un modello su infrastruttura propria può aumentare il controllo sul percorso dei dati, ma richiede hardware, aggiornamenti, monitoraggio e manutenzione. La memoria GPU limita i modelli utilizzabili; tempi e capacità dipendono anche dalla potenza di calcolo, dalla lunghezza delle richieste e dagli utenti simultanei. Prima di scegliere questa strada vanno misurati latenza e carico sull'hardware previsto, con prove rappresentative.

La scelta richiede vincoli espliciti e una stima del lavoro che l'azienda deve sostenere.

1. Quale servizio si vuole offrire e quali dati sono indispensabili?
2. L'azienda può fornire, preparare e aggiornare i dati, comprese etichette o risposte di riferimento se necessarie? Con quale investimento iniziale?
3. Quali dati possono essere inviati a servizi esterni? Il servizio resta praticabile se alcuni non possono esserlo?
4. Quali tempi di risposta, disponibilità e volumi di richieste servono?
5. Qual è il costo complessivo sostenibile, inclusi preparazione iniziale e gestione in produzione?
6. Chi monitorerà il servizio, rileverà eventuali cali di qualità e interverrà nel tempo?
7. Quale livello di controllo sull'infrastruttura e di gestione interna è richiesto?
8. Quale opzione soddisfa meglio questi vincoli: API gestita, risorse cloud dedicate o infrastruttura locale?
9. Chiariti questi vincoli, quali modelli candidati possono soddisfare il compito e con quali prove tecniche se ne valuterà la qualità?

Queste risposte chiariscono i vincoli e l'investimento richiesto prima di scegliere l'infrastruttura.

Un esempio: applicazioni con IA →

Il passo successivo: scelta dei modelli, costi e continuità →

Una selezione di documenti primari a supporto dei criteri descritti:

• NIST — AI Risk Management Framework, Core (si apre in una nuova scheda): prove e misure della qualità prima del rilascio, valutazione dei dati e monitoraggio in produzione.
• OpenAI — buone pratiche per valutare i sistemi IA (si apre in una nuova scheda): criteri di successo, casi di prova, misure e verifiche ripetute per valutare la qualità delle risposte.
• Microsoft — valutazione delle risposte nei sistemi RAG (si apre in una nuova scheda): un esempio concreto di verifica di pertinenza, aderenza alle fonti e completezza delle risposte.
• Google Cloud — etichettatura dei dati (si apre in una nuova scheda): ruolo dei dati etichettati nei progetti che ne hanno bisogno.
• EDPB — sintesi delle linee guida sulla pseudonimizzazione (si apre in una nuova scheda): i dati pseudonimizzati restano personali se riconducibili a una persona.
• OpenAI — controlli sui dati nelle API (si apre in una nuova scheda): uso dei dati, conservazione e opzioni disponibili.
• OpenRouter — privacy policy (si apre in una nuova scheda): trattamento dei dati e differenze tra i fornitori dei modelli.
• Microsoft — tipi di distribuzione dei modelli (si apre in una nuova scheda): localizzazione dell'elaborazione, prestazioni e modalità di pagamento.
• vLLM — configurazione della memoria per le richieste (si apre in una nuova scheda): relazione tra memoria GPU, lunghezza delle richieste e richieste simultanee.