Vai al contenuto
Tutte le note

Quando l'AI ha senso nel prodotto (e quando no)

·6 min read

Tutti i team di prodotto stanno valutando funzionalità con AI. E la maggior parte sta risolvendo il problema sbagliato.

La domanda non è "dobbiamo aggiungere l'AI?" La domanda è: "C'è una decisione che richiede giudizio e che una regola o una query non riescono a gestire?" Se la risposta è no, non ti serve l'AI. Ti serve un filtro e un'interfaccia migliore.

Key Takeaway

Lo schema che uso: l'80% del problema si risolve con regole automatiche. Il restante 20% — dove serve il giudizio — è dove l'AI ha senso.

80%Deterministic rulesFilters · Queries · State machines20%AIJudgment callsFast · Free · Auditable · PredictableSlower · Costs $ · Handles nuanceCasaHunter example:Pass 1: price, size, location → eliminates 80%Pass 2-3: AI scores survivors

CasaHunter: la divisione 80/20 nella pratica

Ho costruito uno strumento per cercare appartamenti in un weekend. Il problema: otto siti di annunci, dati incoerenti, nessun modo per sapere "è uscito qualcosa di buono da ieri?"

L'approccio ingenuo: dare in pasto ogni annuncio a un modello linguistico, fargli valutare la qualità, ordinare, notificare. Fatto. Sembra elegante. Costa soldi, è lento, e il risultato è appena migliore di una regola.

Il vero problema era diverso. Un annuncio di appartamento ha l'80% di dati oggettivi: metri quadri, prezzo, posizione, anno di costruzione, ascensore sì o no, parcheggio sì o no. Tutto verificabile, ordinabile, filtrabile. Tutto automatizzabile con regole.

Quindi il sistema funziona così:

Primo passaggio: filtri automatici. Prezzo tra 400-700k? Metri quadri sopra 120? Non richiede una ristrutturazione totale? Sì a tutti. Altrimenti, scartato. Questo elimina l'80% degli annunci gratis in millisecondi.

Secondo passaggio: AI su quello che sopravvive. Il 20% che resta va al modello. Ma adesso il contesto è ristretto. Non "valuta questo appartamento", ma "considerando che ha passato i filtri oggettivi, e considerando il feedback di questo utente su cinque appartamenti che ha già visto, vale la pena che lo guardi?" Molto più economico. Molto più veloce. Molto più preciso.

Terzo passaggio: apprendimento dal comportamento. Quando un utente ignora un annuncio o lo guarda senza contattare, la valutazione impara. Non dai dati degli annunci. Dal comportamento reale dell'utente.

Quando l'AI è la risposta giusta

L'AI ha senso quando:

Riconoscimento di schemi su dati non strutturati. Hai migliaia di informazioni senza una regola chiara, e devi categorizzarle. Classificazione di testo, analisi di immagini, rilevamento di anomalie. Il modello vede schemi che una regola scritta da un umano non riesce a esprimere.

Valutazione personalizzata quando le preferenze sono complesse. "Quale appartamento dovrei vedere dopo?" non ha una regola sola. A una persona interessa stare vicino al lavoro, ristrutturare poco, avere uno spazio esterno. A un'altra interessa che sia già ristrutturato, l'altezza dei soffitti, l'età del palazzo. Non puoi scrivere regole per questo. Puoi imparare dal comportamento e adattarti.

Comprensione del linguaggio naturale dove il contesto conta. Un cliente scrive "l'integrazione continua a rompersi." Non è un dato strutturato. È una lamentela, e ha bisogno di contesto. Si è rotta una volta? Tre? Il cliente è frustrato o sta solo segnalando? Il linguaggio naturale conta. Una regola non coglie la sfumatura.

Quando no

Qualsiasi cosa risolvibile con un filtro. "Mostrami i pagamenti sotto 1000 euro" non ha bisogno di un modello. Ha bisogno di una condizione nel database. Ogni richiesta di funzionalità che si riduce a "fai vedere solo gli elementi dove [condizione]" è un filtro, non un problema di AI.

Qualsiasi cosa risolvibile con una query. "Quali centri hanno il volume di transazioni più alto?" "Qual è il tasso di abbandono per paese?" Regole. Struttura la domanda, scrivi la query, mostra la risposta.

Qualsiasi cosa con una regola chiara. "Se il pagamento fallisce due volte, metti il centro in revisione." Quella è una regola. "Se l'elaborazione impiega più di 2 secondi, registra un incidente." Regola. Il PM che dice "usiamo l'AI per gestire gli errori" di solito sta guardando un diagramma di stati, non un problema di intelligenza.

Il calcolo del costo

Qui è dove la maggior parte dei team sbaglia. Confrontano il "costo di scrivere una regola" con il "costo di una chiamata al modello." La regola costa 2 ore. La chiamata costa €0,001. Il modello vince. Tranne che:

Le chiamate si accumulano. La valutazione degli appartamenti gira su 5.000 annunci al mese. €0,001 a chiamata. €5 al mese. Ma aggiungi la latenza, i tempi di avvio, il lavoro di integrazione, la gestione degli errori. Quando l'hai reso affidabile, il costo per chiamata è più alto e la latenza è peggiore di una regola.

Più importante: quando l'AI sbaglia un giudizio, quanto costa? In un'app di appartamenti, niente. L'utente vede un annuncio sbagliato. In un sistema di pagamenti, un giudizio sbagliato costa soldi. Ti servono controlli, tracciabilità e revisione umana. A quel punto la "funzionalità AI semplice" diventa infrastruttura.

Cosa ho messo in produzione

CasaHunter è tre filtri automatici, poi AI su quello che sopravvive, poi apprendimento dal comportamento. Payments Rescue è regole — regole rigorose — senza AI. Se un pagamento non rientra nello schema, non viene categorizzato. Lo legge una persona.

ActiveProspect: la configurazione dei collegamenti tra piattaforme ha un po' di AI (mappatura intelligente dei campi), ma la decisione centrale — quali integrazioni suggerire — è una regola basata su quello che l'utente ha già configurato.

Ogni volta che sento "usiamo l'AI" prima di "abbiamo un problema di giudizio?" so che la funzionalità sarà costosa e mediocre.

La domanda migliore: "Cosa possiamo risolvere senza AI?" Risolvi quello prima. Il 20% che resta — è lì che l'AI ha senso.