Come Scegliere il Primo Progetto AI

Il vostro primo progetto AI dovrebbe essere un compito circoscritto, ripetitivo e basato su testo, che un essere umano già svolge lentamente o in modo incoerente, dove gli input esistono già e l'output può essere verificato da qualcuno del vostro team. Dovrebbe essere consegnato in settimane, non trimestri, e dovrebbe avere una metrica leggibile sei settimane dopo il lancio. Tutto il resto della "strategia AI" discende da ciò che quel primo risultato vi insegna.

La maggior parte dei founder con cui parliamo sbaglia l'ordine. Partono dall'idea più visibile (un chatbot sulla homepage, un "copilota AI" per tutto il prodotto) e finiscono con una demo che impressiona in riunione e non arriva mai in produzione. Il filtro qui sotto è quello che usiamo per indirizzarli verso qualcosa che venga effettivamente consegnato.

Il filtro delle quattro domande

Sottoponete ogni candidato a queste domande, nell'ordine. Un progetto che fallisce una sola di esse è un secondo o terzo progetto, non un primo.

1. Un essere umano fa già questo oggi, e se ne lamenta?

I migliori primi progetti stanno già accadendo manualmente. Qualcuno nel vostro team legge i lead in entrata e li classifica. Qualcuno riassume i ticket di supporto per la revisione settimanale. Qualcuno copia campi da PDF nel CRM. Qualcuno scrive email di follow-up quasi identiche quaranta volte a settimana.

Se nessuno svolge il compito oggi, non state automatizzando un workflow, state inventando un prodotto. Questo è legittimo, ma è una scommessa di prodotto con i relativi rischi, e non dovrebbe essere il vostro primo progetto AI.

La lamentela conta quanto il compito. Un workflow odiato dalle persone vi offre un utente interno motivato che testerà l'output, segnalerà i fallimenti e difenderà il progetto quando è imperfetto nella seconda settimana.

2. Gli input esistono già in una forma utilizzabile?

Il testo in email, documenti, ticket di supporto, trascrizioni di chiamate e pagine web è utilizzabile. Dati sparsi su sei fogli di calcolo con nomi di colonna incoerenti non lo sono, e "basta prima pulire i dati" è la causa di morte più comune per una prima iniziativa AI.

Scegliete un compito in cui il modello possa leggere ciò che esiste già. Se la risposta onesta è che i dati richiedono un progetto di migrazione prima che qualsiasi modello possa toccarli, scegliete un altro primo progetto e inserite la migrazione nella roadmap separatamente.

3. Una persona non tecnica può verificare se l'output è corretto?

Il vostro primo progetto ha bisogno di una persona che possa guardare l'output e dire "sì" o "no" in meno di un minuto. Un'email in bozza, un'etichetta di classificazione, un insieme di campi estratti, un riassunto di un paragrafo: tutti verificabili. Un agente multi-step che negozia con fornitori o modifica autonomamente il vostro database non è verificabile a colpo d'occhio, e non avete ancora alcuna prova su come il vostro modello si comporti sui vostri dati.

Questo è anche il motivo per cui diciamo ai founder di rimanere interni per il primo progetto. Quando l'output è sbagliato, il costo è qualche minuto del tempo di un collega, non la fiducia di un cliente. Dopo alcune settimane con tassi di errore reali, la decisione di passare al rivolto-ai-clienti diventa una decisione basata sui dati. Trattiamo cosa richiede questa transizione in portare un agente AI dal pilota alla produzione.

4. C'è una metrica leggibile in sei settimane?

Ore risparmiate a settimana. Tasso di risposta. Percentuale di ticket instradati correttamente. Giorni dal lead in entrata alla prima risposta. Un numero, misurato prima e dopo.

Se l'unico criterio di successo onesto è "il team si sente più produttivo", il progetto non può essere valutato e non può giustificare un secondo progetto. Per la conversazione finanziaria dietro a questo, consultate la nostra guida su come calcolare il ROI di un agente AI.

Cosa esclude questo filtro, e perché va bene così

• Il chatbot sulla homepage. Fallisce contemporaneamente la domanda tre e la domanda quattro. Nessuno nel vostro team può verificare ogni risposta data a un visitatore, la metrica è poco chiara, e il rovescio della medaglia di una risposta sbagliata è pubblico. Un ottimo terzo progetto, una volta che avete tassi di errore interni a cui riferirvi.
• L'assistente di conoscenza interno su "tutti i nostri documenti". Fallisce la domanda due. "Tutti i nostri documenti" significa sei formati, tre modelli di permessi, e nessuno che possa dire se una risposta era corretta. Riducetelo a un tipo di documento e un team, e supera il filtro.
• L'agente che gestisce l'intero workflow. Qualsiasi cosa descritta come "un agente che gestisce l'intero processo end-to-end" fallisce la domanda tre. Nel nostro caso, la versione end-to-end sarebbe stata "un agente che gestisce l'outreach." Non abbiamo costruito quello. Abbiamo costruito il singolo passaggio che un umano svolgeva più spesso e apprezzava meno, la ricerca-e-bozza, lasciando l'invio, il follow-up e gli aggiornamenti del CRM alle persone. La versione a processo completo è un secondo o terzo progetto, assemblato da passaggi ciascuno già verificato.
• Qualsiasi cosa che inizia costruendo infrastruttura. Database vettoriali, data lake, piattaforme di orchestrazione. Sono strumenti che potreste servirvi più avanti. Comprarli o costruirli prima di avere un compito funzionante è il modo in cui i budget svaniscono, ed è quasi sempre il segno che il compito stesso non è stato definito con precisione.

Un esempio concreto dalle nostre operazioni

Il nostro primo progetto AI interno non è stato affatto glamour. Inviamo outreach a potenziali clienti, e la parte lenta era la ricerca: qualcuno doveva aprire il sito di ogni azienda, capire cosa facesse, e scrivere un'email che la citasse. Ha soddisfatto tutti i requisiti. Un umano lo faceva e non gli piaceva. L'input, un sito web pubblico, esisteva già. Un collega poteva leggere la bozza e giudicarla in trenta secondi. La metrica era il tasso di risposta.

Abbiamo costruito un piccolo motore che esegue la scansione del sito di ogni prospect con un crawler self-hosted, passa il contenuto a un modello ospitato localmente, e produce un'email personalizzata per ogni azienda. La prima architettura che abbiamo provato era una catena: un passaggio per estrarre i fatti sull'azienda, un altro per scegliere un angolo, un altro per redigere il testo. Funzionava, ma quando l'abbiamo collassata in un singolo prompt che estraeva i fatti rilevanti e redigeva l'email in un solo passaggio, le bozze sono migliorate e il costo per email è diminuito. Questa scoperta ha modellato il modo in cui costruiamo i progetti per i clienti oggi, e ne abbiamo scritto in single call vs agent chains.

Il punto non è l'architettura specifica. Il punto è che un primo progetto circoscritto, verificabile e misurabile ci ha insegnato qualcosa di generale in poche settimane, che è esattamente a cosa serve un primo progetto.

Quanto dovrebbe costare e quanto tempo dovrebbe richiedere

Un primo progetto che supera il filtro richiede tipicamente poche settimane di lavoro di agenzia: una breve fase di discovery per definire il compito e la metrica, una fase di build, e un paio di settimane di utilizzo supervisionato con input reali. Se l'offerta che ricevete supera le sei-otto settimane, o richiede l'allestimento di nuova infrastruttura prima che qualcosa sia utilizzabile, lo scope è andato alla deriva. Contestate lo scope prima di contestare il prezzo.

I costi dei modelli per un compito interno a questa scala sono di solito un arrotondamento rispetto al costo del build. Il nostro motore di outreach gira su un modello ospitato localmente e un crawler self-hosted, quindi il costo per email è di fatto hardware che già possediamo. Il cambiamento architetturale ha contato più della scelta del modello: collassare tre chiamate al modello in una ha ridotto il costo per email, e lo ha fatto migliorando al contempo le bozze. L'eccezione è l'elaborazione documentale ad alto volume, dove la scelta del modello conta davvero; anche in quel caso, un modello piccolo o self-hosted è spesso sufficiente una volta che il compito è circoscritto, e potete testarlo durante il build piuttosto che decidere a priori.

Preventivate anche la parte noiosa: registrare ogni input e output dal primo giorno. Abbiamo potuto confrontare la catena con il prompt singolo solo perché ogni pagina scansionata e ogni bozza erano state archiviate. Senza quel log non potete misurare i tassi di errore, non potete confrontare due approcci, e non potete rispondere alla domanda "ha funzionato" alla sesta settimana.

Come gestire le sei settimane

1. Settimana zero: scrivete il compito, la baseline attuale per la vostra metrica, e chi verificherà gli output ogni giorno.
2. Settimane uno-tre: costruite. Insistete per vedere input reali, non esempi sintetici, entro la fine della prima settimana.
3. Settimane quattro-sei: fatelo funzionare in parallelo all'umano. L'umano continua a svolgere il compito; l'output dell'AI viene confrontato con il suo. Contate gli accordi e i fallimenti.
4. Fine della sesta settimana: leggete la metrica. Decidete se espandere, mantenere così com'è, o interrompere. Qualsiasi delle tre è un buon risultato, perché ora avete delle prove.

Se ha funzionato, il secondo progetto è di solito ovvio: il passo successivo nello stesso workflow, oppure lo stesso compito per un team vicino. Se non ha funzionato, avete imparato dove i vostri dati o il vostro dominio mettono in difficoltà un modello, al prezzo di poche settimane piuttosto che di un trimestre.

Se avete già un candidato in mente e volete un secondo parere su se supera il filtro, parliamone.