AI Act per le aziende: dati europei, inferenza e sistemi AI sovrani

Per portare l’AI in produzione non basta scegliere dove gira il modello. Servono responsabilità chiare, controlli verificabili e un’architettura coerente con il rischio.

L’AI Act è un regolamento basato sul rischio: guarda alla finalità prevista del sistema, alle persone che può coinvolgere e al ruolo svolto dall’organizzazione. Provider, deployer, importatori e distributori non hanno gli stessi obblighi. Per questo la prima domanda non è «cloud o on-premise?», ma «che sistema stiamo usando, per fare cosa, e con quale responsabilità?».

La timeline da conoscere nel 2026

Il regolamento è entrato in vigore il 1° agosto 2024 ed è divenuto generalmente applicabile il 2 agosto 2026, con eccezioni e scadenze progressive. I divieti e le prime disposizioni sull’alfabetizzazione AI si applicano dal 2 febbraio 2025; gli obblighi sui modelli di AI per finalità generali dal 2 agosto 2025. Dopo l’AI Omnibus entrato in vigore il 27 luglio 2026, le attuali scadenze per i sistemi ad alto rischio sono il 2 dicembre 2027 per i casi dell’Allegato III e il 2 agosto 2028 per i sistemi collegati ai prodotti regolamentati dell’Allegato I.

Riferimenti ufficiali: quadro normativo della Commissione europea e AI Omnibus.

1. Partire da inventario, ruolo e finalità

Un inventario AI utile non è una lista di abbonamenti. Per ogni sistema deve registrare almeno proprietario, finalità prevista, utenti, persone interessate, dati e fonti, modello o fornitore, azioni abilitate, ambiente di esecuzione e livello di supervisione umana.

• Classificare il ruolo. L’azienda può essere deployer di un sistema di terzi, provider di una soluzione propria o assumere nuovi obblighi dopo una modifica sostanziale.
• Classificare il rischio. Non tutti i sistemi sono ad alto rischio; la classificazione dipende dalla finalità e dal contesto d’uso, non dalla sola tecnologia.
• Definire i confini. Cosa può leggere il sistema, cosa può decidere o eseguire, quando deve fermarsi e chi risponde dell’esito.

2. Dati e inferenza in Europa: perché contano

Elaborare dati e inferenza in Europa può ridurre trasferimenti, rendere più chiara la filiera dei subfornitori e facilitare requisiti contrattuali, di sicurezza e di data governance. Per organizzazioni regolamentate può inoltre essere un requisito di procurement o di politica interna.

Questa è una scelta architetturale importante, ma va distinta dalla conformità normativa. Un sistema eseguito interamente in Europa può comunque essere privo di documentazione, oversight, logging o monitoraggio adeguati. Al contrario, l’AI Act non impone in via generale che ogni inferenza avvenga nell’UE: obblighi ulteriori possono derivare da GDPR, Data Act, regole settoriali, contratti e policy aziendali.

3. Scegliere il deployment in base al rischio reale

4. Il piano di controllo che accompagna l’architettura

• Data governance: provenienza, qualità, diritti di utilizzo, minimizzazione, accessi e retention.
• Valutazioni: test su accuratezza, robustezza, sicurezza, bias rilevanti e comportamento fuori perimetro.
• Trasparenza: istruzioni e informazioni comprensibili per chi usa il sistema; disclosure quando una persona interagisce con un’AI o incontra contenuti sintetici nei casi previsti.
• Supervisione umana: persone competenti, autorità reale di intervento, escalation e possibilità di sospendere l’automazione.
• Osservabilità: log, versioni, metriche, fonti, feedback e incidenti. Per alcuni deployer di sistemi ad alto rischio, l’articolo 26 prevede la conservazione dei log sotto il loro controllo per almeno sei mesi, salvo diversa disciplina applicabile.
• Change management: ogni cambio di modello, dati, prompt, tool o finalità deve essere valutato prima del rilascio.
• AI literacy: formazione proporzionata per chi sviluppa, governa e usa i sistemi.

Vedi il testo ufficiale del Regolamento (UE) 2024/1689, gli obblighi dei deployer dell’articolo 26 e le FAQ ufficiali sull’articolo 50.

5. Un piano concreto per i primi 30 giorni

1. 01
   Censire

   Mappare sistemi, owner, finalità, dati, fornitori, utenti e persone coinvolte.

2. 02
   Classificare

   Determinare ruolo, categoria di rischio, obblighi settoriali e gap documentali.

3. 03
   Prioritizzare

   Intervenire prima sui sistemi con impatto sulle persone, dati sensibili o capacità di eseguire azioni.

4. 04
   Dimostrare

   Collegare ogni controllo a evidenze: test, log, decisioni, approvazioni e incidenti.

Come lavoriamo in Hoplo

Progettiamo agenti verticali attorno al lavoro reale: fonti ancorate, permessi minimi, approvazioni umane, audit trail e monitoraggio. In base al caso d’uso possiamo progettare architetture cloud europee, private, on-premise o air-gapped. La scelta viene documentata insieme ai controlli operativi, senza promettere una conformità automatica.

Nota legale. Questo contenuto è informativo e non costituisce consulenza legale, valutazione di conformità o certificazione. La disciplina applicabile dipende dal sistema, dalla finalità prevista, dal ruolo dell’organizzazione, dalla categoria di rischio e dalle altre norme applicabili. Per una prima autovalutazione è disponibile il Compliance Checker ufficiale della Commissione europea, anch’esso a scopo informativo.