Come uso gli LLM nel lavoro di compliance PM

Ho lavorato nelle policy sui contenuti e nella conformità normativa abbastanza a lungo da essere scettico verso le affermazioni del tipo "l'IA automatizzerà X". Quello che ho scoperto è più specifico: ci sono attività particolari nel lavoro di compliance PM in cui gli LLM comprimono i tempi in modo significativo, e attività particolari in cui non aiutano e non ci si dovrebbe fidare. La distinzione conta.

Estrazione dei requisiti

Il caso d'uso più affidabile è l'analisi del testo normativo. Quando esce una nuova legge o una nuova linea guida regolatoria, il primo compito del PM è capire che cosa richiede davvero, nello specifico, quali dati devono essere catturati, quali categorie devono essere mantenute e in quale formato deve essere prodotto l'output.

Il procedimento: incollare il testo integrale della legge o del documento di indirizzo nel modello e chiedergli di enumerare ogni elemento di dato rendicontabile. Per ciascun elemento, chiedere se la descrizione corrisponde a qualcosa che l'infrastruttura dati attuale già produce. Poi confrontare quell'output con ciò che i sistemi di dati della piattaforma effettivamente generano, insieme a un esperto di dominio che sa cosa producono quei sistemi.

Funziona bene perché il testo normativo è preciso e non richiede un giudizio contestuale profondo per essere analizzato. Il modello sta svolgendo un'estrazione strutturata di informazioni, tira fuori elenchi di requisiti e li organizza, cosa che fa in modo affidabile. Dove si sgretola è nell'interpretare definizioni ambigue, che richiedono ancora un giudizio legale. Il modello ti darà una risposta sicura su cosa significhi un requisito ambiguo; quella risposta può riflettere o meno il modo in cui il regolatore leggerà lo stesso testo.

Il vero valore emerge quando una nuova legge si sovrappone a una esistente. Quando è uscita la California AB 587, stavamo già rendicontando ai sensi dell'articolo 15 dell'EU DSA. I quadri di categorie si sovrappongono parzialmente ma non corrispondono in modo netto, la "disinformazione o cattiva informazione" dell'AB 587 non ha un equivalente diretto nel DSA, e il meccanismo di segnalazione dell'articolo 16 del DSA non ha un analogo californiano. Applicare questo processo di estrazione a entrambi i testi normativi e poi eseguire un confronto strutturato con l'infrastruttura dati esistente ha individuato le lacune con precisione: quali dati avevamo già, cosa andava aggiunto e cosa richiedeva decisioni di definizione prima ancora di poter avviare il lavoro sui dati.

Analisi delle lacune tra giurisdizioni

Un caso d'uso correlato è mantenere una tabella dei requisiti tra giurisdizioni man mano che gli indirizzi regolatori evolvono. La Commissione DSA ha pubblicato un modello di rendicontazione armonizzato nel 2024; quando ha aggiornato i requisiti di precisione e richiamo per gli strumenti di rilevamento automatizzato nella versione H2 2025, avevo bisogno di capire nello specifico cosa fosse cambiato rispetto al modello H1 e se ciò incidesse su qualcosa che stavamo già producendo.

Il flusso di lavoro: mantenere una tabella strutturata dei requisiti per giurisdizione, DSA articolo 15, DSA articolo 42, AB 587, S895 e così via, con colonne per i dati specifici richiesti e lo stato attuale dell'infrastruttura. Quando viene pubblicato un nuovo indirizzo, si confronta il nuovo testo con la tabella esistente per segnalare cosa è cambiato. Il modello esegue il confronto; il giudizio del PM sta nel valutare se le modifiche segnalate richiedano lavoro di ingegneria, decisioni di definizione o niente.

È più rapido che leggere un intero documento di indirizzo aggiornato a memoria della versione precedente, e più affidabile, il modello coglie cose facili da perdere in un testo normativo denso, in particolare cambiamenti nella metodologia di misurazione o nella cadenza di rendicontazione sepolti in una nota a piè di pagina.

Revisione della bozza rispetto a una checklist normativa

Prima che qualsiasi report normativo passi al Legal per la revisione, confronto una bozza quasi definitiva con la checklist normativa pertinente. Il prompt è semplice: ecco la bozza del report, ecco la legge pertinente, individua tutto ciò che nella legge non è affrontato nel report e segnala tutto ciò che nel report sembra in conflitto con i requisiti della legge.

Questo coglie omissioni facili da perdere in documenti lunghi, una comunicazione richiesta da un comma che è saltata in un ciclo di revisione, o una categoria presente nella legge ma inavvertitamente accorpata a un'altra nel report. Sono il tipo di errori che emergono nella revisione del Legal e richiedono una revisione completa, il che costa tempo quando si è vicini a una scadenza di deposito.

Non sostituisce la revisione del Legal. Il modello perderà interpretazioni dipendenti dal contesto e non coglierà problemi di accuratezza sostanziale, non può dirti che il numero di ricorsi rendicontato è sbagliato, solo che il report include una sezione sui ricorsi. Ma è un utile controllo preliminare che riduce la probabilità che la revisione del Legal faccia emergere omissioni strutturali anziché questioni sostanziali.

Cosa non funziona

Tutto ciò che richiede un giudizio sull'intento regolatorio, cosa un regolatore è effettivamente probabile che faccia applicare, se una determinata comunicazione soddisfi un requisito il cui testo è ambiguo, non funziona bene. Il modello genererà una risposta dall'aria sicura. Quella risposta può riflettere o meno il modo in cui il regolatore legge lo stesso testo, e nel lavoro di compliance la differenza conta.

Allo stesso modo, tutto ciò che richiede la conoscenza di una specifica storia applicativa, di recenti indirizzi della Commissione o di attività normativa in corso successiva alla data di taglio dell'addestramento è inaffidabile. Il modello non sa ciò che non sa, e la conformità normativa è un ambito in cui agire su informazioni obsolete crea un rischio reale.

Lo schema che ha funzionato: usare gli LLM per attività di testo strutturate, estrazione, confronto, revisione con checklist, in cui gli input e gli output sono ben definiti e un esperto di dominio può verificare l'output. Non usarli per rispondere a domande su cosa significhi un requisito in un contesto applicativo o su come un regolatore risponderà a un determinato approccio di comunicazione. Queste richiedono una competenza che il modello non possiede e non è in grado di simulare in modo affidabile.