Il punto non è scegliere chi scrive il primo prompt. È decidere chi si prende la responsabilità di trasformare un prototipo AI in un processo che continua a funzionare quando cambiano dati, eccezioni e persone. Per una PMI, la scelta concreta è tra un lavoro “forward deployed”, con tecnici dentro il problema operativo, e un’integrazione self-service costruita sulle API.

OpenAI definisce deployment gap la distanza tra ciò che un modello sembra saper fare e ciò che le persone riescono a usare con affidabilità nel lavoro. È un criterio utile anche fuori dalle grandi imprese: più quel divario è ampio, meno basta collegare un endpoint e sperare che il caso demo coincida con la produzione.

Il criterio: quanta ambiguità devi assorbire

Il confronto non è tra “consulenza costosa” e “API economica”. È tra due modi diversi di assorbire l’ambiguità. Un Forward Deployed Engineer, o FDE, lavora a contatto con chi usa il processo, traduce vincoli di business in test, collega dati e strumenti e porta il sistema dal prototipo alla produzione. L’approccio self-service parte invece da un perimetro già abbastanza chiaro: input noti, output verificabile, responsabilità interne e integrazioni disponibili.

La domanda da fare prima del budget è semplice: sappiamo descrivere il risultato corretto e misurarlo? Se sì, API e team interno hanno un vantaggio. Se la risposta cambia tra commerciale, operations e IT, il problema non è ancora pronto per essere consegnato a un fornitore di modello.

FDE: quando il problema viene prima del prodotto

Nel modello FDE il lavoro parte dall’esito e non dalla tecnologia. OpenAI racconta un progetto nel settore dei semiconduttori in cui circa 15 tecnici hanno lavorato su oltre 10 casi d’uso. Nei primi 3-6 mesi le soluzioni hanno raggiunto produzione e adozione iniziale; tra i risultati dichiarati figurano circa il 48% di tempo risparmiato nella generazione dei test e un miglioramento mediano del 22% nell’ottimizzazione dei kernel. Sono numeri di quel progetto, non benchmark trasferibili a qualsiasi azienda.

Il vantaggio è evidente nei processi ad alto impatto: l’ingegnere vede le eccezioni, costruisce eval con gli specialisti e può cambiare architettura quando il modello non regge il lavoro reale. È utile per assistenza regolata, controllo qualità, processi fiscali o automazioni che scrivono nei sistemi aziendali. Qui un errore non produce solo una risposta mediocre: può modificare un ordine, esporre dati o bloccare un flusso.

Il limite è la sostenibilità. Un’implementazione molto personalizzata può diventare difficile da estendere e mantenere. OpenAI descrive lo stesso problema: dopo i primi risultati, il team ha ricondotto applicazioni separate a componenti comuni basati su Codex, eliminando circa il 90% del codice custom per progetto. La lezione non è “personalizzare tutto”, ma usare l’intervento embedded per scoprire il modello operativo e poi ridurre il debito.

API self-service: meno attrito, più disciplina interna

L’approccio API funziona meglio quando il lavoro è delimitato. Un sito WordPress che propone metadati da approvare, una pipeline che classifica ticket senza chiuderli, oppure un’automazione che prepara una bozza senza inviarla hanno un confine chiaro. Il team può partire piccolo, registrare input e output e mantenere un gate umano prima dell’azione irreversibile.

I pro sono velocità, controllo del codice e possibilità di sostituire singoli componenti. I contro emergono dopo la demo: versioni dei prompt, eval, permessi minimi, osservabilità, fallback e budget diventano responsabilità dell’azienda. Ho già descritto il principio del controllo nei workflow AI e quello dei limiti sulle chiavi API degli agenti: senza questi due livelli, il self-service è solo rischio spostato sul team interno.

Cosa cambia per WordPress, web e automazioni

Su WordPress partirei quasi sempre self-service. Il CMS offre ruoli, bozze, revisioni e API: sono confini già pronti per un assistente che genera contenuti, tag o alt text senza pubblicare in autonomia. La stessa logica vale per report, arricchimento CRM e triage: prima si automatizza una proposta, poi si misura l’errore, infine si concede una capacità operativa in più.

Un intervento simile a quello FDE diventa sensato quando l’automazione attraversa più sistemi e nessuno possiede davvero il processo. Se un agente deve leggere il gestionale, decidere una politica commerciale, aggiornare WordPress e scrivere al cliente, non hai un problema di prompt: hai un problema di architettura, governance e responsabilità. In quel caso serve un team embedded, interno o esterno, che lavori con chi conosce le eccezioni e costruisca test prima dei connettori.

La matrice decisionale per una PMI

  • Scegli API self-service se l’output corretto è descrivibile, l’azione è reversibile, i dati sono accessibili e una persona interna può mantenere eval e integrazioni.
  • Scegli un approccio FDE se il processo è critico, attraversa reparti, contiene eccezioni non documentate oppure il modello va valutato sul lavoro reale insieme agli specialisti.
  • Rimanda entrambi se non esiste un proprietario del processo o nessuno sa quale metrica rappresenti un risultato utile.

OpenAI ha formalizzato questa seconda strada con una Deployment Company che parte da una diagnosi, seleziona pochi workflow prioritari e collega modelli, dati, strumenti e controlli. Il prodotto Presence segue una logica analoga ed è offerto a clienti enterprise idonei tramite un programma limitato, non come soluzione self-service. Questo chiarisce il posizionamento: l’FDE non è il gradino iniziale obbligatorio dell’AI, ma uno strumento per situazioni in cui integrazione e affidabilità fanno parte del prodotto.

La mia scelta: self-service finché il rischio resta confinato

Per una PMI partirei con API, un singolo workflow e un gate umano. È il percorso più rapido per capire se esiste valore senza trasformare subito un esperimento in una consulenza strutturale. Passerei a un modello FDE solo quando il risultato dipende dalla conoscenza tacita di più reparti, quando le azioni non sono facilmente reversibili o quando i test mostrano un divario persistente tra demo e produzione.

La take finale è netta: non comprare persone embedded per compensare un caso d’uso vago, e non scegliere il self-service per risparmiare quando nessuno sa governare ciò che verrà messo in produzione. Prima restringi il problema. Poi usa l’opzione meno complessa capace di reggere il rischio reale.

Fonti

Approfondimenti