AI функционалност в реална среда: пригответе се моделът да се промени

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

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

Рискът, който расте по-бързо от внедряването

Според Евростат: използване на изкуствен интелект в предприятията през 2025 г. около 20 % от предприятията в ЕС с поне десет заети използват AI технологии, при 13,5 % година по-рано, а сред големите предприятия — 55 %. Същевременно Stanford HAI AI Index Report 2026 отчита 362 документирани AI инцидента през 2025 г. спрямо 233 през 2024 г.

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

Европейският законодател вече третира точно този клас зависимост изрично. Регламент (ЕС) 2022/2554 (DORA) изисква от финансовите субекти да водят регистър на доставчиците на ИКТ услуги — трети страни, да ги обвържат договорно и да разполагат със стратегии за изход. И извън финансовия сектор списъкът остава полезен: кой от какво зависи, какво се случва при отпадане и покрито ли е това договорно.

Шест практики, които държат функционалността надеждна

1. Фиксирайте версията и знайте докога това издържа

Извикването на подразбиращата се крайна точка на доставчик означава да приемете каквото стои зад нея в дадена сутрин. Назоваването на конкретна версия превръща невидимата промяна в планирана. Фиксирането не е целият отговор, защото версиите се извеждат от употреба. Затова важното число не е само коя версия ползвате, а какъв срок за предизвестие дава доставчикът преди извеждането — и колко трае вашият цикъл на оценка и одобрение. Ако второто е по-голямо от първото, точно тази разлика е рискът, и тя е въпрос на доставка, а не на разработка.

2. Поддържайте оценъчен набор, който отразява вашата работа

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

Сто добре подбрани случая бият десет хиляди събрани напосоки. Разходът е в означаването и се плаща веднъж.

3. Третирайте обновяването на модел като издание, не като известие

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

NIST AI Risk Management Framework описва това като непрекъсната дейност през жизнения цикъл, а не еднократна квалификация. На практика означава: контролна точка, за която някой отговаря и която може да откаже да отвори.

4. Измервайте изхода, а не само наличността

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

5. Поддържайте резервен път, който не е същият модел

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

6. Запишете правата за оценка в договора

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

Кой отговаря за това

Тези практики се провалят тихо, когато никой не отговаря за тях, защото нито една не е спешна в конкретния ден. ISO/IEC 42001, стандартът за система за управление на ИИ, предлага рамка, която може да се заеме и без сертификация: определени отговорности, документирани цели, управлявана промяна и преглед във времето.

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

Откъде да се започне

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

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

Ако въвеждате AI функционалност в продукт и искате оперативната практика да бъде проектирана заедно с нея — това е работа по продукт и платформа и обикновено се оформя като спринт за изпълнение.

Тази публикация е адаптирана от английския оригинал. При различие английската версия е меродавна.