Abbiamo un reparto sistemi ma nessuno specialista di IA: come si divide il lavoro

Mese due, giovedì pomeriggio, un messaggio nel gruppo del progetto: «il bot ha risposto a caso a un cliente». Sistemi controlla e può dimostrare che il flusso è andato a termine, senza una sola eccezione, esattamente come era scritto. La risposta è stata comunque sbagliata, e la conversazione si blocca lì, perché nessuno ha definito prima di partire chi si fa carico di quel tipo di domanda.

La linea di demarcazione che evita quel giovedì non passa per ciò che è tecnico né per ciò che è difficile: passa per il fatto che la risposta corretta si conosca in anticipo. Il tuo reparto sistemi si tiene tutto quello che ha una risposta nota e verificabile —accessi, infrastruttura, sicurezza, integrazioni, finestra di rilascio—. Lo specialista si tiene l'unica cosa che non si verifica leggendo il codice: il comportamento del modello.

Diviso così, sistemi non resta a guardare, perché conserva il veto sulla produzione e sui dati, e non diventa nemmeno un collo di bottiglia, perché non deve imparare a scrivere prompt né a valutare risposte perché il progetto avanzi. Qui sotto c'è la tabella con le dodici decisioni concrete, chi decide e chi esegue ciascuna, i tre accessi da concedere e quello mai, e la prova delle tre domande per classificare la decisione tredici: quella del giovedì, quella che non è in tabella.

La linea di demarcazione è deterministico contro probabilistico, non tecnico contro non tecnico

L'errore classico è dividere per competenza tecnica: «questo è difficile, lo fa quello di fuori». Quel criterio non divide niente, perché il tuo reparto sistemi quasi sempre capisce della tua operatività più di qualunque fornitore appena arrivato.

Il criterio che invece divide è la natura della risposta. Il tuo reparto sa rispondere al perché il processo delle 3 del mattino è fallito: legge il log, trova l'errore, lo sistema. C'è una risposta corretta ed è scritta. Nessuno risponde allo stesso modo al perché il bot ha risposto quella cosa a quel cliente, perché non c'è nessun log che lo dica. Il flusso è stato eseguito alla perfezione, ha restituito 200, non c'è stata nessuna eccezione, e la risposta è stata comunque sbagliata. Dietro ci sono un prompt, un insieme di documenti, un modo di recuperarli e un modello che può rispondere in modo diverso la settimana prossima senza che nessuno abbia toccato niente.

Questa è la frontiera. Tutto quello che si verifica leggendo il codice o guardando un cruscotto degli errori è di sistemi. Tutto quello che si verifica solo leggendo cento conversazioni reali è dello specialista. Dividere lungo quella linea evita l'esito che nessuno ha firmato: sistemi resta responsabile formale di una cosa che non ha modo di verificare.

La tabella: dodici decisioni, chi decide e chi esegue

Questo è quello che va compilato prima della prima riunione tecnica. Metti nome e cognome in ogni cella, non le aree.

Tre cose che si leggono male a prima vista e sono quelle che fanno funzionare la tabella.

Sistemi decide cinque delle dodici ed esegue quattro. Non è un ruolo di accompagnamento: è l'unico che può fermare un rilascio. Se il tuo responsabile sistemi guarda questa tabella e non ci vede potere reale, controlla se gli hai tolto il veto sulla produzione, perché è lì che vive.

Il business ne decide sei e ne propone una settima. Quasi tutte le decisioni che stabiliscono se il progetto serve —cosa si risponde, cosa no, quando interviene una persona, cosa si misura— non sono tecniche. Quando quelle celle restano vuote o dicono «IT», il progetto finisce per essere una dimostrazione che non usa nessuno.

Lo specialista ne esegue otto e ne decide una sola: quale modello si usa e con quale configurazione. È deliberato. Un fornitore che decide anche quali domande rifiuta il tuo bot sta prendendo decisioni commerciali senza il tuo contesto.

La tabella si manda già compilata prima della prima riunione, non si presenta durante: la divisione viene mal digerita quando la si scopre a metà strada, mai quando la si annuncia prima. Tre cose vanno dette quando la si manda, e nessuna richiede più di una riga. Che le cinque righe di sistemi non si toccano senza il loro ok, veto sulla produzione incluso. Che il prompt, i documenti e la valutazione delle risposte non si aggiungeranno al loro carico. E che quello che ti serve indietro sono definizioni con una data —quale ambiente, con quale utenza, chi del loro team entra nella riunione settimanale—, non una relazione.

I tre accessi da concedere e quello mai

Sistemi dovrà concedere accesso a dati aziendali. Quello che si negozia non è se concederlo: è in che forma.

• Un'utenza di servizio nominativa, con scadenza. Dedicata al flusso, con data di scadenza a 90 giorni rinnovabile. Se il progetto si ferma o il fornitore cambia, l'accesso muore da solo.
• Lettura su una vista o su una replica, non sulla produzione. Con i campi che il flusso usa davvero. Un bot che risponde su giacenza e prezzo non ha bisogno di vedere il margine né il costo di acquisto. Definire quell'elenco richiede dieci minuti ed è ciò che evita la discussione di dopo, quando qualcuno scopre che il modello aveva il costo sotto gli occhi.
• Un ambiente di prova con dati anonimizzati per le prime due settimane, che è quando si rompe di più.

Quello che non si concede: amministratore sulla produzione. Se la richiesta iniziale del fornitore è quella, non è il segnale che ne sa molto, è il segnale che va di fretta.

La decisione tredici: la prova delle tre domande

La tabella copre le dodici decisioni che si possono prevedere. Quella che rompe la divisione è la tredicesima, e non arriva in una riunione: arriva un martedì come un messaggio sciolto di quattro parole, «il bot risponde male», che qualcuno deve inoltrare da qualche parte. Se quella classificazione si fa a intuito, in due settimane torni al criterio che non divide niente: questo sembra difficile, mandalo a quello di fuori.

Tre domande in ordine. La prima che dà un sì chiude il caso, e le può applicare in trenta secondi chi riceve il messaggio, senza sapere niente di IA.

1. Esiste una risposta corretta scritta da qualche parte già da prima? Un listino prezzi in vigore, un orario, un permesso, un limite dell'account del fornitore. Se esiste e qualcuno può aprirla e leggerla, il caso è di sistemi, per quanto il sintomo sia arrivato parlando del bot.

2. È rimasto un errore da qualche parte? Un timeout, un'eccezione, un'esecuzione che risulta fallita, un messaggio che non è mai partito. Se il guasto ha lasciato traccia è di sistemi, e si sistema come si sistema qualunque altra cosa. Se la traccia non esiste —per il sistema non è successo niente di strano e quello che è sbagliato è il contenuto— è dello specialista, e conviene dirlo ad alta voce nella riunione di avvio: quel caso non lo segnalerà mai un cruscotto degli errori, quindi se nessuno ha il compito assegnato di leggere, non viene rilevato.

3. Per sapere se è venuto bene, bisogna leggere? Se la verifica consiste nell'aprire la conversazione e giudicare se quella risposta serviva, esegue lo specialista e decide il business, perché «serviva» è una definizione commerciale. Sistemi non può firmare quello, e chiederglielo è ciò che lo lascia responsabile di una cosa che non ha modo di verificare.

Quattro casi che arrivano con la stessa faccia e si dividono in modo diverso:

• «Il bot non ha risposto a cinque messaggi di ieri pomeriggio.» Sistemi. Ci sono esecuzioni fallite, un servizio fermo o un limite dell'account: la traccia esiste e anche la risposta corretta.
• «Il bot ha dato un prezzo che non esiste più.» Prima sistemi, e quasi sempre finisce lì: il numero è uscito da una tabella che si sincronizza ogni tanto ed è arrivato tardi. Solo se il dato era giusto in origine e il modello ne ha comunque detto un altro, il caso passa allo specialista. È lo stesso sintomo con due possibili proprietari, e a decidere quale è una interrogazione al database, non un'opinione.
• «Il bot si è inventato una politica di reso che non abbiamo.» Specialista e business. La domanda 1 dà no: quel documento non esiste, ed è per questo che il modello ha riempito il vuoto. La soluzione non è tecnica, è scrivere la politica che non è mai stata scritta e metterla nel corpus.
• «Ha offerto uno sconto a un cliente.» Decide il business, esegue lo specialista. Sembra un errore del sistema ed è una decisione commerciale che non ha preso nessuno: cosa può promettere l'assistente e cosa deve girare a una persona. Se questo lo risolve sistemi da solo, la tua politica sugli sconti l'ha scritta chi ha configurato il prompt.

Il caso in cui due persone applicano la prova e ottengono risultati diversi è l'unico che merita di andare alla riunione settimanale. Gli altri si inoltrano e basta, che è tutto quello che si chiede a una divisione dei compiti.

I due modi in cui questo si rompe

La coda. Sistemi dice di sì, il progetto parte, e l'accesso al database finisce dietro alla migrazione dell'ERP e alla chiusura del mese. C'è una cosa specifica dei progetti di IA che peggiora la situazione: la prima richiesta a sistemi non è un'attività ma una definizione —quale ambiente, su quali dati, con quale utenza—, e una definizione non ha né tipo di ticket né stima, quindi resta a galleggiare come «da discutere». Si risolve chiedendo una data impegnativa per quelle tre definizioni nella riunione di avvio, non chiedendo urgenza.

L'avvio in produzione a sorpresa. L'assistente va in produzione e sistemi lo scopre quando una interrogazione satura il database un giorno 3, in piena chiusura. Si risolve con una sola regola: la finestra di rilascio la fissa sistemi, sempre, anche se il flusso non tocca niente di loro.

Le tre capacità che non si possono dividere perché ancora non esistono

Una divisione dei compiti assegna lavoro che qualcuno già sa fare. La tabella risolve la convivenza, che è il problema del primo mese, e funziona finché c'è un assistente o due o tre flussi in produzione e le risposte si possono rivedere leggendo a occhio.

Ci sono tre capacità che nessuna cella della tabella contiene, perché non sono compiti ma mestieri che la tua azienda ancora non ha dentro, ed è per questo che mettere altri nomi non le fa comparire:

1. Quando bisogna decidere se le risposte sono abbastanza buone. Dividere i compiti non crea la capacità di costruire un set di casi di prova, eseguirlo ogni volta che cambia il prompt o il modello, e sapere se è peggiorato. Quello è un processo permanente, non una riunione.
2. Quando il modello cambia da solo. I fornitori aggiornano e ritirano le versioni. Un assistente che rispondeva bene può iniziare a rispondere in modo diverso senza che nessuno della tua azienda abbia toccato niente. Qui non basta nemmeno leggere una conversazione: letta da sola, la risposta nuova sembra ragionevole. Si nota solo a confronto con le risposte di prima, e questo richiede di averle conservate.
3. Quando passi da uno a cinque flussi. Lì compare la domanda a cui nessuna divisione dei compiti risponde: perché questo cliente ha ricevuto due messaggi, quale dei cinque flussi glieli ha mandati, e in quale ordine girano.

Questo è il limite reale: la tabella mette ordine su chi fa cosa con quello che già sai fare. Quello che non si può dividere è la parte che nessuno del team sa ancora fare, ed è esattamente la parte che fa sì che l'assistente continui a servire all'ottavo mese.

In una riga

Compila la tabella questa settimana e usa la prova delle tre domande con il primo «risponde male» che arriva. Se il tuo reparto sistemi conserva il veto sulla finestra di rilascio e non si carica la valutazione delle risposte, la divisione si regge da sola.

E metti in agenda una seconda cosa, che è quella che quasi nessuno mette in agenda: fra sessanta giorni, mezz'ora per rieseguire le stesse tre domande sulle stesse conversazioni conservate. Se le risposte sono cambiate e nessuno della tua azienda ha toccato niente, hai smesso di discutere il punto 2 in astratto e sei passato ad avere la prova dentro la tua stessa operatività. Quella mezz'ora vale più della riunione di avvio, ed è l'unica attività di tutta la tabella che non puoi delegare né a sistemi né al fornitore, perché chi decide se una risposta è accettabile è il proprietario del processo.

Due decisioni vicine a cui questa tabella non risponde e che conviene non mescolarci: se conviene mettere qualcuno dentro invece di portare uno specialista si risolve con ore e con soldi, e il conto a 12 mesi è in assumere o esternalizzare; quello che va chiuso per iscritto prima di firmare è in le 12 domande da fare a un fornitore.

Quando la tabella è compilata, mandala a info@striqtech.com. Quello che ci si legge non è quale strumento hai scelto: è quante delle dodici righe sono finite con lo stesso nome nelle due colonne.