**TL;DR:** Tekoäly on tehnyt integraation rakentamisesta halpaa. Se ei ole tehnyt siitä luotettavaa. Kun reitin kirjoittaminen kestää minuutteja tunnin sijaan, kallein työ ei ole enää rakentaminen vaan sen todentaminen, että lopputulos tekee mitä pitää — ja se työ tehdään hallintapinnan läpi. Siksi tuotepäätös, johon olemme käyttäneet Fasthubissa eniten aikaa, ei koske mallia. Se koskee sitä, mitä näyttö tekee silloin kun se ei tiedä. Vihreä valo, joka ei tarkoita mitään, on kalleinta mitä integraatioalusta voi näyttää: se ei poista riskiä, se lykkää laskun eteenpäin ja kasvattaa sitä matkalla.

---

Olemme kirjoittaneet läpi kevään ja kesän siitä, mitä integraatiokerroksesta seuraa muille: suvereniteetille, vaatimustenmukaisuudelle, hankinnalle. Tämä on ensimmäinen artikkeli, jossa kirjoitamme siitä, mitä rakensimme itse — ja aloitamme sieltä, mistä sitä harvoin aloitetaan. Ei generoinnista. Vaan siitä, mitä ruudulla lukee sen jälkeen.

## Kun rakentaminen halpenee, pullonkaula siirtyy todentamiseen

Fasthub syntyi havainnosta, jonka teimme omassa toimitustyössämme: tekoälyavusteinen kehitys tiivisti kvartaalin Apache Camel- ja Kubernetes-työn viikkoihin. Asiakkaat olivat tyytyväisiä. Katteet eivät. Se jännite pakotti rakentamaan tuotteen.

Mutta yksi asia ei tiivistynyt lainkaan, ja se on tässä olennainen. Rakentaminen nopeutui. Todentaminen ei.

Vanhassa mallissa asiantuntemus oli niukka resurssi — ja se oli samalla huomaamaton laadunvarmistus. Sama ihminen, joka kirjoitti reitin, tiesi yleensä myös mitä se tekee kello kahdelta yöllä, mitä tapahtuu kun vastapuoli ei vastaa, ja mikä kohta hajoaa ensimmäisenä kun volyymi kymmenkertaistuu. Se tieto ei ollut missään dokumentissa. Se oli tekijässä.

Kun generointi halpenee, tuo hiljainen kontrolli katoaa. Se ei siirry malliin. Se siirtyy pintaan, jonka läpi ihminen katsoo lopputulosta. Integraatio, jonka rakentaa tunnissa mutta johon luottaa vasta kahden viikon päästä, on kahden viikon integraatio.

Tämä on se kohta, jossa AI-natiivin alustan todellinen työ tehdään — ja se on tylsempää kuin demot antavat ymmärtää.

## Hiljainen vihreä on kallein virhetila

Ohjelmisto epäonnistuu kahdella tavalla. Se voi kertoa hajonneensa, tai se voi näyttää siltä kuin mikään ei olisi vialla. Jälkimmäinen on huomattavasti kalliimpi, ja jälkimmäinen on myös se, jonka käyttöliittymä valitsee oletuksena, koska tyhjä tila näyttää aina rauhallisemmalta kuin selitys.

Kirjoitimme Fasthubiin yhden säännön, joka toistuu läpi tuotteen: kun järjestelmä ei tiedä, se sanoo sen.

Käytännössä se tarkoittaa asioita, jotka näyttävät yksittäin pikkuseikoilta:

Kun klusterista puuttuu metrics-server, resurssien käyttöä ei näytetä nollana — se piilotetaan ja puute nostetaan esiin. Nolla olisi ollut vastaus. Se olisi vain ollut väärä.

Kun hälytyssäännön kysely on niin laaja, että Loki hylkää sen, sääntö ei näy vihreänä. Se saa oman tilansa, joka kertoo ettei sitä arvioida eikä se valvo mitään. Sääntö, jolla ei ole toimituskohdetta lainkaan, merkitään samasta syystä: se laukeaa portaaliin eikä ilmoita kenellekään.

Kun taulukko on katkaistu, se sanoo ettei sen arvot välttämättä kata koko aikaikkunaa — sen sijaan että osittainen vastaus esitettäisiin täytenä. Kun suoritusnäkymä maalaa ajon, jonka aikana sanomasisällön talletus oli pois päältä, se sanoo sen, eikä näytä tyhjiä arvoja oikeina arvoina.

Kun integraatiolle ei ole koskaan kirjattu hinnoittelutilannekuvaa, se ei näy laskutuksessa siistinä nollarivinä. Se näkyy varoituksena.

Yksikään näistä ei ole ominaisuus, jota kukaan pyytäisi tarjouspyynnössä. Yhdessä ne ovat sama päätös tehtynä satoja kertoja, ja se päätös on koko tuotteen luotettavuuden perusta. Nollan näyttäminen on aina helpompaa kuin sen selittäminen, miksi lukua ei ole.

## Väärä vihreä ei katoa. Se siirtyy jonkun toisen laskuksi.

Tähän asti tämä on ollut tuotefilosofiaa. Seuraava kohta on talouskysymys.

Piilotettu epävarmuus ei poista riskiä. Se siirtää sen myöhemmäksi — ja sama vika maksaa eri summan riippuen siitä, milloin se paljastuu. Rakennusvaiheessa se on minuutteja. Tuotannossa se on incident. Auditissa se on löydös. Käyttöliittymä, joka näyttää vihreää tietämättään, on käytännössä päätös maksaa se kalleimmalla mahdollisella hetkellä.

Valvontasääntö, joka ei oikeasti valvo mitään, ei tuota nollan verran arvoa. Se tuottaa negatiivisen määrän, koska se tuottaa väärän turvallisuudentunteen — ja hinta realisoituu ensimmäisessä katkossa, jota kukaan ei huomannut, koska hälytys oli asennettu.

Mittari, joka näyttää nollaa siksi ettei lukua ole olemassa, on budjetointivirhe odottamassa vuoroaan. Kukaan ei kyseenalaista siistiä lukua.

Ja vaarallinen operaatio, joka on tarjolla nappina ilman että sen seuraus on kirjoitettu auki, ei ole ominaisuus vaan koulutuskysymys — eli riippuvuus siitä, kuka sattuu olemaan vuorossa. Peruuttamattoman operaation kohdalla oikea tuotepäätös ei ole helpoin mahdollinen nappi. Se on nappi, joka kertoo seurauksensa ennen kuin sitä painetaan — ja joskus tietoinen päätös olla rakentamatta nappia lainkaan ja perustella se paikan päällä.

Tästä seuraa yksi konkreettinen suositus, joka ei koske meitä. Kun arvioit mitä tahansa integraatioalustaa, pyydä demossa katkaisemaan yhteys taustajärjestelmään ja katso mitä näyttö tekee. Se on halvin tapa erottaa hallintapinta kojelautateatterista, ja se kestää kaksi minuuttia.

## Kun tekoäly kirjoittaa, vastuu ei katoa — se pitää sijoittaa jonnekin

Olemme kirjoittaneet aiemmin siitä, että integraatioalan todellinen muutos ei ole nopeudessa vaan siinä, kuka on vastuussa kun asiat hajoavat. Kun tekoäly kirjoittaa muutoksen, kysymys ei katoa. Se vain siirtyy paikkaan, jossa harva alusta suostuu käsittelemään sitä ääneen.

Vastuu ei ole mallin ominaisuus. Se on kolme tuotepäätöstä, jotka jokainen alusta tekee puolestasi — kertoi se niistä tai ei.

**Missä hyväksyntäportti on?** Houkutteleva vastaus on "kaikkialla": jokainen tekoälyn tekemä muutos ihmisen hyväksyttäväksi. Se on myös väärä vastaus. Portti keskellä maksaa juuri sen nopeuden, jonka vuoksi tekoäly hankittiin, eikä tuota vastineeksi varmuutta — kymmenennen diffin kohdalla kukaan ei enää lue, vaan hyväksyy. Fasthubissa portit ovat päissä, siellä missä päätökset oikeasti tehdään. Ennen toteutusta suunnitelman hyväksyy ihminen, eikä sitä voi hyväksyä niin kauan kuin siinä on avoin estävä kysymys tai päätös — ja avoimeen kysymykseen tekoäly ei koskaan kirjoita vastausta itse. Sama periaate kuin edellä: asettamaton käyttöparametri tuottaa suunnitelmaan avoimen kysymyksen, ei arvausta. Toisessa päässä julkaisu profiiliin vaatii aina ihmisen tietoisen valinnan; tekoäly voi valmistella sen, mutta hyväksynnän tekee ihminen, joka kerta. Väliin jäävä kirjoitustyö kulkee git-committeina, ja sen voi katselmoida joko muutos kerrallaan tai jälkikäteen kokonaisuutena. Se on nopeusvalinta, ei vastuuvalinta.

**Kuka voi muuttaa rajoja?** Tekoälyn kirjoituksia rajaavat integraatiokohtaiset compliance-asetukset. Ihminen määrittää ne ja voi myös muuttaa niitä, ja muutos jää auditlokiin. Tekoäly ei voi. Ero on koko kontrollin määritelmä: rajoite, jota valvottu osapuoli voi itse löysätä silloin kun se haittaa, ei ole kontrolli vaan suositus.

**Jääkö päätöksestä jälki?** Kuka hyväksyi suunnitelman, mitä toteutuksessa muuttui, kuka painoi julkaisua ja mihin versioon se osui. Tämä on kysymys, jonka tarkastaja esittää — ja johon on olemassa vastaus oletuksena tai ei ollenkaan, koska jälkikäteen sitä ei rakenneta.

Elokuun 2. päivästä alkaen AI Actin yleiskäyttöistä tekoälyä koskevat säännökset ovat täytäntöönpanovaiheessa, ja se tekee näistä kolmesta valinnasta kysymyksiä, joihin joudutaan vastaamaan muillekin kuin itselle. Emme väitä, että meillä on turvallinen tekoäly. Väitämme, että jokainen alusta on jo valinnut nämä kolme kohtaa puolestasi, ja että sinulla on oikeus tietää mitä se valitsi.

## Miksi tämä on suvereniteettikysymys, ei käytettävyyskysymys

Kirjoitimme heinäkuussa siitä, että komission pilvisuvereniteetin viitekehys teki suvereniteetista mitattavaa — ja että tuloskortista puuttuu tyypillisesti rivi integraatiokerrokselle. Tässä on sen jatko.

Toimitusketjun läpinäkyvyys ei ole vain kysymys siitä, mistä koodi tulee. Se on myös kysymys siitä, kertooko järjestelmä sinulle totuuden omasta tilastaan. Alusta, joka piilottaa oman epävarmuutensa, on auditoimaton riippumatta siitä, missä sen konesalit ovat ja kenen lippu sen verkkosivulla liehuu. Avoin lähdekoodi antaa mahdollisuuden lukea, mitä järjestelmä tekee. Rehellinen hallintapinta on se osa, joka kertoo mitä se juuri nyt tekee.

Emme ole neutraaleja tässä. Fasthub on rakennettu Turussa, kokonaan avoimen lähdekoodin teknologioista ja 100-prosenttisesti EU:ssa isännöitynä, ja tämä artikkeli kuvaa suunnitteluperiaatetta, jonka valitsimme tietoisesti ja jonka hinta on se, että tuotteemme näyttää ajoittain epävarmemmalta kuin kilpailija, joka ei kerro.

Se on vaihtokauppa, jonka tekisimme uudestaan. Vihreä valo kannattaa ansaita, ei asettaa oletukseksi.

---

*Fasthub on AI-natiivi integraatioalusta, joka on rakennettu Turussa, Suomessa — kokonaan avoimen lähdekoodin teknologioista ja 100-prosenttisesti EU:ssa isännöitynä.*