Un semplice modello mentale di come l'IA “pensa” quando costruisce app

Cosa significa “l'IA pensa” per chi costruisce app

Quando la gente dice “l'IA pensa”, generalmente intende qualcosa del tipo: capisce la tua domanda, ragiona su di essa e poi decide una risposta.

Per le AI testuali moderne (LLM), un modello mentale più utile è più semplice: il modello predice quale testo dovrebbe venire dopo.

Questo può sembrare deludente—fino a che non si vede fino a dove può arrivare quel “testo successivo”. Se il modello ha appreso abbastanza schemi durante l'addestramento, prevedere la parola successiva (e la successiva, e così via) può produrre spiegazioni, piani, codice, riassunti e persino dati strutturati che la tua app può usare.

L'obiettivo: un modello per chi costruisce, non per la matematica

Non devi imparare tutta la matematica sottostante per sviluppare buone funzionalità AI. Ciò che ti serve è un modo pratico per anticipare il comportamento:

• Perché lo stesso prompt può dare risposte diverse
• Perché le risposte possono suonare sicure ma essere sbagliate
• Perché piccole modifiche al prompt possono cambiare molto i risultati
• Quando dovresti aggiungere dati esterni o strumenti invece di “chiedere più forte”

Questo articolo è quel tipo di modello: niente hype, niente paper tecnici approfonditi—solo i concetti che ti aiutano a progettare esperienze prodotto affidabili.

Come si manifesta il “pensiero” in un'app

Dal punto di vista di chi costruisce, il “pensiero” del modello è il testo che genera in risposta all'input che gli dai (il tuo prompt, i messaggi utente, le regole di sistema e qualsiasi contenuto recuperato). Il modello di default non verifica i fatti, non naviga il web e non “sa” cosa contiene il tuo database a meno che tu non passi quelle informazioni.

Imposta le aspettative di conseguenza: gli LLM sono estremamente utili per redigere, trasformare e classificare testo e per generare output simili al codice. Non sono motori magici della verità.

I pezzi che useremo

Divideremo il modello mentale in alcune parti:

• Token (i frammenti di testo che predice)
• Finestra di contesto (ciò che può “tenere a mente” in una volta)
• Probabilità (perché gli output variano)
• Strumenti e retrieval (come collegare il modello ad azioni reali e fatti reali)
• Feedback e valutazione (come rendere gli output affidabili)

Con queste idee puoi progettare prompt, UI e salvaguardie che rendono le funzionalità AI coerenti e affidabili.

Il ciclo principale: predizione del token successivo

Quando si dice che un'AI “pensa”, è facile immaginarla che ragiona come una persona. Un modello mentale più utile è più semplice: fa un autocomplete estremamente rapido—un piccolo pezzo alla volta.

Cos'è un token?

Un token è un frammento di testo con cui il modello lavora. A volte è una parola intera (“mela”), a volte una parte di parola (“app” + “le”), a volte una punteggiatura e a volte anche uno spazio. La frammentazione esatta dipende dal tokenizer del modello, ma la conclusione è: il modello non elabora il testo come frasi ordinate—elabora token.

Predici il token successivo, poi ripeti

Il ciclo centrale del modello è:

1. Leggere i token che gli hai fornito (il tuo prompt e la conversazione precedente).
2. Predire il token successivo più probabile.
3. Aggiungere quel token al testo.
4. Trattare il nuovo testo, ora più lungo, come input e ripetere.

Questo è tutto. Ogni paragrafo, elenco puntato e catena di “ragionamento” che vedi è costruita ripetendo questa predizione del token successivo molte volte.

“Pensare” = autocomplete guidato

Poiché il modello ha visto enormi quantità di testo durante l'addestramento, impara schemi come il flusso tipico di una spiegazione, come suona un'email cortese o come viene descritto di solito un fix. Quando fai una domanda, genera una risposta che si adatta agli schemi appresi e che corrisponde al contesto fornito.

Questo è il motivo per cui può sembrare sicuro e coerente anche quando sbaglia: ottimizza per quale testo dovrebbe venire dopo, non per verificare la realtà.

Anche il codice è fatto di token

Il codice non è speciale per il modello. JavaScript, SQL, JSON e messaggi di errore sono tutti sequenze di token. Il modello può produrre codice utile perché ha imparato schemi comuni di programmazione, non perché “capisca” la tua app come farebbe un ingegnere del tuo team.

Da dove vengono le risposte: schemi appresi nell'addestramento

Quando qualcuno chiede “da dove ha preso quella risposta il modello?”, il modello mentale più utile è: ha imparato schemi da un'enorme quantità di esempi e ora ricombina quegli schemi per predire quale testo dovrebbe venire dopo.

L'addestramento è apprendimento di schemi, non memorizzazione

Durante l'addestramento, al modello vengono mostrati molti frammenti di testo (libri, articoli, codice, documentazione, Q&A e altro). Si esercita ripetutamente in un compito semplice: dato un testo, predire il token successivo. Quando sbaglia, il processo di addestramento aggiusta i parametri interni in modo che la previsione successiva sia un po' più probabile.

Col tempo, quegli aggiustamenti si accumulano. Il modello inizia a codificare relazioni come:

• Come vengono comunemente spiegati i concetti (“una finestra di contesto è…”)
• Quali termini tendono a comparire insieme (API, autenticazione, token)
• Strutture tipiche per le risposte (definizioni, passaggi, esempi)
• Schemi nel codice (come si forma di solito una query SQL)

Perché può generalizzare

Perché impara regolarità statistiche—non uno script fisso—può combinare schemi in modi nuovi. Se ha visto molti esempi di “spiegare un concetto” e molti esempi del “tuo scenario app”, spesso può fonderli in una risposta su misura.

Per questo un LLM può scrivere una plausibile email di onboarding per un prodotto di nicchia o adattare una spiegazione di integrazione API a uno stack specifico. Non sta recuperando un paragrafo memorizzato; sta generando una nuova sequenza che corrisponde agli schemi appresi.

Non è un database incorporato di risposte esatte

Anche se nell'addestramento ci fosse un fatto specifico (per esempio, una fascia di prezzo o una policy interna), non dovresti presumere che il modello possa “consultarlo” in modo affidabile. L'addestramento non funziona come l'indicizzazione di una knowledge base interrogabile. È più vicino a una compressione: molti esempi vengono distillati in pesi che influenzano le predizioni future.

Ciò significa che il modello può sembrare certo su dettagli che in realtà sta indovinando sulla base di ciò che appare più spesso in contesti simili.

Gli schemi sono utili—ma non garantiscono la correttezza

L'apprendimento di schemi è potente per produrre testo fluido e rilevante, ma la fluidità non è la stessa cosa della verità. Il modello può:

• Confondere concetti simili
• Riempire dettagli mancanti con l'ipotesi “più probabile”
• Fornire informazioni obsolete o non adatte al contesto

Per chi costruisce app, la conclusione principale è: le risposte di un LLM provengono solitamente da schemi appresi, non da fatti verificati. Se la correttezza è importante, devi ancorare l'output con i tuoi dati e controlli (ne parleremo nelle sezioni successive).

Probabilità, casualità e perché le risposte variano

Quando un LLM scrive una risposta, non sta estraendo una singola “frase corretta” da un database. A ogni passo predice una gamma di possibili token successivi, ciascuno con una probabilità.

Se il modello scegliesse sempre il token singolarmente più probabile, le risposte sarebbero molto coerenti—ma anche ripetitive e a volte rigidamente innaturali. La maggior parte dei sistemi invece campiona dalle probabilità, il che introduce una casualità controllata.

Le manopole “creatività vs coerenza”

Due impostazioni comuni determinano quanto variano gli output:

• Temperature: temperature più alte distribuiscono la probabilità su più opzioni (più varietà); temperature basse concentrano le scelte sulle opzioni più probabili (più coerenza).
• Top‑p (nucleus sampling): il modello considera solo l'insieme più piccolo di token le cui probabilità sommate raggiungono p (es. 0.9). Un top‑p più basso restringe a scelte più sicure e prevedibili.

Se costruisci un'app, queste manopole servono meno a “essere creativi” in senso artistico e più a scegliere tra:

• Frazioni stabili e ripetibili (ottime per supporto clienti, policy, riassunti)
• Esplorazione più ampia (utile per brainstorming, naming, soluzioni alternative)

Un tono sicuro può comunque sbagliare

Poiché il modello ottimizza per testo plausibile, può produrre affermazioni che suonano certe—anche quando la premessa è incorretta o manca contesto. La sicurezza nel tono non è una prova. Per questo motivo le app spesso necessitano di ancoraggio (come retrieval) o passi di verifica per compiti fattuali.

Un esempio semplice: molti modi corretti per scrivere la stessa funzione

Chiedi a un LLM: “Scrivi una funzione JavaScript che rimuova duplicati da un array.” Potresti ottenere uno qualsiasi di questi, tutti validi:

// Option A: concise
const unique = (arr) => [...new Set(arr)];

// Option B: explicit
function unique(arr) {
  return arr.filter((x, i) => arr.indexOf(x) === i);
}

Scelte di campionamento diverse portano a stili differenti (conciso vs esplicito), compromessi diversi (velocità, leggibilità) e perfino comportamenti diversi su casi limite—il tutto senza che il modello “cambi idea”. Sta solo scegliendo tra molte continuazioni ad alta probabilità.

Finestra di contesto: la memoria di lavoro dell'AI

Quando si dice che un modello “ricorda” la conversazione, ciò che ha davvero è il contesto: il testo che può vedere in quel momento—il tuo ultimo messaggio, eventuali istruzioni di sistema e la porzione di chat precedente che ancora rientra nella finestra.

Cos'è la finestra di contesto

La finestra di contesto è un limite fisso su quanto testo il modello può considerare alla volta. Quando la conversazione si allunga abbastanza, le parti più vecchie escono dalla finestra e scompaiono dalla vista del modello.

Per questo vedrai comportamenti come:

• Dimentica un requisito menzionato all'inizio (“usa un tono amichevole”, “restituisci solo JSON”).
• Contraddice decisioni precedenti (nomi di variabili diversi, ipotesi cambiate).
• La chat deraglia lentamente mentre piccoli fraintendimenti si accumulano.

Perché le conversazioni lunghe deragliano senza sommari

Se continui ad aggiungere messaggi in un thread, stai competendo per uno spazio limitato. I vincoli importanti vengono spinti fuori dalla vista dalle nuove interazioni. Senza un sommario, il modello deve inferire cosa conta da quel che rimane visibile—quindi può sembrare sicuro mentre mancano dettagli chiave.

Una soluzione pratica è sintetizzare periodicamente: riaffermare l'obiettivo, le decisioni e i vincoli in un blocco compatto, poi continuare. Nelle app questo viene spesso implementato come “sommario della conversazione” che viene reinserito nel prompt.

Suggerimento di prompt: metti i vincoli vicino alla fine

I modelli tendono a seguire istruzioni che sono vicine all'output che stanno per generare. Quindi se hai regole da rispettare, mettile verso la fine del prompt—subito prima di “Ora produci la risposta.”

Se costruisci un'app, tratta questo come design di interfaccia: decidi cosa deve rimanere nel contesto (requisiti, preferenze utente, schema) e assicurati che sia sempre incluso—o riducendo lo storico della chat o aggiungendo un sommario compatto. Per più suggerimenti su come strutturare prompt, vedi /blog/prompting-as-interface-design.

Perché l'AI può sbagliare: testo fluente vs realtà

Gli LLM sono molto bravi a produrre testo che sembra la risposta che ti aspetteresti da uno sviluppatore competente. Ma “sembra giusto” non è la stessa cosa di “è giusto.” Il modello predice token plausibili, non verifica l'output rispetto al tuo codebase, alle tue dipendenze o al mondo reale.

Non esegue nulla di default

Se il modello suggerisce una correzione, un refactor o una nuova funzione, è comunque solo testo. Non esegue la tua app, non importa i pacchetti, non chiama la tua API e non compila il progetto a meno che tu non lo colleghi a uno strumento che possa farlo (per esempio un runner di test, un linter o un passaggio di build).

Questa è la contrasto chiave:

• Testo fluente: “Sembra una soluzione valida.”
• Verificato dall'esecuzione: “Il codice compila, i test passano e il comportamento corrisponde alle aspettative.”

Modalità di errore comuni nello sviluppo di app

Quando l'AI sbaglia, spesso lo fa in modi prevedibili:

• API o parametri inventati (metodi di libreria allucinati, firme di funzione sbagliate)
• Casi limite sbagliati (stati vuoti, fusi orari, gestione di null, limiti di paginazione)
• Import mancanti o setup (dipendenza dimenticata, path sbagliato, variabili d'ambiente mancanti)
• Errori logici sottili (off‑by‑one, condizioni booleane errate, nomi incoerenti)
• Assunzioni datate (comportamento del framework cambiato, configurazione deprecata)

Questi errori possono essere difficili da notare perché la spiegazione circostante è di solito coerente.

Regola pratica: fidati dopo la verifica

Tratta l'output dell'AI come una bozza veloce di un collega che non ha eseguito il progetto in locale. La fiducia deve crescere nettamente dopo che:

• esegui test unitari/integrati,
• lint/format/build,
• e verifichi il risultato con input reali.

Se i test non passano, considera la risposta del modello solo un punto di partenza, non una soluzione definitiva.

Gli strumenti trasformano le parole in azioni (e riducono le ipotesi)

Un modello di linguaggio è ottimo nel proporre cosa potrebbe funzionare—ma da solo continua a generare solo testo. Gli strumenti permettono a un'app con AI di trasformare quelle proposte in azioni verificate: eseguire codice, interrogare un database, recuperare documentazione o chiamare un'API esterna.

Cosa sono gli “strumenti” nella pratica

Nei flussi di lavoro per costruire app, gli strumenti solitamente sono:

• Esecuzione di codice (es. eseguire uno snippet Python, compilare un progetto, eseguire migrazioni)
• Ricerca nella documentazione (knowledge base interna, manuale prodotto, riferimenti API)
• Chiamata di API (pagamenti, email, CRM, feature flag, analytics)
• Lettura/scrittura file (modificare una config, generare un file di test)

Il cambiamento importante è che il modello non finge più di sapere il risultato—può verificare.

Il ciclo: proporre → verificare → aggiustare

Un modello mentale utile è:

1. Il modello propone un'azione (“Per trovare utenti inattivi, esegui questa query SQL…”)
2. Lo strumento esegue (la query viene eseguita, la suite di test gira, la documentazione viene recuperata)
3. Il modello si aggiusta in base all'output reale (messaggi di errore, risultati della query, test falliti)

Così si riduce l'incertezza. Se il linter segnala import non usati, il modello aggiorna il codice. Se i test falliscono, itera fino a che passano (o spiega perché non può farlo).

Esempi che mappano su app reali

• Query al database: il modello scrive SQL, lo strumento DB restituisce conteggi o errori e il modello rivede la query in modo sicuro.
• Lint/format: il modello modifica il codice, poi esegue eslint/ruff/prettier per confermare lo stile e rilevare problemi.
• Unit test: il modello scrive una funzione e un test, esegue la suite di test e poi corregge i casi limite emersi dai fallimenti.

Permessi: tratta gli strumenti come accesso di produzione

Gli strumenti possono essere potenti—e pericolosi. Applica il principio del minimo privilegio:

• Dai all'AI accesso in sola lettura di default (soprattutto ai database)
• Limita le API key ai permessi minimi e agli ambienti necessari
• Registra le chiamate agli strumenti e richiedi conferme per azioni distruttive (cancellazioni, rimborsi, invio email)

Gli strumenti non rendono il modello “più intelligente”, ma rendono l'AI della tua app più ancorata—perché può verificare, non solo narrare.

Retrieval (RAG): dare al modello i fatti giusti

Un modello di linguaggio è ottimo per scrivere, riassumere e ragionare sul testo che può “vedere”. Ma non conosce automaticamente le ultime modifiche al prodotto, le policy aziendali o i dettagli del conto di un cliente. Retrieval‑Augmented Generation (RAG) è una soluzione semplice: prima recupera i fatti più rilevanti, poi chiedi al modello di scrivere usando quei fatti.

RAG in parole semplici

Considera RAG come “AI con libro aperto”. Invece di chiedere al modello di rispondere dalla memoria, la tua app estrae rapidamente alcuni passaggi rilevanti dalla tua sorgente di fiducia e li aggiunge al prompt. Il modello genera poi una risposta ancorata al materiale fornito.

Quando usarla

RAG è un'ottima impostazione di default quando la correttezza dipende da informazioni esterne al modello:

• Documentazione prodotto, note di rilascio o articoli della knowledge base
• Policy interne (rimborsi, sicurezza, compliance)
• Dati specifici dell'utente (ordini, ticket, impostazioni account)
• Grandi knowledge base dove cercare è più efficiente che inserire tutto nel prompt

Se il valore della tua app dipende dalla “risposta giusta per la nostra azienda”, RAG è di solito preferibile a sperare che il modello indovini.

Il flusso di base

1. Recupera: trasforma la domanda dell'utente in una query di ricerca e prendi i migliori chunk rilevanti dal tuo store di contenuti (doc, DB, indice vettoriale).
2. Includi / cita: inserisci quei chunk nell'input del modello, spesso con titoli, timestamp o identificatori in modo da poter mostrare “da dove viene” l'informazione.
3. Genera: chiedi al modello di rispondere usando solo il contesto fornito (e di ammettere quando il contesto non basta).

Il limite principale

RAG è efficace quanto la qualità del recupero. Se la ricerca restituisce passaggi obsoleti, irrilevanti o incompleti, il modello può produrre con sicurezza una risposta sbagliata—ora “ancorata” a una fonte errata. In pratica, migliorare la qualità della retrieval (chunking, metadata, freschezza e ranking) spesso aumenta l'accuratezza più di quanto facciano i ritocchi al prompt.

Agenti: quando il modello guida un workflow multi‑passo

Un “agente” è semplicemente un LLM che gira in loop: fa un piano, compie un passo, osserva cosa è successo e decide cosa fare dopo. Invece di rispondere una volta sola, itera finché non raggiunge l'obiettivo.

Il ciclo più semplice di un agente

Un modello mentale utile è:

Pianifica → Esegui → Verifica → Revisione

• Pianifica: scomponi l'obiettivo in pochi passi (“trova i dati, riassumili, prepara l'email”).
• Esegui: esegui un passo—spesso chiamando uno strumento (ricerca, query DB, API calendario) o generando una bozza.
• Verifica: confronta il risultato con l'obiettivo (“ho davvero trovato l'ultima fattura del cliente?”).
• Revisione: aggiusta il piano e passa al passo successivo.

Questo loop trasforma un singolo prompt in un piccolo workflow. È anche il motivo per cui gli agenti possono sembrare più “indipendenti” della chat: il modello non si limita a generare testo, sceglie azioni e le sequenzia.

Condizioni di stop e salvaguardie

Gli agenti hanno bisogno di regole chiare per sapere quando fermarsi. Condizioni comuni di stop includono:

• Si raggiunge il criterio di successo (es. “la bozza email include il numero d'ordine e la data di consegna”).
• Si raggiunge un numero massimo di passi.
• Si esaurisce un budget di token o scade un timeout.
• Una chiamata a uno strumento fallisce ripetutamente.

Le salvaguardie sono i vincoli che mantengono il loop sicuro e prevedibile: strumenti consentiti, fonti permesse, passaggi di approvazione umana e formati di output richiesti.

Evitare loop senza fine

Poiché un agente può sempre proporre “un altro passo”, devi progettare per i casi di errore. Senza budget, timeout e limiti di passi, un agente può ripetersi in azioni ridondanti (“riprovare con una query leggermente diversa”) o accumulare costi.

Default pratici: limita le iterazioni, registra ogni azione, richiedi la validazione dei risultati degli strumenti e interrompi con una risposta parziale più quello che ha provato. Spesso è un design di prodotto migliore che lasciare l'agente in esecuzione indefinitamente.

Dove si inseriscono piattaforme come Koder.ai

Se costruisci con una piattaforma orientata al codice come Koder.ai, questo modello mentale “agente + strumenti” è particolarmente pratico. Non ti limiti a ricevere suggerimenti in chat—usando checkpoint (snapshot) e rollback l'assistente può aiutarti a pianificare feature, generare componenti React/Go/PostgreSQL o Flutter e iterare con punti di controllo in modo da muoverti velocemente senza perdere il controllo delle modifiche.

Prompting come design dell'interfaccia

Quando metti un LLM dietro a una funzionalità, il tuo prompt non è più “solo testo”. È il contratto d'interfaccia tra il prodotto e il modello: cosa il modello deve fare, cosa è autorizzato a usare e come deve rispondere affinché il tuo codice possa consumare l'output in modo affidabile.

Una mentalità utile è trattare i prompt come moduli UI. I buoni moduli riducono l'ambiguità, costringono le scelte e rendono ovvia l'azione successiva. I buoni prompt fanno lo stesso.

Checklist pratica per un prompt

Prima di rilasciare un prompt, assicurati che dichiari chiaramente:

• Obiettivo: com'è il successo (una frase).
• Input: quali dati riceve il modello (e cosa ignorare).
• Vincoli: tono, regole di sicurezza, limiti di lunghezza, requisiti obbligatori/negativi.
• Formato di output: esattamente come l'app deve ricevere la risposta per poterla analizzare.

Mostra un esempio per ancorare il comportamento

I modelli seguono schemi. Un modo efficace per “insegnare” il pattern desiderato è includere un singolo esempio di input buono e output buono (soprattutto se il compito ha casi limite).

Anche un solo esempio può ridurre i tentativi e impedire al modello di inventare un formato che l'interfaccia non può mostrare.

Preferisci output strutturati alla prosa

Se un altro sistema deve leggere la risposta, richiedila strutturata. Chiedi JSON, una tabella o punti rigidi.

You are a helpful assistant.

Task: {goal}
Inputs: {inputs}
Constraints:
- {constraints}
Output format (JSON):
{
  "result": "string",
  "confidence": "low|medium|high",
  "warnings": ["string"],
  "next_steps": ["string"]
}

Questo trasforma il “prompting” in design di interfaccia prevedibile.

Richiedi domande chiarificatrici quando servono

Aggiungi una regola esplicita come: “Se mancano requisiti chiave, poni domande chiarificatrici prima di rispondere.”

Quella singola linea può impedire output sicuri ma errati—perché il modello è autorizzato (e ci si aspetta) di fermarsi e chiedere i campi mancanti invece di indovinare.

Allinea il prompting al tuo workflow di sviluppo

Nella pratica, i prompt più affidabili rispecchiano il modo in cui il tuo prodotto builda e distribuisce. Per esempio, se la tua piattaforma supporta pianificazione prima, poi generazione delle modifiche, poi esportazione del codice o deployment, puoi rispecchiare ciò nel contratto del prompt (pianifica → produce diff/step → conferma → applica). La “planning mode” di Koder.ai è un buon esempio di come trasformare il processo in fasi esplicite riduca il drift e aiuti i team a revisionare le modifiche prima del rilascio.

Come costruire fiducia: test, valutazioni e uso sicuro nelle app

La fiducia non nasce dal fatto che un modello “suona” sicuro. Nasce dal trattare l'output AI come qualsiasi altra dipendenza del prodotto: misurata, monitorata e vincolata.

Valuta ciò che conta (non tutto)

Inizia con un piccolo insieme di compiti reali che la tua app deve svolgere bene. Poi trasformali in controlli ripetibili:

• Prompt gold: una lista curata di prompt + caratteristiche attese (o risposte esatte, quando possibile). Eseguile prima di ogni rilascio.
• Controlli in stile unit test: se il modello produce dati strutturati (JSON, campi, decisioni), verifica forma, chiavi richieste, range e valori consentiti.
• Controlli a campione: una revisione settimanale leggera delle conversazioni recenti per catturare nuovi modi di fallimento che i test non colgono.

Misura l'affidabilità nel tempo

Invece di chiederti “Va bene?”, monitora “Quanto spesso passa i test?” Metriche utili includono:

• Pass rate sui prompt gold (globale e per categoria).
• Controlli di regressione confrontando oggi vs settimana scorsa (o versione modello), così noti cambiamenti silenziosi.
• Tasso di successo degli strumenti (es. % di chiamate strumento che hanno restituito risultati utili).

Registra abbastanza per riprodurre i problemi

Quando qualcosa va storto, devi poterlo riprodurre. Registra (con opportuna redazione):

• Il template del prompt e il prompt finale renderizzato.
• Nome/versione del modello, temperature e istruzioni di sistema.
• Chiamate agli strumenti e risultati (input, output, errori, latenze).

Questo rende il debug praticabile e ti aiuta a rispondere: “È cambiato il modello o i nostri dati/strumenti?”

Nozioni di base di sicurezza per le app in produzione

Alcuni default prevengono incidenti comuni:

• Non inserire mai segreti (API key, password, token privati) nei prompt o nella cronologia della chat.
• Filtra o blocca output sensibili (dati personali, affermazioni mediche/legali, violazioni di policy) prima di mostrarli agli utenti.
• Aggiungi un chiaro percorso di fallback: quando la confidenza è bassa, poni domande chiarificatrici, mostra le fonti o passa a un umano.