Agentic OS — slik automatiserer du back office i en liten bedrift

Systemet bygger på ett felles prosjekt. Tematiske seksjoner ordner chattene i det. Hver chat definerer en gjentakbar oppgave: registrere inngående fakturaer, forberede kundefakturaer, sjekke betalingsstatus, følge opp salgsmuligheter eller skrive et blogg-utkast hver uke.

Noen oppgaver kjører etter en tidsplan, andre på forespørsel. Begge følger samme oppbygning: felles forretningsinformasjon, en varig oppgavedefinisjon, aktuelle inndata og et resultat som kan kontrolleres.

Connectors gir tilgang til e-post, SharePoint, Google Drive, Teams og CRM-data. Filsystemet og skylagringen holder arbeidsdokumentene og sender resultater videre fra én oppgave til den neste. Denne veiledningen beskriver hvordan du setter opp et slikt system, og hvordan oppgavene virker sammen. Den følger et back office som går slik i en liten bedrift.

Hva et Agentic OS er

Agentic OS er ikke et produkt, men en måte å se det på. En KI-assistent med prosjekter, varige instruksjoner, planlagte oppgaver og connectors gjør for arbeidet i en bedrift det et operativsystem gjør for programmer: Den holder en felles tilstand, kjører programmer etter tidsplan, snakker med enheter via drivere og håndhever tillatelser. Mange observatører beskriver i dag de store leverandørenes plattformer slik; leverandørene selv kaller delene noe annet.

Teknisk sett kan plattformen byttes ut. Claude, ChatGPT, Grok og andre tilbyr byggesteinene — arbeidsområder med varige instruksjoner, gjentakende oppgaver, integrasjoner med andre systemer — under ulike navn og i ulikt omfang; hva en plattform kan i dag, bør du sjekke før du velger. Et vanlig abonnement på assistenten er nok. Arkitekturen denne veiledningen beskriver, er ikke avhengig av valget.

Tre nivåer: prosjekt, chat, kjøring

Arkitekturen har tre nivåer. Prosjektet holder det som gjelder for alle oppgaver. En chat holder én gjentakende oppgave og prosedyren for den. En kjøring er én gjennomføring av oppgaven med dagens inndata — startet av en tidsplan eller en forespørsel, utført via connectors og lokale verktøy og avsluttet med en kontroll av resultatet.

Ett prosjekt for felles forretningsinformasjon

Alle oppgaver hører til ett prosjekt og bygger på samme operative grunnlag. Prosjektet inneholder forretningsregler, dokumentplasseringer, maler, referanseinformasjon, tillatelser og arbeidsrutiner. Tematiske seksjoner gjør oppgavechattene lettere å finne fram i:

Seksjonene ordner arbeidet; den felles prosjektinformasjonen binder det sammen. En kontrakt kan fastsette faktureringsvilkår. Timeføringer gir mengdene. En faktura skaper en betalingsforpliktelse. En banktransaksjon registrerer oppgjøret. Ulike oppgaver håndterer disse trinnene ut fra den samme forretningsinformasjonen.

Hva du fastsetter på prosjektnivå

Prosjektets instruksjoner setter regler som gjelder for alle oppgaver.

Autoritative kilder

Hver type informasjon har en utpekt kilde:

• SharePoint holder registrerte dokumenter og deres attributter.
• Regnskapssjekklisten fastsetter hvilke fakturaer som ventes, og hvor ofte.
• Timelister inneholder de førte timene.
• Godkjente maler bestemmer dokumentenes oppbygning.
• CRM-et holder salgsmuligheter og neste handlinger.
• Driftspostkassen mottar innkommende korrespondanse.

Oppgavene leser aktuell informasjon fra disse kildene. Tidligere dokumenter og samtaler gir kontekst; de utpekte registrene avgjør den aktuelle driftsstatusen.

Forretningsregler

Felles instruksjoner fastsetter rapporteringsperioder, matching av motparter, fakturanummerering, beregninger, avrunding, gjenkjenning av duplikater og hva hver status betyr.

Fakturadato og leveringsperiode er for eksempel separate felt. Måneds-, kvartals- og årsfakturaer følger ulike periodiseringsregler. Salgspriser til kunder og honorarsatser til oppdragstakere brukes hver for seg.

Når en beslutning berører flere oppgaver, legges den til de felles reglene, slik at framtidige kjøringer bruker den.

Organisering av dokumenter

Prosjektet fastsetter hvor originaler, maler, utkast, godkjente dokumenter og behandlingslogger ligger. Nye dokumenter lages som kopi av en godkjent mal. Rettelser gir versjoner som kan identifiseres. Oppgaver lenger ned i kjeden bruker nøyaktig den godkjente filen.

Tillatelser og fullføringskriterier

Instruksjonene fastsetter hvilke handlinger hver oppgave har lov til å utføre. Å forberede et utkast, registrere et dokument, sende en e-post og publisere innhold er separate handlinger, hver med egne fullføringskriterier.

En oppgave melder suksess først etter å ha kontrollert resultatet: Dokumentet finnes, attributtene stemmer, den genererte filen består valideringen, eller sendingen er bekreftet registrert.

Hver chat definerer en gjentakbar oppgave

Hver operativ chat står for en oppgave som kan kjøres igjen og igjen. Chatten holder prosedyren, beslutningene som bare gjelder denne oppgaven, kjøringshistorikken, unntak og resultater. En ny kjøring bringer med seg aktuelle parametere og bruker den fastsatte prosedyren.

En chat for kundefakturering fastsetter for eksempel:

• hvor timene hentes fra;
• hvilke aktiviteter som tas med eller utelates;
• hvilke satser og hvilken valuta som gjelder;
• hvilken mal som kopieres;
• hvordan faktureringsperioden velges;
• hvordan resultatet kontrolleres og godkjennes.

Deretter holder det å be: «Forbered fakturaen for forrige måned.»

En chat for fakturaregistrering følger en annen prosedyre, men bruker den samme informasjonen om motparter, de samme dokumentkonvensjonene og de samme statusdefinisjonene. Detaljer som bare gjelder én oppgave, blir værende hos den. Beslutninger som betyr noe for andre oppgaver, føres inn i den felles prosjektinformasjonen. Filer, registre og logger er de uttrykkelige overleveringene mellom kjøringene.

Oppgavedefinisjon og enkeltkjøring

Skill mellom en varig oppgave og en bestemt kjøring. «Registrere inngående fakturaer» er en oppgave; «behandle filene som kom i morges» er én kjøring. «Lage en månedlig kundefaktura» er en oppgave; «lage fakturaen for oktober» er én kjøring.

Hver oppgavedefinisjon omfatter:

Planlagte og forespurte kjøringer bruker samme oppgavedefinisjon. Utløseren avgjør bare når oppgaven kjører.

Rettelsen av én faktura er en bestemt kjøring i den aktuelle oppgavechatten. Viser den en regel som kan brukes igjen, blir regelen en del av de vedlikeholdte instruksjonene.

Connectors og rollene deres

Jobb helst i assistentens skrivebordsapp, for den kombinerer tilkoblede tjenester med en lokal arbeidsmappe på datamaskinen:

Lokale verktøy tar seg av beregninger, filkonvertering og validering der det trengs.

Tilgang via en connector og forretningsmessig fullmakt håndteres hver for seg. En oppgave bruker de funksjonene prosedyren krever, og de tillatelsene som er fastsatt for kjøringen.

Complaica kobles til på samme måte, via sin MCP-connector. Compliance-oppgaver, som å holde protokollen over behandlingsaktiviteter oppdatert, kjører da i samme prosjekt som økonomi og administrasjon.

Felles lagring fungerer også som kø

Filsystemet, SharePoint og skylagringen har to funksjoner: De lagrer resultater og sender dem videre mellom oppgavene. Hver oppgave skriver resultatet sitt til et avtalt sted. En oppgave lenger ned i kjeden sjekker stedet ved neste kjøring, finner nye elementer og behandler dem. Utpekte mapper, dokumentbiblioteker og behandlingslogger danner slik en enkel kø.

Fakturabehandlingen viser hvordan det fungerer:

1. En planlagt e-postsjekk oppdager en innkommende faktura.
2. Den lagrer vedlegget i inndatamappen til fakturaanalysen.
3. Fakturaanalysen kjører etter sin egen tidsplan.
4. Den leser, validerer og registrerer den nye fakturaen.
5. Dokumentet og attributtene lagres i SharePoint.
6. Den månedlige avstemmingen kontrollerer de registrerte fakturaene mot regnskapssjekklisten.

E-postoppgaven har fullført mottaket når den har kontrollert at vedlegget er lagret. Fakturaanalysen finner filen ved neste kjøring; behandlingsloggene skiller mellom nye, fullførte og delvis behandlede elementer.

Slik kjører oppgavene uavhengig av hverandre etter ulike tidsplaner. Et lagret resultat er tilgjengelig til neste oppgave behandler det.

Økonomi: registrere inngående fakturaer

Oppgaven for fakturaregistrering sjekker inndatamappen med faste mellomrom, for eksempel hver time innenfor driftsvinduet. Dokumenter kommer inn som opplastede filer eller via den tillatte e-postbehandlingen. Oppgaven:

1. finner nye eller delvis behandlede filer;
2. leser og klassifiserer hvert dokument;
3. henter ut motpart, fakturanummer, dato, beløp, valuta og leveringsperiode;
4. sjekker for duplikater;
5. registrerer dokumentet i SharePoint;
6. skriver attributtene og kontrollerer dem;
7. oppdaterer regnskapssjekklisten;
8. logger resultatet.

Duplikatsjekken tar hensyn til forretningsmessige identifikatorer og filens innhold: Samme faktura kan komme mer enn én gang eller under ulike filnavn. Loggen kobler kildefilen til det registrerte dokumentet og til oppdateringen av sjekklisten.

Lykkes registreringen, men oppdateringen av sjekklisten mislykkes, fortsetter neste kjøring med det uferdige trinnet. Den eksisterende registreringen beholdes.

Økonomi: kontrollere at alt er med

Kompletthetsoppgaven kontrollerer om alle ventede fakturaer er registrert. Sjekklisten fastsetter faste motparter, dokumentfrekvens, ventet tidspunkt og hvem som har ansvaret for å utarbeide dem.

Ved månedsstart sammenligner oppgaven disse forventningene med dokumentene som er lagret i SharePoint. En senere gjennomgang sjekker den oppdaterte stillingen før overleveringen til regnskap. Statusmarkører oppsummerer behandlingen:

• R: registrert;
• P: betalt;
• S: overlevert til regnskap.

Kombinerte markører viser hvilke trinn som er fullført. Ventes det flere fakturaer for en periode, gjør ett dokument den ikke komplett; delresultater forklares med henvisninger til de underliggende registreringene.

Uregelmessige utgifter kontrolleres etter registrering, uten at det skapes en forventning om at det skal komme en ny faktura hver måned.

Resultatet viser manglende dokumenter, uavklarte perioder og uferdige handlinger.

Økonomi: lage fakturaer

Egne oppgavechatter håndterer fakturaer for oppdragstakere og kundefakturaer.

For oppdragstakere kan beregningen bygge på timesatser, faste månedsbeløp eller honorar i forhold til ført arbeidstid. Supportgebyrer, ekstra timer og godkjente utlegg står som egne linjer der det trengs.

Kundefakturaer bruker de avtalte salgsvilkårene. Oppgaven velger ut fakturerbare aktiviteter og utelater internt arbeid etter de felles reglene.

Hver kjøring leser aktuelle data, beregner beløpene, kopierer den godkjente malen, fyller inn dokumentopplysningene og lager arbeidsfilen og PDF-en. Valideringen omfatter beregning og presentasjon: Summene må gå opp, og det eksporterte dokumentet må ha lesbare tabeller og fullstendige opplysninger.

Utkast, gjennomgang hos brukeren, ekstern godkjenning og sending har hver sin status. En revidert beregning gir en ny dokumentversjon med egen godkjenningsstatus.

Økonomi: betalinger, avstemming og rapportering

Flere oppgaver dekker betalingskontroll, bankavstemming, kontroll i regnskapssystemet og økonomirapportering:

• Betalinger. Betalingsoppgaven finner registrerte fakturaer med utestående betalingshandlinger.
• Avstemming. Avstemmingsoppgaven kobler banktransaksjoner til dokumenter ved hjelp av identifikatorer, beløp, datoer og betalingsreferanser. Tvetydige treff blir stående åpne for gjennomgang.
• Regnskapskontroll. Det interne dokumentregisteret sammenlignes med regnskapsføringen.

Disse oppgavene gir grunnlag for resultatrapporteringen og den aktuelle likviditeten. Reglene deres holder fakturert aktivitet, betalingsforpliktelser og faktiske kontantbevegelser fra hverandre.

Uavklarte punkter meldes med henvisning til dokumentene og den handlingen eller beslutningen som trengs.

Administrasjon, kontrakter og timeføring

Administrative oppgaver behandler kontrakter, lønnsslipper, skattedokumenter, internrapporter og korrespondanse. Hver dokumentkategori har et lagringssted, obligatoriske attributter og en oppfølgingsrutine.

Kontraktsregistreringen kobler et dokument til den aktuelle motparten og fanger opp de viktige datoene. De felles kontraktsopplysningene støtter deretter fakturering og salgsoppfølging.

Timeføringen har sin egen gjentakende oppgave. Den minner teamet om å fullføre føringene og sjekker om opplysningene er klare for fakturering.

Slik blir en avhengighet uttrykkelig: Fakturalagingen trenger tilstrekkelig komplette timeføringer. Manglende timer blir et synlig unntak før et dokument ferdigstilles.

E-postmottak og behandlingslogger

E-postoppgaven sjekker driftspostkassen med korte mellomrom, for eksempel hvert femte minutt. Meldingene går inn i en behandlingskø med stabile identifikatorer. For hver melding logger oppgaven avsender, emne, behandlingstrinn, utførte handlinger, tilhørende filer, feil og utestående beslutninger.

Tillatte fakturavedlegg legges i økonomiens inndatamappe. Andre meldinger oppsummeres med forslag til neste trinn, innenfor oppgavens tillatelser.

Rapportene skiller mellom et vedlegg som er mottatt, lagret for behandling og registrert.

Gjentatte kjøringer sjekker tidligere resultater før de handler. Det hindrer dobbel behandling og gjentatte varsler om forhold som ikke har endret seg.

Oppgaver for salg, markedsføring og produkt

Salgsoppgavene omfatter tilbudslaging, oppfølging av salgsmuligheter og kontrakter, pipeline-analyse og vedlikehold av CRM. Tilbudslagingen bruker felles maler og kommersielle regler. Oppfølgingen sjekker neste handling, ventet svar og frister som nærmer seg. Andre oppgaver ser på utviklingen hos kundene og muligheter for å utvide samarbeidet.

Markedsføringsoppgavene tar seg av analyse av anbud og frilansoppdrag, forberedelse av kampanjer, oppfølging av målgrupper og produksjon av gjentakende innhold. En ukentlig bloggoppgave får et tema og kildemateriale, lager et utkast og følger den avtalte gjennomgangsrutinen. Forberedelse og utsending av kampanjer har separat fastsatte tillatelser og fullføringskriterier.

Produktseksjonen har en oppgave for vedlikehold av backloggen: Den samler forespørsler, finner duplikater, forbedrer beskrivelser og forbereder elementer for prioritering.

Alle disse oppgavene bruker prosjektets felles forretningskontekst og lagrer resultatene der andre oppgaver kan nå dem.

Kjøringsregler for hele systemet

Hver gjentakende oppgave følger de samme prinsippene:

• Lese aktuelle kildedata.
• Sjekke om handlingen allerede er utført.
• Lagre resultatene på det avtalte stedet.
• Kontrollere resultatet.
• Logge fullførte og uferdige trinn.
• Fortsette påbegynt arbeid ved neste kjøring.
• Melde nye resultater, feil og nødvendige beslutninger.

Arkitekturen gir hver komponent en tydelig rolle. Ett prosjekt holder den felles informasjonen. Tematiske seksjoner ordner chattene. Hver chat definerer en gjentakbar oppgave. Connectors gir tilgang til arbeidssystemene. Felles lagring sender resultater mellom oppgavene. Tidsplaner og forespørsler fra brukerne starter kjøringene.

Slik kan automatiseringen utvides én oppgave om gangen, mens forretningsregler, behandlingshistorikk og driftsresultater forblir koblet sammen.

Sikkerhet og personvern

En assistent som leser e-post, arkiverer dokumenter og skriver i forretningssystemer, trenger faste grenser. Fastsett dem fra starten:

• En egen konto. KI-en bør arbeide under en egen brukerkonto og av bedriftens e-post nå nøyaktig én postkasse: sin egen. I SharePoint og Teams får kontoen bare tilgang til bibliotekene oppgavene trenger, og ingen administratorrettigheter.
• Bare interne avsendere. Postkassen bør bare ta imot e-post fra bedriftens egne ansatte. Et dokument utenfra, for eksempel en faktura fra en leverandør, kommer da bare inn når noen i teamet videresender det. Instruksjoner skjult i en fremmed melding (prompt injection) når dermed ikke fram til KI-en.
• Bekreftelse før endringer. En e-post kan sette i gang en oppgave, men KI-en endrer data først når et menneske har bekreftet endringen.
• Hver endring i git. Legg alle filer på arbeidsdisken i et git-repository, for eksempel i bedriftens Azure DevOps, og gjør hver endring til en commit. Da kan det spores hvem som endret hva og når, og enhver tidligere tilstand kan gjenopprettes.
• Ansattdata blir lokalt. La et skript på den lokale maskinen fylle ut lønnsslippene. Da trenger ikke data om de ansatte å sendes til KI-tjenestens sky.
• Dokumentasjon i Complaica. Protokollen over behandlingsaktiviteter etter art. 30 i GDPR opprettes og oppdateres automatisk i Complaica.

Bare intern e-post: innstillingen i Microsoft 365

I Exchange Online er dette en egenskap ved postkassen. I Exchange admin center (engelsk grensesnitt): Recipients → Mailboxes → velg KI-ens postkasse → Mail flow → Message delivery restrictions, og kryss av for «Require senders to be authenticated» under «Accept messages from». Det samme i Exchange Online PowerShell:

Set-Mailbox -Identity ai@example.com -RequireSenderAuthenticationEnabled $true

Deretter avviser Exchange e-post fra utenfor organisasjonen med en melding om at den ikke kunne leveres — også når den forfalsker en intern avsenderadresse, for det som kontrolleres, er om avsenderen har logget på, ikke adressen i Fra-feltet. Vil du begrense det til bestemte kolleger, tar -AcceptMessagesOnlyFromSendersOrMembers en liste over brukere eller en gruppe.

Compliance-arbeid etter samme mønster

Compliance-arbeid passer inn i samme mønster. Complaica har en innebygd MCP-server og blir én connector til i ChatGPT, Claude eller en annen assistent. En oppgavechat kan da finne avvik mot ISO 27001, registrere vurderinger eller lage en DPIA — med din egen innlogging, og hvert kall kjører med dine roller og din lisens.

Koble Complaica til KI-assistenten din