Framework CO-STAR per prompt enterprise: checklist applicativa e anti-pattern del prompt engineering 2026

Il 10 maggio 2026 ho rivisto con un cliente PMI italiana il system prompt del suo chatbot di supporto, scritto sei mesi prima da un fornitore esterno. Tre pagine di testo libero, nessuna struttura, istruzioni contraddittorie, esempi mescolati a regole. Accuracy su domande reali: 62%. Ho riscritto lo stesso prompt applicando il framework CO-STAR di GovTech Singapore, mezz'ora di lavoro, stessa lunghezza. Accuracy salita all'81%. Diciannove punti percentuali senza cambiare modello, dataset, retrieval. La struttura del prompt non è cosmetica, è semantica. Questo articolo è la checklist applicativa di CO-STAR per prompt enterprise, con gli anti-pattern più frequenti e un template riutilizzabile.

Cosa è CO-STAR e da dove arriva?

CO-STAR è un acronimo che struttura un prompt enterprise in sei componenti: Context, Objective, Style, Tone, Audience, Response. È stato formalizzato nel Prompt Engineering Playbook di GovTech Singapore dopo il torneo Prompt Royale del 8 novembre 2023, primo torneo pubblico mondiale di prompt engineering GPT-4. Sheila Teo ha vinto la competizione applicando CO-STAR; il suo articolo How I Won Singapore's GPT-4 Prompt Engineering Competition è diventato uno dei più letti del mondo prompt engineering nel dicembre 2023, con oltre 120.000 lettori in sei settimane. Il framework è stato ideato da Joseph Tan, chief judge del torneo.

Perché funziona? Perché forza l'autore del prompt a esplicitare dimensioni che altrimenti restano implicite. Il modello legge istruzioni ordinate e ne segue la struttura; un prompt disorganizzato produce risposte disorganizzate. Non è magia: è applicazione dei limiti di attention documentati nell'architettura Transformer (vedi l'articolo dentro un Transformer) alla disciplina della scrittura.

Componente 1: Context (il contesto applicativo)

Il modello non sa chi sei, cosa fa la tua azienda, quali vincoli operativi si applicano. Context fornisce questo setup.

Cosa scrivere. Ruolo dell'azienda, dominio di riferimento, dataset su cui il modello deve ragionare, vincoli normativi rilevanti, convenzioni interne.

Esempio pratico.

Context: Sei un assistente tecnico per una software house italiana che sviluppa gestionali ERP per PMI manifatturiere. Il tuo dominio copre fatturazione elettronica, magazzino, produzione. Rispondi solo su casi supportati dalla documentazione aziendale fornita nel contesto.

Anti-pattern. Context generico ("sei un assistente utile"); Context confuso ("lavori per noi e per i nostri clienti"); Context senza vincoli ("rispondi a qualsiasi domanda").

Componente 2: Objective (l'obiettivo specifico della risposta)

Il modello deve sapere che cosa produrre, non solo di cosa parlare.

Cosa scrivere. Il task preciso: classificare, estrarre, riassumere, rispondere, generare. Con criteri di terminazione chiari.

Esempio.

Objective: Rispondi alla domanda dell'utente con una risposta tecnica in massimo 150 parole. Se la documentazione fornita non contiene la risposta, rispondi letteralmente "Non ho informazioni sufficienti per rispondere" e suggerisci di aprire un ticket di supporto.

Anti-pattern. Objective vago ("aiuta l'utente"); Objective multi-obiettivo confuso ("rispondi e anche suggerisci e anche sintetizza"); mancanza di termination criteria.

Componente 3: Style (lo stile di scrittura)

Differente dal tono (vedi sotto): lo stile riguarda la forma strutturale della risposta.

Cosa scrivere. Formattazione (bullet, prosa, tabella), linguaggio tecnico vs semplice, densità informativa, eventuali template fissi.

Esempio.

Style: Scrivi in prosa tecnica, evitando bullet list. Usa frasi brevi (max 20 parole). Quando citi feature del gestionale usa il nome esatto fra backtick. Non usare emoji.

Anti-pattern. Style "sia tecnico che semplice" (impossibile); Style senza esempi (il modello indovina); Style solo negativo ("non essere prolisso" senza dire "scrivi conciso").

Componente 4: Tone (il registro emotivo)

Complementare a Style. Il tono è come il messaggio viene percepito emotivamente.

Cosa scrivere. Professionale, amichevole, autorevole, empatico. Scelta cosciente, non default neutrale.

Esempio.

Tone: Professionale ma empatico. Se l'utente segnala un problema bloccante, inizia riconoscendo la frustrazione ("capisco che questo blocchi il tuo lavoro") prima di dare la soluzione.

Anti-pattern. Tone assente (default spesso innaturale); Tone in conflitto con Style (style "conciso" + tone "empatico verboso" = ambiguo); Tone troppo specifico ("usa esattamente queste frasi") che riduce variabilità utile.

Se vuoi vedere come applico CO-STAR in pipeline AI di produzione con governance dei costi, nel mio hub dedicato all'automazione AI trovo articoli tecnici con metodologia applicata.

Componente 5: Audience (chi legge la risposta)

Il modello calibra la risposta sul profilo del destinatario: developer, titolare, operatore, cliente finale.

Cosa scrivere. Profilo del lettore, conoscenze pregresse assunte, livello tecnico, vocabolario accessibile.

Esempio.

Audience: Amministratore del gestionale, con conoscenza media dell'applicativo ma non di concetti software profondi. Conosce termini come "fattura elettronica" e "ciclo attivo" ma non "microservizi" o "REST API".

Anti-pattern. Audience assente (risposta indirizzata a nessuno in particolare); Audience troppo ampia ("chiunque"); Audience in conflitto con Style tecnico.

Componente 6: Response (il formato atteso)

Il modello deve sapere come la risposta deve essere strutturata.

Cosa scrivere. Formato (JSON, Markdown, prosa libera), schema se strutturato, lunghezza attesa, elementi obbligatori.

Esempio.

Response: Rispondi in formato Markdown con struttura:
1. Una frase di diagnosi del problema
2. Due-tre step di soluzione numerati
3. Un link alla documentazione interna (dal contesto fornito)
Lunghezza totale: 80-150 parole.

Anti-pattern. Response "qualunque formato ti sembri opportuno"; Response contraddittorio con Objective (objective dice "150 parole", response dice "dettagliata"); Response senza constraint sul formato quando serve strutturato.

Checklist applicativa in dodici punti

Sintesi operativa per ogni prompt di produzione. Se non rispondi sì a tutti i punti, il prompt non è pronto.

• Hai definito il ruolo del modello (Context)?
• Il dominio operativo è esplicito?
• I vincoli normativi o di business sono dichiarati?
• L'objective è singolo e misurabile?
• Esiste un criterio di astensione esplicito ("non lo so se...")?
• Lo style è definito con esempio positivo?
• Il tone è coerente con style e audience?
• L'audience è specificata (ruolo + livello tecnico)?
• Il formato di risposta è univoco?
• La lunghezza massima è definita?
• Esiste un termination criterion chiaro?
• Il prompt è stato validato su 20+ casi reali prima del deploy?

Anti-pattern documentati empiricamente che emergono nei miei audit

Cinque errori che vedo ripetutamente nei progetti prompt-heavy italiani.

Esempi negativi inseriti nel prompt. "Non rispondere così: [esempio sbagliato]". Il modello vede l'esempio sbagliato e tende a replicarlo perché l'attention è attratta da ciò che è scritto, non da "non". Regola: mai includere esempi negativi; mostrare solo esempi positivi.

Risposta suggerita nella domanda. "Quando succede X, la risposta corretta di solito è Y. Come risponderesti?". Il modello ripete Y. Se non vuoi suggerire, non suggerire.

"Pensaci passo per passo" su modelli thinking. I LRM hanno già chain-of-thought attivo via reasoning. Aggiungere "pensaci passo per passo" nel prompt produce spesso degradazione (doppio thinking, incoerenza fra i due trace). Regola: CoT prompting è per modelli base, non per thinking mode.

Istruzioni contraddittorie. "Sii dettagliato ma conciso". Il modello sceglie un bilanciamento arbitrario che non è quello che vuoi.

Context overload. Mettere nel context 20 esempi, 5 regole aziendali, 10 vincoli. L'attention si disperde, il modello sbaglia più spesso. Minimalismo: quello che serve davvero, nell'ordine giusto.

Template CO-STAR riutilizzabile

Un template base da customizzare per ogni use case.

# Context
Sei un assistente per [ruolo/azienda/dominio]. Operi su [dataset/sistema]. Vincoli: [normative/business].

# Objective
Il tuo compito è [azione precisa] con criterio di terminazione [quando fermarsi].

# Style
Scrivi in [formato] con densità [alta/media/bassa], [lunghezza].

# Tone
Registro [professionale/empatico/tecnico], attivo in particolare quando [scenari].

# Audience
Il lettore è [ruolo], con conoscenza [livello] del dominio [specificità].

# Response
Produci output in formato [esatto], con struttura [schema], lunghezza [min-max].

# Esempi (few-shot positivi)
Input: [query tipica]
Output: [risposta esemplare]

Come misurare il ROI di un refactoring CO-STAR

Refactoring un prompt in CO-STAR costa tempo (tipicamente 2-4 ore per prompt di produzione); misurarne il ROI richiede disciplina sperimentale.

Setup di misurazione. Prendi 200-400 esempi reali di interazione (prompt user + risposta ideale annotata). Lancia il prompt vecchio e il nuovo prompt CO-STAR sullo stesso set con identica temperature e modello. Misura accuracy esatta (output match), accuracy semantica (judge LLM), lunghezza media, latenza, costo per chiamata.

Metriche da tracciare. Accuracy assoluta (in punti percentuali), variance della risposta a parità di input (temperature 0,3 su dieci run), rate di astensione corretta ("non ho informazioni" quando serve), token consumati per risposta.

Risultati tipici nei miei audit. Refactoring CO-STAR su prompt enterprise italiani porta tipicamente accuracy +10-25 punti percentuali, variance ridotta del 40%, costo per chiamata in leggero calo (prompt meno verbosi → meno input token). Il ROI si paga in meno di una settimana di produzione media.

Quando il refactoring NON paga. Se il prompt originale era già strutturato (accuracy sopra 90%), il guadagno è marginale. Se il problema era in altri componenti della pipeline (retrieval scarso, modello sottodimensionato), CO-STAR non lo risolve. Test del problema prima del refactoring, sempre.

Caso concreto: prima e dopo su un chatbot di supporto

Un esempio sanitizzato dalla mia sandbox. Chatbot di supporto su un gestionale italiano, volume 2.500 chiamate/giorno, obiettivo di deflection ticket human.

Prima (prompt libero, 420 parole). Mix di istruzioni e esempi, tono "prova ad aiutare l'utente", nessuna sezione esplicita. Accuracy di deflection corretta: 58%. Rate di astensione appropriata: 12%. Costo medio per chiamata: 0,021 euro.

Dopo (prompt CO-STAR, 380 parole). Context con ruolo + dominio + vincoli, Objective con soglia di astensione, Style prosa breve, Tone empatico su bloccanti, Audience operatore non-tech, Response markdown strutturato. Accuracy di deflection: 79%. Rate di astensione appropriata: 34%. Costo medio: 0,017 euro.

Il rate di astensione quasi triplicato è la chiave: il prompt vecchio "provava" a rispondere anche quando non sapeva, causando ticket secondari; il nuovo dichiara esplicitamente quando non sa, deflettendo direttamente a human support. Questo ha ridotto i ticket di secondo livello del 22% nello stesso volume. Il refactoring è costato tre ore del mio tempo; il ROI mensile del cliente è in doppia cifra migliaia di euro per risparmio operations.

Ordinamento dei blocchi CO-STAR: conta o no?

Domanda ricorrente. La risposta corta: sì, conta ma non quanto sembra.

La convenzione Singapore è C-O-S-T-A-R in quell'ordine. Il posizionamento Objective dopo Context ha senso: il modello carica il contesto operativo prima di ricevere il task. Style/Tone/Audience/Response sono "come comunicare il risultato"; la loro successione interna è meno critica.

Un'osservazione empirica dalla mia sandbox: mettere Response alla fine aiuta perché l'attention ha recency bias (vedi articolo dentro un Transformer), e Response è ciò che il modello deve produrre subito dopo il prompt user. Mettere Context alla fine spesso degrada l'accuracy perché il contesto operativo viene "sopraffatto" dal recency dei vincoli di formato.

Regola pratica: C-O prima (priming), Response alla fine (recency), S-T-A al centro come stabilizzatori di stile.

Ripetizione strategica di istruzioni critiche

Un trucco che emerge in molti progetti enterprise ma non è nel framework standard: ripetizione. Istruzioni critiche (compliance, vincoli di sicurezza, formato obbligatorio) sono ripetute due-tre volte nel prompt, in posizioni diverse.

Perché funziona. L'attention distribuisce il peso su tutti i token; una regola ripetuta ha peso aggregato maggiore, il modello la rispetta più consistentemente. È lo stesso principio della Constitutional AI dove i principi sono enfatizzati tramite ridondanza.

Esempio operativo. Una regola "mai fornire consulenza legale specifica" va messa nel Context (setup), richiamata nell'Objective (cosa non fare), e riconfermata nel Response (cosa non includere nell'output). Tre occorrenze in un prompt di 400 parole, tre leve di attention sul vincolo.

Trade-off. La ripetizione aumenta leggermente i token; il gain in compliance supera il costo su task ad alto rischio.

Come integrare CO-STAR nella tua pipeline di versioning prompt

Il prompt CO-STAR è codice. Versionalo come codice.

• Un file system.md per ogni pipeline, con i sei blocchi CO-STAR separati da heading.
• Cambio di versione alla modifica di un blocco (minor per text tweaks, major per ristrutturazioni).
• Held-out di 50-200 esempi reali, rigirato a ogni cambio, con accuracy diff esplicito.
• CHANGELOG del prompt con motivazione di ogni modifica.
• Prompt caching key stabilizzato sui blocchi che non cambiano spesso (tipicamente Context, Style, Tone).

CO-STAR è una disciplina, non una bacchetta magica. Un prompt CO-STAR ben scritto migliora significativamente la qualità di un prompt enterprise, ma non compensa un LLM sottodimensionato o un retrieval RAG rotto. È uno dei pezzi della pipeline, il pezzo che costa zero implementare e paga il massimo ROI nel breve termine. Se hai una pipeline LLM in produzione con prompt disordinati e vuoi portarli allo standard CO-STAR con misurazione oggettiva del gain, il modulo di preventivo gratuito ti risponde in due minuti se il caso rientra nel mio ambito. Il prompt engineering del 2026 non è arte: è ingegneria disciplinata con framework verificabili, e CO-STAR è uno dei migliori framework disponibili sul mercato, semplice da capire, rigoroso da applicare, misurabile nei risultati in produzione reale italiana, e soprattutto raggiungibile da qualunque team IT interno senza bisogno di assumere un "prompt engineer" dedicato.