Obblighi dei deployer: guida pratica per team SaaS

Gli obblighi dei deployer nell'EU AI Act riguardano le organizzazioni che usano un sistema di IA sotto la propria autorita. Per un team SaaS non basta sapere se il sistema e stato costruito internamente o comprato. Serve capire chi controlla l'uso, se il sistema e ad alto rischio, quali istruzioni del provider vanno seguite, chi svolge la supervisione umana e quali evidenze esistono su log, monitoraggio e incidenti.

L'articolo 26 richiede ai deployer di sistemi IA ad alto rischio di usare il sistema secondo le istruzioni, assegnare supervisione umana competente, gestire i dati di input quando li controllano, monitorare il funzionamento, conservare i log automatici sotto il loro controllo e agire in caso di rischio o incidente grave. In alcuni casi servono anche informazione ai lavoratori, controlli di registrazione, supporto DPIA o valutazione di impatto sui diritti fondamentali.

Quando e rilevante

Una societa SaaS puo essere provider per una feature cliente e deployer per un workflow interno o per uno strumento di terze parti. Esempi comuni sono support triage, HR, scoring del rischio, frodi, flussi finanziari, reclami o decisioni che influenzano utenti e dipendenti.

L'analisi va fatta per workflow. Un documento unico su "IA aziendale" spesso nasconde ruoli diversi. Separare obblighi del deployer, trasparenza, privacy, security, vendor risk e documentazione cliente evita lacune operative.

Record operativo

Create un record per ogni workflow rilevante. Includete sistema, fornitore, processo, finalita, utenti, persone interessate, categorie di dati, geografia, stato di lancio, istruzioni del provider e documentazione interna.

Poi documentate ruolo e classificazione: perche il team e deployer, se il caso e ad alto rischio, quale percorso dell'AI Act si applica e quali domande bloccano il lancio. Ogni obbligo deve diventare un controllo: istruzioni operative, supervisione, input consentiti, log, monitoraggio, sospensione ed escalation.

Checklist

• Nominare sistema, fornitore, workflow, finalita, utenti e persone interessate.
• Decidere se l'azienda e deployer, provider o entrambi.
• Valutare alto rischio o altro percorso AI Act.
• Tradurre le istruzioni del provider in SOP, ticket, criteri di accettazione e training.
• Assegnare supervisione umana con competenza, autorita e supporto.
• Definire controlli sui dati di input.
• Chiarire log, retention, accesso ed export.
• Monitorare errori, reclami, cambi del vendor, uso improprio e pattern inattesi.
• Preparare incident route, sospensione, contatto provider ed escalation.
• Salvare evidenze con owner, data, decisione e prossimo review.

Errori comuni

Il primo errore e pensare che il vendor copra tutto. I suoi documenti aiutano, ma il deployer controlla l'uso reale. Il secondo e lasciare le istruzioni in procurement senza trasformarle in passi operativi. Il terzo e dare supervisione umana a chi non puo contestare, fermare o scalare. Il quarto e scoprire troppo tardi che i log non sono disponibili.

FAQ

Qual e lo scopo pratico?

Dimostrare che il team segue le istruzioni, assegna supervisione competente, controlla gli input, conserva i log, monitora l'uso, gestisce incidenti e rivaluta il workflow quando cambiano i fatti.

Chi deve esserne owner?

Product o operations possiedono i fatti del workflow, engineering integrazione e log, security evidenze vendor e monitoraggio, legal/compliance interpretazione e standard probatorio.

Fonti

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 26: Obligations of deployers of high-risk AI systems.
• European Commission AI Act Service Desk, Article 27: Fundamental rights impact assessment for high-risk AI systems.
• European Commission AI Act Service Desk, Article 13: Transparency and provision of information to deployers.