Come fare un briefing a un'agenzia AI affinché il preventivo sia davvero preciso

Un preventivo accurato per un progetto AI su misura nasce da un brief che risponde a cinque domande: quale risultato di business si vuole ottenere, quali dati si hanno realmente a disposizione, quanto costa una risposta sbagliata, quali sistemi l'agente deve leggere e scrivere, e quali vincoli sono non negoziabili. Tutto il resto — il modello, il framework, se si tratta di "un agente" o "un workflow" — è compito dell'agenzia proporre. I founder che inviano un problem statement di due pagine ricevono un numero. Quelli che inviano una lista di funzionalità o un generico "vogliamo l'AI nel nostro prodotto" ricevono una forbice così ampia da essere inutile, oppure un'offerta al ribasso che viene rinegoziata al secondo mese.

Perché la maggior parte dei brief AI produce preventivi scadenti

Un'agenzia software prezza il rischio. Ogni elemento sconosciuto nel brief si traduce in una stima gonfiata o in una ottimistica che cede quando arrivano i dati reali. I progetti AI hanno più incognite del software ordinario perché la parte difficile è raramente il codice. La parte difficile sono i dati, i casi limite e decidere quanto basta.

I tre errori più comuni che rileviamo nei brief:

• Soluzione al posto del problema. "Costruisci un chatbot RAG sulla nostra documentazione con GPT e un database vettoriale." L'agenzia deve ora ricostruire a ritroso ciò di cui ha davvero bisogno, e spesso il design prescritto è quello costoso. Lo abbiamo vissuto in prima persona: la catena multi-step che avevamo ipotizzato per il nostro motore di outreach è stata superata da una singola chiamata, sia per costo che per qualità, e un brief che avesse prescritto quella catena ci avrebbe bloccato sul design peggiore. Spieghiamo perché questo è rilevante in RAG vs fine-tuning per i founder.
• Nessuna definizione di "corretto". "Dovrebbe rispondere accuratamente alle domande dei clienti." Accuratamente rispetto a cosa? Chi verifica? Cosa succede quando sbaglia? "Giusto nove volte su dieci e segnala il resto a un essere umano" è una definizione. "Accurato" non lo è.
• Integrazioni citate di sfuggita. "Dovrebbe anche aggiornare il CRM." Questa frase può raddoppiare un progetto. Un agente che abbozza una nota nel CRM per un umano che la approva e uno che modifica le fasi di trattativa autonomamente sono build differenti, e il brief di solito non specifica quale si intende. Autenticazione, rate limit, mappatura dei campi e gestione degli errori per un sistema di terze parti sono lavoro reale.

Correggere questi tre punti avvicinerà il preventivo ricevuto a quanto si pagherà effettivamente.

Le cinque sezioni di cui ha bisogno il suo brief

1. Il risultato, in termini di business

Un paragrafo. Non "un assistente AI" ma "ridurre il tempo di prima risposta sulle richieste di supporto in entrata da ore a meno di due minuti, senza aumentare le escalation al team umano." Un risultato misurabile permette all'agenzia di proporre il design meno costoso che lo raggiunge, invece di quello più impressionante.

Includa i volumi. Cinquanta richieste al giorno e cinquantamila al giorno sono sistemi diversi con strutture di costo diverse. Se non lo sa, fornisca la sua stima migliore e dica che è una stima.

2. I dati che ha realmente a disposizione

Questa sezione incide sul prezzo più di qualsiasi altra. Sia specifico e onesto:

• Dove risiedono. Postgres, un Google Drive pieno di PDF, un CRM legacy con un pulsante di esportazione, conversazioni WhatsApp sul telefono di qualcuno.
• Quanti e quanto sono puliti. Diecimila record ben strutturati è un lavoro diverso da duecento moduli scansionati in tre lingue.
• Chi li possiede e se contengono dati personali. Se il progetto riguarda dati di residenti nell'UE, lo specifichi. L'agenzia deve progettare per il GDPR fin dal primo giorno, non aggiungerlo a posteriori.

Alleghi un campione anonimizzato. Venti righe o dieci documenti sono sufficienti. Nessuna agenzia seria può stimare il lavoro di estrazione o recupero dati dalla descrizione a parole, e chi afferma di poterlo fare sta indovinando.

3. Il costo di una risposta sbagliata

Questa è la domanda che i founder saltano e che le agenzie hanno più bisogno di vedere risposta. Una funzionalità AI che suggerisce tag per i blog può sbagliare un quarto delle volte senza conseguenze. Un agente che quota prezzi ai clienti o archivia richieste assicurative non può permetterselo.

Indichi, in linguaggio chiaro:

• Cosa succede quando l'output è sbagliato. Un danno reputazionale, un rimborso, un problema normativo, un problema di sicurezza per il paziente.
• Chi lo rileva oggi. Un revisore umano, nessuno, il cliente.
• Quale tasso di errore accetterebbe al lancio. Anche una cifra approssimativa aiuta. "Se è giusto nove volte su dieci e segnala il resto a un umano, è meglio di quello che abbiamo."

Questa singola sezione determina se l'agenzia progetterà un sistema economico con un umano nel loop o uno costoso con verifica a più livelli. Il nostro articolo sui guardrail deterministici per le funzionalità AI spiega perché il secondo tipo costa di più e quando ne vale la pena.

4. I sistemi che l'agente deve utilizzare

Elenchi ogni sistema da cui l'AI deve leggere o su cui deve scrivere, e per ciascuno: se dispone di accesso API, chi lo amministra e se esiste un ambiente sandbox. Scrivere è più costoso che leggere. Un agente che abbozza una nota nel CRM per un umano che la approva è un progetto più piccolo di uno che aggiorna autonomamente le fasi di trattativa.

Se un sistema non ha API, lo dica. L'automazione tramite browser e lo screen scraping sono possibili, ma sono una voce di costo separata e si rompono più spesso.

5. Vincoli non negoziabili

Elementi su cui l'agenzia non può transigere:

• Residenza dei dati. Devono rimanere nell'UE, in Arabia Saudita, sui propri server.
• Budget per richiesta o per mese. Un tetto sul costo di inferenza orienta immediatamente la scelta del modello.
• Latenza. Una risposta su WhatsApp può richiedere quattro secondi. Un agente vocale no.
• Tempistiche e motivazioni. La data di una fiera è un vincolo reale. "Il prima possibile" non lo è.
• Requisiti legali o di disclosure. Se i clienti devono essere informati che stanno parlando con una macchina, lo specifichi.

Mantenga questa lista corta. Ogni elemento rimuove opzioni progettuali, e alcune di quelle opzioni erano le più economiche.

Cosa omettere

L'architettura. Non specifichi il modello, il database vettoriale, il framework di orchestrazione o il numero di step della pipeline. Quando abbiamo costruito il nostro motore di outreach — che scansiona il sito di ogni prospect con un crawler self-hosted e abbozza un'email personalizzata con un modello locale — il nostro punto di partenza era una catena multi-step: una chiamata per estrarre i fatti, un'altra per pianificare, un'altra per scrivere. La versione che ha vinto per costo e qualità era una singola chiamata che estraeva i fatti e abbozzava l'email insieme. Se un cliente avesse prescritto la catena nel brief, avremmo costruito il sistema peggiore e addebitato di più. Lasci che sia l'agenzia a proporre, poi metta in discussione la proposta.

Una lunga lista di funzionalità. Le funzionalità senza priorità vengono prezzate come tutte obbligatorie. Se deve elencarle, ne marchi tre come critiche per il lancio e il resto come successive.

Screenshot della concorrenza come specifica. Utili come riferimento, pericolosi come requisiti. Si finisce per pagare per replicare i compromessi di qualcun altro.

Cosa farà una buona agenzia con il suo brief

Riprendendo l'esempio del supporto della prima sezione: un brief che dice "meno di due minuti alla prima risposta, volume attuale di circa cinquecento ticket al giorno, giusto nove volte su dieci con il resto segnalato a un umano, deve abbozzare ma non inviare, solo dati UE" dovrebbe ricevere, entro una o due settimane, una proposta che risponde esattamente a queste righe: un approccio raccomandato con le motivazioni, uno scope pilota (magari una categoria di ticket, solo bozze), un costo suddiviso tra build, inferenza al volume indicato e manutenzione continuativa, e un metodo proposto per misurare il target dei due minuti e il tasso di errore di uno su dieci prima di pagare per la build completa. Se la risposta è un numero unico senza ipotesi elencate, l'agenzia non ha letto il brief. Se è un deck di trenta pagine che non menziona mai il suo campione di dati, stessa conclusione.

Si aspetti anche domande di ritorno. Le buone agenzie approfondiscono la sezione sul costo dell'errore e sulle integrazioni, perché è lì che si concentra il rischio di stima reale. Si aspetti di essere chiesto chi revisiona oggi il decimo segnalato e se il CRM ha un ambiente sandbox. Le agenzie che non chiedono nulla o hanno molta esperienza con il suo problema esatto, oppure stanno pianificando di scoprire i problemi sulla sua fattura.

Prima di firmare, utilizzi come valutare la demo di un'agenzia AI per mettere sotto pressione ciò che le viene mostrato, e si assicuri che la metrica di successo della prima sezione sia riportata nel contratto. Concordare come il sistema verrà valutato prima dell'inizio della build è la polizza assicurativa più economica che possa acquistare.

Un template da copiare

```

1. Outcome: what changes for the business, with a number and a volume.
2. Data: where it lives, how much, how clean, personal data yes/no. Sample attached.
3. Cost of wrong: what happens, who catches it today, acceptable error rate at launch.
4. Systems: each one, read or write, API access yes/no, sandbox yes/no.
5. Constraints: residency, cost ceiling, latency, hard dates, disclosure rules.
6. Not in scope for v1: the things you are consciously deferring.

```

Due pagine, più appendici. A un founder bastano un pomeriggio per scriverlo, e si risparmiano settimane di scambi, o un progetto che raddoppia silenziosamente di prezzo.

Se ha un brief scritto a metà e vuole uno sguardo esterno prima di inviarlo a chiunque, o se preferisce ragionare sul problema a voce prima, parliamone.