Governance di team: ownership, review, policy

Quando un prompt guida una feature reale, non è più un appunto personale. È una decisione tecnica che influenza prodotto, costi, sicurezza, privacy e qualità percepita. Serve quindi governance: non burocrazia pesante, ma regole chiare su chi decide, chi rivede e cosa deve essere verificato.

La governance è il modo in cui un team evita prompt orfani, tool troppo potenti e cambi di modello fatti senza misurazione.

Perché questa lezione conta

In molti team i prompt nascono in modo informale: qualcuno li scrive, qualcuno li copia in codice, qualcuno li ritocca quando c’è un problema. Dopo qualche mese nessuno sa chi ne è proprietario, quali eval devono passare, quale provider è autorizzato o quali dati possono essere usati.

Questa situazione è rischiosa non perché manchi un documento, ma perché mancano responsabilità e criteri. Una policy breve e applicabile vale più di dieci pagine astratte.

Obiettivo operativo

Alla fine della lezione devi saper assegnare ownership a prompt e tool, definire una review efficace e scrivere una policy operativa di una pagina per il tuo team.

Cosa deve avere un owner

Ogni prompt critico dovrebbe avere un owner. L’owner non è l’unica persona che può modificarlo, ma è responsabile del comportamento.

Responsabilità tipiche:

1. mantenere README del prompt;
2. approvare modifiche importanti;
3. curare eval set;
4. monitorare regressioni;
5. coordinare review sicurezza/privacy quando serve;
6. decidere deprecazione o rollback;
7. mantenere changelog.

Per tool e agenti, l’owner deve coprire anche permessi, schema, dry run e log.

Matrice di responsabilità

Una matrice semplice:

artefatto              owner        review obbligatoria
prompt classificazione product eng  tech lead + support lead
tool create_ticket     backend      security se cambia permessi
schema output          platform     consumer del dato
eval dataset           prompt owner domain expert
provider/model config  platform     cost owner

Non serve una struttura complessa. Serve sapere chi coinvolgere prima del merge.

Review di un prompt

Una review seria non guarda solo la grammatica. Deve controllare:

1. diff del template;
2. motivo del cambiamento;
3. risultati eval;
4. impatto su costo e latenza;
5. compatibilità schema;
6. privacy e dati sensibili;
7. rischio prompt injection;
8. tool o permessi coinvolti;
9. rollout e rollback;
10. documentazione aggiornata.

Una checklist di PR può essere:

- [ ] prompt version aggiornata
- [ ] eval eseguito sul dataset minimo
- [ ] regressioni note dichiarate
- [ ] schema/output compatibile o migrazione descritta
- [ ] impatto costo/latenza stimato
- [ ] dati sensibili considerati
- [ ] rollout/rollback indicati
- [ ] owner approva

Livelli di cambiamento

Non tutte le modifiche hanno lo stesso peso.

Basso rischio. Correzione typo, chiarimento non comportamentale, documentazione.

Medio rischio. Nuovo esempio few-shot, cambio vincolo, cambio formato parziale, variazione tono su feature visibile.

Alto rischio. Nuovo tool, modifica permessi, cambio modello, output contract diverso, dati sensibili, automazione senza review umana.

La policy deve dire cosa richiede ogni livello: semplice PR, eval, approvazione owner, security review, rollout con flag.

Policy breve

Esempio di policy:

1. Ogni prompt usato in produzione vive in prompts/ con owner e README.
2. Ogni modifica comportamentale richiede PR, changelog ed eval.
3. Ogni output strutturato ha schema versionato e parser strict.
4. Ogni tool con side effect richiede owner, permessi minimi e dry run quando possibile.
5. Cambi di modello o provider richiedono confronto costo/qualità/latenza.
6. Dati sensibili nei prompt sono vietati salvo approvazione e redazione documentata.
7. Ogni rollout di prompt critico deve avere flag o rollback rapido.

Questa è una policy che si può applicare. Non prova a coprire ogni caso, ma crea default chiari.

Governance e velocità

Governance non significa rallentare tutto. Significa definire corsie:

1. esperimenti locali liberi;
2. prompt interni con review leggera;
3. prompt utente-facing con eval;
4. agenti con tool e side effect con review più severa;
5. dati sensibili con approvazione specifica.

Così il team può sperimentare senza portare in produzione processi informali.

Laboratorio guidato

Prendi un progetto reale o simulato con almeno tre prompt e due tool. Per ciascuno definisci:

1. owner;
2. rischio;
3. eval richiesto;
4. revisori;
5. rollout;
6. policy dati;
7. fallback.

Poi scrivi una policy di massimo una pagina e testala su tre casi:

1. cambio di tono del prompt;
2. cambio modello per ridurre costi;
3. nuovo tool che scrive dati.

Se la policy non dice chiaramente cosa fare in questi casi, è troppo vaga.

Output atteso

Devi produrre:

1. matrice ownership;
2. checklist PR;
3. livelli di rischio;
4. policy breve;
5. esempi di applicazione.

Il risultato deve poter stare nel README tecnico o in docs/ai-governance.md.

Errori comuni

Prompt senza owner. Quando qualcosa peggiora, nessuno sa chi decide il rollback.

Review solo linguistica. Il testo può essere bello e il comportamento peggiore.

Policy astratta. “Usare l’AI responsabilmente” non aiuta al prossimo PR.

Stessa procedura per tutto. Un typo e un nuovo tool di scrittura non hanno lo stesso rischio.

Checklist di verifica

• ogni prompt critico ha owner;
• i livelli di rischio sono chiari;
• la review include eval, costi, privacy e sicurezza;
• i tool con side effect hanno controlli aggiuntivi;
• la policy è corta abbastanza da essere usata.

Collegamenti

• Modulo: Prompt in produzione e governance — questa lezione è la numero 39 del corso.
• Prepara il capstone finale, dove ownership e policy diventano parte della consegna.