Virksomheds-AI har et problem med dataenes parathed: det manglende lag før implementering af AI

Tilgængelige data er ikke det samme som parathed til implementering

Ifølge Eurostat anvendte 19,95 % af virksomhederne i EU med mindst ti ansatte eller selvstændige AI-teknologier i 2025 inden for de erhvervssektorer, som er omfattet af undersøgelsen af virksomhedernes IKT-anvendelse. Det måler udbredelsen – ikke egnetheden af de data, der understøtter hver applikation. [1]

Overvej et andet spørgsmål: Når et AI-system besvarer et driftsspørgsmål, kan organisationen så fastslå, hvilke oplysninger det brugte, om oplysningerne var aktuelle, og om brugeren havde ret til at modtage dem?

Denne artikel argumenterer for, at svar på disse spørgsmål kræver et udtrykkeligt ansvar for dataenes parathed mellem driftssystemer og AI-applikationer. Modellens kapacitet er fortsat vigtig. Den kan dog ikke erstatte oplysninger, som applikationen aldrig modtager, eller forretningsdefinitioner, som ingen har fastlagt.

Betydningen af arbejdet med data er ikke ny. Sambasivan og kolleger dokumenterede, hvordan dataproblemer kan forstærke hinanden og føre til fejl længere fremme i AI-systemer med store konsekvenser. Deres kvalitative undersøgelse omfattede 53 praktikere i flere lande; den bør ikke fortolkes som et skøn over fejlraten i europæiske virksomheder. Relevansen her er mekanismen: Tidlige beslutninger om data kan præge systemets senere adfærd. [2]

Når korrekte registreringer giver et ufuldstændigt svar

Forestil dig en hypotetisk driftsassistent, der bliver spurgt:

»Hvilke produktionstjenester kræver opmærksomhed i dag?«

Dens kildesystemer indeholder hændelsesregistreringer, infrastrukturmålinger og vedligeholdelsesplaner. Hvert datasæt kan være korrekt isoleret set. Alligevel modtager assistenten gårsdagens hændelseseksport, kan ikke skelne produktionsressourcer fra testmiljøer og finder en vedligeholdelsesprocedure, der er blevet erstattet.

Det resulterende svar kan være sammenhængende, men vildledende i driften. Problemet er ikke nødvendigvis en opdigtet oplysning. Det kan være en manglende relation, en forældet registrering eller en tabt skelnen mellem driftsmiljøer.

Eksemplet viser, hvorfor parathed skal række ud over vellykket dataindlæsning. Forberedelsesprocessen bør bevare de relationer, tidsstempler, definitioner og anvendelsesbetingelser, der er nødvendige for at fortolke dokumentationen.

Det viser også, hvorfor en vellykket demonstration ikke er tilstrækkelig. En prototype, der er testet mod et udvalgt øjebliksbillede, har ikke demonstreret, hvordan den opfører sig, når registreringer ændres, kilder svigter, eller tilladelser trækkes tilbage.

Definér parathed til en bestemt anvendelse

En nyttig arbejdsdefinition er:

AI-klare data er data, der er vurderet og forberedt til en bestemt AI-opgave, med dokumenteret betydning, oprindelse, adgangsbetingelser, kvalitetsforventninger og vedligeholdelsesansvar.

Dette er en foreslået operationel definition, ikke en certificering.

Et datasæt kan understøtte dokumentsøgning og samtidig være uegnet til en driftsanbefaling med væsentlige konsekvenser. NIST’s AI Risk Management Framework understreger tilsvarende, at AI skal vurderes i sin tilsigtede kontekst, og at risici skal håndteres gennem hele livscyklussen. [3]

Til teams i virksomheder foreslår jeg fire praktiske spørgsmål.

Dokumentation af datasæt giver et nyttigt fundament. Forslaget Datasheets for Datasets anbefaler at registrere forhold som indsamling, sammensætning og tilsigtet anvendelse. Teams i virksomheder kan tilpasse denne tilgang for at opretholde en udtrykkelig aftale mellem dataproducenter og dem, der anvender data i AI. [4]

Det manglende lag er et ansvar – ikke endnu en database

Et lag for dataenes parathed til AI bør forstås som et koordineret sæt kontrolforanstaltninger, ikke nødvendigvis som et nyt produkt eller datalager. Eksisterende integrationsplatforme, kataloger, databaser og adgangsstyringstjenester kan implementere en stor del af det.

Formålet er at gøre overgangen fra kildeoplysninger til AI-input udtrykkelig:

• hvad der udvælges;
• hvordan det transformeres;
• hvilke kontroller det består;
• under hvilke betingelser det frigives til brug.

Retrieval-Augmented Generation illustrerer denne skelnen. Den oprindelige RAG-forskning kombinerede en generativ model med søgning i et eksternt vidensindeks. Det giver en arkitektonisk vej til at levere oplysninger ud over en models parametre; det garanterer ikke, at de hentede oplysninger er komplette, aktuelle eller egnede til en bestemt opgave i virksomheden. [5]

Parathed bør heller ikke sidestilles med at omdanne alt til embeddings.

Embeddings er numeriske repræsentationer, som bruges i tilgange som semantisk søgning. En præcis driftsmæssig total kan i stedet kræve en kontrolleret databaseforespørgsel; en skiftende tjenestestatus kan kræve et autoriseret API. Repræsentationen bør følge opgaven.

For en dokumentbaseret assistent kan forberedelsen omfatte kuratering, dokumentgenerering, segmentering, indeksering og evaluering af informationssøgningen. Til en anden applikation kan et valideret struktureret datasæt være mere passende.

Det fælles krav er en vej med tydeligt ansvar fra kildedokumentation til applikationsinput.

Parathed skal kunne modstå driftsændringer

En nyttig accepttest handler ikke blot om, hvorvidt en pipeline kan indlæse data. Den handler om, hvorvidt applikationen forbliver pålidelig, efter at disse data ændres.

Test følgende for den hypotetiske driftsassistent:

• en opdateret hændelse;
• en slettet registrering;
• et omdøbt felt;
• en erstattet procedure;
• en tilbagekaldt tilladelse.

Definér den forventede reaktion, før testen køres.

Når en kilde bliver utilgængelig, skal systemet synliggøre begrænsningen eller bruge et kontrolleret alternativ frem for stiltiende at antyde fuld dækning.

I systemer til informationssøgning bør designet tage højde for, hvordan ændringer videreføres til afledte dokumenter, indekser og caches. At bevare en revisionshistorik bør ikke betyde, at forældet indhold fortsat præsenteres som aktuelt.

NIST’s Generative AI Profile indeholder anbefalinger om at spore ændringer i datasæt og opretholde overvågning efter implementering. [6]

Aktualiteten bør også være proportional.

»Aktuelt nok« for en hændelsesassistent kan være noget andet end »aktuelt nok« for en kvartalsvis vidensgennemgang. Definér og mål en maksimalt acceptabel forsinkelse for hver anvendelse frem for at antage, at enhver arbejdsbelastning kræver behandling i realtid.

Validér data og applikation hver for sig

Tre spørgsmål bør holdes adskilt:

• Blev pipelinen kørt?
• Bevarede den de nødvendige oplysninger?
• Brugte AI-applikationen disse oplysninger korrekt?

En afsluttet transformation dokumenterer ikke semantisk korrekthed.

Sporbarhed viser, hvor oplysninger kom fra; den beviser ikke, at kilden er korrekt.

Et søgeresultat dokumenterer ikke, at den valgte passage understøtter svaret.

Validering bør derfor undersøge indholdsmæssig trofasthed fra kilde til output, søgerelevans, genererede påstande og adfærd ved fejl som særskilte forhold.

NIST’s Generative AI Profile anbefaler at verificere kilder og henvisninger i genereret output, kontrollere relevante datas oprindelse og undgå brede påstande om kapacitet på grundlag af snævre eller anekdotiske evalueringer. [6]

For et afgrænset pilotprojekt ville jeg vurdere:

• kildernes sporbarhed;
• overholdelse af aktualitetsmål;
• søgningens dækning på et gennemgået sæt spørgsmål;
• henvisningernes korrekthed;
• resultater af tests af adgangskontrol.

Jeg ville også registrere svar uden underbygning og tilfælde, hvor systemet med rette afstår fra at svare.

Kritiske fejl i adgang eller dataoprindelse bør ikke forsvinde i en attraktiv gennemsnitsscore. Parathedskontroller understøtter beslutninger om implementering; de beviser ikke fraværet af hallucinationer og erstatter ikke bredere vurderinger af sikkerhed, privatliv og menneskeligt tilsyn.

Et praktisk arkitekturperspektiv

Denne opdeling af ansvar ligger til grund for vores arbejde med CIRMS.

GL3 fokuserer på automatisering og indsamling af driftsdata.

GL4 leverer forløbet for dataforberedelse gennem metadatabehandling, indsamling, kuratering, generering af dokumenter og chunks, vektorisering og semantisk validering.

GL5 er det planlagte lag for anvendt AI, som skal bygge videre på dette fundament. [7]

En vigtig arkitektonisk skelnen er, at CIRMS selv ikke er opdelt i separate produktvarianter for PROD, TEST eller DEV.

En CIRMS-udgivelse er ét produktbuild.

Hvis en organisation har behov for en testinstallation, kan den samme CIRMS-version installeres på testinfrastruktur. En produktionsinstallation bruger den samme CIRMS-version på produktionsinfrastruktur.

Miljøbetegnelser knyttet til kildesystemer beskriver den driftsmæssige kontekst for disse kilder. De bør ikke forveksles med forskellige CIRMS-udgaver, builds eller produktversioner.

Denne skelnen er lige så vigtig inde i pipelinen for dataenes parathed til AI.

En deterministisk mekanisme, der bruges til at validere pipelinens adfærd fra start til slut, er ikke en separat »udviklingsversion« af CIRMS. Den bør heller ikke forveksles med en semantisk embedding-model, der bruges til at evaluere den faktiske søgekvalitet.

Validering af pipelinen og validering af semantisk søgning er forskellige ansvarsområder, også når begge foregår i samme CIRMS-produktversion.

Den bredere arkitektoniske lære er uafhængig af CIRMS: Skeln mellem drift af kildemiljøet, forberedelse af brugbare oplysninger og anvendelse af disse oplysninger gennem AI.

Hvert ansvarsområde kræver tydelige input, kontroller og ansvarlige ejere.

Begynd med et afgrænset, testbart tilsagn

Til en virksomhed, der begynder på dette arbejde, anbefaler jeg at vælge:

• ét driftsspørgsmål;
• et begrænset sæt kilder;
• en klart defineret brugergruppe.

Aftal acceptable fejl, aktualitet, adgangsgrænser og eskalationsprocedurer, før applikationens rækkevidde udvides.

Leverancen bør være mere end en demonstration.

Den bør være dokumentation for, at de valgte oplysninger understøtter den tilsigtede opgave, at ændringer håndteres forudsigeligt, og at begrænsninger forbliver synlige for de mennesker, der stoler på systemet.

Det kræver ikke perfekte data i hele organisationen eller udskiftning af hele teknologistakken.

Det kræver proportionale kontrolforanstaltninger for den faktiske anvendelse og en plan for at opretholde dem.

Spørgsmålet er ikke kun: »Hvilken AI-model skal vi implementere?« Det er også: »Hvilken dokumentation viser, at de oplysninger, vi leverer, er egnede til denne opgave – og stadig vil være det i morgen?«

Det er her, dataenes parathed til AI i virksomheder bliver en driftsdisciplin frem for en engangsopgave i forberedelse.