Что спросит служба безопасности клиента, если вы используете ИИ для разработки

Как не потерять сделку из-за вопросов, к которым ваша команда не готовилась

Новая строка в security questionnaire

Ещё два года назад служба безопасности корпоративного клиента спрашивала привычное: шифрование, пентест, ISO 27001, NDA, хранение данных. Сегодня к этому добавилась отдельная секция — про ИИ. И она становится длиннее с каждым кварталом.

По данным Forrester, в 2025 году security-лидеры стали критически оценивать AI-инвестиции, смещая приоритет с функциональности на измеримое управление рисками [1]. Это напрямую затрагивает вендоров и аутсорсеров: если вы разрабатываете продукт с помощью AI-инструментов — особенно для банков, страховых, фармацевтики, ретейла с персональными данными — вас будут спрашивать об этом предметно.

Эта статья — шпаргалка для CTO, Tech Lead и AppSec-команды. Что именно спрашивают, почему спрашивают и что нужно иметь под рукой, чтобы не потерять сделку из-за вопросов, к которым никто не готовился.

Блок 1: Какие AI-инструменты вы используете и кто это знает

Первый вопрос почти всегда звучит так: "Перечислите AI-инструменты, которые применяются в разработке."

Служба безопасности не просто хочет список. Она проверяет три вещи сразу: есть ли у вас реестр одобренных инструментов, есть ли governance, и нет ли у вас shadow AI.

Shadow AI — несанкционированное использование AI-инструментов без ведома IT и безопасности — в 2025 году стало одним из главных корпоративных рисков. По данным Deloitte, доступ сотрудников к AI вырос на 50% в 2025 году, при этом только каждая пятая компания имеет зрелую модель управления [2]. Исследование Cyberhaven зафиксировало, что 27,4% корпоративных данных, которые сотрудники вводят в AI-инструменты, являются чувствительными — из них 12,7% составляет исходный код [3].

По данным Melbourne Business School (апрель 2025), 48% сотрудников загружали конфиденциальные данные компании или клиентов в публичные AI-инструменты, а 44% признались, что используют AI вопреки корпоративной политике [4].

Что должно быть готово к ответу:

1. Реестр разрешённых AI-инструментов с датами одобрения и ответственным.
2. Политика допустимого использования AI (Acceptable Use Policy), охватывающая разработку.
3. Процедура вывода из использования неодобренных инструментов.
4. Механизм мониторинга — хотя бы базовый (прокси-логи, DLP-правила, поведенческая аналитика).

Отсутствие политики — стоп-сигнал. Даже предварительный документ в стадии черновика лучше его полного отсутствия.

Блок 2: Куда уходит ваш код, когда разработчик нажимает Tab

Это самый технически неудобный вопрос. Служба безопасности спрашивает: что происходит с кодом, когда IDE-плагин или агент его "видит"?

Большинство AI-инструментов для разработки работают как cloud-сервисы: фрагмент кода или контекст отправляется на серверы вендора, там обрабатывается LLM, ответ возвращается. Это означает, что код физически покидает контур разработки.

По данным Augment Code, большинство AI-инструментов не могут предоставить даже диаграмму потоков данных, потому что "security visibility was not architected from inception" [5]. Это проблема при прохождении аудита.

Типичные вопросы в этом блоке:

1. Есть ли у вас Data Processing Agreement (DPA) с каждым AI-вендором?
2. Как долго вендор хранит фрагменты кода после запроса? Можно ли управлять retention?
3. Применяется ли Zero Data Retention (ZDR) API — то есть удаляются ли данные сразу после обработки?
4. Что входит в понятие "не храним данные" у вашего вендора — включает ли это телеметрию, логи ошибок, аналитику использования, которые могут содержать фрагменты кода?
5. Есть ли data flow diagram с указанием того, где код транзитирует и где может сохраняться?

Важный нюанс: вендор может честно говорить "мы не обучаем на ваших данных" и при этом хранить логи запросов 30+ дней. Обе гарантии нужны явно и раздельно [6].

Что иметь под рукой: DPA с каждым инструментом, который использует команда. Список sub-processors — третьих сторон, которым вендор может передавать данные. Ответы на вопросы об инфраструктуре обработки (регион, облако, изоляция тенанта).

Блок 3: Обучается ли модель на вашем коде

Это юридический и репутационный вопрос одновременно.

По данным Augment Code, Intellectual Property Tracking входит в число ключевых рисков AI-инструментов: предложения модели могут содержать следы проприетарных алгоритмов других компаний, а код клиента потенциально может влиять на модели, обслуживающие конкурентов [7]. Это не теория — именно по этой причине одна финансовая организация получила инцидент стоимостью $2,3 млн, когда API-ключ, зафиксированный через AI-инструмент, появился в подсказках для других разработчиков [5].

Что проверяет безопасность:

1. Есть ли у вашего AI-вендора явный opt-out от использования данных для обучения, и подкреплён ли он юридически enforceable гарантией — не просто словами в FAQ?
2. Применяется ли этот opt-out ко всем тирам (free, business, enterprise) — или только к платным?
3. Как вы отслеживаете, чтобы код клиента не попадал в инструменты, где opt-out не настроен?

По данным анализа семи крупных AI-платформ, 79% платформ не публикуют достаточно документации по compliance для прохождения enterprise-оценки [8]. GitHub Copilot предоставляет opt-out в Business и Enterprise тирах с формальным DPA; Amazon Q Developer разграничивает политики по тирам — в бесплатном тире данные могут использоваться для улучшения сервиса [7].

Блок 4: Зависимости, которые AI добавил в проект

Это место, где большинство команд проваливаются — просто потому что никто не думал о зависимостях как об AI-риске.

По данным исследования, опубликованного на USENIX Security Symposium в 2025 году, анализ 576 000 фрагментов кода на 16 LLM-моделях показал: почти 20% рекомендованных пакетов не существует в реальности [9]. Это явление получило название "package hallucinations". Атаки типа "slopsquatting" используют именно это: злоумышленники заранее регистрируют пакеты под именами, которые AI-инструменты часто галлюцинируют, — и ждут, пока разработчик выполнит npm install [9].

Помимо несуществующих пакетов:

1. По данным SQ Magazine, 86% организаций используют сторонние пакеты с критическими уязвимостями в AI-driven средах [10].
2. Поставки зависимостей выросли на 40% год к году в 2025 году; AI-модели часто рекомендуют пакеты с непатченными CVE [10].
3. 62% разработчиков ориентируются на AI-предложения при выборе зависимостей [10].

Служба безопасности будет спрашивать:

1. Как вы проверяете зависимости, которые добавляет AI? Есть ли SCA (Software Composition Analysis) в пайплайне?
2. Как часто обновляются lock-файлы и проверяются ли они на integrity?
3. Есть ли процедура проверки новых пакетов перед merge?
4. Кто в команде несёт ответственность за зависимости в PR, сгенерированных с помощью AI?

AI написал зависимость быстро. Но читает ли кто-то lock-файл до merge — вот что реально интересует безопасность клиента. Именно на этом уровне работает HighVibe: анализ конкретного изменения, включая новые и транзитивные зависимости, до того как они попадают в main.

Блок 5: Как вы контролируете то, что AI сгенерировал

По данным Checkmarx, почти 70% CISO, AppSec-менеджеров и разработчиков оценивают долю AI-generated кода в их продуктах выше 40% [11]. При этом, по данным Black Duck, 11% компаний либо знают об использовании AI, либо подозревают его — но не мониторят [12].

Служба безопасности спрашивает не "используете ли вы AI" — а "как вы знаете, что AI-код безопасен перед выходом в production".

Конкретные вопросы:

1. Проходит ли AI-сгенерированный код обязательное peer review, или его принимают на доверии к инструменту?
2. Есть ли в CI/CD автоматические проверки security для всех изменений — в том числе тех, что написаны с помощью AI?
3. Маркируется ли AI-generated код как-то, чтобы его можно было отследить?
4. Ограничено ли использование AI в критичных компонентах — аутентификации, финансовых расчётах, обработке персональных данных?

Veracode в анализе 2025 года фиксирует: 45% AI-generated кода содержит уязвимости по OWASP Top 10 [9]. Плотность уязвимостей в AI-коде в 2,7 раза выше, чем в написанном вручную [10]. По данным GitGuardian, репозитории, использующие GitHub Copilot, имеют на 40% более высокий уровень утечек секретов по сравнению с теми, где AI не используется [9].

Блок 6: Агентный AI и вопрос о границах доступа

Это новая зона, которая появилась в enterprise-опросниках в 2025–2026 годах.

Агентные AI-инструменты — Cursor, Claude Code, GitHub Copilot Workspace и другие — могут не только предлагать код, но и читать файлы, выполнять команды в терминале, взаимодействовать с внешними системами через MCP. Именно это делает их уязвимыми для нового класса атак.

По данным Coalition for Secure AI, в 2026 году доминирующий рабочий процесс разработчика предполагает AI-инструмент с полным доступом к кодовой базе — при этом большинство security-команд имеют нулевую видимость в то, что инструменты реально читали, писали и выполняли [13].

CVE-2025-11445 (Kilo Code) показал, как работает атака: вредоносные инструкции встроены в README или комментарий к коду; когда AI-ассистент читает репозиторий в рамках обычной работы, он получает инструкции изменить конфигурацию и разрешить git-команды, которые ранее были заблокированы [13].

В 2026 году CVE-2025-53773 продемонстрировал remote code execution через GitHub Copilot с CVSS 9.6 — скрытая prompt injection в описании pull request [14]. Cursor IDE получил отдельный CVE за возможность манипуляции конфигом MCP-сервера через indirect prompt injection [15].

Вопросы службы безопасности клиента:

1. Работает ли агентный AI-инструмент в изолированной среде, или у него есть доступ к .env-файлам и секретам на машине разработчика?
2. Есть ли human-in-the-loop для критичных действий — например, деплоя или изменения конфигов?
3. Каков принцип наименьших привилегий для AI-агентов в вашей инфраструктуре?
4. Как вы защищаетесь от prompt injection через внешний контент, который агент читает (PR-описания, README, issues)?

По данным OWASP, prompt injection встречается в 73% проверенных AI-развёртываний; при этом специализированные защиты от него настроены лишь у 34,7% организаций [15].

Блок 7: Compliance и сертификаты — что применимо к AI-tooling

Наличие SOC 2 Type II у вашей компании не отвечает на вопрос "а входит ли ваш AI-инструмент в scope этого аудита".

Служба безопасности будет смотреть на это разграничение. По данным Augment Code, традиционные Trust Service Criteria AICPA создавались не для AI-систем, и понятие "адекватного AI governance" в рамках SOC 2 каждая компания трактует по-своему [7].

Конкретные вопросы:

1. Входит ли использование AI-инструментов в scope вашего SOC 2 аудита?
2. Есть ли у вендоров AI-инструментов SOC 2 Type II (не только Type I)?
3. Применяется ли ISO/IEC 42001 (стандарт управления AI) — либо вашей компанией, либо вендором?
4. Есть ли у AI-вендоров сертификация по стандартам, актуальным для вашей отрасли — HIPAA, FedRAMP, PCI DSS?
5. Что происходит с данными при breach на стороне AI-вендора? Каков процесс уведомления?

По данным анализа платформ, Enterprise-тир с Zero Retention API и Customer-Managed Encryption Keys (CMEK) — не просто маркетинговый пункт: это позволяет демонстрировать контроль на аудите, а не полагаться на заверения вендора [16].

Блок 8: Управление изменениями — кто читает PR до merge

Это операционный вопрос, но он прямо связан с безопасностью.

По данным Tenable, основные вопросы службы безопасности к DevOps-командам при использовании AI: есть ли человек в процессе для каждого деплоя, читает ли кто-то полный diff перед merge, как часто CI/CD проходит security-проверки [17].

Практический контекст: AI-генерирует код быстро, PR-дифы становятся больше, review-усталость растёт. По данным исследований, 58% разработчиков доверяют AI-выходным данным без дополнительного тестирования [10]. Это и есть root cause большинства инцидентов.

Вопросы клиентской безопасности:

1. Кто в команде отвечает за security review каждого PR? Или это автоматизировано?
2. Что произойдёт, если AI добавит небезопасную конфигурацию в файл инфраструктуры — кто это заметит и когда?
3. Как вы отслеживаете критичные изменения — конфиги, миграции БД, CI/CD-файлы — отдельно от обычного кода?
4. Есть ли release gate — момент, когда кто-то явно подтверждает, что ничего критичного перед выпуском не упущено?

AI написал быстро. PR никто не прочитал до конца. Конфиг поехал в prod. Именно этот сценарий — слепое пятно, которое HighVibe закрывает как дополнительный слой контроля: короткий сигнал о том, что реально блокирует merge или release, без длинного отчёта, который никто не дочитает в пятницу вечером.

Блок 9: Интеллектуальная собственность и лицензионные риски

Это юридический блок, но его задаёт security — особенно если клиент работает в regulated-отраслях.

AI-инструменты обучены на публичном коде, включая код под лицензиями GPL, LGPL, MIT, Apache. Если модель воспроизводит фрагменты обучающих данных, ваш продукт может содержать чужой код с ограничениями на использование. По данным Black Duck, лицензионный compliance не является приоритетом для большинства security и DevOps команд — что создаёт скрытый юридический риск [12].

Вопросы:

1. Есть ли у вас инструмент для детектирования AI-сгенерированных фрагментов с потенциальными лицензионными проблемами?
2. Как вы проверяете происхождение AI-предложений перед включением в продукт?
3. Есть ли у вашего AI-вендора IP indemnity — юридическая защита на случай претензий по авторским правам из-за сгенерированного кода?

Amazon Q Developer предоставляет IP indemnity protection. Ряд других вендоров предлагают code similarity detection для предотвращения непреднамеренного воспроизведения чужого кода [7].

Практический чек-лист: что иметь перед встречей с безопасностью клиента

1. Политика допустимого использования AI в разработке (AI Acceptable Use Policy) — даже черновая версия лучше её отсутствия.
2. Реестр AI-инструментов с указанием: название, вендор, статус одобрения, DPA подписан / нет.
3. Список DPA с ключевыми параметрами: срок хранения данных, opt-out от обучения, Zero Retention API, CMEK.
4. Документация по SCA-проверкам зависимостей — скриншоты, конфиги CI, пример отчёта.
5. Процедура security review PR — хотя бы описание в confluence/notion: кто проверяет, что проверяет, как часто.
6. Ответ на вопрос про агентный AI: какие права у инструмента, изолирован ли он, есть ли human-in-the-loop.
7. SOC 2 / ISO-сертификаты вендоров — и объяснение, входит ли AI-tooling в scope вашего собственного аудита.
8. Ответ про shadow AI: как вы знаете, что разработчики не используют неодобренные инструменты.

Ошибки, которые стоят сделки

Первая ошибка — отрицать. "Мы используем Copilot, но это ничего особенного, это просто автодополнение." Для клиента это звучит как "мы не понимаем риски".

Вторая ошибка — обещать без документации. "Мы всё проверяем" без процедуры, без инструментов, без DPA — пустые слова.

Третья ошибка — не знать своих вендоров. "Не знаю, обучается ли модель на нашем коде" — это ответ, который означает провал security review.

Четвёртая ошибка — игнорировать агентный контекст. Если команда использует Claude Code, Cursor или Devin в агентном режиме, а ответ на вопрос про права доступа — "мы не думали об этом", это красный флаг.

Пятая ошибка — отдельный ответ на каждый вопрос без системы. Служба безопасности хочет видеть не набор отдельных мер, а связную программу: политика → реестр → технический контроль → процесс ревью → аудит.

Будущее: куда движутся требования

EU AI Act в части высокорисковых систем начинает применяться с августа 2026 года. Prompt injection уже маппируется как минимум на семь крупных фреймворков: OWASP, MITRE ATLAS, NIST, EU AI Act, ISO 42001, GDPR, NIS2 [18]. Это означает: через год отсутствие документированных мер против prompt injection в AI-tooling будет не просто плохой практикой — оно будет нарушением требований для части клиентов.

OWASP в декабре 2025 опубликовал отдельный Top 10 для Agentic Applications — с участием более 100 исследователей [19]. Это сигнал: агентный AI становится отдельной дисциплиной безопасности, а не подразделом общего AppSec.

По данным Cisco State of AI Security 2026, 83% организаций планируют развёртывание агентного AI, но только 29% считают себя готовыми делать это безопасно [18].

Заключение

Security questionnaire по AI — это уже не экзотика. Это стандартный пункт enterprise-аудита, который будет только усложняться. Хорошая новость: большинство вопросов решаемы через процесс, а не через замену всего стека. Политика → реестр → DPA → SCA → ревью → release gate.

Команды, у которых есть понятный ответ на каждый вопрос из этой статьи, выигрывают не потому что у них "лучше безопасность". Они выигрывают потому что могут это объяснить.

Контроль AI-изменений до merge и до релиза — это то место, где большинство команд имеют пробел. Инструменты вроде HighVibe закрывают этот пробел конкретно: анализ изменения, новых зависимостей, конфигов и релизного контекста — с коротким ответом "что реально блокирует выпуск", а не ещё одним длинным отчётом.

Источники

[1] Forrester Research — "Security Leaders Will Critically Evaluate AI Investments in 2025" — https://www.augmentcode.com/guides/7-soc-2-ready-ai-coding-tools-for-enterprise-security

[2] Deloitte — "2026 State of AI in the Enterprise" — https://www.wiz.io/academy/ai-security/shadow-ai

[3] Cyberhaven — "Shadow AI: Corporate Data in AI Tools Report 2024" — https://www.worklytics.co/resources/shadow-ai-detection-gdpr-compliance-2025

[4] Melbourne Business School — "Employee AI Usage Survey, April 2025" — https://www.mend.io/blog/shadow-ai-examples-risks-and-8-ways-to-mitigate-them/

[5] Augment Code — "7 SOC 2-Ready AI Coding Tools for Enterprise Security" — https://www.augmentcode.com/guides/7-soc-2-ready-ai-coding-tools-for-enterprise-security

[6] Augment Code — "CTO AI Coding Tool Evaluation Checklist (2026)" — https://www.augmentcode.com/guides/cto-ai-coding-checklist

[7] Augment Code — "AI Coding Tools SOC2 Compliance: Enterprise Security Guide" — https://www.augmentcode.com/tools/ai-coding-tools-soc2-compliance-enterprise-security-guide

[8] Augment Code — "Enterprise Feature Gaps That Block Adoption" — https://www.augmentcode.com/guides/ai-coding-tools-enterprise-feature-gaps-that-block-adoption

[9] Kusari — "AI Coding Assistants in 2026: 4× Faster, 10× Riskier" — https://www.kusari.dev/blog/ai-coding-assistants-in-2026-4x-faster-10x-riskier-the-hidden-security-cost

[10] SQ Magazine — "AI Coding Security Vulnerability Statistics 2026" — https://sqmagazine.co.uk/ai-coding-security-vulnerability-statistics/

[11] Checkmarx — "2025 CISO Guide to Securing AI-Generated Code" — https://checkmarx.com/blog/ai-is-writing-your-code-whos-keeping-it-secure/

[12] Black Duck — "AI Coding Assistant Risks and Benefits: 2025 DevSecOps Security Guide" — https://www.blackduck.com/blog/ai-coding-assistant-security-risks-benefits-devsecops-2025.html

[13] Coalition for Secure AI — "Addressing What's Next in Securing Enterprise AI" — https://www.coalitionforsecureai.org/addressing-whats-next-in-securing-enterprise-ai/

[14] Cycode — "Top AI Security Vulnerabilities to Watch out for in 2026" — https://cycode.com/blog/ai-security-vulnerabilities/

[15] Vectra AI — "Prompt Injection: Types, Real-World CVEs, and Enterprise Defenses" — https://www.vectra.ai/topics/prompt-injection

[16] Coworker AI — "Enterprise AI Platforms with SOC 2 Compliance" — https://coworker.ai/blog/enterprise-ai-soc2-compliance

[17] Tenable — "Security for AI: A Guide to Managing the Risks of Vibe Coding" — https://www.tenable.com/blog/security-for-ai-guide-managing-vibe-coding-risks-ai-in-software-development

[18] OWASP Gen AI Security Project — "LLM01:2025 Prompt Injection" — https://genai.owasp.org/llmrisk/llm01-prompt-injection/

[19] Botmonster Tech — "AI Coding Agents Are Insider Threats: Prompt Injection, MCP Exploits" — https://botmonster.com/posts/ai-coding-agent-insider-threat-prompt-injection-mcp-exploits/