Un modello linguistico non deve scrivere nel vostro gestionale. Deve proporre, e qualcosa deve poterlo bloccare

Come innestare un'IA su un magazzino che gira già, con la scrittura diretta esclusa per architettura, una soglia che decide da sola cosa applicare e cosa manda in revisione, e il registro che rende ogni suggerimento verificabile dopo il fatto.

di Nadia Maar · 31 agosto 2026

La domanda che arriva più spesso non è «possiamo usare l'IA per il magazzino», è «possiamo usarla senza che rompa quello che già funziona». Sono due domande diverse, e la seconda è quella giusta: un gestionale che gira da anni ha vincoli che nessuno ha scritto in un manuale — un fornitore che accetta ordini solo il martedì, uno sconto quantità che scatta a soglie precise, un margine minimo sotto cui un prodotto non si riordina mai. Un modello linguistico non conosce niente di tutto questo, e la tentazione di dargli accesso diretto al database «tanto capisce il contesto» è la stessa tentazione che ha già causato incidenti in altri sistemi, solo con un nome più nuovo.

La soluzione non è evitare l'IA, è metterla nel punto giusto della catena: propone, non decide. Il modello legge dati strutturati attraverso funzioni con uno schema preciso, mai una query libera; ogni proposta passa da una soglia di rischio che decide da sola se applicarla o mandarla a una persona; e ogni cosa — proposta, decisione, esito — resta scritta in un registro che si può controllare mesi dopo.

Questo pezzo è quell'architettura: il codice della funzione che il modello può chiamare e di quella che non può, la soglia che smista automatico da manuale, e perché il registro non è una formalità ma la differenza fra un sistema che si può fidare e uno che si spera funzioni.

1 · Perché la scrittura diretta è l'errore, non un dettaglio di sicurezza

Un modello linguistico non sbaglia come sbaglia il codice tradizionale — con un errore che si ripete uguale finché non lo si corregge. Sbaglia in modo diverso ogni volta, in un modo che dipende dalla formulazione della domanda, dal contesto fornito, da un aggiornamento del modello che nessuno ha chiesto. Dargli accesso a un `UPDATE` diretto su una tabella di magazzino significa accettare che, una volta su qualche migliaio, quell'`UPDATE` sia sbagliato in un modo che nessun test ha previsto perché nessun test può prevedere tutte le formulazioni possibili di una richiesta in linguaggio naturale.

• Le funzioni che il modello può chiamare sono un elenco chiuso e tipizzato — «proponi un riordino», «segnala un'anomalia di giacenza» — mai «esegui questa query». Il modello non genera SQL: genera argomenti per funzioni che qualcun altro ha scritto e che sanno esattamente quali tabelle toccare.
• Ogni funzione valida i propri argomenti PRIMA di fare qualsiasi cosa, con le stesse regole che varrebbero se la chiamata arrivasse da un umano distratto: quantità non negativa, fornitore esistente, budget non superato. Il modello può proporre un errore; la funzione non lo lascia passare.
• Niente di quello che il modello propone tocca il database finché non attraversa la soglia della sezione successiva. La proposta e l'esecuzione sono due passi separati, con un controllo in mezzo — non due righe dello stesso metodo.

La domanda da fare a ogni fornitore che propone un'integrazione IA

«Che cosa succede se il modello si sbaglia?» Se la risposta descrive un log da controllare dopo, la scrittura sta già succedendo prima del controllo. La risposta giusta descrive un passo che DEVE succedere prima che qualcosa cambi — non una rete di sicurezza sotto un errore già avvenuto.

2 · Il confine, in codice: che cosa il modello può chiedere

Lo schema qui sotto è quello che si passa al modello come «funzione disponibile». Non è documentazione: è un contratto — il modello può popolare solo questi campi, con questi tipi, e la funzione che riceve la chiamata rifiuta tutto quello che non rispetta lo schema prima ancora di guardare il contenuto.

funzioni-disponibili.ts

const proponiRiordino = {
  nome: "proponi_riordino",
  descrizione: "Propone il riordino di un prodotto sotto scorta minima. " +
    "Non esegue nulla: la proposta entra in coda di approvazione.",
  parametri: {
    type: "object",
    properties: {
      codiceProdotto: { type: "string", pattern: "^[A-Z]{2}-[0-9]{4,6}quot; },
      quantita: { type: "integer", minimum: 1, maximum: 5000 },
      fornitorePreferito: { type: "string" },
      motivazione: { type: "string", maxLength: 400 },
    },
    required: ["codiceProdotto", "quantita", "motivazione"],
    additionalProperties: false, // il modello non può aggiungere campi
                                  // non previsti, nemmeno per "essere utile"
  },
} as const

async function eseguiProponiRiordino(argomenti: unknown) {
  // Prima convalida: lo schema. Seconda convalida: le regole di dominio
  // che nessuno schema JSON può esprimere.
  const dati = SchemaRiordino.parse(argomenti) // lancia se non valido

  const prodotto = await getProdotto(dati.codiceProdotto)
  if (!prodotto) throw new Error("Prodotto inesistente: proposta scartata")

  const costoStimato = dati.quantita * prodotto.costoUnitario
  if (costoStimato > prodotto.budgetRiordinoMassimo) {
    // Il modello può proporre più del budget: la funzione non lo esegue,
    // lo declassa automaticamente a revisione manuale invece di rifiutarlo
    // in silenzio — la sezione 3 spiega perché la differenza conta.
    return accodaPerRevisione(dati, "supera il budget di riordino")
  }

  return valutaSoglia(dati, prodotto)
}

additionalProperties: false è la riga che impedisce al modello di «essere creativo» aggiungendo un campo non previsto — per esempio uno sconto che decide di applicare di sua iniziativa. Senza quella riga, uno schema JSON accetta comunque campi extra per default.

3 · La soglia: che cosa si applica da solo, che cosa aspetta una persona

Non tutte le proposte hanno lo stesso rischio. Riordinare 40 pezzi di un prodotto che si vende regolarmente, dentro il budget previsto, da un fornitore abituale, è una decisione che un magazziniere approverebbe in tre secondi senza pensarci — automatizzarla non toglie controllo, toglie lavoro ripetitivo. Riordinare 3.000 pezzi di qualcosa che non si muove da due mesi è una decisione che merita gli occhi di una persona, qualunque cosa dica il modello.

23 proposte di riordino in una giornata

Quantità e costo sono dentro le soglie configurate?

20 restano sotto soglia; 3 revisione manuale.

Tre proposte superano il budget di riordino o la quantità massima per quel prodotto. Non vengono rifiutate: vengono declassate a revisione, con la motivazione del modello a fianco. La differenza conta — un rifiuto silenzioso avrebbe fatto sparire l'analisi che il modello ha comunque svolto.

Fornitore abituale e storico di vendita regolare?

18 restano sotto soglia; 2 revisione manuale.

Due proposte riguardano un fornitore mai usato prima o un prodotto fermo da settimane. Sono esattamente i casi in cui il modello ha meno contesto storico su cui basarsi, e in cui una persona decide meglio in trenta secondi di quanto qualunque soglia automatica possa fare.

18 su 23 — Applicate senza intervento

Circa il 78%: riordini di routine che rispettano ogni vincolo, generati nel gestionale con la proposta dell'IA come motivazione registrata, e reversibili finché il fornitore accetta modifiche. Il tempo di una persona si concentra sulle cinque che contano davvero, invece di spalmarsi uguale su tutte e ventitré.

4 · Il registro: perché ogni proposta resta scritta, applicata o no

Sei mesi dopo, qualcuno chiederà perché il magazzino ha 400 pezzi di un prodotto che non si vende. Se la risposta è «non lo sappiamo, l'ha deciso il sistema», l'IA smette di essere uno strumento e diventa un sospetto permanente. Il registro esiste per rispondere con precisione: chi ha proposto che cosa, con quale motivazione, chi ha approvato o corretto, e quando.

Registro riordini · ultime 24 ore — 10-11 agosto 2026

23 proposte generate, 18 applicate in automatico, 5 in revisione

• ~6h/sett. — tempo di analisi manuale sostituito dalle proposte automatiche
• 22% — quota di proposte corrette o respinte in revisione, non applicate come suggerite
• 100% — proposte tracciate — nessuna scrittura sul gestionale senza una riga nel registro

Il numero che conta davvero è il 22%

Non è un tasso d'errore da minimizzare: è la prova che la soglia funziona. Se scendesse a zero, vorrebbe dire che la soglia sta lasciando passare tutto in automatico — non che il modello è diventato perfetto. Un sistema onesto con sé stesso manda in revisione una parte del proprio lavoro ogni giorno, per costruzione.

Mezz'ora sul vostro processo, prima di collegare qualsiasi modello

Se avete un processo ripetitivo che vorreste alleggerire con l'IA — riordini, controlli, smistamento — portate un esempio reale di dieci decisioni passate. In mezz'ora vediamo quante rientrerebbero sotto una soglia automatica e quante meriterebbero comunque una persona.

Se il vostro processo cambia raramente e ha meno di una decina di casi eccezionali all'anno, ve lo dico: probabilmente non vi serve un modello linguistico, vi bastano delle regole scritte a mano — più prevedibili, più economiche da mantenere, e altrettanto automatiche.

Il servizio dietro questo articolo

Sviluppo agenti AI per aziende

Se vi è servito questo, continuate da qui

• Un agente AI nei processi aziendali: dove funziona davvero, quanto costa, e i tre casi in cui è la scelta sbagliata — Non un chatbot sul sito. Un agente che legge i vostri dati, risponde citando la fonte e passa la mano a una persona quando non sa — con i numeri per capire se conviene.
• Dall'ordine alla fattura elettronica senza ricopiare niente: come si collega un e-commerce al Sistema di Interscambio — Quando la fattura serve e quando no, quali dati chiedere al checkout, chi deve numerare, che cosa succede con resi e scarti — e dove quasi tutti i collegamenti si rompono.

FAQ

È sicuro dare a un modello linguistico accesso al gestionale aziendale?

Non con un accesso diretto in scrittura. L'architettura sicura limita il modello a un elenco chiuso di funzioni tipizzate — «proponi un riordino», mai «esegui questa query» — ognuna delle quali valida i propri argomenti secondo le regole di dominio prima di fare qualunque cosa. Il modello genera argomenti per funzioni scritte da altri, non codice eseguibile.

Come si decide quali azioni dell'IA si applicano da sole e quali servono revisione umana?

Con una soglia di rischio su più criteri insieme — quantità, costo, affidabilità del fornitore, storico del prodotto. Su un magazzino con vendite stabili, la maggioranza delle proposte di routine passa la soglia ed è automatica; qualunque criterio fuori soglia manda la proposta in coda di revisione con la motivazione del modello a fianco.

Come si controlla dopo il fatto che cosa ha deciso l'IA e perché?

Con un registro che scrive ogni proposta, applicata o no: chi l'ha generata, con quale motivazione, chi l'ha approvata o corretta, e quando. Senza questo registro, ogni domanda su una decisione passata resta senza risposta verificabile — e l'IA smette di essere uno strumento per diventare un sospetto permanente.

Un'IA che sbaglia sempre nello stesso modo si può correggere come un bug?

No, ed è la differenza principale col software tradizionale: un modello linguistico sbaglia in modo diverso a seconda della formulazione della richiesta e del contesto, non con un errore ripetibile. Per questo il controllo non può essere «correggere il bug dopo averlo trovato»: deve essere una soglia che impedisce l'esecuzione prima che l'errore, qualunque forma prenda, tocchi i dati veri.

Nadia Maar