Non esiste una definizione accademica di “architettura semantica“. IBM la definisce come “una parte di architettura dei dati aziendali progettata per semplificare le interazioni tra sistemi di data storage complessi e utenti business“[1], mentre Gartner fa riferimento alle architetture informative d’impresa[2] e a modelli semantici dei dati[3].
Indice degli argomenti:
Architettura semantica, che cosa si intende
Finora, l’architettura semantica di un’azienda era formata esclusivamente da dati (la “verità di base”) + risorse umane e sistemi informativi rispettivamente come “motori semantici” e “mediatori semantici”. Finora, nessun avanzamento tecnologico aveva messo in discussione questo paradigma.
Ogni processo aziendale persegue un fine economico proprio, ma tutti condividono un meta-processo: la creazione e gestione della semantica aziendale. Meta-processo finora rimasto implicito poiché l’asset “capacità di comprensione semantica” non è mai stato oggetto di gestione esplicita, essendo per definizione un corollario delle ordinarie capacità umane. Ma in cosa si esplicita e in che modo questo asset condiziona il funzionamento dell’azienda?
Le competenze delle risorse umane
Consideriamo un memo di un AD che chiede uno studio per un nuovo prodotto. Sotto il profilo semantico, rappresenta esclusivamente un set di specifiche da decodificare e implementare. Le risorse umane interpretano, negoziano, sintetizzano sulla base dei propri ruoli e di quanto i sistemi informativi mettono a disposizione. All’approvazione del Cda segue una catena di azioni: definizione nei sistemi informativi, materiale pubblicitario, documentazione di compliance. Anche qui, specifiche da implementare. L’efficacia, il “time to market”, dipende dalle competenze dei “motori” e dall’efficienza dei “mediatori”.
Le competenze delle risorse umane sono un asset prezioso ma tendenzialmente statico, non gestibile nel breve periodo per competenze di spessore tecnico o relazionale. Similmente per i “mediatori”: il significato dei dati e le regole per acquisirli, interpretarli ed esporli sono depositati in software sviluppato in epoche tecnologiche diverse, con linguaggi e paradigmi propri. Una specie di “geologia del software legacy”. Basti pensare che ancora nel 2025 il 70% delle banche globali faceva affidamento su sistemi bancari legacy, con oltre il 43% che utilizza ancora COBOL, linguaggio degli anni ’50. Il 95% delle transazioni ATM viene elaborato con sistemi basati su COBOL, con 220 miliardi di righe di codice ancora operative[4].
Il sistema transazionale
Il sistema transazionale è la “verità di base”: ERP[5], core banking, MES manifatturiero[6], sistemi di cartelle cliniche. Quasi sempre su architetture relazionali degli anni ’90 o precedenti, spesso su mainframe. I dati sono normalizzati secondo logiche di quando lo storage costava. Lo schema riflette i processi di allora, non di oggi. Ma funziona: ogni giorno milioni di transazioni generano revenues.
Sopra il transazionale ci sono datamart. Ogni funzione aziendale, progetto regolamentare, iniziativa di BI genera la propria replica dei dati con applicazione verticale. Le regole di trasformazione vivono in ETL[7], stored procedure, script in linguaggi non più conosciuti, macro Excel. Spesso con poca documentazione.
Emerge un fenomeno ricorrente: la conoscenza del “perché” si stacca dal “come”. Il documento di progetto spiega perché un datamart è stato costruito. La stored procedure implementa il come. Ma vivono in posti diversi, manutenuti da team diversi, e col tempo divergono. Dopo cinque anni la stored procedure può eseguire operazioni che il documento non descrive.
La stratificazione software distribuisce le regole di business su più strati: codice applicativo, tabelle di configurazione, documenti di policy, testa delle persone. Nessun componente, preso singolarmente, è irrazionale. Il risultato complessivo è però caratterizzato da latenza informativa[8], opacità causale[9], rigidità strutturale[10] e fragilità intrinseca[11].
Infrastrutture obsolete
Ma l’impatto più evidente si ha a livello economico. Diverse ricerche recenti rilevano che le aziende spendono fino all’80% dei budget IT solo per mantenere infrastrutture obsolete[12]. Un sondaggio su 3.700 aziende ha rilevato che i leader IT stimano di spendere il 72% per “mantenere le luci accese“[13].
I processi ETL costituiscono oltre il 50% della spesa cloud per ingerire, preparare e trasformare dati in modelli per analytics, BI, data science e machine learning[14].
L’architettura agentica ibrida
A distanza di circa settant’anni dai primi sistemi software, abbiamo la tecnologia per cambiare radicalmente questo paradigma: architetture basate su agenti che usano IA generativa e collaborano su task complessi.
L’accelerazione tecnologica è forte e sostenuta. Gartner prevede che fino al 40% delle applicazioni aziendali includeranno agenti AI specifici entro fine 2026, rispetto a meno del 5% oggi[15].
È la prima tecnologia in grado di ridefinire la semantica aziendale.
Perché l’effetto è senza precedenti? Perché con strumenti in grado di comprendere il linguaggio naturale che possono operare direttamente nei processi il ciclo analisi – decisione – azione – controllo può avvenire, estremizzando, in tempo reale. Non si tratta di sostituire le decisioni umane. Si tratta di realizzare un’architettura dove una decisione umana possa seguire un’applicazione diretta a livello operativo.
Sempre usando lo stesso esempio, il memo dell’Ad può essere contestualmente processato da uno swarm agentico che collabora con gli attori umani in Cowork. Lo swarm rappresenta una rete semantica distribuita. Cowork è il motore semantico dei processi che orchestra task cross-funzionali comprendendo dipendenze implicite e gestendo file eterogenei inferendo le relazioni semantiche.
Claude Code assume il ruolo di motore semantico del codice, interpretando requisiti in linguaggio naturale e generando -in tempo reale – implementazioni coerenti col dominio, anche delle architetture legacy. Gli skills consentono di gestire competenze delle componenti agentiche e modalità precise di esecuzione del lavoro. Non devo più avere l’applicazione che gestisce le campagne di marketing. Il codice necessario si crea volta per volta.
Un ETL tradizionale necessita di uno schema predefinito: deve sapere prima che un campo significa “categoria cliente” e che ‘3A’ significa “PMI con fatturato tra 2 e 10 milioni”. Questa conoscenza viene codificata manualmente, testata, validata. Processi che durano giorni o settimane.
Il sistema Cowork + Claude Code opera diversamente. Non necessita di dati perfettamente strutturati per comprendere che deve leggere il campo ‘CUST_CTG_CD’ col valore ‘3A’[16] per selezionare le PMI con certa soglia di fatturato. Può leggere la documentazione tecnica del sistema – data dictionary, manuale utente, commenti nel codice sorgente – inferire il significato e costruire strumenti attuativi in tempo reale. Chiedendo conferma se incerto.
Uno swarm di agenti lavora contemporaneamente sugli stessi dati con direttive e competenze diverse. Ognuno con comprensione semantica secondo l’ottica assegnata. Con tempi di collaborazione dell’ordine di minuti, secondi o frazioni di secondo. Il risultato è un sistema dotato di scalabilità intrinseca.
I vantaggi reali
Se un agente può leggere una fonte dati, comprenderne la semantica, applicare una regola di business e produrre output, cosa succede agli strati intermedi che facevano esattamente questo in modo rigido e manuale? Possono essere direttamente sostituiti.
Gran parte del lavoro ETL non è computazionale. Non è “somma questi numeri”. È “prendi questo dato che nel sistema A si chiama X e nel sistema B si chiama Y, verifica formato, trasformalo in formato Z e caricalo nel sistema C”. È traduzione semantica codificata in trasformazioni rigide.
Un agente può fare questa traduzione a runtime, su dati mai visti prima, purché abbia accesso alle specifiche dei sistemi coinvolti. L’ETL non scompare – resta per flussi ad alto volume dove la performance è critica – ma lo strato di logica di trasformazione semantica può essere drasticamente ridotto.
Se le policy sono documenti e le regole devono essere codificate in un’applicazione (esempio: pricing per categoria di clienti) , il gap è colmato manualmente. Un agente policy reader, al contrario, può leggere il documento, formalizzare la regola e alimentare direttamente il motore decisionale, o essere il motore decisionale, applicando la regola direttamente.
Un report tradizionale è una fotografia con parametri predefiniti. Se l’Ad chiede “perché questo numero è cambiato?”, il report non sa rispondere. Serve un analista che riapra i dati, riaggreghi, indaghi.
Un agente reporter produce risposte a domande. “Qual è la nostra esposizione verso il settore immobiliare commerciale, e come è cambiata nell’ultimo trimestre, e perché?” — un’unica query che attraversa dati, regole, contesto storico, e produce risposta narrativa con numeri a supporto.
Si assottiglia quindi drasticamente lo strato di mediazione: software che esiste solo per tradurre tra sistemi, aggregare dati, applicare regole, formattare output.
Questo strato, che nelle organizzazioni mature può rappresentare il 40-60% della complessità IT, diventa in larga parte sostituibile da agenti che comprendono semanticamente ciò che stanno facendo.
Restano: database, sistemi transazionali, infrastruttura di rete, sicurezza, identity management, vincoli regolamentari e interfacce verso l’esterno.
Considerazioni critiche per l’implementazione
Non è un pasto gratis. Il livello di cambiamento che potenzialmente i sistemi di sciami agentici possono apportare a un’organizzazione è rilevante ed appetibile soprattutto per la scalabilità che apportano, ma le organizzazioni devono evolvere di pari passo e adottare un ritmo di cambiamento decisamente sfidante. È possibile.
Alcuni segnali provenienti da oltreoceano segnalano che aziende di rilevanza globale stanno cambiando i propri assetti organizzativi a una velocità maggiore rispetto al passato per adottare processi AI-centrici. Solo per fare un esempio, Goldman Sachs ha introdotto in modo decisamente aggressivo un’architettura di tipo agentico per la gestione di processi chiave, sia infrastrutturali che propriamente di business.
Per catturare il potenziale trasformativo delle architetture agentiche, le organizzazioni devono passare da sforzi tattici a un programma strategico coeso che ridisegni il modo di operare. Per le organizzazioni esistenti potrebbe essere decisamente più complesso che per startup AI native, che scontano decisamente meno vincoli derivanti dalla storia e dalla stratificazione “geologica” di competenze e sistemi.
Per la prima volta nella storia dell’informatica aziendale, è possibile ripensare l’architettura semantica non come vincolo, ma come asset
Per introdurre il livello di autonomia e di vicinanza collaborativa di cui sistemi AI come quello sviluppato da Anthropic sono capaci, devono essere assicurate trasparenza dei log, dei ragionamenti seguiti, tracciabilità. Limitare l’autonomia ad ambienti controllati, costruire vincoli e fail-safe sono i metodi che è possibile adottare. Ogni decisione deve essere registrata. Le metriche di affidabilità devono essere tracciate e visualizzate.
A queste condizioni è possibile usare l’AI agentica per ridefinire interi domini di business piuttosto che ottimizzare task esistenti. Richiede uno spostamento dai singoli casi d’uso a un focus sui processi nel loro complesso.
A livello tecnico, il sistema agentico basato su skills e Cowork può funzionare come strato di orchestrazione che abilita ecosistemi di agenti complessi a scalare, operando in sicurezza ed evolvendosi.
Per la prima volta nella storia dell’informatica aziendale, è possibile ripensare l’architettura semantica non come vincolo, ma come asset da usare attivamente. Le architetture agentiche basate su AI generativa rappresentano un cambio di paradigma oltre la semplice automazione introducendo capacità di comprensione semantica dinamica e adattiva finora esclusivamente umane consentendo di ridefinire il “sistema azienda”.
Questa trasformazione richiede approccio strategico e misurato. È plausibile pensare che le organizzazioni di successo sapranno bilanciare innovazione con capacità di governo.
Non si tratta di sostituire l’intelligenza umana, ma di creare un modello ibrido dove agenti artificiali e risorse umane collaborano sinergicamente. È peraltro lecito immaginare che le finestre di opportunità siano limitate nel tempo per costruire un qualche vantaggio competitivo
La sfida attuale, soprattutto in contesti regolati, appare stabilire controlli di governance robusti e pattern architetturali che abilitino casi d’uso di AI agentica su scala aziendale, preservando autonomia dei team e flessibilità tecnologica. Le organizzazioni che sviluppano queste capacità saranno posizionate per scalare il valore dall’AI e adattarsi mentre la tecnologia evolve.
Note
I valori presentati hanno mero scopo esemplificativo e non tratti da scenari applicativi esistenti. ↑
- Rif.: Pragmatic Coders (2025). “2025 Legacy Code Stats: Costs, Risks & Modernization” ↑
- Enterprise Resource Planning, software gestionale centralizzato che gestisce processi chiave dell’impresa, spesso percepito come una naturale evoluzione della piattaforma contabile e di controllo di gestione. ↑
- Manufacturing Execution System, ovvero un sistema di monitoraggio dell’andamento della produzione ↑
- Extract, Transform and Load. Processo di alimentazione di un datamart a partire da fonti legacy ↑
- Un dato cambia alla base e impiega ore o giorni per propagarsi fino al reporting. Nel frattempo, decisioni possono essere prese su dati non aggiornati. ↑
- Quando una riconciliazione fallisce, o due sistemi di sintesi sono disallineati, risalire la catena delle trasformazioni richiede competenze distribuite su più team. Raramente qualcuno conosce l’intera catena. ↑
- Modificare una regola di business richiede interventi su più strati, spesso con rilasci coordinati, ambienti di test separati, validazioni incrociate. ↑
- Un cambio in uno strato può rompere qualcosa in un altro senza che nessuno se ne accorga immediatamente. I controlli sono spesso a consuntivo, non preventivi. ↑
- Rif: Is Your Legacy IT Infrastructure Draining Your Budget? Forbes, 2024 ↑
- Rif.: Tricension, 2026 – What is a Legacy System and Approaches to Legacy System Modernization ↑
- Rif.: integrate.io – 2026 ETL Cost Savings Statistics for Businesses ↑
- Rif.: Gartner Group Press Releases 2025 – 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026 ↑
