Governance e sicurezza · 7 min di lettura
Chi vede, chi ha fatto cosa, cosa non si cancella: la governance di FlowSharp
A cura di FlowSharp
5 ottobre 2026
Tra la release 0.87 e la 0.88 FlowSharp ha imparato a rispondere alle tre domande di ogni audit: permessi per cartella che valgono ovunque, un registro attività esportabile e uno storico delle pratiche che il database stesso impedisce di alterare.
Chi può vedere: permessi per cartella che valgono ovunque
Nel primo articolo della serie abbiamo raccontato Jev, l'AI di FlowSharp che decide e passa la mano a una persona quando non è sicura. Automatizzare le decisioni, però, ha senso solo se ogni decisione resta tracciabile, riservata a chi deve vederla e conservata come prova. Questo articolo racconta le fondamenta che lo rendono possibile, arrivate tra la release 0.87 e la 0.88.
Il punto di partenza è semplice. Quando un workflow engine gestisce contratti, ordini, perizie e decisioni assistite dall'AI, diventa il luogo in cui restano le prove di come l'azienda lavora. Chi si occupa di compliance, il DPO, il responsabile qualità, la direzione, soprattutto nei settori regolati come finanza, sanità, pubblica amministrazione e assicurazioni, fa sempre le stesse tre domande: chi può vedere questo processo, chi ha fatto cosa, cosa non si può cancellare. Le risposte devono arrivare senza fogli Excel e senza un «fidati». Una precisazione di onestà: non dichiariamo la conformità a una norma specifica. Offriamo strumenti che aiutano a produrre le evidenze che un audit richiede.
La prima risposta sono i permessi per cartella di flussi, su tre livelli: lettura, scrittura e gestione. Si assegnano a singoli utenti, a ruoli personalizzati e a ruoli di sistema, e si ereditano lungo l'albero delle cartelle: si imposta la regola una volta in alto e vale per tutto ciò che sta sotto.
La parte che conta di più è che la regola vale ovunque. Chi non è elencato non vede i flussi, le loro versioni e le pratiche in corso in nessun punto del prodotto: negli elenchi, nelle ricerche, nelle analisi, nelle mappe di processo, nelle esportazioni, nelle chiavi di integrazione e nell'assistente. Spostare un flusso in un'altra cartella sposta con lui tutte le versioni, e le pratiche in corso seguono subito le nuove regole, senza finestre in cui qualcosa resta esposto per errore.
Dalla 0.88.6 c'è anche una tutela contro le sviste. Togliere l'ultima regola da una cartella non la riapre più a tutti: senza regole la vedono solo gli amministratori. Riaprirla è un'azione esplicita, confermata e tracciata. I permessi per cartella sono una funzione premium, attivabile per organizzazione.
Chi ha fatto cosa: il registro attività
La seconda domanda è quella che un revisore fa per prima: chi ha fatto cosa, e quando. Gli amministratori trovano in FlowSharp un registro attività che per ogni evento riporta chi lo ha compiuto, quando, da quale canale (browser, automazioni o assistenti AI) e su quale oggetto. Si filtra per attore, azione, oggetto e periodo e si esporta in CSV o in JSON, così le evidenze si possono consegnare a chi le chiede nel formato che preferisce.
Il registro non si limita alle modifiche ai dati. Traccia anche gli accessi, gli accessi falliti, le verifiche a due fattori, i recuperi password, le modifiche alle bozze dei flussi, le esportazioni e le condivisioni. Una regola vale per tutto: password, codici e token non vengono mai registrati. Il registro serve a ricostruire che cosa è successo, non a creare un nuovo posto dove custodire segreti.
La conservazione si imposta per organizzazione, da 30 giorni a 10 anni, ed è separata da quella delle pratiche. Si può quindi decidere per quanto tenere la traccia delle azioni indipendentemente da quanto si conservano i dati operativi.
Un dettaglio che fa la differenza: se la scrittura nel registro fallisce durante un'operazione delicata, l'operazione viene annullata. Preferiamo un errore visibile a un «fatto» che non ha lasciato traccia.
Cosa non si cancella: storico protetto e legal hold
La terza domanda riguarda la solidità della prova. Lo storico delle pratiche e il registro attività sono protetti direttamente nel database: le modifiche e le cancellazioni ordinarie vengono rifiutate, anche se arrivano da un punto del software che non avrebbe dovuto permetterle. Le uniche eccezioni sono operazioni previste e tracciate, come la conservazione a scadenza. Una prova che chiunque può correggere a posteriori, in fondo, non è una prova.
Per i casi in cui serve congelare la situazione c'è il legal hold, la conservazione legale. Un amministratore mette in conservazione una pratica o una versione di processo indicando un motivo. Da quel momento la pratica non si elimina, né a mano né per scadenza, i suoi documenti non si cancellano e il processo non si rimuove. Un badge lo segnala a colpo d'occhio e le liste hanno un filtro dedicato per trovare tutto ciò che è sotto vincolo. Anche il legal hold è una funzione premium.
Dati riservati, account e sessioni
La governance riguarda anche dove vanno i dati. Il designer, e dalla 0.88.1 anche la pubblicazione, avvisano quando un campo riservato esce verso webhook, eventi, script o modelli AI senza schermatura. Non è un divieto: chi progetta il flusso decide con cognizione di causa, e l'avviso compare nel momento in cui la decisione si prende, non mesi dopo durante una verifica.
Per i modelli AI c'è il registro delle chiamate, che per ogni provider conserva i metadati e il costo stimato. Se lo si sceglie, conserva anche i messaggi inviati e ricevuti; con la schermatura attiva, in quei messaggi compaiono solo pseudonimi. È il Data Shield di cui abbiamo parlato nell'articolo su Jev, che qui diventa anche un'evidenza consultabile.
Anche l'accesso degli utenti ha regole chiare. Dieci tentativi sbagliati in un quarto d'ora bloccano l'account, le ultime cinque password non si possono riusare, ogni sessione web ha un tetto massimo di durata e il logout chiude tutte le sessioni. Nel profilo ciascuno vede le proprie sessioni attive, con dispositivo e indirizzo, e può revocarle una per una. L'amministratore ha lo stesso elenco per ogni utente, utile quando c'è un dubbio su un accesso o un collaboratore lascia l'azienda.
Per gli integratori: le stesse regole per tutti
Un permesso che vale solo nell'interfaccia è un permesso a metà. In FlowSharp le chiavi di integrazione e il Flow Agent rispettano gli stessi permessi degli utenti: per scrivere o gestire serve il livello corrispondente. Via MCP, i ruoli Operator e Sola lettura ricevono la stessa vista ridotta che vedrebbero nell'interfaccia.
Le credenziali scritte nei task Webhook non vengono mai restituite agli agenti: al loro posto c'è un segnaposto. Una chiave limitata a certi flussi non vede nel catalogo gli strumenti che le verrebbero rifiutati, così l'agente non perde tempo a provarli, e quando un'operazione non è consentita riceve gli stessi codici di errore della REST API. Chi integra scrive quindi una sola logica di gestione degli errori, valida per entrambi i canali.
Le richieste al trigger dei flussi e agli strumenti per agenti hanno un limite reale e non aggirabile, pensato per proteggere l'installazione da automazioni impazzite o da un uso scorretto.
Infine, un audit di sicurezza ha chiuso le strade secondarie: pratiche correlate, analisi, confronti di mappe ed estensione. Il principio che abbiamo verificato voce per voce è uno solo: chi non può vedere un flusso non lo vede da nessuna parte.
La fiducia si costruisce con la tracciabilità
Il nostro motto resta «prima misura, poi automatizza», e la governance ne è il complemento naturale: si automatizza con serenità quando si sa chi può vedere cosa, si può ricostruire chi ha fatto cosa e si è certi che la prova non cambi. Jev può decidere perché ogni sua decisione lascia una traccia che resiste nel tempo.
Nel prossimo articolo della serie parleremo dei processi che si impacchettano e si portano da un'installazione all'altra: un altro modo di rendere il lavoro ripetibile, verificabile e davvero dell'azienda.