5 errori ricorrenti nell'adozione degli LLM in azienda B2B (e come evitarli)

5 errori ricorrenti nell'adozione degli LLM in azienda B2B

Il 60% dei progetti LLM in ambito enterprise si blocca entro sei mesi dal PoC. Non perché i modelli non funzionino: funzionano. Il problema è quasi sempre negli strati che stanno intorno al modello — dati, architettura, governance, aspettative.

Questi sono i cinque pattern che vediamo ripetersi più spesso quando affianchiamo aziende B2B nell'adozione di sistemi basati su Large Language Model.

---

1. Confondere il PoC con la produzione

Un notebook Jupyter con chiamate a gpt-4o che produce output decenti in demo non è un sistema pronto per la produzione. La distanza tra i due è concreta e misurabile.

Cosa manca tipicamente:

Rate limiting e retry logic: le API dei provider hanno limiti. Un picco di richieste può bloccare un intero flusso applicativo.
Gestione dei token: prompt non controllati in dimensione possono superare il context window e generare errori silenziosi o troncamenti.
Osservabilità: senza logging strutturato su input, output, latenza e costo per chiamata, non hai dati per ottimizzare né per fare debug.

# Esempio minimo di retry con backoff esponenziale
import time
from openai import OpenAI, RateLimitError

def call_with_retry(client, messages, model="gpt-4o", max_retries=4):
    delay = 1
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(
                model=model,
                messages=messages
            )
        except RateLimitError:
            if attempt == max_retries - 1:
                raise
            time.sleep(delay)
            delay *= 2

Questo non è codice sofisticato. È il minimo sindacale per non andare in produzione con un sistema fragile.

---

2. RAG implementato senza valutazione della qualità dei chunk

Retrieval-Augmented Generation è diventato il pattern di default per portare dati aziendali in contesto. Il problema è che la maggior parte delle implementazioni si ferma al "funziona in demo".

Errori comuni:

Chunk size arbitrari: dividere un documento in blocchi da 512 token senza considerare la struttura semantica del contenuto produce retrieval rumoroso.
Nessuna valutazione del retrieval: quante volte il chunk recuperato è effettivamente il più rilevante per la query? Senza metriche come MRR (Mean Reciprocal Rank) o NDCG, non lo sai.
Embedding model disallineato: usare un embedding model generico su testi tecnici o legali in italiano produce rappresentazioni vettoriali di qualità inferiore rispetto a modelli fine-tunati sul dominio.

Un approccio più solido prevede valutazione offline con un set di query/ground-truth costruito internamente, prima di andare live.

---

3. Ignorare il costo reale a scala

Durante il PoC si fanno 500 chiamate. In produzione, con 200 utenti attivi, le chiamate diventano 50.000 al giorno. Il budget non scala linearmente con la qualità percepita.

Una stima grezza:

| Modello | Costo input (per 1M token) | Costo output | |---|---|---| | gpt-4o | $5 | $15 | | gpt-4o-mini | $0.15 | $0.60 | | Claude 3.5 Haiku | $0.80 | $4 |

Un'azienda che usa gpt-4o per classificare ticket di supporto — task che gpt-4o-mini o un modello fine-tunato gestisce con qualità equivalente — può spendere 30x in più del necessario.

La strategia corretta è routing dei modelli: usa il modello più capace solo per i task che lo richiedono davvero, e modelli più economici per tutto il resto. Frameworks come LiteLLM permettono di implementare questo routing senza riscrivere il layer di chiamata.

---

4. Nessuna strategia di fallback e di valutazione continua

Gli LLM sono sistemi non deterministici. Lo stesso prompt può produrre output diversi, e un aggiornamento del modello da parte del provider può cambiare il comportamento senza preavviso.

Questo è particolarmente critico in ambito B2B dove gli output del modello entrano in flussi documentali, CRM, o sistemi ERP.

Pattern da implementare:

Output validation: non fidarti dell'output grezzo. Valida la struttura (Pydantic, JSON Schema) e, dove possibile, la coerenza logica.
Evals automatizzate: un test suite di prompt/expected-output che giri ad ogni deploy, simile a unit test per il codice. Strumenti come promptfoo o deepeval permettono di farlo con effort contenuto.
Fallback esplicito: se il modello restituisce un output che non supera la validazione, definisci cosa succede. Un errore gestito è meglio di un dato corrotto silenzioso.

# Esempio configurazione promptfoo
prompts:
  - file://prompts/classificazione_ticket.txt
providers:
  - openai:gpt-4o-mini
tests:
  - vars:
      ticket: "Fattura non ricevuta per ordine #4421"
    assert:
      - type: contains
        value: "fatturazione"
      - type: latency
        threshold: 3000

---

5. Sottovalutare la governance dei dati e la compliance

Mandare dati aziendali a un'API esterna ha implicazioni legali e contrattuali che molti team tecnici delegano interamente al legal, spesso troppo tardi.

Domande che devono avere risposta prima dell'integrazione:

I dati che passi nel prompt contengono PII o dati sensibili ex GDPR?
Il provider usa i tuoi dati per il training del modello? (OpenAI non lo fa per le API, ma va verificato per ogni provider)
Hai un DPA (Data Processing Agreement) firmato?
Dove vengono processati i dati? EU o extra-EU?

In contesti B2B con dati di clienti, contratti o documentazione finanziaria, la risposta a queste domande determina se puoi usare un provider cloud pubblico, un modello self-hosted (Llama 3, Mistral, ecc.) o una configurazione ibrida.

Ignorare questo punto non è solo un rischio legale: è un rischio commerciale. Un cliente enterprise che scopre post-integrazione che i suoi dati transitano in modo non conforme può rescindere il contratto.

---

Take-away operativo

Adottare un LLM in produzione non è un progetto di AI: è un progetto di ingegneria del software con componenti non deterministiche. Le competenze che servono sono quelle classiche — osservabilità, testing, gestione degli errori, governance — applicate a un layer con caratteristiche nuove.

Se stai pianificando un'integrazione LLM e vuoi un assessment tecnico prima di iniziare, il team di Evviva Group può affiancarti nella fase di design architetturale.