Conformità all'EU AI Act: come Okta affronta il livello dell'identità

Introduzione

#

Qualche settimana fa, il mio amico Matteo Bisi ha pubblicato un eccellente articolo intitolato "August 2026 Countdown: K8s & AI Compliance", in cui esplora come i team Kubernetes possono prepararsi all’applicazione dell’EU AI Act attraverso l’automazione a livello di piattaforma. Admission controller, sidecar watermarking, AI-BOM: l’angolazione infrastrutturale è reale e importante.

Leggendolo, mi sono ritrovato a pensare: l’infrastruttura è necessaria, ma non sufficiente. Ogni AI agent che gira in un pod, chiama un’API o prende una decisione per conto di un utente è anche un’Identità. E la governance dell’identità, ovvero chi è l’agente, a cosa può accedere, chi ne è responsabile, e se il suo comportamento possa essere tracciato e sovrascritto, rappresenta la dimensione della conformità che gli strumenti infrastrutturali da soli non possono coprire.

Questa è la prospettiva che voglio portare in questo articolo, il quarto della serie O4AA — Okta for AI Agents:

• Nella Parte 1 abbiamo mappato l’Agentic Enterprise Blueprint: perché gli AI agent devono essere trattati come identità di primo livello, e quanto costa alle organizzazioni che non lo fanno lo shadow AI.
• Nella Parte 2 abbiamo introdotto i quattro pattern di accesso che governano il modo in cui gli agenti si autenticano alle risorse aziendali.
• Nella Parte 3 siamo entrati nei dettagli di protocollo: flussi ID-JAG, claim dei token, campi degli audit log e configurazione Okta per ciascun pattern.
• Qui, nella Parte 4, mappiamo l’EU AI Act, insieme ai corrispettivi NIST e NIS2/DORA, articolo per articolo sulle capacità di Okta, mostrando come O4AA trasforma i requisiti normativi in controlli operativi.

L’European Union Artificial Intelligence Act¹, entrato in vigore nell’agosto 2024 e pienamente applicabile entro agosto 2026, rappresenta il primo quadro normativo ampio e orizzontale sull’IA al mondo. Per le organizzazioni che implementano AI agent, crea obblighi di conformità specifici che convergono direttamente sulla gestione delle identità e degli accessi.

L’EU AI Act: un framework basato sul rischio

#

L’EU AI Act adotta un approccio basato sul rischio, classificando i sistemi di IA in quattro livelli:

1. 🚫 Rischio inaccettabile: I sistemi di IA che minacciano la sicurezza, i mezzi di sussistenza o i diritti (ad es. social scoring, identificazione biometrica in tempo reale negli spazi pubblici) sono vietati
2. ⚠️ IA ad alto rischio: I sistemi che impattano infrastrutture critiche, occupazione, servizi essenziali, forze dell’ordine o processi democratici devono soddisfare requisiti stringenti tra cui:
   • 🔁 Sistemi di gestione del rischio
   • 🗄️ Requisiti di governance e qualità dei dati
   • 📄 Documentazione tecnica
   • 🔍 Conservazione dei registri e tracciabilità
   • 👁️ Obblighi di trasparenza
   • 🧑‍💼 Meccanismi di supervisione umana
   • 🛡️ Requisiti di accuratezza, robustezza e cybersecurity
3. 💬 Rischio limitato: Sistemi di IA con obblighi di trasparenza (ad es. i chatbot devono dichiarare di essere IA)
4. ✅ Rischio minimo: IA senza restrizioni (ad es. filtri antispam)

Scadenze principali

#

L’applicabilità del regolamento avviene per fasi. Le organizzazioni non dovrebbero trattare agosto 2026 come un orizzonte lontano: diversi obblighi sono già in vigore:

Per la maggior parte degli AI agent aziendali, quelli utilizzati in ambito HR, customer service, credit scoring, fraud detection o security monitoring, la scadenza critica è il 2 agosto 2027 per i sistemi già implementati, il 2 agosto 2026 per le nuove implementazioni. Nessuno dei due orizzonti è lontano.

Livelli sanzionatori

#

La non conformità comporta sanzioni finanziarie graduali in base alla gravità della violazione:

Per PMI e startup, si applica in genere il tetto percentuale. L’implicazione a livello di consiglio d’amministrazione è chiara: la governance dell’identità IA rappresenta un rischio finanziario, non solo una questione tecnica.

Perché gli AI agent attivano obblighi di conformità

#

Gli AI agent aziendali rientrano spesso nelle categorie ad alto rischio o a rischio limitato, attivando obblighi di conformità sostanziali. I requisiti chiave si intersecano direttamente con la gestione delle identità:

• Tracciabilità: Le organizzazioni devono mantenere log di audit completi delle decisioni e azioni dei sistemi di IA. La governance dell’identità è un abilitatore fondamentale, ma non è l’unico livello richiesto: il logging applicativo, le pipeline SIEM e il system tracing contribuiscono tutti insieme ad essa. Protocolli come XAA/ID-JAG sono progettati tenendo conto di questo, incorporando un ID di transazione in ogni token per abilitare la correlazione cross-system dei log.
• Supervisione umana: I sistemi ad alto rischio richiedono una supervisione “human-in-the-loop” o “human-on-the-loop”, con meccanismi per mettere in pausa, sovrascrivere o revocare le azioni degli agenti
• Responsabilità: Le organizzazioni devono dimostrare chi ha autorizzato ciascun agente, a quali dati ha avuto accesso e quali azioni ha compiuto
• Trasparenza: Gli utenti devono sapere quando interagiscono con sistemi di IA, il che richiede una chiara identificazione degli agenti

Il regolamento prevede sanzioni fino a 35 milioni di euro o il 7% del fatturato annuo globale per le violazioni più gravi (vedi i livelli sanzionatori sopra), rendendo la governance dell’identità IA un imperativo di conformità a livello di consiglio d’amministrazione, non solo una questione tecnica¹.

L’Attribution Gap

#

Prima di addentrarci nei dettagli normativi, è utile definire con precisione il problema sottostante. Il team di ricerca di Okta lo chiama Attribution Gap²: l’incapacità di ricondurre le azioni di un AI agent a un decisore umano autorizzato.

Quando un AI agent approva un prestito, genera consulenza legale o modifica i permessi di accesso, l’organizzazione che lo implementa deve essere in grado di rispondere a cinque domande:

1. Quale agente ha eseguito l’azione?
2. Quali permessi aveva in quel momento?
3. Chi ha autorizzato quei permessi, e quando?
4. A quali dati ha avuto accesso?
5. Dov’è il registro immutabile di tutto quanto sopra?

Se a una di queste domande non si riesce a rispondere, l’organizzazione ha un attribution gap, e i regolatori non sono gli unici a fare domande. I tribunali stanno già stabilendo la responsabilità indipendentemente dal fatto che un framework formale di conformità sia stato violato, come dimostrano i casi Air Canada³, Replika⁴, Garcia v. Character Technologies⁵ e Nippon Life v. OpenAI⁶.

Lo schema in tutti e quattro i casi è identico: quando qualcosa va storto, regolatori e tribunali chiedono chi era responsabile, e le organizzazioni senza una chiara catena di autorizzazione non riescono a rispondere. Questo è il gap di conformità che la governance dell’identità deve colmare.

Mappatura della conformità articolo per articolo

#

Le sezioni seguenti mappano ogni obbligo dell’EU AI Act rilevante per l’identità al blueprint O4AA e alle specifiche funzionalità Okta che lo indirizzano.

Tracciabilità (Articolo 12)

#

Requisito: Le organizzazioni devono mantenere log che consentano la ricostruzione del comportamento e delle decisioni del sistema di IA.

Riferimento al blueprint:

• Audit log e telemetria — ogni azione dell’agente deve produrre un registro a prova di manomissione inoltrato a un SIEM centrale.
• Gestione del ciclo di vita dell’agente — ogni agente deve essere un’identità distinta con un proprietario umano associato, così che i log possano attribuire le azioni a esseri umani autorizzati.
• Agent Integration (MCP Server, SaaS Services, Agent-to-Agent Connections, Service Accounts, Vaulted Credentials) — tutti i pattern di accesso devono essere registrati con identificatori specifici dell’agente, mai con service account generici.

Soluzione Okta:

• Cross-App Access (XAA), grazie al token ID-JAG, incorpora nel contesto del token sia l’utente che ha autorizzato sia l’identità dell’agente — rendendo ogni azione attribuibile a una specifica coppia umano-agente. Consente inoltre di iniettare segnali di rischio personalizzati nel flusso di log, arricchendo i dati di tracciabilità con contesto come punteggi di rischio o indicatori di threat intelligence esterna
• Universal Directory assicura che ogni agente sia un’identità distinta con attributi di proprietario obbligatori, in modo che i log possano sempre attribuire le azioni a uno sponsor umano identificato. Il modello di identità O4AA garantisce che ogni voce di log sia attribuita a un principal non umano identificato, mai a un account condiviso
• La cronologia delle modifiche traccia ogni cambiamento alle policy o alle credenziali degli agenti
• System Log fornisce una traccia di audit completa degli eventi di registrazione, autenticazione, accesso e disattivazione degli agenti. I log registrano quale risorsa ogni agente ha raggiunto, quale azione è stata eseguita e il timestamp esatto, con un riferimento alla transazione che aiuta a correlare con i log delle applicazioni downstream.
• Integrazione nativa con piattaforme SIEM (come Splunk o Datadog) per la conservazione a lungo termine e la correlazione cross-system

Supervisione umana (Articolo 14)

#

Requisito: I sistemi di IA ad alto rischio devono consentire l’intervento, la supervisione o la disattivazione da parte dell’uomo.

Riferimento al blueprint:

• Human-in-the-loop — gate di approvazione che sospendono le operazioni dell’agente in attesa di una decisione umana
• Kill switch — revoca immediata e globale dell’accesso dell’agente
• Gestione del ciclo di vita dell’agente — sponsorizzazione umana e revisione periodica di ogni agente per garantire una supervisione continua

Soluzione Okta:

• Universal Logout: la revoca con una singola azione termina tutte le sessioni attive e i token per un dato agente istantaneamente, soddisfacendo il requisito di “capacità di disattivazione”
• Lifecycle Management (LCM): consente di disattivare o sospendere gli agenti in base a eventi del ciclo di vita, segnali di rischio o azioni manuali di uno sponsor umano
• Identity Governance (OIG) — Access Requests: i workflow di approvazione umana controllano la creazione degli agenti e qualsiasi espansione dei permessi; nessun agente ottiene accesso senza l’approvazione di uno sponsor umano identificato
• Identity Governance (OIG) — Certification Campaigns: revisioni programmate o attivate da eventi richiedono l’attestazione umana che l’accesso di ogni agente rimanga appropriato; gli agenti non attestati vengono automaticamente deprovisionati
• MFA step-up (CIBA) per le operazioni sensibili degli agenti aggiunge un checkpoint di verifica umana a runtime

Responsabilità e governance (Articolo 17)

#

Requisito: Assegnare la responsabilità per la conformità e il funzionamento del sistema di IA.

Riferimento al blueprint:

• Gestione del ciclo di vita dell’agente — onboarding governato, revisione e ritiro di ogni agente
• Rilevamento del rischio degli AI agent — valutazione continua del rischio legato ai privilegi e al comportamento degli agenti
• Rilevamento basato su browser — visibilità sugli shadow AI agent che aggirano i controlli di identità, con workflow per portarli in conformità

Soluzione Okta:

• Universal Directory (UD): gli agenti vengono provisionati come tipi di identità distinti con attributi di proprietario obbligatori, garantendo che la responsabilità sia incorporata nel modello di identità. Ogni agente registrato in Okta deve avere un proprietario umano identificato: la responsabilità è strutturale, non opzionale
• Lifecycle Management (LCM): workflow automatizzati, dalla creazione alla modifica (con cronologia delle modifiche tracciata) alla disattivazione (automatica su eventi del ciclo di vita o manuale da parte del proprietario)
• Identity Governance (OIG) — Access Requests: catena di approvazione documentata per il provisioning degli agenti, che crea un registro verificabile di chi ha autorizzato cosa, e quando
• Identity Governance (OIG) — Certification Campaigns: la revisione umana periodica impone disciplina nel ciclo di vita; gli agenti non più necessari vengono deprovisionati con cadenza regolare
• Privileged Access (OPA): le Pre-shared Key (PSK) e le credenziali API vengono custodite in vault e ruotate, eliminando il rischio di segreti orfani o utilizzati impropriamente che potrebbero portare ad azioni degli agenti non rendicontabili
• Identity Security Posture Management (ISPM): la scansione continua del livello di identità rileva agenti con privilegi eccessivi, credenziali dormienti e violazioni delle policy che potrebbero indicare una deriva dal modello di governance previsto. Il punteggio di rischio ISPM evidenzia gli agenti che accumulano permessi eccessivi per una remediation immediata

Trasparenza (Articolo 13, Articolo 52)

#

Requisito: Gli utenti devono essere informati quando interagiscono con sistemi di IA; i contenuti generati dall’IA devono essere dichiarati.

Riferimento al blueprint:

• Audit log e telemetria — i log distinguono le interazioni umane da quelle degli agenti
• Agent integrations — gli agenti sono registrati come principal distinti e identificabili

Soluzione Okta:

• Universal Directory: gli agenti vengono provisionati come classe di identità separata, mai fusi con gli account umani, rendendo la loro presenza inequivocabile in ogni interazione di autenticazione e API
• Cross-App Access (XAA): implementa lo standard OAuth ID-JAG per il SSO con credenziali client specifiche dell’agente. L’identità chiamante in ogni token è esplicitamente l’agente, non un service account generico o un utente
• System Log registra l’attribuzione umano-vs-agente su ogni evento, consentendo alle applicazioni downstream di mostrare la disclosure “questa azione è stata eseguita da un AI agent”

Requisiti di cybersecurity (Allegato IV)

#

Requisito: I sistemi di IA devono essere resilienti ad attacchi, manipolazione avversaria e accessi non autorizzati.

Riferimento al blueprint:

• Enforcement a runtime — enforcement degli scope e delle policy al momento dell’esecuzione
• Rilevamento del rischio degli AI agent — segnali di anomalia e minaccia in tempo reale
• Agent Integration (MCP Server, SaaS Services, Agent-to-Agent Connections) — pattern di autenticazione sicura e accesso con privilegi minimi
• Service Accounts e Vaulted Credentials — segreti gestiti al di fuori dell’agente, mai incorporati
• Kill Switch — revoca immediata dell’accesso dell’agente

Soluzione Okta:

• Privileged Access (OPA): il credential vaulting elimina i segreti statici incorporati nel codice dell’agente; la rotazione automatica minimizza la finestra di esposizione di qualsiasi credenziale
• API Access Management: gli scope OAuth 2.0 impongono i privilegi minimi a livello di API gateway, un agente può chiamare solo ciò che il suo token consente esplicitamente
• Identity Security Posture Management (ISPM): la scansione continua del livello di identità rileva misconfigurazioni, agenti con privilegi eccessivi, credenziali dormienti e derive rispetto alle baseline delle policy
• Identity Threat Protection (ITP): le analitiche comportamentali in tempo reale rilevano attività anomale degli agenti (volumi di dati insoliti, accessi fuori orario, movimenti laterali) e possono attivare remediation automatiche o Universal Logout
• MFA sull’emissione delle credenziali degli agenti aggiunge un ulteriore livello di autenticazione per le operazioni privilegiate

Gestione del rischio (Articolo 9)

#

Requisito: Istituire e mantenere un sistema di gestione del rischio lungo tutto il ciclo di vita del sistema di IA.

Riferimento al blueprint:

• Rilevamento del rischio degli AI agent — inventariare e assegnare un punteggio di rischio a ogni agente
• Enforcement a runtime — applicare controlli basati sul rischio in modo dinamico

Soluzione Okta:

• L’analisi della postura ISPM produce un inventario del rischio continuo: quali agenti esistono, a cosa possono accedere e dove esistono violazioni delle policy
• I segnali di rischio di ITP alimentano un punteggio di rischio dinamico: livello di privilegio, frequenza di accesso, sensibilità dei dati e anomalie comportamentali contribuiscono tutti a un punteggio di rischio per agente
• La pipeline di segnali di rischio di O4AA aggrega gli input da ISPM, ITP e threat intelligence esterna in una vista unificata del rischio degli agenti
• I workflow di governance in OIG traducono i punteggi di rischio in azioni automatizzate: segnalazione per la revisione, attivazione della certificazione o avvio del deprovisioning
• Il monitoraggio continuo e le notifiche chiudono il ciclo tra rilevamento e risposta lungo tutto il ciclo di vita degli agenti

Governance dei dati (Articolo 10)

#

Requisito: Implementare pratiche di governance dei dati che definiscano a quali dati i sistemi di IA possono accedere e come vengono trattati.

Riferimento al blueprint:

• Vaulted credentials — gli agenti non detengono mai credenziali persistenti di accesso ai dati
• Enforcement a runtime — i permessi sui dati vengono applicati al momento della chiamata, non incorporati nell’agente

Soluzione Okta:

• API Access Management: i token OAuth 2.0 basati su scope limitano ogni agente esattamente agli endpoint di dati che è autorizzato a chiamare, senza accesso implicito o ereditato
• Fine-grained authorization (FGA): il controllo degli accessi basato sulle relazioni applica l’accesso ai dati a livello di oggetto, garantendo che gli agenti possano leggere o scrivere solo i record per cui sono esplicitamente autorizzati
• Privileged Access (OPA): le credenziali dei data store (password di database, API key) vengono custodite in vault e iniettate a runtime; gli agenti non hanno mai accesso permanente ai dati sensibili
• System Log produce un registro completo di ogni evento di accesso ai dati da parte di ogni agente, soddisfacendo i requisiti di documentazione dell’Articolo 10 per dataset di training, validazione e produzione

Allineamento al NIST AI RMF

#

Per le organizzazioni che operano a livello globale, o che seguono già i framework NIST per la cybersecurity o lo sviluppo software, il NIST AI Risk Management Framework (AI RMF 1.0)⁷, pubblicato nel gennaio 2023, rappresenta un complemento volontario ma ampiamente adottato ai requisiti obbligatori dell’EU AI Act.

L’AI RMF si articola attorno a quattro funzioni principali:

Sebbene il NIST AI RMF sia un framework statunitense e di natura volontaria, viene sempre piu citato da regolatori e auditor europei come metodologia di best practice riconosciuta. Si allinea inoltre strutturalmente con l’Articolo 9 dell’EU AI Act (sistemi di gestione del rischio), fornendo un ponte utile per le organizzazioni multinazionali che devono soddisfare entrambi i framework.

Riferimenti complementari:

• NIST SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models⁸
• NIST AI RMF Playbook — Guida pratica all’implementazione mappata su ciascuna funzione principale

Convergenza normativa: NIS2 e DORA

#

L’EU AI Act non opera in modo isolato. Le organizzazioni nei settori regolamentati affrontano obblighi sovrapposti: la conformità all’EU AI Act si interseca con NIS2 e DORA in modi che condividono un denominatore comune: la governance dell’identità.

NIS2 (Direttiva 2022/2555)

#

La Direttiva NIS2 si applica a entità essenziali e importanti in settori critici: energia, finanza, sanità, trasporti, infrastrutture digitali e pubblica amministrazione. Gli AI agent che operano in questi settori attivano obblighi NIS2 inseparabili dall’identità:

• Articolo 21 — Misure obbligatorie di gestione del rischio che includono controllo degli accessi, autenticazione e gestione degli asset per tutti i sistemi ICT
• Sicurezza della supply chain — Le organizzazioni devono governare i componenti IA di terze parti e le identità che portano con sé
• Segnalazione degli incidenti — Gli incidenti significativi devono essere segnalati entro 24 ore (early warning) e 72 ore (report completo); un malfunzionamento di un AI agent può rientrare nell’obbligo se causa una violazione della sicurezza o un’interruzione significativa dei servizi — anche se NIS2 non fa riferimento esplicito all’IA, e non ogni malfunzionamento raggiunge la soglia di notifica

Intersezione con l’identità: Un AI agent che bypassa l’MFA, agisce al di fuori del proprio scope autorizzato o non può essere tracciato in un audit log rappresenta un’inadempienza NIS2, non solo un incidente di sicurezza.

DORA (Regolamento 2022/2554)

#

Il Digital Operational Resilience Act si applica alle entità finanziarie: banche, assicurazioni, istituti di pagamento, fornitori di servizi di cripto-asset e i relativi fornitori ICT terzi critici. Gli AI agent in ambito FinTech e FinServ devono soddisfare:

• Articolo 9 — Requisiti di sicurezza delle informazioni che includono gestione delle identità e degli accessi, autenticazione forte e controlli sugli accessi privilegiati
• Articolo 28 — Gestione del rischio ICT di terze parti: governance degli accessi documentata, diritti di audit e supervisione contrattuale per qualsiasi provider di IA con accesso ai sistemi finanziari
• Test di resilienza — DORA richiede test regolari dei sistemi ICT, incluso il comportamento degli AI agent in condizioni di stress o avversarie

Intersezione con l’identità: I requisiti DORA per il controllo degli accessi documentato, le tracce di audit immutabili e la responsabilità contrattuale per l’accesso di terze parti mappano direttamente su ciò che O4AA fornisce attraverso OIG, System Log e API Access Management.

Un investimento coordinato nella governance dell’identità IA basata su O4AA affronta i requisiti del livello identità condivisi tra EU AI Act, NIS2 e DORA — riducendo le duplicazioni e favorendo un approccio integrato. La governance dell’identità è una componente necessaria per tutti e tre i framework; non sostituisce però la governance organizzativa, la documentazione dei processi e i controlli tecnici aggiuntivi che ciascun regolamento richiede.

Roadmap di implementazione per la conformità all’EU AI Act

#

Non bisogna aspettare agosto 2026 per iniziare a colmare l’attribution gap. I requisiti di conformità descritti sopra non sono solo obblighi futuri: sono best practice attuali per un’implementazione responsabile dell’IA. Le organizzazioni che ritardano rischiano di cadere nella trappola dello “shadow AI”, dove gli agenti proliferano senza governance, creando una bomba a orologeria di non conformità.

Fase 1: Discovery e assessment

#

Obiettivo: Stabilire una visibilità di base e identificare i gap di conformità.

Azioni:

• Abilitare Shadow AI Discovery per catalogare tutti gli AI agent
• Valutare ogni agente rispetto alle categorie di rischio dell’EU AI Act
• Identificare gli agenti ad alto rischio che richiedono governance immediata
• Documentare le attuali capacità di audit e logging

Strumenti Okta: Shadow AI Agent Discovery, ISPM, Universal Directory

Fase 2: Governance e responsabilità

#

Obiettivo: Stabilire meccanismi di ownership e supervisione.

Azioni:

• Assegnare sponsor umani a tutti gli AI agent
• Implementare workflow di approvazione per la creazione e la modifica degli agenti
• Avviare campagne di certificazione per gli agenti esistenti
• Stabilire procedure di Universal Logout

Strumenti Okta: OIG, Workflows, Universal Directory, Universal Logout

Fase 3: Controlli runtime e monitoraggio

#

Obiettivo: Applicare i privilegi minimi e abilitare la supervisione in tempo reale.

Azioni:

• Implementare API Access Management basato su scope
• Implementare ITP per le analitiche comportamentali
• Configurare l’integrazione SIEM per la conservazione degli audit log
• Stabilire le notifiche per le violazioni delle policy

Strumenti Okta: XAA, API Access Management, ITP, ISPM, System Log

Fase 4: Conformità continua

#

Obiettivo: Mantenere la postura di conformità e adattarsi agli aggiornamenti normativi.

Azioni:

• Programmare campagne di certificazione regolari
• Monitorare le dashboard ISPM per le derive dalla conformità
• Condurre audit di conformità periodici
• Aggiornare le policy in base alle linee guida normative

Strumenti Okta: OIG, ISPM, Workflows

Conclusioni

#

Ciò che l’articolo di Matteo e questo condividono, nonostante le prospettive diverse, è lo stesso messaggio di fondo: la conformità non avviene per caso. Richiede un’architettura deliberata, e per gli AI agent quell’architettura parte dall’Identità.

L’EU AI Act crea obblighi chiari, ma le organizzazioni nei settori regolamentati affrontano piu di un framework. Una banca che implementa un AI agent per il rischio di credito è simultaneamente soggetta all’EU AI Act (se ad alto rischio), a NIS2 (come entità finanziaria che gestisce il rischio ICT) e a DORA (per la resilienza ICT e la supervisione delle terze parti). I requisiti di identità incorporati in ogni regolamento si sovrappongono significativamente. Risolverli una sola volta, al livello dell’identità, è piu efficiente e piu duraturo che affrontare ogni regolamento separatamente.

L’O4AA — Agentic Enterprise Blueprint di Okta fornisce quella base unificata:

• Tracciabilità completa tramite audit log e integrazione SIEM (EU AI Act Art. 12, NIS2 Art. 21, DORA Art. 9)
• Supervisione umana attraverso workflow di approvazione e Universal Logout (EU AI Act Art. 14, NIST MANAGE)
• Responsabilità chiara con attribuzione obbligatoria della proprietà (EU AI Act Art. 17, DORA Art. 28, NIST GOVERN)
• Trasparenza che separa le identità degli agenti da quelle umane (EU AI Act Art. 13/52, NIST MAP)
• Resilienza cyber attraverso ISPM, ITP e gestione delle credenziali (EU AI Act Allegato IV, NIS2/DORA Art. 9)

La scadenza di agosto 2026 non è lontana. Per le organizzazioni ancora nella fase di shadow AI, dove gli agenti vengono implementati senza governance, il divario tra lo stato attuale e la prontezza alla conformità è significativo. I framework trattati in questo articolo (EU AI Act, NIST AI RMF, NIS2, DORA) non sono un peso burocratico. Sono il progetto per il tipo di implementazione dell’IA di cui le organizzazioni, i regolatori e gli utenti finali possono davvero fidarsi.

Qual è la postura di conformità della tua organizzazione oggi? Sei in anticipo o stai ancora mappando quali agenti hai? 👇

✋ Prossimi passi

#

Per approfondire

#

• Proteggere l’IA: il blueprint Okta per l’agentic enterprise sicura — Serie O4AA 1: perché gli AI agent necessitano di una governance dell’identità di primo livello
• Okta for AI Agents: Pattern di Accesso — Serie O4AA 2: come gli agenti si autenticano alle risorse aziendali
• Agentic Enterprise Blueprint: Scarica la guida completa al framework
• EU AI Act Full Text: Testo ufficiale del regolamento
• NIST AI RMF 1.0: Il NIST AI Risk Management Framework
• The Attribution Gap: AI Regulation (Okta) — come l’incapacità di tracciare le azioni degli agenti fino agli umani autorizzati crea esposizione legale e normativa
• EU AI Act Explorer — guida interattiva al regolamento: articoli, considerando, obblighi per ruolo e tempistiche di conformità
• OWASP Top 10 for Large Language Model Applications — la lista canonica dei rischi di sicurezza per i sistemi basati su LLM; direttamente rilevante per la modellazione delle minacce degli agenti e gli obblighi di cybersecurity dell’Allegato IV

💬 Partecipa alla conversazione

#

Come si sta preparando la tua organizzazione alla conformità all’EU AI Act? Quali sfide stai affrontando con la governance degli AI agent?

Condividi la tua esperienza nei commenti qui sotto o connettiti con me su LinkedIn per continuare la discussione.