Miksi Enterprise AI-pilottien kehitys tyrehtyy ennen tuotantovaihetta: Ongelma ei ole mallissa, vaan sen ympärillä olevassa kerroksessa

Mallin kehitys ei ollut koskaan vaikein osa. Rakennuksen sisällä tuotanto voitetaan tai hävitetään kerroksessa, joka on sen ympärillä: hakeminen, perustaminen, reititys ja arviointi.

Jokainen suuri yritysten AI-kysely kuvailee samaa esteitä: organisaatiot pystyvät pääsemään malleihin, suorittamaan pilotteja ja esittämään vaikuttavia demoja, mutta lähes mikään niistä ei pääse tuotantoon. Kyselyt kuvaavat tätä kuilua ulkopuolelta, johtajien vastatessa kysymyksiin. Tässä on näkymä toisesta puolelta: rakennuksen sisältä, missä pilotit joko pääsevät tuotantoon tai kuolevat hiljalleen.

Kuila, jota jokainen mitataa

Luvut ovat tulleet tutuksi. Deloitten AI-raportti osoitti, että pääsy AI:hin on lähes yleinen, mutta vain noin neljännes organisaatioista saa 40 %:n kokeistaan tuotantoon, ja noin yksi viidestä raportoi kypsiä sääntöjä autonomisille agenteille. MIT:n Project NANDA totesi suoremmin: satojen käyttöönottojen yli, valtaosa ei tuottanut mitattavaa taloudellista hyötyä. Gartner on ennustanut, että suuri osa generatiivisen AI-projekteista hylätään konseptin osoittamisen jälkeen, vedoten heikkoon datan laatuun, kohoaviin kustannuksiin ja epäselviin liiketoimintahyötyihin.

Kun pinotaan nämä löydökset yhteen, niistä muodostuu yksi muoto. Pullonkaula ei ole pääsyä kykeneviin malleihin. Tämä ongelma on ratkaistu. Pullonkaula on etäisyys mallin ja järjestelmän välillä, joka toimii tuotannossa, aina, jokaiselle käyttäjälle, oikean kuorman alla, oikeiden seurausten kanssa väärästä.

On syytä mainita yksi varoitus: monet pilotit eivät pääse koskaan tuotantoon, koska niillä ei ole oikeaa liiketoimintatapausta, käytettävissä olevaa dataa, johtajan tukea tai kustannusarvioita. Jätetään nämä sivuun. Seuraavassa käsitellään suurta ja ärsyttävää joukkoa pilotteja, jotka ovat teknisesti todellisia, esittävät vakuuttavasti demoja ja joilla on aito liiketoimintatapaus taustalla, mutta jotka jumiutuvat matkalla tuotantoon. Niiden kohdalla ratkaiseva tekijä on harvoin malli.

Kyselydata ei voi kertoa, mikä todella sulkee tämän etäisyyden. Tämä vastaus ei elä kyselyssä. Se elää insinöörien tekemissä päätöksissä siellä, missä demo vakuuttaa kaikki ja ennen kuin järjestelmä luotetaan oikeiden asiakkaiden kanssa.

Malli: ratkaiseva korjaus on harvoin malli

Yritysten AI-käyttöönotoissa, joista voimme puhua, on yksi johdonmukainen malli: kun jumiutunut pilotti lopulta pääsi tuotantoon, se muutos, joka sai sen sinne, oli harvoin parempi malli. Se oli mallin ympärillä oleva kerros: miten tietoja haetaan ja perustetaan, miten tulokset tarkistetaan ennen kuin ne näytetään käyttäjälle, miten työ reititetään oikeaan malliin eikä vain voimakkaimpaan, ja miten koko järjestelmä arvioidaan jatkuvasti.

Kutsuvamme tätä harness-kerrosta. Agentti on käytännössä malli, jolla on pääsy työkaluihin, ja harness on kaikki se, mitä malli käyttää kontekstin hakemiseen, työkalujen käyttämiseen ja sille asetettujen vaatimusten mukaisuuden varmistamiseen: hakeminen, perustaminen, reititys, varmistus ja arviointi. Nämä komponentit eivät toimi eristyneinä. Niitä on yhdistettävä tietoisesti tietyn liiketoimintatapauksen vuoksi. Tämä yhdistetty kurinpidollinen taito on se, mitä kutsuvamme agentin harnessiksi, ja se on siellä, missä tuotantovalmius todella voitetaan tai hävitetään.

Tämä uudelleenmäärittää konseptin osoittamisen ansan. Tiimit jumiutuvat, koska ne jatkavat optimoimista osasta, joka jo toimii. Ne vaihtavat uuden mallin, uudelleenmuotoilevat ohjelmointikieliä ja odottavat seuraavaa raja-aluetta, kun taas todelliset epäonnistumisen kohdat sijaitsevat yhden kerroksen päässä, osissa järjestelmää, joita demo ei koskaan rasita.

Perustaminen, ei älykkäämpi malli, tekee agentin turvalliseksi

Tarkastellaan suosittelua ja neuvontaa tarjoavaa apua, jonka rakensimme vakuutussektorille, alalle, jossa itsevarma väärä vastaus ei ole virhe, vaan vastuu. Ensimmäinen vaisto tapauksissa on tarttua kaikkein kykenevimpään malliin ja olettaa, että kyky ostaa turvallisuuden. Se ei tee sitä. Kykenevämpi malli tuottaa vakuuttavampia harhoja, mikä säädellyssä kontekstissa on pahempaa, ei parempaa.

Se, mikä teki järjestelmästä toimivan, oli harness: hakemisen suunnittelu, joka veti vain hallituilta, vuokralaisen turvallisilta lähteiltä; perustamistarkistukset, jotka vahvistivat luodut väitteet näiden lähteiden vastaisuutta ennen kuin mitään näytettiin käyttäjälle; ja vahvistusväli, joka suosi pidättyväisyyttä sen sijaan, että olisi väittänyt jotain tukemattoman. Tuloksena oli 80-90 prosentin lasku harhoissa LLM-väylän vertailukohtana, perustamistarkkuudella yli 95 prosentilla, samalla kun P95-viive pidettiin alle kahden sekunnin, jotta turvallisuuskerros ei koskaan tehnyt järjestelmästä hitaampaa.

Vastaoletettu oppi niille, jotka yhdistävät edelleen turvallisuuden mallin valintaan: perustamisen ja vahvistuksen kerros on hallinto. Poliisidokumentit ja hyväksymisvaliokunnat ovat tärkeitä, mutta ne eivät estä mallia keksimästä asiaa johtoprosessin aikana. Hakemisen ja vahvistuksen harness tekee. Käyttöönotoissamme tekninen perustamiskerros on todellinen hallintomekanismi: paikka, jossa “AI ei saa keksittyä asioita” ei ole periaate, vaan järjestelmän pakotettu ominaisuus.

Mallin reititys, ei mallin valinta, on siellä, missä AI-kustannukset määrätään

Toinen paikka, jossa pilotit kuolevat, on budjettikatsaus. Järjestelmä voi toimia kauniisti ja silti peruuteta, kun per-merkin taloudellinen arviointi, moninkertaistettuna tuhansien käyttäjien ja kymmenien liiketoimintatapausten yli, muuttuu ylläpidon ongelman, jota kukaan ei mallinnut etukäteen.

Tässäkin vaisto, valita yksi vahva malli ja reitittää kaikki sen kautta, on virhe. Useimmat yritysten työkuormat ovat sekoitus: suuri osa pyynnöistä on rutineja, ja pieni osa on todella vaikeita. Lähetys jokaiselle pyynnölle eturintamalle tarkoittaa maksamista eturintamahintaa triage-työlle, jonka pienempi, halvempi malli käsittelee täydellisesti.

Siinä siirrossa, jonka suorittimme kolmannen osapuolen LLM-API:staAmazon Bedrockiin, hyödyt tulivat mallikerroksen uudelleenarkkitehtuorista eikä mallin vaihdosta. Reitittäminen kullekin tehtävälle oikeaan mallinportaaseen, yhdistettynä Bedrockin omiin kustannus- ja hallintamekanismeihin, toi 42 prosentin laskun AI-infrarakenteen kustannuksissa ja 60 prosentin nopeamman mukautuvan sisällön luomisen ilman sovelluksen uudelleenrakentamista.

Laajentaaksesi tämän periaatteen se kertautuu. Hierarkkinen “neuvonantaja”-arkkitehtuuri, jossa halvat mallit hoitavat suurimman osan pyynnöistä ja eturintamallit on varattu tapauksille, jotka todella tarvitsevat niitä, muuttaa reitityksen yhden kerran säästöstä rakenteelliseksi.

Tämä malli on vähentänyt yritysten AI-kustannuksia 60-80 prosentilla agenttitoiminnassa ja jopa 85 prosentilla joissakin käyttöönotoissa. Asia ei ole otsikossa mainittu prosentti; se on, että AI-järjestelmän kustannukset määräytyvät sen arkkitehtuurin mukaan, ei siitä, mikä malli on valittu.

Miksi tämä on näkymätön kyselydatassa

Tätä ei voida näyttää selvästi kyselyssä, koska kyselyt kysyvät johtajilta tuloksia, eivät insinööreiltä mekanismeja. “Pääsikö pilottisi tuotantoon?” on kyllä/ei-vastaus, jonka johtaja voi antaa. “Mikä erityisesti sai sen sinne?” on kysymys, johon vain rakennusryhmä voi vastata, ja vastaus on harvoin “löysimme paremman mallin”. Se on lähes aina jokin versio “korjasimme kerrosta mallin ympärillä”.

Tämä vastaavuuden puute selittää outoa pysyvyyttä konseptin osoittamisen ansassa. Teollisuus jatkaa diagnoosin tekemistä malliongelmana ja ostaa malliratkaisuja, kun taas todellinen rajoitus sijaitsee hakemisessa, perustamisessa, reitityksessä ja arvioinnissa: ei-glamoerinen putkisto, jota demo ei näytä ja jota perusmallin lancaus mainoksissa ei mainita.

Se selittää myös, miksi hallinto ja toimitusnopeus eivät ole vastakohtia, kuten ne usein oletetaan. Yleinen kertomus käsittää hallinnon jarruksi. Kokemuksemme mukaan se on lähempänä vastakohtaa: perustamis- ja vahvistustyö, joka tekee järjestelmästä hallittavan, on sama työ, joka tekee siitä luotettavan oikeiden käyttäjien kanssa. Tehty harness-kerroksessa hallinto ei ole se, mikä hidastaa rakennusta. Se on se, mikä antaa rakennukselle luvan toimia.

Mitä tämä tarkoittaa, jos pilottisi on jumiutunut

Jos sinulla on generatiivinen AI-projekti, joka on jumiutunut konseptin osoittamisen limboon, hyödyllisin asia, jonka voit tehdä, on vastustaa vaistoa tarkastella mallia ensin. Malli on osa, joka on todennäköisesti jo tarpeeksi hyvä. Tarkastele sen sijaan kerrosta sen ympärillä:

• Hakeminen ja perustaminen: vastaako järjestelmä hallituilta, verifioiduilta lähteiltä, vai improvisoiiko se koulutusaineistostaan?
• Vahvistus: onko mitään, mikä tarkistaa tulokset ennen kuin ne näytetään käyttäjälle, vai meneekö mallin varmuus suoraan läpi?
• Reititys: maksavatko kaikki pyynnöt eturintamahintaa, vai onko työ reititetty halvempaan malliin, joka pystyy tekemään sen hyvin?
• Arviointi: mitataanko laatua jatkuvasti omien mittapuiden vastaisuutta, vai validoidaanko se kerran demossa ja ei enää?

Organisaatiot, jotka siirtyvät pilotista tuotantoon vuonna 2026, eivät ole niitä, joilla on pääsy parhaimpiin malleihin. Jokainen niistä. Ne ovat niitä, jotka ymmärtävät, että malli ei ollut koskaan vaikein osa, ja jotka panivat insinööritöitänsä harnessiin, missä tuotanto todella voitetaan.