Come Valutare un Fornitore di AI Agent Prima di Firmare

Valuti i fornitori di AI agent in base a come gestiscono gli errori, non in base alla loro demo. Una demo curata dimostra solo che l'agent sa gestire i cinque input che il team commerciale ha provato. Non dice nulla su cosa succede al sesto input, quando un cliente scrive qualcosa di inatteso, carica un file corrotto, o chiede all'agent qualcosa che non rientrava nello scope originale. I fornitori che vale la pena assumere sanno rispondere a questa domanda nel dettaglio. Quelli che non sanno farlo Le presenteranno il conto della manutenzione in un secondo momento.

Ecco la checklist che utilizzeremmo se fossimo noi gli acquirenti.

Architettura e design

1. Perché avete scelto un approccio ad agent invece di un workflow più semplice? I loop agentici con più chiamate LLM e catene di tool-calling sono più lenti, più costosi e più difficili da diagnosticare rispetto a una singola chiamata ben strutturata. Lo abbiamo imparato direttamente sviluppando il nostro strumento di outreach: la prima versione concatenava quattro step (plan, extract, draft, revise) e costava di più per ogni email rispetto alla versione a chiamata singola che abbiamo poi rilasciato, producendo per giunta copy peggiori. Un fornitore dovrebbe essere in grado di fornirLe lo stesso tipo di ragionamento prima/dopo per la propria architettura, senza ricorrere per default a più agent solo perché "agent" si vende meglio di "script." Legga il confronto in AI agents vs. workflows prima del primo incontro, così da poter contestare le risposte vaghe.

2. Potete mostrarmi la versione più semplice che funzionerebbe? Nel nostro strumento di outreach, facciamo lo scraping del sito di ogni prospect con un'istanza self-hosted di Firecrawl e un modello locale, poi generiamo l'email in una singola chiamata che estrae i fatti rilevanti e scrive il pitch simultaneamente. Abbiamo provato prima una catena multi-step — plan, poi extract, poi draft, poi revise — e costava di più per ogni email producendo copy peggiori, perché ogni passaggio introduceva una nuova possibilità di deviare dal materiale di partenza. Se la risposta predefinita di un fornitore a qualsiasi problema è "più agent, più step", è il segnale che sta ottimizzando per la complessità fatturabile, non per il suo risultato. Confronti le note in single-call vs. agent chains.

3. A quali strumenti e dati ha accesso l'agent, e perché? Ogni tool che l'agent può chiamare rappresenta un potenziale raggio d'azione in caso di errore. Un agent di supporto che può emettere rimborsi richiede guardrail molto più stringenti rispetto a uno che può solo preparare una bozza di risposta per l'approvazione umana. Chieda al fornitore di illustrare il modello dei permessi, non solo l'elenco delle funzionalità.

Qualità e valutazione

4. Come misurate se l'agent sta effettivamente funzionando? "Lo testiamo prima del lancio" non è una risposta. Quello che serve è un eval set ripetibile: una raccolta fissa di input reali (o realistici) su cui il fornitore esegue l'agent, con criteri di pass/fail concordati tra entrambe le parti. Senza questo, ci si affida alle sensazioni, e le sensazioni non reggono quando il provider del modello rilascia un aggiornamento silenzioso. Questo dovrebbe essere una voce esplicita del contratto, non una promessa verbale, come indicato in evals in AI vendor contracts.

5. Cosa succede quando l'agent è sicuro di sé ma sbaglia? Ogni sistema basato su LLM produce a volte risposte sicure, fluenti e sbagliate. Chieda specificamente come il design del fornitore intercetta questo problema: se tramite una soglia di confidenza che instrada verso un operatore umano, un secondo modello che verifica il primo, o guardrail hard-coded per le azioni ad alto rischio. Se la risposta è "il modello è abbastanza accurato", continui a chiedere.

6. Posso vederlo fallire deliberatamente? Chieda al fornitore di eseguire tre input scelti da Lei, dal vivo, sul momento, incluso almeno uno che dovrebbe essere rifiutato o escalato invece di ricevere una risposta. Ci vogliono dieci minuti e dice più di una settimana di lettura di proposte.

Costi e ownership

7. Qual è il costo unitario per interazione e come scala? I costi dei token, le chiamate ai tool e le eventuali tariffe di API di terze parti (speech-to-text, ricerca, embeddings) dovrebbero convergere in un numero per conversazione o per task, suddiviso per step, non solo in una media aggregata. Questa scomposizione è esattamente ciò che ha evidenziato il problema nel nostro strumento di outreach: una volta calcolato il costo della catena step per step, i passaggi aggiuntivi di plan/extract/revise stavano chiaramente aumentando il costo per email senza migliorarne la qualità, ed è questo che ci ha spinti a tornare alla chiamata singola. Un fornitore che non sa fornire questo tipo di numero step per step non ha effettivamente testato le performance del proprio sistema.

8. Chi possiede il codice, i prompt e gli eval al termine dell'ingaggio? Questo deve essere esplicito nel contratto. Se il fornitore trattiene i prompt, l'eval set o i pesi fine-tuned, Lei sarà vincolato a pagargli ogni modifica futura, indipendentemente da come procede il rapporto.

9. Come sarà il secondo mese, dopo il lancio? I modelli vengono aggiornati, emergono edge case e i prompt si desincronizzano con il prodotto. Chieda quanto costa la manutenzione continuativa, chi è reperibile per gestirla e cosa è incluso rispetto a ciò che viene fatturato separatamente. Abbiamo scritto un'analisi dettagliata in what AI agent maintenance actually costs se vuole i dettagli prima di negoziare.

10. Prezzo fisso o tempo e materiali, e perché per questo progetto? Nessuno dei due è universalmente più sicuro. Il prezzo fisso funziona quando il task è ben definito e i casi di errore sono noti. Il tempo e materiali si adatta meglio quando si sta ancora scoprendo cosa significa "funzionante". Un fornitore che propone sempre lo stesso modello indipendentemente dalla natura del progetto sta ottimizzando per il proprio rischio, non per il suo. Approfondisca il confronto in fixed-price vs. time and materials.

Sicurezza e gestione dei dati

11. Dove vanno i dati dei clienti e chi può vederli? Se l'agent chiama un'API di modello di terze parti, chieda esattamente cosa viene inviato, se i dati vengono utilizzati per il training e dove vengono registrati. Questo è ancora più rilevante per tutto ciò che riguarda dati sanitari, dati finanziari o PII. Scorra l'elenco completo in the AI agent security checklist.

12. Qual è il piano di rollback se qualcosa va storto in produzione? Un kill switch, un modo per instradare tutto verso un operatore umano, uno storico versionato dei prompt a cui tornare. Se il fornitore non ha pensato a questo, sarà Lei ad improvvisare durante un incidente.

Come leggere la proposta stessa

Faccia attenzione agli stessi segnali d'allarme che compaiono in qualsiasi progetto software: scope vago, nessuna indicazione su chi testa cosa, timeline che non tengono conto delle iterazioni. I progetti di AI agent amplificano questi rischi perché l'output è probabilistico, quindi l'ambiguità nel contratto diventa ambiguità nel comportamento in produzione.

Tre proposte sono in genere sufficienti per confrontare le scelte architetturali e la filosofia di pricing, senza trasformare la selezione in un lavoro a tempo parziale. Faccia le stesse dodici domande a ciascun fornitore, e presti più attenzione a chi risponde "dipende" spiegando il perché, piuttosto che a chi ha il deck più curato.

Se sta valutando fornitori per lo sviluppo di un AI agent e desidera un secondo parere su una proposta, parliamone.