di VendorVet (LX AI)

Documentazione tecnica ai sensi del Regolamento AI

Ai sensi del Regolamento (UE) 2024/1689, i fornitori ad alto rischio devono conservare una documentazione tecnica che dimostri la conformità prima della messa sul mercato. Le squadre spesso assemblano le parti ovvie e trascurano ciò che gli auditor esaminano per primi: riassunti dei dataset, progettazione della supervisione umana e monitoraggio post-messa sul mercato. Considerare qualsiasi outline generato come una bozza da verificare contro la Gazzetta Ufficiale, e non come una presentazione finale.

Ciò che la documentazione effettivamente copre

L'articolo 11 e l'allegato IV stabiliscono il contenuto della documentazione per i sistemi ad alto rischio. Il pacchetto comprende lo scopo previsto, le scelte di progettazione, la storia di sviluppo e testing, le pretese di prestazione e le misure di gestione del rischio effettivamente eseguite. La Commissione riassume l'Atto come un quadro basato sul rischio con doveri più gravosi per utilizzi ad alto rischio; partire da questo quadro prima di inventare un modello personalizzato (Commissione europea — Atto sull'IA).

Il testo vincolante è il regolamento stesso su EUR-Lex (Regolamento (UE) 2024/1689). I blog e le presentazioni secondarie sono utili solo dopo che si può fare riferimento all'articolo e alla riga dell'allegato che supporta ogni affermazione. Tratto la documentazione come un set di file vivo sotto controllo versione, non come un PDF esportato una tantum la settimana prima di una demo.

Ciclo di vita, non una fotografia istantanea

Se il modello cambia, l'insieme di training viene aggiornato o un controllo di sicurezza viene riorganizzato, la documentazione deve mostrare la variazione. Le note di modifica, i proprietari e le date sono importanti quanto la prima stesura. Quando un deployer chiede "quale build era in produzione martedì?", dovresti rispondere dallo stesso record che supporta la conformità — non da un thread di Slack.

Flusso di lavoro passo dopo passo che utilizziamo prima di considerare un pacchetto "pronto"

- Conferma che il sistema è ad alto rischio (o verrà trattato come tale) ai sensi dell'Articolo 6 / Allegato III prima di creare un albero di documentazione. Se non è ad alto rischio, non esagerare con la completezza dell'Allegato IV nella copia di vendita. - Apri l'Allegato IV e crea una cartella o un ticket per ogni tema: descrizione generale, specifiche di progettazione, processo di sviluppo, dati, gestione dei rischi, testing, monitoraggio e controllo umano. - Assegna un unico proprietario per ogni tema. La proprietà condivisa senza un nome è il modo in cui le sezioni rimangono vuote. - Redigi con il prodotto e l'ingegneria nella stanza. Le recensioni legali verificano le affermazioni; gli ingegneri forniscono percorsi di prova (configurazioni, dashboard, report di test). - Collega ogni affermazione a un artefatto: un riassunto del set di dati, uno schema di logging, un runbook, una riga del registro dei rischi. La prosa non collegata è un odore. - Verifica il pacchetto contro il sistema live: la configurazione di logging corrisponde alle affermazioni dell'Articolo 12? Il percorso di override nell'interfaccia utente corrisponde al testo dell'Articolo 14? - Pianifica un trigger di aggiornamento: aumento della versione del modello, modifica del set di dati, nuova classe di deployer o incidente grave quasi verificatosi.

VendorVet trasforma questi temi in una checklist funzionante. Non sostituisce il giudizio del corpo notificato o del consulente. Utilizza il prodotto per rilevare le omissioni precocemente; utilizza la Gazzetta Ufficiale per risolvere le discussioni.

Riepilogo dei dati delle squadre (Articolo 10)

L'Articolo 10 prevede la governance dei dati: i dati di training, convalida e testing devono essere rilevanti e rappresentativi per lo scopo previsto, con esame per pregiudizi e lacune che potrebbero danneggiare le prestazioni per le persone che il sistema influenzerà. Gli auditor cercano un riepilogo di quali dati sono stati utilizzati e come sono stati esaminati — non una carta di modello di marketing con tre aggettivi.

Una riga di controllo che dice "dati esaminati" senza un riepilogo dietro di essa non supera la prima revisione seria. Scrivete il riepilogo in modo che un nuovo ingegnere possa rispondere: domini di origine, finestre temporali, distorsioni note, regole di esclusione e come sono stati prodotti o verificati gli etichetti. Se i dati personali si trovano nella pipeline, mantenete i vostri ruoli e basi GDPR coerenti con il modo in cui descrivete l'elaborazione altrove; la libreria di orientamento dell'EDPB è il controllo incrociato pratico per quel linguaggio (linee guida e best practice dell'EDPB).

Controllo — prove dei dati

Progettazione della supervisione umana (Articolo 14)

L'Articolo 14 richiede una supervisione umana significativa: interfacce e controlli che consentono a una persona di monitorare, interpretare e annullare gli output quando necessario. "Gli esseri umani rimangono nel loop" non è un meccanismo. Documentare il percorso di annullamento specifico, chi può esercitarlo, come il sistema segnala che un essere umano debba intervenire e cosa succede quando l'essere umano non è disponibile.

Nei prodotti di agenti, ciò significa spesso un arresto completo prima di un'azione conseguente (pubblicazione dell'elenco di candidati, invio della decisione di credito, aggiornamento del fascicolo), non un pulsante di approvazione decorativo che si attiva automaticamente dopo tre secondi. Accoppiare la descrizione dell'interfaccia utente con la politica di runtime: quali ruoli, quali ambienti, quali eventi di audit si verificano quando viene utilizzato l'annullamento.

Checklist — prove di supervisione

- Ruoli di supervisione nominati e percorso di escalation - Controlli dell'interfaccia utente o dell'API che effettivamente pausano o annullano l'azione dell'AI - Segnali / soglie che richiedono la revisione umana - Formazione o runbook per le persone che supervisionano - Prove che gli eventi di annullamento vengono registrati

Monitoraggio e registrazione post-marketing (Articoli 12 e 72)

L'Articolo 12 richiede una registrazione automatica sufficiente per la tracciabilità, con un periodo di conservazione minimo di sei mesi per i sistemi ad alto rischio. L'Articolo 72 aggiunge doveri di segnalazione di incidenti gravi. I team documentano il modello e dimenticano il piano di prove di runtime. Accoppiare la documentazione con la configurazione di registrazione effettiva in modo che le due siano coerenti.

Se già si esegue l'osservabilità GenAI, mappare span ed eventi alle domande che una revisione post-marketing chiederà: quale classe di input, quale versione del modello, quale decisione di politica, quale azione umana. Le convenzioni GenAI di OpenTelemetry sono un riferimento tecnico pratico per nominare quei campi in modo coerente tra i servizi (OpenTelemetry — Osservabilità GenAI). L'Atto non obbliga OTel; tracce coerenti rendono solo più facili da difendere le pretese dell'Articolo 12.

Errori comuni che riscontriamo nei pacchetti di documentazione

- Scrivere per il brochure, non per l'allegato. I diagrammi belli che non citano i temi dell'Allegato IV sprecano il tempo di revisione. - Copiare un modulo di lavoro US RMF e rinominarlo "pacchetto AI Act." Il framework di gestione del rischio AI di NIST (NIST AI RMF) è utile per il vocabolario dei processi, ma non è un sostituto del contenuto dell'Articolo 11 / Allegato IV. - Documentare il modello di ieri. La produzione è già stata spostata; il pacchetto no. - Lasciare le istruzioni per i deployer vuote. La trasparenza dell'Articolo 13 per i deployer è facile da saltare quando il team del fornitore parla solo con se stesso. - Chiamare una checklist "certificata." Quel linguaggio esagera. Le checklist riducono il rischio di omissione; non certificano la conformità.

Criteri di decisione: spedire il pacchetto vs continuare a redigere

Trattare il pacchetto come blocco di rilascio per un lancio ad alto rischio quando una delle seguenti condizioni è vera:

- Nessun riassunto del set di dati che un terzo può seguire - Nessun meccanismo di controllo umano descritto legato a un controllo reale - Conservazione dei log inferiori a sei mesi, o log che non possono ricostruire una decisione - Registro dei rischi senza proprietari di rischio residuale - Scopo previsto così vago che la mappatura di Annex III è impossibile

È ancora possibile spedire prototipi interni che non toccano l'uso ad alto rischio dell'UE. Siate onesti sulla portata per iscritto. Il linguaggio ambiguo "siamo conformi nello spirito" è peggiore di uno stato chiaro "non ancora ad alto rischio / non ancora sul mercato dell'UE".

Cosa questo non è

Questa pagina non è un parere legale, non è una valutazione di un organismo notificato e non è una garanzia che il tuo sistema sia conforme al Regolamento (UE) 2024/1689. VendorVet non afferma di avere una copertura del 100%, non inventa tassi di vincita dei clienti e non sostituisce un consulente o una valutazione di conformità quando è richiesta. Una checklist ti aiuta a raccogliere e verificare temi; l'obbligo vincolante rimane la documentazione descritta nell'Articolo 11 e nell'Allegato IV, di proprietà di persone qualificate nella tua organizzazione.

Conclusione

Iniziare con il testo della Gazzetta Ufficiale, mappare i temi dell'Allegato IV ai proprietari, poi colmare le tre lacune che gli auditor aprire per primi: dati, vigilanza e registrazione. Mantenere il pacchetto versionato con il sistema. Quando il modello o il set di dati si sposta, spostare la documentazione nello stesso treno di rilascio. Per la decisione di tier di rischio che si trova a monte di tutto questo, leggere la nostra guida sorella sui tier di rischio dell'EU AI Act.

Riferimenti

- Regolamento (UE) 2024/1689 (EUR-Lex) - Commissione europea — Legge sull'intelligenza artificiale - Legge sull'intelligenza artificiale dell'UE — Cronologia di implementazione - Quadro di gestione del rischio dell'intelligenza artificiale del NIST - EDPB — Linee guida e best practice del GDPR - OpenTelemetry — Osservabilità del GenAI