Eval e acceptance per contractor AI nel B2B

Mindset di acceptance: quality bar, non vibes

Tratta le feature LLM come qualsiasi altro subsystem ad alto rischio: soglie misurabili, test automatici, security case e handover operativo. 'Sta bene in demo' non è un gate. Separa gli spike di research dai milestone di produzione. Gli spike possono esplorare; i milestone devono soddisfare criteri di eval, ACL, audit e runbook. Allinea la delivery a strategia di testing e production readiness.

• Scrivi l'acceptance prima che inizi il build
• Includi failure e abuse case, non solo happy path
• Richiedi run di eval riproducibili su un golden set fisso
• Gate del go-live sulle soglie, non sulle slide

Golden set che riflettono utenti reali

Costruisci un set versionato di input con outcome attesi: risposte più citazioni richieste per RAG, field extraction, classificazioni o traiettorie agent end-to-end. Copri persona e tenant che servi davvero. Includi vuoti, conflitti, injection avversarie e richieste out-of-scope. Gli esperti di dominio devono revisionare le label; gli engineer da soli perderanno sfumature di policy. Per lavoro RAG-heavy, segui le pratiche di evaluation in RAG in produzione. Per gli agent, scripta outage tool e reject di approvazione come in workflow agentic.

Soglie di eval e gate di release

Punteggia separatamente retrieval hit rate, correttezza delle citazioni, faithfulness, task success e tasso di azioni non sicure. Imposta minimi per environment: lo staging deve passare prima del traffico di produzione. Regredisci a ogni bump di prompt, modello, chunker, reranker o versione di grafo. Blocca i merge quando le soglie calano, come per integration test flaky. Pubblica chi può waiverare un gate e per quanto. Waiver permanenti sono come le demo diventano debito di produzione.

• Definisci metriche e owner nello SOW
• Conserva i report di eval come artefatti di release
• Richiedi shadow o cohort limitata prima del cutover pieno
• Traccia costo per successo insieme ai quality gate

Demo vs produzione: chiudi i gap

Le demo spesso usano documenti curati, dati single-tenant, tool god-mode e nessun budget di latenza. La produzione serve ACL, audit, write idempotenti, osservabilità e runbook di support. Elenca esplicitamente gli shortcut di demo nel project plan e la data di paydown. Se uno shortcut resta al go-live, è rischio accettato con un owner—oppure non è done. Scope della prima vertical con prioritizzazione MVP e discovery via technical discovery.

Test ACL e security che i contractor devono passare

Tentativi automatici di retrieval e tool cross-tenant. Logging dei denial. Casi di prompt injection via documenti e ticket. Reject di schema su argomenti tool fuori range. Nessun service role condiviso che bypassa i permessi di prodotto. Principal legati a SSO per agent user-facing. Vedi sicurezza AI enterprise e SSO e identity. Tratta un test ACL fallito come ship blocker equivalente a un bug di data breach in una API normale.

Osservabilità, audit e runbook

L'handover include trace (run ID, ID di retrieval, tool, approvazioni), dashboard, alert e runbook: reindex, rollback di versione prompt/grafo, kill switch, outage vendor e risposta a spike di costo. Allinea i log a audit logging e le ops a osservabilità e SLA di support. Se solo il contractor sa interpretare i failure, non possiedi la feature.

• Documenta gli step on-call per incident AI
• Includi ownership di dati/corpus e cadenza di refresh
• Consegna l'eval harness e come estendere il golden set
• Registra setting del vendor modello e gestione dei secret

Linguaggio contrattuale che protegge entrambe le parti

Definisci i deliverable come sistemi che rispettano soglie, non ore di prompt tinkering. Indica environment, accesso ai dati, IP di prompt/grafi/eval set e confidenzialità dei corpora cliente. Il fixed price sta bene per MVP ben delimitati con gate chiari; il T&M sta bene per esplorazione con demo settimanali contro il golden set. Vedi fixed price vs time and materials. Includi change control quando qualità del corpus o API sono peggiori di quanto assunto in discovery—spesso il vero rischio di schedule. Bilancia con range di costo realistici e unit economics in mente.

Acceptance di human-in-the-loop e write path

Se la feature può scrivere sui system of record, l'acceptance include UX di approvazione, evidenze sulla card, comportamento di timeout, idempotenza e compensation su failure parziali. Draft-only può essere un milestone; le write non supervisionate richiedono bar più alti. Le aspettative di prodotto vivono in prodotti AI human-in-the-loop. Path ERP e denaro ereditano anche la disciplina di integrazione ERP: nessun agent ha un free pass sull'idempotenza.

Prossimi passi

Bozza di una checklist di acceptance di una pagina: size del golden set, metriche, test ACL, campi di audit, runbook e kill switch. Allega allo SOW prima del kickoff. Continua con data readiness, altre risorse, case study, prenota una call o contatti per rivedere le proposte dei contractor prima di finanziare un engagement solo-demo.

Domande frequenti