Standard di esecuzione IA

Le regole e le aspettative per delegare il lavoro all'IA in tutta l'organizzazione.

Politica delle Aspettative Organizzative

Il principio operativo alla base di questi standard è la Regola di Traduzione Universale: sostituire "l'umano produce l'artefatto" con "l'umano definisce le specifiche → il sistema produce l'artefatto."

Principio fondamentale

L'IA è trattata come un lavoratore autonomo, non come un chatbot.

Tutto il lavoro assegnato all'IA deve essere eseguibile senza supervisione umana in tempo reale durante l'esecuzione. Il chiarimento pre-esecuzione – l'agente che fa emergere supposizioni e pone domande calibrate prima di produrre output – è consentito e, a maturità più alta, atteso. Vedi Lab IA § Le cinque fasi per il pattern operativo.

Livelli di lavoro obbligatori

Ogni flusso di lavoro abilitato all'IA deve definire i quattro livelli di input (1–4). Il Livello 5 (Progettazione del processo) li estende con la pipeline operativa che consuma gli input; è obbligatorio per il lavoro al Tier 3 / Grado 5 e opzionale al di sotto.

Livello 1 – costruzione del prompt (competenza base)

I dipendenti devono:

scrivere istruzioni chiare
specificare il formato
includere esempi quando utile
risolvere le ambiguità in anticipo

Soglia minima: l'output dell'IA dovrebbe richiedere ≤20% di correzioni.

Livello 2 – ingegneria del contesto

Ogni team deve mantenere un file di contesto strutturato contenente:

obiettivi
vincoli
terminologia
standard di qualità
documenti rilevanti
regole di accesso agli strumenti

Requisito: i compiti IA devono caricare questo contesto prima dell'esecuzione.

Livello 3 – ingegneria dell'intento

Ogni flusso di lavoro deve definire:

gerarchia degli obiettivi
regole di compromesso
condizioni di escalation
cosa l'IA può decidere vs. cosa deve escalare

Nessun agente può operare senza un intento definito.

Livello 4 – ingegneria delle specifiche (standard più alto)

Tutti i compiti non banali devono avere una specifica scritta.

Componenti obbligatori della specifica:

descrizione del problema
ambito
input
vincoli
criteri di accettazione
condizioni di fallimento
test di successo
definizione di completamento

Regola: se il successo non può essere verificato oggettivamente, il compito non è pronto per essere specificato.

Per i codebase brownfield, l'inversione conta: il codice esiste già, e le specifiche devono essere retroingegnerizzate da esso prima che il nuovo lavoro spec-first possa riprendere. Vedi la strategia brownfield per il flusso di lavoro spec-from-code.

Livello 5 – progettazione del processo

Il livello operativo. Una volta che una specifica funziona, la domanda successiva è la pipeline che la esegue. La progettazione del processo è la disciplina di progettare flussi di lavoro vincolati e a fasi entro cui l'IA opera in modo coerente – distinta dall'ingegneria dei prompt e dalla scrittura di specifiche in sé. È il livello che distingue il lavoro al Tier 3 / Grado 5 dal lavoro al Tier 2 / Grado 4.

Il vocabolario, tratto da Building Effective Agents di Anthropic:

Prompt chaining – passaggi sequenziali a prompt singolo con validazione intermedia
Routing – classifica il task, instrada al prompt o flusso di lavoro specializzato appropriato
Parallelizzazione – esegue subtask indipendenti in concorrenza, aggrega i risultati
Orchestratore-lavoratori – un agente principale decompone il task e dispatcha i lavoratori
Valutatore-ottimizzatore – un generatore abbinato a un valutatore separato che dà punteggio e itera
Agenti autonomi – esplorazione aperta con uso di strumenti e cicli di feedback

Regola decisionale: inizia con prompt singolo; aggiungi workflow quando necessario; aggiungi multi-agente solo quando il valore per task giustifica il premium di token (gli agenti tipici usano ~4× i token della chat; multi-agente ~15×, secondo Anthropic, 2025). Non ricorrere al multi-agente perché suona sofisticato.

Anti-pattern:

Pitfall: Megaprompt singolo
Combina modi di fallimento; impossibile da debuggare.
Pitfall: Multi-agente fine a sé stesso
Costoso, fragile, spesso un singolo agente fa altrettanto bene.
Pitfall: Dump del contesto
Più contesto è spesso contesto peggiore.
Pitfall: Saltare le eval
Senza eval, i sistemi IA si degradano silenziosamente.
Pitfall: Ottimizzare i prompt quando il problema è il contesto
Attribuzione errata del modo di fallimento.

I quattro livelli di input (Prompt → Contesto → Intento → Specifica) descrivono cosa l'umano prepara prima della delega. Il Livello 5 descrive la pipeline che consuma quegli input. Al T3/R5 anche la pipeline è un artefatto progettato – e i gate di validazione al suo interno sono graduati per rischio (HITL / HOTL / HOOTL).

Primitivi di specificazione (competenze apprendibili)

L'ingegneria delle specifiche è costruita su cinque primitivi. Ognuno è una competenza distinta da praticare. Per esempi, template e specifiche elaborate per diversi ruoli, vedi la Guida alle specifiche.

Primitivo 1 – descrizioni del problema autocontenute

Descrivi il problema con abbastanza contesto perché il compito sia risolvibile senza che l'agente debba cercare ulteriori informazioni. Porta alla superficie le supposizioni nascoste. Articola i vincoli che normalmente lasci impliciti.

Esercizio di formazione: prendi una richiesta che faresti normalmente in modo conversazionale e riscrivila come se il destinatario non avesse mai visto il tuo progetto, non conoscesse la tua terminologia e non avesse accesso a nulla oltre a ciò che includi.

Primitivo 2 – criteri di accettazione

Definisci come appare il completamento in modo che un osservatore indipendente possa verificare l'output senza fare domande. Se non riesci a scrivere tre frasi che verificano il completamento, non capisci il compito abbastanza bene da delegarlo.

Primitivo 3 – architettura dei vincoli

Definisci quattro categorie per ogni compito:

Deve – requisiti non negoziabili
Non deve – azioni o output vietati
Preferisce – guida quando esistono più approcci validi
Escalation – condizioni in cui l'agente deve fermarsi e chiedere

Primitivo 4 – decomposizione

Suddividi i compiti in componenti che possono essere eseguiti indipendentemente, testati indipendentemente e integrati in modo prevedibile. Granularità target: sottocompiti di ≤2 ore con confini chiari di input/output, ciascuno verificabile da solo.

Primitivo 5 – progettazione della valutazione

Per ogni compito IA ricorrente, costruisci 3-5 casi di test con output noti di buona qualità. Eseguili dopo gli aggiornamenti del modello per rilevare le regressioni. Gli output sono giudicati per metriche, non per apparenza.

Una specifica valida deve superare tutti e cinque: autocontenuta, testabile, vincolata, decomponibile, valutabile.

Checklist di prontezza alla delega

Prima di assegnare un lavoro all'IA, i dipendenti devono confermare:

Capisco completamente il compito
Posso definire il successo oggettivamente
Posso elencare i casi di fallimento
Posso descrivere i vincoli
Posso verificare i risultati senza interpretazione

Se una risposta = no → non delegare ancora.

Modello di responsabilità per i fallimenti

Il fallimento è attribuito per livello:

Tipo di fallimento	Causa principale
Output scadente	Problema di prompt
Output irrilevante	Problema di contesto
Direzione sbagliata	Problema di intento
Output incompleto	Problema di specifica
Output dannoso	Problema di permessi / raggio d'impatto: l'agente non avrebbe dovuto poter intraprendere questa azione
Output non notato	Problema di gate di validazione: postura di supervisione sbagliata per il raggio d'impatto di questa azione (vedi gate graduati per rischio)
Direzione sbagliata difesa con sicurezza	Chiarimento saltato: l'agente si è impegnato prima che le supposizioni fossero esposte

I team devono correggere il livello responsabile, non riprovare i prompt.

Ruoli organizzativi

Ogni sistema IA in produzione deve avere:

Proprietario delle Specifiche – responsabile della qualità della specifica, dei criteri di accettazione e di cosa significa "fatto"
Proprietario del Contesto – responsabile dei file di contesto (CLAUDE.md / AGENTS.md), della freschezza del contesto e dell'ambito di strumenti/skill
Proprietario della Valutazione – responsabile della suite di eval, del rilevamento delle regressioni e delle metriche di qualità
Responsabile dei Permessi – responsabile di ciò che ogni agente può e non può fare e del livello di gating di validazione (HITL / HOTL / HOOTL) per classe di azione

Una persona può inizialmente ricoprire più ruoli. Il ruolo del Responsabile dei Permessi diventa portante non appena gli agenti toccano sistemi di produzione con effetti collaterali irreversibili.

Questi quattro ruoli governano un sistema IA in produzione. Sono distinti dai tre ruoli richiesti per governare la trasformazione IA di un team – vedi Guidare la trasformazione § Ruoli organizzativi.

Standard di documentazione

Tutti i documenti interni devono essere scritti come se un agente li eseguisse.

I documenti devono:

dichiarare le supposizioni
definire i termini
specificare i risultati
includere i vincoli
evitare la conoscenza implicita

Regola riassuntiva esecutiva

Il pensiero chiaro precede l'esecuzione IA.

Se non riesci a specificarlo, non puoi automatizzarlo.

← Torna alla home · Il quadro di riferimento · Il Lab IA · Glossario