{"id":1405,"date":"2026-10-02T09:34:22","date_gmt":"2026-10-02T07:34:22","guid":{"rendered":"https:\/\/sites.unica.it\/ict4lawforensics\/?p=1405"},"modified":"2026-10-02T09:34:22","modified_gmt":"2026-10-02T07:34:22","slug":"multi-token-prediction-la-nuova-sfida-per-la-pubblica-amministrazione-tra-ottimizzazione-resilienza-e-controllo-dello-stato-interno","status":"publish","type":"post","link":"https:\/\/sites.unica.it\/ict4lawforensics\/2026\/10\/02\/multi-token-prediction-la-nuova-sfida-per-la-pubblica-amministrazione-tra-ottimizzazione-resilienza-e-controllo-dello-stato-interno\/","title":{"rendered":"Multi-Token Prediction: la nuova sfida per la Pubblica Amministrazione tra ottimizzazione, resilienza e controllo dello stato interno"},"content":{"rendered":"\n<p class=\"has-pale-ocean-gradient-background has-background wp-block-paragraph\">Non \u00e8 certo una novit\u00e0 che le Pubbliche Amministrazioni facciano affidamento, in misura sempre pi\u00f9 crescente, sui modelli avanzati di IA. Secondo il report del CERT-AgID (Computer Emergency Response Team dell&#8217;Agenzia per l&#8217;Italia Digitale) del giugno 2026, una nuova tecnologia emergente che permetterebbe di ridurre i tempi di risposta, il <em>Multi-Token Prediction<\/em> (MTP), potrebbe configurare un rischio per la sicurezza e la stabilit\u00e0 dei servizi della Pubblica Amministrazione. Vengono in soccorso a riguardo le bozze di linee guida AgID, le quali affrontano lo sviluppo dell\u2019IA lungo l\u2019intero ciclo di vita e lo collegano alle scelte di procurement, ponderando l\u2019adozione di queste nuove tecnologie.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sommario. <a href=\"#uno\">1. La svolta del MTP nel mondo dei Large Language Model: dal \u201cNext-Token\u201d al \u201cMulti-Token\u201d Prediction.<\/a> &#8211;<strong> <\/strong><a href=\"#due\">2. L&#8217;inferenza e i rischi operativi: il Report CERT-AgID.<\/a> &#8211; <a href=\"#tre\">3. I principi delle bozze di Linee Guida AgID.<\/a> &#8211; <a href=\"#quattro\">4. Gestione del rischio: i costi sono prevedibili? <\/a>&#8211; <a href=\"#cinque\">5. Il quadro normativo. <\/a><\/p>\n\n\n\n<h2 id=\"uno\" class=\"wp-block-heading has-primary-color has-text-color has-link-color wp-elements-1\"><strong>1. La svolta del MTP nel mondo dei Large Language Model: dal \u201cNext-Token\u201d al \u201cMulti-Token\u201d Prediction<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Tradizionalmente l\u2019addestramento dei modelli linguistici si basava sul <em>next-token prediction<\/em>: si insegnava all\u2019intelligenza linguistica a indovinare la parola immediatamente successiva. Infatti nel decoding autoregressivo il modello normalmente produceva un token alla volta. Sebbene le implementazioni moderne utilizzino la KV cache, ossia una tecnica di ottimizzazione della memoria usata dai modelli di linguaggio basati su trasformatori, per evitare di calcolare integralmente le rappresentazioni precedenti, la generazione resta vincolata, data la natura sequenziale del processo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Nel contesto dei LLM un token \u00e8 l\u2019unit\u00e0 fondamentale di testo in cui il sistema scompone le parole per poterle leggere, elaborare e generare. Non necessariamente un token corrisponde a una parola intera; ci\u00f2 infatti dipende da come \u00e8 addestrato il <em>tokenizer<\/em> del modello. Ciascun token viene tradotto in un codice numerico univoco che la rete neurale elabora matematicamente. Pi\u00f9 precisamente il tokenizer associa una sequenza di caratteri a token, ai quali corrispondono ID numerici. Questi ID a loro volta vengono trasformati in rappresentazioni vettoriali. La capacit\u00e0 di un LLM di ricordare i messaggi precedenti viene misurata sempre in token. Nelle lingue occidentali possiamo dire che 100 token corrispondano a circa 75 parole (tipicamente per l\u2019inglese, lo stesso documento in italiano richiede pi\u00f9 token, quindi costa di pi\u00f9). Con l&#8217;MTP vediamo che il modello durante la generazione usa e gestisce questi token diversamente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Compreso questo limite, nel 2024 un team di ricercatori di FAIR (Facebook AI Research, il laboratorio di ricerca sull\u2019AI di Meta) sistematizza e porta su larga scala questa tecnologia. Il team pubblic\u00f2 un paper intitolato <em>&#8220;Better &amp; Faster Large Language Models via Multi-Token Prediction&#8221;<\/em>. I ricercatori compresero che addestrare il modello a indovinare solo il token immediatamente successivo lo affaticava nel pianificare la struttura a lungo termine di un testo. Meta ha affermato che i suoi modelli hanno ottenuto prestazioni migliori del 17% su MBPP e del 12% su HumanEval (benchmark usati per misurare le capacit\u00e0 di programmazione e di ragionamento dei modelli di IA) rispetto ai LLM comparabili che generano token uno alla volta; inoltre, i modelli hanno generato output tre volte pi\u00f9 velocemente. In realt\u00e0, come rappresentato nella Tabella 2, un tale miglioramento \u00e8 relativo esclusivamente ai modelli 13B; al contrario, in modelli piccoli (0.3B e 0.6B) il delta \u00e8 negativo, e dunque si pu\u00f2 affermare che in modelli a basso numero di parametri l\u2019uso di MTP peggiori le prestazioni.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&#8220;Durante l&#8217;addestramento, il modello predice quattro token futuri contemporaneamente, per mezzo di un tronco condiviso e quattro teste di output dedicate. Durante l&#8217;inferenza, impieghiamo solo la testa di output del token successivo. Facoltativamente, le altre tre teste possono essere utilizzate per accelerare i tempi di inferenza. (In basso) La predizione multi-token migliora la metrica pass@1 sul task di programmazione MBPP, in modo significativo all&#8217;aumentare delle dimensioni del modello. Le barre d&#8217;errore sono intervalli di confidenza al 90% calcolati mediante <em>bootstrapping<\/em> sui campioni del dataset.&#8221; (Gloeckle et al., 2024)<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La metrica pass@1 misura la probabilit\u00e0 che un singolo output sia stato generato correttamente da un modello di intelligenza artificiale al primo tentativo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Grafico 1<\/p>\n\n\n\n<figure class=\"wp-block-image size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"817\" height=\"445\" src=\"https:\/\/sites.unica.it\/ict4lawforensics\/files\/2026\/10\/image.gif\" alt=\"\" class=\"wp-image-1406\" style=\"aspect-ratio:1.8340807174887892;width:409px;height:auto\" srcset=\"https:\/\/sites.unica.it\/ict4lawforensics\/files\/2026\/10\/image.gif 817w, https:\/\/sites.unica.it\/ict4lawforensics\/files\/2026\/10\/image-300x163.png 300w, https:\/\/sites.unica.it\/ict4lawforensics\/files\/2026\/10\/image-767x418.png 767w\" sizes=\"auto, (max-width: 817px) 100vw, 817px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Grafico 2<\/p>\n\n\n\n<figure class=\"wp-block-image size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"765\" height=\"416\" src=\"https:\/\/sites.unica.it\/ict4lawforensics\/files\/2026\/10\/image-1.gif\" alt=\"\" class=\"wp-image-1407\" style=\"aspect-ratio:1.8413461538461537;width:383px;height:auto\" srcset=\"https:\/\/sites.unica.it\/ict4lawforensics\/files\/2026\/10\/image-1.gif 765w, https:\/\/sites.unica.it\/ict4lawforensics\/files\/2026\/10\/image-1-300x163.png 300w\" sizes=\"auto, (max-width: 765px) 100vw, 765px\" \/><figcaption class=\"wp-element-caption\"><em>Gloeckle, F., Youbi Idrissi, B., Rozi\u00e8re, B., Lopez-Paz, D., &amp; Synnaeve, G. (2024). Better &amp; Faster Large Language Models via Multi-Token Prediction. Proceedings of the 41st International Conference on Machine Learning (ICML), PMLR 235, 15706\u201315734 (pubblicato il 30 aprile 2024 su arXiv). <a href=\"https:\/\/arxiv.org\/abs\/2404.19737\" target=\"_blank\" rel=\"noopener\"><u>https:\/\/arxiv.org\/abs\/2404.19737<\/u><\/a><\/em><br>\u00a0<\/figcaption><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Attualmente DeepSeek-V3 adotta un obiettivo MTP nel proprio addestramento, ma si distingue da Meta per una implementazione diversa rispetto a quella originale: infatti mentre Gloeckle et al. predicono i token futuri in parallelo con teste indipendenti, invece DeepSeek-V3 li predice in sequenza, mantenendo la catena causale completa ad ogni livello di profondit\u00e0. Come affermato nel loro Technical Report, nella sezione 2.2 Multi-Token Prediction:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u201cIspirandoci a Gloeckle et al. (2024), abbiamo studiato e adottato un obiettivo di Multi-Token Prediction (MTP) per DeepSeek-V3, che estende l&#8217;ambito della predizione a pi\u00f9 token futuri per ciascuna posizione. Da un lato, un obiettivo MTP densifica i segnali di addestramento e pu\u00f2 migliorare l&#8217;efficienza nell&#8217;uso dei dati. Dall&#8217;altro, l&#8217;MTP pu\u00f2 consentire al modello di pianificare in anticipo le proprie rappresentazioni interne, per predire meglio i token futuri. La Figura 3 illustra la nostra implementazione dell&#8217;MTP. A differenza di Gloeckle et al. (2024), che predicono in parallelo D token aggiuntivi utilizzando teste di output indipendenti, noi prediciamo i token aggiuntivi in sequenza, mantenendo la catena causale completa a ogni profondit\u00e0 di predizione. In questa sezione presentiamo i dettagli della nostra implementazione dell&#8217;MTP.\u201d<\/p>\n\n\n\n<h2 id=\"due\" class=\"wp-block-heading has-primary-color has-text-color has-link-color wp-elements-2\"><strong>2. L&#8217;inferenza e i rischi operativi: il Report CERT-AgID<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">In fase di inferenza (dopo l\u2019apprendimento), l\u2019MTP viene spesso associato al <em>decoding<\/em> speculativo: il <em>draft model<\/em> (il modello secondario pi\u00f9 leggero) indovina velocemente in anticipo i successivi token, mentre il <em>target model<\/em> (il modello principale che controlla) prende la bozza creata dal <em>draft<\/em> e la verifica con un solo passaggio di calcolo. Infatti, mentre l\u2019MTP ha la capacit\u00e0 di predire molteplici token, il <em>decoding<\/em> speculativo definisce invece il meccanismo di verifica ed accettazione.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Nei LLM tradizionali il limite di velocit\u00e0 \u00e8 dato dalla potenza di calcolo della scheda video e soprattutto dalla velocit\u00e0 con cui la memoria sposta i dati da un chip all\u2019altro per calcolare i token. Ed \u00e8 in questa fase di inferenza che subentra l\u2019analisi del CERT-AgID: il <em>draft<\/em> propone ma deve essere il <em>target<\/em> a decidere. Il <em>draft<\/em> non deve mai diventare l\u2019autorit\u00e0 finale. Cosa succederebbe se cos\u00ec fosse? Non accelererebbe solo il processo, ma andrebbe a modificare le decisioni del modello principale, incidendo nei casi pi\u00f9 gravi anche sulla verificabilit\u00e0 del processo decisionale.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Il report del CERT-AgID si basa principalmente su uno scenario critico dal punto di vista della gestione dello stato, che si pu\u00f2 verificare durante l\u2019inferenza. Non si tratta di una anomalia ma di uno scenario fisiologico.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>La parziale accettazione:<\/strong> il <em>draft<\/em> propone tre token e, invece di accettarli tutti e tre (full accept) o rifiutarli tutti e tre (full reject), il <em>target<\/em> ne accetta solo una parte (partial accept). Cosa accadrebbe in questo caso? Il sistema dovrebbe integrare la parte corretta, scartare quella errata e riallineare lo stato interno per ripartire dal punto esatto. Qui nasce una complicazione: nel percorso MTP \u00e8 necessario tenere coerenti tra loro e sincronizzati sia lo stato interno del modello <em>target<\/em> sia quello del modello <em>draft<\/em>. Nel runtime questo disallineamento si presenta quando non restano coerenti vari elementi: la KV cache, il frontier logico, il sampler, token accettati e rifiutati. Infatti il punto di generazione ufficiale pu\u00f2 trovarsi temporaneamente pi\u00f9 avanti dello stato consolidato. La KV cache, gi\u00e0 citata precedentemente, \u00e8 una memoria interna del transformer e si comporta come un segnalibro del punto raggiunto. Il disallineamento avviene quando tale segnalibro ed il testo consolidato non indicano lo stesso punto.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Il rischio per la sicurezza si verifica quando il <em>runtime<\/em> considera i token proposti come se fossero gi\u00e0 stati verificati. Dall\u2019analisi condotta dalla CERT-AgID, quando il percorso dell\u2019MTP non \u00e8 stabile, si attivano due meccanismi di recupero:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Il <em>replay<\/em>:<\/strong> per cui il sistema deve rifare una parte del lavoro precedentemente svolto;<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Il <em>fallback<\/em>:<\/strong> per cui il <em>runtime<\/em> scarta il <em>decoding<\/em> speculativo pi\u00f9 veloce e torna al <em>decoding<\/em> classico.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Se questi due meccanismi risultano frequenti, la disponibilit\u00e0 peggiorer\u00e0. \u00c8 importante chiedersi cosa succede quando il <em>draft model<\/em> sbaglia spesso. Il costo computazionale resta controllato anche quando i prompt sono difficili? Infatti, un prompt difficile potrebbe portare il <em>draft<\/em> a sbagliare pi\u00f9 spesso, e il costo computazionale crescerebbe rispetto al caso normale.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Come \u00e8 stato anticipato precedentemente, il <em>draft model<\/em> non deve essere l\u2019autorit\u00e0 finale, ma deve generare delle ipotesi che il <em>target model<\/em> andr\u00e0 a convalidare. Per rendere il comportamento pi\u00f9 stabile, pi\u00f9 misurabile e facile da verificare, il <em>draft model<\/em> deve scegliere le proposte pi\u00f9 prevedibili, invece di spingere il <em>target<\/em> a intraprendere traiettorie pi\u00f9 delicate e pericolose. Il rischio \u00e8 nelle implementazioni di runtime che perdono il controllo dello <strong>stato<\/strong> <strong>interno<\/strong>.<br><\/p>\n\n\n\n<h2 id=\"tre\" class=\"wp-block-heading has-primary-color has-text-color has-link-color wp-elements-3\"><strong>3. I principi delle bozze di Linee Guida AgID<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Il report della CERT-AgID conclude la propria analisi con le seguenti domande:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>\u201cIl criterio finale di scelta non pu\u00f2 essere solo: \u00e8 pi\u00f9 veloce? Deve essere anche:<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>\u2022 \u00e8 ancora controllato?<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>\u2022 \u00e8 verificabile?<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>\u2022 mantiene il target come arbitro finale?<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>\u2022 resta stabile con input difficili?<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>\u2022 ha costi prevedibili?\u201d<\/em><em><\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A tal proposito, le domande con cui si chiude il report possono essere lette alla luce dei principi contenuti nelle bozze di linee guida AgID per lo sviluppo e per il procurement. I due documenti si pongono infatti in un rapporto di complementarit\u00e0: da una parte il report della CERT-AgID individua sul piano tecnico i criteri e le metriche con cui valutare un runtime MTP, dall\u2019altra le bozze di linee guida forniscono i principi e gli strumenti contrattuali con cui la PA pu\u00f2 esigerli in fase di sviluppo e di gara. Di seguito si propone una lettura che ricollega ciascuno criterio del report al principio corrispondente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Il <strong>Piano Triennale per l\u2019Informatica nella Pubblica Amministrazione 2024-2026<\/strong> ha introdotto un quadro specifico dedicato all\u2019Intelligenza Artificiale, individuando l\u2019aumento della consapevolezza delle Pubbliche Amministrazioni nell\u2019adozione delle tecnologie di IA e prevedendo la definizione di linee guida per promuoverne l\u2019adozione. Tale attivit\u00e0 si inserisce nelle competenze dell\u2019 AgID e nell\u2019iter previsto dall\u2019articolo 71 del Codice dell\u2019Amministrazione Digitale (CAD).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">AgID, con la <strong>Determinazione n. 17 del 17 febbraio 2025<\/strong>, ha avviato l\u2019iter di consultazione delle <em>Linee guida per l\u2019adozione dell\u2019Intelligenza Artificiale nella Pubblica Amministrazione<\/em>. Successivamente, con la <strong>Determinazione n. 43 del 10 marzo 2026<\/strong>, \u00e8 stato avviato l\u2019iter di consultazione delle <em>Linee guida per lo sviluppo<\/em> e delle <em>Linee guida per il procurement dell\u2019Intelligenza Artificiale nella Pubblica Amministrazione<\/em>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Questo approccio basato sullo stack tecnologico dell\u2019IA consente alla Pubblica Amministrazione di effettuare scelte consapevoli e controllabili, preservando l\u2019autonomia decisionale e operativa nel tempo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Vengono individuati 20 principi per l\u2019adozione, lo sviluppo e il procurement dei sistemi di IA.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Nel report della CERT-AgID si parla di:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Non opacit\u00e0:<\/strong> pu\u00f2 essere ricollegato al <strong>settimo principio (&#8220;Trasparenza, spiegabilit\u00e0 e documentazione&#8221;)<\/strong>: <em>&#8220;I sistemi devono essere sviluppati con meccanismi di <strong>spiegabilit\u00e0<\/strong> proporzionati al rischio e al contesto d\u2019uso. Le architetture devono consentire la documentazione separata e aggiornata di modelli, agenti, servizi e logiche di orchestrazione, <strong>favorendo la tracciabilit\u00e0 delle decisioni<\/strong>&#8220;<\/em>. <em>&#8220;Il procurement deve garantire accesso continuativo alla documentazione tecnica e funzionale, anche post-contratto mediante apposite clausole in fase di gara. I contratti devono prevedere obblighi di aggiornamento della documentazione in caso di modifica dei modelli, degli agenti o delle logiche decisionali&#8221;<\/em>.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">\u00c8 citabile anche il <strong>quattordicesimo principio (&#8220;Registrazioni &#8211; logging&#8221;)<\/strong>: <em>&#8220;I sistemi devono essere sviluppati con <strong>meccanismi di logging interoperabili, strutturati e verificabili mediante audit, che traccino decisioni, flussi di dati, interventi umani e interazioni tra agenti<\/strong>. <strong>I log devono essere indipendenti dall\u2019infrastruttura sottostante e conservabili anche in caso di migrazione o dismissione<\/strong>&#8220;<\/em>. <em>&#8220;I contratti devono garantire alla PA accesso completo ai log, diritti di audit e possibilit\u00e0 di esportazione in formati aperti. Il procurement deve evitare soluzioni che rendano i log non accessibili o vincolati a piattaforme proprietarie&#8221;<\/em>.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Verificabile:<\/strong> possiamo ricollegarlo al <strong>decimo principio (&#8220;Accuratezza&#8221;)<\/strong>: <em>&#8220;Lo sviluppo deve prevedere <strong>metriche di accuratezza misurabili, documentate e monitorabili nel tempo, in relazione al contesto d\u2019uso e al livello di rischio.<\/strong> I sistemi devono consentire l\u2019aggiornamento o la sostituzione dei modelli (anche tramite orchestrazione agentica) in caso di degrado delle prestazioni&#8221;<\/em>. <em>&#8220;<strong>I contratti devono includere SLA e KPI sull\u2019accuratezza, con meccanismi di intervento correttivo inclusa la sostituzione progressiva dei modelli.<\/strong> Il procurement deve evitare vincoli che impediscano l\u2019adeguamento delle prestazioni nel tempo&#8221;<\/em>.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Questo decimo principio richiede SLA e KPI misurabili, e il report del CERT-AgID fornisce esattamente l\u2019elenco delle metriche che una Pubblica Amministrazione pu\u00f2 mettere a contratto: acceptance rate, frequenza di replay e fallback, p95 di latenza, comportamento sotto prompt difficili. Infatti l\u2019analisi non si ferma alla latenza media ma misura anche la coda, calcolando i percentili p75 e p95.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Controllato dal target:<\/strong> <strong>tredicesimo principio (&#8220;Sorveglianza umana&#8221;)<\/strong>: <em>&#8220;I sistemi devono consentire <strong>un intervento umano effettivo, tempestivo e documentabile, anche a livello di orchestrazione dei servizi e degli agenti di IA.<\/strong> Lo sviluppo deve prevedere punti di controllo, modalit\u00e0 di override e meccanismi di arresto o riconfigurazione del sistema&#8221;<\/em>. <em>&#8220;<strong>Il procurement deve escludere soluzioni che impediscano il controllo umano sostanziale o che rendano l\u2019intervento umano solo formale.<\/strong> I contratti devono garantire accesso operativo agli strumenti di supervisione, senza dipendenze esclusive dal fornitore&#8221;<\/em>.<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Robusto nei casi peggiori:<\/strong> <strong>undicesimo principio (&#8220;Robustezza&#8221;)<\/strong>: <em>&#8220;I sistemi devono essere progettati con <strong>architetture modulari, resilienti e degradabili, in grado di mantenere livelli di servizio proporzionati anche in condizioni non ottimali. Lo sviluppo deve prevedere meccanismi di fallback, inclusa l\u2019esecuzione su infrastrutture CPU-only, architetture hardware-agnostic e la riallocazione dinamica dei componenti tramite orchestrazione<\/strong>&#8220;<\/em>. <em>&#8220;Il procurement deve favorire soluzioni componibili e sostituibili, riducendo il rischio di lock-in tecnologico. I contratti devono prevedere clausole di verifica ed eventualmente risoluzione contrattuale in caso di comportamenti non in linea con quanto previsto a livello contrattuale&#8221;<\/em>.<\/li>\n<\/ul>\n\n\n\n<h2 id=\"quattro\" class=\"wp-block-heading has-primary-color has-text-color has-link-color wp-elements-4\"><strong>4. Gestione del rischio: i costi sono prevedibili?<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Arrivati a questo punto, possiamo appunto citare il terzo principio (&#8220;La gestione del rischio&#8221;) presente nelle bozze di linee guida sul procurement. Infatti nello sviluppo e nel procurement, la PA deve condurre un\u2019analisi approfondita dei rischi non solo sotto il punto di vista dei profili tecnologici e organizzativi, ma valutando anche il rischio economico. Quindi in questo caso dove si configura il rischio? Come descritto nel report CERT-AgID un prompt difficile potrebbe portare il draft a sbagliare pi\u00f9 spesso. E nel Path MTP il costo dipende da quanto il draft riesce ad anticipare bene il target. Nel caso dunque di un prompt difficile ci sarebbero rifiuti, molteplici partial accept, pi\u00f9 riallineamenti dello stato interno e pi\u00f9 replay. Il rischio \u00e8 la crescita abnormale del costo computazionale. Per cui se l\u2019input viene costruito con l\u2019obiettivo di spingere il sistema verso questi casi costosi si <strong>potrebbe<\/strong> andare a creare una forma di <strong>Denial of Service applicativo<\/strong>: il sistema funziona ma viene portato a fare pi\u00f9 lavoro. Se il costo computazionale restasse controllato anche nei prompt difficili allora l\u2019MTP sarebbe pi\u00f9 sicuro da usare, tenendo anche in considerazione l\u2019integrit\u00e0 del comportamento e la disponibilit\u00e0.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Per comprendere al meglio tale rischio economico dobbiamo analizzare come vengono valutati i sistemi di IA. Infatti, le pratiche tradizionali si fondano su indicatori parziali: il costo per token, il costo per chiamata API, la fatturazione per ora di calcolo o, in alcuni casi, il <em>Total Cost of Ownership<\/em> (TCO). Ma questi indicatori non permettono di rappresentare in modo completo l\u2019impatto economico dell\u2019IA. Data la diffusione sempre pi\u00f9 crescente di modelli di servizio basati sul consumo, questi indicatori appaiono insufficienti per prevedere i costi. Come viene detto nella bozza di linee guida riguardante il procurement, <em>&#8220;le pubbliche amministrazioni dovrebbero adottare un approccio di valutazione economica fondato sull\u2019analisi di ciclo di vita dei sistemi di IA. Tale approccio consente di rappresentare in modo unitario i costi di investimento e quelli di esercizio, nonch\u00e9 di valutare la sostenibilit\u00e0 complessiva della soluzione&#8221;<\/em>. In questa prospettiva assume un rilievo interessante il concetto di <strong>Costo Livellato dell\u2019IA (<em>Levelized Cost of Artificial Intelligence<\/em> &#8211; LCOAI)<\/strong>, quale metrica proposta per l\u2019analisi economica comparativa delle diverse strategie di procurement e deployment. Tale metrica, introdotta dall\u2019economista Eliseo Curcio e riportata nello Strumento C delle bozze di linee guida sul procurement, esprime il rapporto tra il costo complessivo del ciclo di vita del sistema e l\u2019output produttivo che viene effettivamente generato. Il livellamento implica la somma sulla vita utile e lo sconto a un tasso.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Il LCOAI somma i costi di investimento iniziale (<em>CAPEX<\/em>) e i costi operativi ricorrenti(<em>OPEX<\/em>), dividendoli per il volume complessivo delle prestazioni erogate, calcolato sugli output effettivamente &nbsp;validi (<em>Q<\/em>). Nel caso venisse adottato l\u2019MTP si potrebbero presentare due tipologie di scenari, in base al modello di deployment scelto dalla Pubblica Amministrazione:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">-il runtime locale: la PA acquista l\u2019infrastruttura hardware, quindi il CAPEX \u00e8 fisso e l\u2019effetto dell\u2019MTP ricade sull\u2019 OPEX, dovendo considerare il carico di calcolo, i costi di manutenzione straordinaria legati all\u2019uso intensivo delle risorse; &nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">-as-a-service: il CAPEX \u00e8 quasi nullo (la PA non dovrebbe comprare alcun server perch\u00e8 l\u2019MTP sarebbe disponibile attraverso un servizio esterno) e l\u2019impatto \u00e8 interamente sull\u2019 OPEX variabile (riguardante il consumo di API, il monitoraggio e il loggin al servizio esterno). In questo scenario il costo dei token scartati resta al fornitore ed il rischio per la PA si&nbsp; sposta sulla latenza (SLA). Per questo motivo \u00e8 fondamentale mettere il p95 a contratto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">L\u2019adozione di una metrica di costo livellato permette alla PA di confrontare modelli di fornitura diversi su basi omogenee. Nel path MTP, nel caso di runtime, l\u2019aumento dei costi di esercizio fa s\u00ec che il costo totale cresca mentre l\u2019output valido (Q) rimane invariato, quindi il LCOAI peggiora anche se il sistema continua a rispondere correttamente.<\/p>\n\n\n\n<h2 id=\"cinque\" class=\"wp-block-heading has-primary-color has-text-color has-link-color wp-elements-5\"><strong>5. Il quadro normativo<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La resilienza, richiesta dall\u2019articolo 15 del Regolamento UE 2024\/1689 (AI Act) \u201cAccuratezza, robustezza, cybersicurezza\u201d, non si esaurisce nella capacit\u00e0 del sistema di evitare errori o guasti evidenti, ma comprende anche la tenuta delle sue prestazioni di fronte a input costruiti ad hoc per sfruttarne le vulnerabilit\u00e0. Tale articolo non disciplina specificamente il caso del DoS applicativo, il quale presenta alcune analogie con la logica dell\u2019adversarial example, pur distinguendosi per l\u2019obiettivo: il DoS non mira ad ottenere un errore del modello ma a modificare il profilo computazionale dell\u2019inferenza. Solitamente si pensa ad un input costruito per ottenere un output scorretto, in questo caso invece l\u2019input \u00e8 costruito per ottenere un output corretto ma costosissimo da produrre. Dunque, interpretando l\u2019articolo in tal maniera, pare necessario evidenziare i paragrafi 4&amp;5:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u201c4.&nbsp;&nbsp;&nbsp;<strong>I sistemi di IA ad alto rischio sono il pi\u00f9 resilienti possibile per quanto riguarda errori, guasti o&nbsp;incongruenze che possono verificarsi all&#8217;interno del sistema o&nbsp;nell&#8217;ambiente in cui esso opera, in particolare a&nbsp;causa della loro interazione con persone fisiche o&nbsp;altri sistemi. A&nbsp;tale riguardo sono adottate misure tecniche e&nbsp;organizzative.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>La robustezza dei sistemi di IA ad alto rischio pu\u00f2 essere conseguita mediante soluzioni tecniche di ridondanza, che possono includere piani di backup o&nbsp;fail-safe.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">I sistemi di IA ad alto rischio che proseguono il loro apprendimento dopo essere stati immessi sul mercato o&nbsp;messi in servizio sono sviluppati in modo tale da eliminare o&nbsp;ridurre il pi\u00f9 possibile il rischio di output potenzialmente distorti che influenzano gli input per operazioni future (feedback loops&nbsp;&#8211; \u00abcircuiti di feedback\u00bb) e&nbsp;garantire che tali circuiti di feedback siano oggetto di adeguate misure di attenuazione.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">5.&nbsp;&nbsp;<strong>&nbsp;I sistemi di IA ad alto rischio sono resilienti ai tentativi di terzi non autorizzati di modificarne l&#8217;uso, gli output o&nbsp;le prestazioni sfruttando le vulnerabilit\u00e0 del sistema.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Le soluzioni tecniche volte a&nbsp;garantire la cibersicurezza dei sistemi di IA ad alto rischio sono adeguate alle circostanze e&nbsp;ai rischi pertinenti.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Le soluzioni tecniche finalizzate ad affrontare le vulnerabilit\u00e0 specifiche dell&#8217;IA includono, ove opportuno, misure volte a&nbsp;prevenire, accertare, rispondere, risolvere e&nbsp;controllare gli attacchi che cercano di manipolare il set di dati di addestramento (data poisoning&nbsp;&#8211; \u00abavvelenamento dei dati\u00bb) o&nbsp;i componenti preaddestrati utilizzati nell&#8217;addestramento (model poisoning&nbsp;&#8211; \u00abavvelenamento dei modelli\u00bb), <strong>gli input progettati in modo da far s\u00ec che il modello di IA commetta un errore (adversarial examples&nbsp;&#8211; \u00abesempi antagonistici\u00bb,<\/strong> o&nbsp;model evasion,&nbsp;&#8211; \u00abevasione dal modello\u00bb), gli attacchi alla riservatezza o&nbsp;i difetti del modello.\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Verso la stessa traiettoria porta l\u2019articolo 3 della Legge 132\/2025, riguardante la ricerca, la sperimentazione, lo sviluppo, l\u2019adozione l\u2019applicazione e l\u2019utilizzo di sistemi e modelli di Intelligenza Artificiale <strong>&nbsp;per finalit\u00e0 generali,<\/strong> che al sesto comma afferma:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>\u201c<\/em><em>Al fine di garantire il rispetto dei diritti e dei principi di cui al presente articolo <strong>deve essere assicurata, quale precondizione essenziale, la cybersicurezza lungo tutto il ciclo di vita dei sistemi e dei modelli di intelligenza artificiale per finalit\u00e0 generali, secondo un approccio proporzionale e basato sul rischio<\/strong>, nonch\u00e9 <strong>l&#8217;adozione di specifici controlli di sicurezza,<\/strong> anche al fine di assicurarne <strong>la resilienza contro tentativi di alterarne l&#8217;utilizzo, il comportamento previsto, le prestazioni o le impostazioni di sicurezza.\u201d<\/strong><\/em><strong><em><\/em><\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La resilienza \u00e8 un requisito di sicurezza, non un optional prestazionale. Per cui, in questa ottica, si comprende appieno la natura del rischio analizzato: il Denial of Service applicativo, qui discusso, sfugge alla categoria classica di adversarial example proprio perch\u00e9 non produce un errore, ma un costo ed \u00e8 per questo che solo una lettura congiunta del report tecnico del CERT-AgID, dei principi delle bozze di linee guida AgID, dell\u2019articolo 15 AI Act e della metrica LCOAI riesce a renderlo visibile e governabile in sede di procurement.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Fonti e riferimenti essenziali<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AgID \u2013 Agenzia per l&#8217;Italia Digitale (2026). <em>Bozza di<\/em> <em>Linee guida per il procurement di sistemi di Intelligenza Artificiale nella Pubblica Amministrazione<\/em>. Bozza in consultazione pubblica dal 12 marzo 2026, fino all\u201911 aprile 2026 (Determinazione n. 43\/2026).<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/www.agid.gov.it\/sites\/agid\/files\/2026-03\/LLGG%20procurementper%20consultazione%20pubblica.pdf\">https:\/\/www.agid.gov.it\/sites\/agid\/files\/2026-03\/LLGG%20procurementper%20consultazione%20pubblica.pdf<\/a><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AgID \u2013 Agenzia per l&#8217;Italia Digitale (2026). <em>Bozza di<\/em> <em>Linee guida per lo sviluppo di sistemi di Intelligenza Artificiale nella Pubblica Amministrazione<\/em>. Bozza in consultazione pubblica dal 12 marzo 2026 fino all\u201911 aprile 2026 (Determinazione n. 43\/2026). <a href=\"https:\/\/www.agid.gov.it\/sites\/agid\/files\/2026-03\/LLGG_Sviluppo_per%20consultazione%20pubblica.pdf\">https:\/\/www.agid.gov.it\/sites\/agid\/files\/2026-03\/LLGG_Sviluppo_per%20consultazione%20pubblica.pdf<\/a><\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AgID \u2013 CERT-AgID (2026). <em>Sicurezza e performance nel path MTP. Quando accelerare un LLM diventa anche un problema di affidabilit\u00e0<\/em>. Giugno 2026. <a href=\"https:\/\/www.agid.gov.it\/sites\/agid\/files\/2026-06\/Sicurezza%20e%20performance%20nel%20path%20MTP.pdf\">Sicurezza e performance nel path MTP.pdf<\/a><\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Curcio, E. (2025). <em>Introducing LCOAI: A Standardized Economic Metric for Evaluating AI Deployment Costs<\/em>. arXiv:2509.02596 (pubblicato il 29 agosto 2025). <a href=\"https:\/\/arxiv.org\/abs\/2509.02596\">https:\/\/arxiv.org\/abs\/2509.02596<\/a><\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DeepSeek-AI (2024). <em>DeepSeek-V3 Technical Report<\/em>. arXiv:2412.19437. <a href=\"https:\/\/arxiv.org\/pdf\/2412.19437\">https:\/\/arxiv.org\/pdf\/2412.19437<\/a> Testo originale della sezione 2.2: \u201cMulti-Token Prediction Inspired by Gloeckle et al. (2024), we investigate and set a Multi-Token Prediction (MTP) objective for DeepSeek-V3, which extends the prediction scope to multiple future tokens at each position. On the one hand, an MTP objective densifies the training signals and may improve data efficiency. On the other hand, MTP may enable the model to pre-plan its representations for better prediction of future tokens. Figure 3 illustrates our implementation of MTP. Different from Gloeckle et al. (2024), which parallelly predicts \ud835\udc37 additional tokens using independent output heads, we sequentially predict additional tokens and keep the complete causal chain at each prediction depth. We introduce the details of our MTP implementation in this section.\u201d<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Gloeckle, F., Youbi Idrissi, B., Rozi\u00e8re, B., Lopez-Paz, D., &amp; Synnaeve, G. (2024). <em>Better &amp; Faster Large Language Models via Multi-Token Prediction<\/em>. Proceedings of the 41st International Conference on Machine Learning (ICML), PMLR 235, 15706\u201315734 (pubblicato il 30 aprile 2024 su arXiv). <a href=\"https:\/\/arxiv.org\/abs\/2404.19737\">https:\/\/arxiv.org\/abs\/2404.19737<\/a><\/li>\n<\/ul>\n\n\n\n<p class=\"is-style-info wp-block-paragraph\"><strong>Di Beatrice Meloni<\/strong>                                                                                                                                                                                            <em>Studentessa in Giurisprudenza presso l&#8217;Universit\u00e0 degli Studi di Cagliari. <\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Non \u00e8 certo una novit\u00e0 che le Pubbliche Amministrazioni facciano affidamento, in misura sempre pi\u00f9 crescente, sui modelli avanzati di IA. Secondo il report del CERT-AgID (Computer Emergency Response Team dell&#8217;Agenzia per l&#8217;Italia Digitale) del giugno [&hellip;]<\/p>\n","protected":false},"author":10431,"featured_media":1408,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_coblocks_attr":"","_coblocks_dimensions":"","_coblocks_responsive_height":"","_coblocks_accordion_ie_support":"","footnotes":""},"categories":[50],"tags":[57,14,36,59,58],"class_list":["post-1405","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-approfondimenti","tag-agid","tag-cybersecurity","tag-law","tag-pa","tag-token"],"_links":{"self":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts\/1405","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/users\/10431"}],"replies":[{"embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/comments?post=1405"}],"version-history":[{"count":1,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts\/1405\/revisions"}],"predecessor-version":[{"id":1409,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts\/1405\/revisions\/1409"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/media\/1408"}],"wp:attachment":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/media?parent=1405"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/categories?post=1405"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/tags?post=1405"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}