AI-værktøjer og datadrevne platforme bruges i stigende grad til at beskrive, klassificere og berige produkter. Det kan spare tid, men det flytter også en del af jeres informationssikkerhed ud til leverandører og automatiserede modeller. Denne artikel giver dig et praktisk overblik over de vigtigste sikkerhedskrav: adgangsstyring, datalagring, retention, GDPR-vinklen (selv når data “bare er produkter”), og hvordan du minimerer risiko, når AI er en del af kæden.
Du får konkrete spørgsmål til leverandørdialogen, typiske faldgruber og en tjekliste, du kan bruge ved indkøb eller genforhandling. Målet er at gøre det let at træffe et valg, der både reducerer risiko og gør hverdagen enklere for drift, jura og forretning.
Hvad betyder sikkerhedskrav i praksis?
En kort definition: Sikkerhedskrav er de tekniske og organisatoriske kontroller, der skal sikre fortrolighed, integritet og tilgængelighed af data og systemer. Det betyder noget, fordi produktdata ofte er forretningskritiske, kan afsløre prisstrategi og leverandørrelationer, og i mange tilfælde kan kobles til personer via logfiler, kundedata eller brugeradfærd.
Selv hvis jeres fokus er PIM, kataloger eller e-commerce, er angrebsfladen typisk bred: API’er, integrationer, dashboards, eksportfiler, og AI-funktioner der sender indhold til eksterne tjenester. Derfor bør du vurdere både teknisk sikkerhed og compliance som en samlet pakke.
Mini-konklusion: Behandl produktdata som en værdifuld informationsaktiver, ikke som “ufarlig tekst”.
Adgangsstyring: hvem kan se hvad, hvornår?
Adgangsstyring er ofte den billigste risikoreduktion. Mange brud starter med for brede rettigheder, delte logins eller manglende offboarding. Kravene bør være klare, før du kigger på pris og features.
RBAC, mindst mulige rettigheder og audit trail
Spørg leverandøren om der findes rollebaseret adgang (RBAC), så marketing, indkøb, eksterne bureauer og leverandører kun ser relevante felter. Least privilege bør være standard, og det skal være nemt at skifte rolle uden at oprette “midlertidige” admin-brugere, der aldrig fjernes.
Audit logs er lige så vigtige: Kan I se hvem der ændrede et produkt, hvornår, og fra hvilken integration? Og kan loggen eksporteres til jeres SIEM eller gemmes til revision? Det er afgørende ved fejl, tvister og hændelser.
MFA, SSO og livscyklus for brugere
Multi-factor authentication bør være obligatorisk for admin og anbefalet for alle. Single Sign-On (SAML/OIDC) gør det lettere at håndhæve password-politik og lukke adgang ved fratrædelse. Et godt tegn er også understøttelse af SCIM eller anden brugerprovisionering, så adgang tildeles og fjernes automatisk.
Mini-konklusion: Hvis adgangsstyring ikke kan dokumenteres og administreres enkelt, bliver den sjældent gjort rigtigt.
Datalagring og hosting: hvor ligger data, og hvem har nøglen?
Datalagring handler om datacenterlokation, kryptering, isolering mellem kunder og backupprocedurer. Typiske spørgsmål er: Ligger data i EU/EØS? Bruges underleverandører uden for EU? Hvem kan tilgå data hos leverandøren, og under hvilke kontroller?
Du bør kræve kryptering både “in transit” og “at rest”, samt tydelighed om nøglehåndtering. I nogle brancher er customer-managed keys relevant; i andre er det nok at sikre, at leverandøren følger anerkendte standarder og har klare processer for adgang til produktionsmiljøer.
- Datacenterregion og eventuelle failover-regioner
- Kryptering af databaser, filer og backups
- Segregation mellem kunder (tenant isolation)
- Backupfrekvens, RPO/RTO og restore-test
- Underleverandører og deres lokation
- Logging og overvågning af uautoriseret adgang
Mini-konklusion: Det er ikke nok at høre “vi bruger cloud”; du skal vide hvor, hvordan, og med hvilke kontroller.
Retention og sletning: hvor længe gemmes data, og kan I få dem væk?
Retention er en klassisk blind vinkel. Mange systemer gemmer historik, versionsstyring, eksportfiler og logdata længere end nødvendigt. Det øger både risiko og omkostning, især hvis data kan kobles til personer.
Retentionspolitik for indhold, logfiler og backups
Bed om konkrete tidsrammer: Hvor længe gemmes revisionshistorik? Hvor længe gemmes adgangslogs? Hvad med API-logs og fejlrapporter? Det er helt normalt at have længere retention for sikkerhedslogs, men det skal være begrundet og dokumenteret.
Right to be forgotten og praktisk sletning
Sletning skal være mere end en knap i UI. Spørg om data slettes i produktionsdata, søgeindeks, caches og eksportområder. Og hvad med backups: slettes de, eller udløber de efter fast periode? Hvis jeres virksomhed arbejder med personhenførbare data i forbindelse med produktindhold, er det afgørende at kunne dokumentere sletteflows.
Mini-konklusion: En god retention-strategi reducerer skade ved brud og gør compliance lettere.
GDPR-vinklen: også når det “bare er produkter”
Det lyder banalt, men produktdata kan indeholde personoplysninger. Eksempler: navne på kontaktpersoner i leverandørfelter, e-mailadresser i manualer, billeder med genkendelige personer, eller logdata der viser hvilke medarbejdere der har gjort hvad. Derfor bør du tidligt afklare, om leverandøren er databehandler, og om I skal have en databehandleraftale (DPA).
Hvis en platform tilbyder AI-funktioner, skal du også spørge om data bruges til træning. Opt-out fra modeltræning og klare formålsbegrænsninger er centrale, især hvis I uploader kundespecifikke priser, rabataftaler eller uoffentlig produktstrategi. Midt i vurderingen kan det hjælpe at sammenligne leverandører ud fra konkrete kontrolpunkter for sikker produktdata håndtering og dokumentation, fremfor marketingløfter.
- Hvilke typer data behandles, og kan de indeholde personoplysninger?
- Hvad er formålet, og bruges data til sekundære formål som træning?
- Hvilke underdatabehandlere anvendes, og hvor er de placeret?
- Hvordan håndteres registreredes rettigheder og sletning?
- Hvordan dokumenteres hændelser og brud (incident response)?
Mini-konklusion: GDPR handler ikke om produktfelter, men om alt omkring dem: logs, filer, billeder og integrationsspor.
Risikominimering ved AI: fra prompt til output
AI kan indgå på flere måder: som indbygget tekstgenerator, som klassifikationsmodel, eller via integration til en ekstern LLM. Risikostyring starter med at forstå dataflowet: Hvilke data sendes ud, hvad gemmes, og kan output påvirke forretningen?
Data leakage, modeltræning og følsomt indhold
En typisk fejl er at sende hele produktkataloger, interne prisark eller leverandørkontrakter til en AI-tjeneste for at “rense data”. Brug i stedet dataminimering: send kun de felter, der er nødvendige, og maskér interne noter. Kræv klare svar på: gemmes prompts, og i hvor lang tid? Bruges de til træning? Er der en enterprise-aftale med no training og begrænset retention?
Hallucinationer, kvalitet og ansvar
AI kan opfinde specifikationer, kompatibilitet eller certificeringer. Det er både en sikkerheds- og compliance-risiko, hvis fejlinformation fører til forkert brug. Indfør derfor menneskelig kontrol for kritiske felter, eller brug regelbaseret validering mod kildedata. Accountability skal være tydelig: Hvem godkender output, og hvordan dokumenteres ændringer?
Mini-konklusion: AI bør behandles som en ny integration med egne kontroller, ikke som en smart knap.
Hvad koster sikkerhed, og hvor går budgettet typisk hen?
Omkostningen ved sikkerhedskrav ligger sjældent kun i licens. Den ligger i implementering, drift og governance: opsætning af SSO/MFA, roller, log-eksport, og tid til leverandørstyring. Nogle leverandører tager ekstra for avanceret audit logging eller enterprise-SSO, så vær opmærksom på prisstrukturen.
På den anden side er prisen ved et brud ofte langt højere: nedetid, genopretning, tabt salg og juridisk arbejde. Derfor giver det mening at budgettere efter risiko. Hvis platformen håndterer jeres centrale produktkatalog, er høj oppetid, gode backups og stærk adgangsstyring typisk pengene værd.
- Enterprise-SSO og central brugerhåndtering
- Logning, alarmering og integration til sikkerhedsværktøjer
- Ekstra miljøer til test og adgangskontrol
- Juridisk gennemgang af DPA og underleverandører
- Træning af redaktører i sikker brug af AI
Mini-konklusion: Spørgsmålet er ikke “hvad koster sikkerhed?”, men “hvad koster usikkerhed i jeres setup?”.
Typiske fejl ved leverandørvalg og sådan undgår du dem
Mange vælger ud fra demo og funktioner, og får først sikkerhed på agendaen, når kontrakten er klar. Det giver svag forhandlingsposition og ender i kompromiser, der er dyre at lappe bagefter.
Undgå især disse faldgruber: at acceptere uklare svar om datalokation, at mangle exit-plan, at undervurdere logdata som personoplysninger, og at tro at “ISO-certificering” automatisk dækker jeres konkrete brug. Certificeringer er gode, men du skal stadig sikre, at kontrollerne passer til jeres dataflow og integrationsmønstre.
Mini-konklusion: Hvis du ikke kan forklare dataflow og rettigheder på én side, er leverandørrisikoen sandsynligvis for høj.
Praktisk tjekliste til leverandørvalg: spørgsmål du kan sende i dag
Brug tjeklisten som et kort spørgeskema til leverandører og som intern kravspecifikation. Tilpas den efter om I er en mindre webshop eller en koncern med mange markeder.
- Adgangsstyring: Understøtter I RBAC, MFA, SSO og automatisk offboarding?
- Logging: Hvilke audit logs findes, hvor længe gemmes de, og kan de eksporteres?
- Datalagring: Hvor hostes data, hvilke underleverandører bruges, og er der EU/EØS-løsning?
- Kryptering: Krypteres data i transit og i hvile, og hvordan styres nøgler?
- Retention: Hvad er standard retention for indhold, logfiler og backups, og kan vi ændre den?
- Sletning og exit: Hvordan udleveres data ved exit, og hvordan dokumenteres fuld sletning?
- AI-brug: Bruges vores data til træning, gemmes prompts, og kan vi slå AI fra per felt eller bruger?
- Incident response: Hvad er jeres SLA for sikkerhedshændelser, og hvordan får vi besked?
Når du har svarene, kan du score dem i en simpel risikomodel: høj, middel, lav. Prioritér at få lukket de få punkter, der kan give stor skade: brede rettigheder, uklar datalokation, manglende sletning, og AI uden dataminimering. Best practice er at kræve skriftlig dokumentation og at teste: prøv en restore, prøv en rolleændring, og prøv at eksportere audit logs, før du skriver under.
Mini-konklusion: En god leverandør kan svare konkret, dokumentere kontrollerne og acceptere rimelige kundekrav uden at gøre processen tung.
