AI Act: scadenza 2026, Copilot e AI on-premise

La scadenza AI Act del 2 agosto 2026 cambia una domanda che molte aziende rimandano: possiamo dimostrare come Copilot usa i nostri dati e il nostro know-how? Se la risposta è “Microsoft ha server in Europa”, non è ancora una risposta sufficiente. Per contratti, offerte, email, codici, listini, disegni tecnici o documenti cliente, l'azienda deve conoscere flussi, componenti, giurisdizione applicabile, regole di accesso e tracce di utilizzo.

Microsoft 365 Copilot può essere uno strumento produttivo e Microsoft dichiara protezione dei dati enterprise, rispetto dei permessi Microsoft 365, audit e impegni sulla EU Data Boundary. Queste sono misure rilevanti, ma non rendono Copilot AI Act compliant per default nel singolo contesto aziendale. L'AI Act richiede di valutare sistema, finalità, ruolo dell'organizzazione e impatto; per gli impieghi ad alto rischio il deployer deve monitorare il sistema, assegnare supervisione umana e agire sui rischi individuati.

Perché Copilot diventa un pain point AI Act per dati e know-how

Copilot opera nel perimetro del tenant Microsoft 365, ma per produrre una risposta usa prompt, contenuti a cui l'utente ha accesso e Microsoft Graph. Questo è utile, ma amplifica un problema noto: permessi troppo ampi, documenti condivisi male o archivi non classificati possono trasformarsi in risposte che rendono visibile più know-how del previsto. Microsoft stessa raccomanda di preparare protezione e governance dei dati prima della distribuzione.

Il secondo problema è la dimostrabilità del perimetro. Le promesse di data residency riguardano specifici servizi, piani e configurazioni; non equivalgono a un sistema fisicamente e giuridicamente escluso da ogni dipendenza esterna. Microsoft indica inoltre che alcune opzioni di modello, come gli Anthropic models in Copilot per Word, Excel e PowerPoint, comportano elaborazione fuori dalla EU Data Boundary. L'amministratore deve quindi conoscere, verificare e governare impostazioni, modelli, sub-responsabili e flussi effettivi: non basta verificare dove si trova un datacenter.

Cloud Act americano: il server in Europa non chiude la questione

Il CLOUD Act statunitense stabilisce che un provider soggetto alla giurisdizione USA può essere obbligato a conservare, fare backup o divulgare dati che si trovano nel suo possesso, custodia o controllo, anche se sono archiviati fuori dagli Stati Uniti. Questo non significa che ogni dato in un datacenter europeo venga trasferito o consegnato automaticamente, né equivale da solo a una violazione dell'AI Act. Significa però che la posizione geografica del server non basta per eliminare la valutazione di giurisdizione e accesso legale.

Per l'azienda italiana il problema diventa concreto quando deve provare di aver valutato i rischi del fornitore, le dipendenze da sub-responsabili e le misure applicate a dati personali e know-how. ENISA raccomanda di trattare il cloud come un tema di risk assessment, con domande puntuali al provider e monitoraggio dei livelli di sicurezza; l'EDPB richiede di valutare i trasferimenti e, dove necessario, misure supplementari. Se l'organizzazione non riesce a determinare in modo verificabile quali componenti hanno elaborato un dato, con quale modello e sotto quali condizioni di giurisdizione, non può sostenere con rigore che quel flusso sia governato.

Le argomentazioni a favore di Copilot — e cosa manca per l'AI Act

“I dati restano in Europa.” Microsoft offre impegni di EU Data Boundary e data residency per condizioni definite. È un elemento positivo, non una garanzia assoluta: vanno controllati tenant, licenze, impostazioni, servizi accessori, modello selezionato e possibili eccezioni. La residenza del dato non risolve da sola l'esposizione giuridica di un provider soggetto a norme statunitensi né documenta tutte le elaborazioni.

“Microsoft non addestra i modelli con i nostri prompt.” Per Microsoft 365 Copilot, Microsoft dichiara che prompt, risposte e dati dei file non sono usati per addestrare i foundation model. È un impegno importante, ma diverso dalla domanda AI Act: chi può accedere al dato, quali file entrano nel grounding, quali servizi lo elaborano, quanto restano le tracce e quali controlli sono realmente configurati dall'azienda?

“Copilot rispetta i permessi già presenti.” È vero: Copilot usa le autorizzazioni dell'utente. Proprio per questo eredita gli errori di condivisione dell'ambiente Microsoft 365. Un'autorizzazione eccessiva che prima restava nascosta in un file server può diventare una risposta immediata a una domanda formulata bene.

“Copilot ha audit e controlli enterprise.” Microsoft offre audit, eDiscovery, retention e Purview, ma la disponibilità e l'efficacia dipendono dal piano e dalla configurazione. La documentazione Microsoft segnala anche che l'utente può cancellare la propria cronologia chat. Un'azienda deve quindi verificare che le proprie regole di conservazione e audit mantengano le evidenze necessarie: non può dedurlo automaticamente dalla presenza di Copilot.

In sintesi, Copilot può essere configurato con controlli utili; ciò che non può offrire da solo è una prova automatica di conformità per ogni uso aziendale. La responsabilità di definire caso d'uso, classificazione del rischio, utenti, supervisione, retention e dati autorizzati resta all'impresa.

Perché un'AI on-premise risolve il pain point

Con una soluzione on-premise, server, modello, motore OCR, indice documentale, log e integrazioni vengono definiti nel perimetro tecnico concordato con l'azienda. Questo non elimina gli obblighi AI Act o GDPR, ma permette di fornire una risposta verificabile a domande decisive: quale modello ha elaborato il dato, dove è avvenuta l'inferenza, chi ha avuto accesso, quali guardrail erano attivi e quale traccia è stata conservata.

Per know-how industriale, dati di clienti, contratti e processi regolati, il vantaggio non è solo “tenere il server vicino”. È evitare che la governance dipenda da una catena di condizioni cloud, opzioni e contratti che l'azienda deve ricostruire a posteriori. L'on-premise trasforma una dipendenza da verificare in un'architettura che l'impresa può documentare, ispezionare e governare direttamente.

L'AI Act europeo (Regolamento UE 2024/1689) non vieta alle aziende di usare l'intelligenza artificiale. Chiede invece di capire quale sistema AI viene usato, per quale finalità, da chi e con quale impatto. Per un imprenditore o un responsabile IT, la domanda pratica non è “abbiamo un chatbot?”, ma: possiamo spiegare e governare il modo in cui l'AI entra in contratti, fatture, email, dati clienti, disegni tecnici o processi del personale?

Il regolamento segue un approccio basato sul rischio. Non tutti gli usi hanno gli stessi obblighi: alcune pratiche sono vietate, alcuni sistemi possono essere ad alto rischio, altri ricadono in obblighi di trasparenza o in requisiti più limitati. La prima regola utile è quindi evitare etichette generiche come “AI Act compliant” senza indicare ruolo dell'azienda, caso d'uso, dati trattati e misure applicate.

Dal 2 febbraio 2025 sono applicabili, tra le altre, le norme sulle pratiche vietate e sull'AI literacy. Dal 2 agosto 2026 l'AI Act è in generale applicabile, con calendari specifici per alcune categorie di sistemi ad alto rischio. La formazione non è dunque un dettaglio: chi usa l'AI per conto dell'azienda deve comprenderne limiti, istruzioni, rischi e modalità di supervisione.

Cosa significa davvero una soluzione AI Act compliant

Una soluzione non diventa conforme solo perché è installata in azienda o perché usa un modello noto. La conformità va verificata nel contesto dell'organizzazione e può richiedere il coinvolgimento di legale, privacy, sicurezza e responsabili di processo. Però una piattaforma adatta deve permettere all'azienda di raccogliere le informazioni e le evidenze necessarie senza partire ogni volta da una consulenza tecnica da zero.

In particolare, chi fornisce o propone uno strumento AI dovrebbe poter indicare in modo documentabile:

• dove risiede l'infrastruttura e quali componenti sono nel perimetro dell'azienda;
• quale modello viene usato, quale versione, con quali componenti aggiuntivi e quale architettura gestisce chat, documenti, OCR, ricerca e integrazioni;
• quali dati entrano e dove transitano, compresi indici documentali, backup, telemetria e accessi amministrativi;
• quali guardrail sono configurabili: policy sui prompt, filtri sugli input e sugli output, limiti di utilizzo, ruoli e autorizzazioni;
• come vengono conservate le tracce di utilizzo, chi può consultarne i log e chi può modificarli;
• come sono gestiti gli eventi anomali o impropri, inclusi alert verso gli amministratori;
• come avviene l'anonimizzazione o la pseudonimizzazione dei dati personali e sensibili prima che siano elaborati dal modello.

Questo è il livello di dettaglio che consente a un'azienda di classificare il caso d'uso, aggiornare l'inventario AI e rispondere in modo credibile a clienti, auditor o funzioni di controllo.

AI privata: utile per il controllo, non una scorciatoia normativa

Per contratti, fatture, dati cliente, codice e know-how, un'architettura on-premise o privata può ridurre la dipendenza da piattaforme cloud terze e rendere più chiaro il perimetro tecnico. Non equivale da sola alla conformità AI Act o GDPR: occorre comunque definire finalità, basi giuridiche quando si trattano dati personali, ruoli, permessi, retention e misure di sicurezza.

Il vantaggio è operativo. Se server AI, archivio documentale, integrazioni e accessi sono progettati nel perimetro concordato con l'azienda, è più semplice ricostruire dove passano le informazioni e applicare regole coerenti. È una base utile soprattutto quando l'AI lavora su file server, SharePoint, gestionali, drive interni o database.

Modello e architettura: la domanda da non saltare

“Che modello usate?” è una buona domanda, ma incompleta. Per valutare un sistema servono anche versione del modello, modalità di inferenza, componenti OCR e visione, motore di ricerca sui documenti, integrazioni, gestione delle identità e flussi di rete.

Un fornitore serio deve riuscire a descrivere questi elementi e a chiarire quali dati sono inviati a ogni componente. Se una funzione ricorre a un servizio esterno, deve essere esplicitato; se l'inferenza resta nell'infrastruttura privata, deve essere precisato come è configurata. Senza questa mappa l'azienda non può valutare correttamente né rischio né responsabilità.

Guardrail configurabili e utenti responsabilizzati

Le policy scritte non bastano se l'interfaccia rende facile aggirarle. Per rendere governabile l'uso quotidiano, una soluzione AI aziendale dovrebbe consentire di configurare guardrail coerenti con reparti e casi d'uso:

• ruoli, gruppi e permessi per limitare l'accesso a chat, basi documentali e funzioni sensibili;
• regole su dati e documenti che possono essere caricati o interrogati;
• istruzioni di sistema e filtri su prompt e risposte, aggiornabili dall'azienda;
• limiti per funzioni ad alto impatto e obbligo di revisione umana dove il processo lo richiede;
• log di audit consultabili dagli amministratori, con utenti ordinari impossibilitati a cancellare la cronologia o le evidenze di utilizzo;
• segnalazione automatica agli amministratori quando regole configurate intercettano un utilizzo improprio o un tentativo di aggiramento.

I guardrail non eliminano ogni errore e non sostituiscono la supervisione umana. Danno però all'azienda una disciplina tecnica: definire cosa è ammesso, rilevare le eccezioni e intervenire prima che un comportamento informale diventi prassi.

Anonimizzare dati sensibili: spiegare come, non solo dichiararlo

Dire “i dati sono anonimizzati” non è sufficiente. Occorre distinguere tra anonimizzazione effettiva e pseudonimizzazione, verificare il rischio di re-identificazione e documentare il flusso. In un processo ben definito, la protezione può prevedere il rilevamento di categorie configurate — per esempio nomi, email, numeri di telefono, codici fiscali, IBAN, numeri di pratica o riferimenti clinici — prima dell'elaborazione.

I valori rilevati possono essere mascherati o sostituiti da segnaposto/token; il modello lavora quindi su una versione minimizzata del testo. L'eventuale tabella di corrispondenza tra token e dato originale deve restare separata, con accessi e conservazione definiti. Questa misura va testata sui documenti reali dell'azienda: scansioni OCR, formati inconsistenti e contesto possono produrre falsi negativi. Per questo servono regole di blocco, revisione e monitoraggio, non una promessa assoluta.

Checklist AI Act per aziende: le domande da fare prima della demo

Prima di scegliere un assistente generativo, OCR o agente, chiedi al fornitore:

• Quale problema risolve e in quale reparto? Influenza decisioni su persone, credito, sicurezza, istruzione, sanità o accesso a servizi?
• Quali dati riceve? Dove sono conservati file, chat, indici, backup e log?
• Quale modello e quale architettura vengono impiegati? Esistono componenti o chiamate verso terze parti?
• Chi amministra utenti, permessi, guardrail e integrazioni? Esiste una traccia delle modifiche?
• Gli utenti possono eliminare chat o log? Come vengono segnalati abusi, anomalie o violazioni delle policy?
• Quali dati vengono mascherati o pseudonimizzati, in quale punto del flusso e con quale verifica dell'efficacia?
• Quale documentazione tecnica, formazione e assistenza vengono consegnate per mantenere il sistema governato nel tempo?

Come Chiedilo a Mirko aiuta a prepararsi

Chiedilo a Mirko è una soluzione di AI privata progettata per supportare questa verifica. Fornisce, su richiesta, la documentazione su modello, architettura e trattamento dei dati necessaria per valutare il caso d'uso; l'azienda non deve ricostruirla acquistando una consulenza tecnica separata. L'assessment resta importante per applicare queste informazioni al proprio contesto organizzativo, privacy e normativo.

Mirko combina server AI nel perimetro concordato, chat, OCR, comprensione immagini, agenti e integrazioni con sistemi interni. La configurazione può includere guardrail, ruoli, tracciabilità non cancellabile dagli utenti ordinari, alert amministrativi per utilizzi impropri e processi di mascheramento o pseudonimizzazione definiti sul dato e sul workflow. Installazione, formazione e assistenza in italiano aiutano a far usare questi controlli davvero, invece di lasciarli in una policy.

L'obiettivo non è dichiarare “conformità automatica”. È mettere l'impresa nelle condizioni di sapere che AI sta usando, su quali dati, con quali regole e con quali prove di controllo: il punto di partenza concreto per una governance AI Act proporzionata.