Se non sapete spiegare perché quella pratica è stata approvata, il problema non è l'archivio.
È che la regola applicata quel giorno non è scritta da nessuna parte in modo leggibile. Pwas rende le regole di istruttoria un documento esplicito, applicato dal sistema e ricostruibile anni dopo.
Le regole cambiano spesso. Il software che le applica, no.
In un intermediario finanziario o assicurativo le regole di lavorazione cambiano di continuo: nuove soglie, nuovi controlli, nuove categorie di rischio, nuovi obblighi informativi. Ma nella maggior parte dei sistemi quelle regole sono sepolte dentro il codice applicativo, scritte anni fa da qualcuno che non c'è più. Il risultato è doppio e sempre lo stesso: ogni modifica normativa diventa un progetto costoso, e quando un revisore chiede perché una pratica del 2023 è stata decisa così, la risposta richiede archeologia informatica invece di una consultazione.
scenario esemplificativo
Un'istruttoria in un intermediario di medie dimensioni.
Una pratica entra dalla rete: documenti caricati da un collaboratore, dati inseriti a mano, allegati eterogenei. L'operatore di back office verifica la completezza guardando una checklist che sta su un file condiviso, aggiornata l'ultima volta a marzo. Applica le soglie che ricorda, chiede le integrazioni mancanti via email, e quando tutto torna passa la pratica al responsabile per la decisione.
Il sistema registra il risultato — approvata, respinta, in attesa — ma non registra il ragionamento: quali controlli sono stati fatti, con quali valori di soglia vigenti in quel momento, quali eccezioni sono state concesse e da chi. Quell'informazione esiste solo come somma di email, note libere e memoria delle persone. Due anni dopo, quando un controllo interno chiede conto di quel fascicolo, ricostruirlo richiede giorni.
Cosa cambia con Pwas
Si parte scrivendo ciò che oggi non è scritto: quali documenti servono per ciascun tipo di pratica, quali controlli si applicano e con quali soglie, quali esiti sono ammessi, chi può concedere un'eccezione e con quale motivazione obbligatoria, quali passaggi richiedono una seconda firma. Sono cose che l'azienda già sa fare; quello che manca è averle in un documento che sia anche il meccanismo che le fa rispettare.
Da quella descrizione nascono le schermate, le code di lavoro, i permessi e i controlli automatici. La pratica entra e il sistema verifica da solo la completezza documentale secondo le regole del suo tipo, applica le soglie vigenti, richiede le integrazioni mancanti, e presenta al decisore un fascicolo già istruito con l'esito dei controlli e i punti che richiedono valutazione umana.
La stessa pratica, dopo
Il back office non controlla più la checklist: la checklist è il sistema, e segnala cosa manca nel momento in cui la pratica entra, non tre giorni dopo. Le soglie applicate sono quelle vigenti in quel momento, versionate: se cambiano il mese prossimo, le pratiche già decise restano leggibili con le regole di quando furono decise.
Quando il responsabile concede un'eccezione, l'eccezione è un dato: chi, quando, su quale controllo, con quale motivazione. Non una nota libera che nessuno rileggerà. Due anni dopo, la richiesta del revisore si soddisfa aprendo il fascicolo: controlli eseguiti, valori applicati, eccezioni concesse, decisori — tutto ricostruibile in una pagina, perché la traccia non è un registro che qualcuno doveva ricordarsi di compilare ma una conseguenza del funzionamento.
Quando cambia una soglia
Una comunicazione del mandante modifica i criteri di ammissibilità per una categoria di prodotto, con decorrenza dal primo del mese. Nel modo tradizionale è una richiesta di modifica all'applicativo, con analisi, sviluppo, verifica e rilascio — e nel frattempo l'ufficio applica la regola nuova a mano, sperando che nessuno sbagli.
Qui la modifica è l'aggiornamento di un valore e, se serve, di una condizione nella descrizione delle regole, con la decorrenza dichiarata. Si scrive, si verifica e si pubblica in giornata, e le pratiche entrate prima continuano a essere valutate con i criteri di allora — che è esattamente ciò che un controllo di conformità si aspetta di trovare.
il confronto
Cosa succede oggi, cosa succede dopo.
Le situazioni ricorrenti in un ufficio istruttorie o in una gestione sinistri.
Oggi
Le regole vivono nelle persone e nel codice
La checklist documentale è un file condiviso, aggiornato quando qualcuno se ne ricorda.
Le soglie applicate dipendono da cosa l'operatore ricorda e da quando ha letto l'ultima circolare.
Un'eccezione concessa è una nota libera nel campo commenti.
Ricostruire una decisione di due anni fa richiede giorni di lavoro.
Una modifica normativa passa da una richiesta di sviluppo, con tempi che superano la decorrenza.
I dati per la reportistica di vigilanza si estraggono e si riconciliano a mano.
Con Pwas
Le regole sono un documento che il sistema applica
La completezza documentale è verificata dal sistema all'ingresso della pratica.
Le soglie sono dichiarate, versionate e applicate con la decorrenza corretta.
Un'eccezione è un dato strutturato: chi, quando, su cosa, con quale motivazione obbligatoria.
Un fascicolo si ricostruisce aprendo una pagina, non ricostruendo un archivio.
Una modifica di soglia o di controllo si scrive e si verifica in giornata.
Gli estratti per la reportistica derivano dallo stesso modello, senza riconciliazioni.
come si arriva lì
Il percorso, in concreto.
Senza sostituire il gestionale pratiche e senza interrompere la lavorazione.
01
Mettiamo per iscritto le regole non scritte
Sessioni con back office e responsabili per portare fuori ciò che oggi sta nelle teste: checklist reali, soglie applicate davvero, eccezioni ricorrenti. È la fase che produce più valore anche a prescindere dal software.
02
Formalizziamo un tipo di pratica
Si sceglie una linea di prodotto e si descrive: documenti richiesti, controlli, soglie con decorrenza, esiti ammessi, poteri di deroga, passaggi a doppia firma. La validate voi prima che si costruisca qualcosa.
03
Colleghiamo i sistemi e i portali
Gestionale, archivio documentale e portali dei mandanti restano dove sono. Pwas scambia dati con loro attraverso le interfacce disponibili, evitando doppi inserimenti agli operatori.
04
Lavorazione reale in affiancamento
Si lavora un flusso vero con il nuovo sistema accanto al metodo attuale. Qui emergono le eccezioni che nessuno aveva raccontato, e si formalizzano man mano invece di essere aggirate.
05
Estensione e presidio interno
Si estende alle altre linee e si forma chi in azienda manterrà le regole: l'aggiornamento di una soglia deve poter essere fatto dall'ufficio conformità, non richiesto a un fornitore.
un esempio di flusso
Dalla pratica alla decisione, con le regole scritte.
Completezza documentale e soglie applicate dalla versione in vigore, casi fuori range segnalati e criteri conservati con la decisione.
cosa cambia strutturalmente
Le proprietà del sistema, non promesse di risultato.
Caratteristiche verificabili in dimostrazione, non dati di performance di altri operatori.
100%
delle decisioni ricostruibili
Controlli eseguiti, valori applicati, eccezioni e decisori restano associati alla pratica: la ricostruzione è una consultazione, non un'indagine.
versionate
le regole, con la loro decorrenza
Una pratica resta leggibile con i criteri vigenti quando fu lavorata, anche dopo che quei criteri sono cambiati.
in giornata
il tempo per adeguare una soglia o un controllo
L'aggiornamento è una modifica di configurazione scritta, verificata e pubblicata nello stesso giorno, non un rilascio applicativo.
esplicito
ogni potere di deroga
Chi può derogare, su cosa e con quale motivazione obbligatoria è dichiarato: nessuna eccezione può essere concessa fuori da una regola.
I valori descrivono il funzionamento della piattaforma, non risultati misurati presso clienti specifici. La verifica della conformità del sistema ai requisiti regolamentari applicabili alla vostra attività resta una valutazione che compete a voi e ai vostri consulenti.
approfondimento
Le domande che ci fanno responsabili operations e funzioni di controllo.
"Sostituite il nostro gestionale pratiche?"
Di norma no. Un gestionale pratiche maturo gestisce anagrafiche, contabilizzazione, provvigioni e rendicontazione verso i mandanti: sostituirlo è un progetto rischioso che raramente conviene.
Pwas copre il livello che in genere manca: la lavorazione governata dalle regole. Prende in carico la pratica, applica i controlli, gestisce le code, i poteri di deroga e la traccia della decisione, e restituisce al gestionale l'esito e i dati che gli servono. Il gestionale resta il libro contabile; Pwas diventa il posto dove si vede perché le cose sono andate come sono andate.
In alcune realtà, con il tempo, il perimetro si allarga e funzioni che stavano altrove si spostano. È una scelta che si prende dopo, con i dati in mano, non un prerequisito.
"La nostra funzione di controllo vuole poter verificare le regole da sola. È possibile?"
È esattamente il punto che rende questo approccio interessante per una funzione di conformità, ed è la differenza più concreta rispetto a un applicativo tradizionale.
In un sistema classico le regole di lavorazione sono codice: per sapere cosa fa davvero il sistema bisogna chiedere all'IT o al fornitore, e la risposta è una descrizione di seconda mano. La funzione di controllo verifica gli esiti, non il meccanismo.
Qui le regole sono un documento strutturato leggibile — quali controlli esistono, con quali soglie, con quale decorrenza, chi può derogare e in quali condizioni — e quel documento non è la documentazione del sistema: è il sistema. Non può esserci scostamento fra ciò che è scritto e ciò che viene applicato, perché sono la stessa cosa. Una funzione di controllo può leggerlo, confrontarlo con la propria normativa interna e rilevare differenze senza passare da nessuno.
Resta ovviamente il lavoro di verifica sui casi concreti. Ma cambia la natura del controllo: da ricostruzione a riscontro.
"Abbiamo una rete di collaboratori esterni. Come gestiamo cosa vedono?"
È una delle esigenze più frequenti e una di quelle che nei sistemi tradizionali produce più lavoro, perché la separazione degli accessi finisce per essere implementata in ogni schermata, in ogni report e in ogni interfaccia — con il rischio che da qualche parte ci si dimentichi.
Nel modello dichiarativo la regola si scrive una volta sola e a livello di dato: un collaboratore vede le pratiche di cui è intestatario, con determinati campi visibili e altri no; un responsabile di area vede quelle della propria rete; una funzione di controllo vede tutto ma non può modificare. La stessa regola vale nelle schermate, nei portali e nei flussi automatici, perché è il sistema a farla rispettare in un punto solo invece che ogni applicazione a ricordarsene.
Il beneficio pratico è che dare accesso a un nuovo canale — un portale per la rete, uno scambio dati con un mandante — smette di essere un progetto di sicurezza a sé stante e diventa una dichiarazione di quali dati quel canale può vedere.
"Dove ha senso l'AI in una pratica, e dove diventa un rischio inaccettabile?"
Diventa un rischio inaccettabile nel momento esatto in cui la si mette a decidere. Una valutazione di merito su una pratica non può dipendere da un modello probabilistico, sia per ragioni regolamentari sia perché non sareste in grado di spiegarla.
Ha invece un valore concreto in tre punti. La lettura dei documenti in ingresso: buste paga, visure, documenti di identità, polizze e perizie che arrivano come scansioni vengono letti e i loro dati proposti già compilati, con verifica umana. È la voce di costo più pesante in un back office e la più noiosa per chi ci lavora. Il controllo di completezza e coerenza: segnalare che una data non torna o che un allegato non corrisponde al tipo dichiarato, come segnalazione da verificare e non come esito. La ricerca nei precedenti: trovare come sono state trattate fattispecie analoghe, con una domanda in linguaggio naturale.
La garanzia strutturale, in un settore dove questa domanda è la prima che fa un revisore: l'agente non ha accesso libero. Ogni azione passa da un piano verificato contro i permessi reali di chi l'ha richiesta, le azioni sensibili richiedono conferma umana esplicita e ogni passaggio resta tracciato. Un agente non approva, non respinge, non deroga e non comunica con il cliente: prepara materiale istruito per chi ha il potere di decidere.
verifica rapida
È il caso vostro?
Probabilmente sì
Le vostre regole di lavorazione cambiano più velocemente di quanto il software riesca a seguirle.
Ricostruire perché una pratica è stata decisa così richiede più di qualche minuto.
I controlli di completezza dipendono dalla diligenza degli operatori.
Avete una rete esterna e la gestione di chi vede cosa è complessa e fragile.
Le deroghe si concedono ma non si misurano.
Gestite volumi documentali alti con molta ribattitura manuale.
Probabilmente no
Vi serve un sistema di contabilità o di rendicontazione provvigionale e nient'altro.
Il vostro applicativo verticale copre già bene istruttoria, controlli e tracciabilità.
Cercate un modello di scoring o uno strumento di valutazione automatica del rischio.
Non è possibile dedicare tempo a mettere per iscritto le regole di lavorazione.
domande frequenti
Servizi finanziari: le domande specifiche.
Pwas garantisce la conformità normativa della nostra attività?
No, e diffidate di chi lo afferma. Pwas fornisce gli strumenti strutturali che una conformità verificabile richiede — regole esplicite e versionate, controlli applicati dal sistema, tracciabilità completa, poteri di deroga dichiarati — ma la valutazione di conformità ai requisiti regolamentari applicabili alla vostra attività compete a voi e ai vostri consulenti. Quello che possiamo fare è rendere quella valutazione molto più semplice da istruire e da documentare.
Come gestite il versionamento delle regole nel tempo?
Le regole hanno una decorrenza dichiarata e la lavorazione di una pratica resta associata ai criteri vigenti quando è stata svolta. Questo significa che modificare una soglia oggi non altera la leggibilità delle decisioni prese ieri: un controllo che riapra un fascicolo del passato vede i valori di allora, non quelli attuali. È una proprietà che va progettata insieme all'inizio, perché dipende da come volete trattare le pratiche in corso al momento di un cambio.
Si integra con i portali dei mandanti e delle compagnie?
Quando i portali espongono interfacce di scambio dati, sì: ciascuno viene dichiarato come risorsa esterna con le proprie chiamate e i propri campi. Dove lo scambio avviene ancora via file o via portale web senza interfacce, si lavora con scambio di file strutturati o con lettura automatica dei documenti prodotti. La fattibilità si verifica caso per caso, perché dipende da cosa la controparte mette a disposizione.
I nostri dati escono dall'Europa?
No, se non lo decidete voi. Il sistema gira su cloud europeo, nella vostra infrastruttura o in configurazione mista, come modalità di distribuzione. Quando il progetto prevede l'uso di modelli linguistici, la scelta del fornitore e della sua collocazione è parte del progetto e viene decisa con voi, incluse le opzioni che mantengono l'elaborazione entro perimetri definiti.
Quanto tempo serve per la prima linea di prodotto in lavorazione?
Per un tipo di pratica ben delimitato l'ordine di grandezza è di alcune settimane dalla formalizzazione condivisa delle regole. Le linee successive richiedono meno, perché ripetono uno schema già validato e cambiano solo nei controlli e nelle soglie specifiche.
Chi mantiene le regole dopo la messa in esercizio?
L'obiettivo esplicito del progetto è che l'aggiornamento di soglie, controlli e checklist sia alla portata della vostra funzione di conformità o del back office, senza competenze di programmazione, perché la configurazione è un documento strutturato leggibile. Per estensioni più profonde — una nuova integrazione, un nuovo tipo di flusso — serve un profilo tecnico, vostro, di un partner o nostro.
Utilizziamo cookie tecnici e, previo consenso, cookie analitici (Google Analytics) per capire come viene usato il sito. Leggi la Privacy & Cookie Policy.