Parto da una premessa onesta, perché è il modo in cui mi piace scrivere e perché il pubblico di one or zero merita più cautela che marketing: su questo tema ho ancora poca esperienza diretta. Non ho ancora una libreria di casi chiusi da sbandierare come “best practice”. Ma proprio questa posizione — quella di chi sta mappando il terreno mentre lo attraversa — mi ha insegnato la cosa più importante che voglio condividere: prima di parlare di AI Act nel datacenter bisogna capire davvero gli use case, non inseguire la moda.
Il primo errore: trattare “AI” come una categoria unica
Quando un carico “AI” atterra nella tua infrastruttura, la prima tentazione è etichettarlo genericamente e applicare un checklist di compliance uguale per tutti. È l’errore da evitare. L’AI Act ragiona per rischio, non per hype. Un tool di anomaly detection sul monitoring, un LLM interno usato per la documentazione e il modello di un cliente che gira sui tuoi nodi non sono la stessa cosa e non hanno lo stesso profilo di obblighi.
Nella pratica, i carichi che vedo passare si collocano quasi tutti in zone a rischio limitato o minimo:
- Anomaly detection sul monitoring: strumento operativo interno, tipicamente rischio minimo. Qui il tema vero non è l’AI Act, è la qualità dei dati e i falsi positivi.
- LLM interno: rischio limitato, ma attenzione agli obblighi di trasparenza se genera output verso persone.
- Modello di un cliente ospitato sui tuoi nodi: qui inizia la zona grigia interessante, quella dove la linea tra provider e deployer si sfuma.
Provider o deployer? La domanda che chi gestisce solo l’infra si pone tardi
Se ospiti l’infrastruttura ma non sviluppi né metti in servizio il modello, la posizione naturale è quella di fornitore di infrastruttura, non di provider né di deployer ai sensi dell’AI Act. In teoria. In pratica la linea diventa ambigua nel momento in cui inizi a fare più del “tenere accese le VM”:
- fornisci il layer di orchestrazione (Kubernetes gestito, pipeline di serving);
- gestisci tu logging, retention e osservabilità del modello;
- offri componenti di pre-processing o guardrail come servizio.
Più risali lo stack, più rischi di essere trascinato dentro obblighi che pensavi non ti riguardassero. La mia regola, oggi: definire esplicitamente dove finisce la mia responsabilità e dove inizia quella di chi porta il modello, prima che il carico entri in produzione. Non dopo l’incidente.
I requisiti tecnici che toccano l’architettura
Anche restando “solo infra”, ci sono requisiti che finiscono per impattare architettura e processi già in produzione. Quelli che considero non negoziabili e su cui conviene lavorare da subito:
- Logging e retention degli eventi: tracciare chi ha fatto girare cosa, quando, su quali dati. È il requisito più trasversale e quello che, per esperienza, genera più attrito operativo — perché retention lunghe significano costi di storage e disciplina nei cicli di rotazione dei log.
- Tracciabilità dei dati di training/inferenza: spesso non è nemmeno un problema tuo, ma diventa tuo se il cliente non sa rispondere alla domanda “questi dati da dove arrivano?”.
- Isolamento dei workload: multi-tenancy pulita, segmentazione di rete, separazione dei namespace. Qui chi già lavora bene su Kubernetes parte avvantaggiato.
- Data residency EU: il punto dove il tema AI Act si salda con la sovranità del dato. Per una testata come questa è il cuore: sapere dove risiedono dati e inferenze non è un vezzo, è una precondizione contrattuale.
Il costo più alto, nella mia esperienza embrionale ma già concreta, non è tecnico: è l’attrito di dover retrofittare logging e tracciabilità su architetture nate senza pensarci. Costruire pulito da zero costa poco; rimettere mano a qualcosa in produzione costa molto di più, in ore e in rischio.
“Siamo a posto con l’AI Act?” — cosa rispondo davvero
Quando un cliente me lo chiede, la risposta onesta è: “dipende da chi fa cosa, e questo va scritto”. L’AI Act non è un bollino che si stampa; è una ripartizione di obblighi. Le cose che ho imparato a chiarire subito, prima di firmare:
- Nel DPA: chi è titolare e chi responsabile del trattamento, e come questo si intreccia con i ruoli AI Act.
- Negli SLA: cosa garantisco su logging, disponibilità dei dati di audit e conservazione, senza promettere responsabilità sul comportamento del modello che non è mio.
- La zona grigia da chiudere subito: chi risponde se il modello produce output problematici. Se ospito soltanto, deve essere nero su bianco che la responsabilità sul modello resta a chi lo sviluppa e lo mette in servizio.
La clausola che non lascio mai vaga è quella sulla ripartizione degli obblighi: senza di essa, in caso di contestazione, chi ha l’infrastruttura in mano è il primo a essere chiamato in causa.
Il verdetto: muoversi (1)
Il mio verdetto è 1: conviene muoversi ora. Non per rincorrere la scadenza normativa, ma perché i requisiti veri dell’AI Act — logging, tracciabilità, isolamento, data residency — sono igiene infrastrutturale che dovresti avere comunque. Muoversi non significa comprare l’ennesima piattaforma “AI-ready”: significa capire i tuoi use case reali, classificarli per rischio e scrivere chiaro chi risponde di cosa. Chi aspetta si troverà a retrofittare sotto pressione, che è il modo più costoso e più rischioso di essere conformi. Muoviti adesso, ma con la testa: prima gli use case, poi la compliance. Mai il contrario.