AI-agent til data ops: datakvalitet og overvågning af pipelines

Problemet

Datakvalitetshændelser annonceres ikke altid med en alarm. En undersøgelse gennemført af Wakefield Research for Monte Carlo blandt 200 dataprofessionelle i marts 2023 viser, at 74 procent af de adspurgte oplever, at deres forretningsinteressenter opdager et dataproblem før deres eget team, "hele eller det meste af tiden". Med andre ord, i de fleste organisationer er det et forkert dashboard opdaget af en sælger, eller en inkonsistent oversigt eskaleret af ledelsen, der udløser alarmen, ikke en intern overvågning.

Samme undersøgelse opgør forværringen fra år til år: antallet af månedlige hændelser steg fra 59 i 2022 til 67 i 2023, den gennemsnitlige løsningstid sprang 166 procent op til 15 timer pr. hændelse, og den gennemsnitlige andel af omsætningen berørt af en datahændelse steg fra 26 til 31 procent. En tidligere Monte Carlo-undersøgelse (over 300 adspurgte professionelle i 2022) fandt allerede, at data engineers brugte svarende til to dage om ugen, cirka 40 procent af deres tid, på at rette dataproblemer i stedet for at bygge nye pipelines.

Den finansielle omkostning følger med. En IBM-artikel fra 2025, der citerer en Forrester-rapport, angiver, at over en fjerdedel af de adspurgte organisationer anslår at tabe over 5 millioner dollar om året på grund af dårlig datakvalitet, og 7 procent over 25 millioner dollar. Samme artikel citerer det dokumenterede tilfælde Unity Technologies, som anslog omsætningstabet fra korrupte datasæt til omkring 110 millioner dollar i 2022. IBM Institute for Business Value tilføjer, at 43 procent af driftsdirektørerne placerer datakvalitet øverst på deres dataprioriteter i 2025. Det fælles mønster i alle disse undersøgelser: data går i stykker hurtigere end de overvåges, og ingen bemærker det, før skaden er synlig i sidste led.

Hvad agenten gør, trin for trin

En autonom AI-agent dedikeret til data ops kører kontinuerligt i sit eget miljø, ikke kun når den forespørges. Den tjekker jævnligt Datadog-dashboards og -monitorer knyttet til de fulgte pipelines og tabeller: jobbenes latens, fejlrate, behandlet datavolumen.

Sideløbende kontrollerer den enkle kvalitetsregler på de tabeller, den har fået ansvar for: har datafriskheden en unormal forsinkelse, er den indlæste volumen konsistent med historikken, driver andelen af nullværdier, er der dukket en skemaændring op uden varsel. Så snart en betydelig afvigelse falder uden for den observerede baseline, søger agenten kontekst i stedet for blot at konstatere en overskredet tærskel: den slår historikken over nylige commits og pull requests op på den pågældende pipelines depot, for at finde en kodeændring korreleret i tid med afvigelsen.

Før den opretter en ticket, tjekker den, at en lignende hændelse ikke allerede er under behandling. Er det reelt en ny hændelse, opretter den en struktureret Jira-ticket: pågældende tabel, observeret symptom, estimeret effekt, sandsynlig årsag identificeret ud fra de nylige commits. Den notificerer derefter dataholdet på Slack med link til denne ticket og den allerede indsamlede kontekst, så undersøgelsen ikke starter fra bunden.

Når en strukturændring opdages på en fulgt tabel, opdaterer agenten den tilsvarende skemadokumentation i Notion, så dataordbogen ikke bliver forældet i takt med ændringerne. Når hændelsen er lukket af teamet, udarbejder den en struktureret rapport ud fra logs, identificerede commits og udvekslinger i ticketen, for at bevare et brugbart spor til næste lignende hændelse. Hver kontrol, hver alarm, hver dokumentationsopdatering logges i agentens aktivitetstidslinje, hvilket udgør grundlaget for agentens observerbarhed: dataholdet kan til enhver tid spore, hvad den har tjekket, hvornår, og hvorfor den udløste en alarm.

Integrationerne i spil

Agenten bygger på de værktøjer, der allerede er på plads i datastacken, i stedet for at påtvinge en ny monitoreringsplatform.

På Datadog følger den dashboards og pipeline-monitorer for at opdage en drift i latens, fejlrate eller volumen, før den bliver synlig i sidste led. På GitHub slår den op i historikken over commits og pull requests på det depot, der huser pipeline- eller transformationsmodellernes kode, for at korrelere en hændelse med en nylig kodeændring. På Jira tjekker den, at en lignende ticket ikke allerede findes, før den opretter en ny, dokumenteret med den pågældende tabel, symptomet og den sandsynlige årsag. På Slack alarmerer den dataholdet i realtid med den allerede indsamlede kontekst. På Notion holder den skema- og dataordbogsdokumentationen opdateret ved hver opdaget strukturændring.

Hver integration er kun aktiveret til de strengt nødvendige handlinger: agenten kan kun læse et dashboard, slå op i et depot, oprette en ticket eller ændre en dokumentationsside, hvis et eksplicit grant tillader det, handling for handling, med et omfang på kun læsning eller læsning og skrivning.

Det, der stadig er op til mennesket

Agenten overvåger, korrelerer og dokumenterer, den retter aldrig selv en pipeline. Det er en bevidst grænse for denne use case, ikke bare redaktionel forsigtighed: ingen ændring af en database eller pipeline i produktion udføres nogensinde, uden at et menneske har godkendt ændringen på forhånd.

Konkret bevarer et menneske kontrollen over fire punkter. Det diagnosticerer den præcise rodårsag og retter logikken i pipelinen eller transformationsmodellen, ud fra den korrelation agenten har fremhævet, men uden pligt til at følge dette spor, hvis en anden forklaring viser sig mere sandsynlig. Det godkender og udfører selv enhver ændring af en database eller pipeline i produktion. Det beslutter prioriteringen af udbedring, når flere hændelser er åbne samtidig, ud fra den reelle forretningsmæssige effekt snarere end en automatisk score. Og det gennemgår den skemadokumentation, agenten har genereret, før den betragtes som teamets officielle reference.

Målbart resultat

Den primære gevinst er ikke at erstatte en data engineers vurdering, det er at undgå, at en forretningsinteressent bliver den første til at opdage problemet: husk at 74 procent af de adspurgte i Monte Carlo-undersøgelsen fra 2023 allerede konstaterer dette scenarie i deres organisation. Løbende overvågning af tabeller og pipelines, med en alarm så snart en afvigelse falder uden for baseline, virker direkte på dette friktionspunkt.

En ticket der allerede er dokumenteret, når dataholdet får kendskab til en hændelse, med den pågældende tabel og en sandsynlig årsag allerede identificeret ud fra de nylige commits, reducerer også en del af den løsningstid, der i gennemsnit nåede 15 timer pr. hændelse i 2023-undersøgelsen. En skemadokumentation, der forbliver opdateret i takt med ændringerne, forhindrer endelig ubehagelige overraskelser, når nogen anden genbruger en tabel, de troede, de kendte.

Platformens pris følger samme logik som selve datafunktionen, pr. aktiv agent frem for pr. bruger: detaljer på siden om priser.