Всем привет!
Это продолжение статьи о трансформации подхода к использованию ИИ — от базового применения к AI-Native.
В первой части мы разобрали уровни зрелости искусственного интеллекта, ключевые этапы ИИ-трансформации и классификацию приложений и модальностей LLM.
Во второй части:
-
От Software к Trustware: в процессе непрерывной технологической трансформации
-
AI-Powered Trustware Development Lifecycle
Эволюция инженерных практик
В современном мире разработки программного обеспечения и искусственного интеллекта особое внимание уделяется автоматизации и интеграции процессов для повышения эффективности и надежности. Методология DevOps стала ключевым фактором в обеспечении слаженного взаимодействия команд, построении производственных конвейеров и ускорении циклов разработки и развертывания. На основе DevOps формируются специализированные практики, такие как DataOps и MLOps, которые играют важную роль в управлении данными и жизненным циклом моделей машинного обучения.
🔹DevOps, как методология, фокусируется на максимальной автоматизации взаимодействия инженеров, практиках непрерывной интеграции и развертывания (CI/CD), что закладывает прочную основу для эффективных процессов разработки и эксплуатации программного обеспечения. Являясь основой, DevOps, гарантирует, что подходы DataOps и MLOps наследуют надежную инфраструктуру, которая отдает приоритет эффективности, масштабируемости и более быстрым процессам разработки ИИ-приложений.
🔹DataOps строится на DevOps, где конвейеры работы с данными управляются при помощи аналогичных практик автоматизации, контроля версий и непрерывного мониторинга, что обеспечивает параметры качества и соответствие требованиям на протяжении всего жизненного цикла данных.
🔹MLOps также распространяет принципы DevOps на процессы машинного обучения, уделяя особое внимание уникальным проблемам разработки, обучения, развертывания и мониторинга ИИ-моделей
В свою очередь, MLOps и DataOps являются основой для LLMDevOps, поскольку они устанавливают критически важные процессы и инфраструктуру, необходимые для управления жизненным циклом разработки больших языковых моделей (LLMs). DataOps обеспечивает эффективное управление конвейерами данных — от сбора и подготовки до хранения и извлечения, предоставляя высококачественные, последовательные и защищенные данные, на которых основываются большие языковые модели (LLM). MLOps расширяет эти принципы за счет автоматизации и оркестрации жизненного цикла машинного обучения, включая разработку моделей, а также их обучение, развертывание и мониторинг.
🔹LLMDevOps охватывает весь комплекс процессов обучения, развертывания и управления LLM, которые требуют существенных вычислительных ресурсов и обработки. Процессы существенно различаются между кейсами применения предварительно-обученных моделей LLM в процессе разработки приложений и кейсами создания кастомных LLM-моделей с нуля с использованием открытых и пользовательских наборов данных, которые наследуют больше MLOps-практик с некоторыми дополнениями. LLMDevOps является инженерной основой для реализации практик информационной безопасности при создании комплексных систем на базе ИИ – AI-SDLC (AI-Secure Development Lifecycle).
🔹AI-SDLC – интегрированный подход, включающий совокупность практик и методов, направленных на обеспечение безопасности, надежности и устойчивости при разработке, развертывании и эксплуатации больших языковых моделей. AI-SDLC наследует инженерные практики LLMDevOps и сочетает принципы DevSecOps с особенностями работы и эксплуатации больших языковых моделей, обеспечивая безопасную и этичную интеграцию ИИ в приложения и цифровые сервисы.
От Software к Trustware: в процессе непрерывной технологической трансформации
История разработки программного обеспечения началась с простой задачи — заставить компьютеры работать. Первые десятилетия были посвящены созданию базового «software», решающего утилитарные задачи. Однако с ростом интернета и цифровизации стало очевидно: функциональность сама по себе недостаточна. Ошибки и уязвимости в коде начали приводить к серьезным последствиям — от сбоев в бизнесе до утечек данных. Это стало толчком к появлению нового уровня зрелости — Secure Software, где безопасность стала такой же важной характеристикой, как и сама работоспособность программы.
Эра Secure Software
На рубеже 2000-х годов акцент в индустрии сместился к интеграции безопасности в жизненный цикл разработки. Появились практики Secure SDLC и концепции вроде DevSecOps, где тестирование и защита стали встраиваться прямо в процесс написания кода. Программное обеспечение перестало быть просто набором функций: теперь оно должно было устойчиво работать в условиях атак, защищать данные и соответствовать нормативным требованиям. Secure Software стало новой нормой — продукт без встроенной безопасности терял доверие пользователей и бизнеса.
Переход к Trustware
Однако с приходом искусственного интеллекта и усложнением технологических стеков одной только безопасности стало недостаточно. Программы перестали быть детерминированными, появились новые источники риска: недетерминизм моделей, «галлюцинации» LLM, предвзятость данных и уязвимости в AI-агентных системах. Здесь уже речь идёт не только о защите от атак, но и о создании условий для доверия к результатам работы системы. В концепте Trustware во главу угла ставится прозрачность, объяснимость и надежность AI-систем наряду с их безопасностью.
Будущее Trustware
Trustware — это следующая эволюция программного обеспечения: не просто функциональное и защищённое, а такое, которому можно доверять. Оно сочетает в себе безопасность, этику, контроль качества данных и способность объяснять свои решения. Если Secure Software отвечало на вопрос «как защитить?», то Trustware отвечает на вопрос «как доверять?». В условиях, когда ИИ всё глубже интегрируется в критические процессы бизнеса и общества, именно доверие становится ключевой ценностью и конкурентным преимуществом.
Теперь рассмотрим процесс эволюции в контексте видоизменения “цифровой трансформации” и его влияние на рост продуктивности организации. С технологической точки ��рения преодоление кризиса продуктивности через практику цифровизации может быть разделено на три этапа: Цифровая Трансформация, Cloud-трансформация, AI-трансформация.
1. Цифровая трансформация в начале пути включает в себя реализацию базовых подходов и технологических практик, таких как внедрение Agile-методологии, практик непрерывной интеграции и развертывания, внедрения инструментов системной коллаборации и DevSecOps. Результатом данного этапа является восстановление продуктивности организации и формирование технологического фундамента для дальнейшего развития.
2. Следующий, логичный этап развития организации – Cloud-трансформация, в рамках которой осуществляется переход на микросервисную архитектуру, реализуется концепция EaaC (Everything as a Code). Эта фаза характеризуется дальнейшим ростом продуктивности.
3. Целью этапа AI-трансформации является реализация концепции AI-Native организации, где технологии ИИ полностью и бесшовно интегрированы во все без исключения бизнес-процессы. Процесс технологической эволюции здесь является наиболее сложным, ресурсоемким, включает в себя постепенный переход от ИИ-ассистентов к более сложным и автономным ИИ-платформам, фокусируясь на интеграции, оптимизации и расширении возможностей взаимодействия в рамках комплекса всех систем организации и может быть представлен как несколько фаз.
3.1. Первичное применение AI-технологий и использование ML-моделей. Как правило в этом периоде основной приоритет сфокусирован на решении задач при помощи предиктивных ML-моделей на основе собственных табличных данных и разработке ИИ-ассистентов.
Архитектура решения:
🔹Каналы взаимодействия: через мессенджеры, веб-интерфейс и API.
🔹Ассистенты: Представлены сценарным движком, визуальным редактором и системами сбора истории и метрик.
🔹Платформа процессинга естественного языка (Natural Language Processing, NLP): содержит ML-модели и конвейер обучения ML-моделей.
3.2. Построение интегрированной AI-платформы, предназначенной для базовой автоматизации бизнес-процессов. На этой фазе наблюдается переход от частных, “лоскутных” внедрений AI-элементов к более интегрированному AI-решению позволяющему создать мульти-модельную среду, снизить затраты за счет автоматического выбора LLM, подходящих для простых запросов, и реализовать RAG-конвейеры для обогащения контекста. С точки зрения архитектуры:
🔹Сохраняются те же коммуникационные каналы.
🔹Ассистенты: эволюционируют с добавлением новых функций.
🔹AI-Платформа: расширяется через LLM-шлюз (при помощи Web UI / API), интегрирует в себя векторные базы данных и реализует RAG-архитектуру для обогащения контекста LLM внутренними базами знаний.
🔹Multi-LLM Inference: реализуется мульти-модельная среда для быстрого внедрения новых LLM и оптимизации стоимости за счет улучшенной маршрутизации семантических запросов.
3.3. Трансформация платформы в полноценное, зрелое решение класса AI-Factory. В этой фазе фиксированные сценарии постепенно уступят динамическим агентам, которые смогут самостоятельно выбирать и реализовывать необходимые действия в целевых системах. Пользователи смогут настраивать агенты под свои нужды, расширяя функциональные возможности благодаря динамической архитектуре. ИИ-ассистенты эволюционируют в автономных агентов. Упрощенные коммуникационные каналы взаимодействия сохраняются. Разрабатывается и внедряется архитектура мульти-агентных оркестраторов, доступ агентов к внутренним системам реализуется через UI и API.
Важно отметить, что развитие любых подходов на основе генеративного ИИ требует реализацию на базе облачных инфраструктуры и платформ, что в свою очередь формирует стратегический приоритет как на базовых (DevSecOps), так и на продвинутых (LLMSecOps) практиках информационной безопасности.
Cтек технологий классических DevSecOps-практик является отличным базисом для построения AI-Native организации. Однако, для осуществления подобного технологического перехода необходим SDLC следующего поколения, который в свою очередь использует все преимущества ИИ-технологий в рамках производственного конвейера и при этом включает в себя два синхронизированных между собой цикла:
-
Канонический цикл разработки защищенных приложений (DevSecOps);
-
Цикл безопасной работы с данными и моделями в рамках производства AI-Native приложений.
AI-Powered Trustware Development Lifecycle
Цикл разработки защищенных систем следующего поколения адресует основные аспекты кибербезопасности и содержит необходимые практики на всех этапах разработки программного обеспечения с учетом нативно-встроенных в процесс ИИ-технологий. Охватывает ключевые области, которые необходимы и достаточны для разработки, управления и защиты данных, датасетов, моделей ИИ, их интеграции в релизный процесс, реализации производственного конвейера защищенного ПО, а также встраивания практик обеспечения целостности ПО на всех этапах производства и контроля рисков цифровых цепочек поставок. Только такой цикл позволит повысить уровень безопасности гибридных информационных систем в новом ландшафте современных киберугроз.
AI-Powered Trustware Development Lifecycle — единый контур, где в рамках безопасного производственного конвейера ведется управление созданием защищенных приложений, данных, датасетов и ИИ-моделей (как неотъемлемой части цифровых продуктов), а ИИ сам еще усиливает и ускоряет Dev- и AppSec-процессы.
Риски безопасности AI-Native приложений
Интуитивно понятно – приложения и цифровые сервисы, где ключевую роль играют модели машинного обучения могут быть уязвимы, а сам факт наличия интеграции с моделями существенно расширяет поверхность атаки для злоумышленников.
Так, приложения, использующие предиктивные ML-модели, сталкиваются с рядом специфических вызовов в области ИБ, связанных как с машинным обучением, так и с общими аспектами кибербезопасности. В частности:
🔺Злоумышленники могут внедрять вредоносные или ложные данные в обучающую выборку, чтобы исказить работу модели и сделать прогнозы неправильными или преднамеренно вредоносными.
🔺Входные данные могут быть тонко изменены так, чтобы ввести модель в заблуждение и в результате предоставить пользователю искаженный прогноз.
🔺При атаке с “обратным инжинирингом” если модель обучается на конфиденциальных данных, существует риск восстановления или раскрытия этих данных через анализ выходных результатов модели.
🔺Недостаточная аутентификация и авторизация могут привести к тому, что злоумышленники получат доступ к модели, конфигурациям или обучающим данным и изменят их.
🔺При отсутствии контроля версий и средств проверки целостности модели возможна замена или подмена модели на вредоносную.
🔺Сама предиктивная модель и её параметры могут б��ть конфиденциальной интеллектуальной собственностью, и компрометация их может привести к конкурентным рискам.
🔺Серверы, API и облачные сервисы, на которых развернута модель, могут содержать уязвимости, позволяющие атаковать систему извне.
Относительно простые приложения на основе промптов также сталкиваются с рядом угроз безопасности и надежности:
🔺Атаки с внедрением промптов и утечка данных из-за плохо сформулированных или вредоносных запросов
🔺Отсутствие контекста или управления состоянием может приводить к непреднамеренным и непредсказуемым результатам, повышая риск неправильного использования
🔺Пользовательские промпты могут вызывать непоследовательные или предвзятые ответы, что несет риски нарушения нормативных требований или этических стандартов.
Агентные приложения, обладающие автономностью и доступом к различным системам, сталкиваются с рядом серьезных угроз безопасности, включая несанкционированный доступ, расширенную поверхность атаки из-за интеграции с несколькими внешними системами, а также имеют уязвимости в процессах принятия решений.
В случае, если злоумышленник получит контроль над автономным агентом, последствия могут быть критическими, особенно в системах жизнеобеспечения, приложениях финансового сектора или системах критической информационной инфраструктуры. Необходимо внедрять жесткие механизмы управления доступом и сквозное шифрование для защиты от подобных угроз. Также важно обеспечивать целостность и конфиденциальность данных, поскольку агенты часто работают с чувствительной информацией. Это требует защиты данных в состоянии покоя, при передаче и при доступе через защищенные API.
Некорректно разработанные или вредоносные плагины, взаимодействующие с конфиденциальными данными или критически важными системами, могут привести к утечкам данных или несанкционированному доступу. Плагины больших языковых моделей сталкиваются проблемами совместимости, когда обновления могут вносить уязвимости, а интеграция с чувствительными системами повышает риск утечек данных. Очень важно обеспечивать безопасное взаимодействие через API, регулярное обновление и надежные механизмы контроля доступа. Ресурсоемкие плагины могут ухудшать производительность, что увеличивает риск эксплуатации.
Комплексные приложения на базе LLM сталкиваются с серьёзными угрозами безопасности из-за глубокой интеграции с различными системами и обработки большого объёма чувствительных данных. Основные риски включают в себя уязвимости в API, утечки данных, атаки с использованием вредоносных входных данных. Также комплексным приложениям построенных на базе генеративного ИИ присущи ошибки конфигурации, ведущие к несанкционированному доступу или утечкам. Их сложность также затрудняет соблюдение регуляторных требований и соответствие индустриальным стандартам ИБ во всех компонентах системы.
Решения для реализации защищенного ИИ
Подходы к разработке приложений на базе LLM и генеративного ИИ находятся на ранней стадии развития. Это порождает новые вызовы, выходящие за рамки традиционной безопасности и практик DevSecOps. Хотя существует множество стандартов и лучших практик, которые помогают организациям снижать риски традиционных программных или информационных систем, риски, создаваемые LLM, во многих отношениях являются уникальными. Например, ИИ-модели могут быть обучены на данных, которые со временем могут изменяться — иногда существенно и неожиданно, — что влияет на функциональность и надежность системы способами, которые трудно понять. ИИ-системы и контексты, в которых они развертываются, часто являются сложными, что затрудняет обнаружение и устранение сбоев при их возникновении. Системы на базе LLM по своей природе находятся под влиянием общественных процессов и человеческого поведения.
Спасет ли статический анализ кода от специфических рисков типа атаки через внедрение промптов или от этических и социальных искажений и предвзятости сложной языковой модели? Наверное нет. Полезно ли знать из каких компонент с открытым исходным кодом состоит автономный AI агент? Наверное да, но абсолютно недостаточно. Защита систем на базе LLM требует пересмотра стратегий безопасности с учётом новых, специфичных для моделей уязвимостей, процессов разработки – тестирования – внедрения данных систем в промышленную эксплуатацию. Хорошей новостью является то, что в индустрии появляются новые решения, направленные на устранение этих пробелов в безопасности.
Прежде всего это LLM-фаерволы предназначенные для защиты больших языковых моделей от несанкционированного доступа, вредоносных запросов и потенциально опасных ответов. Такой фаерво�� отслеживает и фильтрует взаимодействие с LLM, блокируя подозрительные или вредоносные входные данные, которые могут повлиять на поведение модели. Он также реализует заранее определённые правила и политики, гарантируя, что LLM отвечает только на допустимые запросы в рамках установленных этических и функциональных ограничений. Кроме того, LLM-фаервол предотвращает утечку данных и защищает конфиденциальную информацию, контролируя потоки данных, поступающих в модель и исходящих из нее.
Другой категорией средств защиты являются сканеры уязвимостей — специализированные инструменты, разработанные для выявления и оценки уязвимостей, присущих большим языковым моделям. Сканеры LLM способны обнаруживать такие проблемы, как атаки через внедрение промптов, атаки с использованием вредоносных входных данных. Сканер оценивает ответы и поведение модели в различных сценариях, выявляя уязвимости, которые могут быть упущены традиционными средствами безопасности.
Защитные механизмы для больших языковых моделей (LLM Guardrails) — это специально разработанные алгоритмы, которые обеспечивают работу моделей в рамках определённых этических, юридических и функциональных границ. Эти защитные механизмы помогают предотвратить генерацию моделью вредоносного, предвзятого или неуместного контента за счёт применения ряда правил, ограничений и контекстных рекомендаций во время взаимодействия. Защитные механизмы для LLM могут включать фильтрацию контента, этические руководства, обнаружение вредоносных входных данных и проверку намерений пользователя.
Решения класса AI-SPM (AI Security Posture Management, Управление Безопасностью ИИ) реализуют концепцию платформенного подхода к управлению безопасностью систем искусственного интеллекта, включая большие языковые модели и генеративные AI-системы (GenAI). Основная задача AI-SPM — охватить весь жизненный цикл ИИ-приложений (от обучения моделей до развертывания ИИ-систем в промышленной эксплуатации), помогая обеспечить устойчивость, надежность и соответствие требованиям ИБ и индустриальным стандартам. AI-SPM предоставляет полную прозрачность экосистемы ИИ внутри организации, индентифицируя все кейсы использования ИИ, а также связанные с ними риски. Позволяет управлять политиками безопасности, консолидировать уязвимости данных, пользователей, ИИ-моделей, приложений, выявлять угрозы, контролировать избыточные права доступа, утечки конфиденциальных данных, ошибки в настройках конфигураций и т.д.
Решения для безопасности приложений на базе архитектуры ИИ-агентов (Agentic AI App Security). Применение агентного ИИ всё еще находится в стадии становления, активно разрабатываются промышленные протоколы взаимодействия (такие как MCP, A2A), при этом новые решения в области безопасности агентных систем уже начинают появляться. Пока до конца неясно, какие именно уникальные аспекты должны быть ключевыми для защиты агентных приложений ввиду только формирующегося рынка, однако с уверенностью можно сказать, что данная область будет являться крайне высокоприоритетной сферой безопасности ИИ.
Лучшие практики
В один прекрасный день появятся модели угроз, классификации рисков и угроз безопасности, процессы оценки зрелости, стандарты, сертификаты соответствия, тренинги, консультанты с 10-летним опытом работы – всё это c приставкой LLM/ИИ. Однако, о чем нужно подумать и c чего же можно начать прямо сейчас?
AI-Governance с первого дня
Организации, внедряющие AI в процессы разработки, должны сразу выстраивать систему управления — это не только вопрос контроля, но и условие для безопасного масштабирования. AI меняет сам подход к разработке, и без правил и процессов риски остаются скрытыми до момента, когда они становятся критичными. Грамотное управление процессом — это карта использования технологий в жизненном цикле разработки, чёткие политики по применению генеративного ИИ для кодинга и разработки AI-Native приложений, встроенные механизмы контроля и аудита через инструментальный стек. Такой фундамент позволяет инновациям происходить быстро, но в рамках безопасных «ограждений».
Безопасность GenAI-кода
Генеративный ИИ ускоряет написание кода, но часто снижает его качество: почти половина сгенерированных фрагментов содержат уязвимости. Поэтому важно интегрировать безопасность в самые ранние этапы цикла разработки: IDE, Pull Requests.
Автоматические сканеры кода и проверенные код-фиксы помогают сократить переделки и снизить нагрузку на команды. Важная цель — сделать защиту «дружественной к разработчику», чтобы она шла в ногу со скоростью работы и не ломала привычный рабочий процесс.
Мониторинг происхождения AI-компонент и контроль цифровых цепочек поставок
AI-системы активно используют зависимости с открытым исходным кодом, что вносит в программные продукты риски низкого качества кода и внедрения вредоносных компонентов. Уже сегодня ИИ влияет на экосистему open-source, и это, соответственно, меняет всю картину безопасности ПО.
Компании должны анализировать зависимости open-source библиотек как можно раньше, формировать SBOM и отслеживать новые компоненты в цепочке поставок. Постоянный мониторинг позволяет вовремя выявлять уязвимости и вредоносные пакеты, не давая им проникнуть в зону промышленной эксплуатации.
Рантайм-тестирование ИИ-приложений
AI-Native приложения создают принципиально новые векторы атак — как при интеграции агентов между собой, так при взаимодействии с LLM. Такие уязвимости не детектируются традиционными сканерами статического анализа кода, поэтому здесь требуется специализированный подход.
Тестирование должно имитировать реальные условия продакшн-среды, включая проверку API и веб-приложений. AI-решения способны помогать в выявлении скрытых логических ошибок и недостатков авторизации. Это позволяет идентифицировать и устранить уязвимости вроде OWASP Top 10 до того, как ими воспользуются атакующие.
Приоритизация по контексту
Когда команды разработки ускоряются, возникает обратный эффект: количество срабатываний от ИБ-инструментов растет лавинообразно. Без контекстной фильтрации разработчики тонут в шуме, что снижает эффективность.
Решение — динамическая оценка рисков, фильтрация «новых» проблем от технического долга и гибкая настройка порогов критичности. Такой подход позволяет фокусироваться на реальных угрозах, игнорируя второстепенные срабатывания, и направлять усилия на то, что действительно важно.
Непрерывное измерение и оптимизация
Для развития процессов защищенности при разработке ИИ-приложений необходимо не просто внедрить практики, а постоянно измерять и оценивать их эффективность. Без метрик невозможно понять, что работает, а что нет.
Ключевые показатели — скорость исправления, процент закрытых уязвимостей, внедрение защищенных GenAI-процессов и их адаптация командами разработки. А регулярная отчетность топ-менеджмента с бизнес-ориентированными метриками помогает связать вопросы кибербезопасности ИИ с ценностью для компании и обеспечить поддержку необходимых изменений на всех уровнях.
Заключение
AI-трансформация требует не просто внедрения технологий, а глубокой перестройки инженерных и организационных практик с приоритетом на безопасность и устойчивость.
Организации, которые уже сегодня выстраивают защищенный AI-Native контур, завтра получат стратегическое преимущество в скорости, качестве и доверии к своим цифровым продуктам.
Автор: YSergeev
