Kysy keneltä tahansa laitospäälliköltä, saako kattilan ajotapa, kulutusprofiili ja hälytyshistoria vuotaa kilpailijalle. Vastaus on aina sama. Kysy sitten, mitä tapahtuu kun sama aineisto liitetään pilvipalvelun kyselyyn — ja vastaus muuttuu epävarmaksi. Tässä on teollisuuden tekoäly pähkinänkuoressa: tekninen kysymys, jonka takana on hallintakysymys.
Keskustelu kääntyy yleensä siihen, mikä malli on paras. Se on väärä ensimmäinen kysymys. Ensimmäinen kysymys on, missä malli ajetaan — koska se ratkaisee, mihin data menee, kuka sen näkee, mitä analyysi maksaa kolmantena vuotena ja toimiiko se silloin kun verkko on poikki.
Tässä artikkelissa käyn läpi neljä syytä, miksi teollisessa ympäristössä malli kannattaa ajaa laitoksen omalla palvelimella, mitä se konkreettisesti vaatii raudalta — ja rehellisesti myös sen, missä paikallinen malli häviää pilvimallille.
Miksi teollisuuden tekoäly törmää kysymykseen datan sijainnista
Prosessidata ei ole tavallista yritysdataa. Se on tarkka kuvaus siitä, miten laitos ajetaan: mihin hyötysuhteeseen kattila pystyy, mikä on todellinen kulutus tuotettua yksikköä kohti, missä tuotantoketjun pullonkaula on ja kuinka usein jokin rikkoutuu. Siitä voi lukea suoraan kilpailukyvyn — ja usein myös sen, mistä kohtaa laitos on haavoittuva.
Kun tällaista aineistoa käytetään pilvipalvelun kyselyssä, siitä seuraa neljä kysymystä, joihin pitäisi olla vastaus ennen kuin ensimmäinen kysely lähetetään:
- Missä data käsitellään ja missä se säilyy? Palvelun sijainti ja alihankkijaketju eivät aina ole yksiselitteisiä, eivätkä ne pysy samoina sopimuskauden yli.
- Käytetäänkö sitä mallin kehittämiseen? Ehdot vaihtelevat palveluittain ja sopimustasoittain, ja ne muuttuvat.
- Kuka pääsee siihen käsiksi? Palveluntarjoajan oma henkilöstö, alihankkijat, viranomaiset — vastaus riippuu lainkäyttöalueesta.
- Mitä tapahtuu, jos palvelu loppuu? Analyysihistoria, kehotteet ja integraatiot ovat sidoksissa palveluun, jota ei omista.
Mikään näistä ei ole ylitsepääsemätön este. Mutta jokainen niistä on asia, joka pitää selvittää, dokumentoida ja tarkistaa uudelleen aina kun sopimusehdot muuttuvat. Paikallinen ratkaisu poistaa koko kysymyssarjan kerralla — ei siksi, että se olisi hallinnollisesti fiksumpi, vaan siksi, ettei siirtoa tapahdu.
Tämä on syy, miksi teollisuudessa teollisuuden tekoäly etenee hitaammin kuin toimistotyössä. Este ei ole tekninen. Este on se, ettei kukaan halua olla se, joka päätti lähettää laitoksen ajotavan ulos verkosta.
Neljä syytä pitää malli laitoksen omalla palvelimella
1. Data ei liiku, joten sitä ei tarvitse suojata matkalla
Kun kielimalli on prosessi samalla koneella kuin tietokanta, analyysissä käytetty aineisto ei poistu palvelimelta. Ei API-avainta ulkopuoliselle, ei siirtoyhteyttä suojattavana, ei kysymystä siitä päätyykö aineisto jonkin mallin koulutusdataan. Tämä ei ole asetus, jonka voi vahingossa kytkeä pois — se on seuraus siitä, missä ohjelma ajetaan.
2. Kustannus on tiedossa etukäteen
Pilvimallin hinta on käytön funktio: mitä enemmän analyysia, sitä suurempi lasku. Se on huono kannustin juuri siellä, missä analyysia pitäisi tehdä enemmän. Omalla palvelimella ajettu malli maksaa kertaluontoisesti, ja kyselyiden määrä ei muuta laskua. Kolmen vuoden kokonaiskustannus on laskettavissa ennen kuin ensimmäistäkään kyselyä on tehty.
3. Analyysi ei katkea, kun verkko katkeaa
Teollisuuslaitos toimii, vaikka toimiston internet-yhteys ei toimisi. Jos analyysityökalu vaatii yhteyden ulos, se ei ole käytettävissä juuri silloin kun tilanne on poikkeuksellinen. Paikallinen malli toimii myös kokonaan suljetussa verkossa, jossa palvelimella ei ole reittiä internetiin lainkaan.
4. Havainto on jäljitettävissä lähtödataan
Analyysi on käyttökelpoinen vasta, kun sen voi tarkistaa. Kun malli lukee saman tietokannan, jossa mittausdata on, jokainen havainto on sidottavissa mittapisteeseen ja aikaväliin. Silloin väitteen voi todentaa raakadatasta — eikä analyysin uskottavuus riipu siitä, miten hyvin se on kirjoitettu.
Neljäs kohta on käytännössä se, joka ratkaisee, käytetäänkö työkalua puolen vuoden päästä. Kielimallin kirjoittama yhteenveto on lähtökohta, ei todiste. Jos havaintoa ei voi jäljittää mittapisteeseen, siitä ei uskalleta tehdä päätöksiä — ja työkalu jää käyttämättä riippumatta siitä, kuinka hyvältä teksti näyttää.
Kolmas kohta ansaitsee tarkennuksen, koska se ymmärretään usein väärin. Suljettu verkko ei tarkoita sitä, että palvelin olisi vaikeasti käytettävissä. Käyttöliittymä toimii laitoksen sisäverkossa normaalisti selaimella, ja analyysi käynnistyy samasta näkymästä kuin muutkin toiminnot. Ainoa asia, jota ei ole, on reitti ulos — ja juuri se on monessa tuotantoverkossa palomuurisääntö, jota ei muuteta yhden työkalun takia.
Mitä paikallisen mallin ajaminen oikeasti vaatii palvelimelta
Yleisin väärinkäsitys on, että paikallinen kielimalli vaatii palvelinsalin ja näytönohjainrivistön. Teollisuuden analyysikäytössä vaatimus on huomattavasti maltillisempi, koska kyselyitä on vähän ja ne ovat lyhyitä — kyse ei ole chat-palvelusta tuhannelle käyttäjälle vaan muutamasta analyysistä päivässä.
Käytännön mitoitus DataPortian™ tekoälymoduulissa näyttää tältä:
| Osa-alue | Vaatimus | Huomioitavaa |
|---|---|---|
| Muisti | Minimi 8 GB RAM, suositus 16–32 GB | Malli varaa muistia koko ajon ajaksi. Tekoälymoduulia käytettäessä kannattaa valita suosituksen yläpää. |
| Levy | 100 GB SSD | Sisältää mallin, tietokannan ja aikasarjahistorian. |
| Näytönohjain | Ei minimivaatimuksissa | Ilman erillistä näytönohjainta vastaus valmistuu hitaammin, mutta se valmistuu. |
| Käyttöjärjestelmä | Windows 10/11, Windows Server 2016+, Linux (Debian, Ubuntu) | Sama palvelin kuin tiedonkeruulla ja tietokannalla. |
| Tietolähde | PostgreSQL 18 + TimescaleDB | Malli lukee saman aikasarjatietokannan, johon mittaukset tallennetaan. |
Malli itse ajetaan Ollamalla, ja käytettävissä olevat mallit ovat avoimia: Qwen, Gemma, DeepSeek ja Llama. Malli valitaan ja asennetaan käyttöönoton yhteydessä, minkä jälkeen analyysi toimii myös suljetussa verkossa. Käytännössä tämä tarkoittaa, että teollisuuden tekoäly mahtuu samalle koneelle, joka laitoksella jo on — ei uuteen investointiin.
Yksi mitoituskysymys jää usein kysymättä: kuinka pitkälle taaksepäin analyysin pitää ulottua. Malli lukee saman aikasarjatietokannan kuin trendinäkymät, joten analyysin ulottuvuus on täsmälleen se, miksi säilytysaika on asetettu — käytännössä usein kahdenkymmenenneljän kuukauden luokkaa. Levytila mitoitetaan sen mukaan, ei mallin mukaan, koska aikasarjahistoria vie moninkertaisesti enemmän tilaa kuin itse kielimalli.
- 8 GB
- RAM on minimivaatimus. Se on vähemmän kuin tavallisessa toimistokannettavassa — ja se on koko se raudan lisäys, jonka paikallinen malli tyypillisessä laitosasennuksessa vaatii.
Missä paikallinen malli häviää pilvimallille — rehellinen vertailu
Paikallinen malli ei ole pilvimallia parempi. Se on erilainen, ja ero kannattaa sanoa suoraan, koska väärin asetettu odotus on nopein tapa saada työkalu hylätyksi.
| Ominaisuus | Paikallinen malli | Pilvimalli |
|---|---|---|
| Datan sijainti | Ei poistu laitokselta | Siirtyy palveluntarjoajalle |
| Vastausnopeus | Hitaampi, erityisesti ilman näytönohjainta | Nopea |
| Päättely pitkissä kysymyksissä | Karkeampaa; malli on pienempi | Tarkempaa |
| Kustannusmalli | Kertamaksu, ei kyselykohtaisia maksuja | Käytön mukaan |
| Toiminta ilman internetiä | Toimii | Ei toimi |
| Yleistieto maailmasta | Suppeampi | Laajempi |
Valinta seuraa siitä, mikä vaatimus on tiukempi. Jos vaatimuksena on nopein mahdollinen vastaus mihin tahansa kysymykseen, paikallinen malli ei ole oikea valinta. Jos vaatimuksena on, ettei prosessidata poistu laitokselta, se on ainoa valinta.
Teollisessa analyysissä kysymykset ovat onneksi kapeita ja aineisto on numeerista: "mitkä pisteet poikkesivat viime viikolla", "miten kulutus kehittyi edelliseen jaksoon verrattuna", "mitkä hälytykset toistuivat eniten". Näihin pienempi malli riittää, koska työn tekee data — ei mallin maailmantieto.
Miten valinnan voi testata ennen päätöstä
Arkkitehtuurivalintaa ei tarvitse tehdä paperilla. Kokeilujakso vastaa kolmeen kysymykseen, joihin mikään vertailutaulukko ei vastaa:
- Riittääkö vastausten laatu teidän kysymyksiinne? Tämä ratkeaa vain teidän omilla mittapisteillänne ja teidän sanastollanne — laitoksen oma nimeämiskäytäntö vaikuttaa tulokseen enemmän kuin mallin koko.
- Onko vastausaika käytännössä ongelma? Kymmenien sekuntien odotus on eri asia interaktiivisessa keskustelussa kuin viikkoanalyysissä, joka käynnistetään kerran ja luetaan kerran.
- Riittääkö palvelimen muisti? Tämä näkyy heti ensimmäisellä ajolla, eikä siitä tarvitse tehdä arviota etukäteen.
Kaksi viikkoa omalla datalla kertoo enemmän kuin mikään mallivertailu. Syy on yksinkertainen: teollisen analyysin laatu riippuu ennen kaikkea siitä, kuinka hyvin data on kerätty — ei siitä, kuinka suuri malli sitä lukee. Aukkoinen tai väärin aikaleimattu aikasarja tuottaa huonon analyysin millä tahansa mallilla, ja päinvastoin ehjä aineisto tekee pienestäkin mallista käyttökelpoisen.
Käytännön esimerkki: prosessiteollisuuden kuukausianalyysi ilman internet-yhteyttä
Prosessilaitos: sama kuukausianalyysi kahdella eri arkkitehtuurilla
Käytännön esimerkki
Pilvipohjainen analyysi
- Kuukauden mittausdata vietiin tiedostona analyysipalveluun
- Vienti vaati tietosuoja-arvion ja sisäisen hyväksynnän joka kerta
- Käytännössä analyysi tehtiin kerran kuussa, koska prosessi oli raskas
- Kustannus kasvoi aineiston koon mukana
- Tuotantoverkon palvelimelta ei ollut reittiä ulos — vienti tehtiin käsin
- Havaintoa ei voinut klikata auki lähtödataan
Paikallinen malli samalla palvelimella
- Analyysi käynnistetään suoraan siitä näkymästä, jossa data jo on
- Ei vientiä, ei hyväksyntäkierrosta, ei tiedostoja liikkeellä
- Analyysi ajetaan viikoittain, koska se ei maksa erikseen
- Palvelin on irti internetistä — analyysi toimii silti
- Vastaus valmistuu hitaammin, tyypillisesti kymmenissä sekunneissa
- Jokainen havainto on sidottu mittapisteeseen ja aikaväliin
Ratkaiseva ero ei ole analyysin laatu vaan sen tiheys. Kun yhden analyysin marginaalikustannus ja hallinnollinen kitka putoavat nollaan, analyysi lakkaa olemasta projekti ja muuttuu tavaksi. Kerran kuussa tehty tarkastelu löytää poikkeaman keskimäärin kahden viikon viiveellä; viikoittain tehty löytää sen kolmessa päivässä — samalla mallilla ja samalla datalla.
Käytännön analyysityypit ovat samat riippumatta siitä, missä malli ajetaan: poikkeamien tunnistus, ennuste mitatusta historiasta, kulutuksen ja ajotapojen vertailu jaksojen välillä sekä rakenteinen yhteenveto havainnoista. Lisäksi aineistosta voi esittää vapaan kysymyksen tavallisella kielellä, esimerkiksi miten kattilan kulutus kehittyi viime viikolla — jolloin moduuli hakee kysymykseen liittyvät mittapisteet tietokannasta ja vastaa niiden perusteella eikä yleistiedon perusteella. DataPortian tekoälymoduulissa nämä ovat 499 euron lisäosa perustuotteen päälle, eikä kyselyistä veloiteta erikseen.
Yhteenveto: teollisuuden tekoäly on arkkitehtuurivalinta, ei mallivalinta
Mallit vaihtuvat vuosittain. Se, missä malli ajetaan, on päätös joka kestää pidempään kuin yksikään yksittäinen malli — ja se on myös ainoa päätös, jota on hankala perua jälkikäteen.
Tärkeimmät opit:
- Ensimmäinen kysymys on sijainti, ei malli. Se ratkaisee datan hallinnan, kustannusmallin ja saatavuuden kerralla.
- Rautavaatimus on maltillisempi kuin luullaan. 8 GB RAM minimissä, 16–32 GB suosituksena, ei erillistä näytönohjainta.
- Paikallinen malli on hitaampi ja karkeampi. Teollisessa analyysissä se riittää, koska kysymykset ovat kapeita ja työn tekee data.
- Jäljitettävyys ratkaisee käytön. Havainto, jota ei voi tarkistaa mittapisteestä, ei muutu päätökseksi.
- Tiheys on tärkeämpää kuin terävyys. Viikoittain ajettu keskinkertainen analyysi löytää poikkeaman ennen kuukausittain ajettua erinomaista.
Kun tiedonkeruu, tietokanta ja malli ovat samalla palvelimella, analyysistä tulee osa päivittäistä työtä eikä erillinen hanke. Kokeile DataPortiaa ilmaiseksi 30 päivää: kokeilujakso sisältää tekoälymoduulin ja kaikki muut ominaisuudet HA-lisäosaa lukuun ottamatta eikä sido mihinkään. Malli ajetaan teidän palvelimellanne ja teidän datallanne, joten arvion ei tarvitse perustua lupaukseen.