Glossario
Definizioni dei concetti usati nella trasformazione IA.
Maturità IA
AI-Assisted – L'IA è uno strumento personale; nulla di strutturale cambia se scompare. Vedi il quadro di riferimento.
AI-Integrated – L'IA è integrata nei flussi di lavoro; i ruoli si spostano dal fare al dirigere. Vedi il quadro di riferimento.
AI-Native – Il design del lavoro assume l'IA come risorsa di primo piano; i ruoli definiti dal giudizio, non dall'esecuzione. Vedi il quadro di riferimento.
AI-Supportive – La leadership sostiene l'IA personalmente senza spingere l'adozione organizzativa. Vedi il quadro di riferimento.
AI-Operational – La leadership definisce aspettative basate sui ruoli e finanzia l'automazione prima di assumere. Vedi il quadro di riferimento.
AI-Strategic – La leadership ridisegna l'organizzazione intorno all'IA e rende l'alfabetizzazione IA una condizione di leadership. Vedi il quadro di riferimento.
Non esposto (Tier 0) – L'IA non fa parte del lavoro. Nessuna sperimentazione, nessuna consapevolezza delle capacità. Vedi il quadro di riferimento.
IA-curioso (Tier 0.5) – Ha provato l'IA ma non ha cambiato il modo in cui il lavoro viene svolto. Il gap verso il Tier 1 non è la conoscenza ma l'abitudine di ricorrere all'IA quando inizia il lavoro. Vedi il quadro di riferimento.
IA-consapevole (Tier 1) – L'individuo usa l'IA come strumento personale senza cambiare i flussi di lavoro. Vedi il quadro di riferimento.
IA-costruttore (Tier 1.5) – Progetta e testa attivamente flussi di lavoro IA. Costruisce prompt, itera, sperimenta. La fase di costruzione tra l'utilizzo ad hoc e i flussi di lavoro consolidati. Qui si bloccano la maggior parte delle persone. Vedi il quadro di riferimento.
IA-potenziato (Tier 2) – L'individuo integra l'IA nei flussi di lavoro ricorrenti in modo sistematico. Vedi il quadro di riferimento.
IA-avanzato (Tier 2.5) – Costruisce sistemi in cui l'IA gestisce la maggior parte dell'esecuzione. Più processi ridisegnati. Il titolo del ruolo non è cambiato ma il lavoro al suo interno sì. Vedi il quadro di riferimento.
IA-nativo (Tier 3) – Ruolo ridisegnato intorno a giudizio e direzione. La persona prevede dove si sposterà il confine umano-agente e alloca l'attenzione dove crea più valore. Vedi il quadro di riferimento.
Ingegneria IA
Produzione autonoma (Grado 5)
Modello ingegneristico dove le specifiche entrano e il software esce senza intervento umano sul codice. L'umano definisce architettura, vincoli e scenari; l'IA produce, testa e itera il codice. Detto anche fabbrica oscura (dark factory). Vedi il Lab IA.
Coding assistito (Grado 0)
Modalità di sviluppo in cui l'umano codifica e l'IA suggerisce completamenti. Il livello più basso di assistenza IA nello sviluppo software.
Sviluppo non interattivo
Modalità di lavoro in cui specifiche e scenari guidano agenti autonomi. L'umano non codifica e non conversa con l'agente durante l'esecuzione. Vedi il Lab IA.
Scenari
Percorsi utente end-to-end che descrivono il comportamento atteso dalla prospettiva dell'utente. Preferiti ai test unitari perché sono più difficili da aggirare per gli agenti. Vedi il Lab IA.
Metrica di soddisfazione
Approccio di valutazione che misura la frazione di traiettorie attraverso tutti gli scenari che soddisfa l'utente, piuttosto che un risultato binario verde/rosso. Vedi il Lab IA.
Ingenuità deliberata
La postura di rimuovere le convenzioni di sviluppo tradizionali e chiedere sistematicamente: "Perché sto facendo questo? Dovrebbe farlo il modello al posto mio." Vedi il Lab IA.
Greenfield
Un progetto avviato da zero, senza codice esistente. Il terreno più naturale per lo sviluppo non interattivo. Vedi il Lab IA.
Brownfield
Un progetto con codice e abitudini esistenti, trasferito al modello di produzione autonoma. Più difficile del greenfield, ma più impattante. Vedi il Lab IA.
Competenze IA
Alfabetizzazione IA – Uso strutturato degli strumenti IA e capacità di distinguere l'utilizzo ad hoc dall'integrazione nel flusso di lavoro. Vedi la guida per i dipendenti.
Costruzione del prompt – Istruzioni chiare, formato specificato, esempi, ambiguità risolta. Vedi gli standard di esecuzione.
Ingegneria del contesto – File di contesto strutturato caricato prima dei compiti IA. Vedi gli standard di esecuzione.
Ingegneria dell'intento – Gerarchia degli obiettivi definita, regole di compromesso e condizioni di escalation. Vedi gli standard di esecuzione.
Ingegneria delle specifiche – Ogni compito non banale ha una specifica scritta completa costruita su cinque primitivi. Vedi gli standard di esecuzione e la Guida alle Specifiche per esempi pratici.
Specifica – Un documento che definisce un problema con precisione sufficiente perché un agente lo risolva autonomamente. Vedi gli standard di esecuzione e la Guida alle Specifiche.
Descrizioni del problema autocontenute – Problema dichiarato con abbastanza contesto da essere risolvibile senza informazioni aggiuntive. Vedi gli standard di esecuzione.
Criteri di accettazione – Come appare il completamento, verificabile da un osservatore indipendente. Vedi gli standard di esecuzione.
Architettura dei vincoli – Quattro categorie per ogni compito: Deve, Non deve, Preferisce, Escalation. Vedi gli standard di esecuzione.
Decomposizione – Compiti suddivisi in componenti eseguibili, testabili e integrabili indipendentemente. Vedi gli standard di esecuzione.
Progettazione della valutazione – Casi di test con output noti di buona qualità per validare e rilevare regressioni. Vedi gli standard di esecuzione.
Progettazione delle giunture
La pratica di strutturare il lavoro in modo che le transizioni tra fasi umane e fasi degli agenti siano nette, verificabili e recuperabili. Una buona giuntura definisce l'artefatto di consegna, consente di controllare l'output dell'agente nel punto di transizione e permette l'intervento senza ricominciare da capo. Le giunture si spostano man mano che le capacità evolvono. Vedi la guida per i dipendenti.
Economia della trasformazione
Migrazione del valore
La tecnologia riassegna il valore al livello più scarso. Nella trasformazione IA, il valore lascia l'esecuzione (commodity) e si concentra su giudizio, inquadramento e proprietà del rischio (premium). Vedi la visione.
Le 5 funzioni umane
Direzione, Giudizio, Gusto, Relazione, Responsabilità. Le funzioni che rimangono insostituibili in un'organizzazione AI-native. Vedi la visione.
Evoluzione dei ruoli
Convergenza – Più ruoli si fondono perché l'IA rimuove il sovraccarico di coordinamento che giustificava la loro separazione. Il ruolo convergente conserva la superficie di giudizio combinata. Vedi Evoluzione dei Ruoli.
Specializzazione – Un ruolo si restringe al suo nucleo umano irriducibile man mano che l'IA assorbe lo strato routinario. Il ruolo diventa più preciso, non più piccolo. Vedi Evoluzione dei Ruoli.
Elevazione – Gli umani si spostano dal produrre artefatti al specificarli e valutarli. Si mappa direttamente sulla Regola di Traduzione Universale del framework. Vedi Evoluzione dei Ruoli.
Assorbimento – Le responsabilità di un ruolo vengono assorbite da ruoli adiacenti o sistemi. Le responsabilità si ridistribuiscono; il ruolo si contrae o scompare. Vedi Evoluzione dei Ruoli.
Emergenza – Nascono ruoli strutturalmente nuovi dalla struttura organizzativa AI-native. Denominati per la loro responsabilità, non per la tecnologia. Vedi Evoluzione dei Ruoli.
Matrice di Decisione dei Ruoli – Uno strumento strutturato che mappa le condizioni osservabili al pattern di evoluzione più probabile e all'azione raccomandata. Vedi Evoluzione dei Ruoli.
Adozione e transizione
Curva J di adozione
Il prevedibile calo di produttività durante l'adozione dell'IA. La produttività scende prima di salire. Le organizzazioni che ne escono sono quelle che ridisegnano i loro flussi di lavoro intorno alle capacità dell'IA. Vedi la guida per i manager.
Brief di transizione
Un documento strutturato consegnato da un dipendente che descrive il suo ruolo attuale, la visione AI-first, il gap, i sistemi da costruire, le metriche e il piano 30/60/90. Vedi la guida per i dipendenti.
Cliniche IA
Sessioni regolari (settimanali o bisettimanali) in cui il team condivide scoperte, blocchi e flussi di lavoro. Formato breve (30 min). L'obiettivo è l'apprendimento tra pari. Vedi la guida per i manager.
Muro dei sei mesi
Pattern di fallimento in cui i progetti guidati dall'IA senza un forte coinvolgimento umano (specifiche, scenari, architettura) accumulano debito strutturale che esplode dopo circa sei mesi. Gli scenari sono la difesa principale. Vedi il Lab IA.
Decadimento della calibrazione
Le competenze IA scadono man mano che le capacità evolvono. Una persona che ha calibrato il suo senso del confine umano-agente sei mesi fa ora o si fida troppo o sottoutilizza i modelli attuali. L'antidoto è la densità di feedback: frequenti cicli delega-valuta-aggiusta con i modelli attuali, non una formazione una tantum. Vedi la guida per i manager.
Costo cognitivo
Curva J cognitiva
La controparte in termini di energia mentale della curva J di produttività. Il carico cognitivo aumenta bruscamente durante la transizione Tier 1→2 (imparare a specificare, valutare output inaffidabili, mantenere il normale carico di lavoro) e torna a scendere una volta che i flussi di lavoro si stabilizzano al Tier 2. L'esaurimento si concentra nella transizione, non nello stato finale. Vedi Costo Cognitivo.
Sovraccarico cognitivo (brain fry)
Affaticamento mentale dalla supervisione dell'IA che supera la capacità cognitiva. Sintomi: nebbia mentale, decisioni più lente, tassi di errore in aumento. Lo studio BCG/UC Riverside ha rilevato che i guadagni di produttività si invertono oltre tre strumenti IA simultanei. Vedi Costo Cognitivo.
Affaticamento decisionale
Esaurimento dal volume di micro-decisioni che l'IA introduce. Ogni output dell'IA è una decisione (abbastanza buono, modificare, rigenerare, fidarsi, verificare) e il volume degrada la qualità delle decisioni che contano davvero. Vedi Costo Cognitivo.
Affaticamento da vigilanza
Esaurimento dal monitoraggio prolungato di sistemi IA che sono di solito corretti. Strutturalmente simile alla complacency da automazione in aviazione: l'attenzione si allenta perché il sistema funziona bene la maggior parte del tempo, e gli errori sembrano plausibili. Vedi Costo Cognitivo.
Intensificazione del lavoro
Il pattern in cui l'IA espande l'ambito piuttosto che ridurlo. Tre meccanismi: espansione dei compiti (le persone si assumono lavoro che prima non avrebbero tentato), confini sfumati (gli strumenti IA sembrano informali, il lavoro si espande), e multitasking (l'IA genera in parallelo mentre gli umani monitorano). Vedi Costo Cognitivo.
Inflazione del carico di lavoro
La tentazione organizzativa di aumentare le quote di output proporzionalmente alla velocità abilitata dall'IA. La capacità produttiva scala con l'IA; la capacità di giudizio no. Raddoppiare le quote di output perché le bozze escono più velocemente è come le persone più impegnate bruciano. Vedi Costo Cognitivo.
Ansia da IA
Stress anticipatorio guidato dall'incertezza sulla sicurezza del lavoro, sulla rilevanza delle competenze e sulla traiettoria di carriera. Distinto dall'affaticamento mentale da IA: colpisce le persone che temono l'IA, incluse quelle che non hanno ancora iniziato a usarla. Vedi Costo Cognitivo.
Disruzione identitaria
Perdita dell'identità professionale quando l'IA esegue competenze che definivano l'immagine di sé. Anche quando i ruoli migliorano oggettivamente, i lavoratori riportano sentimenti di obsolescenza, perdita di scopo e riduzione dell'autostima. Vedi Costo Cognitivo.
Impotenza appresa
Il pattern di ritiro quando i sistemi IA prendono decisioni che i lavoratori non capiscono, non controllano o non possono modificare. Le persone smettono di pensare criticamente all'output dell'IA e delegano anche quando non sono d'accordo. Il pattern più pericoloso per la trasformazione perché sembra conformità. Vedi Costo Cognitivo.
Affaticamento da trasformazione
Esaurimento cumulativo dal cambiamento costante (nuovi strumenti, nuovi flussi di lavoro, nuove aspettative) in aggiunta al normale carico di lavoro. Non specifico all'IA ma amplificato da essa. Una risposta razionale alla domanda cognitiva prolungata senza sufficiente recupero. Vedi Costo Cognitivo.
Maturità del codice
Livelli di maturità del codice
Un modello a cinque livelli per valutare se un codebase supporta lo sviluppo AI-native: Opaco (L0), Strumentato (L1), Validato (L2), Leggibile (L3), Specificato (L4), Governato da scenari (L5). Ogni livello è definito dal meccanismo di feedback che aggiunge. Il livello di maturità di un codebase è il soffitto sul Grado ingegneristico che può operarvi in modo affidabile. Vedi Maturità del codice.
Griglia di maturità del codice (Codebase Readiness Grid)
La diagnostica a nove dimensioni al centro del modello di maturità del codice. Ogni dimensione è valutata da 1 a 5 secondo il proprio rubric. La Griglia è un vettore, non uno scalare: non viene mai riassunta con una media. Il soffitto (punteggio più basso) imposta il livello di maturità; le dimensioni bloccanti (D1, D2, D5) hanno priorità su quelle vincolanti. Una skill Claude Code open source esegue la Griglia su qualsiasi repo.
Harness
L'infrastruttura che circonda un agente di codifica IA e che vincola e valida il suo output. Due parti: guide (feedforward: tipi, convenzioni, documentazione, architettura) e sensori (feedback: test, CI, osservabilità). Inquadrato da Fowler come "Agent = Model + Harness". Nei codebase brownfield, costruire il harness è il punto di leva, non scegliere un modello migliore. Vedi Maturità del codice.
Ambient affordances
Proprietà strutturali di un codebase che lo rendono leggibile a un agente IA senza istruzioni esplicite: tipizzazione forte, confini dei moduli chiari, denominazione coerente, framework consolidati, confini espliciti delle dipendenze. La loro assenza costringe gli agenti a inventare struttura o iniettare inconsistenza. Vedi Maturità del codice.
Topologia dei cicli di feedback
La densità e la latenza dei meccanismi di feedback in un codebase. Il risultato dell'ACMM: la maturità è definita dalla presenza di feedback, non dalla sofisticazione degli strumenti. CI veloce (sotto 30 minuti), test utili e osservabilità strutturata chiudono il ciclo di correzione dell'agente. Una suite di test a 72 ore non è un sensore: è un report.
Dimensioni bloccanti
Le tre dimensioni della maturità del codice i cui punteggi bassi compromettono fondamentalmente il lavoro degli agenti e non possono essere compensati da punteggi alti altrove: copertura dei test e latenza del feedback (D1), rigidità dei tipi (D2) e direttezza delle API (D5). Un codebase che ottiene 1–2 su una di queste non è salvato dall'ottenere 5 su tutto il resto. Vedi Maturità del codice.
Dimensioni vincolanti
Le sei dimensioni della maturità del codice che degradano la qualità dell'output degli agenti quando ottengono punteggi bassi, ma non bloccano completamente il lavoro: dimensione dei file e leggibilità del contesto, chiarezza dei confini dei moduli, intento documentato, osservabilità, semplicità di sviluppo e deploy, aggiornamento di dipendenze e runtime. Punteggi bassi qui significano più revisione umana per modifica e più pulizia, ma gli agenti possono ancora produrre valore affidabile. Vedi Maturità del codice.
Strategia brownfield
Le quattro modalità brownfield
Risanare in loco, migrazione strangler-fig, ricostruzione completa, isolare e aggirare. Ognuna si adatta a una diversa combinazione di solidità architettonica, chiarezza dei seami, vincoli di continuità aziendale, capacità del team e valore residuo nel legacy. Scegliere la modalità sbagliata è costoso. Vedi Strategia brownfield.
Isolare e aggirare
Una modalità brownfield dove il legacy viene congelato in modalità di manutenzione e il nuovo valore viene consegnato come app standalone pronte per il Livello 5 accanto a esso. La scelta giusta quando il costo del risanamento supera il valore residuo nel legacy. Compra tempo ma non risolve il problema sottostante: alla fine qualcosa forza la decisione di sostituzione. Vedi Strategia brownfield.
Ricerca, Revisione, Ricostruzione
Una metodologia a fasi per la modernizzazione brownfield assistita dall'IA (Fowler/EPAM): Ricerca (l'IA ricostruisce l'intento dal codice esistente), Revisione (gli esperti di dominio validano la mappa dell'intento), Ricostruzione (l'IA genera codice sostitutivo con ambiguità minima). Saltare Ricerca e Revisione produce output sbagliato con sicurezza più velocemente. La revisione umana è il collo di bottiglia della capacità, non la generazione IA. Vedi Strategia brownfield.
Spec-from-code
L'inversione brownfield dello sviluppo spec-driven. Le specifiche precedono il codice nel greenfield; nel brownfield, le specifiche devono essere retroingegnerizzate dal codice esistente prima che il nuovo lavoro spec-first possa riprendere. Estrarre la specifica implicita è il lavoro umano più difficile nella transizione: gli agenti possono documentare cosa fa il sistema, solo gli umani possono distinguere il comportamento intenzionale dall'incidente storico. Vedi Strategia brownfield.
Migrazione strangler-fig
Il pattern di sostituzione di un sistema legacy pezzo per pezzo, con i nuovi pezzi che girano accanto ai vecchi dietro una facade, finché il sistema vecchio non può essere ritirato. L'identificazione dei seami (trovare dove le responsabilità possono essere estratte in modo pulito) è la competenza critica. L'IA rende la sostituzione meno costosa ma non elimina la necessità di trovare i seami. Vedi Strategia brownfield e l'originale Strangler Fig Pattern di Martin Fowler.
Technical Debt Quadrant
La categorizzazione a quattro vie del debito tecnico di Fowler per intento (deliberato vs. involontario) e disciplina (prudente vs. sconsiderato). Il quadrante informa la strategia di rimedio: il debito prudente-involontario è spesso rimediabile, il debito sconsiderato-involontario è tipicamente un candidato alla ricostruzione perché la struttura riflette ignoranza che la conoscenza successiva non può sciogliere in loco. Vedi Strategia brownfield.
Identificazione dei seami
La pratica di trovare punti in un codebase legacy dove le responsabilità possono essere estratte in modo pulito per la migrazione strangler-fig. Resa nota da Michael Feathers in Working Effectively with Legacy Code. La competenza critica che determina se un approccio strangler-fig produce un sistema più pulito o due sistemi accoppiati.
Tecniche Black Box to Blueprint
Cinque tecniche di retroingegneria (Fowler) per sistemi legacy opachi: ricostruzione del livello UI, change data capture, inferenza della logica server, archeologia binaria e arricchimento progressivo multi-pass. Due discipline non negoziabili: triangolazione (conferma ogni ipotesi attraverso due fonti indipendenti) e tracciamento della provenienza (registra le prove su cui si basa ogni affermazione). Vedi Strategia brownfield.
Realtà operativa al T3 / R5
Unità operativa a cinque fasi
L'unità operativa ricorrente al Tier 3 / Grado 5: Contesto → Chiarimento → Esecuzione → Validazione → Recupero. Gli umani si concentrano ai confini (fronte: specificazione e chiarimento; retro: validazione e recupero); l'agente lavora all'interno. La stessa forma si applica ai diversi domini di lavoro discreto indipendentemente dal substrato. Vedi Lab IA § Le cinque fasi.
Lavoro a due confini
Il pattern strutturale del lavoro al Tier 3 / Grado 5: l'attenzione umana si concentra al confine anteriore (preparazione del Contesto + Chiarimento) e al confine posteriore (Validazione + Recupero). All'interno del ciclo, l'agente opera senza supervisione. Il passaggio è dalla revisione riga per riga alla direzione e al giudizio per ciclo.
Pattern di lavoro discreto
La categoria di lavoro in cui l'IA opera come livello di esecuzione: un'unità chiara (story, ticket, transazione, query, clausola contrattuale), output verificabili, rischio graduabile. Ingegneria, servizio clienti, operazioni finanziarie, revisione legale e ricerca della conoscenza vi rientrano. I pattern v3 del framework si applicano a tutta questa categoria. Il lavoro continuo / creativo / interpersonale (vendite, marketing creativo, design, HR) richiede un framework diverso – rinviato a una futura traccia di aumento v4+.
Dialogo di chiarimento
Una fase operativa discreta al Tier 3 / Grado 5 in cui l'agente esamina la specifica, espone le sue supposizioni e pone domande calibrate prima di eseguire. /speckit.clarify di spec-kit e la modalità plan + lo strumento AskUserQuestion di Anthropic implementano il pattern in produzione. Regola di costo: il costo del chiarimento è limitato in minuti; il costo di correzione cresce con la profondità di esecuzione. Vedi Guida alle specifiche § Dialogo di chiarimento.
Progettazione del processo per l'IA
La disciplina di progettare flussi di lavoro vincolati e a fasi entro i quali l'IA opera in modo coerente – distinta dall'ingegneria dei prompt e dalla scrittura di specifiche in sé. Livello 5 degli Standard di Esecuzione IA. Distingue il lavoro al Tier 3 / Grado 5 dal lavoro al Tier 2 / Grado 4. Vedi Standard di esecuzione IA § Livello 5.
Topologie di processo (le sei)
Il vocabolario di Anthropic per come è strutturata la pipeline che esegue una specifica: prompt chaining (passaggi sequenziali a prompt singolo con validazione intermedia), routing (classifica e instrada a prompt specializzati), parallelizzazione (esegue subtask indipendenti in concorrenza), orchestratore-lavoratori (un agente principale decompone e dispatcha i lavoratori), valutatore-ottimizzatore (generatore abbinato a un valutatore separato) e agenti autonomi (esplorazione aperta con uso di strumenti e cicli di feedback). Regola decisionale: iniziare con prompt singolo; aggiungere complessità solo quando il valore per task giustifica il premium di token.
Validazione graduata per rischio
Gate di validazione graduati per rischio
Il principio che la validazione al Grado 5 non è monolitica: classi di azioni diverse ottengono gate diversi a seconda del raggio d'impatto, della reversibilità e della conseguenza. Tre posture operative (HITL / HOTL / HOOTL) descrivono il gradiente. Un team maturo al Grado 5 opera tutte e tre contemporaneamente, scegliendo il gate per classe di azione. Vedi Lab IA § Gate di validazione graduati per rischio.
HITL – Human-in-the-Loop
Una postura di validazione in cui l'approvazione umana è richiesta prima che un'azione IA venga eseguita. Predefinita per azioni irreversibili ad alto impatto: transazioni finanziarie, deploy di produzione, comunicazioni rivolte ai clienti, qualsiasi cosa generi obblighi legali o finanziari. Limitata dal throughput dalla capacità di revisione umana. Vedi Lab IA § Gate di validazione graduati per rischio.
HOTL – Human-on-the-Loop
Una postura di validazione in cui l'IA agisce autonomamente ma l'umano monitora con autorità di intervento (kill switch, rollback, override). Predefinita per lavoro di produzione reversibile con forte copertura di eval. Operativamente fragile quando trattata come monitoraggio passivo: l'affaticamento da vigilanza trasforma un HOTL nominale in teatro di conformità. Vedi Lab IA § Gate di validazione graduati per rischio.
HOOTL – Human-out-of-the-Loop
Una postura di validazione in cui l'IA agisce entro confini predefiniti senza coinvolgimento umano in tempo reale. Riservata a lavoro sandbox reversibile con test forti e un agente revisore su ogni artefatto. I merge di codice in un repo ben testato con un agente revisore tipicamente girano in HOOTL. Vedi Lab IA § Gate di validazione graduati per rischio.
Dominio di progettazione operativa (ODD)
Le condizioni entro cui un agente IA è progettato per funzionare. Tratto da SAE J3016 (guida) come analogo più pulito. Al di fuori dell'ODD, l'agente non fa affermazioni; il gate ricade sull'umano. Definire l'ODD fa parte della progettazione del processo: quali strumenti ha l'agente, a quali dati può accedere, quali azioni può intraprendere. Vedi Lab IA § Gate di validazione graduati per rischio.
Agente revisore
Il pattern di abbinare un agente generatore con un agente valutatore separato (contesto diverso, a volte un modello diverso) che revisiona l'output prima del merge o del commit. Ora il default di produzione per la revisione del codice (CodeRabbit, Graphite Diamond, Greptile, GitHub Copilot review) e in adozione nel servizio clienti, nell'elaborazione documenti e in altri domini di lavoro discreto. Sostituisce la revisione umana sincrona su scala perché la matematica del costo per unità unita funziona in un modo in cui la revisione umana su scala non lo fa. Vedi Ingegneria dell'affidabilità § Agente revisore.
Responsabile dei permessi
Un ruolo organizzativo nominato nei sistemi IA di produzione. 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. Diventa portante non appena gli agenti toccano sistemi di produzione con effetti collaterali irreversibili. Vedi Standard di esecuzione IA § Ruoli organizzativi.
Modi di fallimento e recupero
Protocollo di stato bloccato
La procedura al Grado 5 / Tier 3 per gestire un deliverable in cui l'agente ha raggiunto un limite strutturale. Rileva lo stato bloccato (limite di iterazione raggiunto, stesso pattern di fallimento ricorrente o problema soggettivo sollevato da un utente); ferma l'iterazione; convoca una sessione di ricalibrazione; ri-specifica o ri-contestualizza; riavvia il ciclo dal Contesto, non dall'Esecuzione. La regola del Lab è esplicita: non riprendere il lavoro manualmente. Vedi Lab IA § Protocollo di stato bloccato.
Collo di bottiglia dell'IA
Il modo di fallimento al Tier 2.5+ in cui un deliverable manca la sua scadenza perché l'agente ha raggiunto un limite strutturale (direzione sbagliata, specifica ambigua, caso limite soggettivo che non riesce a risolvere da solo), non perché la capacità umana è scarsa. Cemri et al. (Why Do Multi-Agent LLM Systems Fail?, 2025) hanno rilevato che il 41,8% dei fallimenti multi-agente segue questo pattern. La risposta della leadership è tempo di ricalibrazione, non ridistribuzione del lavoro o aggiunta di organico. Vedi Guidare la trasformazione § Collo di bottiglia dell'IA.
Sycophancy (compiacenza)
Gli LLM difendono con sicurezza posizioni sbagliate in modo affidabile. Misurato in Sharma et al. (2023), Wen et al. (2024) e nel lavoro di OpenAI sulle allucinazioni (2025). La letteratura è in genuino disaccordo sul fatto che sia un problema trattabile con il training o un artefatto strutturale dell'RLHF; la posizione del framework è di trattare la sycophancy come una preoccupazione strutturale ai fini ingegneristici indipendentemente dalla traiettoria di training. Inserisci salvaguardie di processo (segnale esterno, agente revisore, retrieval di ground-truth, test eseguibili) in ogni ciclo. Vedi Ingegneria dell'affidabilità § Sycophancy.
Caso limite soggettivo
Un fallimento sollevato da un utente, non dai test o dal monitoraggio: l'IA ha sbagliato qualitativamente qualcosa (tono, intento, voce del brand, allineamento con il cliente) ma l'output tecnico ha superato tutti i controlli. Il modo di fallimento dominante a maggior maturità. Il recupero è conversazione, non patching: parla con l'utente, capisci cosa stava cercando di realizzare, aggiorna la specifica o il contesto. Vedi Ingegneria dell'affidabilità § Casi limite soggettivi.
Ricalibrazione vs debugging
Due risposte operativamente distinte quando l'IA è sbagliata. La ricalibrazione ricostruisce la comprensione dell'agente tramite contesto fresco, specifica riarticolata o brainstorm multi-prospettiva. Il debugging corregge l'artefatto prodotto dall'agente. La letteratura sull'auto-correzione intrinseca è unanime: un modello che si è impegnato in una direzione sbagliata non se ne accorgerà in modo affidabile da solo – il che significa che la maggior parte dei fallimenti non banali al T3 / R5 sono problemi di ricalibrazione travestiti da problemi di debugging. Vedi Ingegneria dell'affidabilità § Ricalibrazione vs debugging.
Economia dell'IA a maturità
Costo per unità di output
La metrica di misurazione al Level 3 che sostituisce "tempo risparmiato dall'IA": costo per PR fuso, costo per ticket risolto, costo per transazione elaborata, costo per cliente servito. L'unità varia per dominio; il principio è coerente: la spesa IA totale senza denominatore è priva di significato a maturità. Vedi Analisi di fattibilità § Economia dell'IA a maturità.
Margine lordo IA
Il rapporto tra valore prodotto e spesa di inferenza a livello di team o di business. Le aziende IA del livello applicativo operano al 40–55% di margine lordo contro il 70–90% del SaaS tradizionale: un gap strutturale perché l'inferenza è un costo variabile che scala con l'uso. Se il gap si chiuda nel tempo è contestato; il pavimento è reale e le aziende AI-native devono pianificare attorno ad esso. Vedi Analisi di fattibilità § Economia dell'IA a maturità.
Economia dei token
La disciplina di misurare l'IA come infrastruttura di produzione: costo per task, costo per unità unita, throughput dell'agente per dollaro, margine lordo IA. Sostituisce "tempo risparmiato" come metrica vincolante al Level 3. I costi per token stanno calando del 10–40× all'anno, ma i costi per task spesso aumentano perché i modelli di reasoning, i cicli di agente e i contesti più lunghi consumano 10–100× i token dei completion one-shot (paradosso di Jevons applicato all'inferenza). Vedi Analisi di fattibilità § Economia dell'IA a maturità e Lab IA § Economia dei token.
← Torna alla home · Il quadro di riferimento · Standard di esecuzione IA