Af Greg Nowak. Senest opdateret 2026-09-25.
Alle i mødet kan være enige om næste skridt, og alligevel står projektplanen urørt dagen efter. Ingen har fået opgaven. Fristen findes kun i samtalen. En ændring, der lød fornuftig i rummet, er aldrig blevet vurderet i forhold til tid eller økonomi.
Kunne jeres virksomhed bruge det her? nowa.dk sætter AI-automatisering op for danske virksomheder.
Transskriptet løser ikke det problem alene. Det dokumenterer, hvad deltagerne sagde, men skelner ikke sikkert mellem en idé, en foreløbig aftale og en beslutning, som projektet faktisk skal handle på.
Her kan AI gøre en reel forskel: Den kan finde de relevante passager og forberede et struktureret udkast. Projektlederen skal stadig afgøre, hvad der er bindende, hvem der ejer arbejdet, og om leverancens omfang har flyttet sig.
Mødeplatformen leverer råmaterialet
De nødvendige tekniske adgangsveje findes allerede. Google Meet REST API giver adgang til mødeartefakter som transskripter og smart notes. Transskription kan bruges uafhængigt af optagelse, så det er ikke nødvendigt at gemme video alene for at kunne arbejde videre med samtalen.
Timingen betyder dog noget. Google oplyser, at de enkelte transskriptposter i Meet REST API slettes 30 dage efter konferencens afslutning. Artefakterne følger som udgangspunkt reglerne i arrangørens Google Drive, men integrationen bør hente de nødvendige oplysninger, mens API-vinduet stadig er åbent.
For Teams kan Microsoft Graph hente transskripter fra planlagte onlinemøder. Adgangen afhænger af rettigheder og administratorindstillinger i tenantmiljøet. Er Graph-adgang til transskripter deaktiveret, får integrationen en fejl i stedet for data. Workflowet skal derfor kunne kende forskel på et møde uden beslutninger og et møde, hvis transskript aldrig blev hentet.
Den samme samtale rummer fire slags projektinformation
Opgaven er ikke at producere et pænere referat. AI’en skal sortere udsagn efter, hvad de betyder for projektet. Fire kategorier dækker et fornuftigt første workflow:
| Kategori | Hvad udkastet skal indeholde | Projektlederens kontrol |
|---|---|---|
| Beslutning | Det valgte samt de alternativer, der blev fravalgt | Bekræft, at beslutningen er endelig og korrekt formuleret |
| Opgave | Handling, foreslået ansvarlig, frist og afhængigheder | Validér ejer, deadline og placering i projektet |
| Risiko | Usikkerhed, mulig konsekvens og foreslået opfølgning | Placér risikoen hos den rette ejer |
| Ændringsønske | Den ønskede ændring, berørt leverance og eventuelle forbehold | Vurdér scope, økonomi og tidsplan særskilt |
Forskellene er små i sproget, men store i driften. “Vi undersøger en integration” placerer ikke nødvendigvis en opgave hos nogen. Et ønske om at flytte lanceringen ændrer ikke automatisk tidsplanen. Og når kunden nævner rapportering, er funktionen ikke dermed blevet en del af det aftalte scope.
Udkastet bør derfor vise sit arbejde. Hvem sagde hvad? Hvornår i mødet? Hvilken passage ligger bag den foreslåede opgave eller beslutning? Med et kildelink eller en tidsreference kan projektlederen kontrollere fortolkningen uden at skulle gennemgå hele transskriptet igen.
Godkendelsen er stedet, hvor projektet ændrer sig
Workflowet bør standse efter analysen. Projektlederen får et udkast med de fundne beslutninger, opgaver, risici og ændringsønsker og kan acceptere, redigere eller afvise hvert element.
Først derefter får integrationen lov til at oprette eller opdatere noget i Jira eller Asana. AI’en forbereder arbejdet; den overtager ikke projektlederens mandat. Det mindsker risikoen for, at en løs idé bliver registreret som et leverancekrav, eller at den samme opgave dukker op igen efter næste møde.
En samlet knap med “Godkend referat” er sjældent præcis nok. Ti forslag kan have ti forskellige konsekvenser. Godkendelsen bør ligge på det enkelte element og fortælle, hvad klikket medfører: Opretter det en ny opgave, opdaterer det en eksisterende, registrerer det en risiko eller sender det et ændringsønske videre til særskilt vurdering?
Jira og Asana skal behandles som kontrollerede outputs
Jira Cloud REST API understøtter både oprettelse og redigering af issues. Integrationen er samtidig bundet af Jiras projekt- og brugerrettigheder. Oprettelse kræver blandt andet adgang til at se projektet og oprette issues. En integrationskonto med afgrænsede rettigheder giver derfor mere mening end brede administratorrettigheder.
I Asana kan en integration oprette en task via API’et, når den har skriverettighed til opgaver. Opgaven skal tilhøre et bestemt workspace, enten direkte eller gennem et projekt eller en overordnet opgave. Destinationen skal altså være kendt, før workflowet sender noget.
Outputtet bør følge samme faste struktur i begge værktøjer: en præcis titel, mødekontekst, foreslået ansvarlig, frist, kildehenvisning og et internt id fra godkendelsesflowet. Det interne id gør det muligt at se, om et godkendt element allerede er behandlet.
Dubletkontrol og fejllog hører til grunddesignet
Forestil dig, at integrationen opretter en Jira-opgave og derefter mister forbindelsen, før den lokale proces når at registrere resultatet. Ved næste forsøg kan den oprette samme opgave igen. Derfor skal hvert godkendt element have en stabil nøgle, og workflowet bør kontrollere både sin egen historik og det relevante projektobjekt inden en ny oprettelse.
Fejl skal lande i en synlig kø. For hvert problem bør man kunne se mødet, det berørte element, det fejlede trin og om handlingen trygt kan gentages. Hele transskriptet behøver ikke ligge i loggen; en reference, en status og en kort fejlbesked vil ofte være tilstrækkeligt.
På den måde opstår en brugbar revisionskæde fra mødeartefakt og AI-forslag til menneskelig godkendelse og resultatet i projektværktøjet. Hvis nogen senere vil vide, hvorfor en opgave blev oprettet, eller hvordan en scopeændring kom ind i projektet, kan forløbet spores.
Beslut retention, før workflowet tages i brug
Transskripter kan rumme personoplysninger og detaljer, der ikke skal gemmes permanent i et projektværktøj. EDPB’s guide til mindre virksomheder fremhæver blandt andet, at personer skal informeres om behandlingen af deres data, at organisationen bør føre fortegnelse over behandlingsaktiviteter, og at persondata skal slettes eller anonymiseres, når de ikke længere er nødvendige.
Rå transskripter, AI-udkast, godkendt projektinformation og tekniske logs tjener forskellige formål. De behøver derfor heller ikke have samme levetid. Inden løsningen går i drift, bør virksomheden beslutte, hvem der kan se hver datatype, hvor længe den gemmes, og hvad en sletning konkret omfatter.
Begynd med ét afgrænset beslutningsflow
En første version behøver ikke omfatte alle møder og projekter. Vælg én mødetype, ét projektværktøj og nogle få tydelige felter. Workflowet kan i begyndelsen hente transskriptet, sortere indholdet i de fire kategorier og sende et udkast til godkendelse uden selv at oprette noget.
Når kategorierne rammer rigtigt, og ansvaret fungerer i hverdagen, kan skriveadgangen til Jira eller Asana åbnes. Det giver mulighed for at justere sprog, felter og godkendelsesregler, før fejl får konsekvenser i den aktive projektplan.
Greg kan hjælpe med at definere kategorierne, forbinde Meet eller Teams med projektværktøjet og bygge kontrollerne omkring godkendelse, dubletter, kildelinks, retention og fejl. Gennem nowa.dk, Gregs AI-automatiseringsservice for danske virksomheder, kan løsningen tilpasses den arbejdsgang, virksomheden allerede bruger, frem for at ende som endnu et selvstændigt referatværktøj.
Resultatet skal være enkelt at arbejde med: Det sagte bliver til et gennemarbejdet forslag, og først en menneskelig godkendelse gør forslaget til en projektforpligtelse.
Relateret på GrN.dk
- Montørens talenote skal blive til en arbejdsordre – ikke rå lyd
- Kundeindbakken må sortere sig selv – men ikke kommandere din AI
- Fra salgsmøde til CRM: Automatisér opfølgningen uden datarod
Brug for hjælp til den slags opgaver?
Tal med Greg om et kontrolleret mødeworkflow Kontakt Greg her.
