Sådan kan HR-teams udrulle apps bygget med AI uden at eksponere medarbejderdata

Sikkerhedsfirmaet RedAccess ledte efter apps bygget med AI-kodningsværktøjer og publiceret på værktøjernes egen hosting og fandt mere end 5.000 med stort set ingen sikkerhed eller autentificering. Blandt de skærmbilleder, firmaet delte med Wired, var noget, der lignede et hospitals arbejdsfordeling, inklusive lægernes personlige oplysninger.

At bygge er den del, AI-kodningsværktøjer har gjort nem. Eksponeringen i apps bygget med AI til HR-teams kommer senere, når en fraværsoversigt eller et vurderingsskema til jobsamtaler går live, som det blev demonstreret: et offentligt link, én administratorkonto og hele medarbejdertabellen bagved.

TL;DR

• Et værktøj, der hjælper med at bestemme, hvem der ansættes eller forfremmes, eller hvordan personer vurderes, kan være højrisiko under EU's AI-forordning. Det skal til IT og den juridiske afdeling eller DPO'en, før det giver nogen en score.
• Medarbejderoplysninger må aldrig ligge på AI-kodningsværktøjets egen hosting. Standardvalget er en server, som teamet kontrollerer, kun tilgængelig på et privat netværk, med virksomhedens login foran, når ledere eller alle medarbejdere har brug for adgang.
• Rettelserne går gennem det samme AI-værktøj, som byggede appen: begræns de felter, den læser, giv HR-administratorer, ledere og medarbejdere forskellige visninger, flyt legitimationsoplysninger ud af koden, reducer eksterne dataoverførsler, log hvem der åbner hvilke oplysninger, og håndter sletteanmodninger under hensyn til opbevaringskrav. En kontrol, du selv udfører, bekræfter hver rettelse; AI'ens egen rapport gør ikke.
• Adgang til værktøjet bør slutte den dag, ansættelsen slutter, én navngiven person bør være ansvarlig, og valget af serverplacering sikrer ikke i sig selv regeloverholdelse.

Udrulningsfejl, der eksponerer medarbejderdata

Et HR-værktøj bygget med AI eksponerer medarbejderdata for enhver, der finder linket, enhver med legitimationsoplysninger indsat i en chat eller koden, kolleger, der åbner andres oplysninger, eksterne tjenester, som modtager data, og personer, der er fratrådt, uden at registrere, hvem der har kigget. At læse hele medarbejdertabellen udvider hver eksponeringsvej.

Den første række er det problem, RedAccess fandt i stor skala. I Wireds artikel om RedAccess' resultater afviste tre af de fire AI-kodningsvirksomheder forskernes påstande (den fjerde svarede ikke), men de benægtede ikke, at de vibe-kodede apps, som RedAccess fandt, var efterladt ubeskyttede. Jeg ser det som et konfigurationsproblem og en sprunget kontrol.

Kontrollér, om værktøjet hjælper med at bestemme, hvem der ansættes, forfremmes eller vurderes

At være bygget med et AI-kodningsværktøj gør ikke i sig selv et HR-værktøj til højrisiko under EU's AI-forordning. Det afgøres af, hvad værktøjet gør. Bilag III til EU's AI-forordning opregner AI-systemer, der bruges til at rekruttere eller udvælge personer og træffe beslutninger om forfremmelse, afskedigelse, opgavefordeling eller overvågning og vurdering af præstationer.

Før du beslutter, hvor værktøjet skal køre, så stil ét spørgsmål: træffer eller påvirker det en beslutning om, hvem der ansættes, forfremmes, afskediges, tildeles arbejde eller præstationsvurderes?

En fraværsoversigt, en onboarding-tjekliste eller en organisationsoversigt gemmer oplysninger og viser dem igen og ligger derfor på ‘nej’-siden. Et vurderingsskema til samtaler, der rangerer kandidater, eller et præstationsværktøj, der giver personer point (især med en AI-model til at beregne dem), kan ligge på ‘ja’-siden. Når jeg ikke kan afgøre, hvilken side et værktøj ligger på, behandler jeg det som et ja og lader IT og den juridiske afdeling sige noget andet.

Forordningen er ikke begrænset til EU-virksomheder: artikel 2 dækker udbydere og idriftsættere uden for EU, når deres AI-systems output bruges i EU. Ifølge artikel 113 som ændret gælder forpligtelserne for højrisikosystemer i bilag III fra 2. december 2027. De omfatter risikostyringssystem, datastyring, teknisk dokumentation, registrering, gennemsigtighed over for idriftsættere og menneskeligt tilsyn (artikel 9 til 14), og vurderingen tilhører IT og den juridiske afdeling.

Er svaret ja, så stop, før værktøjet giver en eneste rigtig kandidat eller medarbejder en score. Tag det til IT og din ansvarlige for jura eller databeskyttelse (DPO'en, hvis der er en). Kontrollen afgør ikke, om et bestemt værktøj er omfattet; den fortæller, hvem der skal afgøre det. Nogle amerikanske stater regulerer også automatiserede ansættelsesbeslutninger, og de regler står i tabellen længere nede.

Du kan give den vurdering et forspring. Jeg ville bede AI-værktøjet argumentere imod sin egen scoring frem for at forsvare den:

Denne app giver jobkandidater eller medarbejdere point eller rangerer dem. Oplist hvert datafelt og hvert beregningstrin, der indgår i scoren eller rangeringen. Fortæl for hvert, om det direkte eller indirekte kan afspejle en beskyttet egenskab: alder, race, køn, nationalitet, etnisk oprindelse, handicap, graviditet, religion eller seksuel orientering. Sig til, når du er usikker, frem for at gætte. Påpeg derefter alt om retfærdigheden i denne scoring, som jeg ikke har spurgt om, men burde have spurgt om.

Kontrol: behandl svaret som en startliste til dem, der vurderer værktøjet, ikke som en afgørelse, og aflever den sammen med selve værktøjet. At køre denne prompt er ikke en bias-revision og opfylder ikke noget lovkrav.

Hvor et HR-værktøj bør køre

Hold medarbejderoplysninger væk fra AI-værktøjets egen hosting. For et værktøj, som kun HR-teamet bruger, er standarden en server, teamet kontrollerer, kun tilgængelig på et privat netværk, med virksomhedslogin foran, når ledere eller medarbejdere har brug for det. Et værktøj, der ikke bestod kontrollen om ansættelsesbeslutninger, eller hvor ingen kan være ansvarlig for serveren, går til IT.

Publicering på et AI-kodningsværktøjs egen hosting placerer appen på en adresse på leverandørens domæne. Medmindre synligheden er sat til privat, kan alle, der finder adressen, nå den. RedAccess fandt tusindvis af sådanne apps med almindelige Google- og Bing-søgninger efter de domæner. Et privat netværk virker modsat, fordi værktøjet kun svarer enheder, som er tilsluttet det. Virksomhedslogin (single sign-on) betyder, at kolleger åbner værktøjet med den virksomhedskonto, de allerede bruger, kontrolleret af en identitetsudbyder, tjenesten som administrerer de konti.

Indtil værktøjet kører på teamets egen server, skal du bygge og teste det med syntetiske data: opdigtede navne, lønninger og fraværsdatoer formet som rigtige oplysninger. En gratis tunnel fra en bærbar til en offentlig adresse er offentlig på samme måde som leverandørens hosting og hører derfor også til demofasen.

Hvorfor et privat netværk og ikke den login-side, appen allerede har? Et privat netværk betyder, at værktøjet slet ikke svarer udefra, så ingen udenfor kan indlæse det, undersøge det eller gætte kodeord. En login-side skrevet af AI-værktøjet er ikke nok alene. Alle kan nå den, og den er kun så sikker som den genererede kode bagved. Veracodes rapport om GenAI-kodesikkerhed fra 2025 fandt, at 45% af de testede kodeeksempler fra mere end 100 modeller ikke bestod sikkerhedstestene på grund af en OWASP Top 10-sårbarhed (en risiko fra en meget brugt liste over de mest kritiske sikkerhedsrisici for webapplikationer). Derfor vil jeg hellere sætte en lås foran appen end stole på den, AI'en skrev.

Ved overdragelsen kører værktøjet på en VPS (en lejet server, teamet kontrollerer fuldt ud) under et udrulningsværktøj som Coolify eller Dokku, der kører appen fra koden; Coolify kan også rulle en dårlig opdatering tilbage til en tidligere version fra sit dashboard. Valget mellem Coolify og Dokku handler især om, hvor mange apps serveren skal køre, og om IT-hjælpen foretrækker et dashboard. Det private netværk kommer fra Tailscale eller WireGuard. Tailscale er hurtigere at sætte op, men koordinationstjenesten drives af Tailscale, mens WireGuard er helt selvhostet. Virksomhedslogin kommer fra en identitetsudbyder som Authentik eller Keycloak. En reverse proxy som Caddy eller Nginx Proxy Manager tilføjer HTTPS, hvor login vender ud mod nettet. Denne del skal overdrages til IT-hjælpen sammen med tjeklisten til sidst.

Rettelserne som prompts til dit eget AI-værktøj

Det meste arbejde med at udrulle en HR-app bygget med AI sikkert går gennem værktøjet, der byggede den, men kun når det bliver bedt om det. Som sikkerhedsforskeren Joel Margolis sagde til Wired, gør AI-kodningsværktøjer ‘det, du beder dem om. Og medmindre du beder dem gøre det sikkert, vil de ikke gøre en ekstra indsats for det.’

Behandl hver prompt nedenfor som et udgangspunkt, og tilpas feltnavne og roller til dit værktøj. Jeg ser AI-værktøjet som udvikleren og mig selv som kontrollanten, så rapporten om en færdig ændring er et udkast. Kontrollen under hver prompt er beviset, og ingen kræver, at du læser kode. Når en kontrol fejler, går rettelsen tilbage til AI-værktøjet, og læringen skrives i en regelfil til dit AI-værktøj, så næste session starter derfra. Hver prompt beder også værktøjet markere sin usikkerhed; en assistent, der indrømmer en mangel, er mere nyttig end en, der lyder sikker. Kør dem mod koden og fiktive oplysninger, aldrig med rigtige oplysninger eller kodeord indsat i chatten.

Find de medarbejderfelter, værktøjet bruger, og blokér resten

Du kan ikke blokere et felt, du ikke ved, at værktøjet indeholder, så den første prompt er en gennemgang:

Gennemgå denne apps database, kode, skærmbilleder og eksport. Oplist hvert felt, der kan indeholde personoplysninger om en medarbejder eller kandidat: navne, medarbejder-ID'er, SSN'er eller nationale identifikationsnumre, skatte-ID'er, fødselsdatoer, hjemmeadresser, helbredsoplysninger, handicapstatus, oplysninger om arbejdspladstilpasninger, immigrations- eller arbejdstilladelsesdokumenter, løn, bonus, ejerandele, præstationsvurderinger og disciplinære noter. Fortæl for hvert felt, hvilken skærm eller funktion der bruger det, og om appens hovedopgave behøver det. Markér det som usikkert, hvis du ikke kan afgøre det, frem for at gætte.

Kontrol: åbn værktøjets hovedskærme og eksport, og sørg for, at hvert synligt felt med personoplysninger er på listen. Et synligt felt, som listen ikke nævner, betyder, at gennemgangen overså noget. Spørg igen.

Den anden prompt fjerner, hvad værktøjet ikke behøver. Den bruger en databasekonto (den konto, appen bruger til at tale med databasen), som kan begrænses til bestemte felter.

Ændr denne app, så den kun læser disse felter: [oplist felterne, værktøjet behøver]. Fjern alle andre felter med personoplysninger fra appens datakopi, koden, hver skærm og hver eksport. Opret derefter en separat databasekonto til appen, som kun kan læse disse felter og kun ændre de data, værktøjet selv skriver, såsom fraværsanmodninger. Skift appen til denne konto. Rapportér præcis, hvad du ændrede, fil for fil, og alt, du ikke kunne udføre.

At ændre skærmene alene er ikke nok. Hvis appens databasekonto ikke kan læse lønkolonnen, kan en fejl et andet sted i den AI-skrevne kode heller ikke vise den. Om data er krypteret i hvile, er et spørgsmål til IT, fordi det afhænger af server- og diskkonfigurationen, som en assistent, der læser kode, ikke pålideligt kan se.

Kontrol: log ind som almindelig bruger, og åbn hver skærm og eksport; ingen fjernede felter må vises. Bed derefter IT-hjælpen, der administrerer serveren (eller AI-værktøjet med output vist til dig), om at forespørge et fjernet felt via appens databasekonto. En fejl om manglende tilladelse eller et ikkeeksisterende felt er bestået. En forbindelses-, syntaks- eller anden uvedkommende fejl er ikke. En tom kolonne eller en faktisk værdi er ikke bestået. Gem listen fra gennemgangen, fordi sletteværktøjet bruger den.

Giv HR-administratorer, ledere og medarbejdere forskellige visninger

Her lækker medarbejderdata internt til kollegaen, der åbner en andens løn eller en teamkollegas note om arbejdspladstilpasninger. Rollebaseret adgangskontrol løser det, og følgende prompt beskriver, hvor kontrollen skal ske:

Tilføj rollebaseret adgangskontrol med tre roller, kontrolleret på serveren for hver anmodning, ikke kun ved at skjule knapper eller links på siden.

- HR-administrator: kan læse og redigere alle medarbejderoplysninger.

- Personaleleder: kan kun læse oplysninger om sine direkte underordnede og ser aldrig felter om løn, helbred, arbejdspladstilpasninger, disciplinære forhold eller immigration.

- Medarbejder: kan kun læse sine egne oplysninger.

Afvis alt andet med svaret ‘adgang nægtet’ (403). Hent hver brugers rolle fra den konto, vedkommende er logget ind med, aldrig fra noget, brugeren kan skrive eller ændre på siden eller i adresselinjen. Oplist alle steder, hvor du tilføjede en kontrol, og markér sider eller eksport, som du er usikker på er dækket.

Nogle virksomheder lader ledere se løn under lønvurderinger. Hvis din gør, skal du ændre lederens linje.

Kontrol: opret en testleder og en testmedarbejder. Log ind som lederen, åbn en direkte underordnets oplysninger, kopiér adressen, ændr postens nummer til nummeret på en person uden for teamet, og indlæs: du bør få ‘adgang nægtet’. Gentag som medarbejder med nummeret på en kollegas post. Bekræft derefter, at ledervisningen aldrig viser felter om løn, arbejdspladstilpasninger eller immigration.

Få legitimationsoplysninger ud af koden og chatten

Et databasekodeord eller et API-token til HRIS eller lønsystemet (den lange nøgle, et system bruger til at logge ind i et andet) kan være fjernet fra dagens kode og stadig ligge i tidligere gemte projektversioner. Derfor spørger prompten også til historikken. En miljøvariabel løser kodedelen. Det er en værdi, serveren giver appen ved start, så koden henviser til den ved navn uden at indeholde den.

Find alle kodeord, API-nøgler, adgangstokens og databaseforbindelsesstrenge i dette projekt, inklusive til vores HRIS-, løn- eller mailsystemer. Udskift hver værdi i koden med en miljøvariabel, og giv mig listen over variabelnavne. Sørg for, at filer med de faktiske værdier, såsom .env, er udelukket fra kodearkivet. Oplist derefter hvert sted, hvor en gammel værdi stadig findes i projekthistorikken, så jeg ved, hvilke legitimationsoplysninger der skal udskiftes.

Prompten kan ikke udføre det vigtigste trin. Udsted nye legitimationsoplysninger i HRIS'ets eller databasens administrationskonsol for alle, der nogensinde stod i en chat eller kodearkivet, og deaktivér de gamle.

Teamets egne kopier af kodeordene hører til i en adgangskodeadministrator, såsom en selvhostet Vaultwarden-server (hvilken løsning der passer til et team er en særskilt beslutning). Den gemmer legitimationsoplysninger til personer og forsyner ikke en kørende app, som får sine værdier fra udrulningsværktøjet. Til hemmeligheder, den kørende app selv læser, er HashiCorp Vault den mere omfattende løsning med centrale politikker og rotation til teams, der behøver det.

Kontrol: bed AI-værktøjet søge de aktuelle filer efter de gamle værdier, og læs søgeresultaterne, ikke dets opsummering. De aktuelle filer må ikke have nogen træffere. Træffere i historikken er forventelige og behøver ikke fjernes; de er listen over legitimationsoplysninger, der skal udskiftes. Beviset for, at hver gammel adgang er lukket, er i HRIS'ets eller databasens administrationskonsol: alle gamle legitimationsoplysninger vises som tilbagekaldt, eller IT bekræfter, at systemet afviser dem.

Se, hvilke medarbejderdata der forlader værktøjet

Når et kald har sendt en kandidats samtalenoter til en ekstern tjeneste, når sletning i dit eget værktøj ikke den kopi, tjenesten måske gemmer. Løsningen er derfor at sende mindre fra starten.

Gennemgå hvert eksternt kald fra denne app: til OpenAI, Anthropic eller en anden AI-API, til HR-systemer som HRIS eller ATS, til analyse- eller fejlsporingsværktøjer og til enhver webhook. Oplist for hvert kald præcis, hvilke medarbejder- eller kandidatfelter der indgår i det sendte. Markér tjenester, som måske gemmer eller logger det modtagne, og fortæl, hvilke kald der kan fungere med færre data. Markér alt, du er usikker på.

Kontrol: opret en fiktiv medarbejder eller kandidat med et karakteristisk opdigtet navn, og brug hver funktion med et eksternt kald (generér samtaleresuméet, udløs webhooken, åbn siden med analysescriptet). Åbn hver ekstern tjenestes eget dashboard, såsom analyseværktøjet, fejlsporingen, ATS'ets log over modtagne webhooks eller AI-udbyderens brugslog, hvor anmodninger vises, og søg efter navnet. Det må kun dukke op, hvor kaldet behøver det. Hvis det vises andre steder, send kaldet tilbage til AI-værktøjet med færre data, og gentag kontrollen. Nogle dashboards viser ikke det modtagne. For disse og enhver tjeneste, der fortsat skal modtage medarbejderdata, skal du give vilkårene for dataopbevaring til den person, der underskriver leverandørkontrakter i virksomheden.

Registrér, hvem der åbnede hvilke medarbejderoplysninger

En medarbejder spørger, hvem der eksporterede lønarket sidste kvartal. Uden en revisionslog (en løbende registrering af, hvem der gjorde hvad med hvilken post) kan ingen svare.

Tilføj en revisionslog. Hver gang en bruger ser, redigerer, eksporterer eller sletter en medarbejderpost, tilføjes en række med brugerens ID, medarbejderpostens ID, handlingen, ændrede felter og tidspunktet. Konfigurér databasen, så appens databasekonto kan tilføje rækker til loggen, men ikke redigere eller slette dem. Kun HR-administratorer kan læse loggen i appen. Fortæl, hvordan og hvor forbuddet mod redigering og sletning håndhæves.

‘Kun tilføjelse’ skal komme fra databasekontoens rettigheder, ikke fra appens løfte om god opførsel. Loggen er selv persondata, fordi den viser, hvem der så hvilke personers oplysninger. Derfor læser kun HR-administratorer den.

Kontrol: åbn en post som HR-administrator, og se derefter loggen for at bekræfte, at indførslen findes. Lad IT eller AI-værktøjet (med output vist til dig) forsøge at slette en logrække via appens databasekonto; du bør se selve rettighedsfejlen.

Håndtér sletteanmodninger uden at bryde opbevaringsregler

Hvad sker der, når en medarbejder beder om sletning, og nogle oplysninger er lønfiler, virksomheden skal gemme? Den oplagte prompt (‘slet alle personoplysninger for denne medarbejder i alle tabeller’) sletter dem alligevel og skaber to problemer. Arbejdsgivere skal ofte gemme visse oplysninger, eksempelvis løn-, skatte- og arbejdstilladelsesfiler. GDPR's ret til sletning gælder ikke, i det omfang behandlingen er nødvendig for en retlig forpligtelse eller retskrav (artikel 17(3)(b) og (e)). En frit tilgængelig knap til at slette alt er også farlig. Den sikrere version skelner mellem ‘slet på anmodning’ og oplysninger med opbevaringspligt, som virksomheden skal beholde uanset anmodningen, og viser planen, før noget slettes:

Byg et værktøj til sletteanmodninger, som kun HR-administratorer kan åbne. Ved et medarbejder-ID viser det først alle tabeller og felter med personens data, grupperet efter kategorierne fra feltgennemgangen. Hver kategori har en opbevaringsindstilling fastsat af en HR-administrator: ‘slet på anmodning’ eller ‘behold: påkrævet opbevaring’. Efter en HR-administrators bekræftelse sletter værktøjet kun kategorier sat til ‘slet på anmodning’. Det logger kun medarbejder-ID, tidspunkt, hvem der bekræftede, og slettede eller bevarede kategorier, intet andet om personen. Alle, som ikke er HR-administratorer, får ‘adgang nægtet’.

Opbevaringsindstillingerne kommer fra din ansvarlige for regeloverholdelse eller DPO, ikke AI-værktøjet eller udviklerens bedste gæt. Fortæl, at revisionsloggen beholder medarbejder-ID'et efter en sletning, så de kan afgøre, hvor længe identifikatoren skal blive. Backups og kopier hos eksterne tjenester behøver egne opbevarings- eller sletteprocesser.

Kontrol: opret en testmedarbejder med poster i to kategorier, én sat til ‘slet på anmodning’ og én med opbevaringspligt. Kør værktøjet som HR-administrator, og bekræft, at kun den første kategori er væk. Åbn derefter værktøjet med en lederkonto, og forvent ‘adgang nægtet’.

Ansættelsesregler at tage op med din DPO eller ansvarlige for regeloverholdelse

Ansættelsesreglerne for et HR-værktøj afhænger af dets funktion og de personer, hvis data det indeholder, ikke af hvordan det blev bygget. Dette er en liste over regler til drøftelse med din DPO eller ansvarlige for regeloverholdelse, ikke juridisk rådgivning. Den afgør ikke, om nogen gælder for dig.

En fraværsoversigt med noter om arbejdspladstilpasninger for ansatte i Tyskland og Californien følger andre regler end en personaleplanlægger med kun stillingsbetegnelser. Spørgsmålet om EU's AI-forordning hører til kontrollen om ansættelsesbeslutninger.

Serverplaceringen afgør, hvor oplysningerne fysisk ligger; den opfylder ikke alene nogen af reglerne ovenfor. For medarbejdere uden for de områder bør du starte hos den relevante nationale, delstatslige eller lokale privatlivs- eller arbejdsmyndighed eller din ansvarlige for jura eller regeloverholdelse.

Adgang slutter, når ansættelsen slutter

Når en fratrådts virksomhedskonto deaktiveres på sidste arbejdsdag, lukkes mail, kalender og filer i ét trin. HR-værktøjet bør lukke i samme trin. Bag virksomhedslogin kan det ske, så længe fratrædelsen også tilbagekalder aktive sessioner. Alle værktøjer uden det login får deres egen linje på fratrædelsestjeklisten, så nogen fjerner kontoen manuelt.

Udvikleren fratræder også en dag. Når personen, der byggede værktøjet, fratræder eller skifter rolle, går ansvaret til en navngiven efterfølger, som kan logge ind som administrator og ved, hvor serveren er. Udviklerens egen administratorkonto lukkes. Jeg ville udpege efterfølgeren før produktionsstart, fordi en opsigelsesperiode er et dårligt tidspunkt at lede efter en.

Gennemgå efter en fast plan, hvem der har hver rolle, og om værktøjet stadig bruges. Når adgangen skal vokse, så udvid ét niveau ad gangen (HR-teamet, derefter ledere, derefter alle medarbejdere), og gentag adresselinjetesten på hvert niveau. Når værktøjet ikke længere bruges, skal det udfases: deaktivér databasekonto og legitimationsoplysninger, slet data efter sletteværktøjets opbevaringsindstillinger, stop det, og fjern det fra det private netværk eller loginsystemet.

Den navngivne efterfølger overtager en server, nogen måtte opsætte, med et udrulningsværktøj, et privat netværk og ved bredere adgang virksomhedslogin. Vores Linux-VPS giver rootadgang, og Coolify, Tailscale og Authentik udrulles hver som en app med ét klik, så IT-hjælpen kan bruge timerne på kontrollerne. Placeringerne omfatter Frankfurt og Amsterdam i EU, London i Storbritannien og flere amerikanske byer. Det afgør, hvilket land serveren står i, et input til samtalen med DPO'en, ikke en erstatning for den.

Tjeklisten før produktionsstart

Hvert punkt nedenfor er enten udført eller ikke udført, før medarbejderoplysninger indsættes. Dette er listen til den, der opsætter serveren.

1. Spørgsmålet om ansættelsesbeslutninger er besvaret, og hvert ‘ja’ er gået til IT og den juridiske afdeling.
2. Værktøjet kører på en server, teamet kontrollerer, ikke på AI-værktøjets hosting.
3. Det er kun tilgængeligt på det private netværk eller via virksomhedslogin.
4. Appens databasekonto læser kun de oplistede felter.
5. Både en testleder og en testmedarbejder får ‘adgang nægtet’ i adresselinjetesten.
6. Alle legitimationsoplysninger, der var i en chat eller koden, er udskiftet, og de gamle tilbagekaldt.
7. Gennemgangen af udgående data er færdig, og unødvendige felter er fjernet.
8. Revisionsloggen registrerer visninger, og appens konto kan ikke redigere eller slette den.
9. Opbevaringsindstillinger og ansættelsesregler er gennemgået af DPO'en eller den ansvarlige for regeloverholdelse.
10. Der er en navngiven ansvarlig og en navngiven stedfortræder.

Ofte stillede spørgsmål

Hvad er Shadow AI i HR?

Shadow AI i HR er brug af AI-værktøjer eller apps bygget med dem på HR-data uden IT's viden eller godkendelse. Sapient Insights 2026 Annual HR Systems Survey viste ifølge Cornerstone OnDemand, at over 80% af HR-fagfolk bruger personlige AI-værktøjer dagligt, mens 3% bruger den AI, der er indbygget i deres HR-systemer.

Kan jeg bruge rigtige medarbejderoplysninger, mens jeg bygger værktøjet?

Nej. Hold rigtige oplysninger ude af chatten, mens du bygger et vibe-kodet HR-værktøj. At indsætte dem i en chatassistent er en separat risiko fra udrulningen af appen, som opstår i det øjeblik, du indsætter dem, uanset om værktøjet nogensinde går live. Byg med fiktive oplysninger, indtil værktøjet kører på en server, teamet kontrollerer.

Skal medarbejdere give samtykke til, at et HR-værktøj bruger deres data?

Som regel er samtykke det forkerte grundlag. EDPB's retningslinjer om samtykke siger, at det ‘anser det for problematisk, at arbejdsgivere behandler personoplysninger om nuværende eller fremtidige medarbejdere på grundlag af samtykke, fordi det sandsynligvis ikke gives frivilligt’. Hvilket lovligt grundlag der gælder efter GDPR artikel 6, er et spørgsmål til din DPO.

Dækker HIPAA de medicinske noter i et HR-værktøj?

Som regel ikke. HIPAA's definition af beskyttede helbredsoplysninger udelukker oplysninger i ansættelsesregistre hos en omfattet enhed, når denne handler som arbejdsgiver (45 CFR 160.103). Det gør ikke noterne uregulerede. Spørg din ansvarlige for regeloverholdelse, hvilke regler der dækker dem.