В това интервю за Help Net Security, Прасад Тарипала, Field CISO във Versa, обяснява какво пропускат организациите, когато внедряват модели с отворени тегла (open-weight) вътрешно. Той разглежда скритите разходи за GPU инфраструктура, прегледа на лицензите и осигуряването на персонал, както и защо укрепването на защитата и реагирането на инциденти се превръщат в задължение на купувача.
Той описва симулирането на атаки (red-teaming) срещу AI агенти, какво се счита за неуспешен резултат и петте въпроса, които купувачите трябва да зададат на платформите за агенти. За екипи с 90 дни и ограничен бюджет, той подрежда по приоритет инвентаризацията, намаляването на радиуса на поражение и непрекъснатото тестване.
Стартирането на модела във ваша собствена среда може да подобри контрола и съхранението на данни. Това обаче не прави автоматично внедряването по-сигурно. То прехвърля отговорността за укрепване на защитата, отстраняване на уязвимости, контрол на достъпа, мониторинг, оценка на моделите и реагиране при инциденти върху организацията, която го експлоатира.
Най-голямото подценяване е, че работата на модела е само част от проблема. Реалните оперативни разходи идват от всичко около модела: GPU инфраструктура, мрежи, съхранение на данни, захранване и охлаждане, планиране на капацитета, оркестрация, актуализации на моделите, мониторинг, контроли за сигурност, управление на данни, одитни доказателства и непрекъсната оптимизация.
Прегледът на лицензите и съответствието е друг разход, който рядко влиза в бюджета. „Отворени тегла“ не означава без ограничения. Много лицензи за отворени тегла носят ограничения за употреба, а разпоредби като Законодателния акт на ЕС за изкуствения интелект (EU AI Act) налагат задължения за по-големите модели. Някой трябва да прегледа това преди внедряването, като работата не спира след старта. Всяко обновяване на модела или адаптера изисква повторно валидиране, превръщайки се в постоянен разход, а не в еднократно упражнение.
Съществува и недостиг на умения. Нужни са хора, които разбират както от AI/ML инфраструктура, така и от сигурност, мрежи, наблюдаемост и производствени операции. На практика това обхваща инженерство на платформи, MLOps, експертиза в GPU и Kubernetes, надеждност на системите, сигурност на AI и симулиране на атаки, управление на идентичността и данните. В много случаи организациите приемат, че техните съществуващи инфраструктурни екипи или екипи по сигурност могат да поемат тази работа. Но надеждното управление на изводите (inference) в голям мащаб е различна дисциплина. Това може да доведе до значителни забавяния, а в някои случаи проектът никога не постига очакваната бизнес стойност.
Друга често подценявана област е степента на използване на ресурсите. Графичните процесори (GPU) са скъпи ресурси и лошото управление на работния товар може да доведе до значителен неизползван капацитет или непредвидима производителност по време на пикове в търсенето. Планирането на задачи, квотите, пакетирането, кеширането, маршрутизирането на модели и прогнозирането на търсенето помагат, а техники като квантуване и съвместно използване на GPU от множество клиенти (multi-tenant) могат да донесат реална разлика. Икономическата ефективност може да се промени значително в зависимост от това колко ефективно се споделят и управляват ресурсите за изводи.
Стратегията, дисциплинираното планиране и правилните умения със сигурност могат да накарат това да проработи. Решението обаче не трябва да се свежда единствено до дилемата „създаване или купуване“. То трябва да бъде продиктувано от чувствителността на данните, изискванията за суверенитет, нуждите от ниска латентност, обема на работния товар, наличните вътрешни умения и регулаторните изисквания или изискванията за съответствие. За много организации хибридният подход, при който някои работни товари се изпълняват вътрешно, а други се ползват като управлявана услуга, се оказва практичният отговор.
Това в крайна сметка е стратегическо решение за CISO, CIO и други технологични лидери, базирано на бизнес целите на организацията, нивото на сигурност, оперативната зрялост и регулаторните изисквания или съответствието. Няма универсален отговор за всички.
Симулирането на атаки (red-teaming) срещу агенти трябва да надхвърли традиционното тестване за проникване в приложения. Трябва да се тества не само дали агентът може да бъде компрометиран, но и какво може да направи, след като бъде компрометиран или манипулиран.
Бих тествал за инжектиране на команди (prompt injection), индиректно инжектиране на команди, прекомерни разрешения, изтичане на данни, неоторизирано използване на инструменти, ескалация на привилегии, опасни действия, манипулиране на паметта или контекста и способността за преминаване от една свързана система към друга. Към този списък бих добавил заразяване на паметта и RAG, злонамерен изход от инструменти, компрометирани конектори, кражба на идентификационни данни, злоупотреба с доверието между агенти, уязвимости във веригата на доставки и атаки за изтощаване на ресурсите. По-голямата част от това съвпада с настоящите насоки на OWASP за приложения с агенти и MITRE ATLAS, така че помага да се тества спрямо призната рамка.
Нещо, което заслужава специално внимание, е какво се случва, когато резултатът от един агент бъде предаден на втори или трети агент. Голяма част от реалния риск в системите с агенти не се намира в рамките на един агент. Той е в прехвърлянето, където изходни данни, които изглеждат напълно безвредни сами по себе си, се превръщат в проблем, след като друг агент започне да действа по тях.
Тестването не трябва да спира до агента. Основната инфраструктура, софтуерните компоненти, API интерфейсите, слоят за идентификация, големият езиков модел (LLM) и други поддържащи компоненти също трябва да бъдат подложени на тестване за сигурност и red-teaming, за да се установи пълното състояние на сигурността. Това трябва да обхване също стъпките за одобрение от човек, аварийното изключване и механизмите за връщане към предишно състояние, а не само технологичните аспекти.