Aino Tilpassede agenter: AI som leser, resonnerer og ruter

Av Tapio Luostarinen, Janne Uitto, Yen Hoang og Minja Alakoski

Fakturaer som venter på at noen skal sjekke dem mot kontrakten. Risikovurderinger fra leverandører som forfaller, med signaler spredt over avviksregistreringer, kontrakter og sertifiseringer i hele systemet. Inspeksjonsskjemaer som krever at hver måling verifiseres mot produktspesifikasjonen før et parti kan aksepteres. Dette er ikke vanskelige problemer. De er veldefinerte, informasjonen er der, og det riktige svaret er vanligvis klart for alle som tar seg tid til å lese alt. Det er flaskehalsen: noen må gjøre det. AI kan lese alt raskere enn noen annen person. Men når den peker på ustyrt innhold, mapper, flate filer og frakoblede nettsteder, produserer den raske, troverdige og uforklarlige svar. Flaskehalsen var aldri hastighet. Det var hastighet du kunne stole på. Generering er en vare; styrt generering er ikke det.

I dag introduserer vi Aino Tilpassede agenter, AI-drevne arbeidsflyttrinn som leser, resonnerer og handler på dine vegne, konfigurert i naturlig språk av administratorer, uten behov for tilpasset utvikling.

Hvordan det fungerer

En faktura ankommer og går inn i verifiseringsstatus. Når den når godkjenneren, har agenten allerede lest kontrakten, registrert funnene og angitt en anbefalt handling. Ingen har startet det. Arbeidet bare skjedde. For de som nå har en agent i arbeidsflytene sine, er det hele opplevelsen: et trinn som pleide å vente på at noen skulle fullføres, fullføres nå av seg selv.

Bak den opplevelsen har en administrator konfigurert agenten én gang. Administratorer konfigurerer agenter i Automatisering-fanen for en hvilken som helst arbeidsflyttilstand i M-Files Admin. En ledetekst beskriver oppgaven i naturlig språk. Plassholdere for inndata injiserer kontekst fra hvelvet, inkludert det utløsende objektets filer, dets metadata og egenskaper og filer fra relaterte objekter. Plassholdere for utdata definerer nøyaktig hvilke egenskaper agenten har lov til å endre. Alt utenfor disse plassholderne er utenfor rekkevidde, uavhengig av agentens begrunnelse. Én agent per arbeidsflyttilstand; den samme agenten kan brukes på nytt på tvers av flere tilstander og arbeidsflyter .

Slik ser dette ut i praksis

Her er tre scenarioer der kombinasjonen av strukturert innhold og en kunnskapsgraf endrer kvaliteten på svaret.

Fakturaverifisering for underleverandører

Før en underleverandørfaktura kan godkjennes, må den bekreftes: er linjepostene dekket av kontrakten? Samsvarer prisene med prisplanen? Er totalen innenfor det kontrakten tillater?

Dette gjøres manuelt, og betyr å finne riktig kontraktsversjon og lese den side om side mot fakturaen, for hver faktura som kommer inn. Ved høyt volum blir prosessen en flaskehals. Avvik slipper gjennom når kontrollører jobber raskt eller ikke er kjent med prosjekthistorikken.

Når fakturaen går inn i verifiseringsstatus i arbeidsflyten, leser agenten både fakturaen og underkontrakten. Underkontrakten hentes fra underleverandørens relaterte dokumenter i hvelvet, ikke via et søk som kanskje ikke finner riktig versjon, men gjennom en eksplisitt relasjon som alltid er der. Den registrerer funnene sine: hvilke linjeposter som er bekreftet, hvilke som ikke er det, og hva avviket er. Deretter ruter den fakturaen direkte til en menneskelig godkjenner.

Det som endres er det godkjenneren mottar: et strukturert sett med funn som allerede er samlet, som dekker hva som ble fakturert, hva kontrakten tillater, og en anbefalt neste handling. Godkjenneren vurderer hva agenten har avdekket. De trenger ikke å søke etter kontrakten eller lese begge dokumentene fra bunnen av. Hver faktura får samme sjekk, samtidig, uavhengig av kontrollørens arbeidsmengde eller kjennskap til prosjektet.

Leverandørrisikovurdering

De fleste organisasjoner evaluerer leverandører regelmessig, men i praksis er disse evalueringene inkonsekvente. Kvalitetsregistreringer, kontraktsstatus, sertifiseringsutløp, åpne avvik: signalene finnes på tvers av systemet, men det tar tid å sette dem sammen, og evalueringer blir hoppet over når arbeidsmengden er høy. En leverandør med sammensatte risikofaktorer kan virke grei for en anmelder som bare sjekket én kilde.

Dette brukstilfellet gjør at M-Files forskjell konkret. En bruker med et chatverktøy må manuelt samle avviksposter, sjekke kontraktsstatus, slå opp sertifiseringsutløp og deretter lime inn alt i en ledetekst for hver leverandør i hver gjennomgangssyklus. Agenten får alt dette samlet automatisk fordi informasjonen allerede finnes som tilkoblede objekter i hvelvet. Det er ikke noe dokument å lime inn. Alle inndata (leverandørkategori, startdato for relasjon, avviksposter, kontraktsstatus, sertifiseringsutløp) kommer fra metadata og objektrelasjoner som er løst under kjøretid. Agenten gjennomgår disse relasjonene, setter sammen hele bildet og resonnerer over det.

Poengspørsmålet bruker deterministiske gulvkriterier: en utløpt sertifisering eller et åpent avvik utløser alltid minst en middels risikovurdering. En eskaleringsinstruksjon lar agenten resonnere om sammensatt risiko når kombinasjonen eller konteksten av funn berettiger et høyere nivå. Agenten registrerer et risikonivå, en kort forklaring av begrunnelsen og en neste gjennomgangsdato beregnet ut fra tidsplanen definert i spørsmålet. Leverandører vurdert som høy går over til en menneskelig gjennomgangstilstand; alle andre går automatisk tilbake til aktiv og planlegges for sin neste vurdering. Hver leverandør i systemet får en fullstendig vurdering i hver syklus, ikke bare de noen hadde tid til å se på.

Innkommende inspeksjon: måleverifisering

Når en leverandør leverer et parti med produkter, inkluderer de et inspeksjonsskjema som dokumenterer de målte verdiene for leveransen. Før partiet kan aksepteres, må hver måling finnes, sammenlignes med den tillatte toleransen, og eventuelle avvik eller manglende verdier må flagges. Oppgaven er detaljrik og repeterende, og utmattingsfeil er akkurat den typen feil som slipper gjennom et parti som ikke samsvarer.

Dette gjøres manuelt, der kontrolløren leser inspeksjonsarket, finner produktspesifikasjonen og kryssrefererer hver måling én etter én. Når inspeksjonsvolumet er høyt, eller den samme personen gjennomgår mange lignende ark i rekkefølge, blir prosessen både en flaskehals og en belastning.

Når inspeksjonsarket går inn i analysetilstand i arbeidsflyten, leser agenten det sammen med produktets designdokument, hentet gjennom objektrelasjonskjeden i hvelvet. En anmelder som bruker et generisk AI-verktøy, må finne riktig spesifikasjon, finne ut hvilke målinger som gjelder for denne produkttypen, og mate alt inn i en ledetekst. Her vet hvelvet allerede: produktet lenker til designdokumentet, og produktets metadata definerer hvilke målinger som kreves for innkommende inspeksjon. Agenten kontrollerer at nøyaktig disse målingene er tilstede i inspeksjonsarket og innenfor toleransene som er definert i spesifikasjonen. Å legge til et nytt produkt betyr å opprette et designdokument og angi de nødvendige målingene i produktposten. Selve agentkonfigurasjonen trenger aldri å endres.

Agenten produserer en strukturert valideringsliste: alle nødvendige målinger, tillatt område fra designdokumentet, og om de er innenfor toleransen, utenfor den eller mangler fra inspeksjonsarket. Basert på funnene styrer den arbeidsflytovergangen direkte. Ark der alle nødvendige målinger er tilstede og innenfor toleransen godtas automatisk; ethvert avvik eller manglende verdi sender arket til en menneskelig gransker for løsning. Ingen kø, ingen manuell rutingsbeslutning.

Styrt AI, forklarbar gjennom design

Hver agenthandling kjører innenfor sikkerhetsrekkverk angitt av administratoren. Tillatelser følger tilstand: agenten ser bare det ledeteksten definerer den skal se, og endrer bare det den har fått tillatelse til å endre. Utdataplassholderne i ledeteksten definerer det komplette settet med egenskaper agenten kan endre. Ingen egenskaper utenfor denne listen kan endres, uavhengig av hva agentens resonnement måtte antyde.

Det som gjør dette til mer enn bare en konfigurasjonssikkerhetsmekanisme, er hva som skjer etter at agenten har handlet. Hver verdi agenten angir er merket på metadatakortet med en AI-indikator. Ved å klikke på den åpnes agentens begrunnelse, forklaringen på hvorfor verdien ble valgt, basert på kildeinnholdet agenten leste. En kontraktsansvarlig kan se nøyaktig hvorfor en fakturalinjepost ble flagget. En kvalitetsingeniør kan bekrefte hva agenten sammenlignet en måling mot. En innkjøpsansvarlig kan lese hele grunnlaget for en leverandørs risikovurdering før vedkommende handler ut fra den.

Denne resonnementet forblir tilgjengelig i versjonshistorikken selv etter at verdien har blitt endret eller overstyrt av et menneske. Beslutningsregistrering er et førsteklasses artefakt: den opprinnelige AI-resonnementet og begrunnelsen forblir en del av registreringen, ikke bare resultatet.

For organisasjoner som opererer i regulerte miljøer, er dette spesielt viktig. EUs KI-lov krever at KI-systemer som brukes i profesjonell beslutningstaking skal være transparente, forklarbare og reviderbare. M-Files «Perpetent resonnement-arkitektur» adresserer disse kravene direkte: hver AI-drevet metadataverdi har en sporbar forklaring, knyttet til kildeinnholdet, lagret med objektet og tilgjengelig for alle som trenger å gjennomgå den. Revisjonssporet er ikke en separat rapport. Det er produktet, innebygd i dokumentposten.

Etter hvert som agentens nøyaktighet blir tydeligere over tid, kan arbeidsflyter utvikle seg. Et menneskelig gjennomgangstrinn som ga mening i starten kan bli unødvendig når agentens anbefalinger har vist seg å være pålitelige, og det strukturerte resultatet agenten produserer gjør overgangen enkel når organisasjonen er klar for det.

Arbeidet som pleide å vente på noen, er nå det arbeidet som blir gjort først, med en fullstendig oversikt over hvordan og hvorfor.

Hva dette betyr for din organisasjon

Hver faktura får samme verifisering. Hver leverandør får en fullstendig risikovurdering i hver syklus. Hvert inspeksjonsark kontrolleres mot spesifikasjonen før et menneske i det hele tatt ser det. Arbeidet skaleres uten å skalere teamet, og hver avgjørelse agenten tar er forklarbar, sporbar og reviderbar fra selve dokumentasjonen.

Tilgjengelig nå i beta
Aino Tilpassede agenter er tilgjengelig i betaversjon fra og med utgivelsen 24. juni 2026. Aino Custom Agents – Administratorveiledning tar deg med fra oppsettet til din første konfigurerte agent.