La maggior parte delle piattaforme AI rende l’AI Act un tuo problema.
L'EU AI Act non chiede se la tua AI sia brillante — chiede se sei in grado di dimostrare dove risiedono i dati, cosa ha fatto il sistema, chi lo ha supervisionato e quale modello ha prodotto la risposta. Con un servizio LLM in cloud pubblico, queste prove vivono sull'infrastruttura di qualcun altro. Con Emblema, sono un sottoprodotto dell'architettura.
Ogni obbligo qui sotto corrisponde a un articolo reale del Regolamento (UE) 2024/1689 e a una capacità Emblema reale e già disponibile — non una promessa di roadmap.
Il Regolamento si applica per fasi — e il grosso arriva presto.
A vincere il mercato regolamentato sono i team che si dotano dell’architettura giusta ora.
Pratiche vietate
Gli usi a rischio inaccettabile — social scoring, manipolazione, identificazione biometrica di massa — sono vietati.
Regole sui modelli GPAI
Si applicano gli obblighi per i fornitori di modelli di IA per finalità generali, incluse le soglie di rischio sistemico.
Obblighi alto rischio
Entra in vigore il grosso degli obblighi per i sistemi ad alto rischio — governance dei dati, logging, supervisione, documentazione.
Dove i concorrenti si fermano — e dove risponde l’architettura.
Ogni obbligo è un articolo reale del Regolamento. Ogni risposta è una capacità Emblema già disponibile, ordinata per quanto è decisiva per un acquirente regolamentato.
I tuoi dati non lasciano mai le tue mura — e puoi dimostrarlo
Sovranità e governance dei dati che controlli davvero.
L'AI Act si aspetta che tu governi i dati che la tua AI elabora. Non puoi governare dati che hai consegnato al cloud di terzi — e secondo il GDPR spesso non puoi nemmeno inviarli legalmente.
ChatGPT Enterprise / OpenAI API, Microsoft 365 Copilot / Azure OpenAI, Google Gemini / Vertex AI, Anthropic Claude API e AWS Bedrock sono tutti erogati come servizi cloud gestiti: i tuoi prompt, documenti ed embedding vengono elaborati sull'infrastruttura del fornitore. Anche i piani "enterprise" e "EU region" significano che affitti capacità — non possiedi il dato.
- Prompt e file caricati transitano e vengono elaborati sul cloud del fornitore — fuori dal tuo confine di controllo.
- Non puoi documentare pienamente le pratiche di governance, rappresentatività e qualità dei dati richieste dall’AI Act quando la pipeline di elaborazione non è la tua.
- L’elaborazione transfrontaliera riapre il rischio di trasferimento del Capo V del GDPR (post-Schrems II) per ogni record regolamentato.
- "Fidatevi, non addestriamo sui vostri dati" è una clausola contrattuale, non una garanzia architetturale.
Art. 10 — Dati e governance dei dati · rafforzato dall’Art. 26 — Obblighi dei deployer · e dal Capo V del GDPR (trasferimenti internazionali).
La soluzione EmblemaEmblema si installa interamente sulla tua infrastruttura. I dati risiedono fisicamente in store gestiti da te e l’inferenza gira sul tuo hardware per impostazione predefinita.
- Tutti i dati stanno nei tuoi container — PostgreSQL /
postgres-vector, Milvus (vettori), MinIO (oggetti), Redis, Neo4j — avviati dainstall.sh/docker-compose-data-source.yaml. - Gli embedding sono calcolati localmente (BGE-M3, 1024-d, via
vllm-bge-m3) e il reasoning gira su un LLM locale per default (es. Qwen via LiteLLM); le chiavi dei modelli cloud sono vuote se non scegli tu di attivarle. - Air-gap capable — deployment completo single-node o multi-node senza egress obbligatorio (
scripts/swarm/). I tuoi dati non lasciano mai la tua rete, nemmeno verso di noi. - La sincronizzazione Drive è solo-metadati — i file sorgente restano dove sono; nulla viene migrato o copiato fuori.
L’audit trail è integrato, non aggiunto dopo
Registrazioni a prova di manomissione, per tutta la vita del sistema.
L'AI ad alto rischio deve mantenere log automatici per tutto il suo ciclo di vita, e i deployer devono conservarli. Una dashboard SaaS non è una registrazione a prova di manomissione da consegnare a un auditor.
Con un servizio LLM ospitato, i log di cui hai bisogno vivono dal lato del fornitore: ottieni dashboard d'uso, non un registro eventi immutabile e permanente. La retention è decisa dal vendor, l'immutabilità non è garantita, e non puoi ricostruire su richiesta l'intera catena "chi ha chiesto cosa, quali dati sono stati recuperati, cosa è stato prodotto".
- I log degli eventi sono controllati e conservati dal fornitore — non puoi garantire che esistano quando ti servono.
- Nessuna garanzia di write-once / immutabilità: la registrazione non regge alla domanda "è stata alterata?".
- Ricostruire una catena decisionale completa attraverso un’API black-box è di fatto impossibile.
Art. 12 — Conservazione delle registrazioni · Art. 19 — Log generati automaticamente · Art. 26(6) — conservazione dei log da parte del deployer.
La soluzione EmblemaEmblema include un sottosistema di audit reale (apps/www-emblema/lib/audit/index.ts) con persistenza dual-sink e privacy-by-design.
- Ricercabile + immutabile: ogni evento è loggato in modo strutturato su Loki (retention predefinita 6 mesi) e scritto come oggetto JSON per-evento su MinIO — WORM-ready: configura il bucket con S3 Object Lock (modalità COMPLIANCE) e la registrazione diventa immutabile.
- Privacy-by-design: lo store immutabile conserva solo un hash con salt dell’ID utente e un IP troncato a /24 — gli identificatori grezzi restano nel log operativo entro la retention.
- Storia di esecuzione durevole: ogni run del Workspace è un workflow Temporal con storia interrogabile (
workspace-service/app/temporal/workflows.py); ogni nodo del grafo è ispezionabile e rieseguibile — la traccia è strutturale. - Emblema include un set di policy di compliance documentate (
docs/compliance/) invece di lasciare la governance come esercizio per l’acquirente.
Puoi documentare — e spiegare — un sistema che puoi davvero vedere
Documentazione tecnica e diritto alla spiegazione.
L'AI ad alto rischio richiede documentazione tecnica dettagliata e output interpretabili. Non puoi redigere né l'una né gli altri per un modello i cui interni sono segreto industriale e il cui comportamento cambia silenziosamente dietro un'API.
OpenAI, Anthropic e Google distribuiscono modelli di frontiera chiusi: architettura, dati di addestramento e metodologia di valutazione non sono divulgati, e il modello può essere aggiornato sotto i tuoi piedi senza preavviso né garanzie di versione. Dipendi dalla documentazione del fornitore — che potrebbe non soddisfare il tuo obbligo dell’Allegato IV — e raramente puoi risalire da un output alla sua fonte.
- Non puoi compilare la documentazione tecnica dell’Allegato IV per un sistema che non ti è consentito ispezionare.
- Gli aggiornamenti silenziosi del modello rompono riproducibilità e stabilità di versione.
- "Perché ha risposto così?" non ha risposta tracciabile quando recupero e generazione sono opachi.
Art. 11 + Allegato IV — Documentazione tecnica · Art. 13 — Trasparenza e fornitura di informazioni ai deployer.
La soluzione EmblemaEmblema esegue modelli open-weight scelti dall’operatore dentro un resource-graph ispezionabile — e ogni risposta fondata porta con sé le sue prove.
- Modelli aperti e documentabili (Qwen, BGE-M3,
gpt-oss) che selezioni e puoi descrivere — fissa una versione, documentala, mantienila stabile. - Citazioni su ogni risposta RAG: lo schema
dataSourcePart(schema/chat-stream.ts) allega documento sorgente, knowledge base, punteggio di similarità vettoriale e punteggio del reranker a ogni chunk citato, resi come riferimenti cliccabili (lib/remark-citations.ts) — un letterale diritto alla spiegazione tracciabile fino al testo esatto. - Provenienza del modello per messaggio:
llmIdregistra il modello esatto che ha prodotto ogni risposta — i nomi collidono, gli ID no. - Ogni nodo è deterministico e ispezionabile, così il comportamento del sistema è documentabile invece che emergente.
Una persona può fermarlo — su qualsiasi nodo, in corsa
Supervisione umana progettata dentro il grafo.
L'AI ad alto rischio deve essere effettivamente supervisionabile: una persona deve poter intervenire, correggere o fermarla. Gli agenti SaaS autonomi procedono in avanti soltanto, e "stop" significa chiudere la scheda.
I prodotti agentici dei grandi vendor eseguono una catena dall'inizio alla fine. Non puoi inserire un checkpoint umano obbligatorio dentro il loop del vendor, non puoi fermare un singolo passo senza uccidere l'intero run, e non c'è un punto di override pulito — esattamente ciò che l'Articolo 14 richiede.
- Nessun punto di intervento integrato dentro la catena autonoma di un vendor.
- "Stop" è tutto-o-niente; non puoi mettere in pausa o annullare un passo mentre gli altri continuano.
- Il bias di automazione è difficile da contrastare quando il processo è solo-in-avanti e opaco.
Art. 14 — Sorveglianza umana.
La soluzione EmblemaEmblema orchestra il lavoro come un grafo guidato da Temporal con vero controllo human-in-the-loop (workspace-service/app/temporal/workflows.py).
- Ispeziona il piano prima che parta — il piano di esecuzione (DAG) è generato e revisionabile prima di qualsiasi commit.
- Segnali di cancellazione per nodo — fermi un nodo mentre i fratelli continuano; i nodi a valle si annullano automaticamente.
- Macchina a stati esplicita — PENDING → RUNNING → COMPLETED / CANCELLED / FAILED, interrogabile in tempo reale.
- Nodi atomici deterministici che una persona può verificare e rieseguire in autonomia — la supervisione non è aggiunta dopo, è come funziona il grafo.
Il tuo perimetro di sicurezza è tuo
Accuratezza, robustezza e cibersicurezza dentro le tue mura.
L'AI ad alto rischio deve raggiungere un livello adeguato di robustezza e cibersicurezza e resistere alle manomissioni. Su cloud multi-tenant non puoi verificare la postura né garantire l'isolamento.
I servizi LLM ospitati sono multi-tenant, i tuoi dati sono in transito verso le region del fornitore, e non puoi verificare la postura di sicurezza del fornitore né garantire l'isolamento tra tenant. La superficie d'attacco ora include il vendor e il percorso di rete — nessuno dei due sotto il tuo controllo.
- Infrastruttura condivisa, multi-tenant, che non puoi ispezionare né irrobustire.
- I dati attraversano la rete verso region di terzi (spesso di Paesi terzi) nel normale funzionamento.
- Nessun modo di verificare in autonomia la resilienza contro data/model poisoning o input avversari dal lato del fornitore.
Art. 15 — Accuratezza, robustezza e cibersicurezza.
La soluzione EmblemaTutto gira dentro il tuo perimetro, dietro il tuo IAM, sulla tua rete.
- TLS 1.2+ con cifrari moderni e forward-secret al bordo (Traefik,
config/traefik/dynamic/tls.yml,sniStrict). - Keycloak IAM per gli utenti e autenticazione JWT service-to-service (
getAppToken,packages/data-core/lib/keycloak.ts). - Isolamento di rete — solo il reverse proxy espone la 443; i data store (Milvus, PostgreSQL, Redis) non hanno porte esterne per default (reti
emblema/emblema-cluster). - Single-tenant e air-gappable — il tuo SOC possiede la postura end-to-end.
Scegli tu il modello — e puoi dimostrare quale ha risposto
Controllo, provenienza e nessun lock-in sui modelli GPAI.
Costruisci sul modello generale di qualcun altro ed erediti obblighi che non puoi soddisfare — perché non vedi la provenienza del modello, e sei legato alla roadmap di un solo fornitore.
Quando costruisci su un modello di IA per finalità generali chiuso, dipendi dalla compliance del fornitore per provenienza dei dati di addestramento, policy sul copyright e documentazione — nulla di cui tu possa fare verifica. Inoltre non puoi sapere se il modello supera la soglia di calcolo del rischio sistemico che attiva gli obblighi più pesanti, e sei vincolato a prezzi e cadenza di rilascio di un solo vendor.
- Erediti gli obblighi GPAI a valle pur avendo visibilità zero su provenienza o gestione del copyright.
- Nessun controllo sul fatto di poggiare o meno su un modello di classe a rischio sistemico.
- Lock-in del vendor: una sola roadmap, un solo prezzo.
Art. 53 — Obblighi per i fornitori di modelli di IA per finalità generali · Art. 55 — Modelli GPAI con rischio sistemico.
La soluzione EmblemaI modelli sono configurabili dall’operatore tramite un registro dichiarativo (config/litellm/config.yaml) — nessun lock-in, piena provenienza.
- Default open-weight locali (Qwen, BGE-M3,
gpt-oss) che puoi documentare e governare; i modelli cloud sono opzionali, protetti da chiavi API esplicite. - Cambi qualsiasi modello in una riga — LiteLLM fa da front-end a oltre 100 provider, così non sei mai sposato con un solo vendor.
- Dimensiona con criterio — scegli modelli che ti tengono sotto le soglie di rischio sistemico quando è la postura più sicura.
- La provenienza per messaggio via
llmIdregistra esattamente quale modello ha prodotto ogni output.
Puoi davvero superare un audit da deployer
Responsabilità del deployer e valutazioni d’impatto reali.
Come deployer sei responsabile a prescindere dal vendor — ma puoi valutare e monitorare solo ciò che vedi. Una valutazione sui diritti fondamentali o sulla protezione dati su una black box è teatro.
L'AI Act mette obblighi sul deployer: usare il sistema secondo le istruzioni, garantire la supervisione, monitorarne il funzionamento, conservare i log e informare le persone interessate. Con un servizio ospitato non hai leve per farlo in modo significativo, e una Valutazione d'Impatto sui Diritti Fondamentali su elaborazione opaca e offshore è in gran parte performativa.
- Nessuna leva operativa per monitorare, loggare o vincolare un servizio di terzi.
- Una FRIA / DPIA su una black box non può produrre una base di evidenze credibile.
- "Chi ha fatto cosa su quale record" è senza risposta quando il controllo accessi vive nel prodotto del vendor.
Art. 26 — Obblighi dei deployer · Art. 27 — Valutazione d’impatto sui diritti fondamentali.
La soluzione EmblemaMonitoraggio, logging, supervisione e localizzazione del dato sono tutti nelle mani dell’operatore — e l’accesso è governato e registrato.
- Permessi granulari a livello di Entità e Record per Utenti, Service Account e Gruppi (
packages/data-core/types/permissions.ts). - Imposti e registrati: il middleware
withApiOperation(utils/api-middleware.ts) valida la catena delle entità e scrive il risultato — chi, quale azione, quale risorsa, consentito/negato, durata — nell’audit trail. - Una base di evidenze reale per una FRIA / DPIA: posizione dei dati, logica di elaborazione, controlli di supervisione e registrazioni di accesso sono tutti ispezionabili nel tuo estate.
- Responsabilità dimostrabile verso un’autorità di vigilanza, perché l’intero sistema è tuo da mostrare.
Disclosure e marcatura dei contenuti come policy imposta, non come ripensamento
Trasparenza per interazione AI e contenuti sintetici.
L'AI Act richiede che le persone sappiano quando hanno a che fare con un'AI, e che i contenuti sintetici siano marcati. Spargi la tua AI su una dozzina di strumenti SaaS e l'enforcement coerente diventa impossibile.
L'Articolo 50 richiede di rivelare l'interazione con l'AI (es. chatbot) e la marcatura leggibile dalla macchina di audio, immagini, video e testo sintetici, oltre all'etichettatura dei deep fake. Quando le funzioni AI sono sparse su molti prodotti SaaS disconnessi, applicare un'unica policy di disclosure e marcatura in modo uniforme e verificabile è un ripensamento manuale e soggetto a errori.
- Nessun punto di controllo centrale per applicare disclosure e marcatura dei contenuti in modo coerente.
- Ogni strumento gestisce (o ignora) la marcatura dei contenuti sintetici a modo suo.
- L’etichettatura di deep-fake / media sintetici diventa una checklist per-strumento invece di una garanzia.
Art. 50 — Obblighi di trasparenza per fornitori e deployer di determinati sistemi di IA.
La soluzione EmblemaPoiché tutto passa attraverso un solo livello di orchestrazione, disclosure e marcatura dei contenuti possono essere espresse come un nodo imposto nel grafo deterministico — applicato in modo uniforme agli artefatti generati invece che lasciato a ogni strumento.
- Un unico punto di policy dove disclosure dell’interazione AI e marcatura dei contenuti sintetici sono applicate su tutti gli output.
- Policy-as-node: la regola gira come parte del grafo, quindi è coerente e ispezionabile.
- Nota onesta sullo scope: questa è policy-enablement che l’architettura rende semplice — un luogo centrale dove imporre l’etichettatura — più che un prodotto di watermarking chiavi-in-mano oggi. È in ultima posizione esattamente per questo.
Una causa radice. Una risposta architetturale.
Il problema dei concorrenti è architetturale: un modello ospitato e chiuso significa che dati, log, interni del modello e punti di controllo vivono tutti in un posto che non puoi raggiungere. La risposta di Emblema è anch'essa architetturale: un resource graph self-hosted, deterministico e ispezionabile emette residenza del dato, audit trail, citazioni, provenienza del modello e i punti di supervisione che i regolatori chiedono — come sottoprodotto del suo utilizzo.
Ecco perché i numeri di benchmark contano oltre il costo: un grafo deterministico al ±3% (contro il ±13% di un agente a ruota libera) è un grafo che puoi riprodurre, ispezionare e difendere. La riproducibilità è auditabilità.
La conformità è un output del grafo deterministico — non lavoro extra aggiunto dopo.
Perché questo ordine
- 1Art. 10Sovranità del dato — La decisione di sbarramento per ogni acquirente regolamentato; se il dato lascia le mura, nient’altro conta.
- 2Art. 12/19/26Conservazione registrazioni — Il differenziatore più concreto e supportato da codice: un vero sottosistema di audit WORM-ready.
- 3Art. 11/13Trasparenza e documentazione — Modelli aperti + citazioni trasformano la "spiegabilità" da aspirazione a funzionalità.
- 4Art. 14Supervisione umana — La cancellazione per nodo è una capacità che ai concorrenti manca strutturalmente.
- 5Art. 15Cibersicurezza — Il controllo del perimetro è la conseguenza naturale del self-hosting.
- 6Art. 53/55Controllo GPAI — Scelta e provenienza del modello; forte, ma un livello sopra la residenza grezza del dato.
- 7Art. 26/27Responsabilità del deployer — Sintetizza sovranità + logging + permessi in "superare l’audit".
- 8Art. 50Trasparenza contenuti sintetici — Obbligo reale, ma policy-enablement più che funzionalità rilasciata — da qui l’ultima posizione.
Indice degli articoli
Regolamento (UE) 2024/1689| # | Tema | Articolo/i |
|---|---|---|
| 1 | Sovranità e governance dei dati | Art. 10 (+ Art. 26; GDPR Capo V) |
| 2 | Registrazioni, logging e tracciabilità | Art. 12, Art. 19, Art. 26(6) |
| 3 | Trasparenza e documentazione tecnica | Art. 11 + Allegato IV, Art. 13 |
| 4 | Sorveglianza umana | Art. 14 |
| 5 | Accuratezza, robustezza e cibersicurezza | Art. 15 |
| 6 | Controllo e provenienza dei modelli GPAI | Art. 53, Art. 55 |
| 7 | Responsabilità del deployer e valutazioni d’impatto | Art. 26, Art. 27 |
| 8 | Trasparenza su contenuti sintetici e interazione | Art. 50 |
Questo contenuto è informativo e riflette come l'architettura di Emblema supporta gli obblighi dell'EU AI Act e del GDPR; non è consulenza legale. La classificazione regolatoria (es. se un dato uso sia "ad alto rischio") dipende dal deployment, e gli obblighi vanno confermati con consulenti qualificati. Le note sulle capacità fanno riferimento al codice Emblema alla data di questa bozza; le funzioni "opzionali" (es. backend di modelli cloud, configurazione MinIO Object Lock) richiedono configurazione da parte dell'operatore.