Integrare GPT-4 in n8n: Guida Completa con Esempi

n8n ha il nodo OpenAI nativo, ma usarlo bene in produzione richiede di capire come gestire il context window, come parsare l'output in modo affidabile e come non bruciare il budget API. Questa guida copre tutto quello che ho imparato costruendo workflow AI in produzione.

La differenza tra un workflow n8n "normale" e uno con GPT-4 è che il secondo introduce un elemento non deterministico: lo stesso input può produrre output leggermente diversi, e il modello può — occasionalmente — non rispettare il formato richiesto. Se hai già letto la guida al primo workflow n8n, qui aggiungiamo un livello: non solo automatizzare un processo, ma farlo prendere decisioni basate su testo. È lo stesso principio dietro gli agenti di automazione — la differenza è che qui restiamo dentro un workflow strutturato, con GPT-4 usato per singoli step decisionali invece che per pianificare l'intero processo.

Setup: nodo OpenAI in n8n

In n8n, aggiungi il nodo OpenAI e configura le credenziali con la tua API key. Usa sempre le variabili d'ambiente di n8n — mai hardcoded nei workflow.

Pattern 1: classificazione automatica

Caso d'uso classico: classificare email, ticket o feedback in categorie predefinite. È il pattern più semplice e anche il più affidabile, perché l'output atteso è ristretto a poche opzioni — il modello ha poco spazio per "divagare".

// Prompt per classificazione affidabile
System: Sei un classificatore di email aziendali.
Rispondi SOLO con un JSON valido senza altri testi.

User: Classifica questa email:
{{$json["emailBody"]}}

Output richiesto:
{
  "categoria": "supporto|fatturazione|partnership|altro",
  "urgenza": "bassa|media|alta",
  "riassunto": "max 20 parole"
}

Parsing affidabile dell'output JSON

Dopo il nodo OpenAI, aggiungi un nodo Code per parsare e validare:

// Nodo Code in n8n
const raw = $input.item.json.message.content;

// Rimuovi eventuali markdown blocks
const cleaned = raw.replace(/```json\n?/g, '').replace(/```\n?/g, '').trim();

try {
  const parsed = JSON.parse(cleaned);
  // Valida campi obbligatori
  if (!parsed.categoria || !parsed.urgenza) {
    throw new Error('Campi mancanti');
  }
  return [{ json: parsed }];
} catch (e) {
  // Fallback: ritorna errore strutturato per error handling
  return [{ json: { error: true, raw: raw, message: e.message } }];
}

Pattern 2: generazione contenuti con contesto variabile

// Costruisci il prompt dinamicamente con i dati del workflow
System: Sei un copywriter B2B specializzato nel settore {{$json["settore"]}}.
Tono: {{$json["tone_of_voice"]}}
Lunghezza: {{$json["lunghezza_parole"]}} parole
Lingua: italiano

User: Scrivi una descrizione prodotto per: {{$json["nome_prodotto"]}}
Caratteristiche principali: {{$json["features"]}}

Pattern 3: estrazione dati strutturati da testo libero

Un caso frequente: hai testo non strutturato (un'email, un documento, una trascrizione) e ti serve estrarne dati precisi in formato utilizzabile — nomi, date, importi, indirizzi. È lo stesso principio della classificazione, ma con più campi e più attenzione alla validazione.

System: Estrai i dati strutturati dal testo. Rispondi SOLO con JSON valido.
Se un campo non è presente nel testo, usa null — non inventarlo.

User: {{$json["testoLibero"]}}

Output richiesto:
{
  "nome_cliente": "string|null",
  "data_richiesta": "YYYY-MM-DD|null",
  "importo": "number|null",
  "note": "string|null"
}

La regola "usa null, non inventare" nel prompt è cruciale: senza un'istruzione esplicita, il modello tende a riempire i campi mancanti con valori plausibili ma falsi. Nel nodo Code successivo, tratta ogni campo null come dato da verificare manualmente, non da scartare.

Gestione costi API in produzione

• Usa GPT-4o-mini per classificazione e task semplici: costa una frazione di GPT-4 e per task ben definiti la qualità è quasi indistinguibile
• Limita il context window: manda solo i dati necessari, non l'intera conversazione — ogni token in più è costo e latenza
• Imposta max_tokens esplicitamente: previeni risposte infinite che costano di più e rallentano il workflow
• Monitora i costi su OpenAI dashboard settimanalmente — i workflow in loop (es. un errore che ritrigghera se stesso) possono esplodere in poche ore
• Metti un tetto di spesa (usage limit) direttamente su OpenAI — è la rete di sicurezza finale se tutto il resto fallisce

Error handling in produzione

// In n8n: aggiungi sempre il nodo "Error Trigger"
// Configurazione consigliata:

1. Nodo OpenAI → retry: 2 tentativi con backoff 30s
2. Nodo IF: controlla se json.error === true
   - True → nodo Slack/email per alert
   - False → continua il workflow
3. Error Trigger globale → salva su Google Sheets per audit

Domande frequenti

Meglio il nodo OpenAI nativo o un nodo HTTP Request generico?

Il nodo nativo è più veloce da configurare e gestisce l'autenticazione per te. Il nodo HTTP Request generico ha senso quando serve un controllo più fine sui parametri della richiesta, o quando l'endpoint da chiamare non è direttamente supportato (es. un modello open-source self-hosted con API compatibile OpenAI).

Come evito che il modello "esca" dal formato JSON richiesto?

Tre accorgimenti: istruzioni esplicite nel system prompt ("rispondi SOLO con JSON valido"), temperature bassa o a 0 per ridurre la variabilità, e un parsing difensivo lato codice (come nell'esempio sopra) che gestisce il caso in cui il modello aggiunga testo extra o markdown attorno al JSON.

Conviene usare GPT-4 per ogni step del workflow?

Quasi mai. Il pattern più efficiente è "a cascata": un modello economico e veloce (GPT-4o-mini) per i task semplici e ad alto volume, GPT-4 riservato solo agli step che richiedono più ragionamento o qualità superiore. Riduce i costi senza sacrificare l'affidabilità dove conta.