M-Files agentit: tekoäly, joka lukee, päättelee ja ohjaa

Kirjoittajat: Tapio Luostarinen, Janne Uitto, Yen Hoang ja Minja Alakoski

Laskut, jotka odottavat, että joku tarkistaa ne sopimuksen perusteella. Erääntyneet toimittajien riskinarvioinnit, joiden viitteet ovat hajallaan järjestelmän eri osissa olevissa vaatimustenvastaisuusraporteissa, sopimuksissa ja sertifikaateissa. Tarkastuslomakkeet, joissa jokainen mittaus on tarkistettava tuotespesifikaation perusteella ennen kuin erä voidaan hyväksyä. Nämä eivät ole vaikeita ongelmia. Ne ovat selkeästi määriteltyjä, tiedot ovat saatavilla, ja oikea vastaus on yleensä selvä kaikille, jotka viitsivät lukea kaiken läpi. Siinä on pullonkaula: jonkun on tehtävä se. Tekoäly pystyy lukemaan kaiken tämän nopeammin kuin kukaan ihminen. Mutta kun se kohdistetaan hallitsemattomaan sisältöön, kansioihin, tekstitiedostoihin ja erillisiin sivustoihin, se tuottaa nopeita, uskottavia mutta vastuuttomia vastauksia. Pullonkaula ei ole koskaan ollut nopeus. Se on ollut nopeus, johon voi luottaa. Sisällön tuottaminen on tavaraa; hallittu sisällöntuotanto ei ole.

Esittelemme tänään M-Files Agents -toiminnon, joka koostuu tekoälypohjaisista työnkulun vaiheista, jotka lukevat, päättelevät ja toimivat käyttäjän puolesta. Järjestelmänvalvojat voivat määrittää ne luonnollisella kielellä ilman, että tarvitaan erillistä sovelluskehitystä.

Kuinka se toimii

Lasku saapuu ja siirtyy tarkastusvaiheeseen. Kun se päätyy hyväksyjän käsiteltäväksi, agentti on jo lukenut sopimuksen, kirjannut havainnot ja määrittänyt suositellun toimenpiteen. Kukaan ei käynnistänyt prosessia. Työ vain hoituu itsestään. Niille, joiden työnkulkuun agentti on nyt integroitu, tämä on koko kokemus: vaihe, joka aiemmin odotti jonkun toimia, hoituu nyt itsestään.

Tämän toiminnon taustalla järjestelmänvalvoja on määrittänyt agentin kerran. Järjestelmänvalvojat määrittävät agentit M-Files minkä tahansa työnkulun tilan ”Automaatio”-välilehdessä. Tehtävää kuvataan luonnollisella kielellä näkyvässä ohjeessa. Syöttöpaikat tuovat kontekstia arkistosta, mukaan lukien laukaisijan tiedostot, sen metatiedot sekä ominaisuudet ja tiedostot liitännäisistä kohteista. Tulostuspaikat määrittelevät tarkasti, mitä ominaisuuksia agentti saa muuttaa. Kaikki näiden paikkamerkkien ulkopuolella oleva on kiellettyä, riippumatta agentin päättelystä. Yksi agentti kutakin työnkulun tilaa kohti; samaa agenttia voidaan käyttää uudelleen useissa tiloissa ja työnkuluissa.

Miltä tämä näyttää käytännössä

Seuraavassa on kolme esimerkkiä tilanteista, joissa jäsennellyn sisällön ja tietograafin yhdistelmä vaikuttaa vastauksen laatuun.

Alihankkijoiden laskujen tarkastus

Ennen kuin alihankkijan lasku voidaan hyväksyä, se on tarkistettava: sisältyvätkö laskun erät sopimuksen piiriin? Vastaavatko hinnat hinnastoa? Onko kokonaissumma sopimuksessa sallitun rajoissa?

Manuaalisesti suoritettuna tämä tarkoittaa, että jokaisen saapuvan laskun kohdalla on etsittävä oikea sopimusversio ja verrattava sitä laskuun rinnakkain. Suurilla volyymeillä prosessista tulee pullonkaula. Poikkeamia jää huomaamatta, kun tarkastajat työskentelevät kiireessä tai eivät tunne projektin taustaa.

Kun lasku siirtyy työnkulussaan tarkastusvaiheeseen, käsittelijä lukee sekä laskun että alihankintasopimuksen. Alihankintasopimus haetaan alihankkijan asiakirjoista arkistosta – ei hakukyselyn avulla, joka saattaa löytää oikean version tai olla löytämättä sitä, vaan aina olemassa olevan nimenomaisen yhteyden kautta. Asiakaspalvelija kirjaa havainnot: mitkä rivit on vahvistettu, mitkä eivät ja mikä on eroavaisuus. Sen jälkeen lasku ohjataan suoraan ihmisen hyväksyjälle.

Muutos koskee sitä, mitä hyväksyjä saa: valmiiksi kootun, jäsennellyn yhteenvedon havainnoista, joka kattaa laskutetut erät, sopimuksen sallimat ehdot sekä suosituksen seuraavasta toimesta. Hyväksyjä arvioi oman harkintansa mukaan, mitä asiamies on tuonut esiin. Hänen ei tarvitse etsiä sopimusta tai lukea molempia asiakirjoja alusta alkaen. Jokainen lasku käydään läpi samalla tavalla ja samassa ajassa riippumatta tarkastajan työmäärästä tai perehtyneisyydestä projektiin.

Toimittajien riskien pisteytys

Useimmat organisaatiot arvioivat toimittajiaan säännöllisin väliajoin, mutta käytännössä nämä arvioinnit ovat epäjohdonmukaisia. Laatuasiakirjat, sopimusten tila, sertifikaattien voimassaolon päättyminen, avoimet poikkeamat: merkkejä on järjestelmän eri osissa, mutta niiden kokoaminen vie aikaa, ja arviointeja jätetään väliin, kun työmäärä on suuri. Toimittaja, jolla on useita riskitekijöitä, voi vaikuttaa kunnolliselta arvioijalle, joka on tarkistanut vain yhden lähteen.

Tämä käyttötapaus havainnollistaa konkreettisesti M-Files . Chat-työkalua käyttävän käyttäjän olisi jokaisen toimittajan ja jokaisen tarkastusjakson osalta koottava manuaalisesti yhteen poikkeamatiedot, tarkistettava sopimuksen tila, selvitettävä sertifikaatin voimassaolon päättymispäivä ja liitettävä kaikki nämä tiedot keskustelukenttään. Asiakaspalvelija saa kaikki nämä tiedot koottuna automaattisesti, koska tiedot ovat jo olemassa toisiinsa linkitettyinä objekteina arkistossa. Mitään asiakirjaa ei tarvitse liittää. Kaikki syötetyt tiedot (toimittajaluokka, suhteen alkamispäivä, poikkeamatiedot, sopimuksen tila, sertifikaatin voimassaolon päättymispäivä) perustuvat metatietoihin ja objektien välisiin suhteisiin, jotka määritetään suorituksen aikana. Agentti käy läpi nämä suhteet, kokoaa kokonaiskuvan ja tekee siitä johtopäätöksiä.

Arviointikehote soveltaa deterministisiä vähimmäiskriteerejä: vanhentunut sertifikaatti tai avoin vaatimustenvastaisuus johtaa aina vähintään ”Keskitason” riskiluokitukseen. Eskalointiohjeen avulla agentti voi arvioida yhdistettyä riskiä, kun havaintojen yhdistelmä tai konteksti edellyttää korkeampaa tasoa. Agentti kirjaa riskitason, lyhyen selityksen perusteluistaan sekä seuraavan tarkastuspäivän, joka lasketaan ohjeessa määritetyn aikataulun perusteella. Korkeaksi luokitellut toimittajat siirretään ihmisen suorittamaan tarkastukseen; kaikki muut palautuvat automaattisesti aktiiviseen tilaan ja niille varataan aika seuraavaan arviointiin. Jokainen järjestelmässä oleva toimittaja saa täyden arvioinnin jokaisella kierroksella, ei vain ne, joita joku ehti tarkastella.

Saapuvan tavaran tarkastus: mittausten tarkistaminen

Kun toimittaja toimittaa tuote-erän, se liittää mukaan tarkastuslomakkeen, johon on kirjattu kyseisen toimituksen mittausarvot. Ennen kuin erä voidaan hyväksyä, jokainen mittausarvo on löydettävä, verrattava sallittuun toleranssiin ja mahdolliset poikkeamat tai puuttuvat arvot on merkittävä. Tehtävä on yksityiskohtainen ja toistuva, ja väsymyksestä johtuvat virheet ovat juuri niitä virheitä, joiden vuoksi vaatimustenvastainen erä pääsee läpi.

Manuaalisesti suoritettuna tarkastaja lukee tarkastuslomakkeen, etsii tuotteen tekniset tiedot ja vertaa jokaista mittaustulosta yksi kerrallaan. Kun tarkastusten määrä on suuri tai kun sama henkilö tarkastaa peräkkäin useita samankaltaisia lomakkeita, prosessista tulee sekä pullonkaula että riski.

Kun tarkastuslomake siirtyy työnkulussaan ”Analyysi”-tilaan, agentti lukee sen yhdessä tuotteen suunnitteludokumentin kanssa, joka haetaan varaston objektisuhdeketjun kautta. Yleistä tekoälytyökalua käyttävän tarkastajan olisi löydettävä oikea spesifikaatio, selvitettävä, mitkä mittaukset koskevat tätä tuotetyyppiä, ja syötettävä kaikki tiedot komentoriville. Tässä tapauksessa tietovarasto tietää nämä tiedot jo valmiiksi: tuote on linkitetty sen suunnitteludokumenttiin, ja tuotteen metatiedot määrittelevät, mitkä mittaukset vaaditaan saapuvan tavaran tarkastuksessa. Agentti tarkistaa, että juuri nämä mittaukset ovat läsnä tarkastuslomakkeessa ja että ne ovat spesifikaatiossa määriteltyjen toleranssien rajoissa. Uuden tuotteen lisääminen tarkoittaa suunnitteludokumentin luomista ja vaadittujen mittausten asettamista tuotetietueeseen. Itse agentin konfiguraatiota ei tarvitse koskaan muuttaa.

Järjestelmä laatii jäsennellyn tarkastuslistan: jokainen vaadittu mittaus, sen suunnitteluasiakirjassa määritelty sallittu vaihteluväli sekä tieto siitä, onko mittaus toleranssin sisällä, sen ulkopuolella vai puuttuuko se tarkastuslomakkeelta. Tulosten perusteella järjestelmä ohjaa työnkulun etenemistä suoraan. Lomakkeet, joissa kaikki vaaditut mittaukset ovat mukana ja toleranssin sisällä, hyväksytään automaattisesti; mikä tahansa poikkeama tai puuttuva arvo ohjaa lomakkeen ihmistarkastajalle ratkaistavaksi. Ei jonotusta, ei manuaalisia reitityspäätöksiä.

Säännelty tekoäly, selitettävissä jo suunnitteluvaiheessa

Jokainen agentin toiminto suoritetaan järjestelmänvalvojan asettamien rajojen puitteissa. Käyttöoikeudet määräytyvät tilan mukaan: agentti näkee vain sen, mitä kehote sille määrittelee, ja muuttaa vain sitä, mitä sille on annettu lupa muuttaa. Kehotteen tulostuspaikkamerkit määrittelevät kaiken ne ominaisuudet, joita agentti voi muuttaa. Mitään kyseisen luettelon ulkopuolista ominaisuutta ei voida muuttaa, riippumatta siitä, mitä agentin päättely saattaisi viitata.

Se, mikä tekee tästä enemmän kuin pelkkän konfiguraatiosuojauksen, on se, mitä tapahtuu agentin toimien jälkeen. Jokainen agentin asettama arvo merkitään metatietokorttiin tekoälymerkillä. Sitä napsauttamalla avautuu agentin päättelyprosessi, eli selitys sille, miksi kyseinen arvo valittiin, perustuen lähdesisältöön, jonka agentti on lukenut. Sopimusvastaava voi nähdä tarkalleen, miksi laskun rivikohta on merkitty. Laatuinsinööri voi tarkistaa, mihin agentti on verrannut mittaustulosta. Hankintavastaava voi lukea toimittajan riskiluokituksen kaikki perustelut ennen kuin ryhtyy toimenpiteisiin.

Tämä päättelyprosessi säilyy näkyvissä versiohistoriassa, vaikka arvo olisi muutettu tai korvattu ihmisen toimesta. Päätöksen tallentaminen on ensisijaisen tärkeä osa prosessia: alkuperäinen tekoälyn päättely ja sen perustelut säilyvät osana tallennetta, ei pelkästään lopputulos.

Säännellyissä ympäristöissä toimiville organisaatioille tällä on erityinen merkitys. EU:n tekoälylaki edellyttää, että ammatillisessa päätöksenteossa käytettävien tekoälyjärjestelmien on oltava läpinäkyviä, selitettävissä olevia ja tarkastettavissa olevia. M-Files pysyvä päättelyarkkitehtuuri täyttää nämä vaatimukset suoraan: jokaisella tekoälypohjaisella metatietoarvolla on jäljitettävä selitys, joka on sidottu lähdesisältöön, tallennettu objektin mukana ja saatavilla kaikille, joiden on tarpeen tarkistaa se. Tarkastusjälki ei ole erillinen raportti, vaan se on osa tuotetta, joka on integroitu asiakirjatallenteeseen.

Kun agentin tarkkuus selviää ajan myötä, työnkulkuja voidaan kehittää. Alun perin järkevä ihmisen suorittama tarkistusvaihe voi käydä tarpeettomaksi, kun agentin suositukset ovat osoittautuneet luotettaviksi, ja agentin tuottama jäsennelty tuloste helpottaa tätä siirtymää, kun organisaatio on siihen valmis.

Työ, joka aiemmin jäi odottamaan jotakuta, hoidetaan nyt ensimmäisenä, ja siitä jää kattava kirjanpito siitä, miten ja miksi se tehtiin.

Mitä tämä tarkoittaa organisaatiollenne

Jokainen lasku käy läpi saman tarkastusprosessin. Jokaisesta toimittajasta tehdään kattava riskinarviointi jokaisella kierroksella. Jokainen tarkastuslomake tarkistetaan vaatimusten mukaisesti ennen kuin ihminen edes näkee sen. Työ skaalautuu ilman, että tiimiä tarvitsee laajentaa, ja jokainen agentin tekemä päätös on perusteltavissa, jäljitettävissä ja tarkastettavissa itse asiakirja-arkistosta.

Nyt saatavilla beetaversiona
M-Files Agents on saatavilla beetaversiona 24. kesäkuuta 2026 julkaistusta versiosta lähtien. M-Files Agents -järjestelmänvalvojan opas opastaa sinut asennuksesta ensimmäisen määritetyn agentin käyttöönottoon.