Un assistente AI può aggiornare il gestionale? Come delimitare le azioni

Un assistente che sbaglia una risposta si corregge rileggendo. Un assistente che sbaglia una scrittura lascia un dato sbagliato nel gestionale, e da lì partono una fattura, una consegna o una telefonata a un cliente. È la stessa tecnologia, ma il rischio cambia natura: si passa da un’informazione discutibile a un’operazione compiuta.

La domanda «l’intelligenza artificiale può aggiornare il gestionale?» ha quindi una sola risposta utile: sì, su operazioni definite in anticipo, con permessi propri, con un controllo prima della scrittura e con un registro di quello che ha fatto. Il lavoro sta tutto nel decidere quali operazioni.

Leggere, proporre, scrivere: tre livelli, tre rischi

La distinzione più utile non è tecnica ma organizzativa, e riguarda chi si assume l’esito.

Quasi tutti i progetti utili vivono nei primi due livelli. Il terzo si concede alle operazioni ripetitive e reversibili; il quarto, in pratica, non si concede.

L’assistente non è un amministratore: eredita i permessi di un ruolo

L’errore di impostazione più frequente è collegare l’assistente con un accesso che può fare tutto, perché è più rapido da configurare. Da quel momento ogni limite dipende soltanto dalle istruzioni date al modello, cioè dalla parte più facile da aggirare.

• L’assistente ha una propria utenza, distinta da quelle delle persone, con i permessi minimi per i compiti assegnati.
• Se risponde a utenti diversi deve vedere quello che vedrebbe quell’utente: un commerciale non deve poter ottenere tramite l’assistente dati che il gestionale gli nega.
• Gli strumenti collegati sono un elenco chiuso. «Può interrogare la banca dati» non è un elenco: è un accesso generale con un altro nome.
• Le prove si fanno su un ambiente separato, non sui dati di produzione, e vanno ripetute ogni volta che i permessi cambiano.

Le scritture si delimitano per campo, non per buone intenzioni

Delimitare significa scrivere l’elenco delle operazioni ammesse, ciascuna con i suoi campi e le sue condizioni. Quello che non è nell’elenco non è possibile, non è sconsigliato: la differenza è tutta lì.

• Quali campi può toccare l’operazione, e quali restano in sola lettura anche quando l’assistente ne parla.
• Quali valori sono ammessi: una data futura, uno stato fra quelli previsti, un cliente che esiste. La convalida sta nel sistema, non nelle istruzioni scritte al modello.
• Su quali record: i propri, quelli aperti, quelli del periodo corrente. Il caso «aggiorna tutti i clienti» non deve poter esistere.
• Quante volte: un limite al numero di operazioni per sessione impedisce che un fraintendimento diventi un lavoro di ore da annullare a mano.

Un flusso di esempio: spostare un appuntamento

Operazione ripetitiva, a basso rischio, con un cliente dall’altra parte. Sequenza illustrativa.

1. Arriva una richiesta: «Il tecnico di giovedì può venire venerdì mattina?». L’assistente individua di quale appuntamento si parla e, se i dati non bastano, chiede invece di indovinare.
2. Verifica le condizioni: l’appuntamento esiste, non è già chiuso, chi scrive ha diritto di spostarlo, la nuova data è disponibile per quel tecnico.
3. Prepara la proposta con i valori compilati: vecchia data, nuova data, tecnico, cliente.
4. Mostra la proposta a chi deve autorizzarla e attende un consenso esplicito. Il consenso vale per quella proposta, non per le successive.
5. Esegue la sola operazione autorizzata, con un identificativo che impedisce di applicarla due volte se la richiesta viene ripetuta.
6. Registra l’esito e comunica che cosa è cambiato. Se l’operazione non riesce lo dice apertamente: un assistente che riferisce un successo mai avvenuto è peggio di uno che sbaglia.

Il passaggio che si taglia per primo, e che invece regge tutto, è il quarto. Senza una conferma esplicita il sistema non è più delimitato: è soltanto ben istruito, e le istruzioni non sono un limite.

Duplicati, ripetizioni e come si torna indietro

Le richieste si ripetono: qualcuno riscrive, la rete cade, l’assistente riprova. Se ogni tentativo produce un’operazione, ci si ritrova con tre appuntamenti spostati e due avvisi mandati al cliente.

• Ogni operazione porta un identificativo derivato dalla richiesta: se arriva due volte, la seconda non produce nulla.
• Prima di creare qualcosa si cerca se esiste già: un cliente, un ordine, un appuntamento simile nello stesso giorno.
• Per ogni operazione va scritto come si annulla e chi può farlo. Alcune sono reversibili, altre no: un messaggio inviato a un cliente non si ritira, e questo basta a spostarlo fra quelle che richiedono una conferma umana.
• Le operazioni fatte in sequenza vanno pensate come un blocco: se la terza fallisce, va deciso in anticipo se le prime due restano o vanno annullate.

Il registro: che cosa, quando, su richiesta di chi

Senza registro non si può rispondere alla domanda che prima o poi arriva: perché questo appuntamento è stato spostato? Il registro serve a ricostruire, non a incolpare.

• La richiesta originale, l’operazione eseguita e i valori scritti.
• Chi ha autorizzato, quando e attraverso quale canale.
• L’esito, compresi i tentativi non riusciti e le operazioni rifiutate dai controlli.
• Quanto si conserva e chi può consultarlo: il registro contiene dati aziendali e a volte personali, e si protegge come il resto.

I rifiuti registrati sono la parte più utile nei primi mesi: dicono che cosa l’assistente ha provato a fare e non ha potuto. È da lì che si capisce se i limiti sono troppo stretti o troppo larghi, senza doverlo scoprire da un errore.

Quello che questa guida non copre

Qui si tratta il controllo delle azioni: quali operazioni sono permesse, chi conferma, come si registrano. Le verifiche tecniche per collegare due software fra loro, cioè che cosa espone ciascuno e che cosa succede quando uno cambia, sono un argomento a sé. Lo è anche la difesa dalle istruzioni ingannevoli nascoste nei documenti o nei messaggi che l’assistente legge: è un rischio diverso, con contromisure proprie.