UX, Design e AI Act: la guida per chi disegna interfacce, non leggi

Il problema, prima della norma

Un designer non ha bisogno di conoscere il Regolamento (UE) 2024/1689 articolo per articolo. Ha bisogno di sapere tre cose molto più semplici:

• Quando devo far capire all'utente che sta parlando con una macchina?

• Come spiego una decisione che l'AI ha preso al posto suo?

• Dove metto il pulsante che gli permette di fermarla o correggerla?

L'AI Act, per chi progetta interfacce, si riduce quasi interamente a queste tre domande. Il resto — provider, deployer, allegati, articoli — è il linguaggio con cui i legali parlano tra loro. Questa guida parte dal problema di design e usa la norma solo come vincolo, non come punto di partenza.

Il quadro normativo in 90 secondi

Tre cose da sapere, in ordine di urgenza:

1. La trasparenza (Art. 50) è confermata al 2 agosto 2026. Badge, disclosure, marcatura dei contenuti sintetici: non è rinviata da nessun pacchetto di semplificazione. È la parte che tocca più da vicino il lavoro di interfaccia, ed è quella su cui c'è meno margine di attesa.

2. L'alto rischio ha preso tempo, non l'ha perso. Il Digital Omnibus, approvato dal Parlamento europeo il 16 giugno 2026, sposta gli obblighi per i sistemi ad alto rischio (selezione personale, credito, sanità, istruzione, giustizia) al 2 dicembre 2027 per l'Allegato III e al 2 agosto 2028 per l'Allegato I. Manca l'ultimo passaggio formale del Consiglio UE, ma la direzione è ormai stabile.

3. Le sanzioni non sono un numero solo. Chi cita "35 milioni o 7% del fatturato" come cifra unica sta semplificando male: quella soglia vale solo per le pratiche vietate (Art. 5). Sui sistemi ad alto rischio si scende a 15 milioni / 3%; sulle informazioni fuorvianti alle autorità a 7,5 milioni / 1%.

ScadenzaCosa scattaGià attivoDivieti pratiche vietate, obblighi GPAI2 agosto 2026Trasparenza e disclosure AI (Art. 50)2 dicembre 2026Watermarking machine-readable sui contenuti sintetici2 dicembre 2027Alto rischio, Allegato III2 agosto 2028Alto rischio, Allegato I

Un framework per calibrare lo sforzo di design

Non tutti i prodotti AI richiedono lo stesso livello di intervento. Prima di aprire Figma, vale la pena classificare dove si colloca il progetto — è la domanda che eviterebbe metà degli errori di over-engineering o under-compliance che si vedono in giro.

LivelloEsempio di prodottoCosa richiede il designMinimoFiltro antispam, autocomplete, correttore di bozzeNessun obbligo specifico. Buon senso UX.TrasparenzaChatbot, generatore di immagini/testo, raccomandazioni editorialiBadge visibile, disclosure pre-interazione, marcatura contenuti sinteticiTrasparenza + spiegabilità leggeraSuggerimento prodotto, personalizzazione feed, raccomandazione non vincolanteBadge + tooltip contestuale con motivazione sinteticaAlto rischioCredit scoring, selezione candidati, diagnosi di supporto, valutazione scolasticaBadge + pannello di spiegazione dedicato + validazione umana obbligatoria + percorso di contestazione

Questo framework non sostituisce la classificazione legale formale (che resta compito di un legale o di uno strumento come una valutazione d'impatto), ma è sufficiente per orientare le prime decisioni di design senza aspettare il parere legale su ogni singola schermata.

Le tre domande, con esempi reali

1. L'utente sa che sta parlando con un'AI?

Non basta metterlo scritto da qualche parte nei termini di servizio. Il marcatore deve essere visibile prima che l'interazione inizi e deve restare presente durante il flusso — non solo comparire come disclaimer finale.

Errore tipico: un badge "Generato con AI" che appare solo dopo che l'utente ha già letto il contenuto, o un'icona così piccola da confondersi con altri elementi dell'interfaccia.

Pattern che funziona: badge persistente con contrasto visivo dedicato (colore o forma diversi dal resto della UI), posizionato all'ingresso del flusso, non alla fine.

2. L'utente capisce perché l'AI ha deciso così?

Qui il livello di dettaglio deve essere proporzionale al peso della decisione. Un consiglio di lettura sbagliato è fastidioso; un rifiuto di credito senza spiegazione è un problema — anche legale, non solo di UX.

Errore tipico: uno score numerico ("72/100") senza alcun contesto su cosa lo abbia determinato.

Pattern che funziona: per le decisioni a basso impatto, un tooltip contestuale basta. Per quelle ad alto impatto, serve un'area dedicata — pannello espandibile o sezione "Dettaglio della valutazione" — consultabile anche dopo, non solo nel momento in cui la decisione viene mostrata.

3. L'utente può correggere o fermare l'AI?

La supervisione umana non deve trasformarsi in un ostacolo che rende inutile l'automazione, ma nei processi critici la conferma umana prima della decisione finale non è negoziabile.

Errore tipico: un flusso "a singolo clic" dove l'AI decide e l'utente scopre il risultato solo a cose fatte.

Pattern che funziona: uno stato intermedio di validazione — "rivedi prima di confermare" — con la possibilità di modificare, annullare o richiedere una revisione umana. Attenzione particolare quando chi usa lo strumento e chi ne subisce l'effetto sono persone diverse (un recruiter che usa un tool di selezione, il candidato che viene valutato): in questi casi il percorso di contestazione va progettato per chi subisce, non solo per chi opera.

Checklist per fase di progetto

A differenza delle checklist organizzate per articolo di legge, questa segue il flusso di lavoro reale di un team di design — così si integra nei rituali che già esistono (discovery, wireframe, UI review, QA) invece di aggiungerne uno nuovo.

In discovery

• Il progetto è stato classificato per livello di rischio (vedi framework sopra)?

• È chiaro chi è provider e chi è deployer del sistema AI coinvolto?

• Sono stati identificati tutti i soggetti impattati dalla decisione, non solo chi usa il tool?

In wireframe

• Il badge di disclosure AI è posizionato prima dell'interazione, non dopo?

• Esiste uno spazio dedicato per la spiegazione, proporzionato al livello di rischio?

• È previsto uno stato di validazione umana prima delle decisioni critiche?

In UI review

• Il badge resta visibile durante tutto il flusso, non solo all'ingresso?

• Il linguaggio delle spiegazioni è comprensibile a un non tecnico?

• Le opzioni suggerite dall'AI non sono presentate come l'unica scelta possibile?

• Rifiutare la personalizzazione algoritmica è facile quanto accettarla?

In QA / collaudo

• Gli stati di errore del sistema sono distinguibili dalle decisioni dell'AI?

• È possibile segnalare un errore o dare feedback su un output?

• Per gli output ad alto impatto è comunicato un livello di affidabilità?

• Il percorso di contestazione/revisione è testato end-to-end, non solo disegnato?

Tre errori che si vedono spesso (e non c'è bisogno di farli)

1. Trattare la compliance come uno strato finale. Aggiungere badge e disclaimer a un prodotto già disegnato costa più tempo e produce risultati peggiori che integrarli fin dal wireframe. Il retrofit su un sistema ad alto rischio, in particolare, è un debito tecnico che si paga con gli interessi.

2. Confondere "rinviato" con "non richiesto". Il rinvio del Digital Omnibus riguarda solo l'alto rischio, e riguarda le scadenze — non elimina la convenienza di progettare bene fin da subito. Chi aspetta il 2027 per iniziare a pensarci parte con un ritardo che il rinvio non recupera.

3. Usare la spiegabilità come alibi per la genericità. Una spiegazione tecnicamente presente ma incomprensibile ("il modello ha assegnato un punteggio basato su 47 feature") non soddisfa né lo spirito della norma né l'utente. Va tradotta in linguaggio naturale, sempre.

In sintesi

• Trasparenza confermata ad agosto 2026; alto rischio spostato al 2027-2028, non eliminato.

• Le sanzioni sono graduate: non un numero unico, ma tre soglie diverse a seconda della violazione.

• Il framework a livelli aiuta a calibrare lo sforzo di design senza aspettare ogni volta il parere legale.

• Le tre domande — visibilità, spiegabilità, controllo — restano il modo più rapido per verificare se una schermata è a rischio compliance, indipendentemente da come evolve il calendario normativo.

Fonti: Regolamento (UE) 2024/1689; accordo provvisorio Parlamento-Consiglio UE sul Digital Omnibus (7 maggio 2026); voto del Parlamento europeo (16 giugno 2026). Quadro aggiornato a fine giugno 2026, soggetto ad adozione formale del Consiglio UE.