Quando aggiungere AI al software B2B (e quando no)

Parti dal job, non dal modello

Scrivi l'outcome nel linguaggio dell'operatore: 'ridurre il tempo per trovare la SOP giusta', 'bozza di ticket da email con campi compilati', 'segnalare fatture fuori policy prima del post'. Se non sai nominare utente, system of record e metrica di successo, non sei pronto per una feature LLM. Separa la comprensione del linguaggio dalla verità di business. Status, saldi e entitlement arrivano da API e database. I modelli draftano, classificano, recuperano e suggeriscono; non inventano lo stato del ledger. Usa la technical discovery per mappare owner dei dati, cadenza di refresh e chi è responsabile quando la risposta è sbagliata.

• Nomina la persona e la frequenza settimanale del job
• Nomina il system of record e il write path (se c'è)
• Definisci 'abbastanza buono' con esempi, non con aggettivi
• Decidi chi revisiona gli output ad alto rischio prima del go-live

Chat vs RAG vs agent vs automazione classica

La chat plain (o un thin wrapper su un foundation model) va bene per brainstorming, drafting interno e Q&A a basso rischio senza corpus privato. Fallisce quando le risposte devono citare le tue policy o quando il modello deve compiere azioni. Il RAG va bene per knowledge privata e che cambia, con citazioni: manuali, contratti, ticket, cataloghi. Gli agent vanno bene per uso tool multi-step con branch, retry e approvazioni. L'automazione classica (regole, BPM, script, RPA a path fisso) vince quando il path è noto e inventare step è un bug. Gli hybrid sono normali: RAG come tool dentro un grafo agent, o un agent che drafta mentre codice deterministico posta dopo sign-off. Non vendere 'una chat box che fa tutto'.

• Chat: aiuto linguistico, senza requisito di grounding
• RAG: risposte grounded dal tuo corpus
• Agent: giudizio sui tool con stato durevole
• Automazione: path fisso, SLA forti, LLM non necessario

Quando l'AI è lo strumento sbagliato

Salta gli LLM quando un filtro, un template o un workflow engine risolvono già il job con più affidabilità e meno costo. Salta quando mancano documenti autorevoli o API pulite: il modello amplificherà il disordine. Salta le write non supervisionate verso ERP, billing o access control. Salta consulenza regolata senza human review e audit. Salta la 'AI search' che in realtà è un filtro sfaccettato mancante su campi strutturati. Se l'obiettivo del pilot è un comunicato stampa, aspetta. Se è una metrica ops misurabile con un owner, procedi con una slice stretta.

Red flag di vendita e vendor

Red flag: demo solo su dati pubblici; nessuna storia di ACL per tenant; 'faremo fine-tuning dopo' come risposta al grounding; post ERP non supervisionati nel happy path; nessun eval set; pricing che ignora retrieval e costo di human review. Attenzione anche a: autonomia infinita dell'agent venduta come 'set and forget', retrieval black-box proprietario che non puoi auditarare, e contractor che non mostrano i failure mode. Usa valutazione e acceptance dei contractor AI e assunzione contractor per trasformare demo lucide in deliverable con gate.

• Chiedi test di leakage cross-tenant per iscritto
• Chiedi cosa succede quando il retrieval è vuoto
• Chiedi quali azioni richiedono sempre un umano
• Chiedi il costo per task riuscito, non solo il listino del modello

Scope di un MVP AI da cui si impara

Una persona, un corpus o un journey, una metrica di successo. Non-goal: swarm multi-agent, ogni connector, browsing open-ended, movimenti di denaro non supervisionati. Spedisci citazioni o UX di approvazione prima di prompt furbi. Strumenta usage e ragioni di failure dal giorno uno. Preferisci shadow mode o draft-only prima dei write path. Allinea lo scope a prioritizzazione MVP e il budget a stime di delivery. L'igiene dei dati spesso domina la scelta del modello; vedi data readiness per RAG e agent.

Segnali di ROI accettati da buyer e board

Misura tempo risparmiato per task, error rate vs baseline, deflection dei ticket di support e human override rate. Abbina metriche di qualità (correttezza citazioni, task success) al costo per outcome riuscito. Evita vanity: pollice in su in chat senza completamento del task, o 'messaggi inviati' senza impatto di business. Per gli agent, traccia spreco di tool-call e escalate da loop. Prezza la feature così che i margini sopravvivano a token, retrieval e lavoro di review. Quello è unit economics delle feature LLM, non una nota a piè di pagina.

• Fai baseline del processo manuale prima del pilot
• Definisci kill criteria se qualità o costo mancano il bar
• Separa successo del pilot da readiness per expand enterprise
• Includi il carico di support nel modello di ROI

Security e compliance come gate di prodotto

I deal enterprise si bloccano su data residency, prompt injection, tool abuse e audit di ciò che il modello ha visto. Trattali come criteri di release, non come homework del questionario dopo la vendita. Segui sicurezza AI per B2B enterprise, audit logging e SSO e identity così la feature AI eredita lo stesso principal e modello tenant del resto del prodotto.

Readiness organizzativa

Qualcuno deve possedere qualità del corpus, versioni di prompt/grafo, soglie di eval e incident response quando il modello sbaglia. Senza owner, l'AI diventa un buco nero di support. Forma gli operatori su refusal ed escalation. Allinea gli SLA a modelli di support: AI che 'di solito funziona' serve comunque un path umano. Human-in-the-loop è una superficie di prodotto, non una stampella temporanea; vedi prodotti AI human-in-the-loop.

Prossimi passi

Scegli tre job reali e valuta ciascuno come automazione, RAG, agent o 'non AI'. Uccidi tutto ciò che sta bene solo in un transcript di demo. Approfondisci RAG in produzione, workflow agentic, altre risorse, case study, prenota una call o contatti se vuoi una review di fit prima che il budget si blocchi sul pattern sbagliato.

Domande frequenti