1. Il progetto nasce già maggiorenne

Il progetto DLP nacque un martedì alle 9:12, quando il direttore generale inoltrò a dodici persone un articolo che non aveva letto, accompagnandolo con una domanda che conteneva già una data di scadenza:

«Noi questa cosa ce l’abbiamo, vero?»

Era una domanda interessante. Non specificava quale cosa, per fare cosa, a protezione di cosa. Specificava però molto bene che sarebbe stato spiacevole rispondere di no.

Alle 9:19 qualcuno scrisse «stiamo verificando». Alle 9:26 era nato un gruppo di lavoro. Alle 10:04 il gruppo aveva un nome inglese, una cartella condivisa e diciassette partecipanti. Alle 11:30 esisteva già una presentazione con una freccia che andava da sinistra a destra: il segno convenzionale che in azienda si sta facendo progresso, anche quando non si è ancora deciso verso dove.

Paolo, responsabile IT, lesse la catena mentre cercava di capire perché una stampante avesse cambiato religione e rifiutasse i documenti di amministrazione.

«Che cosa vogliamo ottenere?» domandò.

«Proteggere i dati», rispose il direttore.

«Quali?»

«Quelli importanti.»

«Importanti per chi?»

«Paolo, non complichiamo subito le cose.»

La riunione cominciò dunque con un accordo: il progetto sarebbe stato semplice, purché nessuno facesse domande che richiedessero una risposta.

Il titolo arrivò poco dopo: “DLP - Data Loss Prevention”. Prevenire la perdita dei dati. Una formulazione rassicurante, quasi materna. Nessuno perde niente. Tutto resta dove deve stare. Un adulto digitale controlla che i bambini non escano dal cancello.

Restavano da stabilire i bambini, il cancello, gli orari di uscita e chi fosse autorizzato a venirli a prendere. Ma quelli, spiegò qualcuno, erano dettagli implementativi.

Fu in quel momento che l’idea venne dichiarata approvata.

Non c’era, ma aveva superato il comitato.

2. Il capitolato del soprannaturale

La prima raccolta dei requisiti produsse un risultato ambizioso: la DLP avrebbe dovuto impedire qualsiasi uscita impropria di informazioni, consentire tutte quelle legittime, non rallentare il lavoro e non richiedere interventi alle persone.

«E niente falsi positivi», precisò il commerciale.

«E niente falsi negativi», aggiunse la sicurezza.

«E niente costi operativi», concluse il direttore finanziario, che riconosceva sempre il momento giusto per rendere impossibile una cosa già difficile.

Paolo riassunse: «Quindi deve capire tutto, non sbagliare mai e gestirsi da sola».

«Esatto. Una soluzione moderna.»

La modernità, in quella stanza, consisteva soprattutto nell’aver abolito la necessità di spiegare le proprie intenzioni.

Il caso d’uso ideale era questo: lo stesso dipendente invia lo stesso file allo stesso indirizzo. Se sta lavorando, il messaggio deve passare. Se sta rubando informazioni, deve fermarsi. Se ha sbagliato allegato, il sistema deve avvisarlo con discrezione. Se ha allegato il file giusto ma non si ricorda di averlo fatto, possibilmente deve tranquillizzarlo.

«Da cosa distingue i casi?» chiese Paolo.

«Dal contesto.»

La parola “contesto” entrò nel verbale con la funzione che nelle fiabe ha la polvere magica: veniva sparsa sopra un problema e ci si aspettava che il problema prendesse il volo.

Nessuno aveva descritto il processo di lavoro, censito i destinatari, identificato i documenti o assegnato le responsabilità. Il contesto avrebbe dovuto presentarsi spontaneamente alla console, ben vestito, con un documento di identità.

Il direttore generale aggiunse l’ultimo requisito:

«Deve anche capire quando faccio un’eccezione.»

«Glielo diciamo?»

«Se devo dirglielo io, che intelligenza è?»

Il capitolato era pronto. Mancava soltanto una casella per specificare la confessione religiosa del fornitore.

3. La demo e il mondo senza cognati

Il fornitore arrivò con una demo bellissima. C’era un utente chiamato Test User, che lavorava nel reparto Test Department e provava a spedire un file chiamato Confidential_Data.xlsx a un indirizzo evidentemente esterno.

Il sistema lo bloccò.

Nella sala calò quella particolare ammirazione che si prova quando una macchina risolve un problema che le era stato preparato con tutte le risposte scritte dietro.

«Vedete?», disse il direttore.

Paolo vedeva. Vedeva anche che Test User non aveva un consulente del lavoro con una casella storica, un cliente che pretendeva i documenti sul proprio portale, un socio che usava l’indirizzo personale e un amministratore delegato che aveva promesso tutto entro mezzogiorno.

Il mondo della demo non conteneva cognati. Nelle aziende vere, invece, almeno un processo critico dipende da qualcuno che è contemporaneamente fornitore, ex dipendente e cognato di una persona che non conviene bloccare.

La slide successiva conteneva “context aware”, “intelligent decision-making” e “autonomous remediation”. La sala si rilassò. Se era consapevole del contesto, prendeva decisioni intelligenti e rimediava da sola, evidentemente avevano trovato chi avrebbe partecipato alle riunioni al posto loro.

La dimostrazione successiva mostrò il riconoscimento di contenuti sensibili. Funzionava. Era una capacità reale e utile. La sala però compì un salto logico notevole: dal riconoscere determinati contenuti al comprendere l’intera organizzazione, comprese le sue contraddizioni del giovedì.

Elena, della sicurezza, provò a rallentare l’entusiasmo.

«Dobbiamo verificare i nostri casi, i canali coperti e come gestiremo le eccezioni.»

«Certo», rispose il fornitore. «Serve una fase di progettazione.»

Quella frase venne udita da tre persone e archiviata dalle altre come rumore ambientale.

Nel verbale rimase: “Dimostrata piena rispondenza alle esigenze”. Le esigenze, essendo ancora sconosciute, non poterono smentire.

Il sogno non se l’era inventato soltanto il cliente. Sullo schermo il prodotto capiva, decideva, interveniva. Le condizioni comparivano durante le spiegazioni tecniche; i verbi restavano nella memoria. Il marketing consegnava un soggetto quasi umano, il cliente gli assegnava un compito sovrumano. In mezzo, chi doveva configurarlo riceveva il verbale.

4. Chi sa quanto vale un file?

La settimana seguente Paolo convocò i responsabili dei reparti per identificare le informazioni da proteggere.

«Ci serve sapere quali documenti avete, dove sono e quali usi devono essere consentiti.»

La richiesta fu accolta con la perplessità che si riserva a un idraulico che chieda al cliente dove passa l’acqua.

«Ma non potete vederlo voi?»

Vederli, in parte, sì. Decidere che cosa significassero, era un’altra faccenda. IT poteva trovare un file chiamato finale_vero_2_definitivo_bis.xlsx. Non poteva ricavare dal nome se contenesse il budget riservato, la lista dei panini o il budget riservato nascosto nella lista dei panini, secondo una tecnica di classificazione sviluppata autonomamente da amministrazione.

«Il valore lo conosce chi usa l’informazione», osservò Paolo.

«Appunto. Voi gestite i sistemi.»

Con lo stesso ragionamento, chi costruisce i frigoriferi dovrebbe decidere se il contenuto del Tupperware sia una cena, un esperimento o un’emergenza biologica.

Il direttore commerciale portò un esempio: «I nostri listini sono riservati».

«Tutti?»

«Certo.»

«Anche quello pubblicato sul sito?»

«Quello è diverso.»

«E quello che mandate ai rivenditori?»

«Anche quello.»

«E quello personalizzato per il cliente?»

«Dipende dal cliente.»

Finalmente stavano emergendo informazioni utili. Non erano ancora regole, ma erano l’inizio di un ragionamento. Purtroppo erano anche le 12:27 e alle 12:30 il commerciale aveva un’altra riunione.

«Facciamo così: per ora considerate tutto riservato. Poi affiniamo.»

“Poi affiniamo” è il certificato di nascita di molti incidenti organizzativi. Ha un tono artigianale, quasi da liuteria. In pratica significa che qualcuno dovrà risolvere, sotto pressione, quello che oggi non abbiamo voglia di definire con calma.

5. HR scopre il verbo analizzare

Marta, responsabile HR, era stata tra le sostenitrici più convinte del progetto. Nei suoi uffici passavano informazioni delicate e l’idea di proteggerle meglio le sembrava sensata.

Poi Elena descrisse i controlli previsti sui contenuti.

«Aspetta», disse Marta. «Che cosa significa che il sistema analizza gli allegati?»

«Che cerca gli elementi rilevanti per le regole.»

«Negli allegati di HR?»

«Se rientrano nell’ambito del controllo, sì.»

«Ma lì ci sono informazioni riservate.»

Era una frase impeccabile. Era anche il motivo per cui erano riuniti.

La conversazione si complicò quando emerse la possibilità che gli alert rendessero visibili a chi li gestiva alcuni dettagli del contenuto, secondo la configurazione e gli strumenti adottati.

Marta pose domande precise: chi avrebbe potuto vedere cosa? Sarebbe stato necessario mostrare un intero documento? Gli accessi sarebbero stati limitati e tracciati? Quanto sarebbero rimaste quelle informazioni? Si potevano separare i compiti?

Erano domande serie. Il problema fu che, essendo serie, nessuno le aveva incluse nel budget.

«Dobbiamo coinvolgere le persone competenti e progettare questi aspetti», disse Elena.

Il direttore guardò l’orologio. «Ma noi abbiamo comprato la protezione dei dati. Adesso dobbiamo fare un progetto per proteggere i dati dalla protezione dei dati?»

«Dobbiamo decidere come usare lo strumento.»

«Mi sembra una complicazione.»

Marta non voleva che documenti delicati diventassero consultabili da chiunque avesse accesso a una console. Aveva ragione. Elena non poteva promettere controlli utili senza capire quali segnali servissero. Aveva ragione anche lei. Paolo avrebbe voluto almeno un pomeriggio in cui due persone avessero ragione senza che questo diventasse un suo problema.

La soluzione proposta dalla sala fu escludere HR.

Il primo reparto escluso dalla protezione delle informazioni fu dunque quello che aveva spiegato meglio perché le proprie informazioni andassero protette.

6. Il listino che voleva uscire

Il commerciale fu più diretto.

«La DLP va benissimo, purché non blocchi le vendite.»

Era una posizione comprensibile. Il reparto esisteva per concludere affari, non per collezionare schermate rosse. Elena chiese allora di descrivere i flussi: listini pubblici, condizioni riservate, sconti autorizzati, offerte specifiche, destinatari previsti.

«Non possiamo descrivere ogni trattativa.»

«Non ogni trattativa. Le situazioni ricorrenti.»

«Ogni cliente è speciale.»

L’azienda aveva quindi quattromila clienti e nessun caso normale.

Si scoprì che alcuni listini potevano uscire, altri solo verso certi soggetti, altri ancora dopo un’autorizzazione. Lo stesso documento poteva contenere parti divulgabili e margini interni. C’erano fogli nascosti, note dimenticate e colonne che “tanto il cliente non guarda”.

«Questa colonna dei margini va tolta prima dell’invio», osservò Paolo.

«La togliamo sempre.»

«Qui c’è.»

«Quello è un caso particolare.»

Il caso particolare risultò essere il modello usato da tutto il reparto.

Per la prima volta la riunione sfiorò una soluzione concreta: preparare un documento destinato all’esterno che non contenesse i dati interni, invece di chiedere al sistema di indovinare quali celle il cliente avrebbe avuto la cortesia di ignorare.

«Sì, ma rifare il modello richiede tempo.»

Il software doveva quindi compensare anche l’impossibilità organizzativa di cancellare una colonna.

Poco dopo un venditore mandò un’offerta al proprio indirizzo personale per finirla a casa. Il sistema di prova segnalò l’operazione.

«Falso positivo», decretò il responsabile.

«Il documento è riservato e sta andando a una casella personale», disse Elena.

«Ma lo conosco.»

Si prese nota di un nuovo requisito: integrazione con la fiducia personale del direttore commerciale, comprese le sue variazioni stagionali.

7. Legal e il legittimo dipende

L’avvocato Rinaldi ascoltò le questioni emerse e rispose con prudenza. Le informazioni non avevano tutte la stessa natura, gli usi non erano equivalenti e i vincoli andavano esaminati nei casi concreti.

«Quindi?» chiese il direttore.

«Dipende.»

Il “dipende” di Legal era corretto. Il problema era che l’azienda voleva caricarlo in una casella con due opzioni: consenti o blocca.

Elena propose di tradurre almeno alcune condizioni in criteri operativi: quali documenti, quali destinatari, quali autorizzazioni, quali controlli. L’avvocato annuì. Sarebbero serviti esempi e persone dei reparti.

«Non possiamo avere una policy generale?» domandò il direttore.

La policy generale arrivò dopo pochi giorni. Diceva che le informazioni dovevano essere trattate in modo appropriato da soggetti autorizzati, per finalità legittime e attraverso strumenti idonei.

Era una frase alla quale nessuna persona ragionevole poteva opporsi. Era anche una frase con la quale nessun amministratore di sistema poteva configurare alcunché senza organizzare altre sei riunioni.

Paolo provò comunque a cercare “appropriato” nell’elenco delle condizioni disponibili. La console, mostrando un raro senso del limite, non lo conteneva.

«Chi è autorizzato?» chiese.

«Chi ne ha necessità per il proprio ruolo.»

«Chi lo stabilisce?»

«Il responsabile competente.»

«Quale?»

La risposta richiese un allegato.

Non c’era niente di sbagliato nell’avere principi generali. Sbagliato era presentarli come se il lavoro fosse finito. Una policy può dire dove si vuole andare. Qualcuno deve ancora verificare le strade, i mezzi e se il ponte regge il camion.

Nel progetto, invece, la produzione del documento venne registrata come “definizione delle regole completata”.

Il camion poteva partire. Il ponte sarebbe stato coinvolto in una fase successiva.

8. Tutto riservato, niente distinguibile

Per uscire dall’impasse, venne lanciata la classificazione dei documenti. Quattro etichette, nomi comprensibili, esempi da preparare. In teoria, un passo utile.

In pratica, i responsabili ricevettero una comunicazione che chiedeva di classificare il patrimonio informativo entro venerdì.

Era mercoledì pomeriggio.

Marta classificò con attenzione alcuni casi, poi domandò chiarimenti su quelli ambigui. Il commerciale scelse “Riservato” quasi ovunque, perché “Pubblico” sembrava poco professionale. Amministrazione selezionò il livello più alto per prudenza. Un reparto lasciò il valore predefinito, convinto che fosse una raccomandazione ufficiale.

Venerdì risultò riservato anche il modulo per ordinare le capsule del caffè.

«Meglio abbondare», commentò qualcuno.

Abbondare funzionava finché l’etichetta era un adesivo. Quando cominciò a produrre conseguenze, l’azienda scoprì di aver messo il controllo passaporti tra la macchinetta e il distributore.

Altri reagirono nella direzione opposta: scelsero il livello meno restrittivo per riuscire a inviare i file. Non necessariamente per malizia. Se ogni scelta prudente trasformava un’attività normale in un ricorso amministrativo, il sistema stava insegnando una lezione molto precisa.

«Le persone non classificano bene», concluse il comitato.

Non avevano ricevuto criteri sufficienti, esempi pertinenti o tempo per capire. Avevano ricevuto una scadenza. L’avevano rispettata nel solo modo disponibile: facendo comparire una scritta su ogni documento.

La percentuale di file etichettati raggiunse un valore eccellente.

La percentuale di etichette sensate rimase fuori dal cruscotto, probabilmente per ragioni estetiche.

Elena fece notare che classificare tutto allo stesso modo cancellava proprio le differenze di cui avevano bisogno. Il direttore chiese se fosse possibile risolvere con una quinta etichetta.

Si pensò a “Veramente riservato”.

Paolo suggerì di prenotare anche “Questa volta sul serio”, per non farsi trovare impreparati al trimestre successivo.

9. L’interruttore dell’apocalisse

Elena voleva partire da pochi casi definiti, osservare cosa succedeva, correggere le regole e allargare gradualmente il controllo. Aveva perfino preparato delle prove con i reparti: operazioni da consentire, da avvisare e da fermare.

Il direttore preferiva un segnale forte.

«Se aspettiamo di essere pronti, non partiamo mai.»

Era vero in senso generale. Applicato ai controlli che potevano interrompere attività quotidiane, diventava una filosofia con un numero di assistenza.

«Partiamo su tutto», concluse. «Poi aggiustiamo.»

L’attivazione avvenne un lunedì mattina, perché l’azienda riteneva evidentemente insufficiente la sofferenza naturale di quella fascia oraria.

Alle 8:41 un documento per il consulente del lavoro venne fermato. Alle 8:47 un’offerta commerciale richiese un passaggio non previsto. Alle 8:53 amministrazione non riuscì a completare un invio abituale. Alle 9:02 un allegato innocuo venne segnalato per una corrispondenza che meritava di essere rivista.

Non tutti gli eventi avevano la stessa causa. Alcuni erano errori delle regole. Alcuni erano operazioni effettivamente rischiose che tutti avevano sempre fatto. Altri erano attività legittime per le quali nessuno aveva definito un percorso consentito.

Dal punto di vista del centralino, però, esisteva una sola categoria: “Quella roba nuova di IT”.

Paolo ricevette undici telefonate, tre messaggi urgenti e una visita fisica. La visita fisica rappresenta il livello più alto di escalation: significa che il richiedente ha deciso di portare il proprio disappunto fino alla tua scrivania, rinunciando temporaneamente all’aria condizionata del suo piano.

«Non funziona niente.»

«Quale operazione?»

«Ti sto dicendo: niente.»

La regola che doveva fermare certi invii stava fermando certi invii. Era quasi offensivo constatare con quanta precisione una macchina potesse eseguire una decisione presa male.

Alle 9:34 il direttore chiese di “ripristinare l’operatività mantenendo piena protezione”.

Paolo iniziò a sospettare che nel suo contratto mancasse una voce relativa alla moltiplicazione dei pani.

10. Falso positivo è quando mi dà fastidio

Nel pomeriggio venne convocata la riunione sugli errori della DLP. Il commerciale arrivò con un elenco.

«Sette falsi positivi.»

Elena aprì il primo caso: un foglio con informazioni interne inviato a un indirizzo personale.

«Qui la regola ha riconosciuto quello che doveva riconoscere.»

«Ma l’invio era necessario.»

«Allora dobbiamo discutere se e come consentirlo. Non è automaticamente un errore di riconoscimento.»

«Se mi blocca mentre lavoro, per me è falso.»

Era nata una tassonomia basata sull’irritazione.

Un controllo può sbagliare a identificare un contenuto. Può applicare una regola tecnicamente corretta ma scritta male. Può intercettare un’attività davvero rischiosa. Può infine mettere in luce che l’azienda ha costruito un processo normale sopra un’eccezione mai dichiarata.

Sono problemi diversi. Chiamarli tutti “falsi positivi” aiuta soltanto a chiudere prima la riunione, che infatti era l’unico obiettivo condiviso.

Il secondo caso riguardava una sequenza numerica senza il significato attribuito dalla regola. Quello era un errore da correggere. Il terzo riguardava un documento inviato al destinatario sbagliato. Il quarto un fornitore legittimo che nessuno aveva comunicato al progetto.

«Vedete?», disse il commerciale. «Quattro blocchi inutili.»

Nel terzo caso avevano evitato un errore. Ma poiché l’errore evitato non aveva prodotto un disastro, sembrava meno concreto dei quaranta secondi necessari a leggere l’avviso.

Il dipendente coinvolto ammise: «In effetti stavo mandando la tabella a un omonimo».

Si creò un breve silenzio. Era comparsa una prova di utilità, evento difficile da gestire in una riunione convocata per dimostrare che lo strumento fosse inutile.

Il responsabile recuperò subito: «Sì, ma non può chiedercelo tutte le volte».

La richiesta si perfezionava: il sistema doveva disturbare soltanto quando avevi torto, sapendo prima di disturbarti che avresti riconosciuto di avere torto.

11. La repubblica delle eccezioni

Per calmare gli animi venne introdotta una procedura di eccezione. Poteva essere una buona idea: motivazione, ambito preciso, approvazione, durata e revisione.

L’azienda ne adottò immediatamente la parte centrale: l’eccezione.

La motivazione divenne “esigenze operative”. L’ambito “il reparto”. La durata “poi vediamo”. L’approvazione arrivava con un messaggio del tipo “sblocca, ne rispondo io”, inviato da una persona che in caso di problema avrebbe chiesto chi avesse autorizzato lo sblocco.

La prima deroga fu per il consulente. La seconda per una casella. La terza per il direttore che usava quella casella. La quarta per il gruppo a cui apparteneva il direttore, perché gestire una singola persona sembrava poco elegante.

Ogni eccezione risolveva un problema locale. Nel loro insieme stavano costruendo una tangenziale attorno al controllo.

Paolo propose una scadenza.

«Fra trenta giorni la rivediamo.»

«E se siamo ancora impegnati?»

«La rinnoviamo motivandola.»

«Non puoi lasciarla e basta?»

In quel “e basta” viveva un’intera strategia di gestione del rischio.

Le eccezioni permanenti hanno un vantaggio: smettono di chiamarsi eccezioni. Diventano ambiente. Dopo sei mesi nessuno si chiede più perché un reparto sia escluso, come nessuno chiede perché ci sia una colonna portante in mezzo alla stanza. Si gira intorno e si arreda.

Elena preparò l’elenco delle deroghe per la direzione. Il documento risultò sorprendentemente lungo.

«Ma allora cosa stiamo proteggendo?» domandò il direttore.

Paolo aveva la risposta, ma anche un mutuo.

Disse: «Dobbiamo rivedere l’equilibrio tra copertura e necessità operative».

Era la traduzione aziendale di “abbiamo tolto quasi tutto quello che faceva rumore e adesso ci stupiamo del silenzio”.

Si decise di istituire un comitato eccezioni. Nel giro di un mese il comitato chiese un’eccezione alla cadenza delle proprie riunioni.

12. Il direttore è un contesto a sé

La questione della direzione emerse quando il sistema segnalò un invio del direttore generale verso il suo indirizzo personale.

«È il mio documento», disse.

Era un documento aziendale, preparato da tre reparti, contenente informazioni su altre persone. Ma “mio” aveva in quel momento il significato di “sono la persona più alta in questa catena di email”.

«Mi serve sull’altro computer.»

Paolo propose il canale aziendale previsto.

«Non ho tempo di fare tutti quei passaggi.»

I passaggi erano due. Il direttore ne aveva già spesi nove per spiegare perché non poteva farli.

Elena cercò di riportare la discussione sul punto: un ruolo elevato può richiedere accessi e usi specifici. Questo non rende automaticamente appropriata ogni destinazione scelta da chi ricopre quel ruolo.

«Io mi assumo la responsabilità.»

«Possiamo definire il caso e registrare la decisione.»

«Non vorrei burocratizzare.»

La responsabilità era gradita finché restava una manifestazione orale di autorevolezza. Scriverla sembrava un atto ostile.

Alla fine arrivò la richiesta di esclusione “per evitare impedimenti alle funzioni apicali”. Nessuno usò il termine privilegio. Si preferì continuità operativa, che nelle riunioni ha lo stesso potere detergente del limone nelle pubblicità.

Il resto dell’azienda capì perfettamente il messaggio: le regole erano importanti, soprattutto per chi non aveva abbastanza importanza da evitarle.

Quella scelta pesò più di molte comunicazioni di sensibilizzazione. Le persone osservano cosa succede quando il controllo incontra qualcuno che può protestare con successo. Imparano in fretta quale sia la differenza tra una regola e un suggerimento rivolto ai piani inferiori.

Una settimana dopo un responsabile domandò l’esclusione per il proprio reparto.

«Anche noi siamo critici.»

Nessuno aveva ancora chiesto di essere protetto meglio. Tutti avevano capito come chiedere di essere abbastanza importanti da esserlo meno.

13. Gli alert cercano una famiglia

Mentre i reparti discutevano, gli alert aumentavano. Non avevano opinioni, non partecipavano ai comitati, non rimandavano. Arrivavano.

«Chi li prende in carico?» chiese Paolo.

«La sicurezza», rispose il direttore.

Elena spiegò che il suo gruppo poteva occuparsi di alcuni aspetti, ma per capire certi eventi serviva il reparto interessato. Bisognava inoltre definire priorità, tempi, accessi e modalità di escalation. Non ogni segnalazione era un incidente. Non ogni incidente si poteva risolvere leggendo una riga.

«Allora IT.»

IT, nell’immaginario aziendale, è il reparto che esiste quando non si sa a chi assegnare un problema che contiene un elettrone.

Paolo fece presente che i suoi collaboratori gestivano già infrastrutture, assistenza e numerose urgenze che arrivavano senza appuntamento.

«Ma il sistema non automatizza?»

Automatizzava la produzione di segnali. Era precisamente il motivo per cui ne avevano tanti.

Vennero create una casella condivisa e una rotazione informale. La casella si chiamava dlp-alerts. La rotazione consisteva nello sperare che qualcun altro avesse guardato.

Lunedì c’erano ventinove eventi da verificare. Mercoledì ottantatré. Venerdì il numero aveva superato la soglia psicologica oltre la quale un arretrato smette di essere una lista e diventa paesaggio.

Una segnalazione può richiedere di capire il documento, il destinatario, il processo e ciò che è successo dopo. Se chi la guarda non ha tempo, informazioni o autorità per agire, il sistema ha prodotto una domanda e l’ha lasciata in una stanza vuota.

Elena lo spiegò al comitato.

«Serve capacità operativa.»

«Possiamo mettere un filtro?»

Lo misero. Gli avvisi finirono in una sottocartella.

Fu il primo risultato completamente automatico del progetto: il rischio arrivava e veniva archiviato senza disturbare nessuno. La produttività migliorò immediatamente, almeno dal punto di vista della posta in arrivo.

14. Le informazioni traslocano senza avvisare

Il progetto era nato attorno alla posta elettronica. Nel frattempo il lavoro si svolgeva anche attraverso cartelle condivise, applicazioni, portali, dispositivi e servizi diversi.

Non era un segreto. Semplicemente, nessuno aveva chiesto ai dati di partecipare alla riunione iniziale e loro avevano continuato a circolare come prima.

Un reparto caricava documenti su un portale del cliente. Un altro condivideva collegamenti. Un terzo aveva adottato un servizio approvato durante un progetto precedente, il cui referente era poi andato in pensione. Un quarto stava sperimentando uno strumento online perché “ci fa risparmiare tantissimo tempo”.

«La DLP controlla anche quello?»

La risposta dipendeva dalla soluzione, dalla configurazione, dalle integrazioni e dal canale. Una frase concreta, poco adatta a chi aveva acquistato la parola “tutto”.

«Ma abbiamo la DLP.»

Come se l’acronimo fosse una pellicola trasparente stesa sopra l’azienda, capace di seguire l’informazione anche quando entrava in un processo mai descritto.

Elena disegnò una mappa dei flussi conosciuti. Alcuni erano coperti, altri richiedevano verifiche, altri interventi differenti. La mappa non dimostrava che il progetto fosse inutile. Dimostrava che aveva dei confini.

Il direttore la guardò con disappunto.

«Nella presentazione iniziale non c’erano tutte queste frecce.»

«C’erano già nel lavoro.»

Era un’ingiustizia evidente: la realtà non aveva rispettato la semplificazione grafica.

Quando poi le persone incontravano un ostacolo senza avere un’alternativa praticabile, cercavano un modo per terminare l’attività. Non tutti erano aspiranti sabotatori. Alcuni dovevano consegnare una fattura entro le cinque e avevano ricevuto dal capo un ordine molto meno ambiguo della policy.

Proteggere un percorso ignorando gli altri può perfino spostare il lavoro verso percorsi meno visibili. Per questo il progetto doveva capire come si lavorava e rendere utilizzabili le modalità consentite.

La proposta venne classificata come “tema di processo”. Fu un modo molto raffinato per accompagnarla fuori dalla sala.

15. Context aware, tranne del fatto che non ci parliamo

Quando il progetto mostrò le proprie fatiche, qualcuno riaprì la presentazione commerciale. La salvezza era già scritta lì: contesto, decisioni intelligenti, rimedi autonomi, AI. Bastava evidentemente attivare meglio gli aggettivi.

«Dice che capisce», osservò il direttore.

Il verbo era il cuore del problema. Non “analizza questi segnali per questa funzione”. Capisce. Una parola che permette a chi ascolta di completare liberamente l’oggetto: i documenti, l’azienda, Marta, il commerciale, le intenzioni del direttore prima ancora che il direttore le abbia chiarite a se stesso.

Il mantra funzionava per traduzioni successive. “Context aware” diventava “sa come lavoriamo”. “Decision-making” diventava “decide al posto nostro”. “Autonomous remediation” diventava “se succede qualcosa, sistema tutto”. AI aggiungeva la certezza che qualsiasi limite residuo fosse una questione di pessimismo.

«Quindi il contesto sa che il consulente è autorizzato?» chiese Marta.

«Da quali informazioni dovrebbe ricavarlo?» rispose Elena.

«Se devo fornirgliele io, non è molto aware.»

Usare contenuti, identità, destinazioni e altri segnali può rendere un controllo più informato. Non rende automaticamente accessibile la decisione presa ieri al telefono e mai registrata. Il contesto disponibile al sistema non coincide con tutto ciò che esiste nella testa dell’azienda. Anche perché l’azienda non ha una testa sola: ne ha diverse, alcune in aperto contenzioso.

«E il rimedio autonomo?» insistette il direttore.

Un’azione automatica può essere utile, ma bisogna capire quale, in quali condizioni e con quali conseguenze. Un conto è intervenire entro un ambito definito. Un altro è sistemare da soli qualsiasi guaio, riconciliando HR e commerciale prima del caffè.

Nella brochure l’autonomia era una capacità. Nel budget era diventata l’assenza di persone. Nel progetto era diventata l’assenza di decisioni. Tre cose diverse, legate da una transizione grafica impeccabile.

Il marketing aveva responsabilità in quel viaggio: usare continuamente verbi umani rendeva molto comodo dimenticare i confini tecnici. Il cliente collaborava volentieri, selezionando ogni promessa che gli consentisse di saltare una riunione.

«Dobbiamo verificare cosa fa davvero nei nostri casi», concluse Elena.

«Con quello che costa, dobbiamo pensare ancora noi?»

Era la domanda definitiva. Avevano comprato assistenza alle decisioni, ma si aspettavano l’esonero dal decidere. E se la macchina avesse chiesto conferma, l’avrebbero giudicata poco intelligente. Se avesse deciso senza chiedere, troppo autonoma. Se avesse contraddetto un direttore, configurata male.

16. Quando il nome cresce più del progetto

Alla revisione trimestrale il progetto venne ribattezzato Data Protection.

«DLP è troppo limitante», spiegò il direttore. «Dobbiamo avere una visione più ampia.»

La visione più ampia era una richiesta sensata. Significava però occuparsi di altre domande: chi accede ai dati, come vengono condivisi, quali copie esistono, quanto restano disponibili, quali protezioni servono nei diversi momenti del loro utilizzo.

La sala aveva immaginato soprattutto di cambiare il titolo della presentazione.

Paolo mostrò alcune delle attività necessarie. «Dobbiamo coinvolgere chi gestisce questi aspetti e chiarire le responsabilità.»

«Cerchiamo di non allargare troppo il perimetro», rispose il direttore che lo aveva appena allargato.

Un mese dopo comparve Information Protection. Ancora meglio. Non soltanto il file, ma l’informazione, il suo valore, il suo uso. L’azienda aveva raggiunto un livello di astrazione al quale diventava difficile perfino domandare dove fosse salvato qualcosa.

Non era una scala ufficiale sulla quale salire comprando il gradino successivo. Erano modi di guardare un problema, con ambiti che potevano sovrapporsi. Nel loro caso, tuttavia, ogni nome nuovo veniva accolto come un avanzamento del progetto precedente.

La DLP non era pronta, ma Information Protection era già in roadmap.

Elena provò a usare l’occasione per tornare ai processi e al significato dei contenuti. Il direttore propose un logo nuovo per l’iniziativa. Il vecchio aveva un lucchetto, il nuovo uno scudo: un progresso visibile, soprattutto a schermo intero.

Durante la riunione il commerciale chiese se fosse stato finalmente risolto il problema del listino.

Il file era sempre lo stesso. Nessuno aveva ancora deciso quali colonne dovessero uscire e verso chi.

Nel frattempo era passato sotto tre grandi visioni strategiche. Si sarebbe potuto riconoscergli un avanzamento di carriera.

17. Il file che nessuno voleva mandare

L’incidente arrivò in un giovedì ordinario, senza cappuccio, senza musica drammatica e senza una riga di codice verde che scorresse sul muro.

Giulia doveva inviare un prospetto a un fornitore. Aprì una cartella, prese un file con un nome plausibile e lo allegò. Dentro c’erano anche dati che il fornitore non avrebbe dovuto ricevere: una copia di lavoro più ampia di quella destinata all’esterno.

Il flusso era stato escluso durante la prima settimana di proteste. L’esclusione, inizialmente temporanea, era ancora lì. Nessuno aveva completato la revisione del modello, perché l’urgenza che aveva giustificato la deroga era finita e con essa l’attenzione.

Il messaggio partì.

Il destinatario telefonò per avvisare dell’errore. L’azienda attivò le verifiche e le azioni necessarie a gestire il caso. Soltanto dopo cominciò la riunione destinata a stabilire chi avrebbe dovuto avere ragione prima.

«Come è possibile? Abbiamo la DLP.»

Paolo ricostruì i passaggi. Il controllo non si applicava a quel flusso per una decisione documentata. La revisione era rimasta aperta. Il file continuava a contenere informazioni non necessarie all’invio. Giulia aveva commesso un errore, dentro un processo che gli aveva lasciato molto spazio.

«Il sistema avrebbe dovuto capire che non voleva mandare quei dati», disse il direttore.

Era tornato il requisito originario: leggere il pensiero, possibilmente ignorando l’istruzione esplicita di non intervenire.

«Su quel flusso avevamo tolto il controllo», ricordò Elena.

«Sì, ma non per questi casi.»

«Quali casi avevamo definito?»

Nessuno rispose. La deroga diceva “esigenze operative”. La differenza tra l’esigenza giusta e quella sbagliata era rimasta nella testa di persone che, interrogate separatamente, ne avevano cinque versioni.

Giulia disse piano: «Il file si chiamava come quello del mese scorso».

Per un attimo il progetto tornò sulla Terra. C’erano documenti, cartelle, modelli, fretta e una persona che aveva sbagliato. Tutte cose molto meno affascinanti della telepatia, ma sulle quali si poteva finalmente lavorare.

18. Il processo al pulsante

La riunione successiva fu dedicata alle cause. Cominciò con un imputato già seduto: lo strumento.

«Forse abbiamo scelto il prodotto sbagliato.»

Poteva anche essere. I prodotti hanno limiti, difetti e differenze reali. Una configurazione può essere sbagliata. Una funzione può non coprire il caso necessario. Elena non aveva intenzione di assolvere il software per principio.

Chiese però di verificare i fatti prima di acquistare un nuovo nome per lo stesso problema.

Nel caso concreto il flusso era escluso. Altrove c’erano regole da affinare, canali da verificare e attività lasciate senza gestione. Cambiare prodotto non avrebbe automaticamente nominato i responsabili, corretto i modelli o fatto scadere le eccezioni.

«Il nuovo magari lo fa da solo», suggerì qualcuno.

L’azienda stava valutando il rinnovo del miracolo presso un’altra confessione. Il nuovo materiale commerciale usava già la parola “agentic”. Nessuno sapeva ancora cosa avrebbe cambiato nei loro casi, ma suonava come qualcuno che finalmente si sarebbe occupato della pratica.

Il direttore finanziario domandò perché non fossero stati previsti tutti quei costi di lavoro. Nella stima iniziale figuravano licenze, avvio e qualche giornata tecnica. Erano quasi assenti le ore dei reparti, la gestione degli eventi, la manutenzione delle regole e la revisione dei cambiamenti.

Il progetto era stato finanziato come l’acquisto di una lavastoviglie. Si era scoperto essere anche l’organizzazione della cucina, con persone convinte che i piatti sporchi fossero sempre di qualcun altro.

«Dovevamo saperlo prima», disse il direttore.

Elena aprì il documento iniziale. Lo avevano scritto. La voce era stata ridotta durante la revisione del budget per “massimizzare l’automazione”.

Ci fu un silenzio abbastanza lungo da consentire alla frase di invecchiare male in tempo reale.

Anche il fornitore venne coinvolto: dovevano verificare limiti, configurazioni e capacità sui casi reali. Questa volta gli vennero portati documenti e flussi rappresentativi, con le dovute cautele. Test User poteva finalmente andare in ferie.

Al suo posto c’era Giulia, che faceva domande meno comode e quindi molto più utili.

19. Un’idea, finalmente: ma piccola

Dopo l’incidente, Elena propose di ripartire da un flusso preciso: il prospetto che aveva creato il problema. Chi lo preparava, quali dati dovevano esserci, chi poteva riceverli, attraverso quale percorso, con quali verifiche e cosa fare in caso di anomalia.

«Solo questo?» chiese il direttore.

«Cominciamo da questo e da pochi altri casi prioritari. Li facciamo funzionare e poi estendiamo.»

Era una proposta poco spettacolare. Nessuna copertura universale, nessun cervello digitale sospeso sopra l’organigramma. C’erano persone chiamate per nome e domande alle quali potevano rispondere.

Giulia mostrò come preparava il prospetto. Si scoprì che usava un file più ampio perché il modello corretto era difficile da trovare. Amministrazione sistemò il modello e il percorso. Il referente confermò quali dati servissero al destinatario. IT ed Elena verificarono come tradurre i casi concordati nei controlli disponibili.

Provarono l’invio corretto. Passò. Provarono una versione con contenuti non previsti. Ottennero la reazione attesa dal controllo configurato. Provarono un caso ambiguo e decisero come gestirlo, compreso chi dovesse rispondere senza lasciare Giulia bloccata fino alla pensione.

Non provarono che qualsiasi errore futuro fosse impossibile. Provarono alcune cose precise e utili, sapendo quali avevano verificato e quali no.

Marta partecipò alla definizione degli accessi necessari per i casi HR, insieme alle altre funzioni competenti. Il commerciale portò finalmente due listini diversi: uno per l’esterno e uno per l’uso interno. Nessuno li confuse con una trasformazione digitale epocale. Erano due file. Ma erano due file sensati.

Le deroghe ebbero un responsabile e una scadenza. Gli eventi importanti trovarono persone incaricate di esaminarli. Le aree non ancora coperte vennero descritte senza colorarle di verde per incoraggiamento.

Il progetto faceva meno cose di quante ne promettesse la prima slide. Cominciava a farne alcune molto meglio.

Per la prima volta aveva un’idea. Purtroppo il budget del sogno era già stato speso.

20. Se non lo sai, sallo

Il guaio di un progetto impostato così è che chiede a uno strumento di produrre automaticamente ciò che l’organizzazione non ha ancora deciso. La licenza arriva subito. Il consenso interno, purtroppo, non è incluso neppure nel pacchetto più costoso.

Una DLP può essere utile. Può riconoscere situazioni, applicare controlli, avvisare, limitare certe operazioni e fornire segnali, nei limiti di ciò che è stato scelto, configurato e coperto. Può anche sbagliare, essere configurata male o risultare poco adatta a un’esigenza concreta. Sono cose da verificare, non da risolvere con la fede nel prodotto o con il disprezzo per la tecnologia.

Ma nessun cambio di logo rende superflue le domande che l’azienda aveva saltato. Cosa vale? Perché? Chi deve usarlo? Cosa deve poter fare? Quale rischio accettiamo? Chi decide nei casi dubbi? Chi controlla che quelle decisioni continuino ad avere senso?

Se queste risposte mancano, il software riceve l’incarico di indovinare. Se le risposte si contraddicono, riceve l’incarico di mediare. Se nessuno vuole occuparsene, riceve l’incarico di assumersi una responsabilità che poi, al primo problema, verrà comunque restituita a una persona. Generalmente Paolo.

Ecco perché “dall’idea al sogno” è un titolo generoso. Fa credere che all’inizio ci fosse un’idea. Spesso c’era soltanto una paura, una scadenza e qualcuno che aveva visto una demo. Il sogno, invece, era già completo di tutti i requisiti: autonomia totale, zero errori, nessun disturbo, comprensione universale e lettura del pensiero inclusa nel prezzo. Il marketing gli aveva dato le parole; l’azienda ci aveva messo tutto quello che non voleva più fare.

La domanda che aprì il progetto era: «Noi questa cosa ce l’abbiamo, vero?»

Quella che avrebbe dovuto aprirlo era: «Noi cosa vogliamo che faccia, esattamente?»

Richiede qualche minuto in più. A volte alcune riunioni. Può perfino costringere HR, IT, sicurezza, Legal e commerciale a parlare tra loro senza usare il fornitore come interprete emotivo.

Capisco che sia un sacrificio.

Ma se compri una DLP perché nessuno in azienda sa cosa vuole, rischi di ottenere soltanto una risposta molto veloce alla domanda sbagliata.

E quando finalmente ti chiederà cosa intendevi fare, cerca di non offenderti.

Sta facendo la domanda che mancava dall’inizio.