Miksi Agentic AI -projektit Jäätävät Mittakaavassa, ja Mitä Yrityksien on Korjattava Ensinnä

Agentic AI on nopeasti muodostumassa kaikkien yritysten kriittiseksi osaksi. Yritykset ottavat koekäyttöön osaksi toimintojaan, demo-ympäristöt vaikuttavat johtajuuteen ja tiestöt muutetaan autonomisen AI-työnkulun ympärille.

Mutta monille näistä projekteista jotain menee pieleen hallitun demon ja tuotannon välillä. Projekti jää paikoilleen, käyttöönotot venyvät kuukausista vuosiin ja vastuussa olevat tiimit joutuvat selittämään, miksi agentti, joka toimi täydellisesti testauksessa, käyttäytyy odottamattomasti oikeassa maailmassa.

Lähes jokaisessa tapauksessa vastaus ei ole itse malli, vaan data-omaisuus, orkesterointikerros, hallintorakenne ja perinteinen infrastruktuuri, jonka useimmat yritykset eivät koskaan modernisoinut ennen kuin päättivät rakentaa älykkäitä agenteja sen päälle. Kunnes nämä perustukset korjataan, agentic AI jatkaa tuottamista demoja, jotka vaikuttavat ja käyttöönottoja, jotka pettävät.

POC-ympäristö on Ansapari

Useimmat yritykset arvioivat malleja. Vähemmän arvioivat agenteiden käyttäytymistä loppupäähän. Malli voi olla erittäin tarkin ja agentti, joka on rakennettu sen päälle, voi silti epäonnistua pahasti. Tämä johtuu siitä, että agentit ketjuvat työkalukutsuja peräkkäin ja yksi huono askel tuottaa väärän vastauksen, jonka seuraava askel käsittelee oikeana syötteenä, ja virhe kasvaa alaspäin ennen kuin kukaan huomaa.

POC-ympäristö on suunniteltu piilotamaan tämä. Syötteet ovat hallittuja, laajuus on kapea ja joku tarkkailee tulostetta. Mikään näistä olosuhteista ei ole olemassa tuotannossa. Agentti, joka sai hyvän arvosanan testauksessa, käsittelee nyt epäselviä ohjeita, osuu käyttöoikeusvirheisiin ja tekee peräkkäisiä päätöksiä datasta, jota se ei ollut testannut. Tiimi, joka rakensi sen, on havainnut, että arviointikehykset, jotka on suunniteltu mallin suorituskyvyn arvioimiseksi, eivät kerro, onko agentti kohdannut oikein, käsitellyt reunatapauksia arvostavasti vai tiennyt, milloin lopettaa.

McKinsey’n AI:n tila 2025 -raportin mukaan 88 %:ssa organisaatioista käytetään AI:ta vähintään yhdessä liiketoimintafunktiossa, mutta vain noin kolmasosa on onnistunut siirtämään sen koko yritykseen. Se ero adoptio ja mittakaava aloittaa siitä, miten yritykset suunnittelevat ja arvioivat koekäyttöjään. Tiimit, jotka mittakaavaavat onnistuneesti, käsittelevät virhetilamallin suunnittel vaatimuksena. Ennen käyttöönottoa he rakentavat luettelon siitä, miten agentti odotetaan epäonnistuvan ja mitä vastaus on, kun se epäonnistuu. Se kuulostaa ilmiselvältä. Vähän yrityksiä tekee sitä tosiasiallisesti.

Roska Data, Roska Agentit

Yritykset kysyvät usein, miksi heidän agenttinsa suorittavat heikosti tuotannossa. Vastaus on lähes aina data. Data-omaisuus ei ollut valmis. Lähteet olivat hajanaisia kymmenissä järjestelmissä, jotka oli rakennettu eri aikoina eri tarkoituksiin. Määritelmät olivat epäjohdonmukaisia liiketoimintayksiköissä. Semanttista kerrosta ei ollut. Yhtä totuuden lähdettä ei ollut. Siinä oli vain vuosien kerääntyneitä data velkaa, jota kukaan ei priorisoinut, koska vanhat järjestelmät toimivat tarpeeksi hyvin.

Tämä velka ei katoa, kun rakennetaan agentti sen päälle. Se muodostuu agentin toimintarealiteetiksi. Agentti, joka navigoi hajanaisissa data-lähteissä, ei ole järkeilemässä yhtenäisestä liiketoiminnan kuvasta. Se tekee parhaansa sen kanssa, mitä se voi löytää, sovittaa ristiriitoja lennossa ja tuottaa tulosteita, jotka näyttävät uskottavilta, kunnes joku, joka tietää liiketoiminnasta, tarkastelee tarkkaan. Agentti ei ole rikkoontunut. Data, jota se sai, oli rikkoontunut ennen projektin aloittamista.

Data-ajautuminen ja käsiteajautuminen tekevät tästä pahempaa ajan myötä. Kun todellisen syötteen jakautuminen siirtyy siitä, mihin malli on koulutettu, agentti ei heitä virhettä. Se jatkaa suorittamista ja alkaa tuottaa väärää tulostetta, varmasti ja laajassa mittakaavassa. Ilman MLOps- tai AIOps-pipelinea, joka on rakennettu agentin orkesterointikerrokseen, ei ole mekanismia, jolla tämä voidaan kiinni ennen kuin vahingot kasvavat. Agentti, joka suoritti hyvin käynnistysvaiheessa, alkaa hiljalleen heiketä viikoiksi ennen kuin kukaan yhdistää tulosteen laadun data-ongelmaan, joka oli siinä jo alusta alkaen.

Data-modernisointi ja AI-modernisointi käsitellään usein rinnakkain työvirroina, järjestettyinä itsenäisesti ja rahoitettuina erikseen. Ne eivät ole rinnakkaisia. Et voi rakentaa luotettavaa agenttia data-arkkitehtuurin päälle, joka oli rikkoontunut ennen projektin aloittamista. Järjestys on äärimmäisen tärkeä, ja datakerroksen ohittaminen siirtymiseksi nopeammin AI-kerrokselle on yksi yleisimmistä ja kalleimmista virheistä, joita yritykset tekevät.

Väärä dashboard antaa jollekulle väärän numeron. Väärä agentin toiminta voi laukaista alijärjestelmän ennen kuin kukaan huomaa, hyväksyy laskun, jota ei pitäisi hyväksyä, ohjaa noudattamismerkin väärin tai mukauttaa hintaa sen ulottuvuuden ulkopuolelle. Agenteille tarvitaan tarkoituksenmukainen havainnointi, ei yleisiä sovellusvalvontatyökaluja.

Yhdenmukaisen Data-alustan Edut

Yritykset, jotka siirtyivät yhdenmukaiseen data-alustaan ennen agenteilleen AI-ohjelmia, ovat skaalautumassa nopeammin kuin ne, jotka eivät ole. Kun Lakehouse, data-warehouse, semanttinen malli ja putkistot kaikki elävät yhdessä ympäristössä, kuten Microsoft Fabric issa, agenteilla on yksi johdonmukainen pinta, jota voidaan kuulustella. Se poistaa koko virheluokan, joka johtuu agenteista, jotka hyppäävät järjestelmistä toiseen eri schemojen, eri päivityssyklien ja eri liiketoimintamittauksien määritelmiä.

Tämä on syy, miksi alustat, joita yritykset valitsevat data-yhdenmukaistamiseksi, vaikuttavat niin paljon heidän agenteilleen AI-tuloksiin. Microsoft Fabricin yhdenmukainen lähestymistapa tuo yhteen Lakehouse, data-warehouse, semanttisen mallin ja putkistot yhdessä ympäristössä, antaen Microsoft (MSFT ) -keskeisille yrityksille rakenteellisen edun siirtymisessä kokeilusta todelliseen käyttöön.

Databricks toimittaa saman periaatteen Lakehouse-arkkitehtuurin ja Unity Catalogin kautta, antaen data- ja AI-tiimille yhdenmukaisen hallintakerroksen rakenteisen ja rakenteettoman datan yli MLflow-integraatiolla seurata mallin käyttäytymistä tuotannossa. Snowflaken lähestymistapa hyödyntää Cortex AI:ta ja tiivistä yhteyttä data-pilven ja AI-päätöksenteon välillä, mahdollistaen yritysten suorittaa agentti-työkuormia suoraan hallitun, elävän datan vastaan ilman viivästystä ja johdonmukaisuusriskejä, jotka liittyvät datan siirtämiseen järjestelmistä.

Kukin näistä alustoista edustaa eri reittiä samaan lopputulokseen. Datakerros, joka on yhdenmukainen, havainnollinen ja luotettava tarpeeksi tukemaan agentin päätöksentekoa mittakaavassa. Oikea valinta riippuu yrityksen olemassa olevasta pinosta. Se, mikä ei ole valinnainen, on tekemällä se valinta ja sitoutuminen siihen ennen kuin agenttikerros rakennetaan sen päälle. Se, mikä erottaa edistyvät tiimit niistä, jotka ovat edelleen jumissa kokeiluissa, ei ole se, mikä alusta he valitsivat. Se on se, että he korjasivat datakerroksen ensin.

Hallinto Ennen, Ei Jälkeen

Hallinto, joka on rakennettu jälkikäteen, ei ole hallintoa ollenkaan. Kun agentilla on alijärjestelmän päätöksentekovallan ja suojavarustuksia lisätään kuusi kuukautta käyttöönoton jälkeen, yrityksellä on jo kertynyt kuusi kuukautta kirjaamattomia päätöksiä. Auditin jäljitys on suunniteltava ennen kuin agentti siirtyy tuotantoon, ei jälkikäteen.

Sama periaate koskee AI-turvallisuutta, roolipohjaisia käyttöoikeuksia ja käyttöoikeuksien määrittelyä. Agentti, jolla ei ole oikein määritettyjä käyttöoikeuksia, voi päästä datan, jota se ei pitäisi päästä, suorittaa toimintoja, jotka ovat sen tarkoitetun rajauksen ulkopuolella, tai muodostua aktiiviseksi hyökkäyspinnaksi. Nämä ovat riskejä, jotka on käsiteltävä kehitysvaiheessa, ei käyttöönoton tarkastelussa.

Jos hallintoa ei ole upotettu koulutusputkistoihin ennen kuin ne on rakennettu, virheellinen tai vihamielinen data voi päästä koulutusprosessiin havaitsemattomasti. Malli, joka on koulutettu komprometoidulla datalla, suorittaa hyvin benchmarkkeja, mutta ajautuu tuotannossa, juuri sellaisen hiljaisen epäonnistumisen, joka on vaarallisin, kun agentin päätöksillä on todellisia liiketoimintaseurauksia.

EU:n AI-laki ja kasvavat sääntelykehykset AI-vastuullisuudesta tekevät tästä vaikeamman Ignoreerata ja yritykset, jotka eivät ole rakentaneet hallintoa agenttien arkkitehtuuriin, kerryttävät noudattamattomuuden altistusta, joka tulee maksamaan paljon enemmän myöhemmin.

Kokeilusta Tuotantoon: Mitä Se Vaatii Oikeasti

Yritykset, jotka sulkevat tuotantoon siirtymisen aukon, ovat ne, jotka korjaavat datakerroksen ennen kuin rakentavat agenttikerroksen. He upottavat hallinnon suunnitteluun, ei jälkikäteen. He rakentavat havainnollisuuden orkesterointiarkkitehtuuriin ja suorittavat muutoshallintaa rinnakkain teknisen toimituksen kanssa. He käsittelevät virhetilamallin tärkeänä suunnittel vaatimuksena.

Deloitten yritysten AI-tutkimus osoittaa, että työntekijöiden pääsy AI:hin kasvoi 50 %:lla vuonna 2025 ja osuus yrityksistä, jotka suorittavat yli 40 %:ia AI-projekteistaan täysin tuotannossa, on tarkoitus kaksinkertaistua seuraavien kuuden kuukauden aikana. Yritykset, jotka voittavat nyt, eivät ole niitä, joilla on kehittyneimmät mallit. Ne ovat niitä, jotka rakensivat toiminnallisen infrastruktuurin suorittaa AI:ta luotettavasti ja tekivät sen ennen kuin rakensivat agenteille.

Jokainen yritys, joka edelleen suorittaa erillisiä kokeiluja, tulisi keskittyä varmistamaan, että sijoitus malleihin ja käyttöliittymään on suhteessa sijoitukseen data-valmiuteen ja hallintorakenteeseen, joka määrää, pääsevätkö agentit koskaan demo-ympäristöstä. Tässä monilla yrityksillä on puute.

Kunnes tämä muuttuu, monista agenteille AI-projekteista, joihin yritykset ovat sijoittaneet resursseja ja toivoneet, että ne tuottaisivat hedelmää, kuolevat kuin viiniköynnös.