Agent/ica · Area Clienti · Governance dell'AI

Governare l'AI: dai dati agli agenti.

Tre passaggi per usare l'AI in azienda senza regalare i dati, senza perdere il controllo e costruendo un sistema di cui ti puoi fidare.

01

Data Governance

Dove finiscono davvero i tuoi dati — e come proteggerli.

02

Governance dei sistemi agentici

Quando l'AI non risponde ma agisce: chi la autorizza e la traccia.

03

Dalla teoria alla pratica

Come costruire il tuo primo agente, passo per passo.

Agent/ica· Leonardo Milan · PCC-ICF (Professional Certified Coach – International Coaching Federation) · Business Agility Coach

Sezione 1 · Data Governance

I tuoi dati non sono al sicuro per default.

La vera linea di rischio non passa tra «gratis» e «a pagamento» — passa tra piani Consumer e piani Business.

La regola d'oro della Data Governance AI

Se paghi Pro, compri prestazioni.
Se paghi Business, compri protezione.

01

La scala del rischio: dove sei davvero

Tutti i piani consumer addestrano i modelli sulle tue conversazioni per default. Cambia solo quanto te ne accorgi.

FreeRischio massimo

«Se è gratis, il prodotto sei tu»

Addestramento attivo di default, nessun avviso. Quando un dipendente usa il Free per lavoro, l'azienda regala i propri dati senza saperlo.

Pro · Plus · MaxFalsa sicurezza

«Pago, quindi sono protetto» — falso

Stesse regole del Free, ma con opt-out. Il vero pericolo è la falsa sicurezza: il toggle è una concessione revocabile, non un contratto.

Business · Team · EnterpriseProtetto

Protezione strutturale

DPA (Data Processing Agreement: contratto sul trattamento dei dati). Nessun addestramento. Conservazione max 30 giorni. «Normalmente chiuso» per design.

02

La vera linea di demarcazione

Non «gratis vs a pagamento». Consumer vs Business.

Consumer · Free / Pro / Plus / Max

Compri prestazioni

Toggle revocabile · cronologia indefinita · revisione umana da contractor · ogni utente è un'isola · «normalmente aperto».

vs

Business · Team / Enterprise

Compri protezione

DPA (Data Processing Agreement) bilaterale · max 30 giorni · accesso solo per supporto/legge · admin che impone e revoca · «normalmente chiuso».

03

Opt-out non è un piano Business

Opt-out = l'opzione per dire «non usare le mie conversazioni per addestrare il modello». Cinque differenze tra questa concessione e una protezione contrattuale.

1

Contratto vs Toggle (l'interruttore on/off)

L'opt-out è una concessione revocabile. Il DPA Business (Data Processing Agreement, un contratto sul trattamento dei dati) è un obbligo bilaterale.

2

Conservazione dati

Free: cronologia indefinita. Business: max 30 giorni. Enterprise: + ZDR (Zero Data Retention: nessuna conservazione).

3

Accesso ai dati

Consumer: revisione umana da contractor. Business: solo supporto, abusi, legge.

4

Controllo centralizzato

Free: ogni utente è un'isola. Business: admin impone, monitora, revoca.

5

Default del rischio

Free: «normalmente aperto». Business: «normalmente chiuso» per design.

In una frase

La protezione non deve dipendere dalla memoria del singolo.

Allarme dal 28 settembre 2025

Anche Claude Pro è un piano Consumer.

Dal 28/09/2025 Anthropic addestra i modelli sulle conversazioni consumer per default — piani Free, Pro e Max. Solo Claude for Work (Team/Enterprise) offre protezione contrattuale. Con il consenso, i dati restano in pipeline fino a 5 anni. Lo stesso vale, con regole diverse, per ChatGPT e Gemini consumer.

04

I tre provider, a confronto

La stessa logica vale ovunque: consumer = esposto, business = protetto.

ChatGPT
ConsumerTraining sì · opt-out manuale
Business / Ent.No training · DPA · SOC 2
Revisione umanaSì, contractor → solo abusi
Claude
ConsumerTraining dal 09/2025 · opt-out
for WorkNo training · DPA commerciale
RetentionFino a 5 anni se consenti
Gemini
AdvancedTraining · opt-out = perdi storico
WorkspaceNo training di default · DPA
AdminConsole completa se Workspace

DPA = Data Processing Agreement (contratto sul trattamento dati) · SOC 2 = standard di audit sulla sicurezza dei dati.

06

Dati normalizzati: il tuo RAG aziendale

RAG (Retrieval-Augmented Generation: generazione potenziata dal recupero): l'AI recupera le risposte dalla tua base dati aziendale, ordinata e governata — non «inventa» e non pesca dai dati pubblici.

OggiDati sparsi
Il lavoroNormalizzazione
Il risultatoKnowledge base · RAG
Il valoreRisposte coi tuoi dati

Una verità sola

L'AI risponde dalla tua base dati governata: niente allucinazioni, niente versioni vecchie. Una fonte unica, aggiornabile e verificabile.

I dati restano tuoi

Nel RAG i documenti vengono recuperati al momento della domanda, non assorbiti nell'addestramento. Governance per design: li usi senza regalarli.

Pronti per gli agenti

È il gate «AI-ready» di HALO: senza dati normalizzati non si costruiscono agenti affidabili. È il primo mattone della tua AI agentica.

07

In pratica: il tuo RAG con Claude (Team)

Con Claude for Work (piani Team / Enterprise) il RAG si costruisce coi Progetti — senza addestrare i modelli sui tuoi dati.

1

Crea un Progetto condiviso

Il Progetto Claude è lo spazio del RAG: condiviso col team, con permessi per ruolo e dati non usati per l'addestramento.

2

Carica e ordina la conoscenza

Documenti, procedure, FAQ nella knowledge base del Progetto. Nomi file chiari, versioni aggiornate: è la «normalizzazione» pratica.

3

Scrivi le istruzioni di Progetto

Le project instructions fissano tono, regole e confini: cosa l'AI può usare e come rispondere. È la governance del comportamento.

4

Il team interroga, l'AI cita le fonti

Ogni domanda recupera dai documenti del Progetto: risposte coerenti e tracciabili, uguali per tutto il team.

5

Aggiorna, versiona, controlla

Aggiorni i file, gestisci permessi, verifichi gli accessi. Il RAG resta vivo, governato e tuo.

05

La guida pratica: prima, durante, dopo

Prima

Imposta

  • Piano giusto: Business/Team per i dati aziendali
  • Opt-out su ogni piattaforma + screenshot di prova
  • Policy interna: cosa si può e non si può inserire
  • Account separati: personale ≠ aziendale

Durante

Proteggi

  • Anonimizza: togli nomi, cifre, riferimenti
  • Chat temporanee per le query esplorative
  • Non riaprire vecchie chat sensibili
  • File su Drive, non «digeriti» nella chat AI

Dopo

Verifica

  • Cancella le chat sensibili (le esclude dal training)
  • Audit trimestrale: opt-out attivo? nuovi ToS (Terms of Service: termini di servizio)?
  • Monitora i cambi di policy dei provider
  • Forma il team: governance nei workshop

La via d'uscita · Agent/ica

Costruisci la tua AI agentica.

«AI tua, o AI di altri dentro casa tua.»

Costruirsi la propria AI agentica non è una scelta di innovazione: è una scelta di governance. HALO parte da un gate fondativo — non costruiamo agenti dove mancano dati, governance e processo.

Agent/ica· agentica.wikicoaching.it · Parliamone in discovery call

Sezione 2 · Governance dei sistemi agentici

Da «l'AI ha capito» a «l'AI può procedere solo se è governata».

Quando l'AI non si limita a rispondere ma agisce — legge file, esegue programmi, produce documenti — la domanda da farsi cambia.

Il problema non è che l'AI non capisce

Nei sistemi agentici (un'AI che non solo risponde, ma agisce: legge file, esegue programmi, usa strumenti, scrive documenti) il rischio cambia. Il problema è che l'AI può agire anche quando dovrebbe fermarsi.

La vecchia domanda

«L'AI ha dato una buona risposta?»

Bastava valutare il risultato finale.

La domanda corretta oggi

«Era autorizzata, tracciata e governata mentre produceva quell'output?»

Conta come è stato prodotto, non solo cosa.

Output buono, processo sbagliato

Un agente può produrre un Excel, un PDF o un report impeccabile. Ma se l'ha fatto fuori dalla pipeline autorizzata (il percorso ufficiale e controllato) — senza identità, senza tracciamento, senza registro delle prove — non è «agent-led» (guidato da un sistema di agenti governato). È solo l'output di un assistente.

Sembra a postoOutput materiale
È davvero a postoOutput governato

Skill, Agenti, Subagenti, Swarm: non sono la stessa cosa

La governance inizia quando smettiamo di chiamare «agente» qualsiasi cosa. Quattro oggetti diversi:

01

Skill

Un pacchetto di istruzioni e risorse che orienta il comportamento dell'AI. Dice «come» fare una cosa.

orienta
02

Subagente

Un lavoratore specializzato, con proprio contesto, istruzioni e strumenti. Fa un compito preciso.

esegue un compito
03

Agente

Un esecutore identificabile, con responsabilità e strumenti autorizzati. Si sa chi ha fatto cosa.

è responsabile
04

Swarm

Uno sciame orchestrato di agenti con regole, instradamento, prove e controllo. Il sistema completo.

governa

La trappola del «promptone»

Un grande prompt non è un sistema agentico. Il promptone (un unico, enorme prompt) simula una catena di agenti dentro un solo contesto: sembra ordinato, ma resta un solo esecutore che fa tutto.

Il promptone

Un solo esecutore fa tutto

Legge, decide, scrive, corregge, valida, consegna. Mancano la separazione dei ruoli, le prove indipendenti, la responsabilità tracciabile.

Il sistema governato

Ruoli separati e verificati

Ogni agente ha un compito, le prove sono indipendenti, il controllo è tecnico. Un promptone può produrre. Non può governare.

La regola madre

Senza run_id (il codice univoco che identifica e traccia ogni singola esecuzione), nessun processo ufficiale. In un sistema governato la prova arriva prima dell'azione, non alla fine.

NO VALID RUN_ID

NO CANONICAL PROCESS

NO CANONICAL ARTIFACT

Se manca un run_id valido nel registro delle prove, il sistema non apre il processo, non esegue codice, non genera file.

Il run_id non è una formalità

È la «ricevuta di esistenza» della run (l'esecuzione svolta dall'AI). Senza, non abbiamo una run agentica: abbiamo solo una sessione di chat. Risponde a sei domande essenziali:

?

Chi ha avviato

Chi ha lanciato la richiesta.

?

Quale capability

Quale funzione autorizzata è stata invocata.

?

Quale agente

Quale agente o team ha eseguito.

?

Quali strumenti

Quali tool (strumenti) erano autorizzati.

?

Quali file

Quali documenti sono stati prodotti.

?

Dove sono le prove

In quale registro è tracciato tutto.

Trasparenza non è governance

Dire «non era agent-led» dopo aver prodotto il report non basta.

Trasparenza postuma

Sapere dopo che era sbagliato

«Ho prodotto il report, ma non era governato.» Onesto — ma il danno è già fatto.

Governance

Impedire prima l'azione non autorizzata

Il sistema blocca prima. La governance non è una nota a piè di pagina: è un gate (un cancello che apre solo se le condizioni sono rispettate).

Il principio fail-closed

Fail-closed = in caso di dubbio, il sistema si chiude e si ferma, non procede comunque. Il processo parte solo se ci sono tutte le condizioni minime:

Runtime attivol'ambiente che fa girare gli agenti è acceso
Capability registratala funzione richiesta è prevista e autorizzata
Agente o route autorizzataesiste un percorso permesso per eseguirla
run_id validoil codice di tracciamento è stato creato
Evidence Log scrivibileil registro delle prove è pronto a ricevere
Lineage degli artifactsi può ricostruire la provenienza di ogni file

Skill ≠ enforcement

Una Skill può dire cosa fare. Un hook (gancio tecnico che intercetta un'azione) può impedire cosa non fare. Enforcement = applicazione forzata delle regole.

La Skill orienta

Aiuta l'AI a scegliere il processo giusto. Ma da sola non impedisce il bypass (l'aggiramento).

L'hook blocca

Gancio tecnico sul prompt, sui comandi e prima di usare gli strumenti: ferma ciò che non è autorizzato.

La CI impedisce

CI (controlli automatici prima della pubblicazione): evita che un output non governato diventi ufficiale.

Il caso tipico di fallimento: il bypass

Il pattern pericoloso, passo per passo. L'AI riconosce il processo, ma procede fuori pipeline.

1

La richiesta chiede un processo agentico

E la Skill corretta si attiva.

2

L'AI riconosce il processo

Sa quale percorso ufficiale dovrebbe seguire.

3

Ma non trova run_id o runtime valido

Mancano le condizioni minime per partire.

4

Procede comunque, fuori pipeline

Usa Python, file locali o un percorso alternativo, e produce output simili a quelli ufficiali.

5

Solo alla fine dichiara: «non era agent-led»

Troppo tardi. Questo è il bypass da bloccare prima.

La governance agentica in una frase

Non vogliamo che l'AI capisca meglio. Vogliamo che possa agire solo quando è autorizzata. La maturità si misura dalla capacità del sistema di dire NO.

NOse manca il runtime (l'ambiente attivo che esegue gli agenti)
NOse manca la capability (la funzione autorizzata)
NOse manca il run_id (il codice di tracciamento)
NOse manca l'Evidence Log (il registro delle prove)
NOse l'output sembra ufficiale ma non ha lineage (tracciabilità della provenienza)

HALO: Hub for Agent-Led Operations

Non un agente: un sistema di governo degli agenti, lo strato che sta sopra e decide chi può agire e con quali prove. (Hub for Agent-Led Operations = centro per operazioni guidate da agenti governati.)

01

Gateway

La porta d'ingresso: ogni richiesta passa di qui.

02

Capability Registry

L'elenco delle funzioni ammesse e autorizzate.

03

Orchestratore

Coordina e instrada gli agenti sui processi.

04

Agenti autorizzati

Gli esecutori abilitati, con compiti definiti.

05

Runtime Evidence Log

Il registro delle prove di ogni esecuzione.

06

run_id

Il codice univoco che traccia ogni run.

07

Artifact Lineage

La provenienza tracciabile di ogni file prodotto.

08

Gate di blocco

Il cancello che ferma ciò che non è in regola.

La differenza decisiva

Il passaggio da fiducia a controllo.

Prompt-driven · guidato dal prompt

Fiducia

Scrivi una richiesta → l'AI interpreta → produce → e poi spiega cosa ha fatto.

vs

Evidence-driven · guidato dalle prove

Controllo

Il sistema intercetta → verifica runtime e capability → crea il run_id → registra l'evidenza → solo dopo autorizza l'output.

La nuova regola operativa: prima il gate, poi il lavoro

Ogni richiesta agentica segue una sequenza obbligatoria. Se la catena si rompe, l'output non è ufficiale.

1Intent riconosciuto
2Runtime verificato
3Capability risolta
4run_id creato
5Agente o team autorizzato
6Evidence Log aperto
7Artifact prodotti
8Lineage verificato
9Output consegnato

Cosa deve imparare un'azienda

L'AI agentica non si governa con le buone intenzioni. Servono tre livelli:

Regole

Cosa è ammesso e cosa è vietato. Senza gate, restano promemoria.

Gate

Cosa viene tecnicamente bloccato. Senza prove, sono solo dichiarazioni.

Prove

Cosa dimostra che il processo è avvenuto correttamente. È la base di tutto.

Senza governance, l'AI agentica diventa automazione opaca.

La lezione finale: l'output non basta più

Il rischio si è spostato. È cambiata la domanda da farsi alla fine.

AI generativa

Il rischio era la risposta sbagliata

«Il report è venuto bene?»

AI agentica

Il rischio è il processo non governato

«È stato prodotto da una run autorizzata, tracciata e verificabile?» Solo allora è agent-led.

Il principio HALO · Agent/ica

AI tua, ma solo se governata.

La vera AI agentica non è quella che fa di più. È quella che fa solo ciò che è autorizzata a fare.

Costruire la propria AI agentica significa costruire un sistema che decide chi può agire, quando, con quali strumenti, su quali dati, con quali prove e con quali limiti.

Agent/ica· agentica.wikicoaching.it · Parliamone in discovery call

Sezione 3 · Dalla teoria alla pratica

Come costruire il tuo primo agente, senza sbagliare.

Un sistema agentico non nasce quando «l'AI fa una cosa complessa». Nasce quando un processo diventa una catena controllata: richiesta → processo → Skill → agente → strumenti → prova → output.

La regola madre: l'ordine giusto

Non si parte dicendo «creiamo tanti agenti». Si parte dalla domanda: qual è il processo minimo che vogliamo rendere ripetibile, verificabile e governato?

1Mappa il processo
2Costruisci le Skill
3Costruisci il primo agente
4Solo dopo: lo Swarm

Prima il processo. Poi gli agenti — mai il contrario.

Scegli il primo processo

Piccolo, gestibile da uno o due agenti, con un inizio chiaro, una fine chiara e pochi output.

Buoni per partire

  • Analizzare un CV e produrre una scheda strutturata
  • Estrarre dati da un documento e creare una tabella
  • Controllare la qualità di un report
  • Trasformare un documento grezzo in una bozza ordinata

Da evitare all'inizio

  • Costruire un'intera piattaforma multi-agente
  • Creare subito uno Swarm completo
  • Automatizzare un processo non ancora chiaro
  • Un agente diverso per ogni tipo di output

Mappa il processo, prima degli agenti

Scrivi il processo in linguaggio umano. La parte più importante è definire quando fermarsi: un buon processo agentico non è quello che fa sempre qualcosa, è quello che sa fermarsi quando mancano le condizioni.

L'input

Qual è l'input e chi lo fornisce.

I controlli

Cosa va verificato prima di partire.

I passaggi

Quali sono obbligatori e quali facoltativi.

Gli output

Quali vanno prodotti e quali sono vietati.

Gli stop

Quando il processo deve fermarsi.

La prova

Cosa dimostra che è stato eseguito bene.

Chi fa cosa: Cowork e Claude Code

Cowork (l'ambiente di progettazione) e Claude Code (l'ambiente che scrive il codice) hanno due mestieri diversi. Non vanno confusi.

Cowork · progetta

Chiarisce e prepara

Definisce il processo, scrive il «charter» (documento che fissa scopo e regole), prepara i criteri di accettazione e l'handoff (passaggio di consegne) per Claude Code. Non costruisce il sistema.

Claude Code · implementa

Costruisce e dimostra

Crea i file, gli script, gli hook e i permessi, esegue i test e mostra le prove: comandi, differenze, esiti. Non dichiara «funziona» solo perché ha prodotto un output.

Le prime Skill devono saper dire NO

Una Skill (pacchetto di istruzioni che dice all'AI «come» comportarsi) non è generica: descrive un processo preciso, e dice anche cosa fare quando il processo non è applicabile.

Quando usarla

Quali input accetta e quali rifiuta, quali domande fare prima di partire.

Cosa può produrre

Quali output sono ammessi e quali vietati. Niente «se non trovi, inventa».

Quando fermarsi

Se non è un CV, non forzare il processo CV. Se manca un dato o il run_id, stop.

Ma il NO della Skill, da solo, non basta: serve un blocco tecnico.

Il run_id è il permesso di avvio

Non è valido solo perché qualcuno lo scrive: è valido se esiste davvero nel Runtime Evidence Log (il registro delle esecuzioni). Il sistema deve controllare:

È presente?la variabile del run_id esiste
Esiste nel registro?il valore è davvero nel log delle prove
È collegato alla capability?corrisponde alla funzione richiesta
Il processo è autorizzato?quel run_id può fare quell'operazione

Solo se tutte sono vere, l'agente può procedere.

Gli hook sono obbligatori

Le Skill guidano, gli hook bloccano. Un hook è un «gancio» tecnico che intercetta un'azione e la ferma se non è in regola. Senza, l'AI può aggirare le regole.

01

All'arrivo della richiesta

Intercetta le richieste agentiche prima che l'AI inizi.

UserPromptSubmit
02

Prima di usare uno strumento

Blocca codice e scrittura file se manca il run_id.

PreToolUse
03

Prima della risposta finale

Impedisce l'esito incoerente «ho prodotto l'output, ma non era governato».

Stop
04

Sui comandi diretti

Intercetta le scorciatoie e le attivazioni dirette delle Skill.

UserPromptExpansion

Il primo agente: una sola responsabilità

Deve essere noioso, controllato e prevedibile — non creativo. La creatività viene dopo. Esempio: un «Agente CV».

1

Riceve un CV e ne verifica la validità

Se l'input non è un CV, si ferma.

2

Estrae i dati e produce una scheda

Solo i campi previsti, nello schema definito.

3

Registra le evidenze

Ogni passaggio finisce nel registro delle prove.

!

Niente output finale se manca il run_id

Strumenti limitati: lettura e ricerca, scrittura solo su cartella autorizzata, nessun comando libero all'inizio.

Le fixture: testa prima il blocco

Le fixture sono casi di test predefiniti. La regola: prima si testa il fallimento, poi il successo. Se il sistema non sa bloccare, non è pronto — sai solo che funziona quando tutto va bene.

Input valido + run_id valido→ passa
Input valido, nessun run_id→ bloccato
run_id falso→ bloccato
Tentativo di scrivere un file senza run_id→ bloccato

Non creare agenti verticali troppo presto

Creare subito Agente-CV, Agente-Report, Agente-Matching… porta a frammentazione. Meglio costruire ruoli riusabili che ogni processo può richiamare.

Collezione di bot

Un agente per ogni output

Dieci agenti diversi che replicano a mano il lavoro umano. Tanti pezzi, nessuna architettura.

Architettura

Capability e ruoli riusabili

Classificatore d'input, estrattore dati, controllo qualità, costruttore di output, registro prove, instradatore. Lo stesso ruolo serve CV, report e assessment.

La rotta operativa in 12 fasi

Dal processo all'output canonico (ufficiale, valido). Un secondo agente si pensa solo alla fine.

1Un solo processo
2Scriverlo a parole
3Input, output, stop
4Skill di processo
5Skill di controllo
6Evidence Log
7run_id obbligatorio
8Primo hook di blocco
9Agente con tool limitati
10Test + e test −
11Output canonici
12Secondo agente

Cosa non fare

Gli errori che fanno fallire un primo sistema agentico.

NOpartire dallo Swarm o creare dieci agenti subito
NOconfondere una Skill con un Agente, o usare il «promptone»
NOaccettare «funziona» senza prove (comandi, esiti, test)
NOpermettere output ufficiali senza run_id, o lasciare codice libero
NOaffidarsi alla memoria dell'Owner: la protezione non dipende dal singolo

La formula da ricordare

Un primo agente non è «un Claude più bravo»: è un processo trasformato in un esecutore controllato. Il valore non è che produca un output, ma che l'output sia autorizzato, ripetibile, verificabile, tracciato e non aggirabile.

Processo chiaro · Skill piccola · Agente limitato

run_id obbligatorio · Hook bloccanti · Evidence Log

Test negativi · solo dopo: output canonico