Negli ultimi due anni, l’azienda ha acquistato numerosi strumenti di intelligenza artificiale: assistenti conversazionali, plugin per la scrittura, robot per il servizio clienti e sistemi di risposta alle domande interne. Tuttavia, le capacità realmente consolidate sono poche. I prompt rimangono memorizzati sui computer personali, i flussi di lavoro sono dispersi negli angoli dei documenti, dopo il lancio degli agenti intelligenti mancano feedback e revisioni, e i collaboratori chiave continuano a dedicare gran parte del proprio tempo a richieste di tipo ripetitivo. Il problema spesso non è che i modelli non siano abbastanza intelligenti, ma che il sistema non abbia trasformato il “lavoro” in competenze professionali gestibili .
Innanzitutto, analizziamo: perché la finestra di chat non può essere considerata una posizione lavorativa
Un robot conversazionale termina la propria attività dopo aver risposto a una singola domanda. Una posizione lavorativa, invece, deve assicurare un’erogazione continua del servizio: raccogliere informazioni, applicare regole, interfacciarsi con i sistemi, aggiornare lo stato e, in caso di eccezioni, inoltrare la richiesta a un operatore umano. L’indennizzo per viaggio è un esempio tipico: l’utente potrebbe iniziare dicendo “Aiutami a presentare la nota spese”, poi chiedere “Quanto mi resta del budget mensile?” e infine allegare una nuova ricevuta. Se il sistema trattasse ogni dialogo come una nuova sessione, il flusso si interromperebbe, il contesto andrebbe perso e, a posteriori, non sarebbe possibile capire se il problema sia dovuto a una regola errata o a un’interfaccia difettosa.
Nel settore esiste già la pratica di configurare gli agenti intelligenti come “impiegati digitali”: assegnando loro una posizione, un numero di matricola, limiti di competenza e registri delle attività, accompagnati da SOP modificabili, basi di conoscenza, strumenti e tracce operative. Sul fronte open source, piattaforme come StaffDeck, sviluppate da OpenBMB e altre organizzazioni, concepiscono gli agenti come combinazioni gestibili di risorse, anziché come semplici stringhe di prompt. Per le aziende che sviluppano internamente o personalizzano soluzioni, ciò che vale la pena adottare non è tanto il nome del prodotto, quanto questo modello oggettivo.
Logica operativa: all’interno del sistema devono essere presenti almeno sette tipologie di oggetti
Per realizzare un sistema di impiegati digitali, occorre prima definire gli oggetti aziendali nelle specifiche, quindi passare alla scelta del modello.
- Archivio della posizione : nome o ruolo, numero di matricola, mansioni, stato online, utenti serviti. Senza un archivio, non vi sono punti di riferimento per autorizzazioni e valutazioni.
- Limiti di competenza : quali documenti possono essere letti, quali campi possono essere modificati, cosa non può essere promesso. Questi limiti devono essere modificabili dall’amministratore, non fissati rigidamente nei prompt.
- SOP / Competenze procedurali : scomporre processi complessi in nodi, supportando ramificazioni condizionate, chiamate di strumenti, ricerca di conoscenze e passaggio a operatori umani.
- Ontologia della conoscenza : temi, regole, fonti e manuali d’uso vengono conservati separatamente; le risposte devono sempre riportare la fonte originaria e le ricerche devono essere verificabili.
- Integrazione degli strumenti : tramite API HTTP o MCP, per consultare i limiti, creare documenti e aggiornare lo stato, anziché limitarsi a generare un semplice testo.
- Attività programmate : riassunti giornalieri, solleciti per scadenze superate, controlli delle scorte: queste attività periodiche non possono attendere che l’utente prenda l’iniziativa.
- Tracciamento e feedback : registrare percorsi, passaggi, strumenti, conoscenze e risposte; i like e i dislike, così come il passaggio a un operatore umano, entrano nella fase successiva di revisione.
Una singola richiesta reale spesso comprende più compiti. Gli impiegati digitali devono essere in grado di accedere prima alla SOP per le note spese, raccogliere tutti i campi e applicare le regole, per poi passare alla SOP per la consultazione dei limiti e chiamare l’interfaccia corrispondente. Se l’utente interviene durante il processo per porre domande sulla politica, occorre salvare il nodo corrente e, una volta risposto, tornare al flusso originario. Per le questioni che esulano dalle regole, il contesto va affidato al creatore o all’operatore di turno, vietando risposte arbitrarie senza fondamento.
Logica progettuale: ruoli, macchine a stati, gerarchia della conoscenza
Come si cambia ruolo
Almeno quattro categorie di persone: il creatore (che fissa l’esperienza nel personale), l’amministratore (che gestisce autorizzazioni, pubblicazioni e quote), l’utente (che assegna compiti agli impiegati digitali) e l’operatore di turno (che gestisce le eccezioni). Il creatore non dovrebbe avere di default il permesso di modificare le scorte o i prezzi; l’utente non dovrebbe vedere i prompt completi né le chiavi segrete. Anche le interfacce aperte devono essere gerarchizzate: le chiavi a livello di account possono gestire le risorse, mentre quelle a livello di dipendente consentono solo di avviare sessioni e consultare il proprio storico.
Le SOP utilizzano macchine a stati, non si basano esclusivamente sulla memoria conversazionale
Il linguaggio naturale può generare una bozza iniziale, ma l’esecuzione deve avvenire tramite macchine a stati: nodo corrente, slot raccolti, strumenti attivabili, tentativi di ripetizione in caso di errore, passaggio a un operatore umano. Quando un compito viene interrotto, è necessario serializzare il contesto e riprendere dal punto originario. Diverse SOP consentono cambiamenti in tempo reale, ma ogni passaggio deve lasciare traccia di “da dove proviene e quali informazioni confermate porta”, evitando che l’utente debba compilare nuovamente i moduli. Le versioni e le diramazioni devono essere reversibili: se si modifica un solo prompt sul posto, il sistema entra immediatamente in produzione, rendendo impossibile qualsiasi responsabilità successiva.
La conoscenza non deve essere trasformata in un grande miscuglio da cercare
Creare indici navigabili suddivisi per documento, capitolo, pagina e sommario; prima individuare in quale categoria potrebbe trovarsi l’informazione, poi localizzare il testo originale. Suddivisione della conoscenza: normative, descrizioni dei prodotti, discorsi post-vendita e casi eccezionali vanno separati; la ricerca mirata è più stabile rispetto alle parole chiave globali. Ogni risposta deve essere associata a fonte, regola e tema commerciale; nell’ambiente di test è necessario poter vedere “perché è stata selezionata questa parte”. La verifica e la messa a punto della ricerca risolvono spesso problemi meglio di un ulteriore, più grande, modello.
Sviluppo e implementazione: interfacce, isolamento, monitoraggio, accettazione
Durante il funzionamento, si consiglia di unificare l’ingresso, evitando che ogni competenza segua un proprio percorso e causi deragliamenti dello stato. La scoperta delle capacità, l’esecuzione isolata, l’integrità dei componenti e il calcolo delle quote devono essere completati in fase operativa, non sulla base di accordi predefiniti. Prima di pubblicare le competenze sul mercato interno, effettuare una scansione delle autorizzazioni: teste di autenticazione, variabili d’ambiente e credenziali di connessione non devono comparire nelle normali interfacce di lettura.
- Canale di esecuzione : il flusso sincrono è adatto ai dialoghi; il Run asincrono e il flusso di eventi sono ideali per la ripresa dopo interruzioni e per le code di lavoro, entrambi condividono lo stesso nucleo.
- Identità del canale : WeChat, WeChat Work, Feishu e DingTalk possono fungere da ingresso, ma l’identità del dipendente, la sessione e il tracciamento devono essere unificati; è vietato costruire memorie separate per ciascun canale.
- Sicurezza : la configurazione del modello fa riferimento esclusivamente a numeri di configurazione esistenti, senza restituire le chiavi dei fornitori; i risultati degli strumenti vengono anonimizzati quando vengono inseriti nel tracciamento.
- Copertura umana di emergenza : in caso di timeout, bassa fiducia, violazione di autorizzazioni o richiesta esplicita dell’utente di passare a un operatore umano, tutte e quattro le situazioni devono garantire un completo passaggio del contesto.
L’accettazione non deve limitarsi a verificare la sola capacità di “chattare”. Fornire una serie di scenari ripetibili: ciclo chiuso normale, domande intermedie, budget insufficiente, timeout dell’interfaccia, scrittura oltre autorizzazione, risposta negata per mancanza di fonte. Controllare ogni scenario: se i nodi sono stati ripristinati, se i documenti sono stati compilati correttamente, se il tracciamento è completo e se le eccezioni sono state affidate a un operatore umano. Il tasso di approvazione dei campioni, il tasso di gestione dei timeout e il numero di risposte prive di fondamento sono indicatori più adeguati del rating di soddisfazione come criterio di accesso all’implementazione.
Ordine di lancio: innanzitutto una fase di lavoro ripetitivo
Non lanciare subito un assistente universale. Scegliere tra i resoconti di follow-up delle vendite, le sollecitazioni di approvazione, le domande sulle normative o le pre-approvazioni delle spese, quei segmenti che si ripetono quotidianamente per più di mezz’ora; scrivere input, output, autorizzazioni ed eccezioni in quattro frasi, poi integrarli con SOP e due o tre interfacce di sola lettura o di scrittura limitata. Quando i dati principali sono sporchi o i nodi di approvazione poco chiari, prima completare gli oggetti e lo stato, poi sovrapporre l’esecuzione intelligente — una volta automatizzati i dati sporchi, si diffonderanno ancora più rapidamente in tutta l’azienda.
Come capire se la progettazione è stata fatta bene: quel segmento che prima dipendeva dai solleciti di gruppo e dalla compilazione di moduli non è più il percorso principale; i resoconti, le sollecitazioni e i riassunti possono essere verificati confrontandoli con i documenti; le situazioni poco chiare hanno un referente per l’upgrade; le operazioni sensibili sono sottoposte a controllo e i log sono consultabili. Per valutare se lo sviluppo è stato qualificato, guardare se una stessa SOP, dopo essere stata interrotta, riesce a riprendersi , se le risposte possono rintracciare la fonte , se i casi limite possono entrare nella fase successiva di revisione . Solo quando questi tre elementi sono superati, si può ampliare la gamma delle posizioni; è più stabile procedere così, piuttosto che predisporre molti ingressi per la chat fin dall’inizio.
La difficoltà tecnica dei sistemi di impiegati digitali non sta nella generazione dei dialoghi, ma nel trasformare posizioni, processi, conoscenze, strumenti e tracce in oggetti software versionabili. I prompt possono essere modificati dieci volte a settimana, ma una volta disperso il modello oggettivo, ogni competenza successiva finirà per scrivere la propria versione.Prima di tutto, bisogna far funzionare correttamente queste sette categorie di oggetti e la macchina a stati; solo così si può procedere con l’aggiornamento del modello; altrimenti, ogni volta che si cambia il modello, si tratta di un nuovo progetto, non di una semplice modifica della configurazione.