I dag holdt jeg innlegg på IT-avdelingens idémøte om KI i administrativ databehandling. Det var ment for å ta pulsen på hva folk på UiO bruker KI til og hva de ønsker seg.

Jeg kalte innlegget “kreativ administrasjon”, som for noen kanskje virker litt rart/skummelt, men jeg mener det positivt. Som professor underviser jeg, veileder, forsker og leder, og på alle de feltene jobber jeg tett med administrasjonen, både ved RITMO og MishMash. Jeg har derfor mange tanker om hvordan KI kan brukes administrativt ved et universitet. Ettersom jeg bare hadde ti minutter til rådighet, rakk jeg bare å skrape litt på overflaten. Her er en oppsummering av innholdet sammen med noen refleksjoner.

Assistent eller agent?

Jeg begynte med å forklare forskjellen på assistenter og agenter. Dette er KI-systemer med ulike grader av autonomi. Disse kan ses på som mer avanserte enn de tradisjonelle botene, f.eks. hjelpere på nettsider som svarer på enkle spørsmål. Dagens assistenter (ChatGPT, etc.) svarer innefor “veggene” i en nettleser. De kan søke på nett, men er i utgangspunktet satt opp til å svare på spørsmål. Agenter derimot jobber direkte med filer og kan utføre en rekke prosesser i rekkefølge. De kan også korrigere seg selv underveis, avhengig av hvordan de instrueres.

Assistent inne i et system, mot agent i midten av filer, mapper, API-er, databaser og scripts Assistenten er bundet av det systemet allerede kan. Agenten jobber på filer og mapper, og krever tilgang til data.

Man får mye ut av en assistent, men utrolig mye mer ut av en agent. Over agentene ligger multi-agent-systemer, der mange maskiner og mange mennesker snakker sammen, og det er det jeg har forsket mest på de siste årene.

Verktøy og modell

Et annet poeng jeg forsøkte å få frem, er forskjellen på verktøy og moddell. ChatGPT, NotebookLM, Claude Code og VS Code er verktøy, mens Gemini, GPT og Fable er modeller som ligger under. Noen blander dem sammen, men de fleste verktøyene kan brukes med flere modeller, og samme modell dukker opp i mange verktøy. VS Code er et kjempekraftig verktøy, men med en dårlig modell hjelper det ikke stort. Så det er alltid relevant å spørre seg hvilken modell man bruker, hvor den kjører, og hva som skjer med dataene.

Seks verktøy øverst, fem modeller nederst, med koblinger på kryss og tvers Samme modell i mange verktøy, og samme verktøy kan bytte modell.

Svart boks lager hvit boks

Tradisjonelt har vi programmert regelbaserte systemer, og det gjør vi fortsatt. Veldig mye av det vi kaller KI er egentlig regelbasert, selv om vi ofte glemmer det. Et menneske skriver reglene, reglene kjører på dataene, og ut kommer resultatet. Det kan være så enkelt som en formel i Excel. Det er en “hvit boks” der alle kan lese reglene, kjøre dem om igjen og rette dem. Ulempen er at hver regel er håndarbeid, og at systemet bare kan det noen har tenkt på.

En programmerer skriver regler som kjører på dataene og gir tabell, figur eller rapport Gammel tilnærming: et menneske skriver reglene, og reglene kjører på dataene. Lesbart og reproduserbart, men håndarbeid.

KI-revolusjonen vi nå ser er basert på mulighetene til de store språkmodellene (LLM). Disse er trent opp på forhånd (maskinlæring) og har ofte mye innebygget “kunnskap” i tillegg til at de kan hjelpe med å formulere og gjennomføre prosesser. Dette er ofte en “svart boks” fordi vi ikke ikke hva de er trent på og hva som skjer inni modellen. Det kan fungere for mange ting, men som en fra økonomni kommenterte, det er greit med litt upresise svar for mange ting, men ikke for lønnsubetalinger.

Dataene går rett inn i språkmodellen, og ut kommer et svar som er ulikt hver gang Ny tilnærming: dataene rett inn i språkmodellen. Svaret kan verken sjekkes eller gjentas.

Alternativet, og det jeg selv synes er mest interessant, er å bruke den svarte boksen til å lage en hvit. Modellen skriver regelbasert kode som er lesbar for mennesker (ihvertfall hvis du kan litt koding) forståelig, og kjører dette på dataene. Du skjønner kanskje ikke helt hvordan scriptet ble til, men så lenge du kan lese det og se at det er bra, er det greit. Slik brukte jeg også agenter i sommer, da femten år med bevegelsesdata skulle ryddes til Oslo Standstill Database.

Språkmodell som lager et script som kjører på data Modellen er uforståelig. Scriptet den lager, er lesbart og kan kjøres på nytt.

Hva får agentene tak i?

Agenten er bare så god som dataene den slipper til på, og ved UiO er det store forskjeller. NVA, Orcid, Zenodo og DataverseNO er åpne, med API. Vortex, Nettskjema og GitHub er delvis åpne. FS, arkivet, DFØ og SAP er lukket, i hvert fall for meg som vanlig ansatt og leder. Noen på UiO har tilgang, men ikke de fleste av oss. Alt jeg viste som fungerer, ligger i den første gruppen. Alt som ikke fungerer, ligger i den siste.

Tre kolonner: åpent med API, delvis, lukket Datakartet slik det ser ut for en ansatt og leder på UiO.

God praksis

Jeg snakket også litt om hvordan jeg selv jobber med agenter. Her trakk jeg frem tre vaner:

  1. Jeg begynner alltid med å lage én mappe med filene jeg vil jobbe med
  2. Deretter ber jeg agenten om å lage tre tekstfiler (handover, todo og log) som forklarer både meg og agenten hvordan vi skal jobbe sammen.
  3. Dette kjører innenfor et virtuelt miljø på maskinen min, slik at jeg isolerer det jeg driver med for å unngå krøll.

Disse tingene hjelper til med å få god arbeidsflyt og det gjør det enklere for en agent å komme tilbake til hvor vi var.

I tillegg er det mye som bør følge alt vi lager:

  • versjonskontroll (Git)
  • hvem som har gjort hva (Orcid)
  • varig identifikator (DOI)
  • tidsstempel
  • riktig lisens (CC-BY)
  • personvern (grønn, gul, rød, svart)

Dette er ganske vanlig innenfor forskning, men kan med fordel også rulles it administrative arbeidsflyter.

Syv eksempler

Etter de litt generelle tingene, nevnte jeg flere ulike eksempler. Her startet jeg med reiseregninger, hvor DFØ-systemet vi har nå er, for å si det mildt, en plage. Som sluttbruker er det ikke et godt system: masse klikking, masse feil, masse runder mellom mennesker, og det tar dagevis, om ikke ukevis, å rydde opp. Det jeg ville hatt, er noe i retning av reklamen på Gardermoen: ta bilde, klikk, utbetaling. En agent fyller ut resten fra kalender og reise, jeg godkjenner med ett trykk, og økonomen får et forslag som allerede er kontrollert. Av alle ting er det økonomi jeg mener vi burde få mye raskere prosesser på.

DFØ-flyten med mange klikk og retur, mot en flyt der kontrollen er bygget inn Slik er det, og slik kunne det vært. Dialogen bør skje i forkant, ikke som retur etterpå.

Men også som leder trenger jeg KI-hjelp med okonomien. Jeg leder to sentre som begge er ganske komplekse fra et organisatorisk perspektiv. Økonomene river seg i håret for å finne ut av ting. De må gjøre alt manuelt og mekanisk og sliter med å få oversikt. Resultatet er at vi får for dårlige rapporter, for sent. Hvis jeg hadde hatt tilgang til økonomidataene kunne jeg spurt en agent om f.eks. hvor mye har vi igjen på driftsmidlene eller hva det økonomiske handlingsrommet blir hvis en ansatt slutter to måneder før tiden. Det er ingen grunn til at vi ikke skulle kunne spørre en agent om slikt.

Så det mer personlige. NVA er fint, og der legger vi inn ting. Som jeg har beskrevet tidligere, har jeg god erfarign med å hente ut egne NVA-data som jeg har lagt inn i NotebookLM sammen med gamle CV-er. Nå har jeg min egen CV/bio-generator: hver gang jeg trenger en bio på 100 eller 200 ord, eller en CV i et nytt format, ber jeg om det. Det som mangler, er FS. Jeg skulle gjerne hatt inn alle emnene jeg har undervist og studentene jeg har veiledet, for det ligger jo der. Forskningen er åpen, undervisningen er lukket, og det skal jeg snakke mer om på idémøtet om utdanning i morgen.

Kildene NVA, Orcid, undervisningsportefølje og gamle CV-er inn i NotebookLM, bioer og CV ut, og FS som mangler Det som kommer ut, er bare så godt som kildene. FS finnes, men er ikke tilgjengelig.

NVA er også en datakilde vi bruker aktivt i MishMash. Biografiene på nettsidene våre hentes fra NVA, institusjonsprofilene fra Wikipedia, og ingen skriver personsidene for hånd. Det vi mangler, er den andre veien: når Retriever sender over medieoppslag på e-post om morgenen, burde de gått automatisk inn i NVA som mediebidrag, i stedet for at noen skal legge dem inn manuelt.

Styrepapirer er en annen sak vi sliter med. I RITMO settes styremøtesidene opp for hånd i Vortex. I borettslaget mitt bruker vi OBOS Styrerommet, som er overraskende bra, ikke minst til å ta vare på historikken. I MishMash ligger alt i markdown-filer i et GitHub-repo, og nettsidene bygges automatisk. Vi har laget en oversetter som gir engelsk og norsk versjon av alle sidene. De må kontrollsjekke, men vi sparer enormt med tid. For å sikre transparens, står det nederst på hver MishMash-side hvem som har endret den, når, hvor lang tid den tar å lese, lisens, personvernnivå, tilgjengelighetsnivå og hvilke datakilder som er brukt. Noen sider er skrevet av mennesker, andre er helt maskinelle, men leseren kan alltid se hva som ligger bak.

Jeg er også opptatt av hvordan vi kan bevare historien vår, og da er arkivet viktig. Jeg har tidligere skrevet om hvordan UiOs nettsider er en viktig forskningsinfrastruktur. Dessverre tenkes ikke arkiv inn som en integrert del av arbeidsflyten. Det er et låst og lukket system, som sikkert er bra for å ivareta innholdet, men som ikke kan brukes som kilde for oss som har laget mye av innholdet. I MishMash tenker vi motsatt: alt ligger i GitHub, med hele versjonshistorikken fra senteret startet til det en gang er slutt.

Arkivet som lukket safe, mot ønsket om søke-API, nedlasting og lokale analyser Vår egen nære historie er en viktig datakilde.

Til slutt datarydding, og grunnen til at jeg begynte å jobbe så mye med agenter. I sommer skrev jeg på en bok som heter Still Standing, om alle årene jeg har stått stille i laben, og satt med femten år med data som var, la oss si, halvryddige. Slik blir det når mange folk har vært innom en lab. Med agenter fikk jeg ryddet opp i hele kaoset og publisert det som Oslo Standstill Database på Zenodo, på en måte som er både maskinlesbar og menneskelesbar, med scriptene ved siden av. Det er kjernen i det jeg prøver å si: vi må få inn en god arbeidsmåte for dette. Og det positive er at UiO, av alle steder i Norge, er stedet med den beste kunnskapen. Vi kan alle disse tingene, vi har menneskelig kunnskap og maskinene som kan kjøre det. Hvis vi klarer å få det over i administrasjonen, blir det helt perfekt.

Slik ble dette innlegget laget

Dette innlegget er i seg selv et eksempel på den agentiske tilnærmingen. Jeg tok skjermbilde av innkallingen, skrev en side med stikkord og eksempler, og ba Claude Code lese begge og lage lysbilder i reveal.js, notatark, PDF og et bloggutkast. Jeg kommenterte, leste, kommenterte og leste, ca 40 runder. Jeg byttet på rekkefølgen på lysbilder, ba om flere bilder, fjernet tekst, osv.

Jeg sparte antagelig ikke noe tid på å gjøre dette agentisk. Ikke denne gangen. Men ved at jeg lagrer loggen fra det vi har gjort sammen, vil jeg enklere kunne forklare fremtidige agenter hvordan jeg jobber og hva jeg ønsker. Så jeg ser på dette som en måte å spare tid, og forbedre resultater, i fremtiden.

Hvordan prosessen var, har jeg skrevet om i en egen post. Det korte svaret er at det gikk fordi alt agenten trengte, lå på min egen disk. Hadde jeg bedt den om det samme for FS eller arkivet, hadde den stoppet ved innloggingen. Konklusjonen er at agentene er klare, men vi mangler tilgang til en del data.