"Quali contratti scadono nei prossimi due mesi?" "Quante ore abbiamo fatto per questo cliente quest'anno?" "Preparami il testo del rinnovo."

Farsi rispondere a domande così senza costruire un filtro, senza esportare in un foglio di calcolo e senza chiedere a qualcuno che sa dove guardare, è una delle poche applicazioni dell'AI in azienda che si ripaga da sola in poche settimane. Soprattutto perché la usa anche chi non ha nessuna voglia di imparare l'interfaccia del CRM.

È anche una delle poche che, fatta male, mette l'intero archivio clienti a portata di una frase scritta male. Vale la pena sapere dove passa la differenza.

Cosa succede davvero quando fai una domanda

Il modello linguistico non "guarda dentro" il vostro database. Riceve delle domande e ha a disposizione un elenco di strumenti che qualcuno ha scritto: cerca clienti, leggi la scheda, elenca i contratti in scadenza. Ogni strumento è codice normale, con dentro una interrogazione precisa e un elenco preciso di campi che può restituire.

Questo è il punto che cambia tutto: quello che il modello può vedere è esattamente quello che gli strumenti gli passano, niente di più. Non è una questione di quanto è bravo o di quanto è furbo chi scrive la domanda. È una lista, e la lista la scrivete voi.

Le tre condizioni

Sola lettura, salvo eccezioni dichiarate. Il default deve essere che non si scrive niente. Se serve una scrittura, per esempio creare le attività di un progetto, si dichiara quale, si limita a quelle entità e si sa che esiste. Sul nostro CRM funziona così: tutto in lettura, tranne la gestione dei progetti, che è scritta nella documentazione perché chiunque possa saperlo.

Un elenco esplicito di cosa può uscire. Non "tutto il CRM tranne le cose sensibili", che è una lista destinata a rimanere indietro. Al contrario: questi campi di queste entità, e nient'altro è raggiungibile. Da noi restano fuori utenti e credenziali, note interne, allegati, configurazione di sistema e il dettaglio delle fatture: il fatturato si vede aggregato sulla scheda del cliente, che è quello che serve per lavorare.

Il perimetro imposto due volte. Nel codice, con i campi filtrati da una lista di ammessi. E nel CRM, con un utente tecnico dedicato che ha solo quei permessi. Se il codice ha un errore, i permessi lo fermano; se i permessi vengono allargati per sbaglio, il codice lo ferma. Una barriera sola prima o poi passa.

Le domande che vi faranno, e le risposte

"I nostri dati finiscono nell'addestramento di qualcuno?" Dipende dal contratto con il fornitore del modello, non dal vostro CRM: va letto, e va scritto nella policy aziendale. È esattamente il genere di cosa che l'AI Act vi chiederà di sapere. Ne parliamo nella pagina sulla governance dell'AI.

"Chi ha chiesto cosa?" Serve un registro. Non per sfiducia verso le persone, ma perché il giorno in cui qualcosa non torna, la domanda "chi ha tirato fuori quell'elenco e quando" deve avere una risposta.

"E se risponde una cosa sbagliata?" Succede, ed è il motivo per cui questa roba va bene per cercare e preparare bozze, non per decidere da sola. Il testo di un rinnovo lo scrive in trenta secondi, ma chi lo manda al cliente è una persona che lo ha letto.

Da dove partire

Non dal comprare uno strumento. Da una lista di dieci domande che in azienda si fanno tutte le settimane e che oggi richiedono di chiedere a qualcuno o di aprire tre programmi. Se quelle dieci domande hanno risposta nei dati che avete già, il lavoro consiste nello scrivere gli strumenti che le coprono, con il perimetro deciso prima.

Se invece quelle domande non hanno risposta perché i dati sono sparsi in cinque posti diversi, il problema non è l'AI: è che manca il pezzo prima. Quello lo raccontiamo nella pagina del servizio CRM, e comincia sempre allo stesso modo, mettendo ordine.