Come i team HR possono distribuire app create con l'IA senza esporre i dati dei dipendenti

La società di sicurezza RedAccess ha cercato app create con strumenti di programmazione basati sull'IA e pubblicate sull'hosting degli strumenti stessi, trovandone oltre 5.000 praticamente prive di qualsiasi sicurezza o autenticazione. Tra gli screenshot condivisi con Wired figurava quello che sembrava un prospetto delle assegnazioni di lavoro di un ospedale, completo di informazioni personali dei medici.

La creazione è la parte che gli strumenti di programmazione con IA hanno semplificato. L'esposizione nelle app create con l'IA per i team HR arriva dopo, quando un registro delle assenze o una scheda di valutazione dei colloqui viene pubblicata come nella demo: un link pubblico, un solo account amministratore e l'intera tabella dei dipendenti dietro di esso.

TL;DR

• Uno strumento che contribuisce a decidere chi assumere o promuovere, o come valutare le persone, può essere considerato ad alto rischio ai sensi dell'AI Act dell'UE. Deve passare dall'IT e dall'ufficio legale o dal DPO prima di assegnare un punteggio a qualcuno.
• I record dei dipendenti non devono mai risiedere sull'hosting dello strumento di programmazione con IA. L'impostazione predefinita è un server controllato dal team, raggiungibile soltanto su una rete privata, con accesso aziendale anteposto quando i responsabili o tutti i dipendenti devono accedervi.
• Le correzioni passano attraverso lo stesso strumento di IA che ha creato l'app: ridurre i campi letti, offrire viste diverse agli amministratori HR, ai responsabili e ai dipendenti, spostare le credenziali fuori dal codice, ridurre ciò che viene inviato all'esterno, registrare chi apre ogni record e gestire le richieste di cancellazione nel rispetto degli obblighi di conservazione. Ogni correzione viene confermata da una verifica che esegui tu, non dal rapporto dell'IA stessa.
• L'accesso allo strumento deve terminare il giorno in cui termina il rapporto di lavoro, una persona identificata deve esserne responsabile e scegliere la posizione del server non garantisce alcuna conformità.

Gli errori di distribuzione che espongono i dati dei dipendenti

Uno strumento HR creato con l'IA espone i dati dei dipendenti a chi trova il suo link, a chi possiede una credenziale incollata in una chat o nel codice, ai colleghi che aprono record destinati ad altri, ai servizi esterni a cui invia dati e alle persone che hanno lasciato l'azienda, senza registrare chi ha consultato cosa. Leggere l'intera tabella dei dipendenti amplia ciascuna di queste vie.

La prima riga è il problema che RedAccess ha riscontrato su larga scala. Nel reportage di Wired sui risultati di RedAccess, tre delle quattro aziende di programmazione con IA hanno contestato le affermazioni dei ricercatori (la quarta non ha risposto), ma non hanno negato che le app realizzate tramite vibe coding trovate da RedAccess fossero rimaste esposte. Io lo interpreto come un problema di configurazione e un passaggio di revisione saltato.

Verifica se lo strumento contribuisce a decidere chi assumere, promuovere o valutare

Essere stato creato con uno strumento di programmazione con IA non rende, di per sé, uno strumento HR ad alto rischio ai sensi dell'AI Act dell'UE. A determinarlo è ciò che fa. L'allegato III dell'AI Act dell'UE elenca i sistemi di IA usati per reclutare o selezionare persone e prendere decisioni su promozioni, licenziamenti, assegnazione dei compiti o monitoraggio e valutazione delle prestazioni.

Quindi, prima di decidere dove eseguire lo strumento, poniti una domanda: prende o influenza una decisione su chi viene assunto, promosso, licenziato, assegnato a un lavoro o valutato per le sue prestazioni?

Un registro delle assenze, una checklist di onboarding o un elenco dell'organizzazione memorizza i record e li mostra, quindi si trova dalla parte del «no». Una scheda di valutazione dei colloqui che classifica i candidati, o uno strumento delle prestazioni che assegna punteggi alle persone (soprattutto se è un modello di IA a farlo), potrebbe trovarsi dalla parte del «sì». Quando non riesco a capire da quale parte si trovi uno strumento, lo tratto come un sì e lascio che l'IT e l'ufficio legale mi dicano altrimenti.

Il regolamento non riguarda solo le aziende dell'UE: l'articolo 2 copre fornitori e deployer stabiliti fuori dall'UE quando l'output del loro sistema di IA viene utilizzato nell'UE. Ai sensi dell'articolo 113 come modificato, gli obblighi per i sistemi ad alto rischio dell'allegato III si applicano dal 2 dicembre 2027. Includono un sistema di gestione dei rischi, governance dei dati, documentazione tecnica, conservazione delle registrazioni, trasparenza verso i deployer e supervisione umana (articoli da 9 a 14), e la loro valutazione spetta all'IT e all'ufficio legale.

Se la risposta è sì, fermati prima che lo strumento valuti anche un solo candidato o dipendente reale. Portalo all'IT e al tuo responsabile legale o della protezione dei dati (il DPO, se presente). Questa verifica non stabilisce se uno specifico strumento rientri nell'ambito di applicazione; indica chi deve decidere. Anche alcuni stati degli USA regolano le decisioni automatizzate sulle assunzioni; trovi queste norme nella tabella più avanti.

Puoi dare un vantaggio iniziale a questa revisione. Io chiederei allo strumento di IA di argomentare contro il proprio sistema di punteggio anziché difenderlo:

Questa app assegna punteggi o classifica candidati o dipendenti. Elenca ogni campo di dati e ogni passaggio di calcolo che contribuisce al punteggio o alla classifica. Per ciascuno, dimmi se potrebbe riflettere direttamente o indirettamente una caratteristica protetta: età, razza, sesso, nazionalità, origine etnica, disabilità, gravidanza, religione o orientamento sessuale. Quando non sei sicuro, dillo invece di indovinare. Poi segnala qualsiasi aspetto di equità di questa valutazione su cui non ho fatto domande ma avrei dovuto farle.

Verifica: considera la risposta come un elenco iniziale per chi esamina lo strumento, non come un verdetto, e consegnala insieme allo strumento stesso. Eseguire questo prompt non è un audit dei bias e non soddisfa alcun requisito legale.

Dove dovrebbe essere eseguito uno strumento HR

Tieni i record dei dipendenti fuori dall'hosting dello strumento di IA. Per uno strumento usato solo dal team HR, la scelta predefinita è un server controllato dal team, raggiungibile solo su una rete privata, con accesso aziendale anteposto quando serve ai responsabili o ai dipendenti. Uno strumento che non supera la verifica sulle decisioni di assunzione, o per il cui server nessuno può assumersi la responsabilità, va all'IT.

Pubblicare sull'hosting di uno strumento di programmazione con IA colloca l'app a un indirizzo sul dominio del fornitore e, se la visibilità non è impostata su privata, chiunque trovi quell'indirizzo può raggiungerla. RedAccess ha identificato migliaia di app create così tramite normali ricerche su Google e Bing per quei domini. Una rete privata funziona al contrario: lo strumento risponde solo ai dispositivi che vi hanno aderito. L'accesso aziendale (single sign-on) permette ai colleghi di aprire lo strumento con l'account aziendale che già utilizzano, verificato da un provider di identità, il servizio che gestisce quegli account.

Finché lo strumento non viene eseguito sul server del team, crealo e testalo con dati sintetici: nomi, stipendi e date di assenza inventati ma strutturati come quelli reali. Un tunnel gratuito da un portatile a un indirizzo pubblico è pubblico esattamente come l'hosting del fornitore, quindi appartiene anch'esso alla fase dimostrativa.

Perché una rete privata e non la pagina di accesso che l'app possiede già? Una rete privata significa che lo strumento non risponde affatto dall'esterno: nessuno al di fuori può caricarlo, sondarlo o indovinare le password. Una pagina di accesso scritta dallo strumento di IA da sola non basta. Chiunque può raggiungerla ed è sicura solo quanto il codice generato che la sostiene. Il rapporto Veracode 2025 sulla sicurezza del codice GenAI ha rilevato che il 45% dei campioni di codice testati, provenienti da oltre 100 modelli, non ha superato i test di sicurezza per una vulnerabilità OWASP Top 10 (una delle voci di un elenco ampiamente usato dei rischi di sicurezza più critici delle applicazioni web). Ecco perché preferisco mettere un lucchetto davanti all'app anziché affidarmi a quello scritto dall'IA.

Per il passaggio di consegne, lo strumento gira su un VPS (un server noleggiato che il team controlla completamente) sotto uno strumento di distribuzione come Coolify o Dokku, che esegue l'app a partire dal codice; Coolify permette anche di ripristinare una versione precedente dopo un aggiornamento difettoso dal suo dashboard. Scegliere tra Coolify e Dokku dipende soprattutto da quante app eseguirà il server e dal fatto che il supporto IT preferisca un dashboard. La rete privata è fornita da Tailscale o WireGuard. Tailscale è più rapido da configurare, ma il suo servizio di coordinamento è gestito da Tailscale, mentre WireGuard è interamente self-hosted. L'accesso aziendale viene da un provider di identità come Authentik o Keycloak. Un reverse proxy come Caddy o Nginx Proxy Manager aggiunge HTTPS dove l'accesso è esposto al web. Questa è la parte da affidare al supporto IT, insieme alla checklist finale.

Le correzioni, come prompt per il tuo strumento di IA

Gran parte del lavoro per distribuire in sicurezza un'app HR creata con l'IA passa dallo strumento che l'ha costruita, ma solo se glielo chiedi. Come ha detto a Wired il ricercatore di sicurezza Joel Margolis, gli strumenti di programmazione con IA «fanno quello che chiedi loro. E, se non chiedi di farlo in modo sicuro, non si sforzeranno appositamente di farlo».

Considera ogni prompt seguente come un punto di partenza e modifica i nomi dei campi e i ruoli in base al tuo strumento. Io considero lo strumento di IA come l'ingegnere e me stesso come il revisore, quindi il rapporto che dichiara completata una modifica è una bozza. La verifica sotto ogni prompt è la prova, e nessuna richiede di leggere codice. Quando una verifica fallisce, la correzione torna allo strumento di IA e la lezione viene inserita in un file di regole per il tuo strumento di IA, così la sessione successiva parte da lì. Ogni prompt chiede anche allo strumento di segnalare le incertezze; un assistente che ammette una lacuna è più utile di uno che sembra sicuro. Eseguili sul codice e su record fittizi, mai con record reali o password incollati nella chat.

Trova i campi dei dipendenti usati dallo strumento, poi blocca gli altri

Non puoi bloccare un campo che non sai essere presente nello strumento, quindi il primo prompt è un audit:

Esamina il database, il codice, le schermate e le esportazioni di questa app. Elenca ogni campo che potrebbe contenere dati personali di un dipendente o candidato: nomi, ID dipendente, SSN o numeri di identificazione nazionale, codici fiscali, date di nascita, indirizzi di casa, informazioni sanitarie, stato di disabilità, record degli accomodamenti lavorativi, documenti di immigrazione o autorizzazione al lavoro, stipendio, bonus, partecipazioni azionarie, valutazioni delle prestazioni e note disciplinari. Per ogni campo, dimmi quale schermata o funzionalità lo utilizza e se serve alla funzione principale dell'app. Se non riesci a determinarlo, segnalalo come incerto anziché indovinare.

Verifica: apri le schermate principali e le esportazioni dello strumento e assicurati che ogni campo di dati personali visibile compaia nell'elenco. Un campo che vedi ma che non è menzionato significa che l'audit ha trascurato qualcosa: chiedi di nuovo.

Il secondo prompt elimina ciò che non serve allo strumento. Si basa su un account del database (l'account con cui l'app comunica con il database), che può essere limitato a campi specifici.

Modifica questa app affinché legga solo questi campi: [elenca i campi necessari allo strumento]. Rimuovi ogni altro campo di dati personali dalla copia dei dati dell'app, dal codice, da ogni schermata e da ogni esportazione. Poi crea un account del database separato per l'app, che possa leggere solo quei campi e modificare solo i dati scritti dallo strumento stesso, come le richieste di assenza. Configura l'app per usare quell'account. Descrivi esattamente cosa hai modificato, file per file, e dimmi tutto ciò che non hai potuto fare.

Modificare soltanto le schermate non basta. Se l'account del database dell'app non può leggere la colonna dello stipendio, nemmeno un bug altrove nel codice scritto dall'IA può mostrarla. La cifratura dei dati a riposo è una questione per l'IT, perché dipende dalla configurazione del server e del disco, che un assistente che legge il codice non può vedere in modo affidabile.

Verifica: accedi come utente normale e apri ogni schermata e ogni esportazione; nessuno dei campi rimossi deve apparire. Poi chiedi al supporto IT che gestisce il server (o allo strumento di IA, con l'output mostrato a te) di richiedere un campo rimosso usando l'account del database dell'app. Un errore di autorizzazione negata o che segnali l'inesistenza del campo indica il superamento della verifica. Un errore di connessione, sintassi o altro non pertinente non basta. Una colonna vuota o un valore effettivo indicano un fallimento. Conserva l'elenco dell'audit, perché lo strumento di cancellazione lo usa.

Offri viste diverse ad amministratori HR, responsabili e dipendenti

È qui che i dati dei dipendenti trapelano all'interno, al collega che apre lo stipendio di un altro o la nota sugli accomodamenti lavorativi di un compagno di team. Il controllo degli accessi basato sui ruoli risolve il problema e il prompt seguente specifica dove deve avvenire la verifica:

Aggiungi un controllo degli accessi basato sui ruoli con tre ruoli, verificati sul server per ogni richiesta, non solo nascondendo pulsanti o link nella pagina.

- Amministratore HR: può leggere e modificare tutti i record dei dipendenti.

- Responsabile: può leggere soltanto i record dei propri riporti diretti e non vede mai i campi relativi a stipendio, salute, accomodamenti lavorativi, disciplina o immigrazione.

- Dipendente: può leggere soltanto il proprio record.

Rifiuta tutto il resto con una risposta «accesso negato» (403). Ricava il ruolo di ogni utente dal suo account autenticato, mai da qualcosa che possa digitare o modificare nella pagina o nella barra degli indirizzi. Elenca ogni punto in cui hai aggiunto una verifica e segnala le pagine o esportazioni di cui non sei sicuro della copertura.

Alcune aziende consentono ai responsabili di vedere gli stipendi durante le revisioni retributive; se la tua lo consente, modifica la riga del responsabile.

Verifica: crea un responsabile e un dipendente di prova. Accedendo come responsabile, apri il record di un riporto diretto, copia il suo indirizzo, modifica il numero del record con quello di una persona esterna al team e caricalo: devi ricevere «accesso negato». Ripeti come dipendente con il numero del record di un collega. Poi conferma che la vista del responsabile non mostri mai i campi di stipendio, accomodamenti lavorativi o immigrazione.

Togli le credenziali dal codice e dalla chat

Una password del database o un token API dell'HRIS o del sistema paghe (la lunga chiave con cui un sistema accede a un altro) può essere eliminata dal codice attuale e restare nelle versioni precedenti salvate del progetto: per questo il prompt chiede anche della cronologia. Una variabile d'ambiente risolve la parte relativa al codice. È un valore che il server passa all'app all'avvio, così il codice lo richiama per nome senza contenerlo.

Trova ogni password, chiave API, token di accesso e stringa di connessione al database in questo progetto, inclusi quelli dei nostri sistemi HRIS, paghe o email. Sostituisci ciascuno nel codice con una variabile d'ambiente e forniscimi l'elenco dei nomi delle variabili. Assicurati che i file con i valori reali, come .env, siano esclusi dal repository del codice. Poi elenca ogni punto in cui un vecchio valore appare ancora nella cronologia del progetto, così so quali credenziali sostituire.

Il prompt non può svolgere il passaggio più importante. Nella console di amministrazione dell'HRIS o del database, emetti una nuova credenziale per ciascuna apparsa almeno una volta in una chat o nel repository e disattiva quella vecchia.

Le copie di queste password del team devono stare in un gestore di password, come un server Vaultwarden self-hosted (quale opzione sia adatta a un team è una decisione separata). Conserva le credenziali per le persone e non alimenta un'app in esecuzione, che riceve i suoi valori dallo strumento di distribuzione. Per i segreti letti dall'app stessa in esecuzione, HashiCorp Vault è l'opzione più impegnativa, con policy centralizzate e rotazione per i team che ne hanno bisogno.

Verifica: chiedi allo strumento di IA di cercare i vecchi valori nei file attuali e leggi i risultati che ti mostra, non il loro riepilogo. Nei file attuali non devono esserci corrispondenze. Quelle nella cronologia sono previste e non devono essere ripulite: costituiscono l'elenco delle credenziali da sostituire. La prova che ciascuna non funziona più è nella console di amministrazione dell'HRIS o del database: ogni vecchia credenziale risulta revocata, oppure l'IT conferma che il sistema la rifiuta.

Controlla quali dati dei dipendenti escono dallo strumento

Una volta che una chiamata ha inviato le note del colloquio di un candidato a un servizio esterno, cancellare il record nel tuo strumento non raggiunge la copia che quel servizio potrebbe conservare. La soluzione è quindi inviare meno dati fin dall'inizio.

Verifica ogni chiamata esterna di questa app: a OpenAI, Anthropic o qualsiasi altra API di IA, a sistemi HR come HRIS o ATS, a strumenti di analisi o tracciamento degli errori e a qualsiasi webhook. Per ogni chiamata elenca esattamente quali campi dei dipendenti o candidati sono inclusi nei dati inviati. Segnala ogni servizio che potrebbe memorizzare o registrare ciò che riceve e dimmi quali chiamate potrebbero funzionare con meno dati. Indica tutto ciò di cui non sei sicuro.

Verifica: crea un dipendente o candidato fittizio con un nome inventato e riconoscibile, poi usa ogni funzione che esegue una chiamata esterna (genera il riepilogo del colloquio, attiva il webhook, apri la pagina che carica lo script di analisi). Apri il dashboard di ciascun servizio esterno, come lo strumento di analisi, il sistema di tracciamento degli errori, il registro dei webhook ricevuti dall'ATS o il registro di utilizzo del fornitore di IA dove mostra le richieste, e cerca quel nome. Deve comparire solo dove la chiamata lo richiede. Se compare altrove, rimanda la chiamata allo strumento di IA con meno dati e ripeti la verifica. Alcuni dashboard non mostrano ciò che hanno ricevuto. Per questi, e per qualsiasi servizio che debba continuare a ricevere dati dei dipendenti, porta le condizioni di conservazione dei dati alla persona che firma i contratti con i fornitori nella tua azienda.

Registra chi ha aperto ciascun record dei dipendenti

Un dipendente chiede chi ha esportato il foglio degli stipendi lo scorso trimestre. Senza un registro di audit (una registrazione continua di chi ha fatto cosa su quale record), nessuno può rispondere.

Aggiungi un registro di audit. Ogni volta che un utente visualizza, modifica, esporta o cancella il record di un dipendente, aggiungi una riga con l'ID dell'utente, l'ID del record del dipendente, l'azione, i campi modificati e l'ora. Configura il database affinché l'account del database dell'app possa aggiungere righe al registro ma non modificarle né cancellarle. Solo gli amministratori HR possono leggere il registro nell'app. Dimmi come e dove viene applicata la regola che vieta modifiche e cancellazioni.

La proprietà «solo aggiunta» deve derivare dai permessi dell'account del database, non dalla promessa dell'app di comportarsi correttamente. Il registro contiene a sua volta dati personali, perché mostra chi ha consultato i record di chi: per questo lo leggono solo gli amministratori HR.

Verifica: come amministratore HR apri un record, poi visualizza il registro e conferma che la voce sia presente. Chiedi all'IT o allo strumento di IA (con l'output mostrato a te) di provare a cancellare una riga del registro usando l'account del database dell'app; devi vedere l'errore di autorizzazione stesso.

Gestisci le richieste di cancellazione senza violare gli obblighi di conservazione

Cosa succede quando un dipendente chiede la cancellazione e alcuni suoi record sono documenti delle paghe che l'azienda deve conservare? Il prompt ovvio («cancella tutti i dati personali di questo dipendente da ogni tabella») li cancella comunque e causa due problemi. I datori di lavoro devono spesso conservare alcuni record, come quelli relativi a paghe, imposte e autorizzazioni al lavoro, e il diritto alla cancellazione del GDPR non si applica nella misura in cui il trattamento è necessario per adempiere a un obbligo legale o per pretese giuridiche (articolo 17(3)(b) ed (e)). Anche lasciare disponibile un pulsante che cancella tutto è pericoloso. La versione più sicura separa «cancella su richiesta» dai record soggetti a conservazione obbligatoria, cioè quelli che l'azienda deve tenere indipendentemente dalla richiesta, e mostra il piano prima di cancellare qualcosa:

Crea uno strumento per le richieste di cancellazione che possano aprire solo gli amministratori HR. Dato un ID dipendente, mostra prima ogni tabella e campo che contiene i dati di quella persona, raggruppati nelle categorie dell'audit dei campi. Ogni categoria ha un'impostazione di conservazione definita da un amministratore HR: «cancella su richiesta» o «conserva: conservazione obbligatoria». Dopo la conferma di un amministratore HR, lo strumento cancella solo le categorie impostate su «cancella su richiesta». Registra soltanto l'ID dipendente, l'ora, chi ha confermato e quali categorie sono state cancellate o conservate, e nient'altro sulla persona. Chi non è amministratore HR riceve «accesso negato».

Le impostazioni di conservazione vengono dal responsabile della conformità o dal DPO, non dallo strumento di IA o dalla migliore ipotesi del creatore. Segnala loro che il registro di audit conserva l'ID dipendente dopo una cancellazione, così possono decidere quanto a lungo debba restare. I backup e le copie conservate dai servizi esterni richiedono processi propri di conservazione o cancellazione.

Verifica: crea un dipendente di prova con record in due categorie, una impostata su «cancella su richiesta» e una su conservazione obbligatoria. Esegui lo strumento come amministratore HR e conferma che sia sparita soltanto la prima categoria. Poi aprilo con un account responsabile e attenditi «accesso negato».

Norme sul lavoro da discutere con il DPO o il responsabile della conformità

Le norme sul lavoro applicabili a uno strumento HR dipendono da ciò che fa e dalle persone i cui dati contiene, non da come è stato creato. Questo è un elenco di norme da discutere con il DPO o il responsabile della conformità, non una consulenza legale, e non determina se qualcuna si applichi a te.

Un registro delle assenze con note sugli accomodamenti lavorativi del personale in Germania e California è soggetto a norme diverse da quelle di un pianificatore dell'organico che contiene soltanto titoli professionali. La questione dell'AI Act dell'UE rientra nella verifica sulle decisioni di assunzione.

La posizione del server determina dove risiedono fisicamente i record; da sola non soddisfa nessuna delle norme precedenti. Per il personale fuori da questi luoghi, parti dall'autorità nazionale, statale o locale competente in materia di privacy o lavoro, oppure dal responsabile legale o della conformità.

L'accesso termina quando termina il rapporto di lavoro

Quando l'account aziendale di una persona viene disattivato nel suo ultimo giorno, email, calendario e file diventano inaccessibili in un solo passaggio. Anche lo strumento HR dovrebbe chiudersi nello stesso passaggio e, dietro l'accesso aziendale, può farlo, purché l'offboarding revochi anche le sessioni attive. Qualsiasi strumento privo di accesso aziendale deve avere una voce propria nella checklist di offboarding, così qualcuno rimuove quell'account manualmente.

Anche il creatore prima o poi lascerà l'azienda. Quando la persona che ha creato lo strumento se ne va o cambia ruolo, la responsabilità passa a un successore identificato, che può accedere come amministratore e sa dove si trova il server, e l'account amministratore del creatore viene chiuso. Io nominerei quel successore prima della messa in produzione, perché il periodo di preavviso è un pessimo momento per cercarne uno.

Verifica secondo una cadenza stabilita chi detiene ogni ruolo e se lo strumento è ancora in uso. Quando occorre ampliare l'accesso, fallo un livello alla volta (prima il team HR, poi i responsabili, infine ogni dipendente) e ripeti la prova della barra degli indirizzi a ogni livello. Quando lo strumento non viene più usato, dismettilo: disattiva il suo account del database e le credenziali, cancella i dati secondo le impostazioni di conservazione dello strumento di cancellazione, arrestalo e rimuovilo dalla rete privata o dal sistema di accesso.

Il successore identificato eredita un server che qualcuno ha dovuto configurare, con uno strumento di distribuzione, una rete privata e, per un accesso più ampio, un accesso aziendale. Il nostro VPS Linux offre accesso root e Coolify, Tailscale e Authentik si distribuiscono ciascuno come app con un clic, così il supporto IT può dedicare le proprie ore alle verifiche. Le località includono Francoforte e Amsterdam nell'UE, Londra nel Regno Unito e diverse città degli USA. Questo stabilisce in quale paese si trova il server: un elemento per la conversazione con il DPO, non un sostituto.

La checklist per la messa in produzione

Ogni voce seguente è completata oppure no prima che vengano inseriti record dei dipendenti: questa è la lista da consegnare a chi configura il server.

1. La domanda sulle decisioni di assunzione ha una risposta e ogni «sì» è stato trasmesso all'IT e all'ufficio legale.
2. Lo strumento gira su un server controllato dal team, non sull'hosting dello strumento di IA.
3. È raggiungibile soltanto sulla rete privata o tramite accesso aziendale.
4. L'account del database dell'app legge soltanto i campi elencati.
5. Un responsabile e un dipendente di prova ricevono entrambi «accesso negato» nella prova della barra degli indirizzi.
6. Ogni credenziale apparsa in una chat o nel codice è stata sostituita e quella vecchia revocata.
7. L'audit dei dati in uscita è completato e i campi non necessari sono stati rimossi.
8. Il registro di audit registra le visualizzazioni e l'account dell'app non può modificarlo né cancellarlo.
9. Le impostazioni di conservazione e le norme sul lavoro sono state esaminate dal DPO o dal responsabile della conformità.
10. Esistono un responsabile identificato e un sostituto identificato.

Domande frequenti

Che cos'è la Shadow AI nelle risorse umane?

La Shadow AI nelle risorse umane è l'uso di strumenti di IA, o app create con essi, sui dati HR senza che l'IT ne sia a conoscenza o abbia dato l'approvazione. La Sapient Insights 2026 Annual HR Systems Survey, secondo quanto riportato da Cornerstone OnDemand, ha rilevato che oltre l'80% dei professionisti HR usa quotidianamente strumenti personali di IA, mentre il 3% utilizza l'IA integrata nei propri sistemi HR.

Posso usare record reali dei dipendenti durante la creazione dello strumento?

No. Tieni i record reali fuori dalla chat mentre crei uno strumento HR tramite vibe coding. Incollarli in un assistente di chat è un rischio distinto dalla distribuzione dell'app e si manifesta nel momento dell'incolla, indipendentemente dal fatto che lo strumento venga mai pubblicato. Sviluppa su record fittizi finché lo strumento non gira su un server controllato dal team.

I dipendenti devono acconsentire all'uso dei loro dati da parte di uno strumento HR?

Di solito il consenso è la base sbagliata. Le linee guida sul consenso dell'EDPB dichiarano che «ritiene problematico che i datori di lavoro trattino dati personali di dipendenti attuali o futuri sulla base del consenso, poiché è improbabile che sia prestato liberamente». Quale base giuridica si applichi ai sensi dell'articolo 6 del GDPR è una domanda per il DPO.

HIPAA copre le note mediche in uno strumento HR?

Di solito no. La definizione di informazioni sanitarie protette di HIPAA esclude le informazioni nei record lavorativi detenuti da un'entità soggetta alla normativa nel suo ruolo di datore di lavoro (45 CFR 160.103). Questo non rende quelle note prive di regolamentazione, quindi chiedi al responsabile della conformità quali norme le coprono.