Sikkerhed og ansvarlig AI
HumAIn Labs udvikler og driver AI-agenter efter offentligt tilgængelige, anerkendte sikkerheds- og styringsrammeværk. Nedenfor beskrives, hvilke rammeværk vi bygger efter, hvordan de omsættes til kontrol i det enkelte setup, og hvad vi ikke påstår.
En AI-agent adskiller sig fra en almindelig applikation ved at træffe beslutninger og udføre handlinger i flere trin. Det gør agenten anvendelig — og det flytter en del af risikobilledet fra modellen til den måde, agenten er sat i verden på: hvilke værktøjer den har, hvilke rettigheder den har, hvad den kan nå, og hvem der kan stoppe den.
Derfor behandler vi sikkerhed som en egenskab ved opsætningen, ikke som et filter oven på modellen. Hvert setup beskrives, måles og godkendes, før det tages i drift.
| Rammeværk | Type | Anvendelse hos HumAIn Labs |
|---|---|---|
| OWASP Top 10 for Agentic Applications 2026 | Åbent kontrolkatalog (OWASP GenAI Security Project, december 2025) | Det operative risikokatalog. De ti risikokategorier ASI01–ASI10 omsættes til konkrete, efterprøvelige kontroller i vores setups. |
| NIST AI Risk Management Framework 1.0 med Generative AI Profile (NIST AI 600-1) |
Amerikansk standardramme (NIST) | Strukturen for risikostyring: Govern, Map, Measure, Manage. Vi bruger den til at fastholde roller, risikovurdering, måling og løbende opfølgning. |
| ISO/IEC 42001:2023 | International standard for AI-styringssystemer (AIMS) | Referenceramme for styringsdokumentation, ansvar, risikoregister og intern kontrol. HumAIn Labs er ikke certificeret efter ISO/IEC 42001. |
| EU's AI-forordning (2024/1689) | Lovgivning | Vi tilrettelægger løsningerne med henblik på overensstemmelse, herunder transparens- og dokumentationskrav. Klassificeringen af det enkelte system foretages sammen med kunden før ibrugtagning. |
Om certificering: Rammeværkene anvendes som kontrolkatalog og styringsmodel — ikke som et kvalitetsstempel. Vi kalder ikke et system certificeret, før en akkrediteret certificeringsinstans har erklæret det.
Ingen agent, profil, integration eller planlagt opgave tages i drift, uden at den har gennemgået vores sikkerhedskontrol. Kontrollen er maskinel og gentagelig: den læser den faktiske konfiguration, ikke en beskrivelse af den. Resultatet er én af tre tilstande:
Kontrollen køres på ny ved ændringer i konfiguration, værktøjer eller rettigheder — og som fast del af den løbende overvågning.
Når en agent skal betjene et program, er der to veje. Den dybe: integration gennem programmets API, database eller et plugin. Og den flade: agenten betjener programmets skærmbillede — den ser, klikker og skriver, som et menneske ville gøre.
Vi vælger som udgangspunkt den flade vej. Det betyder, at vi ikke skal have nøgler til kundens systemer, ikke skal ændre i deres opsætning og ikke skal have adgang til data i bagvedliggende databaser. Agenten kan det, brugeren med samme rettigheder kan — ikke mere.
Prisen for den tilgang er, at agenten er afhængig af, at skærmbilledet ser ud som forventet. Ændrer programmet sig, standser agenten og rejser en hændelse i stedet for at fortsætte på et gæt. Den dybe integration er stadig det rigtige valg, når opgaven kræver store datamængder eller høj hastighed — vi vælger den, når den er den bedste, og siger det højt, når den er.
En agent, der aldrig stopper, er ikke en stærk agent — den er en risiko. Vores agenter arbejder derfor med et defineret stoppunkt (HARM), og med en autonomi der skal optjenes.
Ingen agent får frie hænder fra dag ét. Retten til at handle selv kommer fra dokumenteret træfsikkerhed: et aftalt antal beståede kontroller i træk løfter niveauet, og ét afvist resultat sænker det og sender sagen til et menneske. Grænserne gælder ved alle niveauer, også ved højeste autonomi.
Kontrolkataloget dækker de ti risikokategorier i OWASP's agentliste. Hver kontrol har et målbart kriterium og en registreret status.
| Område | Hvad der kontrolleres |
|---|---|
| Adgangsrettigheder | At agenten kun har de rettigheder, opgaven kræver — og at forhåndsgodkendte kommandoer er minimeret. |
| Værktøjsbegrænsning | At en indskrænkning faktisk er aktiv, ikke blot beskrevet. En restriktion der ikke bider, tæller ikke. |
| Håndtering af hemmeligheder | At nøgler og tokens ikke ligger i klartekst i konfiguration, der deles mellem profiler. |
| Kontrolflade | At administration og godkendelser kun er tilgængelige fra det tilsigtede netværk. |
| Leverandørkæde | At plugins, hooks og integrationer er versionsbestemte og ikke henter og kører kode under drift. |
| Isolation af hukommelse | At hver bruger og rolle har egen hukommelse, så én kontekst ikke kan forgifte en anden. |
| Menneskelig godkendelse | At godkendelser kræver et menneske — også når agenten kører planlagt. |
| Netværkseksponering | At tjenester, der lytter bredt, er kendte, nødvendige og accepterede. |
| Planlagte opgaver | At autonome kørsler har et værktøjsloft, og at eksternt indhold ikke kombineres med kodeeksekvering. |
| Integrationer | At dataforbindelser er lokale eller godkendte, og at der ikke opstår uønsket dataudveksling. |
Sikkerhed, der ikke kan efterprøves, er en hensigtserklæring. Ved levering følger derfor dokumentation, som kunden eller en tredjemand kan gennemgå:
Vi gennemgår gerne kontroller og dokumentation for jeres konkrete system.