01 · La premessa
Se un agente in produzione non si può debuggare come un microservizio, non è in produzione. È una demo che vive su un server.
L'AI generativa è diventata una primitiva di sistema. Non è più una sezione separata dell'architettura — è una libreria che gestisci come gestisci Postgres: con monitoring, con SLO, con rollback, con governance.
Il nostro approccio applica XP al dominio AI: piccoli rilasci di prompt, eval suite come test, refactor continuo del catalogo di prompt, integrazione continua delle valutazioni in CI.
E applichiamo Extreme Contracts: ogni capability AI ha precondizioni dichiarate (input shape, sicurezza dei dati), postcondizioni verificabili (eval gates, latency budget, accuracy floor) e fallback espliciti per il caso in cui il modello fallisca.
04 · Il contratto
Precondizioni, postcondizioni, invarianti.
Ogni engagement ha precondizioni esplicite, postcondizioni misurabili e invarianti che non violiamo. Sai cosa serve all'inizio, cosa esce alla fine, e cosa non negoziamo nel mezzo.
Precondizioni / cosa serve da te
- Use case validato: un utente finale reale che userà il sistema, non un esperimento da CMO.
- Accesso ai dati di dominio (con clearance privacy/legal) o ad un dataset rappresentativo.
- Budget di inference dichiarato: serve per dimensionare l'architettura.
- Tolleranza all'errore concordata: cosa succede quando il modello sbaglia? Quanto sbagliare è accettabile?
Postcondizioni / cosa garantiamo
- Sistema AI in produzione con eval gate in CI: nessun deploy senza eval pass.
- Dashboard live di accuracy, latency, cost, safety.
- Runbook operativo: come si gestisce un drift di performance, un'escalation di costi, un incidente di safety.
- Stack di prompt + eval + tooling versionato e nel repository del cliente.