Gli skills di Claude rappresentano la componente operativa di una trasformazione. Non sono semplici prompt elaborati: sono pacchetti di conoscenza specializzata — con scope definito, trigger precisi, competenze incorporate e workflow deterministici — che consentono di affiancare agli esseri umani agenti specializzati in grado di svolgere compiti cognitivi complessi in modo esplicito, versionato e auditabile.
Il concetto di architettura semantica d’impresa e il ruolo che le architetture agentiche possono svolgere nel ridefinirla, affida esclusivamente alle risorse umane il compito di interpretare, negoziare e sintetizzare significato: un asset prezioso ma, per sua natura, non esplicitabile e non scalabile.
La differenza con l’automazione tradizionale è sostanziale. Un ETL o uno script RPA implementano una sequenza rigida di operazioni su dati strutturati. Uno skill comprende semanticamente ciò che sta facendo: può leggere un documento normativo in linguaggio naturale, inferirne il significato regolamentare, confrontarlo con la configurazione esistente dei sistemi e proporre modifiche coerenti — chiedendo conferma quando incerto. Come nel caso che segue.
Ecco come questo cambiamento si realizzi in pratica, attraverso un caso che tocca simultaneamente dimensioni normative, legali, organizzative e tecniche: l‘implementazione di un nuovo controllo antiriciclaggio (AML) in una banca.
Mettendo a confronto i due paradigmi si apprezzano alcune differenze strutturali tra l’architettura semantica tradizionale e quella ibrida basata su skills agentici.
Tabella 1 — Confronto tra architetture
| Dimensione | Architettura tradizionale | Architettura ibrida (Skills + Cowork) |
| Motore semantico | Esclusivamente risorse umane | Risorse umane + agenti specializzati |
| Deposito della conoscenza | Teste delle persone, stored procedure, macro Excel, documentazione disallineata | Skill espliciti, versionati, auditabili, non degradabili |
| Traduzione policy → sistema | Manuale: analista legge, interpreta, configura l’engine (giorni/settimane) | Policy Reader agent: estrae regola, formalizza, propone modifica con audit trail |
| Integrazione cross-funzionale | Riunioni, email, escalation manuali tra Legal, IT, Compliance, Ops | Swarm di agenti specializzati che collaborano in parallelo, coordinati da Cowork |
| Trasmissione conoscenza | Rischio di perdita alla rotazione del personale; conoscenza tacita non trasferibile | Skill permanente: la conoscenza non parte con il senior analyst |
| Latenza decisionale | Ore/giorni per propagare una modifica normativa ai sistemi operativi | Minuti: dall’aggiornamento normativo alla configurazione proposta e validata |
| Governance | Controlli a consuntivo, spesso manuali; opacità causale nelle catene di trasformazione | Audit trail automatico; Auditor Agent indipendente; confidence score espliciti |
Indice degli argomenti:
Un caso realistico di applicazione
L’antiriciclaggio può essere un banco di prova ideale per l’architettura semantica ibrida. Non perché sia il dominio più tecnico, ma perché è uno dei domini dove la complessità è genuinamente multi-strato. Una nuova disposizione AML della Banca d’Italia o dell’EBA non impatta solo i sistemi IT. Tocca simultaneamente l’interpretazione giuridica, la governance interna, i processi operativi di filiale, i sistemi di monitoraggio delle transazioni, la formazione del personale e le segnalazioni all’UIF.
Proviamo a immaginare uno scenario concreto (puramente esemplificativo): L’EBA pubblica un aggiornamento alle linee guida sui sistemi di transaction monitoring che abbassa la soglia di attenzione rafforzata per i bonifici verso giurisdizioni ad alto rischio da 5.000 a 2.500 euro, con nuovi criteri di profilazione del cliente che richiedono dati aggiuntivi e, a cascata, modifiche contrattuali e dei documenti privacy.
Nell’architettura tradizionale la catena delle latenze è evidente. Questo di seguito potrebbe essere uno sviluppo tipico:
- giorno 1-5: il responsabile compliance riceve la norma, la studia, produce una nota interna.
- giorno 6-15: la nota va al servizio legale per validazione interpretativa.
- giorno 16-25: il legale restituisce commenti, compliance integra.
- giorno 26-40: si apre un tavolo con IT per l’impatto sui sistemi di transaction monitoring. Il vendor viene coinvolto. Si scopre che la soglia è hardcoded in tre punti diversi del sistema, con logiche di aggregazione diverse a seconda del canale (filiale, internet banking, corporate banking).
- giorno 41-70: requirements, sviluppo, test in UAT.
- giorno 71-85: aggiornamento policy, approvazione CdA.
- giorno 86-100: formazione al personale, rilascio in produzione.
Il coordinamento? Via email — con tutto ciò che questo implica in termini di tracciabilità, versioning e latenza.
La norma entra in vigore al giorno 60. La banca è a metà percorso. Oppure, si rientra nei tempi saltando a piè pari alcuni passaggi.
Questo non è malfunzionamento. È l’unica modalità di lavoro possibile con l’architettura semantica tradizionale.
Il risultato è che, quando la norma entra in vigore, la banca è spesso ancora in fase di implementazione, esponendosi a rischi regolamentari non tanto per negligenza, quanto per frizione strutturale tra strati organizzativi e informativi che non comunicano — né potrebbero farlo — in tempo reale.
Cosa cambierebbe introducendo un’architettura agentica?
Con un’architettura basata su skills[2] di Claude e Cowork, questo processo cambia natura: la conoscenza smette di essere sequenziale e diventa distribuita, parallela e in grado di essere applicata senza latenza.
Quando viene pubblicata una nuova circolare AML, uno swarm di agenti specializzati — ognuno dotato del proprio skill — può lavorare contemporaneamente sulla stessa norma con ottiche diverse, coordinandosi attraverso Cowork.
Tabella 2 — Gli agenti dello swarm AML (ipotesi realistica)
| Agente | Skill principale | Input | Output |
| Regulatory Reader | Lettura e interpretazione normativa (EBA, Banca d’Italia, FATF) | Testo normativo aggiornato | Obblighi strutturati in formato eseguibile |
| Legal & Compliance Analyst | Gap analysis tra norma e policy interna; valutazione rischio sanzionatorio | Output Regulatory Reader + policy vigenti | Gap report, priorità di intervento, rischio residuo stimato |
| Policy / Contract Drafter | Redazione bozze di policy e contratti in linguaggio compliant al dettato regolamentare | Gap report + policy precedenti come template + schemi contrattuali esistenti | Bozza aggiornata con sezioni modificate evidenziate di policy e contratti |
| IT & Data Architect | Traduzione requisiti normativi in specifiche tecniche; analisi impatto su sistemi legacy | Obblighi strutturati + mappa dei sistemi esistenti | Specifiche di implementazione, stima effort, piano di migrazione |
| Training Content Designer | Produzione materiale formativo per il personale di rete e back office | Policy aggiornata + profili dei destinatari | Moduli formativi differenziati per ruolo, quiz di verifica |
| Auditor Agent | Verifica coerenza end-to-end: norma → policy → configurazione sistema → audit trail | Output di tutti gli agenti precedenti | Relazione di conformità, finding, raccomandazioni |
| Nota: L’Auditor Agent opera in fase successiva rispetto agli agenti operativi e con perimetro distinto: ha accesso read-only agli output di tutti gli altri agenti e non partecipa ai processi produttivi. La sua indipendenza è una scelta architetturale deliberata, non un limite funzionale. | |||
Ogni agente porta una competenza che, nell’architettura tradizionale, era distribuita in teste diverse, non comunicanti in tempo reale e, a volte, comunicanti con frizioni e difficoltà. Il Regulatory reader non aspetta che il Legal & Compliance Analyst abbia finito per iniziare a lavorare. L’IT & Data architect non aspetta la policy definitiva per avviare l’analisi d’impatto sui sistemi. Lavorano in parallelo, condividono output intermedi, si mettono in standby se attendono un risultato. Pur avendo obiettivi e paletti propri, convergono su una proposta coerente.
Il Regulatory reader estrae dall’aggiornamento EBA le modifiche operative: nuova soglia 2.500 euro, nuovi criteri di profilazione (tipologia cliente, paese di destinazione, frequenza storica), obblighi di documentazione rafforzata. Struttura il tutto in formato eseguibile.
Contemporaneamente, il Legal & compliance analyst confronta i nuovi obblighi con le policy interne vigenti e identifica tre gap: la soglia nei sistemi, i criteri di profilazione cliente nel CRM, e una lacuna nella procedura di archiviazione documentale. Stima il rischio sanzionatorio per ciascun gap in funzione della scadenza normativa. Identifica che vi sono tre moduli contrattuali impattati.
L’IT & data architect analizza la mappa dei sistemi esistenti e individua i tre punti di hardcoding della soglia precedente. Produce specifiche tecniche per la modifica, stima l’effort (4 giorni di sviluppo, 3 giorni test), segnala che il modulo corporate banking richiede attenzione separata perché gestito da un vendor terzo.
Il Policy / contract drafter produce una bozza aggiornata della policy AML con le sezioni modificate evidenziate, pronta per la review del CdA. Produce inoltre le bozze dei contratti modificati.
Il Training content designer genera tre moduli formativi differenziati: uno per il personale di filiale (focalizzato sui comportamenti operativi), uno per il back office (procedure di documentazione), uno per i responsabili di relazione (profilazione cliente).
Tutto questo in parallelo. Al termine del primo ciclo — ore, non settimane — il responsabile della Compliance riceve un pacchetto completo: gap analysis con priorità, bozza di policy e contratti, specifiche tecniche con stima effort, piano formativo. Il suo lavoro è di revisione e decisione, non di coordinamento e raccolta.
L’Auditor agent — operando in fase successiva con accesso read-only agli output di tutti gli altri agenti — verifica la coerenza end-to-end: che le specifiche tecniche coprano tutti i gap identificati dall’analisi di compliance, che la policy aggiornata recepisca correttamente tutti gli obblighi normativi, che il materiale formativo sia coerente con la policy. Produce un report di conformità con i finding aperti, esattamente come un auditor indipendente.
Come funziona in pratica
Per capire come in meno di un’ora di lavoro questa architettura possa arrivare al risultato, è necessario vedere fisicamente come funziona.
Finora abbiamo parlato degli agenti come se fossero unità funzionali con un nome e uno scopo. Ma cosa c’è concretamente dentro uno skill? Prendiamo ad esempio il Policy / contract drafter.
Uno skill non è un prompt. È una cartella strutturata che contiene istruzioni operative, materiali di riferimento, template e casi d’uso validati. È, letteralmente, il manuale professionale di un collega specializzato — reso azionabile da un agente AI. Vediamo come questi componenti vengono attivati in sequenza su un caso concreto.
La cartella dello skill Policy Drafter contiene tipicamente i seguenti file[3]:
Tabella 3 — Cosa c’è dentro lo skill
| File | Tipo | Cosa contiene e a cosa serve |
| SKILL.md | Istruzioni operative | Definisce la mission dell’agente, quando attivarsi, come strutturare il lavoro, quali errori evitare. È il documento che l’agente legge prima di fare qualsiasi cosa, come un briefing all’inizio di ogni incarico. |
| policy_structure_guide.md | Guida alla struttura | Descrive l’architettura standard di una policy bancaria: sezioni obbligatorie (scopo, ambito di applicazione, definizioni, responsabilità, disposizioni operative, regime sanzionatorio, allegati), ordine logico, livello di dettaglio atteso per ciascuna sezione. |
| regulatory_language_patterns.md | Dizionario linguistico | Raccolta di formule linguistiche regolamentari: come si scrive un obbligo vincolante o una raccomandazione, come si definisce una soglia con le giuste clausole di eccezione, come si cita una normativa di riferimento in modo formalmente corretto per un contesto italiano/europeo. |
| aml_policy_template.docx | Template operativo | Il documento base da usare come riferimento per struttura e contenuti. Contiene le sezioni standard già formattate, le intestazioni istituzionali, i riferimenti normativi fissi (D.Lgs. 231/2007, IV e V Direttiva AML, circolari Banca d’Italia). L’agente lo usa come scheletro e lo popola con il contenuto specifico. |
| examples/policy_soglie_2022.docx | Esempio validato | Una policy reale prodotta e approvata in una iterazione precedente. L’agente la consulta per calibrare il livello di dettaglio, lo stile espositivo e la gestione dei casi limite. È la memoria storica: evita di reinventare soluzioni già testate. |
| examples/diff_aggiornamento_2023.md | Esempio di aggiornamento | Mostra come è stato gestito un aggiornamento normativo precedente: quali sezioni sono cambiate, come sono state segnalate le modifiche rispetto alla versione precedente, come è stato strutturato il documento di accompagnamento per il CdA. |
| validation_checklist.md | Lista di controllo | Prima di consegnare una bozza, l’agente esegue questa checklist: tutti i riferimenti normativi sono aggiornati? Le soglie citate corrispondono a quelle nel sistema? Le responsabilità sono attribuite a ruoli esistenti nell’organigramma? La sezione sanzionatoria è coerente con il regime disciplinare interno? |
| escalation_rules.md | Regole di escalation | Definisce quando l’agente deve fermarsi e chiedere. Se la norma è ambigua su un punto che impatta responsabilità personali, l’agente non interpreta autonomamente: segnala il punto aperto, propone due o tre letture possibili, e rimanda la decisione al Compliance Officer. |
Ecco cosa potrebbe realisticamente produrre il Policy / contract drafter nel caso AML descritto in precedenza: la modifica della soglia di monitoraggio da 5.000 a 2.500 euro e l’introduzione di un nuovo criterio di profilatura.
L’agente riceve in input l’output strutturato del Regulatory reader (gli obblighi formalizzati) e la policy AML vigente. Legge prima SKILL.md per orientarsi, poi consulta il template e la documentazione di riferimento indicata.
Quindi produce un documento come questo:
output_PDR-2026-0214-003_delta_report.md
| # OUTPUT AGENTE — Policy/Contract Drafter ## Delta Report: Aggiornamento Policy AML ### POL-AML-001 v3.1 → v3.2 — Task ID: PDR-2026-0214-003 Data/ora avvio: 14/02/2026 09:47:23 Data/ora completamento: 14/02/2026 10:29:11 Durata task: 41 minuti 48 secondi Agente: Policy/Contract Drafter v2.1 Operatore richiedente: Ufficio Compliance — M. Ferretti — OUTPUT REF. AML-2025-03 Sezioni modificate rispetto alla versione vigente (v4.2, approvata CdA 14/03/2024): § 3.1 — Soglie di monitoraggio rafforzato [MODIFICATA] Precedente: operazioni verso giurisdizioni ad alto rischio ≥ €5.000. Aggiornata: soglia abbassata a €2.500, in recepimento Linee guida EBA/GL/2024/09. [*] NOTA: la modifica impatta i parametri di configurazione del sistema di TM (cfr. specifiche IT allegate). Raccomando coordinamento con IT prima dell’approvazione formale. § 5.3 — Criteri di profilazione cliente [MODIFICATA] Aggiunta la categoria ‘cliente con storico di operatività frammentata verso area MENA’. Definizione mutuata dal glossario FATF 2024. Verificare che il CRM supporti il nuovo attributo di profilazione. § 7.1 — Documentazione rafforzata [NUOVA] Introdotto obbligo di acquisizione documentale entro 5 giorni lavorativi per operazioni superiori alla soglia. Template allegato (Allegato C). PUNTI APERTI — decisione richiesta al CCO: • Il § 3.1 aggiornato si applica anche ai conti di corrispondenza esteri? • La norma EBA è ambigua su questo punto. Propongo due letture: [A] inclusione totale (approccio conservativo); [B] esclusione con documentazione rafforzata in alternativa. Indicare preferenza. PROSSIMI PASSI: approvazione CCO sulla scelta al punto aperto → revisione Servizio Legale → inserimento in ordine del giorno CdA. |
[*] I riferimenti normativi nell’esempio (EBA/GL/2024/09 ecc.) sono utilizzati a scopo illustrativo.[4]
Tre elementi di questo output meritano attenzione:
- L’agente segnala esplicitamente le dipendenze operative: la modifica della policy deve essere coordinata con IT prima dell’approvazione, non dopo.
- Individua autonomamente un punto ambiguo nella norma e non lo risolve da solo, ma propone opzioni e rimanda la decisione all’umano competente.
- Produce già la sequenza di prossimi passi, riducendo il coordinamento manuale a pura esecuzione di un percorso già tracciato.
Questo è il principio degli escalation_rules.md in azione. La scelta di far massimizzare l’utilità per chi decide, anziché l’autonomia dell’agente, è essa stessa una decisione architetturale — non un limite, ma un principio.
Si potrebbe obiettare che, in fondo, anche un buon template Word con logica condizionale fa cose simili. Template “intelligenti” nel senso del marketing software esistono da anni — campi dinamici, auto-completamento, regole if-then. Qual è la differenza?
La differenza sta in dove risiede l’intelligenza. In un template sofisticato, l’intelligenza è hardcoded da chi lo ha costruito: il template sa rispondere solo alle situazioni che il suo autore aveva previsto. Se arriva una norma con una fattispecie mai vista, il template non sa cosa farne. Se un punto è ambiguo, lo compila comunque — senza segnalarlo.
Nello skill, l’intelligenza non è nel file: è nel LLM che lo legge. Lo skill fornisce il contesto di dominio — cos’è una policy AML, come si struttura, quali sono i pattern linguistici regolamentari corretti, quando fermarsi e chiedere. L’LLM porta la capacità di ragionamento: leggere una norma mai vista e capire cosa cambia, accorgersi che un passaggio è ambiguo e formulare interpretazioni alternative, coordinarsi con l’output di un agente che stava lavorando in parallelo sullo stesso problema.
Separati, né l’uno né l’altro bastano. Lo skill senza LLM è un documento. L’LLM senza skill è un modello generalista che non conosce le convenzioni del dominio, la storia delle decisioni precedenti, le regole di escalation specifiche di quell’organizzazione. La combinazione produce un agente che ragiona nel dominio — ed è questo il salto che nessun template, per quanto sofisticato, può compiere.
Questa architettura non riduce il ruolo umano. Lo ridefinisce, azzerando le latenze. Le decisioni che richiedono giudizio, responsabilità legale, conoscenza del contesto istituzionale e relazionale restano — devono restare — prerogativa delle persone.
Tabella 4 — Perimetro delle decisioni umane
| Tipo di decisione | Responsabilità (human in the loop) |
| Interpretazione norma in contesto ambiguo | Chief Compliance Officer |
| Approvazione policy aggiornata | CdA / Organo di Vigilanza |
| Modifica configurazione sistema ICT | CISO + Compliance |
| Formazione e certificazione del personale | Risorse umane + Compliance |
Questo è il principio architetturale fondamentale: determinismo dove serve, intelligenza dove serve, giudizio umano dove è necessario.[5]
In un’architettura tradizionale, la conoscenza su “come si implementa una modifica AML in questa banca specifica” vive nelle teste delle persone. Il responsabile Compliance che conosce la storia dei sistemi, il senior developer che sa dove sono i punti di hardcoding, il formatore che conosce i bisogni del personale di filiale. Se le persone cambiano, la conoscenza in parte si perde e va ricostruita. C’è un passaggio di consegne, ma il successore spesso impiega tempo prima di raggiungere lo stesso livello di competenza immediatamente applicabile.
Nell’architettura con skills agentici[6], questa conoscenza è lo skill dell’agente: esplicita, versionata, auditabile. Il Regulatory reader ha memoria delle interpretazioni precedenti e delle scelte fatte. L’IT & data architect conosce la mappa dei sistemi e le ragioni delle architetture esistenti. Questa conoscenza non si perde. Non si degrada. E — aspetto cruciale in contesto regolamentare — è verificabile: si può in ogni momento controllare quale versione dello skill era attiva quando una certa decisione è stata presa, e confrontarla con la norma vigente in quel momento.
Uno skill, in sostanza, non è un manuale di istruzioni: è la professionalità di un dominio distillata in forma esplicita, versionata e trasferibile. Non descrive soltanto cosa fare — incorpora le competenze necessarie per farlo, i pattern di interpretazione testati, la memoria delle decisioni precedenti. Esattamente ciò che una job description tradizionale descrive ma non incorpora mai davvero.
Note
- Anthropic — Building effective agents (2024). https://www.anthropic.com/research/building-effective-agents. Il documento descrive i pattern architetturali per sistemi multi-agente, incluse le modalità di orchestrazione e coordinamento tra agenti specializzati. ↑
2. Claude Skills+Cowork: verso l’architettura semantica ibrida — AI4Business. https://www.ai4business.it/intelligenza-artificiale/claude-skillscowork-verso-larchitettura-semantica-ibrida/ ↑
3. Anthropic — The Complete Guide to Building Skills for Claude. https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf ↑
4. Volutamente si omette di descrivere il ruolo dei tools agentici (ad es.: server/tools MCP). Nell’ambito degli skills vengono esplicitati gli strumenti che l’agente ha a disposizione per eseguire attività con effetti reali (es.: chiamate API al sistema informativo aziendale, script sviluppati ad hoc). È però necessario ricordare che gli strumenti operativi — dalla semplice modifica di un file a chiamate API strutturate — sono ciò che consente all’agente di mettere a terra il lavoro in modo effettivo. ↑
5. I riferimenti normativi nell’esempio di output (EBA/GL/2024/09, D.Lgs. 231/2007 ecc.) sono utilizzati a scopo esclusivamente illustrativo. I dati e le sigle normative reali variano in funzione del contesto e dell’aggiornamento regolamentare effettivo. ↑
6. Il principio di human-in-the-loop in contesti regolamentari è esplicitamente richiamato nelle linee guida EBA sull’uso dell’intelligenza artificiale nei servizi finanziari (EBA/REP/2020/01 e successivi aggiornamenti). Cfr. anche la Comunicazione della Commissione Europea sull’AI Act (Regolamento UE 2024/1689), che per i sistemi ad alto rischio in ambito finanziario richiede supervisione umana adeguata. ↑
Partecipa alla community