ETD

• ai act, cyber resilience act, open-source software

Every obligation in the EU Artificial Intelligence Act is addressed to an identifiable person. Open-source agentic frameworks do not supply one. This thesis asks how EU law decides whom to place obligations on when no producer of an AI system can be identified, and why the AI Act did not do so here. Taking OpenClaw, its add-on registry and its US foundation as a most-likely case, it reads the Act actor by actor and weighs nine allocation devices across eight instruments. No actor in the middle of the chain holds a determinate status, and in a sanctions-backed regime that uncertainty engages the interest the legality principle protects. Where a status does attach, the duties that follow are not aimed at the conduct that produced the harm. The systemic-risk regime is keyed to model capability, so its duties land on the model's provider rather than on the deployed population. One architectural choice produces all three. The Cyber Resilience Act, facing the same difficulty, built an addressee: the open-source software steward. Why they diverged is put as a question and tested; a deliberate policy choice about open source is best supported and still incomplete. Other instruments narrow the gap without closing it, and what none requires of this chain is the screening of what a registry publishes, vulnerability handling and coordinated disclosure. The contribution is doctrinal and comparative: the technique exists and was not applied here, and whether it should be is left open.

Nell'AI Act ogni obbligo presuppone un destinatario identificabile, che i framework agentici open source non offrono. La tesi indaga come il diritto dell'Unione individui il soggetto obbligato quando manca un produttore riconoscibile, e perché qui non l'abbia fatto. Sul caso OpenClaw, col suo registro di estensioni e la sua fondazione statunitense, applica il regolamento attore per attore e soppesa nove tecniche di allocazione tratte da otto strumenti. Nessuno degli attori intermedi assume uno status determinato: in un regime sanzionatorio l'incertezza chiama in causa l'interesse tutelato dal principio di legalità. Dove sussiste, gli obblighi non colpiscono la condotta all'origine del danno. Il rischio sistemico è ancorato alle capacità del modello: gli obblighi ricadono sul suo fornitore, non sulla popolazione delle installazioni. Un'unica scelta architetturale le produce tutte e tre. Davanti alla stessa difficoltà, il Cyber Resilience Act ne ha costruito uno: il gestore di software open source. Perché divergano resta da verificare, e la spiegazione meglio sostenuta, tuttora incompleta, è una scelta di politica legislativa sull'open source. Altri strumenti restringono la lacuna senza colmarla: nessuno impone a questa catena lo screening di ciò che un registro pubblica, la gestione delle vulnerabilità e la divulgazione coordinata. Il contributo è dottrinale e comparativo: la tecnica esiste e qui non è stata applicata; se debba esserlo resta una domanda aperta.