Tag: GDPR

Il 2 agosto 2026 entrano in piena applicazione gli obblighi del Regolamento UE 2024/1689, l’AI Act, per i sistemi di intelligenza artificiale classificati ad alto rischio. Mancano poco più di due mesi al momento in cui scrivo, e nelle ultime settimane mi è capitato di sedermi a quattro tavoli diversi con responsabili compliance, CTO e direttori generali italiani, che mi hanno tutti fatto la stessa domanda, declinata in modi diversi: “Siamo davvero pronti?”. La risposta media che ho dato è: ancora no, ma il tempo per chiudere il gap c’è, se si parte adesso.

In questo articolo provo a tradurre l’AI Act in una checklist operativa per chi opera nei due settori dove l’urgenza è massima: finanza e sanità. Non è un articolo giuridico (per quello ci sono ottimi studi legali italiani specializzati), è un articolo da chi ha visto cosa succede dentro le aziende quando si avvicina una scadenza regolatoria seria.

Le date che contano

L’AI Act è entrato formalmente in vigore il 1 agosto 2024, con applicazione progressiva su quattro tappe. La prima, 2 febbraio 2025, ha introdotto i divieti per i sistemi a rischio inaccettabile (social scoring, manipolazione comportamentale dannosa, riconoscimento biometrico massivo) e l’obbligo di alfabetizzazione AI del personale. La seconda, 2 agosto 2025, ha attivato gli obblighi per i modelli di AI generativa di uso generale (GPAI), come Claude, GPT, Gemini, e ha richiesto agli Stati membri di nominare le autorità nazionali competenti (in Italia, l’AgID).

La terza tappa, 2 agosto 2026, è quella che riguarda la maggior parte delle aziende italiane che usano l’AI nei processi. Da quella data, tutti i sistemi classificati come ad alto rischio devono essere conformi a obblighi sostanziali in materia di risk management, qualità dei dati, documentazione tecnica, supervisione umana, robustezza, cybersecurity, e devono essere registrati nel database europeo dei sistemi AI ad alto rischio. La quarta tappa, 2 agosto 2027, riguarda specificamente i dispositivi medici AI che già rientrano nelle normative di conformità di prodotto.

Le sanzioni sono articolate. Per i sistemi vietati, fino a 35 milioni di euro o 7% del fatturato annuo globale (il valore maggiore). Per gli obblighi sui sistemi ad alto rischio, fino al 3% del fatturato globale. Per informazioni inesatte alle autorità, fino a 7,5 milioni di euro. Per le PMI, si applica l’importo inferiore tra cifra fissa e percentuale, ma non c’è esenzione: una PMI con 2 milioni di fatturato rischia fino a 60.000 euro su obblighi alto rischio, non rovinosa ma abbastanza da rendere la compliance un investimento razionale.

Cosa è “alto rischio” nei vostri processi

L’Allegato III del Regolamento elenca le categorie di sistemi AI considerate ad alto rischio per ragioni di impatto su diritti fondamentali, salute e sicurezza. Vale la pena leggerle con attenzione perché il perimetro è più largo di quanto molti pensino.

Finanza. Sistemi AI usati per credit scoring, valutazione del merito creditizio delle persone fisiche, risk scoring assicurativo per la determinazione dei premi sulla vita e sulla salute, valutazione delle frodi che impatti direttamente decisioni sui clienti. Una banca italiana media-piccola, una compagnia assicurativa, una fintech che fa lending automatizzato hanno tutti almeno un sistema dentro questo perimetro. Le grandi banche italiane stanno già lavorando, le piccole e medie spesso non sanno ancora di doverlo fare.

Sanità. Sistemi di supporto decisionale clinico, diagnostica AI, triage automatizzato di pazienti, sistemi che determinano l’accesso a servizi sanitari o prestazioni assistenziali pubbliche, AI per la gestione delle emergenze sanitarie. Praticamente ogni applicazione AI in un ospedale o azienda sanitaria territoriale italiana ricade qui.

HR. Sistemi per il recruiting automatizzato, screening dei CV, valutazione delle performance, decisioni su promozioni, demansionamenti, licenziamenti, accesso alla formazione. È la categoria che riguarda la maggior parte delle aziende italiane sopra i 100 dipendenti, soprattutto quelle che hanno adottato sistemi di people analytics negli ultimi anni.

PA. Sistemi usati per accesso a servizi pubblici essenziali, valutazione di richieste di immigrazione e asilo, sistemi giudiziari predittivi, polizia predittiva. Tutto il PSN italiano e diverse iniziative AI di amministrazioni regionali ricadono qui.

Infrastrutture critiche. Sistemi che gestiscono o supervisionano reti energetiche, idriche, di trasporto, sistemi di telecomunicazione. Per chi lavora in questi settori, lo scrutinio è massimo.

L’attribuzione della categoria non è automatica né certificata da un’autorità prima del rilascio. La responsabilità è del provider del sistema (chi lo sviluppa) e del deployer (chi lo usa). Sarà verificata ex post dalle autorità di vigilanza, in Italia l’AgID. La domanda da farsi oggi è semplice: avete fatto una mappatura formale dei vostri sistemi AI e li avete classificati ai sensi dell’AI Act? Se la risposta è no, è il primo passo da fare.

Gli otto obblighi sostanziali sui sistemi alto rischio

Per ogni sistema classificato ad alto rischio, gli obblighi che diventano operativi il 2 agosto 2026 sono otto. Provo a riassumerli con un occhio operativo, non giuridico.

1. Sistema di gestione del rischio. Procedura documentata che identifica, valuta e mitiga i rischi del sistema AI per tutto il suo ciclo di vita, dalla progettazione al ritiro. Deve essere aggiornata continuamente, non un documento una tantum.

2. Qualità e governance dei dati. I dataset di training, validation e testing devono essere rappresentativi, accurati, esenti da bias significativi. Per modelli open-weight (Llama, Mistral, Qwen) significa che dovete documentare con cura quale modello state usando, con quale dataset di fine-tuning, e attestare che avete fatto le verifiche di qualità.

3. Documentazione tecnica. Deve descrivere il sistema, le sue funzionalità, i dati usati, le metriche di performance, i limiti noti. È un documento corposo, paragonabile alla documentazione tecnica richiesta per i dispositivi medici, e deve essere mantenuto aggiornato.

4. Logging e tracciabilità. Il sistema deve registrare automaticamente gli eventi rilevanti durante l’uso, con un livello di dettaglio sufficiente a permettere audit post-incidente. Non è banale tecnicamente, soprattutto per applicazioni AI che usano LLM cloud dove il logging delle prompt e degli output deve essere strutturato.

5. Trasparenza e informazione all’utente. L’utente del sistema deve sapere che sta interagendo con un AI, deve capire come funziona, deve essere informato dei limiti. Per un chatbot di customer service, significa disclaimer e onboarding. Per un sistema di decision support, significa documentazione del processo decisionale.

6. Supervisione umana. Deve esistere un meccanismo per cui un operatore umano può intervenire, sospendere, correggere le decisioni del sistema. Per applicazioni completamente automatizzate, il design deve esplicitamente prevedere punti di override umano.

7. Robustezza, accuratezza e cybersecurity. Il sistema deve essere testato per resistere a tentativi di manipolazione, deve avere metriche di accuratezza documentate, deve essere protetto da attacchi (prompt injection, data poisoning, model extraction).

8. Registrazione nel database europeo. Tutti i sistemi AI ad alto rischio dei provider (chi sviluppa) devono essere registrati nel database centrale europeo, accessibile pubblicamente. È una sorta di registro internazionale dei sistemi AI critici dell’UE.

Il caso operativo di una banca italiana media

Vorrei provare a tradurre questa lista in cosa fa concretamente un’azienda. Prendiamo una banca italiana media (50 sportelli, 700 dipendenti) che usa tre sistemi AI principali: credit scoring per i mutui retail, antifrode automatizzato sui pagamenti, chatbot di customer service in app.

Il credit scoring è inequivocabilmente alto rischio. Va fatta DPIA combinata con AI Act assessment, documentata la pipeline di training (con quali dati storici, con quale provider del modello, con quale tasso di errore noto), implementata supervisione umana effettiva (non basta una casella “approva/rifiuta”, deve esserci processo di review), preparata la documentazione tecnica, registrato il sistema nel database europeo.

L’antifrode pagamenti è una zona grigia. Se prende decisioni che impattano direttamente i clienti (blocco di una carta, sospensione di un pagamento), è alto rischio. Se invece genera solo alert per analisti umani che poi decidono, è basso rischio. La differenza sta nel grado di automazione effettiva. Vale la pena formalizzare la classificazione.

Il chatbot di customer service rientra negli obblighi di trasparenza (l’utente deve sapere che sta parlando con un AI), ma non in alto rischio se non prende decisioni sostantive. Va comunque documentato, monitorato, dotato di escalation a operatore umano.

Per una banca così, il lavoro di compliance AI Act richiede 4-8 mesi di lavoro di un team misto IT-legale-compliance, e costa fra 80.000 e 200.000 euro fra consulenze esterne e tempo interno. Sostenibile, ma da pianificare adesso, non a luglio.

Perché l’AI privata semplifica drammaticamente la compliance

Un punto che emerge in modo trasversale su tutti gli otto obblighi: alcuni sono molto più facili da gestire se il modello AI gira nella vostra infrastruttura invece che essere chiamato via API cloud.

Sulla documentazione del modello, su un sistema cloud (Claude, GPT) avete accesso limitato: dovete fidarvi della documentazione che il provider rende disponibile, che non sempre è sufficiente per l’AI Act. Su un modello open-weight in casa (Llama, Mistral, Qwen), avete il modello, sapete da dove viene, potete documentare il fine-tuning, attestare la pipeline.

Sul logging, su cloud dovete loggare voi tutte le chiamate API, e il provider potrebbe non darvi accesso ai logging interni. Su on-premise, il logging è completo, sotto controllo, archivable secondo i vostri standard.

Sulla qualità dei dati, su cloud non sapete davvero su cosa è stato addestrato il modello del provider. Su on-premise con un modello open-weight, sapete almeno cosa è dichiarato nel paper di training del modello base, e sapete esattamente i vostri dati di fine-tuning.

Sulla robustezza, su cloud i test di sicurezza che potete fare sono limitati ai casi non distruttivi. Su on-premise potete fare red teaming completo, simulare attacchi, validare la postura di sicurezza in modo molto più approfondito.

Sulla registrazione nel database europeo, è obbligo del provider, non del deployer. Quindi: se usate un modello cloud americano, il provider è OpenAI o Anthropic, che dovrà fare la registrazione lui. Se usate un modello open-weight in casa con fine-tuning vostro, voi siete il provider del sistema specifico che usate, quindi dovete farlo voi (con sforzo accessibile, è una procedura documentale).

In sintesi, le aziende italiane di finanza e sanità che stanno scegliendo l’AI privata oggi non lo fanno solo per ragioni di sovranità del dato. Lo fanno anche perché l’AI Act è strutturalmente più semplice da rispettare su un perimetro che controllate.

Quattro azioni concrete da fare entro luglio 2026

Riassumo in quattro azioni operative quello che le aziende italiane sotto AI Act dovrebbero avere fatto prima della scadenza.

Inventario e classificazione. Mappare tutti i sistemi AI in uso in azienda (anche quelli che il business non sa di chiamare “AI”, come algoritmi di scoring legacy o automazioni machine learning vecchie), classificarli rispetto all’Allegato III. Output: un registro dei sistemi AI aziendali con la categoria di rischio attribuita.

Gap analysis. Per ogni sistema ad alto rischio, valutare lo stato attuale di compliance sugli otto obblighi. Output: una matrice sistema × obbligo con verde/giallo/rosso, e per ogni rosso un piano di adeguamento.

Adeguamento documentale e tecnico. Eseguire il piano di adeguamento. Per chi parte da zero, è il lavoro più lungo, soprattutto su sistema di gestione del rischio, documentazione tecnica, logging strutturato.

Governance permanente. L’AI Act richiede un cambio strutturale nella gestione dell’AI in azienda, non una compliance una tantum. Va istituito un AI Governance Committee (anche piccolo, in PMI può essere CIO + DPO + un legale), va definito chi fa il monitoring continuo, vanno aggiornati i contratti con i fornitori di sistemi AI per riflettere le nuove responsabilità.

Per chi opera in finanza, sanità, PA, e non ha ancora avviato questo percorso, vale la pena partire questa settimana. Lo dico senza catastrofismo, ma due mesi sono pochi per fare un’inventario serio e iniziare almeno l’adeguamento dei sistemi più critici.

Per chi sta valutando se accelerare la migrazione a un’infrastruttura AI privata anche per ragioni di compliance, è una decisione che entra naturalmente nel piano AI Act. Su questo lavoro come cofondatore di LocalAI.io, che è il gateway open-source che facilita il setup di un ecosistema AI privato auditable, documentabile, sotto controllo aziendale. Ho scritto recenti articoli su come scegliere il modello open-weight giusto, su GDPR e LLM, su hardware locale, che insieme coprono lo stack di decisione completo. Per una conversazione specifica sulla vostra situazione AI Act, c’è la pagina Advisory.

La domanda finale è una sola, e va portata al primo consiglio di amministrazione utile. Siamo in grado di dimostrare, davanti a un’ispezione AgID nei prossimi 12 mesi, che i nostri sistemi AI ad alto rischio rispettano il regolamento? Se la risposta del CIO è “credo di sì”, è il momento di trasformare quel “credo” in evidenze documentali strutturate.

Il 18 marzo 2026 il Tribunale di Roma ha annullato la sanzione da 15 milioni di euro che il Garante per la protezione dei dati personali aveva irrogato a OpenAI nel novembre 2024 per la gestione di ChatGPT. Sentenza 4153/2026, motivazioni non ancora depositate, solo dispositivo. Quella sanzione era diventata, in due anni, il caso simbolo del rapporto fra GDPR e LLM. Adesso è caduta, e con lei l’idea che bastasse un provvedimento del Garante a chiarire i confini fra normativa europea e AI generativa americana.

Però il problema giuridico resta intatto: quando un dipendente di un’azienda italiana scrive il nome di un cliente dentro ChatGPT o Claude per riassumere un contratto, quel dato attraversa l’Atlantico, finisce in un’infrastruttura americana, viene processato da un modello di cui non controlliamo i dataset di training, e torna indietro come output. Sopra questo flusso si sovrappongono GDPR, AI Act, Schrems II, Data Privacy Framework, decisioni dei garanti nazionali, sentenze dei tribunali. Il risultato per chi lavora in azienda è una tela densa di vincoli che cambiano spesso, raramente in modo sincronizzato, e ognuno applicabile a casi specifici che non sempre il giurista interno riesce a circoscrivere bene.

Mi capita spesso, lavorando come advisor con CEO e CTO italiani, di sentire la stessa domanda formulata in modi diversi: ma alla fine, posso usare OpenAI sui dati dei miei clienti, o no? La risposta breve è che dipende, e quel dipende è dove si sta giocando una partita seria fra sovranità giuridica europea e dominanza tecnologica americana. Vorrei provare a dare una mappa praticabile, da imprenditore che ha visto il problema dal vivo, non da giurista.

Cosa dice il GDPR di un dato che entra in un LLM

Il GDPR è del 2016, è entrato in applicazione nel 2018, e nessuno dei suoi articoli è stato scritto pensando ai large language model. Però i suoi principi cardine restano applicabili a qualsiasi trattamento di dati personali, e un prompt che contiene il nome di una persona, l’indirizzo di un’azienda, una mail di un fornitore, una pratica medica, sono tutti dati personali ai sensi dell’articolo 4.

Quattro dimensioni del GDPR si attivano quando un dato personale finisce dentro un LLM cloud: la base giuridica del trattamento (articolo 6), la trasparenza nei confronti dell’interessato (articoli 12-14), la minimizzazione del dato (articolo 5), e il trasferimento internazionale verso paesi terzi (capitolo V, articoli 44-50). Il caso ChatGPT ha attivato tutte e quattro: il Garante italiano contestava a OpenAI di non avere una base giuridica adeguata per addestrare il modello sui dati personali, di non aver dato informativa agli interessati, di non aver implementato sistemi di age verification, e di trasferire dati verso gli Stati Uniti.

Il punto più sottile, però, è il quarto. Schrems II ha invalidato nel luglio 2020 il Privacy Shield che fino ad allora regolava il flusso di dati UE-USA. Da quel momento, ogni azienda europea che usa un servizio americano deve fare una valutazione caso per caso del rischio di sorveglianza governativa, deve adottare clausole contrattuali standard rafforzate, deve implementare misure tecniche supplementari come la cifratura end-to-end con chiavi che restano in UE. Nel luglio 2023 è arrivato il Data Privacy Framework, terzo tentativo dopo Safe Harbor e Privacy Shield, e Max Schrems ha già annunciato che lo porterà nuovamente davanti alla Corte di Giustizia. La storia, vista dall’esterno, sembra un loop che continua a non chiudersi.

Il caso ChatGPT e cosa è successo davvero

Vale la pena ricostruire il caso in tre passaggi, perché segna lo stato dell’arte del rapporto fra LLM e GDPR in Italia.

Marzo 2023: il Garante blocca temporaneamente ChatGPT in Italia per la prima volta. OpenAI si adegua su quasi tutti i punti contestati, il servizio viene riattivato dopo qualche settimana. Dicembre 2024: il Garante conclude l’istruttoria e sanziona OpenAI per 15 milioni di euro, ordinando anche una campagna informativa di sei mesi. Marzo 2026: il Tribunale di Roma annulla la sanzione, sentenza 4153/2026. Le motivazioni non sono ancora pubbliche al momento in cui scrivo, però il dispositivo è chiaro: la sanzione cade integralmente.

Cosa significa per chi deve decidere oggi se usare ChatGPT, Claude o Gemini sui dati aziendali? Tre cose, secondo me. La prima è che lo strumento sanzionatorio del Garante è meno solido di quanto sembrasse: i tribunali stanno mostrando di poter ribaltare provvedimenti anche molto strutturati. La seconda è che il fatto stesso che il caso sia arrivato fino qui dimostra quanto la materia sia controversa, e che ogni azienda italiana resta esposta a contestazioni se non struttura bene la propria posizione documentale. La terza è la più importante: l’annullamento della sanzione non significa che il trattamento sia lecito, significa solo che quel provvedimento specifico non reggeva. Il sostrato GDPR resta in piedi, e il prossimo caso può essere il vostro.

Le quattro verticali italiane dove il problema è già operativo

Negli ultimi diciotto mesi ho seguito direttamente o di sponda progetti in quattro settori italiani dove l’uso degli LLM cloud sta già generando attriti giuridici concreti. Vorrei riportare cosa ho visto succedere.

Banche e finanza. Le grandi banche italiane hanno tutte progetti AI attivi, però il commitment legale è massimo. Le sandbox interne usano modelli open-weight in infrastruttura privata. L’uso di ChatGPT o Claude su dati di clientela è proibito per policy nella stragrande maggioranza dei casi. Le DPIA (Data Protection Impact Assessment) sono diventate documenti corposi, con sezioni dedicate ai modelli AI, e gli ispettori di Banca d’Italia stanno cominciando a chiederle. Per le banche medio-piccole, che non hanno il budget per un’infrastruttura AI privata, il dilemma è reale: aspettare l’evoluzione normativa, o cominciare con il cloud accettando il rischio. La risposta che vedo emergere è terza: AI privata su Mistral, Llama o modelli simili, gestita on-premise o su cloud sovrano italiano.

Sanità. Qui la sensibilità è massima per ovvi motivi: i dati sanitari sono categoria particolare ai sensi dell’articolo 9 GDPR. Le aziende sanitarie pubbliche e private che ho visto adottare LLM stanno tutte andando su soluzioni private. Niente ChatGPT, niente Claude.ai dalla finestra del browser. Strumenti AI integrati nei gestionali clinici, con modelli fine-tuned su dataset sanitari e infrastruttura sotto controllo dell’azienda. Il vincolo qui è doppio: GDPR più normativa specifica sanitaria, e nessun primario è disposto a mettere la firma su un trattamento dove il dato esce dal perimetro ospedaliero.

Pubblica amministrazione. Il PSN (Polo Strategico Nazionale) e l’Agenzia per la Cybersicurezza Nazionale stanno dettando linee guida sempre più stringenti sull’uso di AI nei processi della PA. La direzione è chiara: dati pubblici dei cittadini italiani devono restare in cloud sovrani, su infrastrutture nazionali. Questo apre uno spazio commerciale enorme per soluzioni AI private che possano installarsi dentro il perimetro PSN. Diverse software house italiane si stanno posizionando su questo, e ho il sospetto che nei prossimi diciotto mesi vedremo accelerazione forte.

Manifattura e proprietà intellettuale. Qui il problema non è solo il dato personale, è il segreto industriale. Aziende manifatturiere italiane che caricano disegni tecnici, formule, processi produttivi dentro ChatGPT per chiedere ottimizzazioni stanno regalando informazioni potenzialmente strategiche a un fornitore che, per quanto contrattualmente impegnato a non trainare sui dati enterprise, opera comunque sotto giurisdizione americana. Il punto qui sfora dal GDPR, va su trade secret, segreto industriale, sicurezza economica nazionale. Però è una conversazione che adesso i CTO italiani fanno con i CEO, e prima non si faceva.

La banca italiana che voleva sapere dove gira il modello

Racconto una scena reale, leggermente anonimizzata. Lavoro nel 2025 con il team innovazione di una banca italiana medio-grande che sta valutando di adottare un sistema AI generativa per la customer assistance. Il fornitore propone un’integrazione standard con un grande modello cloud americano. Il responsabile compliance, dopo aver letto il contratto, chiede una cosa apparentemente semplice: “Possiamo avere certezza che, quando un nostro consulente filiale interroga il sistema con il nome di un cliente per ricostruire la sua posizione, quel nome non passi per un data center fuori dall’Unione?”. Il fornitore impiega due settimane per rispondere, poi torna con una soluzione ibrida che usa pre-processing locale e poi chiama il modello cloud su dati anonimizzati. Funziona, ma costa il doppio del setup originale, e introduce latenza.

Quella domanda era la domanda giusta, ed è la domanda che oggi fanno i clienti sofisticati durante le RFP. Se la vostra applicazione AI non sa rispondere bene a quella domanda, perde la gara. E rispondere bene, sempre più spesso, significa: “Il modello gira nella nostra infrastruttura, sotto controllo italiano, mai i dati escono dal perimetro”.

L’unica architettura che chiude il problema alla radice

Ci sono tre modi di gestire la conformità GDPR su un’applicazione AI in produzione. Il primo è usare un grande LLM cloud americano e costruire un apparato documentale e contrattuale robusto (DPIA, clausole contrattuali, registro dei trattamenti, valutazione TIA per il trasferimento dati). Funziona, ma è costoso da mantenere, e ogni cambio di policy del fornitore impone una nuova valutazione. Il secondo è usare un LLM cloud europeo, tipo Mistral hostato in Francia. Mitiga il problema del trasferimento extra-UE, ma non lo elimina del tutto perché Mistral comunque processa dati su infrastruttura cloud condivisa. Il terzo è portare il modello in casa, on-premise o su cloud privato sotto controllo aziendale.

Il terzo modo, che fino a due anni fa era proibitivo per ragioni di capex hardware e complessità operativa, oggi è alla portata di aziende dai 50 dipendenti in su. I modelli open-weight (Llama 3.3, Mistral, Qwen, DeepSeek) sono molto vicini alle prestazioni dei top di gamma cloud sui task aziendali standard. L’hardware necessario per farli girare in locale è sceso a una frazione di quello che serviva nel 2023. E lo stack software per orchestrarli sta maturando rapidamente.

Su questo terreno ho investito personalmente, come cofondatore di LocalAI.io. LocalAI è un progetto open-source che permette di costruire ecosistemi di AI privata partendo dai modelli open-weight esistenti, con tutto lo stack che serve per portare un prodotto in produzione: gateway compatibile con le API OpenAI, gestione di modelli multipli, RAG, agenti con memoria, deployment on-premise o su cloud privato italiano. È usato in produzione da aziende che hanno deciso di avere il proprio strato AI in casa, e da team che vogliono mantenere la flessibilità di cambiare modello senza rifare il prodotto.

La conversazione su GDPR e LLM nel 2026 si è spostata. Da terreno legale astratto è diventata terreno di architettura concreta. Le aziende italiane che capiscono questo, e che spostano il proprio stack AI dentro un perimetro controllato, eliminano alla radice il 70-80% delle questioni che oggi tengono sveglio il responsabile DPO. Le altre continueranno a discutere clausole contrattuali con i fornitori americani, a stipulare TIA che invecchiano dopo pochi mesi, a sperare che il prossimo accordo UE-USA regga davanti alla Corte di Giustizia. È legittimo, ma è un modo molto laborioso di costruire un prodotto AI serio.

Per chi sta vivendo questa decisione, ho scritto la settimana scorsa un articolo che riassume le dieci ragioni per portare l’AI privata al tavolo del board, e dopo questo articolo ne pubblicherò altri sul tema (TCO, scelta del modello open-weight, AI Act ad agosto 2026). Per una conversazione diretta sul vostro caso specifico, c’è la pagina Advisory.

La domanda finale, quella che vale la pena tenere davanti quando si decide oggi su un progetto AI aziendale, è semplice. Volete che la vostra compliance GDPR dipenda da una sentenza che può arrivare fra tre anni, da un accordo UE-USA che può essere annullato fra cinque, da un fornitore americano che può cambiare le sue policy fra tre mesi? Oppure preferite costruire il vostro prodotto sopra un’infrastruttura che resta sotto il vostro controllo, dove la conformità è una proprietà strutturale invece di un esercizio documentale continuo?