Il rifiuto che arriva dal fornitore, non da voi
Un esempio dal lavoro vero, senza fare nomi. Un sistema che genera bozze di risposta per il servizio clienti di un'azienda che vende prodotti soggetti a regole particolari. Funziona bene per mesi. Poi il fornitore aggiorna il modello e alcune richieste iniziano a ricevere un rifiuto educato, perché la nuova versione considera quella categoria di prodotti materia delicata.
Non è un errore del modello. Non è un difetto del vostro codice. È una decisione presa da qualcun altro, per ragioni sensate dal suo punto di vista, che ricade sul vostro prodotto senza che nessuno vi abbia avvisato.
Il caso opposto succede altrettanto: comportamenti che prima venivano bloccati e ora passano. Se avevate costruito un controllo assumendo che il modello rifiutasse, quel controllo adesso non c'è più.
Perché queste regole esistono e perché non spariranno
Vale la pena essere chiari: le regole di comportamento non sono un capriccio. Chi produce un modello risponde di quello che il modello dice, davanti alla legge, alla stampa e ai propri clienti. Un sistema senza limiti sarebbe ingestibile e nessuna azienda seria lo adotterebbe.
Il problema non è che i limiti esistano. È che sono decisi da un attore privato, applicati globalmente, calibrati su un contesto culturale e normativo che spesso non è il vostro, e modificabili unilateralmente.
Un modello addestrato e allineato altrove porta con sé assunzioni su cosa è appropriato dire, su come si parla di certi temi, su quali forme di comunicazione sono aggressive e quali no. In italiano, e per il mercato italiano, quelle assunzioni ogni tanto stonano. Non è censura: è che la taratura è stata fatta guardando altrove.
Cosa significa avere un prodotto sopra questa dipendenza
Tre conseguenze concrete, in ordine di gravità.
- Il comportamento del vostro prodotto può cambiare senza che voi abbiate toccato niente. È la differenza più importante rispetto a qualunque altra dipendenza software. Una libreria, se non la aggiornate, resta com'era. Un modello dietro un servizio no: la versione sotto si muove.
- Non potete spiegare ai vostri clienti perché il sistema ha rifiutato. La regola non è vostra e non la conoscete nella sua forma esatta. Potete solo constatarla.
- Le vostre garanzie contrattuali poggiano su qualcosa che non controllate. Se avete promesso a un cliente che il sistema tratterà un certo tipo di richiesta, quella promessa dipende da una decisione altrui.
Cosa si può fare, senza raccontare favole
Non esiste un modo di eliminare questa dipendenza mantenendo i vantaggi. Ci sono modi di ridurne l'impatto, e valgono la pena.
- Sapere cosa fa il sistema, di continuo. Una serie di casi vostri, quelli che devono funzionare per forza, eseguiti automaticamente a ogni aggiornamento del fornitore. Non è una valutazione di qualità raffinata: è un allarme antincendio. Se un caso che ieri passava oggi viene rifiutato, volete saperlo prima del cliente.
- Fissare la versione, quando si può. Molti fornitori permettono di ancorare le richieste a una versione specifica invece che all'ultima disponibile. Costa qualcosa in termini di aggiornamento e compra prevedibilità.
- Progettare il fallimento. Cosa fa il vostro prodotto quando il modello si rifiuta? Se la risposta è mostrare il messaggio di errore del fornitore all'utente finale, il prodotto non è finito. Un rifiuto deve avere una via di uscita pensata: una risposta di ripiego, un passaggio a una persona, una formulazione diversa.
- Tenere il controllo dove è vostro. Le regole del vostro dominio, quelle che riguardano il vostro settore e i vostri obblighi, non delegatele al modello. Se un contenuto non deve uscire, il controllo che lo blocca è codice vostro, verificabile e testabile, non una speranza che il fornitore continui a pensarla come voi.
- Avere un'alternativa provata. Non tre fornitori in produzione, che è un costo inutile. Un secondo percorso che avete già fatto funzionare almeno una volta, così che il giorno in cui serve il lavoro sia di ore e non di mesi.
La posizione
L'espressione che circola per descrivere tutto questo è che pochi soggetti decidono le regole di espressione per tutti. È vera e non è la parte interessante, perché nella pratica non si risolve indignandosi.
La parte interessante è che chi costruisce prodotti su questi sistemi sta accettando, spesso senza scriverlo da nessuna parte, che una parte delle regole del proprio prodotto sia scritta da un'altra azienda. È una scelta legittima. Diventa un problema quando è implicita, quando il contratto con il cliente finale non ne tiene conto, e quando nessuno in azienda sa dire cosa succede il giorno in cui quelle regole cambiano.
La nostra regola operativa è semplice: tutto quello di cui rispondete davanti a un cliente deve stare in codice che potete leggere. Il modello fa il lavoro difficile. Le decisioni le prendete voi.
