BLOG
14 agosto 2026ai-agentsblockchainenterprise3 min di letturaITENHR

La richiesta è nel cassetto

Le software house .NET non rifiutano blockchain e agenti AI perché siano cattive idee. Le rifiutano perché costruire quella competenza costa due anni.

In quasi ogni software house .NET c'è una richiesta rimasta senza risposta. Un cliente storico ha chiesto qualcosa che riguardava la blockchain, oppure un agente che classificasse documenti dentro il gestionale, e la risposta è stata no. Non perché fosse una cattiva idea: perché costruire quella competenza è una deviazione di due anni da ciò che il team sa già fare bene.

Il motivo è più tecnico di quanto sembri. Il layer API di un agente lo scrive chiunque abbia esperienza .NET: chiamate, serializzazione, un endpoint, un paio di test. Il resto è la parte che non si sa stimare, ed è la parte che decide se il progetto va in produzione o muore in collaudo.

Quello che non si riesce a preventivare

La regressione dei prompt, per cominciare. Ogni cambio di versione del modello può spostare il comportamento su casi che funzionavano il mese prima, e serve una suite che se ne accorga prima del cliente.

Poi i retry. Un agente che scrive su dati vivi non può ripetere un'operazione senza garanzie di idempotenza: la stessa fattura approvata due volte è un incidente contabile, non un bug di frontend.

Poi l'autorizzazione delle chiamate a tool, per tenant e per utente, perché un agente che legge un archivio documentale eredita in un colpo solo tutti i problemi di permessi che l'applicativo ha risolto in dieci anni.

E infine il log decisionale, che è il punto dove quasi tutti i piloti si fermano. Non è una tabella in più nello stesso schema dell'applicativo: quella tabella la può riscrivere chiunque abbia i permessi sul database, e nessuno può dimostrare che non sia successo. L'AI Act, per i sistemi ad alto rischio, chiede la registrazione automatica degli eventi. Un log che il gestore del sistema può modificare non è una prova.

Messe insieme, queste quattro cose non sono una feature. Sono una superficie operativa da presidiare nel tempo, e nessun preventivo a corpo la copre.

Il costo del cassetto

Così la richiesta finisce nel cassetto, ed è una decisione ragionevole nel breve. Il problema arriva dopo: diciotto mesi più tardi il cliente trova un system integrator che porta tutto il pacchetto, e insieme al pacchetto si porta il rapporto. Non si perde un progetto, si perde un account.

Una terza strada

C'è un'opzione fra "assumiamo un team" e "diciamo di no": prendere la capacità ingegneristica dall'esterno e tenerla dentro il proprio perimetro. In C#, dentro il repository della software house, sotto il suo marchio.

Tre aree, e sono quelle su cui lavoro: agenti AI che girano in produzione dentro sistemi .NET aziendali, smart contract e tokenizzazione, e il punto dove le due cose si incontrano — il decision ledger dell'agente con l'impronta ancorata on-chain, così che un terzo possa verificare senza doversi fidare.

Le condizioni sono le uniche che rendono la cosa praticabile per entrambi: NDA standard, tariffa giornaliera, clausola di non sollecitazione in entrambe le direzioni. Il cliente resta della software house. Il codice resta nel suo repository.

Qual è la richiesta a cui hai detto no, e che avresti preso se la competenza ci fosse stata?

Questo articolo è nato come post su LinkedIn, dove è stato discusso.Vedi la discussione