Skip to main content

Conformità al regolamento IA nella pipeline CI/CD

Che cosa richiede il regolamento e una pipeline CI/CD può documentare, tre fasi della pipeline, come funziona il merge gate GitHub di Scanara e dove si fermano le scansioni basate su regole.

Il regolamento non richiede CI/CD. I fornitori di sistemi di IA ad alto rischio devono tenere aggiornata la documentazione tecnica (articolo 11). Devono anche fare prove prima dell’immissione sul mercato o della messa in servizio (articolo 9(8)). Devono inoltre gestire un sistema di gestione della qualità (articolo 17). Una pipeline può fornire prove di questi obblighi.

Questi obblighi si applicano dal 2 dicembre 2027 (allegato III) e dal 2 agosto 2028 (allegato I). L’articolo 2 elenca esclusioni. Le sanzioni arrivano a 15 milioni di EUR o al 3 % del fatturato mondiale annuo, se superiore (articolo 99(4)). Prossimo passo: associare ogni fase della pipeline all’articolo che documenta.

Una pipeline può fornire prove di questi obblighi; non decide la conformità

  • La documentazione tecnica resta aggiornata (articolo 11)

    La documentazione tecnica è redatta prima dell’immissione sul mercato o della messa in servizio e tenuta aggiornata. Contiene almeno gli elementi dell’allegato IV. Un passaggio della pipeline può verificare che i documenti richiesti esistano e cambino insieme al codice.

  • Le prove si fanno prima dell’immissione sul mercato o della messa in servizio (articolo 9(6)-(8))

    Le prove si svolgono in qualsiasi momento dello sviluppo e, in ogni caso, prima dell’immissione sul mercato o della messa in servizio, sulla base di metriche e soglie probabilistiche definite in precedenza e adeguate alla finalità prevista. Fasi di test della pipeline con soglie fisse producono risultati datati.

  • La gestione della qualità comprende il controllo delle modifiche (articolo 17(1))

    Il sistema di gestione della qualità documenta il controllo della progettazione, il controllo di qualità dello sviluppo, le procedure di esame, prova e convalida e la gestione delle modifiche. I log della pipeline e le regole di revisione possono registrare questi passaggi.

  • Le modifiche sostanziali richiedono una nuova valutazione della conformità (articolo 43(4))

    Una modifica apportata a un sistema dopo l’immissione sul mercato, non prevista dalla valutazione della conformità iniziale e che incide sulla conformità ai requisiti della sezione 2 o cambia la finalità prevista, è una modifica sostanziale (articolo 3, punto 23). Una pipeline può segnalare le modifiche al modello o alla finalità prevista per la revisione umana. Non decide se una modifica sia sostanziale. Per i sistemi che continuano ad apprendere dopo l’immissione sul mercato, le modifiche predeterminate nella valutazione iniziale e documentate secondo l’allegato IV, punto 2, lettera f), non sono modifiche sostanziali (articolo 43(4)).

Tre fasi della pipeline coerenti con questi obblighi (nostra proposta)

Il regolamento non indica fasi della pipeline. Questa suddivisione mette controlli rapidi su ogni pull request e la scansione completa prima del rilascio.

Fase 1: controlli sulla pull request

Si eseguono a ogni pull request e danno un riscontro rapido agli sviluppatori.

  • Scansione del codice: L’analisi statica basata su regole segnala componenti di IA e schemi mancanti, per esempio operazioni di IA senza registrazione. Rileva solo schemi standard dei framework di ML.
  • Controllo dei documenti: Regole di policy verificano che i documenti richiesti esistano e contengano le sezioni richieste. Verificano che il contenuto sia presente, non che sia vero o buono.
  • Registro della classe di rischio: Verifichi che la classificazione del rischio del sistema sia registrata e riesaminata quando cambiano il codice o la finalità prevista. La classificazione stessa è una decisione umana (articolo 6).

Fase 2: merge gate

Un controllo prima del merge che può fermare modifiche non conformi.

  • Soglie dei riscontri: Fissi soglie per i riscontri critici e alti. In modalità bloccante, una scansione sopra le soglie fa fallire il controllo.
  • Riscontri sugli articoli 5 e 14: Una scansione del codice non mostra intenzione né contesto. Una persona esamina ogni riscontro che indica una pratica vietata (articolo 5) o l’assenza di sorveglianza umana (articolo 14).
  • Modifiche alla documentazione: Verifichi che la documentazione dell’allegato IV cambi nella stessa pull request del codice che descrive.

Fase 3: scansione prima del rilascio

Una scansione completa della versione candidata.

  • Scansione completa: Una scansione completa di codice e documenti. La scansione dei documenti supporta otto lingue: EN, DE, FR, IT, ES, NL, PL e PT.
  • Bozza di dossier: Scanara redige bozze di documenti allineate agli allegati IV e V a partire dai suoi dati e dalle risposte di valutazione. Il precompilato è parziale; il resto lo scrive e lo verifica lei.
  • Istantanea delle prove: Conservi il rapporto di scansione con il registro del rilascio, per poter mostrare che cosa è stato verificato e quando.

Come funziona il merge gate GitHub di Scanara

Scanara riceve gli eventi di pull request di GitHub, scansiona la modifica e riporta il risultato come check run di GitHub. In modalità solo rapporto, un controllo fallito è segnalato come neutro. In modalità bloccante il controllo fallisce.

Il merge gate funziona solo con GitHub. Le scansioni pianificate non sono ancora disponibili; le scansioni si eseguono su richiesta e sulle pull request.

Che cosa verificano le scansioni e dove si fermano

La copertura è parziale. Nell’istantanea del 24 agosto 2026, 77 dei 174 obblighi mappati hanno regole sul codice, in 43 articoli, e 23 hanno regole sui documenti, in 23 articoli. La mappatura precede le modifiche del regolamento (UE) 2026/1744, per esempio gli articoli 4a, 60a e da 75a a 75d. Gli altri obblighi richiedono valutazioni e lavoro umano.

Regole sul codice

  • Articolo 5: pratiche vietate

    Le regole segnalano schemi di codice che possono indicare una pratica vietata. Se una pratica sia vietata dipende da finalità e contesto, che il codice non mostra.

  • Articolo 9: gestione del rischio

    Le regole segnalano punti decisionali di IA senza codice riconoscibile di valutazione del rischio o di convalida.

  • Articolo 10: dati e governance dei dati

    Le regole segnalano pipeline di addestramento senza controlli riconoscibili della qualità dei dati.

  • Articolo 12: registrazione

    Le regole segnalano operazioni di IA senza registrazione riconoscibile.

  • Articolo 14: sorveglianza umana

    Le regole segnalano percorsi decisionali senza un punto di intervento umano riconoscibile, come un override o una procedura di arresto.

  • Articolo 15: accuratezza e robustezza

    Le regole segnalano la mancanza di convalida del modello e di metriche di accuratezza.

Regole sui documenti

  • Sezioni della documentazione tecnica (articolo 11)

    Le regole di Scanara definiscono otto sezioni obbligatorie della documentazione tecnica, basate sull’allegato IV, e verificano che siano presenti. Verificano che il contenuto sia presente, non che sia buono.

  • Istruzioni per l’uso (articolo 13)

    Verifica che le istruzioni per l’uso esistano e contengano le sezioni richieste.

  • Dichiarazione di conformità UE

    Verifica che la dichiarazione contenga gli elementi elencati nell’allegato V.

  • Otto lingue

    La scansione dei documenti supporta EN, DE, FR, IT, ES, NL, PL e PT.

Checklist di implementazione

  • Aggiunga una scansione di codice e documenti al flusso di lavoro delle pull request.
  • Inizi in modalità solo rapporto e riesamini i riscontri.
  • Fissi soglie per i riscontri critici e alti, poi passi alla modalità bloccante.
  • Richieda la revisione umana di ogni riscontro che riguarda l’articolo 5 o l’articolo 14.
  • Conservi il rapporto di scansione con ogni registro di rilascio.
  • Segnali per la revisione le modifiche a modello, dati di addestramento o finalità prevista come possibili modifiche sostanziali (articolo 43(4)).
  • Ripeta la scansione completa prima di ogni rilascio e aggiorni la documentazione dell’allegato IV.
  • Tenga la documentazione tecnica nel repository accanto al codice e la aggiorni nella stessa pull request.

Esclusioni, sistemi più vecchi e massimali delle sanzioni

Il regolamento non si applica ai sistemi di IA usati esclusivamente per scopi militari, di difesa o di sicurezza nazionale (articolo 2(3)). Non si applica ai sistemi di IA sviluppati e messi in servizio specificamente e al solo scopo di ricerca e sviluppo scientifici (articolo 2(6)), né alla ricerca, alle prove o allo sviluppo prima dell’immissione sul mercato o della messa in servizio, salvo le prove in condizioni reali (articolo 2(8)). I sistemi con licenze libere e open source sono esclusi, salvo che siano immessi sul mercato o messi in servizio come sistemi ad alto rischio o rientrino nell’articolo 5 o 50 (articolo 2(12)). Le persone fisiche che usano un sistema in un’attività puramente personale e non professionale non sono vincolate come deployer (articolo 2(10)). Per i sistemi ad alto rischio legati a prodotti disciplinati dalla normativa dell’allegato I, sezione B, come veicoli a motore, aviazione, ferrovie, attrezzature marittime, veicoli agricoli e macchinari, si applicano solo l’articolo 6(1), l’articolo 60a e gli articoli da 102 a 112. Gli articoli da 57 a 59 si applicano solo nella misura in cui tale normativa integra i requisiti (articolo 2(2)).

I sistemi ad alto rischio immessi sul mercato o messi in servizio prima della data di applicazione sono coperti solo dopo modifiche significative della progettazione. In ogni caso, i fornitori e i deployer di sistemi di IA ad alto rischio destinati a essere utilizzati da autorità pubbliche devono adottare le misure necessarie per conformarsi entro il 2 agosto 2030 (articolo 111(2)).

Per le PMI, ogni sanzione arriva al massimo alla percentuale o all’importo più bassi (articolo 99(6)). Per le piccole imprese a media capitalizzazione (articolo 3, punto 14b) lo stesso massimale vale per le sanzioni dell’articolo 99, paragrafi 4 e 5 (articolo 99(6a)). Il livello da 15 milioni di EUR copre anche gli obblighi di fornitori e operatori dell’articolo 25, paragrafi 2 e 4 (articolo 99(4), lettera da)).

Da leggere dopo: audit trail, scansione basata su regole e documentazione tecnica

Scanara prepara evidenze dai vostri repository

Scanara legge i vostri repository GitHub collegati ed esegue scansioni basate su regole per individuare pattern comuni di IA e machine learning. Può non rilevare il codice non standard. Separatamente genera bozze di documentazione a partire da modelli e dalle vostre risposte alle valutazioni, come evidenze per il vostro lavoro di conformità. La classificazione la decidete voi.