L’intelligenza artificiale non vive soltanto nel cloud
Sempre più spesso algoritmi di AI entrano direttamente nei prodotti: sistemi embedded, macchine industriali, dispositivi medicali, robot, sistemi di controllo e apparati capaci di elaborare dati e prendere decisioni localmente.
Quando questo accade, una domanda diventa particolarmente interessante per chi si occupa di progettazione elettronica:
la conformità all’AI Act può influenzare anche il modo in cui progettiamo hardware e software embedded?
In determinati casi, sì.
Ed è uno dei motivi per cui conoscere almeno i principi del nuovo quadro normativo europeo sta diventando importante anche per progettisti, R&D manager e responsabili dello sviluppo prodotto.
AI Act: non tutti i sistemi di intelligenza artificiale sono “ad alto rischio”
Il Regolamento (UE) 2024/1689, conosciuto come AI Act, adotta un approccio basato sul rischio. Questo significa che utilizzare intelligenza artificiale all’interno di un prodotto non comporta automaticamente la classificazione del sistema come “high-risk”.
La classificazione dipende, tra le altre cose, dalla finalità prevista del sistema (intended purpose) e dal contesto nel quale viene utilizzato.
Per il mondo della progettazione elettronica è particolarmente interessante l’articolo 6.
Tra i sistemi che possono essere classificati ad alto rischio rientrano infatti quelli destinati a essere utilizzati come componenti di sicurezza di prodotti disciplinati dalla normativa europea di armonizzazione indicata nell’Allegato I dell’AI Act, oppure che costituiscono essi stessi tali prodotti, quando ricorrono anche le condizioni relative alla valutazione di conformità da parte di terzi previste dal Regolamento.
La Commissione europea cita, tra gli esempi possibili, sistemi AI utilizzati in robot, droni o dispositivi medici.
Quando l’AI incontra il mondo fisico
Per un progettista elettronico questo passaggio è particolarmente interessante.
Un algoritmo eseguito in un ambiente software può elaborare informazioni e produrre un risultato. Ma quando lo stesso principio entra all’interno di un sistema embedded che interagisce con sensori, attuatori, macchine o infrastrutture, le sue decisioni possono avere conseguenze nel mondo fisico.
A quel punto non basta più chiedersi:
“L’algoritmo funziona?”
Occorre chiedersi anche:
“Come si comporta l’intero sistema quando l’algoritmo sbaglia, riceve un dato anomalo o si trova in una condizione non prevista?”
Ed è qui che AI e ingegneria elettronica iniziano a incontrarsi davvero.
Dalla compliance al “compliance by design”
Per i sistemi AI classificati ad alto rischio, l’AI Act introduce requisiti che riguardano, tra gli altri aspetti, gestione del rischio, documentazione tecnica, registrazione degli eventi, supervisione umana, accuratezza, robustezza e cybersecurity.
Non sono quindi necessariamente questioni da affrontare soltanto quando il prodotto è terminato.
Alcune possono avere conseguenze sulle scelte effettuate molto prima.
Pensiamo, per esempio, alla capacità del sistema di registrare determinate informazioni, alla gestione delle condizioni anomale, alla disponibilità di dati diagnostici o alla possibilità di implementare meccanismi di supervisione.
In questi casi diventa utile ragionare in termini di compliance by design: considerare requisiti tecnici e normativi già durante la definizione dell’architettura.
Cosa cambia per chi progetta sistemi embedded?
Un sistema embedded che incorpora AI può richiedere di affrontare alcune domande fin dalle prime Design Review.
Cosa succede in caso di errore dell’algoritmo?
Il sistema deve poter entrare in una condizione sicura? È necessaria una strategia di fallback?
Quali informazioni dobbiamo registrare?
Se occorre ricostruire il comportamento del sistema, hardware e software devono essere in grado di rendere disponibili le informazioni necessarie.
Come validiamo il comportamento?
Non basta verificare che il dispositivo funzioni nelle condizioni nominali. Occorre definire scenari, condizioni limite e possibili failure mode.
Come proteggiamo il sistema?
Cybersecurity e robustezza non possono essere considerate elementi separati dall’architettura del prodotto.
Come documentiamo le decisioni progettuali?
Requisiti, architettura, test e risultati della validazione devono poter raccontare in modo coerente come il sistema è stato progettato e verificato.
Dal modello AI al prodotto industriale
C’è poi un altro aspetto che conosciamo bene nel mondo engineering.
Un algoritmo che funziona non è ancora un prodotto.
Tra un modello sperimentale e un sistema embedded industrializzato ci sono risorse computazionali, memoria, consumi, latenza, gestione termica, interfacce, cybersecurity, testabilità, affidabilità e ciclo di vita.
L’introduzione dell’AI aggiunge quindi un ulteriore livello alla progettazione, ma non elimina le regole fondamentali dell’ingegneria.
Al contrario, rende ancora più importante ragionare sul sistema nel suo complesso.
AI Act e progettazione elettronica: prepararsi prima di essere obbligati
Il quadro normativo è ancora in evoluzione sul piano applicativo. Nel 2026 la Commissione ha pubblicato un progetto di orientamenti specificamente dedicato alla classificazione dei sistemi AI ad alto rischio, con esempi pratici; al momento della verifica delle fonti, tali orientamenti risultano ancora presentati dalla Commissione come draft guidelines, quindi non vanno confusi con il testo vincolante del Regolamento.
Inoltre, a seguito dell’accordo politico sull’AI Omnibus, la Commissione indica attualmente il 2 agosto 2028 come data di applicazione delle regole high-risk per i sistemi AI integrati in prodotti quali robotica e macchinari industriali.
Per chi sviluppa prodotti con cicli di progettazione e industrializzazione lunghi, tuttavia, il tema non riguarda soltanto una scadenza normativa.
Un prodotto che arriverà sul mercato tra alcuni anni viene progettato oggi.
Ed è per questo che comprendere fin dalle prime fasi se e come l’AI Act possa interessare un nuovo progetto può diventare parte del lavoro di progettazione.
Perché quando l’intelligenza artificiale esce dal cloud ed entra nell’hardware, la compliance può diventare anche una questione di engineering.
