Manifesto
Costruire sistemi agentici con metodo, governo e chiarezza.
Il manifesto ADLC (Agentic Development Lifecycle) definisce principi condivisi per progettare sistemi agentici governati, tool-agnostic e guidati da un lifecycle esplicito.
ADLC Manifesto
L’ADLC non sostituisce l’SDLC: ne conserva le pratiche di ingegneria e le estende per governare il software sviluppato con agenti e i sistemi agentici in produzione.
L'ADLC si applica sia al software sviluppato con il supporto di agent, sia ai sistemi che impiegano agent in produzione.
Nel primo caso, governa le modifiche generate, la verifica rispetto ai requisiti e la responsabilità umana nell'accettazione. Nel secondo, estende questi controlli al comportamento runtime, alla conoscenza, agli strumenti e all'autonomia degli agent.
Non coincide con il coding autonomo né con la sola sicurezza del codice generato dall'AI: richiede evidenze verificabili e responsabilità esplicite lungo tutto il ciclo di vita.
Il sorgente del Manifesto ADLC, la licenza, le linee guida di contribuzione e i file del sito sono disponibili nel repository pubblico.
Principi
Ogni iniziativa parte da requisiti verificati, comprensibili e abbastanza maturi da ridurre ambiguità e rilavorazioni.
Componenti, agenti e capability devono essere pensati per essere riusati, collegati e orchestrati nel tempo.
Gli strumenti aiutano, ma non devono dettare l’architettura: processo e governance vengono prima del tool.
Non ogni problema richiede un agente, né più agenti producono necessariamente risultati migliori. Scegliere la soluzione meno complessa che soddisfa i requisiti approvati, concedendo solo l'autonomia necessaria. Giustificare la complessità aggiuntiva con benefici misurabili rispetto a una soluzione più semplice.
Permessi, approvazioni, budget e controlli di arresto sono applicati a runtime, non soltanto descritti nei prompt.
Controlli di governance
La supervisione umana è un layer di controllo obbligatorio nell'ADLC, soprattutto nell'approvazione dei requisiti, nella validazione della qualità, nell'autorizzazione delle release e nel governo della produzione.
Gli agent accelerano e strutturano il lavoro, ma le decisioni critiche e responsabili restano esplicitamente umane.
Supervisione competente, non approvazione rituale.
Chi approva deve essere formato sul dominio, sui limiti degli agent e sui rischi decisionali, con esercitazioni su errori e incidenti proporzionate al rischio. Deve avere accesso a evidenze, fonti, incertezze e conseguenze delle azioni, oltre a tempo sufficiente e un carico di lavoro sostenibile per valutarle.
Deve poter contestare, rifiutare, sospendere, richiedere una revisione ed effettuare escalation. Un'approvazione formale senza verifica sostanziale non costituisce un controllo di governance.
Nessuna implementazione inizia senza aver superato il quality gate dei requisiti. Il gate approva il prossimo incremento, non tutti i requisiti futuri. Un agent può supportarne la preparazione; le persone responsabili approvano ambito, risultati misurabili, rischi e incertezze note.
Questo gate è fondamentale perché determina se l'implementazione debba iniziare oppure no.
L'ADLC tratta la conoscenza e il contesto come parti governate del sistema. Documenti, prompt, skill condivise, memoria, policy, esempi, istruzioni dei tool e informazioni recuperate tramite RAG, ove utilizzato, possono influenzare il comportamento dell'agent e introdurre regressioni silenziose anche quando il codice applicativo non cambia.
La Knowledge Governance si applica indipendentemente da come viene fornito il contesto. La generazione aumentata dal recupero di informazioni (RAG) è una tecnica, non un'architettura obbligatoria né un sinonimo di governance della conoscenza. Ove utilizzata, richiede controlli specifici sulla qualità del retrieval, sull'aggiornamento delle fonti, sulle autorizzazioni di accesso e sulle citazioni.
Le modifiche alla conoscenza devono quindi essere revisionate, versionate, tracciabili e validate rispetto al comportamento atteso prima dell'uso in produzione.
Contesto runtime e memoria richiedono provenienza, autorizzazioni di scrittura, conservazione, isolamento tra utenti e tenant, cancellazione e gestione delle contraddizioni. I contenuti recuperati non conferiscono autorità. La compressione deve preservare permessi, vincoli ed evidenze decisive.
Contesto aziendale distribuito, accesso governato. Gli agent devono poter individuare e utilizzare le informazioni pertinenti attraverso interfacce interoperabili, come API, MCP o meccanismi equivalenti. Le fonti mantengono responsabilità, versioni, provenienza e autorizzazioni. Il contesto fornito deve essere selezionato per il task e il suo contributo alla qualità dei risultati deve essere verificato.
FAIR · W3C DCAT 3 · W3C PROV-DM. Questi riferimenti supportano reperibilità, interoperabilità e provenienza; non garantiscono da soli output migliori degli agent.
Definire un responsabile, azioni e dati consentiti, autorità delegata, budget, condizioni di arresto ed escalation. Applicare permessi e approvazioni fuori dal prompt, con credenziali revocabili e un meccanismo di arresto testato.
Usare dataset rappresentativi e versionati, prove ripetute, stato isolato e soglie basate sul rischio. Verificare risultati effettivi e rispetto delle policy; calibrare i valutatori basati su modelli rispetto al giudizio umano e dichiarare incertezze e lacune di copertura.
Misurare costo per task riuscito, latenza, interventi umani, rilavorazioni, escalation e valore di business rispetto a una baseline. Le evidenze possono giustificare la riduzione dell'autonomia o il ritiro del sistema.
Stage 0
Nessuna implementazione inizia senza aver superato il quality gate dei requisiti. Il gate approva il prossimo incremento, non tutti i requisiti futuri. Un agent può supportarne la preparazione; le persone responsabili approvano ambito, risultati misurabili, rischi e incertezze note.
Usare il minimo livello di autonomia e complessità necessario per ottenere il risultato validato. Confrontare automazione deterministica, workflow LLM, singolo agent e orchestrazione multi-agent rispetto a una baseline di business misurabile.
Anche gli esperimenti richiedono ipotesi approvata, sandbox, dati consentiti, budget e criteri di uscita prima dell'implementazione.
Qui la presenza umana è necessaria per confermare scope, intenzione, significato di business e approvazione prima dell'avvio del lifecycle.
ADLC Lifecycle
Nessuna implementazione inizia senza aver superato il quality gate dei requisiti. Il gate approva il prossimo incremento, non tutti i requisiti futuri. Un agent può supportarne la preparazione; le persone responsabili approvano ambito, risultati misurabili, rischi e incertezze note.
Human in the loop: approvazione obbligatoria della qualità e dell'intento dei requisiti.
Tradurre i requisiti approvati in capability concrete, servizi, prompt, workflow, integrazioni e componenti riusabili. È lo step in cui l’intento diventa una soluzione reale, strutturata in modo da poter essere revisionata, testata, governata ed evoluta nel tempo senza perdere coerenza architetturale.
Implementare il contratto di autonomia con accesso a privilegio minimo, policy applicate a runtime, budget e controlli di arresto. Le persone restano progettisti e implementatori, oltre che reviewer.
Rivedere la soluzione in termini di qualità, coerenza, sicurezza, manutenibilità e allineamento ai principi del manifesto prima di procedere alla validazione.
Human in the loop: review esperta, giudizio sul rischio e decisione di procedere.
Revisionare autorità delegata, confini di fiducia, gestione della memoria, qualità delle valutazioni e piani di recupero, inclusi gli effetti irreversibili.
Convalidare comportamento atteso, edge case, failure mode, affidabilità e prontezza operativa tramite evidenze di test strutturate e criteri di accettazione misurabili.
Il test copre anche le regressioni comportamentali causate da modifiche a prompt, contenuti RAG, shared skill, configurazione del modello, tool e regole di orchestrazione.
Usare dataset rappresentativi e versionati, prove ripetute, stato isolato e soglie basate sul rischio. Verificare risultati effettivi e rispetto delle policy; calibrare i valutatori basati su modelli rispetto al giudizio umano e dichiarare incertezze e lacune di copertura.
La validazione del software prodotto da agent richiede supervisione umana competente. Le persone responsabili approvano i criteri di accettazione, revisionano l'adeguatezza dei test e valutano evidenze e rischio residuo per autorizzare il rilascio. Gli agent possono generare ed eseguire test, ma non approvare il proprio lavoro né indebolirne unilateralmente le condizioni di accettazione. Un secondo agent non sostituisce la responsabilità umana; la profondità della revisione è proporzionata al rischio, senza richiedere l'esecuzione manuale di ogni test.
Rilasciare in modo controllato, osservabile e ripetibile, con rollback, release note, ownership ed evidenze di deployment chiaramente definite.
Le evidenze di release devono identificare modifiche al codice, ai prompt, al RAG o alla documentazione, ai tool, alla configurazione del modello e all'orchestrazione.
Human in the loop: autorizzazione della release e responsabilità del go-live.
Distinguere rollback della configurazione, ripristino dello stato e compensazione degli effetti esterni. Le azioni irreversibili richiedono controlli preventivi e approvazione esplicita: un rollback non può annullare ogni azione.
Gestire la soluzione con monitoraggio, alert, runbook, flussi di supporto e checkpoint di governance che mantengano il sistema affidabile in condizioni reali.
Le operazioni devono monitorare non solo la salute tecnica, ma anche drift comportamentale, risposte inattese, uso di conoscenza obsoleta, fallimenti di retrieval e regressioni introdotte dagli aggiornamenti di conoscenza.
Human in the loop: gestione incident, escalation e supervisione di governance in produzione.
Limitare i tentativi ed evitare effetti duplicati. Testare funzionamento degradato, escalation, arresto e revoca. Misurare costo per task riuscito, latenza, interventi umani, rilavorazioni, escalation e valore di business rispetto a una baseline. Le evidenze possono giustificare la riduzione dell'autonomia o il ritiro del sistema.
Migliorare continuamente sulla base di feedback di produzione, incident, analytics, insight utenti e apprendimenti di delivery che mostrano cosa affinare dopo.
Usare le evidenze di produzione per ridurre l'autonomia o ritirare sistemi con valore o affidabilità insufficienti. Revocare credenziali, endpoint e attività pianificate; conservare o cancellare la memoria secondo policy approvate.
Coordinare agenti, flussi, policy e capability riusabili in un ecosistema composabile capace di scalare oltre implementazioni isolate.
Propagare identità, limiti dei permessi, budget, stato delle approvazioni e tracciabilità nelle deleghe. Governare stato condiviso e memoria senza ampliare implicitamente l'autorità.
ADLC Operating Model
Requisiti validati, intento di business esplicito, ownership nominata e quality gate superato prima di iniziare qualsiasi build.
Usare questa checklist per validare le evidenze, non per ripetere le attività del lifecycle. Assegnare responsabili umani nominati; la profondità della revisione dipende dal rischio e l'esecuzione può essere automatizzata. I controlli obbligatori falliti bloccano l'avanzamento. Operatività e orchestrazione richiedono controlli continui, non un gate di uscita una tantum.
Baseline di implementazione
I principi diventano operativi solo quando sono tradotti in controlli ripetibili, verifiche misurabili ed evidenze revisionabili.
Requirements quality gate superato, criteri di accettazione misurabili e responsabili business, tecnici e di rischio nominati.
Codice, prompt, conoscenza, fonti RAG, shared skill, configurazione del modello, descrizioni dei tool e regole di orchestrazione sono input controllati e versionati.
Test, valutazioni, controlli di policy e approvazioni richieste vengono eseguiti nelle pipeline e bloccano la promozione quando un controllo obbligatorio fallisce.
Dataset di valutazione versionati coprono comportamento atteso, edge case, azioni non sicure, qualità del retrieval, escalation e regressioni.
Ogni release include evidenze approvate, inventario completo delle modifiche, autorizzazione responsabile e piani di recupero testati per configurazione, stato ed effetti esterni.
Tracing, eventi di audit, segnali di qualità, drift, errori di retrieval, incident e feedback umano alimentano il ciclo di miglioramento governato.
Checklist di conformità ADLC
SDLC e ADLC
| Caratteristica | SDLC tradizionale | ADLC |
|---|---|---|
| Esecuzione primaria | Delivery software guidata dalle persone | Delivery coordinata tra persone e agenti, con responsabilità umana esplicita |
| Comportamento | Prevalentemente deterministico e guidato dal codice | Anche non deterministico, adattivo e influenzato dal contesto runtime |
| Superficie di cambiamento controllata | Codice sorgente, configurazione, infrastruttura e dati | Anche prompt, conoscenza e RAG, skill, configurazione del modello, tool e orchestrazione |
| Validazione | Test di codice, integrazione, sistema, sicurezza e accettazione | Gli stessi controlli più valutazioni continue di comportamento, retrieval e regressione |
| Ruolo umano | Autore, reviewer, approvatore e operatore | Progettista, implementatore, operatore, reviewer, approvatore, responsabile dell'escalation e delle decisioni |
| Evidenze | Record di build, test, approvazione e release | Tracciabilità end-to-end dal requisito al comportamento, alle evidenze, alla release e all'operatività |
ADLC in pratica
Nella pratica, l'ADLC non funziona come una pipeline a senso unico. I team entrano attraverso il quality gate dei requisiti, attraversano il delivery e poi rientrano nel ciclo tramite operatività, miglioramento e orchestrazione.
Skill condivise
Le shared skill possono partire da framework consolidati, ma devono essere adattate all'architettura, alle policy, al linguaggio, al modello di rischio e alla cultura di delivery dell'azienda.
Trasformano il know-how riusabile in pattern di esecuzione governati, applicabili in modo coerente da agent e team.
Definisce come documentazione umana e agent context vengono prodotti come artefatti collegati ma separati.
La documentazione umana vive in strumenti progettati per persone. La documentazione per agent viene esposta tramite Agent Context Endpoint governati, come server MCP (Model Context Protocol), file llms.txt, indici di retrieval o context pack versionati.
Gli strumenti per il contesto agentico possono includere Context7, GitMCP, MCPDoc, mcp-documentation-server, server MCP custom basati su SDK MCP open source o sistemi equivalenti. Questi endpoint devono esporre URL stabili, ownership delle fonti, versioning, stato di approvazione e regole di retrieval.
Recuperare solo il contesto approvato necessario al task. Ridurre i token senza eliminare permessi, vincoli, provenienza o evidenze necessarie per una decisione corretta.
Pubblicare contesto riusabile tra progetti e team, evitando copie manuali divergenti e preservando il collegamento alle fonti autorevoli.
Definisce come le fonti di conoscenza e l'agent context vengono selezionati, assegnati a un owner, approvati, strutturati, versionati, pubblicati, testati, tracciati e ritirati.
Copre fonti RAG, context endpoint, conoscenza condivisa, gestione delle contraddizioni, freschezza, valutazione del retrieval, aspettative sulle citazioni, regole di accesso e regression test comportamentali dopo modifiche alla conoscenza.
Contesto runtime e memoria richiedono provenienza, autorizzazioni di scrittura, conservazione, isolamento tra utenti e tenant, cancellazione e gestione delle contraddizioni. I contenuti recuperati non conferiscono autorità. La compressione deve preservare permessi, vincoli ed evidenze decisive.
Definisce come generare, raggruppare, revisionare e adattare le release note per audience tecniche, business e operative.
Include regole per breaking changes, migrazioni, known issues, note di rollback e sintesi customer-facing.
Codifica principi architetturali, criteri decisionali, reference pattern e aspettative di review dell'azienda.
Aiuta gli agent a ragionare con standard locali invece che con consigli architetturali generici.
Codifica convenzioni di piattaforma su ambienti, deployment, osservabilità, rollback, naming, ownership e readiness operativa.
Deve riflettere il modello infrastrutturale reale dell'azienda, non una checklist cloud astratta.
Le skill di sicurezza dovrebbero essere definite o validate dal gruppo CISO e allineate alle policy enterprise.
Esempi: gestione dati, identità, segreti, access control, threat modeling, uso sicuro di prompt/tool ed evidenze di audit.
Definisce dataset rappresentativi, prove ripetute, soglie di accettazione basate sul rischio, verifica di risultati e policy, valutatori calibrati da persone ed evidenze di regressione dopo cambiamenti comportamentali. Collega qualità, costi, latenza e interventi umani alle decisioni di release.
Agenti condivisi
Produce e aggiorna documentazione per persone nella knowledge base umana ufficiale, come Confluence, SharePoint, Notion, GitBook, Backstage TechDocs, Read the Docs o piattaforme equivalenti.
La documentazione umana è ottimizzata per lettura, review, onboarding, governance e auditability. Non è, di default, l'interfaccia di contesto per gli AI agent.
Si occupa di ADR, runbook, onboarding, note architetturali, FAQ e documentazione di processo collegate agli eventi reali di delivery.
Supporta le pull request end-to-end, riassumendo i cambiamenti, verificando le policy, evidenziando i rischi e proponendo i reviewer.
Aiuta a mantenere le review coerenti, tracciabili e allineate ai guardrail condivisi di engineering.
Genera release note a partire dal lavoro integrato, raggruppando funzionalità, fix, breaking changes, migrazioni e note operative.
Produce sia sintesi tecniche sia versioni leggibili per audience business.
Rileva gap tra codice, ticket, release e documentazione, poi propone o applica gli aggiornamenti mancanti.
Mantiene allineate nel tempo la realtà del delivery e la knowledge base.
Revisiona e governa le fonti di conoscenza e di agent context prima che vengano usate dagli agent. Controlla freschezza, ownership, stato di approvazione e versione, duplicazioni, contraddizioni, validità business, tracciabilità, qualità del retrieval e impatto di regressione.
Aiuta a garantire che documenti, context endpoint, contenuti RAG e conoscenza condivisa migliorino il comportamento degli agent senza introdurre cambiamenti non controllati.
Collega requisiti, implementazioni, test, documentazione e release in una catena auditabile di evidenze.
Supporta quality gate, review e checkpoint di governance lungo tutto il lifecycle.
Verifica che ogni release abbia runbook, ownership, rollback guidance, alert ed evidenze di prontezza operativa.
Aiuta i team a passare dal deploy a un'operatività stabile con meno punti ciechi.
Capacità di tooling
Questa mappa ADLC raggruppa capacità di tooling a supporto dei suoi controlli, facendo riferimento a standard e pratiche tecniche consolidate ed emergenti. Non è una tassonomia normativa né uno stack obbligatorio: uno strumento può coprire più capacità e i servizi aziendali esistenti possono essere riutilizzati. Scegliere le implementazioni in base all'ambito approvato, al rischio e all'architettura.
Il retrieval serve solo quando il sistema recupera conoscenza esterna; i workflow persistenti sono appropriati quando l'esecuzione deve sopravvivere alle interruzioni o coordinare azioni di lunga durata. Un gateway multi-provider è opzionale quando serve centralizzare l'accesso ai modelli o il routing. Questi componenti non sostituiscono il quality gate dei requisiti né la supervisione umana responsabile.
I riferimenti supportano le capacità sottostanti, non questa specifica classificazione né la conformità ADLC. Standard e framework descrivono processi o controlli; la ricerca studia metodi specifici; la documentazione tecnica illustra implementazioni.
| Capacità | Cosa serve utilizzare | Controllo da dimostrare |
|---|---|---|
| Requisiti e tracciabilità Standard: ISO/IEC/IEEE 29148 | Un registro dei requisiti collegato a decisioni, test e release. | Ambito approvato, criteri di accettazione misurabili, responsabilità e quality gate superato. |
| Versionamento e delivery Framework: NIST SSDF | Controllo versione, archivio degli artefatti e pipeline di delivery automatizzate. | Modifiche revisionabili a codice, prompt, skill e configurazione; promozione bloccata se falliscono controlli obbligatori. |
| Conoscenza, contesto e documentazione Documentazione tecnica: Context engineering | Documentazione per persone e un'interfaccia separata per il contesto degli agent, catalogo delle fonti, indice di retrieval e policy della memoria dove necessari. | Ownership, approvazione, provenienza, aggiornamento, accessi, conservazione e cancellazione delle fonti; il contesto deve preservare i vincoli. |
| Identità e accessi delegati Standard: RFC 8693 | Gestione delle identità, identità di servizio, controlli di autorizzazione e gestione dei segreti. | Chi agisce, per conto di chi e con quali permessi; privilegio minimo, delega limitata, scadenza e revoca. |
| Policy runtime e limiti di consumo Documentazione tecnica: Policy enforcement Documentazione tecnica: Gateway budgets | Applicazione delle policy al confine dei tool, contatori di utilizzo, quote e controlli di arresto. | Limiti su azioni, spesa, durata, chiamate e tentativi; le azioni vietate vengono bloccate, non solo registrate. |
| Orchestrazione e recupero Documentazione tecnica: Durable execution | Controlli di esecuzione e procedure di recupero; un motore di workflow persistente dove servono ripresa o coordinamento di azioni di lunga durata. | Ripresa dell'esecuzione, idempotenza, condizioni di arresto, riconciliazione dello stato e compensazioni autorizzate. |
| Revisione umana Framework: NIST AI 600-1 | Una coda di revisione con evidenze, assegnazione a reviewer autorizzati, scadenze ed escalation. | Reviewer formati possono contestare o fermare le azioni; l'approvazione è legata all'azione esatta, con evidenze della decisione e senza approvazione implicita alla scadenza. |
| Valutazione comportamentale Documentazione tecnica: Agent evaluations | Dataset di test versionati, motori di valutazione, test avversariali e calibrazione umana. | Prove ripetute, risultati effettivi, rispetto delle policy, soglie basate sul rischio e gate di regressione. |
| Osservabilità, costi e risultati Documentazione tecnica: OpenTelemetry GenAI | Tracce, metriche, alert, contabilizzazione dei costi e dashboard operative. | Deriva comportamentale, errori di retrieval, costo per task riuscito, latenza, interventi umani e risultati di business. La sola telemetria non dimostra il valore di business; valutare i risultati rispetto a una baseline approvata. |
| Audit e gestione degli incidenti Documentazione tecnica: Decision logs Framework: NIST SP 800-61r3 | Archivio protetto delle evidenze, flussi di gestione degli incidenti e runbook operativi. | Ricostruire decisioni e cambiamenti, gestire incidenti, testare il recupero e dismettere accessi e dati secondo policy. |
| LLM Gateway e routing dei modelli Ricerca: RouteLLM Documentazione tecnica: LLM gateway | Dove necessario, un gateway multi-provider con routing valutato, policy sui token in ingresso e in uscita, caching e controllo dei consumi. | Scelta di modelli approvati, evidenze separate dei consumi input/output, spesa limitata e ottimizzazione che preservi la qualità. |
Verificare SSO (Single Sign-On) e ruoli, isolamento tra tenant, conservazione e cancellazione, evidenze di audit esportabili, hosting e residenza dei dati, supporto operativo e integrazione con i controlli esistenti. La sola licenza open source non garantisce l'adeguatezza.
Esempi di tooling enterprise
Gli esempi non sono normativi. Usare un prodotto non rende da solo un team conforme all'ADLC: controlli, evidenze, ownership e decisioni responsabili restano obbligatori.
| Capability | Tool | Uso enterprise | Stato open source | URL |
|---|---|---|---|---|
| Requisiti e approvazioni | Jira | Requisiti strutturati, workflow, approvazioni, ownership e record di tracciabilità. | No - commerciale | https://www.atlassian.com/software/jira |
| Delivery e gate di evidenza | GitLab | Controllo versione, review, CI/CD, policy gate, controlli di sicurezza ed evidenze di release. | Open core - CE è MIT; le funzioni enterprise sono proprietarie | https://about.gitlab.com/ |
| Test comportamentali | promptfoo | Valutazioni di prompt, RAG, agent e red teaming eseguibili localmente o nelle pipeline CI. | Sì - progetto MIT; offerta enterprise commerciale | https://www.promptfoo.dev/ |
| Tracing e valutazione | Langfuse | Tracing, gestione dei prompt, dataset di valutazione, esperimenti e feedback dalla produzione. | Open core - il core è MIT; gli add-on enterprise sono commerciali | https://langfuse.com/ |
| Decisioni di policy | Open Policy Agent | Policy-as-code per gate di delivery e autorizzazioni runtime. Il servizio o gateway integrato deve applicare le decisioni; i decision log supportano la tracciabilità. | Sì - Apache-2.0 | https://www.openpolicyagent.org/ |
| Documentazione umana | Backstage TechDocs | Catalogo software e docs-as-code per le persone, integrati con l'ownership ingegneristica. | Sì - Apache-2.0 | https://backstage.io/docs/features/techdocs/ |
| Contesto tecnico per coding agent | Context7 | Documentazione di librerie ed esempi di codice coerenti con la versione tramite MCP e CLI. Un esempio di distribuzione del contesto tecnico, non una piattaforma completa di governance di tutta la conoscenza aziendale. | Parziale - il server MCP è MIT; il backend hosted è privato | https://context7.com/ |
| Esecuzione persistente dei workflow | Temporal | Workflow persistenti, recupero dai guasti e coordinamento di attese e approvazioni. Idempotenza e compensazione degli effetti esterni devono comunque essere progettate. | Sì - server MIT; servizio cloud commerciale | https://github.com/temporalio/temporal |
| Segreti e credenziali temporanee | OpenBao | Segreti centralizzati, credenziali dinamiche per i sistemi supportati, scadenza e revoca. Supporta l'accesso a privilegio minimo senza inserire credenziali nei prompt. | Sì - MPL-2.0 | https://github.com/openbao/openbao |
| Ownership e provenienza delle fonti | OpenMetadata | Catalogo dei metadati, ownership, segnali di qualità, tracciabilità delle derivazioni e analisi di impatto per un contesto dati governato. Integra, senza sostituirli, approvazione della conoscenza e test comportamentali. | Sì - progetto Apache-2.0 | https://github.com/open-metadata/OpenMetadata |
Arize Phoenix: Arize Phoenix è un'alternativa per tracing, valutazione del retrieval, esperimenti e diagnostica comportamentale. È source-available con licenza ELv2, non open source approvato OSI. Licenza.
LangGraph: LangGraph è un framework opzionale con licenza MIT per agent con stato, checkpoint e sospensione/ripresa per la revisione umana. Non è una piattaforma completa di governance: interfaccia di revisione, competenza dei reviewer, autorizzazioni e policy di approvazione devono comunque essere implementate.
Sono esempi di capacità, non uno stack obbligatorio né una garanzia di conformità ADLC. Scegliere solo i componenti necessari per l'ambito approvato e verificare licenze e requisiti operativi della specifica edizione.
LLM Gateway
Un LLM Gateway deve governare l'accesso a più provider e instradare ogni task verso il modello approvato più adatto, bilanciando qualità valutata, rischio, latenza, disponibilità e costo. Il solo bilanciamento del carico o la scelta del modello più economico non ne dimostrano l'adeguatezza al task.
| Gateway / fonti ufficiali | Licenza / offerta | Routing multi-provider | Controlli su token e consumi |
|---|---|---|---|
| LiteLLM Documentazione | Core open source: MIT; moduli enterprise con licenza separata. | Strategie per costo/latenza e fallback tra provider. | Caching e limiti d'uso; configurare i parametri dei token di output e l'eventuale riduzione del contesto. |
| Portkey AI Gateway Documentazione | Gateway open source: MIT; offerte hosted/enterprise separate. | Routing multi-provider, bilanciamento e fallback. | Caching; ottimizzazioni avanzate secondo l'edizione. Validare limiti di output e policy del contesto. |
| Kong AI Gateway Documentazione | Funzioni AI avanzate commerciali; verificare edizione e licenze dei plugin. | Routing multi-provider e semantico tramite plugin configurati. | Cache semantica, limiti di token/costo; la compressione richiede un servizio. Configurare separatamente i limiti di output. |
| Cloudflare AI Gateway Documentazione | Servizio gestito proprietario; verificare i limiti del piano. | Routing condizionale, scelta dei modelli, fallback e budget. | Caching e quote di costo; limiti di generazione secondo i parametri del provider. La riduzione del contesto richiede integrazione. |
Prima i gateway open source, poi i servizi commerciali. Sono esempi, non raccomandazioni obbligatorie né uno stack richiesto. Nessuna riga implica il supporto automatico di tutte le policy input/output: verificare versione installata, compatibilità dei provider ed edizione, inclusi streaming e rispetto dei budget con richieste concorrenti.
Link utili
Riferimenti durevoli per rischio enterprise, responsabilità, sicurezza e governance del ciclo di vita.
| Risorsa | Descrizione | Link |
|---|---|---|
| NIST AI Risk Management Framework | Framework vendor-neutral per gestire rischi e affidabilità dell'AI lungo progettazione, sviluppo, rilascio, utilizzo e valutazione. | nist.gov/ai-rmf |
| NIST Generative AI Profile | Profilo complementare che applica l'AI RMF ai rischi e ai controlli del ciclo di vita dell'AI generativa. | nist.gov/genai-profile |
| ISO/IEC 42001 | Standard internazionale per sistemi di gestione dell'AI, con policy, responsabilità, controlli del rischio e miglioramento continuo. Lo standard completo è commerciale. | iso.org/standard/42001 |
| MITRE ATLAS | Knowledge base evolutiva di tattiche e tecniche avversarie contro sistemi AI, incluse minacce agentiche e mitigazioni. | atlas.mitre.org |
| OWASP Agentic AI Threats and Mitigations | Tassonomia basata sul threat modeling e indicazioni di mitigazione per sistemi AI autonomi e agentici. | genai.owasp.org |
| OWASP State of Agentic AI Security and Governance | Report sullo scenario corrente della sicurezza e governance agentica, utile come lettura di contesto e non come standard normativo. | genai.owasp.org/state-of-agentic-ai |
Specifiche aperte per integrare il contesto, rendere interoperabili gli agent e produrre evidenze operative portabili.
| Risorsa | Descrizione | Link |
|---|---|---|
| Model Context Protocol | Protocollo aperto per collegare applicazioni agentiche a tool, fonti dati e servizi di contesto governati. | modelcontextprotocol.io |
| Agent2Agent Protocol | Standard aperto Apache-2.0 per discovery, interazione sicura e collaborazione tra sistemi agentici indipendenti. | a2a-protocol.org |
| OpenTelemetry GenAI Semantic Conventions | Convenzioni Apache-2.0 per tracce, metriche ed eventi portabili relativi a retrieval, tool call, MCP ed esecuzione degli agent. | github.com/open-telemetry/semantic-conventions-genai |
Risorse implementative che i team devono valutare rispetto ai propri controlli, piattaforme e modelli di rischio.
| Risorsa | Descrizione | Link |
|---|---|---|
| Microsoft APM | Dependency manager con licenza MIT per distribuire istruzioni, skill, plugin e server MCP portabili, versionati e governati da policy. | github.com/microsoft/apm |
| Superpowers | Framework open source di skill e metodologia di delivery per design, planning, TDD, review e sviluppo assistito da agent. | github.com/obra/superpowers |
| GitHub Copilot Token Optimization | Guida community specifica per prodotto, dedicata alla riduzione del contesto e del consumo di token senza compromettere la qualità della delivery. | github.com/olivomarco/github-copilot-token-optimization |
| Termine | Nome esteso / concetto | Significato nell'ADLC |
|---|---|---|
| ADLC | Agentic Development Lifecycle | Ciclo di vita dei sistemi agentici che estende l'SDLC con la governance di comportamento, contesto e autonomia. |
| SDLC | Software Development Lifecycle | Disciplina del ciclo di vita del software, dai requisiti al rilascio, all'operatività e alla dismissione. |
| AI | Artificial Intelligence | Capacità di intelligenza artificiale utilizzate nel sistema e soggette agli stessi controlli di governance. |
| LLM | Large Language Model | Modello linguistico usato dagli agent; versione e configurazione influenzano il comportamento e richiedono validazione. |
| RAG | Retrieval-Augmented Generation | Recupero di informazioni esterne a supporto della generazione; opzionale, con fonti governate e test del retrieval. |
| MCP | Model Context Protocol | Protocollo per collegare applicazioni AI a strumenti e contesto; non sostituisce autorizzazione o governance. |
| CI/CD | Continuous Integration / Continuous Delivery or Deployment | Integrazione continua e delivery o deployment continuo, con controlli obbligatori prima della promozione. |
| IAM | Identity and Access Management | Gestione di identità e permessi, incluse identità di servizio e deleghe limitate. |
| SSO | Single Sign-On | Autenticazione unica tra servizi; da sola non autorizza l'esecuzione di azioni. |
| Human in the Loop | HITL | Revisione umana competente e responsabile nei checkpoint critici, con evidenze e autorità di intervento. |
| Quality gate | Quality gate | Controllo di ingresso o promozione basato su evidenze; il gate dei requisiti deve essere superato prima dell'implementazione. |
| Agent context | Agent context | Informazioni disponibili all'agent per un task: istruzioni, fonti recuperate, strumenti e memoria. |
| Guardrail | Guardrail | Controllo preventivo o di rilevamento che limita comportamenti non sicuri o non autorizzati; i limiti critici richiedono enforcement runtime. |
| Orchestration | Orchestration | Coordinamento di agent, strumenti, stato e workflow entro permessi e budget approvati. |
| Context engineering | Context engineering | Selezione e composizione del contesto operativo; integra, senza sostituirla, la governance della conoscenza. |