Assistere a demo in cui l’Intelligenza Artificiale genera risultati straordinari è del tutto normale, ma cosa succede quando quella stessa tecnologia deve gestire migliaia di PEC reali, dati stratificati in dieci anni di operatività e informazioni sensibili?
Nei contesti B2B, il passaggio dalla sperimentazione ai sistemi operativi richiede un approccio progettuale molto diverso rispetto a quello che emerge durante una demo o un proof of concept.
Integrare l’AI in processi reali significa, infatti, confrontarsi con dati incompleti o classificati in modo incoerente, eccezioni di processo, vincoli di integrazione tra sistemi e modalità di utilizzo che incidono direttamente anche sui costi operativi e sulla tenuta del sistema nel tempo.
Riconoscere e sapere come governare queste variabili fin dalle prime fasi progettuali è ciò che permette di trasformare una sperimentazione in un sistema realmente utilizzabile nei processi operativi. Per questo, esperienza progettuale, conoscenza dei sistemi entreprise e capacità di gestire dinamiche operative complesse diventano elementi centrali per portare l’Intelligenza Artificiale in produzione in modo sostenibile.
In questo articolo vedremo come gestire al meglio le 5 aree di attenzione che le aziende si trovano ad affrontare nell'integrazione dell'AI nei processi B2B.
1. I dati disponibili non sono allineati all’obiettivo del sistema
Nei contesti B2B, i dataset non nascono per addestrare un sistema basato su Intelligenza Artificiale: anche quando sono strutturati e governati all’interno di ERP o gestionali, sono progettati per supportare processi operativi specifici, non per rispondere all’obiettivo del sistema che si vuole realizzare. All’interno si trovano eccezioni, informazioni non aggiornate, casi gestiti manualmente o processi che nel frattempo sono cambiati.
Per ottenere un livello di affidabilità coerente con il contesto operativo, è necessario lavorare in modo iterativo: analizzare i risultati, confrontarli con chi conosce il dominio, intervenire sui dati e ripetere il ciclo fino a ottenere un allineamento sufficiente.
Un caso tipico riguarda gli storici di richieste utente come PEC o ticket di assistenza, utilizzati per costruire sistemi di classificazione. Ad esempio, in un sistema che Make IT ha sviluppato per la classificazione automatica delle PEC in ingresso al Comune di Cinisello Balsamo, lo storico messo a disposizione copriva cinque anni di messaggi. Al suo interno si trovavano inoltri verso uffici soppressi anni prima, richieste classificate secondo logiche ormai cambiate, messaggi che il sistema non avrebbe dovuto prendere in carico. Nessuna di queste anomalie era documentata, sono emerse lavorando sui dati.
2. L'output ha sempre un margine di incertezza
Quando l’Intelligenza Artificiale entra in un sistema B2B, cambia una condizione implicita su cui si basano i sistemi tradizionali: la prevedibilità del risultato.
A parità di input, l’output non è sempre lo stesso; il sistema può restituire esiti diversi o introdurre errori che non seguono uno schema stabile. Per questo, nei contesti reali, il problema non è ottenere una risposta sempre corretta, obiettivo che questi sistemi non garantiscono, ma costruire un funzionamento che renda gestibile questo margine di errore.
In pratica, significa definire quando un risultato può essere utilizzato in automatico e quando deve essere verificato, rendere esplicito il livello di affidabilità e progettare l’interazione in modo che l’utente possa intervenire senza bloccare il processo.
È un cambiamento sostanziale rispetto al software tradizionale: il sistema non restituisce più una risposta certa, ma un risultato che deve essere interpretato all’interno del contesto operativo.
Questo cambia il rapporto tra utente e sistema. L'operatore non riceve una risposta certa, ma un suggerimento con un livello di affidabilità esplicito. Progettare questo comportamento richiede di definire le soglie, comunicarle nell'interfaccia e formare gli utenti a lavorarci. Un sistema che non espone l'incertezza non è più affidabile: è solo meno governabile.
Nel sistema di classificazione delle PEC realizzata per il Comune di Cinisello Balsamo, la scelta progettuale è stata di non restituire mai una sola risposta automatica; al contrario, il sistema propone la destinazione con la confidenza più alta, più due o tre alternative ordinate per probabilità. Quando la confidenza supera una soglia definita, l'operatore può procedere rapidamente, quando scende sotto quella soglia, l'interfaccia lo segnala e richiede una verifica manuale.
3. Privacy e perimetro dei dati
Nei sistemi che gestiscono richieste utente, e-mail, documentazione o ticket, i dati trattati possono includere informazioni personali o sensibili. Quando questi contenuti vengono utilizzati per alimentare modelli di Intelligenza Artificiale, soprattutto esterni, il perimetro cambia: non tutto può essere inviato al modello e non tutto può essere gestito nello stesso modo. In molti casi è necessario definire con precisione:
- quali dati possono essere inviati al modello;
- quali devono essere filtrati o anonimizzati;
- quali vanno esclusi dal processo.
Questa scelta non è mai standard, ma dipende dal tipo di processo e dal contesto in cui il sistema viene utilizzato. Ad esempio, un sistema che elabora manualistica tecnica ha vincoli minimi; un sistema di customer care di primo livello che risponde a richieste degli utenti, come quello che Make sta realizzando in ambito sanitario, si trova a trattare dati sulla salute, riferimenti a situazioni personali, contesti che non possono essere inviati a un modello esterno senza un trattamento preventivo.
Rimuovere o anonimizzare i dati senza distinguere quali informazioni servono realmente al sistema può compromettere la qualità del risultato; al contrario, utilizzare i contenuti senza filtri adeguati espone a criticità legate al trattamento dei dati sensibili.
4. I costi dipendono dall'uso, non solo dallo sviluppo
Nei sistemi che integrano modelli AI tramite API, i costi operativi dipendono direttamente da come il sistema viene progettato e utilizzato. Numero di richieste generate, quantità di contesto inviato al modello e modalità di interazione degli utenti incidono sui consumi e rendono il costo del sistema strettamente legato ai volumi di utilizzo reali.
In un sistema B2B con accesso esteso, questa dinamica può evolvere in modo non lineare. Un utente che interagisce a lungo con il sistema o un processo che genera più richieste per ogni singola operazione produce costi molto diversi da quelli stimati sul singolo utilizzo medio.
Il controllo passa anche dalle scelte progettuali. Ridurre il contesto al necessario, evitare ridondanze nelle richieste e limitare le elaborazioni non rilevanti sono interventi che incidono direttamente sui costi operativi. In alcuni casi si cerca di rendere i costi più prevedibili, ma questo è possibile solo se i volumi di utilizzo sono stimati in modo attendibile prima del rilascio.
In realtà, però, stimare questi volumi su un sistema nuovo è complesso perché il comportamento degli utenti reali potrebbe divergere dalle ipotesi iniziali.
Per questo il controllo dei costi va considerato già in fase di progettazione: definire quante richieste vengono generate per ogni operazione, limitare il contesto inviato al modello e monitorare l’utilizzo fin dalle prime fasi sono scelte che incidono direttamente sulla sostenibilità del sistema.
5. Aggiornamento dei modelli e continuità operativa
Un sistema AI addestrato su un dataset ha una data di validità implicita. Quando cambiano le normative di riferimento, i processi interni, la struttura degli uffici o i comportamenti degli utenti, il modello inizia a produrre risultati meno coerenti con il contesto attuale. In altre parole, il sistema continua a generare output, ma questi diventano progressivamente meno coerenti con il contesto operativo.
Con i modelli attuali, il riaddestramento non avviene a sistema attivo ma richiede di lavorare su dati aggiornati, rivedere il modello, verificarne il comportamento su casi di test e solo dopo rimettere il sistema in produzione. È un processo che introduce tempi, costi e una fase di verifica che non può essere ridotta.
Nei sistemi che lavorano su documentazione normativa, procedure operative o basi di conoscenza che si aggiornano nel tempo, questa attività deve essere pianificata. Non come intervento straordinario, ma come parte del ciclo di vita del sistema.
Un approccio orientato ai sistemi reali: il ruolo di Make IT
Portare l’Intelligenza Artificiale nei sistemi B2B non è una sfida legata alla potenza del modello, ma alla sua integrazione nel contesto reale. Come abbiamo visto, il successo di un progetto non si misura nella qualità della demo, ma nella capacità di gestire dati imperfetti, governare l’incertezza degli output e garantire sostenibilità economica, affidabilità e continuità nel tempo.
Passare dalla sperimentazione alla produzione significa smettere di considerare l’AI come una “scatola nera” e iniziare a trattarla come un vero asset del software aziendale, che richiede manutenzione continua, controlli, meccanismi di governo e monitoraggio.
In questo scenario, affidarsi a un partner professionale come Make IT significa poter contare su competenze progettuali capaci di adattare l’AI al contesto operativo reale, mantenendo coerenza tra architettura, processi e sostenibilità del sistema nel tempo.
In oltre vent’anni di esperienza nello sviluppo software, l’azienda ha lavorato su sistemi enterprise, integrazioni applicative e processi operativi complessi, affrontando problematiche che diventano evidenti soprattutto quando l’AI entra nei flussi di lavoro reali.
