Projektledere, driftsansvarlige og teams, der vil bruge AI til referater og opfølgning
Vælg det resultat, mødet skal efterlade
Start med en konkret mødetype, eksempelvis det ugentlige projektmøde. Beskriv hvad deltagerne skal kunne gøre bagefter: se vedtagne beslutninger, kende næste handling og opdage det, der mangler afklaring. Et referat med flot sprog er ikke nok, hvis en ansvarlig eller en reservation er blevet forkert gengivet.
Aftal en enkel kontrakt for output. Den kan bestå af kort resumé, beslutninger, opgaver og åbne spørgsmål. Beslutninger skal have deres grundlag, opgaver skal have en tydelig status, og manglende ansvar eller frister skal kunne stå som uafklarede. Undgå at tvinge alle punkter ind i et komplet skema, når mødet ikke gav oplysningerne.
Afklar samtidig, hvilke møder der ligger uden for første version. Et almindeligt planlægningsmøde er et andet udgangspunkt end en personalesamtale eller en fortrolig forhandling. Den afgrænsning gør både teknisk test og datahåndtering mere konkret. Brug et manuelt referat som sammenligningsgrundlag, så I kan vurdere den samlede rettetid og brugbarhed.
Afklar optagelse og information før mødet
Optagelse er en selvstændig beslutning. Datatilsynet beskriver, at digitale mødeoptagelser behandler personoplysninger, og at lovligt grundlag, nødvendighed og mødesituation skal vurderes konkret. En funktion i mødeplatformen afgør ikke i sig selv, om jeres anvendelse er passende eller lovlig.
Lad den dataansvarlige afklare formål, behandlingsgrundlag og information til deltagerne, før en automatisk optager tages i brug. Beskriv også, hvad der sker, hvis optagelsen skal standses, eller nogen har brug for et alternativ. En genkendelig arbejdsgang med menneskelige noter kan være nødvendig i de situationer.
I den praktiske opsætning bør mødeindkaldelsen og mødestarten gøre processen forståelig: hvilket materiale der dannes, hvem der kan se det, og hvem der kontrollerer referatet. Hold optagelse afgrænset til den relevante del af mødet, og kontrollér at den faktisk stopper. En bot, der bliver i mødet efter det planlagte formål, skaber et andet datagrundlag end det, teamet har aftalt.
Adskil fire trin, som kan fejle forskelligt
Talegenkendelse omsætter lyd til tekst. Taleropdeling forsøger at skelne stemmer. En sprogmodel kan derefter fortolke teksten til et referatudkast. Til sidst kan en integration oprette godkendte opgaver. Når trinene blandes sammen, bliver det svært at finde årsagen til en fejl.
Gem passende referencer mellem trinene, så en vigtig sætning kan kontrolleres i den relevante kilde, mens den er tilgængelig efter jeres opbevaringsregler. Google dokumenterer eksempelvis talerlabels og tidsangivelser i understøttede tale-til-tekst-forløb. En label som taler 2 er dog ikke i sig selv et verificeret medarbejdernavn.
Kontrollér mødeplatformens faktiske indstillinger. Microsoft beskriver optagelse og transskription som funktioner, der påvirkes af organisatoriske politikker. Test med de roller og konti, I vil bruge, frem for at antage, at en mulighed i en administratorvisning virker identisk for alle deltagere.
| Trin | Mulig fejl | Kontrol |
|---|---|---|
| Lyd til tekst | Et “ikke” mangler | Lyt til det relevante tidsudsnit |
| Taleropdeling | To stemmer får samme label | Afklar taleren før ansvar tildeles |
| Referatudkast | Et forslag bliver til en beslutning | Sammenhold formulering og mødegrundlag |
| Opgaveoverdragelse | En opgave oprettes to gange | Brug stabilt ID og læs resultatet tilbage |
Fra første afklaring til noget, der virker.
Afgræns mødet
Vælg formål, deltagere og nødvendigt output.
Kontrollér de ord, der ændrer betydningen
En transskription kan være let at læse og stadig have vigtige fejl. Negationer, beløb, produktnavne og datoer fortjener særlig opmærksomhed. En fejl i “vi godkender ikke” har større betydning end en unøjagtig fyldlyd. Det er derfor utilstrækkeligt kun at bedømme, om teksten virker flydende.
Afprøv jeres sprog og lydforhold: deltagere i et mødelokale, fjernforbindelser, afbrydelser og blanding af dansk med engelske fagord. Brug korte kontrollerede optagelser, som deltagerne har aftalt at bruge til testen. Skriv et manuelt referenceudsnit og markér de beslutningsrelevante ord.
Et internt navne- og begrebsark kan hjælpe den efterfølgende kontrol, men det må ikke få modellen til automatisk at erstatte en usikker formulering med et forventet navn. Ved tvivl skal systemet markere stedet til gennemgang. Sæt også en grænse for, hvornår lydkvaliteten er for dårlig til, at et referat kan godkendes uden en supplerende afklaring.
Bevar forskellen mellem drøftelse og beslutning
Bed modellen udtrække beslutninger med en kort henvisning til det relevante udsnit. Den skal kunne skelne mellem en idé, en foreløbig mulighed, en betinget beslutning og en endelig aftale. Formuleringer som “det kunne vi gøre” eller “hvis kunden godkender” må ikke blive til ubetingede opgaver.
Et illustrativt møde indeholder tre udsagn: “Vi kunne teste løsningen i oktober”, “Jeg undersøger kapaciteten inden fredag” og “Vi vælger først datoen, når kapaciteten er afklaret”. Et brugbart udkast registrerer undersøgelsen som en mulig opgave til den identificerede taler og datoen som uafklaret. Det må ikke oprette en oktoberlancering som vedtaget.
Hvis en ansvarlig ikke er entydig, skal navnet stå åbent. Relative frister som “fredag” bør kun omsættes til en dato med et kendt mødetidspunkt og relevant kalenderkontekst. Vis fortolkningen til godkendelse. Modellen skal ikke udfylde hullerne for at gøre opgavelisten pæn; hullerne er en vigtig del af det arbejde, mødelederen skal afslutte.
Gør referatet let at kontrollere og rette
En godkendelsesvisning bør fremhæve beslutninger, ansvar, frister og åbne spørgsmål. Læseren skal kunne gå fra et punkt til det relevante tekstudsnit eller tidsstempel, når kilden stadig må opbevares. Det er mere effektivt end at kræve, at alle genlæser hele transskriptionen.
Aftal en ansvarlig referatejer og en passende frist for rettelser. Det behøver ikke være samme person, der starter optagelsen. Markér tydeligt, om dokumentet er et AI-udkast, et rettet udkast eller en godkendt version. En ændring efter godkendelse skal kunne ses, især når den påvirker en allerede oprettet opgave.
Lad modtageren ændre et forkert ansvar uden at skulle omskrive hele referatet. Bevar dog forbindelsen til den godkendte version og den person, der foretog rettelsen. En lang historik er ikke et mål i sig selv; log kun det, der er nødvendigt for at forstå ændringerne og håndtere jeres konkrete dokumentationsbehov.
Opret opgaver efter en særskilt godkendelse
Når referatet er godkendt, kan en integration forberede opgaver i jeres eksisterende system. Begynd med en kladde eller en tydelig godkendelseshandling. Det skal fremgå, hvilke punkter der bliver overført, til hvilket projekt og med hvilken ansvarlig. Et mødeudsagn giver ikke automatisk et system tilladelse til at sende beskeder eller ændre eksterne aftaler.
Brug et stabilt ID for mødet og hvert godkendt opgavepunkt. Registrér modtagersystemets ID, når oprettelsen lykkes. Hvis forbindelsen afbrydes, skal næste forsøg undersøge den kendte status frem for blindt at oprette opgaven igen. En afsendt API-anmodning er ikke det samme som bekræftet oprettelse.
Planlæg også ændringer. Hvis en frist rettes i referatet, skal teamet vide, om den allerede overførte opgave opdateres, markeres til manuel kontrol eller står uændret med en tydelig besked. Undgå at love automatisk synkronisering i begge retninger, før ejerskab og konflikter er afklaret. Et enkelt, kontrolleret overdragelsespunkt er ofte et godt sted at begynde.
Behandl lyd, transskription og opgaver som forskellige data
Lav et lille register over de kopier, processen skaber: optagelse, transskription, udkast, godkendt referat, opgaver og relevante logposter. For hver del angives formål, adgang, placering og opbevaring. Det er ikke givet, at alle mødedeltagere eller alle projektdeltagere skal kunne se alle versioner.
GDPR beskriver blandt andet dataminimering og opbevaringsbegrænsning. Oversæt de principper til jeres konkrete arbejdsgang sammen med den ansvarlige for databeskyttelse. En standardindstilling fra en leverandør er ikke en begrundet opbevaringsperiode for alle møder. Microsofts dokumentation viser desuden, at adgang til Teams-optagelser og transskriptioner afhænger af konkrete møde- og delingsindstillinger.
Afprøv derfor med en intern deltager, en ekstern gæst og en person, der ikke deltog. Kontrollér også, hvad en delt filkopi eller et eksporteret referat betyder for sletning. Når lydfilen slettes, er dens oplysninger ikke nødvendigvis væk fra transskription, opgaver eller andre afledte dokumenter.
Test hele forløbet med kendte vanskeligheder
Lav et lille første testsæt, hvor hver optagelse eller transskription har et kendt forventet resultat. Medtag et normalt møde, en betinget beslutning, manglende ansvar, flere talere med lignende stemmer og et punkt, der senere trækkes tilbage. Antallet er mindre vigtigt end at få de relevante forskelle med.
Bedøm transskription og referat hver for sig. Registrér udeladte beslutninger, opdigtede opgaver, forkerte ansvarlige og fejl i frister. Mål desuden medarbejderens tid til kontrol og rettelse. En hurtig generering kan være en dårlig løsning, hvis den kræver mere efterarbejde end et almindeligt referat.
Afprøv også drift: afbrudt upload, manglende adgang, modeltimeout og et opgavesystem, der ikke svarer. Brug testprojekter og kontrollerede modtagere. Godkend kun den arbejdsgang, der faktisk er gennemført fra input til kontrolleret resultat. Gentag de relevante tests efter ændringer i model, skabelon, mødeplatform eller integration.
| Situation | Acceptabel adfærd |
|---|---|
| Ansvarlig er ikke nævnt | Punktet står til afklaring uden opdigtet navn |
| En idé bliver afvist senere | Den oprettes ikke som en vedtaget opgave |
| Overførsel svarer med timeout | Status undersøges før et nyt oprettelsesforsøg |
| Bruger mangler adgang | Kilden og dens indhold vises ikke |
Følg ét opgavepunkt hele vejen igennem
Forestil jer et projektmøde, hvor en deltager siger: “Jeg spørger leverandøren, om de kan levere den ekstra skærm. Jeg vender tilbage torsdag.” Senere præciserer mødelederen, at indkøbet først må godkendes, når prisen er kendt. Det er to forskellige forhold: en undersøgelsesopgave og en betingelse for et muligt køb.
Udkastet skal derfor beskrive opgaven som at indhente leveringsmulighed og pris, med den verificerede deltager som ansvarlig. Det skal bevare torsdag som en frist, der kontrolleres mod mødedatoen. Det må ikke registrere skærmen som bestilt eller oprette en indkøbsordre.
Referatejeren kontrollerer taler og frist, godkender punktet og overfører det til projektets opgaveliste. Integrationen får et eksternt opgave-ID tilbage. I referatet vises nu, at overdragelsen lykkedes, mens indkøbsbeslutningen stadig er åben. Hvis svaret fra opgavesystemet udebliver, markeres overdragelsen som uafklaret. Denne type gennemgang viser, om løsningen bevarer betydningen gennem alle trin, også når hvert enkelt delresultat ser korrekt ud isoleret.
Mål den samlede tid og de nødvendige rettelser
Sæt et lille måleskema op, før piloten begynder. Registrér tid til klargøring, generering, kontrol, rettelser og overdragelse. Notér samtidig, hvor mange beslutningsrelevante fejl der blev fundet, og hvilke punkter der måtte afklares med deltagerne. Sammenlign med jeres normale referatpraksis på en tilsvarende mødetype.
Tallene skal fortolkes sammen. Et kortere referat kan være hurtigere at kontrollere, men stadig mangle en vigtig beslutning. Et system kan også flytte arbejde fra mødelederen til en projektkoordinator uden at reducere den samlede indsats. Aftal derfor, hvem der registrerer tidsforbruget, og hvilke fejl der er uacceptable.
Brug pilotresultatet til en afgrænset beslutning: fortsæt med samme mødetype, ret et bestemt trin eller stop forsøget. En vellykket prøve giver ikke automatisk grundlag for at optage alle virksomhedens møder. Udvidelse til andre deltagere, datatyper eller integrationer er et nyt valg, som kræver en relevant gennemgang.
Lav et pilotbrief, som kan vurderes konkret
Et brugbart brief indeholder mødetypen, deltagernes roller, jeres nuværende referatformat og det system, opgaver skal ende i. Tilføj et anonymiseret eksempel på en godkendt opgave og et eksempel på noget, AI ikke må gøre til en beslutning. De to eksempler fortæller ofte mere end en lang ønskeliste.
Aftal hvem der ejer skabelonen, hvem der godkender udkast, og hvem der reagerer på tekniske fejl. Beskriv også, hvordan teamet arbejder videre, hvis optagelse eller transskription ikke er mulig. En pilot bør kunne standses uden at blokere det almindelige mødearbejde.
Moselstudio kan gennemgå jeres nuværende mødeflow og afklare et første afgrænset forløb fra input til opgaveoverdragelse. Til en indledende samtale er et format, en systemoversigt og nogle anonymiserede eksempler et bedre grundlag end rå optagelser med fortrolige oplysninger. Et tilbud kan derefter beskrive integrationer, kontrolpunkter og ansvar, som faktisk passer til jeres arbejde.
Det bliver vi ofte spurgt om.
Er et AI-mødereferat det samme som en transskription?
Nej. Transskriptionen gengiver tale som tekst. Referatet udvælger og fortolker det relevante. Derfor kan korrekt talegenkendelse stadig føre til et forkert referat, hvis et forslag bliver gjort til en beslutning.
Kan AI automatisk finde den ansvarlige for hver opgave?
Den kan foreslå en ansvarlig ud fra et tydeligt grundlag, men må ikke udfylde et ukendt navn. Talerlabels og deltagerlister kræver kontrol, især når flere deler mikrofon eller navne nævnes om andre.
Kan vi gøre det med vores eksisterende mødeplatform?
Det afhænger af platformens aktuelle funktioner, licens, politikker og de integrationer, I behøver. Undersøg et konkret mødeforløb og de faktiske brugerroller, før I vælger ekstra værktøjer.
Hvor længe skal optagelser gemmes?
Det skal begrundes ud fra formål og reglerne for jeres situation. Lyd, udkast og godkendte referater kan have forskellige behov. Aftal perioderne med den dataansvarlige og kontrollér sletning af de relevante kopier.
Læs videre ved kilden.
Vores beslutningsmodeller er rådgivning fra Mosel Studio. Tekniske fakta og rammer understøttes af kilderne her.
- Datatilsynet: Optagelse af digitale møder
Konkret vurdering af formål, grundlag, nødvendighed og deltagerinformation.
- Google Cloud: Detect different speakers
Taleropdeling som forsøg på at skelne stemmer i lyd.
- Google Cloud: Speech recognition response
Talerlabels og tidsangivelser i den dokumenterede responsstruktur.
- Microsoft: Recording and transcription overview
Organisatoriske politikker og styring af funktionerne.
- Microsoft: Access to recordings and transcripts
Adgangsindstillinger og deres konkrete anvendelse.
- GDPR: Artikel 5 og 25
Dataminimering, opbevaringsbegrænsning og databeskyttelse gennem design.
