ИИ уже вошёл в разработку. Компании тратят большие бюджеты на ИИ-вычисления, часть лидеров индустрии вообще пророчит закат профессии программиста. Если в вашей команде есть разработчики, они уже пользуются агентными IDE вроде Cursor или отдельными инструментами вроде Claude Code и Codex. В работе или дома, но пользуются.
Работодатели не ждут, пока внутри компании расцветёт «теневой ИИ», и сами внедряют агентный ИИ (Agentic AI) в разработку: производительность, автотесты, генерация документации. Восемь вопросов ниже — план для тех, кто только начинает, и способ найти дыры для тех, кто уже внутри процесса. Прежде чем доверять ИИ защиту, полезно понять, где ИИ в кибербезопасности реально помогает, а где начинается маркетинг.
1. Защищено ли рабочее место сотрудника?
Защита конечных точек не устарела. Наоборот, стала критичнее. Система на базе LLM может автономно скачивать и запускать скрипты из интернета, искать файлы и рассылать почту со скоростью, которую человек не воспроизведёт.
ИИ-агент под воздействием непрямых промпт-инъекций генерирует вредоносные команды на лету. Значит, у вас должны быть продукты класса EDR и SIEM, которые эти команды заметят, помогут расследовать и остановят инцидент.
2. Защищены ли цепочки поставок?
Атаки на цепочку поставок и раньше были головной болью разработки. В сфере ИИ они особенно опасны, потому что скорость развития технологий заставляет пользователей ставить самые свежие версии, а разработчиков — выкатывать обновления часто. Компрометация в такое окно попадает легко.
ИИ-агент способен установить не просто скомпрометированный пакет, а изначально вредоносный. Классический сценарий: модель галлюцинирует несуществующее имя пакета, а злоумышленник заранее это имя регистрирует. Централизованный корпоративный репозиторий с проверкой пакетов на безопасность и соответствие политикам эту атаку закрывает.
3. Проведено ли обучение сотрудников?
Даже технически грамотный разработчик не всегда знает, чем LLM отличается от обычной программы. Модели галлюцинируют, поэтому данные из ответа нужно проверять в первоисточнике, а деструктивные действия агента подтверждать вручную.
- Агенты запускаются в изолированной среде с минимальными привилегиями и отключённой телеметрией.
- Исполняемые файлы агента берутся из доверенного источника.
- Чат-формат создаёт иллюзию приватности, а на деле переписки могут читать владельцы сервиса и использовать их для обучения модели. Сотруднику это стоит проговорить прямо.
4. Правильно ли выбрана модель доступа к LLM?
ИИ-инструменты разработчика требуют огромного объёма вычислений. Где эти вычисления выполнять, зависит от того, насколько критичен и конфиденциален код.
Для менее критичного кода минимум — централизованные корпоративные подписки авторитетного провайдера с SSO, контролем аккаунтов и zero data retention. Это защищает от типичной истории, когда скомпрометирован личный аккаунт разработчика, а корпоративные данные всплывают в даркнете.
Если требования жёстче (регуляторные, отраслевые), уместнее on-premise-модель: своя команда или интегратор разворачивает GPU-инфраструктуру внутри контура, а поверх запускаются модели. Тогда нагрузка по безопасности переезжает на защиту серверов, контейнеров и самих моделей.
Есть и гибрид: небольшие autocomplete-модели гоняют прямо на устройствах разработчиков, тяжёлые арендуют GPU в private cloud. У каждого варианта своя модель угроз, и её нужно закладывать в решение.
5. Правильно ли реализована модель доступа к корпоративному контексту?
Чтобы ассистент был полезен, ему нужен доступ к рабочему контексту: коду, задачам, вики, документации. У всех этих источников есть ролевые модели доступа. Агент, запущенный от имени разработчика, должен наследовать его права, а не игнорировать их.
На практике этим часто пренебрегают. Инструмент подключается с правами создателя коннектора или полного администратора. Это значит: скомпрометирована одна учётка разработчика — злоумышленник получает доступ к привилегированным данным всей компании.
6. Реализованы ли LLM-специфичные меры безопасности?
Кроме традиционных методов защиты, LLM-системы требуют своих. Без них ни разработчик, ни агент не работают безопасно.
- Observability. Действия агентов и запросы к LLM пишутся в SIEM или в специализированные средства (Langfuse, Arize Phoenix), чтобы их можно было потом разобрать.
- AI Firewall и guardrails. Отдельный класс решений против утечек данных (в том числе персональных при облачной модели) и против промпт-инъекций.
- Secure by design. Собственные in-house инструменты стоит сразу закладывать по лучшим практикам защиты от этих атак, а не патчить потом.
- AI Redteaming. ИИ-специфичное тестирование на проникновение показывает, где реально дырка, а где только табличка «security» в презентации.
7. Есть ли единый репозиторий доверенных моделей, навыков, MCP-серверов?
Современные агенты легко расширяются. MCP-серверы (Model Context Protocol) дают доступ к API сторонних и внутренних сервисов, а навыки (Agent Skills) быстро адаптируют агента к новым задачам.
За удобство приходится платить. Полезный агентный навык вполне может оказаться вредоносным — та же история, что с плагинами для браузеров и IDE. Отдельный вектор атаки — файлы моделей: загрузка недоверенной модели может привести к исполнению кода, зашитого в неё. Если команды или разработчики имеют право сами разворачивать модели, риск ещё выше.
Решение простое: единый централизованный репозиторий одобренных моделей, навыков и артефактов, каждый из которых сканируется на угрозы.
8. Организованы ли накопление экспертизы, обмен опытом и практиками?
Самый нетехнический из вопросов, но обычно самый провальный. Нужна культура: прозрачность процессов, вовлечённые лица, принимающие решения, и выделенные ресурсы у департаментов, участвующих в трансформации.
- Следите за изменениями в законодательстве и требованиями регуляторов.
- Изучайте практики оценки рисков и безопасности агентных систем.
- Оценивайте фреймворки (например, OWASP Top-10 for Agentic Security) на применимость к вашей команде.
- Создайте центр компетенций по безопасности ИИ: методология, аудит, помощь при инцидентах.
- Введите роль AI Security-чемпионов, чтобы поднять вовлечённость команд.
Заключение
Безопасность ИИ в разработке не бесплатная. Плюсы понятны: рост продуктивности, сокращение time-to-market. Риски частично новые, поэтому и защита строится в три параллельных потока.
- Не бросать традиционные меры защиты: EDR, SIEM, контроль цепочки поставок.
- Достроить новые процессы: observability, guardrails, AI Redteaming, репозиторий доверенных артефактов.
- Вкладываться в людей: обучение, вовлечённость, распространение опыта внутри компании.
Восьми вопросов мало для полного чек-листа безопасности ИИ-разработки. Но они подсвечивают белые пятна и дают точку старта.
Материал подготовлен на основе индустриальной практики внедрения LLM во внутренние сервисы и инструменты разработчиков.
Планируете внедрять ИИ в бизнес? eq.team проводит внедрение ИИ под ключ — от аудита и пилота до масштабирования, старт от 0 ₽.
