AI-agenter i datamigrering – mer affär, mindre kod
Av Isak La Fleur EngdahlFöreställ dig en vanlig migreringsdag. En ekonomicontroller och jag tittar på en kundreskontra från ett 20 år gammalt affärssystem. "De här 4 000 kontona märkta spärrade – är de döda, eller bara vilande?" Den enda frågan avgör om tusentals poster följer med in i det nya systemet eller arkiveras. Det samtalet är migreringen. Pythonkoden som formar om datan när vi väl bestämt oss är bara skrivande.
Större delen av min karriär var den proportionen upp och ner: timmar på att skriva extract-transform-load-kod, minuter kvar till frågorna som faktiskt bar risken. AI-agenter vänder tillbaka den – och det är därför jag byggt in dem i mitt arbete.
Mindre kod, mer affär
I praktiken beskriver jag mappningar och kvalitetsregler i klara affärstermer, och agenten skriver Python-koden som extraherar, transformerar och producerar laddfilerna. En verklig instruktion ser mindre ut som kod och mer som en brief:
"Mappa
KUNDNRtillCustomerNo, vänsterfyll till 10 siffror. Släng rader där kontot är spärrat och saknar transaktion sedan 2021. DelaNAMNi för-/efternamn vid sista blanksteget. Flagga momsnummer som faller på checksumman i stället för att slänga dem."
Agenten gör om det till testad, körbar Python och producerar den deliverable jag ändå skulle leverera: en CSV- eller parquet-fil redo att läsas in i datapipen eller målsystemet. Skillnaden är var mina timmar hamnar – på kraven och bedömningarna, inte på boilerplate jag skrivit hundra gånger förr. När en regel ändras (och det gör den alltid) ändrar jag en mening i stället för att skriva om ett skript.
Verktygen jag använder: Hermes och Goclaw
Två öppna agentramverk är särskilt intressanta för det här:
- Hermes från Nous Research (GitHub) – ett MIT-licensierat, helt självhostat agentramverk. Det kör lokalt, stödjer många modell-leverantörer, parallella subagenter och Model Context Protocol (MCP).
- Goclaw (GitHub) – en självhostad multi-agent-plattform byggd i Go, med orkestrering av flera agenter, inbyggd säkerhet (bl.a. prompt injection-detektering) och en lokal "Lite"-utgåva.
Båda passar in i det AI-workflow jag redan beskrivit: flera samverkande agenter som tar det repetitiva – mappning, profilering, transformation – medan jag och verksamheten styr. I praktiken delar de upp arbetet: en profileringsagent läser källan och rapporterar vad som faktiskt finns där (andel null-värden, distinkta värden, format som inte matchar specen), en transformationsagent skriver och kör mappningskoden, och en valideringsagent kontrollerar resultatet innan jag godkänner det. Var och en lämnar sitt resultat vidare till nästa, och jag granskar vid skarvarna.
En extra valideringsrunda – innan verksamheten lägger tid
Det här är poängen som gör störst skillnad. I min 8-stegsmetod hör steg 6 och 7 – testmigreringarna – till verksamheten. Men innan någon i verksamheten ens loggar in i målsystemet – ERP:t som datan har migrerats till – låter jag en uppsättning agenter validera de förberedda CSV-/parquet-filerna mot reglerna. Konkret kontrollerar den rundan saker som:
- Kompletthet – radantal stämmer av käll mot mål; inget obligatoriskt fält är tyst tomt.
- Format & domäner – datum, valutor och koder matchar målets förväntade typer; statusvärden ligger inom den tillåtna mängden.
- Referentiell integritet – varje order pekar på en kund som existerar; inga föräldralösa nycklar.
- Avstämning – kontrollsummor (summor av saldon, antal per kategori) stämmer mellan käll och mål, så att inget tappats eller dubbelräknats på vägen.
- Affärsregler – kantfallen vi kommit överens om håller faktiskt: de spärrade-och-vilande kontona uteslöts verkligen, momschecksummorna flaggades verkligen.
Effekten: verksamheten börjar från ren data i stället för att bränna sin granskningstid på att flagga uppenbara fel. Deras timmar går till verklig affärsbedömning – är den här kunden egentligen fortfarande aktiv? – inte till att fånga sådant en maskin borde ha fångat först. Det blir mer effektivt för alla, och förtroendet för datan byggs långt snabbare, eftersom det första de ser håller.
Men känslig data, då?
Den självklara invändningen: migreringsdata är känslig – medlemmar, priser, löner, personuppgifter. Att klistra in sådant i en publik chatbot är en reell risk. Datan kan fastna i loggar och felsökning, hamna i framtida träningsdata, eller återidentifieras genom att aggregeras med andra källor. Under GDPR är det en olaglig överföring som väntar på att hända, och EU:s AI Act lägger till egna krav kring transparens och tillsyn. För ett reglerat företag är "vi klistrade in kundfilen i en chatbot" ingen mening någon vill ha med i en revision.
Det är precis därför självhostade, öppna agenter spelar roll. Hermes och Goclaw kan köras på egen infrastruktur – ert VPC, er server on-prem – så att känslig data aldrig lämnar din kontroll. Den centrala insikten är att agenten inte behöver datan för att göra sitt jobb: den behöver schemat och reglerna för att skriva koden, och det är koden som rör raderna. Kombinera det med några principer jag alltid håller:
- Dataminimering – ge agenten schemat och reglerna, inte rådata med personuppgifter. Den skriver en transformation mot kolumnnamn, inte mot era medlemmars faktiska poster.
- Anonymisering – när agenten verkligen behöver se värden för att resonera om ett format, ge den maskade eller syntetiska stickprov, inte det skarpa fältet.
- Opt-out & företagsavtal – om en molnmodell någonsin används för ett icke-känsligt steg, stäng av träning på dina indata och välj enterprise-/API-nivå med bindande personuppgiftsbiträdesavtal.
Agenten skriver koden; koden körs på din data i din miljö. Effektivitet och datasäkerhet behöver inte stå i motsats – med rätt uppsättning förstärker de varandra, eftersom en självhostad pipeline också är en repeterbar och spårbar sådan.
Slutsats
AI ersätter inte migreringsledaren – den tar bort boilerplate så att jag kan lägga tiden där den gör skillnad: affärsdialogen, kantfallen och besluten om datakvalitet. Agenterna profilerar, transformerar och validerar; jag tar med bedömningen av vad datan betyder. Verktyg som Hermes och Goclaw gör det möjligt att arbeta snabbare och hålla känslig data under kontroll – inte som en avvägning, utan för att samma självhostade uppsättning som skyddar datan också är den som gör arbetet snabbt och repeterbart.
Nyfiken på hur det skulle se ut hos er? Hör av dig – jag berättar gärna mer.