La scelta dei programmi AI parte da attività dati e costo totale
Quali programmi AI conviene scegliere per un’azienda? Quelli proporzionati al compito, al danno che può causare un errore, ai dati utilizzati e al costo totale di gestione.
Tre richieste aziendali arrivano spesso sotto un’identica etichetta, usare l’intelligenza artificiale, ma chiedono di scrivere, prevedere o decidere. La prima può essere affidata a un assistente generativo con revisione umana; la seconda richiede dati storici e un modello predittivo; la terza può coinvolgere procedure, sistemi aziendali, responsabilità e controlli molto più severi. Trattarle come varianti dello stesso acquisto porta a scegliere male.
La scelta dei programmi AI parte dal danno possibile
Il criterio iniziale non è la quantità di funzioni offerte. Bisogna chiedersi che cosa succede quando il sistema sbaglia e chi intercetta l’errore prima che produca conseguenze.
Un ufficio commerciale vuole preparare la bozza di una risposta a un cliente. Un chatbot può generarla in pochi secondi, mentre una persona controlla prezzi, condizioni e tono prima dell’invio. L’errore è visibile e correggibile. Il lavoro resta nelle mani dell’addetto.
Un responsabile di produzione vuole prevedere il fermo di una macchina. Qui serve un modello predittivo, cioè un sistema che cerca relazioni nei dati storici per stimare un evento futuro. Se i sensori registrano valori incompleti, se gli interventi passati non sono stati classificati bene o se la macchina è cambiata nel frattempo, la previsione perde utilità. Il problema non si risolve comprando un chatbot più potente.
Un’impresa vuole invece far decidere al sistema quali ordini accettare, quali pratiche bloccare o quali interventi assegnare. In questo caso l’IA entra nel processo operativo: deve ricevere dati da altri programmi, applicare regole, registrare ciò che ha fatto e lasciare alla persona competente la possibilità di intervenire. L’architettura e i controlli contano più della qualità apparente di una singola risposta.
La distinzione pratica è questa: per una bozza a basso impatto può bastare un programma pronto all’uso; per una previsione servono dati storici pertinenti; per una decisione con effetti su clienti, lavoratori, impianti o denaro occorrono integrazione, tracciabilità e responsabilità definite. La scelta si restringe subito, prima ancora di confrontare i fornitori.
Struttura e sensibilità dei dati cambiano lo strumento
Dopo aver valutato il danno possibile, bisogna guardare i dati. Contano sia la loro struttura sia la loro sensibilità.
I dati strutturati sono organizzati in campi regolari, come quantità, date, codici prodotto, temperature o tempi di fermo. Sono adatti ad analisi statistiche e modelli predittivi, purché le registrazioni siano coerenti e descrivano davvero il fenomeno da prevedere. Una colonna compilata in modi diversi dai reparti non diventa affidabile solo perché viene elaborata dall’IA.
I dati non strutturati comprendono invece manuali, e-mail, verbali, immagini e documenti in formato libero. Un modello generativo può riassumerli o produrre una risposta, ma deve sapere quali contenuti usare e quali escludere. Se l’azienda vuole interrogare procedure interne, listini approvati o istruzioni tecniche, può servire un sistema RAG, sigla di retrieval-augmented generation: prima recupera i documenti pertinenti dall’archivio aziendale, poi li fornisce al modello per preparare la risposta.
Il RAG è utile quando le informazioni cambiano e devono restare sotto il controllo dell’impresa. Evita di affidarsi soltanto alle conoscenze generali del modello, ma non elimina gli errori. I documenti vanno selezionati, aggiornati, suddivisi correttamente e associati ai permessi degli utenti. Se un tecnico può consultare una procedura riservata a un altro reparto, il problema è nell’accesso ai dati, non nella formulazione della domanda.
La sensibilità richiede un controllo separato. Prima di caricare anagrafiche, contratti, dati dei dipendenti, informazioni finanziarie o documenti dei clienti, occorre verificare dove vengono trattati, per quanto tempo sono conservati, se possono essere usati per addestrare il servizio e chi può consultarli. Le risposte devono essere scritte nel contratto e nelle impostazioni amministrative, non dedotte dalla schermata commerciale del prodotto.
Quando i dati sono molto riservati, può essere necessario un ambiente dedicato o una soluzione installata sull’infrastruttura controllata dall’azienda. Quest’ultima viene spesso chiamata on premises, cioè eseguita su sistemi gestiti direttamente dall’organizzazione. Offre maggiore controllo, ma trasferisce sull’impresa attività come aggiornamenti, sicurezza, capacità di calcolo e assistenza.
Chatbot, immagini, codice e previsioni richiedono architetture diverse
I programmi di intelligenza artificiale vanno confrontati all’interno della stessa famiglia. Un generatore di immagini e un sistema di manutenzione predittiva possono entrambi usare l’IA, ma rispondono a requisiti incompatibili.
- Chatbot e assistenti generativi: sono adatti a bozze, sintesi, classificazione di testi e ricerca assistita. Per contenuti generici può bastare un servizio pronto; per risposte basate su procedure interne servono archivi controllati, permessi e spesso un sistema RAG.
- Generatori di immagini e foto: servono per concept, varianti visive e materiali da sottoporre a revisione. Prima dell’uso esterno vanno controllati contenuto, coerenza con il prodotto, condizioni contrattuali e provenienza degli elementi impiegati.
- Assistenti per la programmazione: propongono codice, spiegano funzioni e aiutano nei test. La scelta dipende dall’accesso consentito ai repository, cioè agli archivi del codice, dalle regole sulla conservazione e dalla possibilità di applicare controlli automatici e revisione umana.
- Modelli predittivi: stimano domanda, guasti, anomalie o tempi sulla base di dati storici. Richiedono una variabile da prevedere ben definita, dati confrontabili e verifiche periodiche sulle prestazioni.
- Soluzioni integrate nei processi: leggono e scrivono dati nei gestionali, aprono attività o propongono azioni. Servono interfacce, autorizzazioni, registri delle operazioni, procedure di blocco e responsabilità chiare.
Queste categorie possono essere combinate. Un assistente di manutenzione, per esempio, può interrogare i manuali tramite RAG, ricevere gli allarmi dal sistema di fabbrica e preparare una proposta d’intervento. Il tecnico deve però vedere da quali dati deriva la proposta, controllarla e correggerla. Senza questa catena, l’integrazione rende l’errore più rapido invece di rendere il lavoro più affidabile.
Va chiarito anche il livello di autonomia. Un programma che suggerisce una risposta è diverso da uno che la invia; un modello che segnala un’anomalia è diverso da un sistema che ferma una linea. La funzione può sembrare simile nella dimostrazione, mentre responsabilità, sicurezza e costi cambiano nettamente.
Privacy, integrazione e AI Act vanno verificati prima dell’acquisto
Una prova gratuita mostra come il programma risponde a una richiesta isolata. Per capire se può lavorare in azienda bisogna verificare autenticazione, permessi, registrazione delle attività, esportazione dei dati, continuità del servizio e collegamento con i programmi già usati.
L’integrazione avviene spesso tramite API, interfacce che permettono a due sistemi di scambiarsi dati e comandi. La presenza di un’API, da sola, non garantisce un collegamento pronto. Occorre stabilire quali campi passano, chi li può modificare, come vengono gestiti errori e duplicati e che cosa accade quando uno dei servizi è fermo. Queste attività generano sviluppo, prove e manutenzione.
Serve inoltre una valutazione normativa proporzionata all’uso. Il Parlamento europeo descrive il quadro dell’Unione come basato sul rischio: gli obblighi aumentano per gli impieghi capaci di incidere maggiormente su sicurezza e diritti. I sistemi classificati ad alto rischio devono essere valutati prima dell’immissione sul mercato e durante il loro ciclo di vita; per l’IA generativa sono previsti anche requisiti di trasparenza e misure relative ai contenuti illegali e al diritto d’autore.
Per l’impresa, la domanda utile non è soltanto quale modello viene utilizzato, ma in quale processo viene inserito e con quali effetti. Lo stesso motore generativo può preparare una descrizione interna a basso impatto oppure contribuire a un’attività sottoposta a obblighi più stringenti. Prima della messa in esercizio conviene quindi classificare il caso d’uso con chi segue conformità, sicurezza e protezione dei dati, verificando il testo consolidato applicabile su EUR-Lex.
Nel contratto vanno poi separati i ruoli del fornitore e del cliente: gestione degli accessi, aggiornamenti del modello, conservazione dei registri, segnalazione degli incidenti e possibilità di recuperare dati e configurazioni alla fine del rapporto. Se questi punti restano vaghi, cambiare servizio può diventare più difficile del previsto.
Il costo totale comprende strumento, integrazione e gestione
Il prezzo visibile copre spesso solo l’accesso al programma. Il costo totale va calcolato con una formula più completa: licenze o consumo + preparazione dei dati + integrazione + infrastruttura + sicurezza e conformità + formazione + supervisione umana + manutenzione.
Il costo del tool comprende abbonamenti, utenti, chiamate al modello o capacità di calcolo. Il costo dell’integrazione riguarda collegamenti con gestionali e archivi, pulizia dei dati, configurazione dei permessi, prove e adattamento delle procedure. Il costo di gestione continua comprende monitoraggio, correzioni, aggiornamenti, controllo degli accessi e verifica delle risposte.
Un chatbot usato da poche persone per preparare bozze può avere un’integrazione minima, ma richiede comunque regole sui dati ammessi e revisione. Un assistente interno basato sui documenti aziendali aggiunge la costruzione e l’aggiornamento dell’archivio RAG. Un modello predittivo richiede raccolta dei dati, addestramento, confronto tra previsioni e risultati reali. Una soluzione che agisce sui sistemi operativi aggiunge test, registri, procedure di emergenza e controlli nel tempo.
Per confrontare due proposte bisogna chiedere che il preventivo separi queste voci. Un abbonamento economico collegato con sviluppo su misura può costare più di una soluzione apparentemente cara ma già compatibile con i sistemi presenti. Vale anche il contrario: una piattaforma completa è uno spreco se il compito consiste soltanto nel produrre bozze sottoposte a controllo.
Prima di autorizzare una prova operativa, conviene fissare per iscritto:
- la frequenza del compito e il tempo che oggi assorbe;
- l’accuratezza necessaria e gli errori che richiedono il blocco del processo;
- i programmi, gli archivi e le macchine da collegare;
- la presenza di dati personali, riservati o soggetti a permessi differenziati;
- il punto preciso in cui interviene la supervisione umana;
- i costi ricorrenti per utenti, consumo, infrastruttura, assistenza e controlli;
- la classificazione del caso d’uso e gli obblighi applicabili secondo l’AI Act.
La prova dovrebbe usare casi rappresentativi, includere richieste difficili e misurare quante correzioni restano alle persone. Solo dopo si può confrontare il beneficio con il costo totale, invece di valutare il prodotto sulla risposta migliore ottenuta durante una dimostrazione.
Trascurare attività, dati e integrazione espone l’azienda a errori operativi, costi ricorrenti sottostimati e dipendenza da un fornitore difficile da sostituire. Una scelta circoscritta, verificata su un processo reale e accompagnata da responsabilità chiare riduce questi rischi senza bloccare l’adozione.
Da leggere anche: I servizi digitali al cittadino bastano o serve ancora lo sportello?
Da leggere anche: Computer che non si accende: quali controlli fare senza peggiorare il guasto?