Vendere una soluzione AI con l'iperammortamento

Il fornitore non concede l’iperammortamento e non può promettere che il cliente lo otterrà. Può però fare in modo che il cliente disponga degli elementi per chiederlo: un bene identificabile nell’offerta, una voce pertinente dell’allegato, un’interconnessione verificabile e documenti coerenti dalla comunicazione preventiva fino alla consegna.

Le tre verifiche descritte nell’articolo per chi compra diventano qui i compiti di chi vende: rendere il bene identificabile, interconnesso e documentato.

Prima dell’offerta: definire il bene

Il preventivo deve permettere di capire che cosa viene acquisito, che cosa resta un servizio e quale voce dell’allegato descrive il bene.

«Piattaforma AI» non è una classificazione sufficiente. L’allegato V nomina espressamente AI generativa e modelli linguistici di grandi dimensioni, AI agentica, MLOps, manutenzione predittiva e process mining. Contiene anche altre voci con requisiti propri. Il fornitore dovrebbe indicare la voce proposta e descrivere quali caratteristiche del prodotto la soddisfano, senza sostituirsi al professionista che le attesterà.

Una mappatura utile mette in relazione una funzione acquistata, il testo preciso della voce e le prove disponibili. Non basta indicare più voci alternative o fondare la corrispondenza su un’analogia commerciale: per ogni voce proposta occorre riprendere le caratteristiche richieste dall’allegato e indicare dove siano presenti nel bene consegnato.

La distinzione fra dd.1 e dd.2 va fatta prima di scrivere l’offerta. La prima comprende AI generativa e modelli linguistici anche per il supporto ai processi decisionali; non richiede autonomia. La seconda richiede che il bene sappia eseguire compiti complessi, orchestrare flussi di lavoro e operare con capacità decisionale automatizzata nei processi operativi.

Voce proposta	Funzione da documentare	Cautela
dd.1, AI generativa e LLM	generazione automatizzata di contenuti, documentazione tecnica o codice, oppure supporto ai processi decisionali	non occorre sostenere che il sistema agisca autonomamente
dd.2, AI agentica	compiti complessi eseguiti dal sistema, flussi di lavoro orchestrati e decisioni automatiche nel processo operativo	la legge non impone un’azione su sistemi esterni; un compito informativo può essere rilevante, ma la sola etichetta «agente» o l’assenza di scritture nei sistemi collegati non provano i tre requisiti

Per sola lettura si intende una modalità in cui il software consulta dati e documenti senza modificare archivi, registrare transazioni o avviare azioni nei sistemi collegati. Un compito informativo autonomo può rispettare questo limite e al tempo stesso scomporre una richiesta, scegliere le fonti da interrogare, formulare ricerche, incrociare i risultati, controllarne la coerenza e decidere come proseguire fino all’esito informativo.

La documentazione tecnica dovrebbe mostrare l’obiettivo affidato al sistema, i passaggi compiuti, le decisioni prese nel flusso, i controlli, le condizioni di arresto o correzione e il modo in cui il risultato entra nel processo aziendale. L’assenza di azioni esterne non esclude la dd.2; descrive soltanto gli effetti dell’attività. Occorre comunque provare che il software esegua un compito complesso, orchestri il flusso e operi con capacità decisionale automatizzata nel processo operativo. Una ricerca predefinita o la semplice presentazione della risposta di un modello non dimostrano queste caratteristiche.

Come documentare il processo

Un sistema informativo candidato alla dd.2 dovrebbe lasciare una prova leggibile del suo funzionamento. La documentazione tecnica può descrivere:

1. obiettivo, ingresso e risultato del compito, per mostrare che il sistema riceve un incarico completo e non esegue soltanto una singola ricerca;
2. piano e passaggi disponibili, compresi i criteri con cui il software sceglie l’ordine delle attività o modifica il percorso in base ai risultati;
3. fonti e strumenti selezionabili, con le regole di accesso e, quando pertinenti, le interrogazioni costruite per ottenere i dati;
4. decisioni intermedie, come la scelta del perimetro, della fonte, del confronto o del controllo successivo;
5. controlli e gestione degli errori, per esempio verifica di risultati vuoti o incoerenti, correzione del piano e condizioni di arresto;
6. traccia dell’esecuzione, con passaggi, strumenti usati, esiti e interventi umani, sufficiente a ricostruire che cosa è accaduto;
7. vincolo di sola lettura e permessi, che impedisca modifiche ai dati senza impedire al sistema di prendere le decisioni necessarie alla ricerca.

Questo elenco traduce i tre elementi della dd.2 in evidenze osservabili; non è un elenco prescritto dalla legge. Pianificazione, interrogazione, controllo e composizione della risposta possono formare un flusso operativo anche quando il risultato finale è informativo. Resta aperta la qualificazione del caso concreto, perché non esiste ancora una casistica ufficiale 2026 sui sistemi agentici in sola lettura.

Le prove necessarie per la dd.2

Il fornitore non deve aspettare il collaudo per domandarsi se le evidenze bastano. Prima dell’offerta conviene coinvolgere il professionista o l’ente che attesterà il bene, concordare il percorso di prova e fargli esaminare una versione identificata del prodotto. Questa verifica preventiva non sostituisce l’attestazione finale, che riguarda il bene effettivamente fornito e interconnesso, ma permette di scoprire in tempo ciò che manca.

Questa preparazione produce anzitutto un fascicolo del prodotto, riutilizzabile per le diverse forniture. Deve contenere:

1. la versione, i moduli e la configurazione che formano il bene;
2. una matrice di prova della dd.2 che associa «compito complesso», «orchestrazione del flusso» e «capacità decisionale automatizzata nel processo operativo» alle funzioni, al codice, ai test e alle tracce che li rendono osservabili;
3. l’architettura e il diagramma del flusso, comprese diramazioni, controlli, tentativi di correzione e condizioni di arresto;
4. il confine fra software acquisito, modelli esterni, hosting, manutenzione e altri servizi;
5. il manuale tecnico con permessi, controlli e modalità di registrazione delle esecuzioni.

Servono poi prove dell’intero processo, eseguite sulla versione candidata alla vendita. Almeno cinque casi mostrano comportamenti diversi: un compito complesso portato a termine; una richiesta ambigua che richiede un chiarimento; un’operazione vietata o fuori perimetro che viene bloccata; un errore che induce il sistema a correggere il piano o il risultato; un guasto che impone l’arresto. Per ogni caso si conservano ingresso, passaggi, strumenti, decisioni, controlli, risultato, versione, configurazione e data.

Queste tracce vanno previste nell’architettura prima del collaudo. La legge non prescrive questo elenco, ma ricostruirlo a posteriori rende la prova fragile. Il progetto deve anche stabilire chi può accedere ai registri, per quanto tempo conservarli e come proteggere i dati aziendali o personali che contengono.

Il cliente completa un fascicolo dell’installazione. Il documento deve descrivere il processo operativo nel quale il software svolge il compito: chi lo avvia, quali sistemi e dati usa, quali decisioni prende durante l’elaborazione, quale risultato produce e come quel risultato entra nel lavoro dell’impresa. Nello stesso fascicolo si documentano l’identificazione del bene, la sua entrata in funzione e la prova dell’interconnessione. La documentazione tecnica del prodotto può dimostrare le capacità generali; da sola non dimostra il loro impiego nel processo operativo del cliente né l’interconnessione della singola installazione.

«Fascicolo» indica qui una raccolta di documenti ed evidenze, non un documento con questo nome da caricare integralmente sul portale GSE. Prima dell’ordine, questa raccolta aiuta cliente, fornitore e attestatore a decidere se il progetto ha basi sufficienti. Dopo l’installazione alimenta la perizia o l’attestazione e deve essere conservato per eventuali integrazioni e controlli. Sulla piattaforma l’impresa trasmette invece le comunicazioni e gli allegati richiesti dai modelli vigenti.

Chi redige la perizia o l’attestazione può attestare la corrispondenza alla dd.2 quando verifica senza lacune il rapporto fra requisito normativo, funzione del bene, prova eseguita, traccia prodotta, processo operativo e installazione interconnessa. Se uno dei tre elementi della dd.2 non risulta dimostrato, il supporto decisionale può ancora essere valutato rispetto alla dd.1; le due voci non devono essere confuse.

La dd.2 non prova l’interconnessione

La prova dell’interconnessione è distinta. Anche un processo agentico ben documentato deve scambiare informazioni con il sistema aziendale di gestione della produzione oppure con la rete di fornitura ed essere identificato in modo univoco.

Il dubbio è particolarmente rilevante per i compiti informativi in sola lettura. Un software può consultare fonti, scegliere i passaggi e controllare il risultato senza modificare i sistemi collegati; queste capacità possono sostenere la valutazione della dd.2, ma non provano da sole l’interconnessione. Se il compito appartiene a un processo di lavoro intellettuale e non mostra un legame chiaro con il sistema di gestione della produzione o con la rete di fornitura, le fonti disponibili non danno ancora una risposta generale. Il fornitore deve descrivere il processo, i flussi di dati e l’uso del risultato, così che il cliente possa sottoporre il caso a chi redigerà la perizia o l’attestazione prima dell’ordine.

Separare il software dai servizi ricorrenti

L’offerta deve distinguere almeno:

• il bene o la licenza che il cliente acquisisce;
• configurazione, sviluppo e integrazione;
• formazione e assistenza;
• infrastruttura ospitata, consumo di modelli e altri canoni ricorrenti.

Questo confine del bene software non decide da solo il trattamento fiscale, ma impedisce che un unico prezzo nasconda spese di natura diversa. Serve soprattutto nei prodotti ospitati dal fornitore. La parola «cloud» compare nell’allegato V come tecnologia o architettura; la legge 2026 non ripete invece la vecchia previsione che comprendeva, a certe condizioni, i canoni per l’accesso a software cloud.

L’interrogazione parlamentare 5-05448 del 3 giugno 2026 chiede di rivedere proprio l’esclusione dei software in cloud e dei modelli as a service. La risposta del Governo del 4 giugno annuncia possibili soluzioni normative, ma non chiarisce il caso del software venduto separatamente dai servizi. Nel quadro vigente, il normale canone SaaS, il consumo di API e l’accesso a un modello AI as a service non rientrano come tali nell’iperammortamento. La scheda sintetica della serie ricostruisce la questione con le due fonti parlamentari.

La conclusione non cambia quando il contratto chiama il prodotto «licenza pluriennale» e il prezzo comprende, senza indicarli separatamente, i costi sostenuti dal fornitore per usare modelli AI. Se il cliente riceve soltanto l’accesso alla piattaforma gestita dal fornitore, la mancata esposizione di quei costi non trasforma il SaaS in un bene acquisito dal cliente.

Per rendere leggibile il perimetro, l’offerta deve esporre separatamente ogni componente:

Componente dell’offerta	Come presentarla
Diritto d’uso del software identificato	prezzo fisso e costo da sottoporre alle verifiche per l’iperammortamento
Configurazione e integrazione indispensabili	voce separata; la parte direttamente imputabile a rendere utilizzabile il bene può essere inclusa fra i costi da verificare soltanto se è correttamente capitalizzata
Sviluppi specifici	descrizione e prezzo separati; occorre stabilire se generano o completano il bene acquisito e se sono capitalizzabili
Manutenzione ordinaria e assistenza	servizio separato, escluso dalla base agevolabile
Formazione e cambiamento organizzativo	prestazioni separate dal costo del bene
Hosting	servizio separato, escluso dalla base agevolabile
API e consumo di modelli LLM esterni	servizio separato, escluso dalla base agevolabile
Diritto su un modello eseguito nell’infrastruttura del cliente	caso distinto dal consumo tramite API: identificare diritto, costo e voce dell’allegato e sottoporli a verifica; manca una risposta ufficiale generale

Preventivo, contratto, ordine e fatture devono conservare la stessa ripartizione, fondata sul valore reale delle componenti. Una licenza perpetua rende particolarmente netto il confine, ma non è una formula richiesta dalla legge e non garantisce il beneficio. L’OIC 24 comprende fra i beni immateriali le licenze e gli altri diritti identificabili; la capitalizzazione resta soltanto uno dei requisiti.

L’articolo 110 del TUIR comprende nel costo gli oneri accessori di diretta imputazione; l’OIC 24 include i costi collegati all’acquisto necessari perché l’immobilizzazione possa essere utilizzata. Il fornitore deve perciò descrivere attività e risultati, lasciando al cliente e al revisore la verifica di quali costi di configurazione o integrazione possano entrare nel costo del bene. La sola etichetta «servizi professionali» o «implementazione» non risolve il problema.

Il software deve costituire esso stesso un bene nuovo dell’allegato V ed essere interconnesso. La qualificazione è più solida quando il prodotto possiede funzioni proprie, codice, flussi, dati e integrazioni identificabili, mentre il LLM esterno è soltanto un componente. In questo caso il fornitore può presentare il prezzo del diritto software come costo da sottoporre a verifica e lasciare fuori il consumo del modello. Non basta invece rivendere, dietro un’interfaccia, l’accesso a un LLM.

Neppure la risposta all’interrogazione conferma o esclude in modo specifico questa configurazione. La qualificazione va quindi definita prima dell’ordine con il cliente e con chi redigerà la perizia. La manutenzione evolutiva che produce un nuovo bene o un ampliamento capitalizzabile richiede una valutazione separata.

Un modello eseguito nell’infrastruttura del cliente pone un problema analogo. Non c’è consumo tramite API, ma occorre ancora stabilire quale diritto sia stato acquisito, quale costo venga capitalizzato e quale voce dell’allegato descriva il bene. L’esecuzione interna, da sola, non rende il modello agevolabile.

La separazione delle voci non basta se il software non è interconnesso. Il contratto non deve promettere una generica integrazione con il sistema informativo aziendale: il progetto deve prevedere uno scambio di informazioni con il sistema aziendale di gestione della produzione oppure con la rete di fornitura e un’identificazione univoca del bene. Il fornitore deve permettere a chi prepara la perizia di osservare queste condizioni quando il bene è in esercizio.

Prima della comunicazione preventiva: raccogliere i dati del bene

Il GSE registra ogni bene con una descrizione, un costo, una categoria e date riferite alla struttura produttiva che lo userà.

Il modello di comunicazione preventiva pubblicato dal GSE chiede, per ciascun bene, la categoria dell’allegato IV o V, una descrizione, il costo di acquisizione, il coefficiente di ammortamento, la data prevista di completamento, la data prevista di interconnessione, la struttura produttiva e l’eventuale appartenenza a un bene complesso. La piattaforma genera poi un «Codice Bene».

Il cliente presenta la comunicazione, ma molti dati dipendono dal prodotto e dall’offerta. Il fornitore dovrebbe consegnarli in una scheda del bene coerente con il preventivo e con il contratto:

Dato	Che cosa prepara il fornitore	Chi ne risponde nella procedura
Identità del bene	nome, versione o istanza, componenti comprese e separazione dai servizi	l’impresa beneficiaria nella comunicazione; il tecnico nell’attestazione
Voce dell’allegato	proposta motivata con le caratteristiche tecniche corrispondenti	il tecnico verifica e attesta
Compiti e flussi, se si propone la dd.2	obiettivi, passaggi governati dal software, decisioni automatiche, controlli, correzioni, interventi umani e registri disponibili	il fornitore descrive ciò che il prodotto esegue; il tecnico verifica la corrispondenza con la voce
Costo	ripartizione fra bene e prestazioni, coerente con ordine e fatture	impresa e revisore per il sostenimento della spesa
Struttura produttiva	sede e sistemi con cui il bene verrà interconnesso	impresa beneficiaria
Date	piano realistico di consegna, entrata in funzione e interconnessione	impresa nella procedura, con i dati forniti dal fornitore

Il requisito che i beni fossero prodotti nell’Unione europea o nello Spazio economico europeo, presente nel testo originario della legge, è stato eliminato con effetto dal 1° gennaio 2026. Non va quindi chiesto al fornitore un dossier di origine per questa agevolazione.

Progettare un’interconnessione che si possa mostrare

Un’integrazione promessa non basta: lo scambio deve funzionare e produrre evidenze tecniche verificabili.

La circolare 4/E del 2017 applica il requisito anche ai beni immateriali. Richiede che il bene scambi informazioni con sistemi interni o esterni mediante specifiche documentate, disponibili pubblicamente e riconosciute a livello internazionale, e che sia identificato in modo univoco mediante standard riconosciuti.

Fra gli esempi la circolare cita TCP/IP, HTTP e MQTT. La presenza di un’API proprietaria non esclude quindi da sola l’interconnessione: il fornitore deve però documentare il protocollo di collegamento, i messaggi scambiati, la direzione dei flussi e l’identificativo univoco in modo che il tecnico possa verificarli.

Per rendere verificabili queste due condizioni, il fornitore può preparare un dossier di interconnessione composto da:

1. uno schema dell’architettura che mostri dove si trova il bene e quali sistemi aziendali o della filiera raggiunge;
2. l’identificativo dell’istanza e il metodo con cui resta riconoscibile;
3. l’elenco delle interfacce e dei protocolli, con la relativa documentazione;
4. esempi di messaggi o transazioni scambiati durante il collaudo;
5. registri tecnici datati che mostrino lo scambio in esercizio;
6. una descrizione dei flussi informativi e della funzione che svolgono nel processo.

La legge e la circolare fissano il principio. Questo elenco è una traduzione prudenziale per un progetto software, non un elenco ufficiale del GSE. Al 24 settembre 2026 non risultano pubblicate istruzioni specifiche per provare l’interconnessione di un sistema AI. Il tecnico incaricato va quindi coinvolto prima del collaudo, quando l’architettura può ancora essere corretta.

Dalla conferma dell’acconto al completamento

Ordine, acconto, fatture e bene consegnato devono descrivere in modo coerente la stessa fornitura.

Il DM 7 maggio 2026 prevede una comunicazione preventiva per ciascuna struttura produttiva. Dopo l’esito positivo, l’impresa ha sessanta giorni per confermare il pagamento di un acconto almeno pari al 20 per cento del costo di ogni bene. Il modello di conferma chiede gli estremi delle fatture. Non consente di aggiungere beni o di aumentarne il costo rispetto alla preventiva.

Questa è la sequenza della procedura, ma il decreto non afferma espressamente che l’ordine commerciale debba seguire la preventiva. Cliente e fornitore devono quindi concordare il calendario con il professionista fiscale prima di assumere impegni, così che ordine, acconto e fatture restino compatibili con la pratica GSE.

Una piattaforma centrale può servire più strutture produttive. Le fonti disponibili non spiegano ancora come assegnare in questo caso il bene, come ripartirne il costo o in quale struttura attestarne l’interconnessione. Non è un dettaglio da rinviare al collaudo: cliente, fornitore, fiscalista e tecnico incaricato devono risolverlo prima della comunicazione preventiva, perché condiziona la struttura produttiva indicata nella pratica e il costo associato.

L’investimento deve essere completato entro il 30 settembre 2028, secondo le regole dell’articolo 109 del TUIR. Dopo l’interconnessione, l’impresa presenta la comunicazione di completamento entro il 15 novembre 2028. Il secondo termine riguarda l’invio della comunicazione e non prolunga la data entro cui deve essere completato l’investimento. L’impresa deve inoltre inviare comunicazioni periodiche il 20 gennaio e il 30 giugno, fino alla fine della fruizione. La sezione documenti del GSE metteva a disposizione, alla data di verifica, la guida, la preventiva e la conferma. La guida indicava che le funzionalità per il completamento e le comunicazioni periodiche non erano ancora disponibili. L’elenco definitivo dei campi dovrà quindi essere aggiornato quando usciranno i modelli.

La coerenza documentale dell’investimento richiede che il fornitore mantenga la corrispondenza fra Codice Bene, ordine, acconto, fatture, versione consegnata, verbale di collaudo e prova dell’interconnessione. Se la soluzione cambia durante il progetto, il cliente deve sapere subito se è cambiata soltanto l’esecuzione oppure il bene descritto nella preventiva.

Perizia, contabilità e controlli: responsabilità diverse

Il fornitore produce evidenze tecniche; il professionista attesta i requisiti; l’impresa chiede il beneficio e conserva il fascicolo.

Il decreto richiede per tutti i beni una perizia tecnica asseverata, corredata da analisi tecnica e redatta da un ingegnere o da un perito industriale iscritto all’albo. In alternativa ammette l’attestazione, anch’essa corredata da analisi tecnica, di un ente di certificazione accreditato. Per il settore agricolo sono previste anche le figure professionali indicate dal decreto. Non c’è una soglia di costo sotto la quale basti una dichiarazione dell’impresa.

Il decreto richiede che l’ente sia accreditato, ma non indica la norma di accreditamento. I riferimenti alle norme ISO/IEC previsti nel regime 4.0 non sono ancora stati confermati per il 2026: prima di affidare l’incarico occorre verificare che l’ente possa rilasciare l’attestazione richiesta dalla misura.

Un revisore legale certifica invece che le spese sono state sostenute e corrispondono ai documenti contabili. Sono due verifiche diverse: una riguarda caratteristiche e interconnessione, l’altra costi e contabilità.

Il GSE controlla la documentazione e la coerenza delle informazioni trasmesse. L’Agenzia delle Entrate interviene nell’accertamento e nel recupero del beneficio non spettante. Il cliente resta il beneficiario e conserva perizie, attestazioni, fatture, documenti di trasporto e gli altri documenti dell’acquisizione. Il fornitore non deve dichiararsi «certificatore dell’incentivo» se non possiede il ruolo e l’accreditamento richiesti.

All’interno dell’impresa conviene assegnare esplicitamente i compiti. Il responsabile dei sistemi informativi presidia architettura, identificazione, interconnessione e registri; il responsabile finanziario e il fiscalista verificano capitalizzazione, capacità fiscale e cumulo; acquisti e legale mantengono coerenti contratto, ordine e fatture. È una buona pratica organizzativa, non un requisito aggiunto dalla legge.

La documentazione deve restare coerente anche dopo il completamento. Se, durante la fruizione, il bene viene ceduto a titolo oneroso o destinato a una struttura produttiva all’estero, il comma 432 conserva le quote residue soltanto alle condizioni che indica per la sostituzione con un bene materiale strumentale nuovo. Il testo non formula una regola sostitutiva equivalente per il software immateriale. Contratto e piano di assistenza dovrebbero quindi imporre di segnalare per tempo cessioni, dismissioni, trasferimenti e cambiamenti sostanziali della soluzione.

Indicare nel contratto prove e responsabilità

Il contratto deve assegnare consegne e responsabilità senza trasformare una previsione tecnica in una garanzia fiscale.

Le clausole utili disciplinano elementi concreti:

• la composizione del bene e la separazione economica dai servizi;
• per la dd.2, i compiti complessi, i flussi orchestrati, le decisioni automatiche e le evidenze che li rendono verificabili;
• le interfacce da realizzare e le condizioni del collaudo di interconnessione;
• i documenti tecnici che il fornitore consegna e i tempi di consegna;
• l’accesso del tecnico incaricato alle informazioni e alle prove necessarie;
• chi comunica variazioni di costo, architettura, sede o calendario;
• come vengono prodotti, protetti e conservati i registri necessari alle prove;
• come vengono gestiti sostituzioni, dismissioni e trasferimenti durante la fruizione;
• come si tratta un cambiamento normativo o un nuovo modello GSE;
• il limite della responsabilità del fornitore sulla spettanza fiscale, che dipende anche dal cliente e dai professionisti incaricati.

Una formula commerciale come «software iperammortizzabile» trasforma troppe condizioni in un’unica promessa. Una formula verificabile indica invece la voce proposta, le caratteristiche fornite, l’integrazione prevista e il materiale che verrà consegnato. Lascia al cliente la decisione fiscale e gli fornisce gli elementi necessari per costruire la prova.

I concetti che questo articolo introduce

Il dossier nasce mentre il bene viene descritto, integrato e collaudato; non si ricostruisce alla fine dalle fatture.

Fonti

Le fonti fissano requisiti e responsabilità; l’elenco operativo distingue sempre ciò che prescrivono da ciò che il fornitore prepara per provarlo.

• Legge 30 dicembre 2025 n. 199, commi 427-436 e allegati IV-V.
• Art. 7 del DL 38/2026, convertito dalla L. 88/2026.
• DM 7 maggio 2026.
• MIMIT, decreto direttoriale 10 giugno 2026 e modelli.
• GSE, documenti del Nuovo Piano Transizione 5.0.
• Circolare Agenzia delle Entrate-MISE 4/E del 30 marzo 2017.
• TUIR, articolo 110 e OIC 24.
• Camera dei deputati, testo dell’interrogazione 5-05448 del 3 giugno 2026 su software in cloud e modelli as a service.
• Camera dei deputati, risposta del Governo del 4 giugno 2026.