Защо повечето проекти за корпоративни AI агенти никога не напускат пилотния етап - и какво могат да направят техническите директори по въпроса

Системите с агентен изкуствен интелект вече работят в пилотни проекти в повечето големи предприятия. Демонстрациите са убедителни: агент, който обработва ескалациите на клиентите, друг, който изготвя и изпраща заявки за обществени поръчки, и друг, който следи инфраструктурата и отваря билети за инциденти без човешка намеса. Техническите възможности са реални. Неуспехът почти никога не е технически. Това, което държи тези проекти в капан в постоянни пилотни проекти, е набор от организационни, архитектурни и измервателни условия, които не са били налице по време на тестването на концепцията и не са били разрешени, преди някой да попита дали внедряването в производство е осъществимо.

Допълнителна статия към по-широката ни работа върху неуспеха на пилотните проекти с ИИ и готовността за производство. Вижте „Защо все още повече от 75% от пилотните проекти с ИИ не успяват да достигнат до производство и как да го поправим“ за петте структурни причини, които се отнасят за всички системи с ИИ като цяло.

Разликата на агентите: Защо стандартните наръчници за пилотен проект до производство се разпадат

Повечето предприятия вече са внедрили поне един модел за предсказуемо машинно обучение или RAG-базиран асистент в производствена среда. Институционалните знания от тези програми – канали за данни, наблюдение на модели, управление на промените в заинтересованите страни – създават фалшиво чувство за готовност, когато агентните системи се включат в действие. Агентният изкуствен интелект е архитектурно различен по начини, които нарушават стандартния наръчник в няколко точки. Агентът не създава препоръка, по която човек да действа; той предприема действия директно, често в множество системи, в последователности, които не са били напълно предвидени по време на проектиране. Това означава, че повърхността на отказа не е влошена прогноза – тя е завършено действие, което не е трябвало да бъде предприето, често такова, което вече е променило база данни, изпратило е комуникация или е ангажирало ресурс.

Последицата за готовността за производство е, че толерантността към тих отказ, която може да се управлява в система за препоръки чрез човешки преглед, не съществува в агентен контекст. Агент, който халюцинира име на доставчик в работен процес за обществени поръчки, не създава лоша препоръка – той създава поръчка за покупка. Организационната инфраструктура, необходима за улавяне, регистриране и отстраняване на този клас грешки, е съществено различна от това, което повечето предприятия са изградили за първото си поколение внедрявания на ИИ, и почти никога не е налице в момента, в който пилотен проект се оценява за производство.

Пропуски в организационната готовност, които пилотите не разкриват

Пилотните проекти по дизайн са проектирани да се изпълняват при условия, които не съществуват в производствената среда. Данните са по-чисти, обхватът е по-тесен, инженерният екип е внимателен, а заинтересованите страни са мотивирани да видят успех. Тези условия систематично прикриват трите организационни пропуски, които най-надеждно блокират внедряването на агентни системи в производствената среда.

Първото е неяснотата на собствеността. Агентските системи пресичат функционалните граници по начини, по които прогнозните модели обикновено не го правят – един агент може да докосва CRM данни, да задейства ERP транзакции и да комуникира чрез канал, насочен към клиента. В пилотен проект малка междуфункционална група управлява това неформално. В производствения процес нито един екип няма ясна отговорност за поведението на агента, което означава, че реагирането на инциденти, мониторингът на производителността и решенията за преквалификация попадат в организационни пропуски. Вторият пропуск е липсата на път за човешка ескалация, който е бил оперативно тестван. Повечето пилотни проекти включват механизъм за ескалация на теория; почти никой не е провел симулация на производствен обем за това какво се случва, когато 15% от задачите на агентите изискват едновременен човешки преглед. Третото е управлението на промените за оперативните екипи, чиято работа агентът модифицира. Агент, който автоматизира задача, не елиминира човешката роля – той я преструктурира. Екипите, които не са подготвени за това преструктуриране, ще заобикалят агента, създавайки паралелен ръчен процес, който прави резултата на агента неизмерим, а грешките му невидими.

Проблемът с измерването: Защо стандартните рамки за възвръщаемост на инвестициите дават грешен отговор

Най-честата причина, поради която един пилотен проект не получава финансиране за производство, е, че бизнес казусът му е изграден върху показател, който не оцелява при контакт с финанси. „Спестено време“ е показател по подразбиране за агентните пилотни проекти с изкуствен интелект и е грешна мерна единица за почти всеки агентен случай на употреба. Механизмът на стойност в агентната система не е компресиране на времето за задача, която преди това е била изпълнявана ръчно, а способността да се изпълняват процеси с обем, скорост или последователност, които преди това изобщо не са били постижими. Сравняването на агент, който обработва 10 000 фактури от доставчици на ден, с времето, което човек би отделил за тези фактури, дава число, което изглежда неправдоподобно за финансовия директор, защото базовата линия за сравнение не е реалистична. Никое предприятие не би наело достатъчно персонал, за да обработва 10 000 фактури на ден ръчно.

Правилната рамка за измерване се измества от спестено време към скорост на резултатите: колко цикъла на вземане на решения са завършени за единица време, какъв е процентът на грешки спрямо човешкия базов цикъл при еквивалентен обем и каква е цената на завършен резултат в производствен мащаб в сравнение с пилотен мащаб. Тази рамка изисква инструменти, които повечето пилотни проекти не изграждат – по-специално, възможността за регистриране на всяко действие на агента, всяко извикване на инструмент, всяка ескалация и всеки резултат надолу по веригата във формат, който може да бъде агрегиран в цифра за цена на резултат. Пилотните проекти, които не са оборудвани с инструменти на това ниво, не могат да предоставят доказателствата, необходими за оправдаване на производствените инвестиции, поради което разговорът за бизнес казуса се зацикля на „демото работи добре“.

Написахме подробна рамка за този подход към измерването в „Как да измерим икономическото въздействие на агентния ИИ: Рамка за финансови директори и технически директори“ , обхващаща специфичните показатели, които издържат на финансов контрол.

Блокиращи фактори за управление: Където правните и нормативните изисквания пречат на одобренията за производство

Прегледът на управлението, който се задейства от внедряването на производствен агент, е категорично различен от това, което изисква пилотен проект. Екипите по правно съответствие, съответствие и информационна сигурност, които не са участвали в пилотния проект – или са участвали само повърхностно – се превръщат в блокиращи заинтересовани страни, когато въпросът се промени от „можем ли да тестваме това“ на „можем ли да го изпълним в мащаб с реални последици“. Три проблема с управлението се повтарят с достатъчна честота, за да се третират като структурни, а не като ситуационни.

Първото е местоживеенето на данните и обхватът на достъп. Агент, който извиква множество вътрешни API в производствения процес, в повечето големи предприятия ще изисква официален преглед на достъпа до данни, който картографира всеки източник на данни, който агентът може да чете или записва, класификацията на чувствителността на тези данни и одитната следа за всяко събитие за достъп. Пилотните проекти рядко предоставят тази документация, защото работят в пясъчни среди с разрешителен контрол на достъпа. Второто е отговорността за агентски действия. Когато агент предприеме действие, което причинява вреда надолу по веригата – комуникация с клиент, изпратена по погрешка, финансова транзакция, изпълнена неправилно – въпросът за организационната отговорност не е отговорен за повечето предприятия, тъй като техните правни рамки са написани за вземане на решения от хора. Третото е съответствието със Закона за изкуствения интелект за предприятия, работещи в ЕС. Агентските системи, които вземат последващи решения в области като кредитиране, заетост или критична инфраструктура, вероятно ще бъдат класифицирани като високорискови съгласно Закона на ЕС за изкуствения интелект, което изисква оценки на съответствието, механизми за човешки надзор и регистрация преди внедряването. Откриването на това по време на процеса на одобрение в производствения процес, а не по време на пилотния проект, добавя от три до шест месеца към срока и понякога прави случая на употреба неразполагаем в сегашния му вид.

Архитектурни решения, които определят жизнеспособността на производството

Няколко архитектурни избора, направени по време на пилотната фаза, определят дали внедряването в производствения процес е постижимо в разумен срок или изисква почти пълно преустройство. Най-важният от тях е изборът между едноагентна и многоагентна архитектура. Едноагентните системи са по-лесни за пилотиране – един модел, една верига от подкани, един набор от инструменти – но те бързо достигат ограниченията на възможностите си в производствения процес, защото един контекстен прозорец не може да поддържа кохерентно състояние в рамките на дълъг, разклоняващ се работен процес. Многоагентните архитектури, при които оркестратор делегира на специализирани подагенти, са по-подходящи за сложни работни процеси, но изискват оркестрационен слой, протоколи за комуникация между агентите и модел за разпространение на грешки, който повечето пилотни проекти не са проектирали.

Проектиране на извиквания на инструменти и обработка на грешки

Второто критично архитектурно решение е как се проектират извикванията на инструменти и какво се случва, когато те се провалят. В пилотен проект, повреди на инструменти се обработват ad hoc - инженер наблюдава, повредата се регистрира, сесията се рестартира. В производствения проект, повреди на инструменти трябва да се обработват детерминистично: агентът трябва да знае дали да опита отново, да ескалира или да прекрати, и тази логика на решение трябва да бъде кодирана изрично, а не оставена на преценката на модела. Агентите, които разчитат на основния езиков модел, за да решат как да обработят неуспешно API извикване, ще се държат непоследователно в производствения обем, защото реакцията на модела на двусмислени състояния на повреда не е стабилна при температурни промени и подканващи промени в контекста.

Памет и устойчивост на състоянието

Третото решение е архитектурата на паметта. Агентите, които разчитат изцяло на контекстна памет, не могат да поддържат състоянието си между сесиите, което е сериозно ограничение за всеки работен процес, обхващащ часове или дни. Производствените агентни системи изискват експлицитен слой памет – обикновено комбинация от краткосрочна работна памет във векторно хранилище и дългосрочно структурирано състояние в база данни – с дефинирани разрешения за четене и запис, които могат да бъдат одитирани. Пилотните проекти, които използват изключително контекстна памет, ще се нуждаят от възстановяване на този слой преди производството, което е нетривиално инженерно усилие, което често се подценява в производствения график.

Структуриран път към производството

Преминаването на пилотен проект към производствен проект изисква разрешаване на организационните, измервателните, управленските и архитектурните пропуски в определена последователност. Опитът за паралелното им разрешаване създава конфликти на зависимости — прегледът на управлението не може да бъде завършен без картата за достъп до данни, която не може да бъде създадена без да е дефинирана производствената архитектура.

Последователността, която постоянно намалява времето за пускане в производство, започва с валидиране на архитектурата: преди да бъде одобрена каквато и да е инвестиция в производство, пилотната архитектура трябва да бъде прегледана спрямо производствените изисквания за обработка на повреди на инструменти, устойчивост на паметта и нуждите от многоагентна оркестрация. Този преглед обикновено отнема от две до четири седмици и води до оценка за възстановяване, която е от съществено значение за честно бизнес казус. Втората фаза е инструментацията: пилотният проект трябва да бъде повторен с активирано пълно регистриране на действията, като се получат данните за цена на резултат, които бизнес казусът изисква. Третата фаза е предварителното ангажиране на управлението: правните, съответстващите и информационните отдели трябва да бъдат запознати с производствената архитектура преди началото на официалния процес на одобрение, по-специално за да се идентифицира класификацията на риска по Закона на ЕС за изкуствения интелект и изискванията за преглед на достъпа до данни. Изненадите във формалния процес на управление са убийци на срокове; предварителното ангажиране ги превръща в планирани работни потоци. Четвъртата фаза е оперативната готовност: пътят на човешка ескалация трябва да бъде тестван за натоварване, отговорността за собственост трябва да бъде официално определена и екипите, чиито работни процеси агентът ще модифицира, трябва да са завършили структурираното управление на промените преди пускането в експлоатация.

Тази последователност не компресира времевата линия за производствено внедряване — реалистичното внедряване на нетривиална агентна система отнема от шест до дванадесет месеца от завършен пилотен проект. Това, което прави, е да елиминира най-честите причини за неуспех в късен етап, които са изненади от страна на управлението, отхвърляне на бизнес сценарии и изоставяне след внедряването поради неуредени въпроси относно собствеността.

Какво отличава добрите примери, които достигат до производство

Предприятията, които успешно прехвърлят агентни пилотни проекти в производствена среда, споделят малък брой структурни характеристики, които си струва да бъдат назовани точно. Те са инструментализирали пилотните си проекти за измерване на разходите за резултат, а не за оценка на спестеното време. Те са ангажирали заинтересованите страни от управлението преди процеса на одобрение за производство, а не по време на него. Те са назначили вътрешен собственик за агентната система преди приключване на пилотния проект, с изрична отговорност за мониторинг, реагиране при инциденти и решения за преквалификация. И са избрали първи производствен случай на употреба, при който режимът на повреда е възстановим - агент, който изготвя документ за човешки преглед преди изпращане, а не такъв, който изпраща автономно - което им е позволило да изградят оперативна увереност, преди да премахнат човешката контролна точка.

Техническият капацитет, необходим за изпълнение на агентен ИИ в производствени условия, съществува в повечето големи предприятия днес. Разликата не е в моделите, инструментариума или инфраструктурата. Тя е в организационните и архитектурни решения, които бяха отложени по време на пилотния проект, защото отлагането им ускори изпълнението му. Запълването на тази празнина изисква третиране на производствената готовност като ограничение на дизайна от първия ден на пилотния проект, а не като проблем, който трябва да се реши, след като демонстрацията е впечатлила борда.