The Holy Trinity: cosa serve davvero all'AI per lavorare

Un'azienda manifatturiera vuole sapere quali dei suoi 14.000 SKU sono effettivamente profittevoli. La risposta si trova in tre sistemi che non si sono mai scambiati un singolo dato. Fino a poco tempo fa ottenerla costava tre reparti, due settimane e una buona dose di buona volontà. Dall'inizio del 2026 un'AI può rispondere a questa domanda in pochi minuti: scandagliare i dati, stabilire le correlazioni, produrre una raccomandazione. A condizione che abbia accesso.

I modelli sono pronti. Agiscono, eseguono compiti su più passaggi e attraverso i confini dei sistemi, preparano decisioni, avviano workflow. Molte aziende se ne sono già fatte una prima idea grazie a Copilot, ma Copilot conosce l'universo M365: mail, documenti, calendari. Chi vuole mettere l'AI al lavoro sui dati che reggono davvero il business, su ERP, CRM, IoT e sistemi di produzione, ha bisogno di fondamenta diverse.

Queste fondamenta sono composte da tre parti. Abbiamo costruito ognuna di esse come Managed Service, ognuna va in produzione in tre o quattro settimane e insieme formano la piattaforma su cui l'AI può svolgere un lavoro reale.

Primo: dati che vale la pena interrogare

Torniamo ai 14.000 SKU. I dati di produzione stanno nell'ERP, i numeri di vendita nel CRM, e da qualche parte nel mezzo una singola persona aggiorna un foglio di calcolo che per caso è l'unica fonte di un KPI business-critical. Non è un caso particolare. È la regola. E fino a quando questi dati restano in sistemi separati, l'AI non ha una visione coerente del business.

Un'architettura lakehouse risolve il problema su tre livelli: dati grezzi dai sistemi sorgente (bronze), dataset curati e validati (silver), aggregati di business che confluiscono direttamente nelle pipeline di analytics o di AI (gold). Che girino su Databricks o su Fabric dipende dai requisiti. Funzionano entrambi. Anche un ibrido dei due.

La Azure Data Foundation è il nostro Managed Service per questo. Integra i dati da ERP, CRM, IoT e altri sistemi sorgente in un'unica piattaforma, definita integralmente come Infrastructure as Code, con drift detection automatica, data governance continua tramite Unity Catalog o Purview e accesso basato sui ruoli per business user, analisti e data engineer allo stesso modo. La conseguenza pratica: un'azienda con queste fondamenta può porre per la prima volta domande che prima erano senza risposta, non perché non lo si volesse, ma perché i dati c'erano sì, ma non erano mai collegati.

Secondo: un posto in cui i workload girino davvero

Avere i dati è una cosa. Farci qualcosa che vada oltre un'interrogazione una tantum è un'altra. Applicazioni di AI, business logic automatizzata, job di lunga durata: tutto ciò che accede in modo autonomo e ripetuto ai dati aziendali ha bisogno di un runtime controllabile. Questo ambiente, previsto o no, è fatto di container.

La Azure Container Foundation fornisce questo perimetro: una piattaforma container standardizzata basata su Azure Container Apps o Azure Kubernetes Service, a seconda del workload. Accessi di rete uniformi, autenticazione centralizzata tramite Entra ID con managed identity, monitoring continuo. Tutto gestito tramite Terraform e GitHub, tutto riproducibile.

Cosa rende possibile: invece che ogni team tiri su il proprio cluster e definisca regole proprie, esiste un perimetro comune in cui i workload non solo girano, ma restano governabili. È il presupposto per dare loro autonomia.

Terzo: il posto in cui dai modelli nascono gli agent

Un modello non è ancora un agent. Tra un modello linguistico e qualcosa che registra ordini, verifica fatture o escala casi di assistenza in modo affidabile c'è una quantità di lavoro poco spettacolare: quale modello, quali strumenti, quali fonti dati, quali guardrail, e cosa succede quando l'agent sbaglia. Questo lavoro deve avvenire da qualche parte, in modo tracciabile e ripetibile, non in un notebook sul laptop di una singola persona.

La Azure AI Foundation è il nostro Managed Service per questo livello, costruito su Microsoft Foundry (prima Azure AI Foundry): catalogo dei modelli, orchestrazione degli agent, collegamento a strumenti e fonti dati, valutazione e observability in un unico posto. Un agent costruito qui accede a dati e workload tramite le stesse identità Entra del resto del panorama, gira contro i guardrail che sono stati definiti e lascia una traccia verificabile.

Lo consegniamo definito come codice, con accesso basato sui ruoli, content filter e confini di rete non negoziabili, e con un percorso di deployment che porta un agent dallo sviluppo alla produzione senza che nessuno debba stringere viti a mano. Solo così un agent smette di essere un prototipo e diventa qualcosa che un'azienda può effettivamente gestire.

The Holy Trinity

Tre componenti, ognuna produttiva in tre o quattro settimane, ognuna utilizzabile singolarmente, insieme la piattaforma su cui l'AI arriva dove in azienda si genera davvero valore.

La Azure Data Foundation dà all'AI accesso ai dati che descrivono il business. La Azure Container Foundation dà ai suoi workload un posto in cui girare, in modo duraturo e controllato. E la AI Foundation è il posto in cui da questi dati e da questi workload nasce un agent che si può costruire, verificare e gestire.

Mettendo insieme tutti e tre, si ottiene il terreno su cui l'AI smette di riassumere e inizia a lavorare.