AI Act e robotica industriale: obblighi e compliance

Quando un robot con intelligenza artificiale è soggetto sia all’AI Act sia al Regolamento Macchine? La risposta dipende soprattutto da tre condizioni:

• la funzione AI svolge un ruolo di sicurezza,
• il sistema è classificato come ad alto rischio
• chi lo utilizza o lo modifica resta deployer oppure diventa fornitore

Per produttori, fabbriche e team legali, la robotica industriale con AI richiede oggi una lettura coordinata di due regimi normativi europei. L’AI Act disciplina i sistemi di AI ad alto rischio; mentre il Regolamento Macchine disciplina i requisiti di sicurezza dei macchinari. Nella pratica, i due quadri si incontrano quando l’intelligenza artificiale incide sulla sicurezza del robot o del contesto produttivo.

Si tratta di chiarire i punti essenziali per orientarsi: quando un sistema di AI nella robotica industriale è ad alto rischio, quando una funzione AI è un componente di sicurezza, quali obblighi ricadono su fornitore e deployer, e quando una modifica sostanziale può far nascere nuovi obblighi di compliance. L’obiettivo è capire come ridurre incertezza normativa e rischio operativo.

Perché AI Act e Regolamento Macchine si applicano insieme alla robotica industriale

In alcuni casi, AI Act e Regolamento Macchine si applicano insieme alla robotica industriale. Ciò accade soprattutto quando la funzione AI è collegata alla sicurezza del macchinario e richiede una valutazione della compliance anche ai sensi della normativa sui macchinari. Per i produttori, questo significa gestire una doppia compliance che non può essere affrontata separatamente ed è destinata a diventare una realtà stabile per chi sviluppa o utilizza robot intelligenti in ambito industriale. Inoltre, anche se il quadro potrà evolvere con futuri interventi europei, l’approccio più prudente è valutare da subito i requisiti dei due regimi in parallelo, invece di presumere che la compliance in uno escluda obblighi nell’altro.

Perché è importante essere compliant

Essere compliant non è solo un obbligo normativo: è una condizione per adottare la robotica AI in modo sicuro, scalabile e sostenibile. In Europa, la competitività manifatturiera dipende sempre più dalla capacità di automatizzare processi complessi, senza aumentare il rischio regolatorio.

Ne consegue che produttori e deployer devono capire con precisione quando un robot con AI è classificato ad alto rischio, come si distingue il ruolo di fornitore da quello di deployer e in quali casi una modifica del sistema può far scattare nuovi obblighi di compliance. Ignorare questi passaggi può rallentare l’adozione, aumentare i costi e generare esposizione normativa.

Ma vediamo di seguito di fare maggiormente chiarezza.

Classificazione ad alto rischio per la robotica industriale

Il test di classificazione

Ai sensi dell’articolo 6(1) dell’AI Act, un sistema di AI è ad alto rischio quando ricorrono due condizioni cumulative:

1. il sistema di AI è destinato a essere utilizzato come componente di sicurezza di un prodotto, oppure il sistema di AI è esso stesso un prodotto, coperto dalla legislazione di armonizzazione dell’Unione Europea elencata nell’Allegato I;
2. il prodotto la cui componente di sicurezza è il sistema di AI, o il sistema AI stesso come prodotto, è tenuto a sottoporsi a una valutazione della compliance da parte di terzi ai sensi della legislazione di armonizzazione dell’Unione Europea elencata nell’Allegato I.

In pratica, nella robotica industriale, la classificazione ad alto rischio dipende spesso dal fatto che la funzione AI svolga un ruolo di sicurezza e che il prodotto rientri in una procedura di valutazione della compliance da parte di terzi. Anche quando queste condizioni non ricorrono, il sistema può comunque essere ad alto rischio, se rientra nei casi previsti dall’Allegato III dell’AI Act.

Cosa costituisce una “componente di sicurezza”?

Nella maggior parte dei casi, nella robotica industriale il sistema di AI non coincide con l’intero robot, ma con una sua funzione specifica. La domanda decisiva è quindi questa: quella funzione AI è un componente di sicurezza?

L’AI Act definisce “componente di sicurezza” un elemento che svolge una funzione di sicurezza oppure il cui guasto o malfunzionamento può mettere in pericolo la salute e la sicurezza di persone o beni. In termini pratici, se un errore della funzione AI può causare collisioni, danni fisici o altri rischi rilevanti, la classificazione come “componente di sicurezza” diventa molto probabile.

Di seguito una tabella che illustra quando le funzioni IA possono qualificarsi come componenti di sicurezza e, precisamente:

Cosa fare per classificare correttamente un sistema AI come componente di sicurezza: approccio pragmatico

• Documentare in modo chiaro l’analisi svolta per stabilire se la funzione AI rientra o meno tra le componenti di sicurezza.
• Nei casi di classificazione borderline, valutare gli effetti di un possibile errore in entrambe le direzioni: una sovra-classificazione può generare obblighi di compliance non necessari, mentre una sotto-classificazione può esporre l’azienda a rischi normativi, sanzionatori e di responsabilità.
• Registrare e motivare il ragionamento adottato, così da poter dimostrare in modo coerente il percorso decisionale seguito.
• Quando la qualificazione resta incerta, considerare fin dalle prime fasi il coinvolgimento di un ente di certificazione autorizzato, affinché il percorso di valutazione di compliance possa guidare l’architettura tecnica del sistema, invece di dover essere adattato successivamente.

Valutazione della compliance da parte di terzi

La valutazione della compliance da parte di terzi diventa centrale quando il sistema AI rientra nella disciplina dei prodotti soggetti a controlli esterni secondo la normativa europea di armonizzazione, in particolare il Regolamento Macchine.

Il Regolamento Macchine è il riferimento principale per la sicurezza dei prodotti nella robotica industriale e la “funzione di sicurezza” è intesa come una misura che serve a eliminare o ridurre un rischio e che, se fallisce, può aumentare quel rischio. Per questo motivo, quando una funzione AI svolge un ruolo di sicurezza, i due regimi normativi tendono a sovrapporsi.

Per i macchinari inclusi nell’Allegato I, Parte A del Regolamento Macchine, la valutazione da parte di un ente di certificazione autorizzato è richiesta proprio perché il livello di rischio è considerato troppo elevato per il solo controllo interno. SI tratta di un passaggio è decisivo anche per capire quando un sistema AI può essere trattato come ad alto rischio ai sensi dell’AI Act.

Di fatto, l’Allegato I affronta specificamente le macchine basate sull’IA (descritte come l’uso di approcci di apprendimento automatico per comportamenti auto-evolutivi) in due aspetti che richiedono una valutazione da parte di enti di certificazione autorizzati (Allegato I, Parte A, nº 5 e 6), ovvero:

• come componenti di sicurezza autonomi basati sull’AI;
• come macchinari che incorporano tali sistemi basati sull’AI – a meno che in questo caso, la componente di sicurezza basata sull’AI del macchinario non sia già stata sottoposta a una valutazione della compliance da parte di terzi quando inserita indipendentemente nel mercato.

La Commissione Europea ha ritenuto necessaria l’inclusione esplicita di macchinari basati su AI alla luce del profilo di rischio distintivo di tali sistemi: la loro dipendenza dai dati, l’opacità intrinseca, l’autonomia e la connettività contribuiscono ciascuna a un potenziale di danno sostanzialmente aumentato, sia in termini di probabilità sia di gravità; inoltre, tali preoccupazioni sono notevolmente accentuate quando il sistema in questione è destinato a svolgere una funzione di sicurezza.

Di conseguenza, numerose funzioni presenti nei robot industriali avanzati – che incorporano il machine learning per compiti come la collaborazione uomo-robot, il riconoscimento di oggetti o il controllo adattivo – possono essere classificate come ad alto rischio.

Ad esempio, i robot industriali dotati di algoritmi di machine learning per compiti di riconoscimento e presa di oggetti – incluse funzioni come rilevare ed evitare la presenza umana durante l’operatività – sono considerati caratteristiche ad alto rischio, poiché incorporano funzionalità di sicurezza abilitate dall’AI e devono sottoporsi a una valutazione della compliance di terze parti ai sensi del Regolamento Macchine.

Allo stesso modo, i sistemi di controllo adattivi che utilizzano il machine learning per regolare i parametri di controllo in base alle condizioni ambientali – inclusa la regolazione della velocità o l’evitamento delle collisioni – sarebbero anch’essi considerati ad alto rischio.

Vale la pena notare un possibile disallineamento tra i due quadri normativi. L’Allegato I al Regolamento sulle Macchine definisce la “macchina basata sull’AI” facendo riferimento all'”uso di approcci di apprendimento automatico per un comportamento auto-evolutivo”, trattando la capacità auto-evolutiva come una caratteristica definitoria—e quindi essenziale. Al contrario, l’Articolo 3(1) della Legge sull’AI definisce “sistema AI” in termini che trattano l’adattività dopo il dispiegamento come una semplice caratteristica opzionale: il sistema “può mostrare adattività dopo il deployment”, come confermato dalle Linee Guida della Commissione sulla definizione di sistema di intelligenza artificiale.

Tale divergenza significa che un sistema può qualificarsi come sistema IA ai sensi dell’AI Act senza mostrare comportamenti auto-evolutivi; tuttavia, la classificazione dell’Allegato I del Regolamento Macchine presuppone proprio questa caratteristica. Ne consegue che il divario definitorio risultante rischia di generare incongruenze nell’applicazione combinata di entrambi i Regolamenti, in particolare quando si determina se un dato Sistema AI ai sensi dell’AI Act rientri nell’ambito delle disposizioni del Regolamento Macchine.

Di fatto, tale lacuna crea una reale incertezza per i produttori che cercano di determinare quale regime (o combinazione di regimi) si applichi al loro prodotto nella fase di classificazione. A tal proposito la Commissione Europea ha pubblicato di recente una bozza delle “Guidelines-Classification high risk AI-systems” che mirano a supportare i fornitori e i deployer di sistemi di intelligenza artificiale, nonché le autorità competenti di vigilanza del mercato, nella valutazione dell’opportunità di classificare un sistema di intelligenza artificiale come ad alto rischio, facilitando così l’applicazione uniforme e l’efficace attuazione dell’articolo 6 dell’AI Act.

Quando la robotica industriale con AI è considerata ad alto rischio

Le funzioni di sicurezza basate sull’IA nella robotica industriale – inclusi l’evitamento delle collisioni, il rilevamento umano e il controllo adattivo – sono tipicamente considerate sistemi AI ad alto rischio ai sensi dell’AI Act e, contemporaneamente, attivano obblighi di funzione/componenti di sicurezza ai sensi del Regolamento Macchine. Pertanto, i produttori dovrebbero presumere una classificazione ad alto rischio e pianificare, di conseguenza, la doppia compliance.

Fornitore vs. Deployer nell’AI Act: differenze di ruolo e obblighi di compliance

La distinzione tra fornitore e deployer è centrale per capire chi ha gli obblighi principali di compliance nell’AI Act. Il fornitore sviluppa il sistema di AI e lo immette sul mercato o lo mette in servizio a proprio nome; il deployer, invece, utilizza il sistema sotto la propria autorità.

La differenza pratica è molto ampia. Se il robot con AI è ad alto rischio, il fornitore deve rispettare gli obblighi previsti dagli articoli 8–15 dell’AI Act e coordinarli con la valutazione di compliance richiesta dal Regolamento Macchine. Ciò significa gestire una doppia compliance, colmare eventuali lacune tra i due regimi e prepararsi, ove necessario, a una valutazione da parte di terzi.

In altre parole, per i produttori di robotica AI ad alto rischio non basta rispettare una sola normativa, bensì occorre applicare insieme AI Act e Regolamento Macchine, pianificando sin dall’inizio la compliance tecnica, documentale e organizzativa.

Di seguito una tabella che elenca alcuni requisiti paralleli:

Obblighi del fornitore

Gli obblighi del fornitore di un sistema di AI ad alto rischio includono, in particolare:

• sistema di gestione del rischio;
• governance dei dati;
• documentazione tecnica;
• registrazione degli eventi e tenuta dei log;
• trasparenza e istruzioni d’uso;
• supervisione umana, accuratezza, robustezza e cybersecurity.

Obblighi del deployer nell’AI Act: cosa deve fare concretamente la fabbrica

Nel quadro tradizionale del Regolamento Macchine, la fabbrica che utilizza il macchinario non assume, di regola, obblighi specifici in quanto utente. L’AI Act, invece, introduce obblighi diretti anche per il deployer, cioè per il soggetto che utilizza il sistema di AI sotto la propria autorità. In pratica, questo significa che l’impresa che impiega robot intelligenti in produzione non può limitarsi a usare la tecnologia, ma deve adottare alcune misure organizzative e operative precise.

In base all’articolo 26 dell’AI Act, gli obblighi principali del deployer includono:

• utilizzare il sistema di AI secondo le istruzioni fornite dal produttore;
• monitorare il funzionamento del sistema per individuare rischi, anomalie o possibili impatti sulla sicurezza;
• conservare i log, quando richiesto o tecnicamente previsto, e segnalare eventuali incidenti gravi;
• garantire che i dati di input siano pertinenti, affidabili e di qualità adeguata rispetto all’uso previsto.

La differenza rispetto al ruolo del fornitore è rilevante. Gli obblighi del fornitore comportano in genere costi elevati, competenze specialistiche, possibile coinvolgimento di un ente di certificazione, documentazione tecnica articolata e adempimenti continuativi. Gli obblighi del deployer, invece, si traducono soprattutto in procedure operative, controlli interni e una documentazione più contenuta.

Il punto decisivo è questo: qualificare correttamente il proprio ruolo lungo la filiera dell’AI è essenziale. Un errore può portare a sovra-compliance, con spreco di risorse e adempimenti non necessari, oppure a sotto-compliance, con conseguenti rischi regolatori, sanzionatori e di responsabilità.

Nota: l’AI Act prevede obblighi specifici anche per importatori e distributori.

Modifiche sostanziali: quando i deployer diventano fornitori

Le “modifiche sostanziali” sono uno dei punti più delicati nella robotica industriale con AI. Quando una modifica cambia la sicurezza della macchina o la compliance del sistema di AI, chi la apporta può assumere obblighi che normalmente spettano al produttore o al fornitore. Vediamo in dettaglio di che si tratta.

Regolamento Macchine

L’assegnazione delle responsabilità è stata migliorata, chiarendo che gli operatori economici sono responsabili quando una persona fisica o giuridica diversa dal produttore modifica significativamente il prodotto. Tale aspetto risulta particolarmente rilevante per le macchine basate su IA, soggette a rapidi progressi tecnologici e aggiornamenti.

Il Regolamento Macchine definisce “modifica sostanziale” qualsiasi cambiamento fisico o digitale non pianificato, effettuato dopo la messa sul mercato o la messa in servizio, che incide sulla sicurezza della macchina creando un nuovo pericolo o aumentando un rischio esistente. Quando ciò accade e si rendono necessarie nuove misure di protezione o modifiche al sistema di controllo di sicurezza, chi interviene assume le responsabilità del produttore.

La manutenzione ordinaria e le riparazioni che non alterano il profilo di rischio della macchina, al contrario, non rientrano normalmente in questa nozione gli aggiornamenti di sicurezza.

AI Act

Nel contesto dell’AI Act, per “modifica sostanziale” si intende un cambiamento non pianificato o imprevisto apportato a un sistema di AI dopo la sua immissione sul mercato o messa in servizio, che incide sulla compliance dei sistemi di AI ad alto rischio oppure modifica lo scopo previsto sulla base del quale il sistema era stato originariamente valutato.

In pratica, ogni intervento che possa incidere sulla compliance del sistema — i.e. una modifica del sistema operativo, dell’architettura software o delle condizioni d’uso — può comportare una nuova valutazione di compliance. Lo stesso vale quando cambia lo scopo previsto del sistema.

Tuttavia, non ogni adattamento costituisce una modifica sostanziale. Se il sistema continua ad apprendere dopo la messa sul mercato e modifica automaticamente il modo in cui svolge le proprie funzioni, tali cambiamenti non rientrano, di regola, nella nozione di modifica sostanziale, purché siano stati predeterminati dal fornitore e già valutati in sede di valutazione di compliance.

L’effetto giuridico è particolarmente rilevante: ai sensi dell’articolo 25, lettera b), chiunque, diverso dal fornitore originario, apporti una modifica sostanziale a un sistema di AI già immesso sul mercato assume a sua volta lo status di fornitore e, di conseguenza, tutti gli obblighi previsti dall’AI Act per tale ruolo.

In sintesi, quando una modifica incide su una funzione di sicurezza basata sull’AI, AI Act e Regolamento Macchine tendono a produrre effetti convergenti. Nella maggior parte dei casi, chi modifica il sistema non viene qualificato soltanto come produttore della macchina modificata, ma anche come fornitore del sistema di AI, con un conseguente aumento degli obblighi di compliance e delle responsabilità.

Strategie pratiche di compliance

Produttori e deployer, per ridurre il rischio normativo e gestire correttamente la compliance, devono adottare procedure pratiche già dalla fase di progettazione, di acquisto e di integrazione del robot.

Produttori di robotica AI ad alto rischio

• Definire chiaramente l’uso previsto: documentare industria, applicazione, ambiente e limiti operativi; indicare usi vietati e modifiche non consentite.
• Progettare il sistema per il controllo delle modifiche: adottare versioning, tracciamento delle modifiche, autenticazione degli aggiornamenti e limiti tecnici alle modifiche non autorizzate.
• Supportare i deployer nella compliance: fornire istruzioni chiare, esempi di modifiche sostanziali, protocolli approvati e supporto tecnico dedicato.
• Ridurre il rischio di vendor lock-in: usare architetture modulari, interfacce definite e percorsi di aggiornamento documentati che non alterino il ruolo del deployer.
• Organizzare la tenuta dei registri: condividere le informazioni rilevanti sugli eventi e coordinare la registrazione dei log con il deployer.

Deployer industriali di robotica AI ad alto rischio

• Verificare il proprio ruolo: accertare di operare come deployer, controllare l’uso previsto definito dal produttore e documentare la coerenza dell’impiego pianificato.
• Stabilire controlli interni sulle modifiche: consultare il produttore prima di ogni cambiamento rilevante e mantenere registri interni delle modifiche approvate.
• Prevedere tutele contrattuali: negoziare definizioni chiare di modifica sostanziale, supporto tecnico e tempi certi per le richieste di approvazione.
• Gestire il rischio di implementazione: ottenere conferme scritte sull’uso previsto, linee guida sulle modifiche consentite e supporto continuativo durante il ciclo di vita del prodotto.
• Curare la compliance operativa: seguire le istruzioni del produttore, monitorare le prestazioni, conservare i log richiesti, segnalare incidenti gravi e garantire la qualità dei dati di input.

La parola all’esperto di settore: Ugo Gecchelin – Comitato direttivo UNINFO, CEO di Team 4.0

Come enfatizza Ugo Gecchelin “Per la prima volta la sicurezza dovrà fare i conti con macchine che non si limitano a eseguire, ma apprendono ed evolvono. Di fatto, il 20/01/2027 il Regolamento (UE) 2023/1230 sostituirà la Direttiva Macchine 2006/42/CE e si segnerà un passaggio fondamentale per la robotica industriale. Il robot non sarà più considerato soltanto una macchina che ripete movimenti, ma un sistema che raccoglie dati, adatta traiettorie, riconosce oggetti e migliora progressivamente le proprie prestazioni: apprendendo ed evolvendosi”.

“Questa evoluzione – spiega Gecchelin – modifica anche il modo di concepire la sicurezza. Non basterà più verificare il comportamento della macchina all’immissione sul mercato: occorrerà valutare come essa potrà agire lungo tutta la sua vita utile. Un robot collaborativo può adattarsi alla presenza dell’operatore, un sistema di visione può perfezionare il riconoscimento dei pezzi, un robot mobile può scegliere percorsi diversi in funzione dell’ambiente. E lo stesso approccio vale anche in altri ambiti, quali quelli sanitario o zootecnico, dove automazione e adattamento operativo aprono nuove opportunità, ma richiedono controlli rigorosi. Ma fino a che limite il comportamento appreso rimane prevedibile, verificabile e sicuro?”

Gecchelin aggiunge: “Un algoritmo può ottimizzare una traiettoria, ma non deve ridurre le distanze di sicurezza. Può adattare una presa, ma non deve superare i limiti di forza compatibili con l’interazione uomo-macchina. Può modificare una sequenza operativa, ma non deve compromettere funzioni di arresto o controllo rilevanti per la sicurezza. La macchina può quindi apprendere, ma solo entro confini progettati, dichiarati e validati. A tutto ciò si aggiunge l’aspetto essenziale della cybersecurity. Un robot connesso non è esposto solo a possibili derive dell’algoritmo, ma anche ad attacchi informatici. Se software o parametri di sicurezza vengono alterati, il tema non è più soltanto informatico (ICT), ma diventa immediatamente un tema di safety e di convergenza IT/OT”.

In questo quadro si inserisce la Prassi di Riferimento UNI/PdR promossa da Federmacchine e di prossima pubblicazione, di cui Gecchelin è project leader, dedicata alla protezione dall’alterazione dei sistemi informatici delle macchine.

“Il fabbricante – evidenzia Gecchelin – dovrà definire con precisione quali funzioni possano essere adattive e quali debbano restare bloccate, stabilire limiti non superabili, garantire la tracciabilità delle versioni software e documentare il comportamento ammesso della macchina, tenendo conto anche dei profili di cybersecurity introdotti dal nuovo Regolamento Macchine, poiché la protezione dei sistemi di controllo e dei dati diventa parte integrante della sicurezza della macchina. La valutazione del rischio diventerà più dinamica, considerando aggiornamenti, apprendimento e modifiche dei parametri lungo l’intera vita utile del sistema, per garantire che un robot sicuro oggi, lo rimanga anche mentre apprende ed evolve”.

Conclusione

La robotica industriale con AI richiede una gestione integrata di AI Act e Regolamento Macchine. La vera linea di confine è data da tre fattori: funzione di sicurezza, ruolo di fornitore o deployer e modifiche sostanziali. Di fatto, chi chiarisce questi punti in anticipo può gestire meglio la compliance, ridurre il rischio normativo e accelerare l’adozione delle soluzioni AI in fabbrica.

Anche gli scenari di aggregazione dei dati, pur coerenti con la strategia europea di sviluppo dei modelli di fondazione, restano oggi giuridicamente incerti. Recentemente la Commissione Europea ha pubblicato una bozza di linee guida che chiariscono la classificazione dei sistemi IA ad alto rischio e un elenco di esempi pratici per raccogliere i commenti delle parti interessate.

È comunque prudente definire in modo esplicito nei contratti i ruoli di fornitore e deployer, valutando, ove opportuno, la designazione di terzi o consorzi affidabili come fornitori, così da consentire agli altri partecipanti di mantenere il proprio ruolo di deployer.

Nel contesto attuale, per l’industria europea, innovazione e compliance devono procedere insieme. Produttori e deployer possono muoversi con maggiore sicurezza solo se comprendono i criteri di classificazione ad alto rischio, rispettano la distinzione tra fornitore e deployer e presidiano le modifiche sostanziali. Tale approccio rende possibile accelerare il deployment della robotica AI senza compromettere certezza normativa e competitività manifatturiera.

In questo quadro, i Centri di Qualificazione Robotica (Robotics Skills Qualification Centres – RSQC), previsti nell’ambito della Apply AI Strategy, rappresentano uno sviluppo promettente. La Commissione europea li descrive come ambienti pratici per valutare e qualificare le competenze robotiche, con i primi progetti pilota attesi nel 2026 presso il TEF for Manufacturing AIMATTERS.

Di fatto, questi centri possono contribuire a ridurre l’incertezza di implementazione e a rendere più efficiente il percorso di compliance, sostenendo al tempo stesso la velocità di adozione richiesta dalla strategia industriale europea.

Un ulteriore punto chiave è distinguere tra “qualifica” e “certificazione”. La qualifica serve a dimostrare prestazioni tecniche e operative rilevanti per il mercato e per i clienti; la certificazione, invece, riguarda la verifica obbligatoria della compliance normativa. La qualifica non sostituisce la certificazione regolamentare, ma può diventare un fattore competitivo importante per l’accesso al mercato e per la fiducia degli utilizzatori.

In prospettiva, i sistemi già qualificati potrebbero agevolare anche il lavoro degli enti certificatori, perché offrono evidenze preliminari sulle prestazioni del robot. Tuttavia, i produttori dovranno verificare con attenzione se i requisiti di qualifica introdurranno, di fatto, un ulteriore livello di compliance. Per questo, man mano che i RSQC diventeranno operativi, i produttori dovrebbero valutare la qualifica come leva di differenziazione e come possibile supporto ai processi di valutazione della compliance; mentre i deployer potrebbero ridurre il rischio di implementazione scegliendo sistemi già pre-qualificati.

Concludendo, regolamentazione e sicurezza non rallentano l’innovazione: la rendono più solida. Solo una gestione strutturata dei rischi, della resilienza operativa e della compliance può sostenere una robotica industriale basata sull’AI che sia affidabile, scalabile e utile per persone, imprese ed ecosistemi industriali europei.