Vi har AarhusAI: Nye muligheder, arbejdsgange og opgaver
AarhusAI blev i august 2025 lanceret som en “soft launch” med opfordring til at indsende løbende feedback. Platformen bevæger sig således gradvist fra afprøvning til hverdag. Det betyder, at adgang og brug vil blive mere udbredt, samtidig med at brugerne løbende får mulighed for at give feedback, som kan blive omsat til forbedringer.
Vi ønsker at undgå overfladiske målsætninger, der ikke siger noget om platformens reelle værdi. Derfor bliver en vigtig tilgang at skabe en kontinuerlig feedback-loop med brugerne for at forstå deres oplevelser og forventninger.
Hvis AarhusAI over tid skal blive et stærkt og sikkert alternativ til de kommercielle værktøjer, kræver det dedikerede ressourcer og ledelsesmæssig forankring. Platformens succes kan fx måles på, om den enkelte bruger vender tilbage og oplever værdi i sin dagligdag. Det handler ikke kun om effektivitet, men også om kvalitet – og om at skabe nye samarbejder, hvor AarhusAI kan fungere som sparringspartner og dialogstarter mellem kolleger. Hvis der opstår en aktiv brugerbase, hvor brugerne hurtigt giver feedback og fortsat vælger platformen til, er det en stærk indikator for, at den giver værdi.
Ambitionen er, at AarhusAI bliver et varigt element i kommunens digitale værktøjskasse. Fremtiden handler om at sikre både bred forankring og ansvarlig anvendelse af AI generelt på tværs af kommunens mange enheder og her kan AarhusAI være en grundsten på teknisk såvel som organisatorisk plan.
På længere sigt kan AarhusAI blive en byggesten i nye arbejdsformer – ikke kun digitalt, men også som basis for automatisering, robotteknologi og beslutningsstøtte. Men denne fremtid kræver fortsat ansvarlighed, klare rammer og en menneskelig forståelse af, hvordan teknologien bruges.
Den første feedback har bekræftet os i en række forhold:
• At vidensdeling og dialog i Builder gruppen, er en vigtig forudsætning for platformens succes • At der bør sidde implementeringsbistand klar i opstartsfasen, til at støtte de udfordringer, der måtte være, når der skal bygges en ny chatbot. For at Builders ikke mister modet og udbredelsen dermed mister momentum • At governance og organisering rundt om platformen er vigtig og tydelig • At entydigt systemejerskab og det nødvendige setup rundt om AarhusAI generelt er vigtigt; organisering, kompetence, økonomi, support m.v.
Forud for implementeringen af en ønskværdig use case ligger et analyse- og dokumen- tationsarbejde, der skal sikre, at man kan levere brugbar kvalitet til forretningen i et kryds mellem model/modelstørrelse, åben/proprietær model, datasikkerhed osv. Derfor er en organisering og governance rundt om platformen ikke alene et spørgsmål om teknik og tekniske ressourcer, men i høj grad også et spørgsmål om en systematisk tilgang til den løbende forretningsudvikling som forbrænder til den praktiske implementering af specialister m.v.
Vi skal med andre ord have ressourcer og metode til at afdække og kvalificere – f.eks. gennem brugerrejser og AI Screeningsværktøjet – detaljerne omkring en given use case før vi implementerer den i AarhusAI eller i øvrigt.
Det handler bl.a. også om at støtte forretningen i at vælge den rette generative model til opgaven, foretage systematisk evaluering af samme konkrete prompts på forskellige modeller, hvor svarene kan give nogle pejlemærker ift. modellernes grundlæg- gende formuleringsevner på dansk, verbositet, formuleringsevner på domænesprog m.v.
Arbejdet vil resultere i en form for internt generativ AI modelkatalog eller ”aktuelt situationsbillede” på mulige modeller i Aarhus Kommune og som løbende skal vedligeholdes i takt med at nye modeller kommer til. Det kræver ressourcer til at opretholde overblikket, følge med i den hastige udvikling og sikre systemunderstøttelse til samt udføre kontinuerlige test- og kvalitetskortlægningsaktiviteter på modelsiden (EvalOps).
Dertil er mange use cases for platformen bundet op på inddragelsen af eksisterende kildemateriale – fra intranettet, fra vejledninger i PDF-format m.v. og det er endnu en forudsætning for at lykkes med de faktiske use cases at vi har ressourcer til at arbejde med tilvejebringelsen og nyttiggørelse af information på den korte bane og at arbejde generelt på at forbedre vores informationsarkitektur på den lidt længere bane, så vi sikrer lettere adgang til kommunens ustrukturerede data i relation til både generativ AI via platformen, men også på sigt i relation til agentic AI, hvor agenter forventes at skulle kunne tilgå forskellige kildesystemer på mere autonom vis.
Når alt kommer til alt er den centrale leverance kontinuerligt at kunne levere generativ AI af brugbar kvalitet, sikkert og transparent til forretningen i et kryds mellem forretningsbehov og tekniske kapaciteter, datasikkerhed osv.
For at kunne sikre løbende afdækning af forretningsbehov og den nødvendige kapacitet til at levere på behovene (både for generativ AI i relation til platformen her, men i et bredere perspektiv AI bredt set) er der behov for at se på den måde, vi indretter os på for at kunne levere.
Det er vurderingen – fraset direkte driftsrelaterede opgaver – at opgaveomfanget til den organisatoriske implementering, support m.v. vi være stort set det samme, hvis vi køber en eksisterende platform ”ude i byen”, da det i vid udstrækning handler om at vi organiserer os klogt rundt om den tekniske platform og får skabt liv og energi, så vi sikrer at platformen får den forretningsmæssige og faglige værdi, den har potentiale til.
Som opfølgning på udviklingen af AarhusAI er en række processer kortlagt. Der vil rundt om platformen være processer, der er ”kendte” systemejeropgaver – men dertil en række processer, som opstår, fordi der arbejdes med generativ AI og fordi feltet hele tiden rykker sig med stormskridt.
Formålet med kortlægningen af processerne er ikke at diktere, hvordan opgaver skal udføres (om end ensartethed kan bidrage til mange ting) eller af hvem. Formålet har været at synliggøre hvilke roller, der aktiveres i arbejdet med AarhusAI og hvad omfanget af den enkeltes involvering er.
Hensigten er at synliggøre et ressourcetræk på tværs af roller, så det bliver synligt, hvor mange timer der skal prioriteres til forskellige roller. Kortlægningen er ikke komplet og altomfavnende, men synliggør hvor komplekse og tværgående processer, vi har med at gøre.
Kortlægningen illustrerer hvordan en hændelse ”trigger” en proces, som nogen i organisationen skal drive eller være involveret i. En hændelse kan f.eks. være, at nogen ønsker en ny specialist og det starter processen der på tværs af roller – Builder, Faglig Systemejer, juridisk vejledning, dataejere m.v. – tilvejebringer denne specialist. En anden hændelse kan være, at der kommer en ny release fra OS2ai hvilket starter en proces, hvor Teknisk Systemejer – i praksis udviklere/DevOps – skal reviewe, udrulle, teste, dokumentere og kommunikere den nye release. Et sidste eksempel kan være, at nogen mener at kvaliteten i svarene i en given specialist er for dårlig og at det så starter en proces med dialog, fejlsøgning, optimering af prompts og kildemateriale osv.
Hvis vi arbejder med en øget fælles bevidsthed om og understøttelse af den slags flows, så vil det ikke bare blive en mere robust proces (dvs. ensartet udført med kendte steps, handovers og outcomes), men også en mere effektiv proces at udføre fra gang til gang (dvs. mindre ressourcetung). Det kræver, at der er en villighed til at skabe hhv. efterleve fælles tilgange til opgaveløsningen på tværs af aktørlandskabet.