Ho una richiesta art. 22 GDPR da un cliente. Mi serve la lista delle decisioni automatizzate sul suo profilo, ultimi 90 giorni.
AGENTE · POLICY MAPPER
Ogni decisione automatica si collega all'articolo normativo specifico.
Policy Mapper lavora sopra il registro audit del runtime. Per ciascuna decisione automatica, associa il riferimento all'articolo specifico del regolamento applicabile (AI Act, GDPR, DORA, IDD, MDR, regolamenti settoriali). L'audit regolatorio passa da query SQL generica a evidenza tracciata articolo per articolo.
Policy Mapper al lavoro.
17 decisioni trovate. 12 Lead Scoring (AI Act Allegato III 5b + GDPR art. 22), 4 Compliance Scan (GDPR art. 5 + AI Act art. 13), 1 Wealth Copilot (MiFID II art. 25 + GDPR art. 22).
Esporto la lista strutturata in CSV per la risposta al cliente?
Sì, esporta. Rispondo entro 24h. Grazie.
Perché esiste.
Audit Recorder registra ogni decisione automatica del runtime in registro immutabile. Policy Mapper aggiunge il livello di mapping regolatorio: per ciascuna decisione, identifica l'articolo del regolamento applicabile — GDPR art. 22 per decisioni automatizzate su persone fisiche, AI Act Allegato III per sistemi ad alto rischio, DORA per incidenti operativi significativi, IDD per proposte assicurative, MDR per software medico.
Come annota il registro per articolo.
Il mapping cambia il modo in cui il compliance officer e il regolatore leggono il registro. Una query SQL può estrarre 'tutte le decisioni che coinvolgono GDPR art. 22 negli ultimi 90 giorni' invece di 'tutte le decisioni del runtime senza categorizzazione regolatoria'. L'audit si chiude in ore, non in settimane.
La completezza del mapping resta del team compliance.
Policy Mapper non interpreta autonomamente nuove circolari normative. Le regole di mapping sono dichiarative, scritte e mantenute aggiornate dal team compliance del cliente.
DPO, compliance officer, responsabile risk.
DPO
Ottiene un registro audit annotato regolatoriamente. Le query per audit GDPR art. 22 (diritto alla spiegazione delle decisioni automatizzate), per richieste di accesso dati e per audit del Garante Privacy diventano dirette, senza interpretazione manuale del log di runtime.
fnol.receive 09:14:22 ALLOW
triage.classify 09:14:25 ALLOW
idd.check 09:14:31 WARN
liquidation.propose 09:15:02 ALLOW
SELECT * FROM audit_log WHERE claim_id = '2024-0847'
Compliance officer di settore
IVASS, Banca d'Italia, AGENAS, per aziende nei rispettivi perimetri: ha l'evidenza strutturata articolo per articolo. L'audit periodico si chiude in tempi più brevi, con la traccia già organizzata per regolamento.
Proposta n. 2024-081 In revisione
Disclosure mancante
art. 21 TUF · strumento finanziario regolato
Alt. 1 …nel rispetto dell'art. 21 TUF e delle disposizioni Consob vigenti.
Alt. 2 …con disclosure completa allegata al documento di offerta.
Traccia audit registrata · 14:31
Responsabile risk
Vede l'esposizione regolatoria del runtime aggregata per articolo normativo. L'analisi del rischio operativo è basata su dati strutturati, non su ricostruzioni retrospettive.
Pratica KYC-2024-091 In verifica
Documento ID VERIFICATO
Biometria · SCA PSD2 LINKING OK
Beneficial owner REGISTRO IMPRESE
Pratica passata a AML Screening
Una richiesta art. 22 GDPR da un cliente. Il DPO risponde in 24 ore.
Un cliente esercita il diritto art. 22 GDPR.
Una banca ha diversi agenti Polyant in produzione. Un cliente esercita il diritto di accesso ai dati ai sensi dell'art. 22 GDPR: vuole sapere quali decisioni automatizzate sono state prese sul suo profilo.
Diciassette decisioni in novanta giorni, mappate per articolo.
Il DPO apre il client SQL, esegue la query sul registro audit filtrata per cliente e per campo regulatoryReference contenente 'GDPR art. 22'. L'output strutturato include diciassette decisioni: dodici Lead Scoring con reason code complete, quattro Compliance Scan su contratti commerciali, una Wealth Copilot con suggerimenti di portfolio.
Il DPO risponde al cliente in ventiquattro ore.
Il DPO costruisce la risposta al cliente con il dettaglio strutturato in ventiquattro ore. Senza Policy Mapper, la stessa operazione avrebbe richiesto settimane di ricostruzione manuale attraverso log non annotati.
Configurazione e risorse tecniche.
Le regole sono dichiarative. Il team compliance, DPO e risk del cliente definiscono in formato leggibile le regole di mapping: per ogni tipo di decisione del runtime e per ogni tipo di gate attivato, l'articolo normativo applicabile. Le regole vivono nel repository del cliente, versionate.
La completezza del mapping rispetto al panorama normativo del settore è responsabilità del team compliance del cliente. Quando un regolatore pubblica nuove linee guida (nuove circolari AI Act, aggiornamenti DORA, recepimento nazionale di direttive EU), il team compliance aggiorna le regole. L'agente esegue il mapping configurato; non interpreta autonomamente i nuovi testi normativi.
- Linguaggio
- TypeScript (Node.js)
- Modello LLM
- a scelta del cliente: Anthropic, OpenAI, Mistral, modelli open source ospitati internamente, AWS Bedrock per modello privato
- Controlli built-in usati
- pii-detector, credential-detector
- Integrazione
- nativa col registro audit del runtime Polyant (non richiede adapter esterni)
- Regole di mapping
- dichiarative, versionate, scritte dal team compliance + DPO + risk
- Nota correttezza
- la completezza del mapping rispetto al panorama normativo aggiornato è responsabilità del team compliance del cliente; l'agente esegue le regole configurate
- Memoria
- persistente per istanza, pgvector + PostgreSQL FTS sui riferimenti normativi
- Registro
- aggiornamento immutabile del campo `regulatoryReference` su `governance_events`; interrogabile con client SQL standard
Domande frequenti sull'agente.
Quando un regolatore pubblica un aggiornamento (nuove linee guida AI Act, recepimento NIS2 italiano via D.Lgs. 138/2024, circolari Banca d'Italia), il team compliance aggiorna le regole di mapping nel repository. L'agente applica le regole aggiornate sulle decisioni successive. Le decisioni precedenti mantengono il mapping originario (immutabilità del registro).
Sì. Policy Mapper è integrato nativamente con il registro audit del runtime. Ogni agente Polyant scrive nel registro; Policy Mapper annota il campo regulatoryReference per ciascun evento, indipendentemente dall'agente che ha generato la decisione. Non richiede configurazione per-agente.
No. Le regole di mapping sono scritte e mantenute dal team compliance del cliente. L'agente esegue le regole configurate; non ha la capacità di leggere autonomamente nuovi testi normativi e aggiornarsi. Il team compliance è responsabile di tenere aggiornato il repository di regole man mano che il panorama normativo evolve.
Il pattern tipico è 8-14 settimane. Discovery e mappa del perimetro normativo del cliente 2 settimane, scrittura delle regole di mapping con compliance, DPO e risk 4-7 settimane, integrazione col registro audit 1-2 settimane, hand-off 1-3 settimane. Il fattore principale è la profondità e la complessità del perimetro normativo del cliente.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come Policy Mapper si configurerebbe sul caso del cliente. Quale perimetro normativo, quali tipi di decisione automatica nel runtime, quali regolatori rilevanti.