AI-systemer leverer uforudsigelige resultater. Problemet kan ikke løses for AI-systemer med et generelt formål (ChatGPT), men det kan løses for virksomhedsejede AI-systemer med et specifikt formål. En forpligtelse til gennemsigtighed kan udledes af GDPR alene. Operatører og udbydere af AI-systemer skal opfylde yderligere forpligtelser i henhold til AI-loven.
Indledning
Hvordan kan man gøre et AI-system gennemsigtigt? Svaret på dette spørgsmål for generelle AI-systemer er: slet ikke. Det skyldes, at disse generelle systemer, herunder ChatGPT, arbejder på basis af neurale netværk. Det er velkendt, hvordan dette netværk fungerer. Hvis man skrev en formel ned, der beskrev netværket, ville ingen forstå den, endsige være i stand til at læse den ordentligt.
GDPR fastsætter i Artikel 5 pligt til transparens ved behandling af personlige oplysninger. Dette gælder således for alle AI-systemer, hvorved personlige oplysninger bliver behandlet. Det er alle systemer, hvorved personlige oplysninger er blevet indført under træning eller ved brugerindgang (ofte via en prompt) personlige oplysninger er blevet indført. Det er en Tatsache, der (nur?) den hamburgiske dataskyddsbevægelse i farlig måde nægter.
I Art. 5 § 1 stk. d GDPR kræves, at data er sachligt korrekte, altså korrekte, skal være. Det gælder for alle personlige data i AI-systemer. Så sent som ved tidspunktet for inferens, altså når et AI-system producerer en udgang, skal denne lovgivning være opfyldt.
Den AI-Forordning (AI Act) definerer pligter, som især leverandører af AI-systemer skal efterholde. Særlige pligter bliver pålagt for højrisiko-AI. Denne type system burde være undtagelsesfald i praksis.
De fleste virksomheder, der bruger AI-systemer, er Operatør. For betreibernes vedkommende gælder der langt færre pligter end for Udbyder. Betreiber er man som virksomhed eller organisation ifølge art. 3 § 4 AI-VO, hvis man "bruger et AI-system i egen regi". Alt andet falder under Anbieter-begrebet (art. 3 § 3 AI-VO).
En idé til at øge gennemsigtigheden og dokumentationen af AI-systemer kom til forfatteren på et møde i AI-ekspertgruppen hos den statslige databeskyttelseskommissær i Niedersachsen, som forfatteren er medlem af. Forfatteren har også tidligere udgivet en bog om testdrevet softwareudvikling.
På den ene side er gennemsigtighed en ekstern præsentation af AI-resultater. Men den interne gennemsigtighed, dvs. for operatøren af en AI, er næsten endnu vigtigere: Hvordan fungerer AI'en? Hvilke resultater producerer den?
Bevis for korrektheden af AI-output
Generelt er det ikke muligt helt at sikre, at en AI kun bruger penge korrekt. Det er dog muligt at komme tæt på. Før vi kommer med et forslag til dette, giver vi et eksempel fra den meget dygtige DEEPL-oversætter (fra Tyskland!), som selv bruger AI, og som ligesom alle andre AI-systemer nogle gange begår fejl:
DEEPL blev bedt om at oversætte en tekst, der indeholdt et pengebeløb. DEEPL oversatte 1.050,00 euro på en sådan måde, at tallet i euro blev erstattet af et tal i pund. Det er tydeligvis forkert. For alle, der har lyst til at prøve det selv: Det afhænger af den overordnede tekst! Dette er delvist skjult i skærmbilledet ovenfor, fordi det var halvfølsom information. Du vil sandsynligvis få et korrekt resultat, hvis du kun indtaster den sidste sætning i DEEPL. Men hvis præambelteksten er anderledes, kan der opstå en fejl. Alene dette viser, hvordan uigennemsigtige AI-systemer fungerer.
Fejl kan derfor ikke undgås. Hvordan kan du stadig opfylde din pligt til gennemsigtighed og sikre korrektheden af AI-output så meget som muligt?
Svaret er: Gennem testfald.
Testcases er par af faktiske input og måloutput. En testcase består af et faktisk input og et faktisk output, der accepteres som godt. AI-forordningen (AI-VO) har tilsyneladende endda taget højde for dette:
Dette skyldes, at art. 3 nr. 53 i AI-forordningen definerer udtrykket "plan for en test i den virkelige verden" som "et dokument, der beskriver mål, metodologi, geografisk, populationsmæssig og tidsmæssig rækkevidde, overvågning, organisering og gennemførelse af en test i den virkelige verden".
Artikel 56 definerer AI-Kompetence som "de færdigheder, viden og forståelse, der gør det muligt for leverandører, driftschefer og berørt personer at anvende AI-systemer med indsigt samt at blive bevidst om chancerne og risikoen ved AI og de skader, som det kan forårsage
Ved hjælp af testcases kan operatører (og i endnu højere grad udbydere) blive mere bevidste om mulighederne og risiciene ved den AI, de driver eller tilbyder.
Man kan også indgå i de i artikel 3, § 60 af AI-loven nævnte Deepfakes. Her drejer det sig om en "af AI frembragt eller manipuleret billed-, lyd- eller videomateriale, der ligner virkelige personer, genstande, steder, institutioner eller begivenheder og ville gøre en person til at ligne ægte eller sand". Ved hjælp af billedmodeller kunne man sikre sig, at indgivne, som søger at ramme reelle personer og sætte dem i et dårligt lys, blev bedst mulig anerkendt og forhindret. I hvert fald kan med hjælp af testfald allerede dokumenteres, hvor (endnu) svaghederne ved AI-systemet ligger.
Testcases er et fremragende middel til at dokumentere kvaliteten af AI-systemer. De kan også gøre sådanne systemer mere gennemsigtige og fremhæve deres resterende svagheder.
Forpligtelsen for udbydere af AI-systemer uden høj risiko til at vurdere deres eget system, som fastsat i artikel 6, stk. 4, i AI-forordningen, kan også finde sted via testcases.
Det risikostyringssystem, der henvises til i artikel 9, stk. 1, i AI-forordningen, kan understøttes meget godt ved hjælp af testcases.
Mange andre bestemmelser i AI-loven pålægger udbydere og operatører af AI-systemer forpligtelser, som kan opfyldes ved hjælp af dokumenterede testcases. Disse omfatter:
- Art. 11 (1) AI-forordningen: teknisk dokumentation af et højrisiko-AI-system
- Art. 17 AI-VO: Kvalitetsstyring
- Art. 53 AI-forordningen som helhed: Forpligtelser for udbydere af AI-modeller til generelle formål
- Art. 91 og 101 i AI-forordningen kan have negative konsekvenser for AI-udbydere, hvis deres dokumentation ikke ser ud til at være tilstrækkelig.
- Art. 4 i AI-forordningen kræver også, at operatørerne sikrer, at deres medarbejdere har tilstrækkelig AI-ekspertise.
Eksempler på testcases
Hvordan ser en testcase ud? Her er et eksempel på en sprogmodel, der er designet til at besvare spørgsmål:
Is (spørgsmål = input)Should (svar = output fra AI)Hvad er cookies? Cookies er dataposter … Er cookies tekstfiler?
Alene disse to testcases gør det klart, at det ikke er en god idé at ville drive en universel chatbot. Ingen vil være i stand til at skrive nok testcases til at teste alle spørgsmål i verden, dvs. til at sikre kvaliteten.
Et AI-system bør derfor skræddersys til en brugssag eller et specialiseret domæne. Det gør det ikke kun lettere at opfylde de forpligtelser, der følger af AI-forordningen, men forbedrer også kvaliteten af resultaterne. Kvaliteten af specialiserede chatbots, f.eks. til byggebranchen, er betydeligt bedre, end nogen vil kunne opnå med ChatGPT.
Antallet af testcases bør være rimeligt højt. Yderligere testsager kan tilføjes gradvist. Især hvis et AI-svar på et brugerspørgsmål ikke var tilfredsstillende, er det tilrådeligt at inkludere en testcase for dette. Testcasen fungerer så i det mindste som dokumentation, men helst som grundlag for at optimere AI-systemet og bruge testcasen til at kontrollere, om optimeringen er lykkedes.
Når man bygger et videnssystem (som et af mange mulige AI-systemer), er der et trick til at øge kvaliteten af resultaterne betydeligt. Den såkaldte RAG-tilgang fører kun til begrænset succes og til toppen. Hvad det handler om, vil blive beskrevet i en senere artikel,
Hvordan kan testcases køres igennem?
Når testcases er sat op, skal de køres igennem. Konkret betyder det:
- Det definerede "faktiske" fra en testcase præsenteres for AI'en som input.
- AI'en svarer.
- AI-responsen sammenlignes med "målet" fra testcasen.
Testcases kan udføres automatisk.
Mennesker behøver så kun at se resultaterne.
Der er flere muligheder for at sammenligne AI-outputtet med det forventede optimum fra testcasen:
- AI-analyse med sammenligning af semantisk lighed
- AI-analyse via en sprogmodel (eller flere!)
- Konventionel analyse (eksempel: "Nej" i målet og "Ja" i AI-outputtet er i modstrid med hinanden)
- Blanding af alle metoder (anbefales)
Det i case to nævnte alternativ med at bruge flere sprogmodeller samtidig til at analysere testresultaterne fungerer meget godt med open source-modeller. Omkostningerne er altid de samme, nemlig nul (plus faste driftsomkostninger til serveren). Hvis ChatGPT blev brugt, ville omkostningerne være ret høje på lang sigt.
Med disse analysemetoder kan testcases i vid udstrækning analyseres automatisk. Mennesket kontrollerer derefter resultatet og kan skrive en konklusion i dokumentationen.
Konklusion
AI-systemers funktionalitet kan dokumenteres ved hjælp af testcases og dermed gøres transparent. Gennemsigtighed omfatter naturligvis også information om AI-systemets arkitektur. Det kan man nemt gøre, hvis man selv driver AI-systemet. Når det drejer sig om tredjepartssystemer som ChatGPT, er man nødt til at stole på de oplysninger, som udbyderen (OpenAI eller lignende) giver.
Testcases kan også bruges til at kontrollere og forbedre korrektheden af AI-output.
Testcases har derfor flere fordele og store gevinster. De oprettes ofte hurtigt. Med AI-support kan testcases endda udledes automatisk. Den menneskelige testcase-skaber får således en meget god skabelon for testcases og kan rette dem med en brøkdel af den manuelle indsats, der ellers ville være nødvendig.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
