AI-кодинг в команде: одностраничная policy, которую реально читают

Шаблон внутренней политики для engineering-команд — approved tools, sensitive paths, review rules, exception process, ownership_

Зачем это вообще нужно

Ваша команда уже использует Cursor, GitHub Copilot, Claude Code или что-то похожее. Вопрос не в том, разрешить или нет — вопрос в том, есть ли у вас контроль над тем, что происходит.

В 2024 году разработчик Samsung вставил проприетарный код в ChatGPT для отладки [4]. Код стал частью обучающих данных OpenAI. Samsung не смогла ничего отозвать. Это не исключение — это норма для команд, у которых нет политики.

С другой стороны, бесконечные запреты не работают. По данным опроса Anagram 2025, 58% сотрудников вставляли чувствительные данные в LLM даже в компаниях, где этого явно не разрешали [5]. Там просто не было чёткого определения, что «чувствительные данные» означает на практике.

Хорошая policy решает конкретную задачу: дать разработчикам понятные правила, а компании — аудируемый контроль. Документ ниже намеренно умещается на одной странице. Разделы с пометкой [заполнить] — ваши точки кастомизации.

Шаблон: AI Coding Policy v1.0

Документ: AI Coding Policy
Версия: 1.0
Дата: [дата]
Владелец: [Engineering Manager / Head of Security]
Следующий пересмотр: [через 6 месяцев]
Применяется к: все инженеры, доступ к production кодовой базе

1. Approved Tools

Список инструментов, разрешённых для использования в рабочих задачах. Инструменты за пределами списка требуют отдельного одобрения по процессу исключений (раздел 5).

Approved (enterprise/team план):

• [Инструмент 1] — [план/tier] — [владелец лицензии в компании]
• [Инструмент 2] — [план/tier] — [владелец лицензии в компании]

Запрещены для рабочего кода:

• Бесплатные consumer-тарифы любых AI-инструментов (ChatGPT Free, личные аккаунты Copilot и т.д.) — входные данные могут использоваться для дообучения модели [4]
• Любые инструменты без DPA (Data Processing Agreement) с компанией

Правило для новых инструментов: запрос через [ссылка на форму / тикет-систему], срок рассмотрения — [N] рабочих дней. Оценивается: data handling policy вендора, наличие zero-retention гарантий, соответствие классификации данных (раздел 2).

Примечание по enterprise vs consumer: enterprise-планы Copilot и ChatGPT Team/Enterprise включают договорные обязательства о неиспользовании данных для обучения — проверяйте конкретный договор [4].

2. Sensitive Paths — что никогда не передаётся в AI

Следующие файлы и директории исключены из контекста AI-инструментов на уровне конфигурации:

# Базовые паттерны исключений (добавить в настройки каждого инструмента)
.env*
*.key
*.pem
*.p12
/secrets/
/credentials/
config/secrets.*
database-passwords.*
auth-config.*
**/migrations/sensitive_*
internal-config.yaml

Классификация данных для AI:

1. Public — открытый код, документация, публичные API → AI разрешён без ограничений
2. Internal — стандартная бизнес-логика, internal tools, нечувствительный код → AI разрешён только через enterprise-план с DPA
3. Confidential — проприетарные алгоритмы, client-specific реализации → требуется zero-retention гарантия от вендора; согласовывается отдельно
4. Restricted — secrets, credentials, PII, платёжные данные, данные аутентификации → никогда не передавать в external AI [6]

Технические меры:

• Конфигурация Content Exclusion в GitHub Copilot настраивается на уровне организации (Settings → Copilot → Content exclusion) — .copilotignore не поддерживается [6]
• Claude Code: deny rules в ~/.claude/settings.json [7]
• Pre-commit hooks с secret scanning (git-secrets, Gitleaks, TruffleHog) для блокировки коммитов с API-ключами и паролями [2]
• Secret scanning в CI/CD

Если инструмент не поддерживает path-level deny rules — компенсируйте через сегрегацию репозиториев и environment isolation [7].

3. Что AI делает, а что — нет

Разрешено без дополнительного review:

• Boilerplate-код, утилиты, helper functions
• Документация, README, комментарии к коду
• Генерация тестов (кроме тестов для security-critical paths)
• CRUD-операции, UI-компоненты, data transformations
• Рефакторинг и переименование в пределах non-sensitive модулей

Разрешено, но требует обязательного security review (раздел 4):

• Изменения в бизнес-логике
• API-интеграции и endpoint definitions
• Работа с зависимостями: добавление пакетов, bump major versions, изменение lock-файлов
• Конфиги: Terraform, Helm, CI/CD workflows, IAM-правила

Запрещено для AI-генерации (только human implementation):

• Authentication flows, authorization frameworks
• Cryptographic implementations
• Payment processing
• Secrets management systems
• Security controls и access policies

Обоснование: <br>Apiiro зафиксировала в AI-генерированном коде 322% больше путей для privilege escalation и 153% больше архитектурных дефектов по сравнению с человеческим [2]. Именно в security-critical зонах AI-ошибки наиболее дорогостоящи.

4. Review Rules — правила проверки AI-кода

Принцип: AI-генерированный diff читается как код от нового контрактора — независимо от автора и инструмента.

Обязательный review для AI-кода:

• Любой PR, затрагивающий Confidential-пути (классификация из раздела 2)
• Любые изменения зависимостей (новые пакеты, bump версий, транзитивные зависимости)
• Изменения в CI/CD, deployment scripts, IAM
• Все изменения в модулях из запрещённого списка раздела 3

Reviewer checklist для AI-PR:

1. Нет ли hardcoded secrets, API-ключей, паролей?
2. Нет ли новых зависимостей? Если есть — проверить в advisory (npm audit, pip-audit, Dependabot)
3. Нет ли hallucinated пакетов? — Slopsquatting: коммерческие модели галлюцинируют пакеты в ~5% случаев, open-source модели — до 22% [6]
4. Соответствует ли код OWASP Top 10 в части input validation, access control, error handling? [8]
5. Не логирует ли код PII или sensitive data?
6. Если есть TODO/placeholder — помечены ли для security review перед деплоем? [8]
7. Были ли проверены все входные данные от пользователя перед передачей в LLM-контекст (защита от prompt injection)?

Автоматизация:

• SAST на changed functions (не весь репозиторий) — повышает precision на 12%, recall на 5,6% [3]
• SCA-сканирование новых зависимостей до merge
• Secret detection pre-commit + в CI

HighVibe — дополнительный слой контроля, который анализирует конкретный diff и связанный контекст (зависимости, конфиги, CI/CD-файлы) до merge. Даёт короткий сигнал: можно ли безопасно принять это изменение сейчас. Не заменяет SAST/SCA/SBOM, но закрывает зазор между ними и реальным ревью PR. highvibe.dev

5. Exception Process — как получить исключение

Когда нужно исключение:

• Использование инструмента не из approved list
• Работа с Confidential-данными в AI без zero-retention гарантии
• AI-генерация кода из запрещённого списка раздела 3

Процесс:

1. Подать запрос через [тикет-система / форма], указав: инструмент, сценарий использования, классификацию данных, предлагаемые компенсирующие меры
2. Рассматривает: [Engineering Manager] + [Security/AppSec]
3. Срок рассмотрения: [3–5] рабочих дней
4. Временные исключения выдаются на срок не более [30] дней с обязательным пересмотром
5. Решения документируются в [место хранения решений]

Компенсирующие меры, которые увеличивают вероятность одобрения:

• Изоляция среды (sandbox, отдельный репозиторий)
• Дополнительный mandatory review от AppSec
• Аудит-лог всех промптов и выходных данных

6. Ownership — кто за что отвечает

Расписание пересмотра:

• Квартальный review approved tools list
• Полугодовой пересмотр всего документа
• Внеплановый пересмотр при: смене вендора, инциденте, изменении регуляторных требований

Куда сообщать об инцидентах или вопросах: [email / канал в Slack / тикет-тип]

7. Базовые обязательства каждого инженера

Принимая этот документ, инженер подтверждает:

• Использую только approved инструменты для рабочего кода
• Не передаю в AI: secrets, credentials, PII, данные клиентов, restricted-данные
• Читаю AI-generated diff перед merge — не принимаю «выглядит нормально» как достаточную проверку
• Проверяю новые зависимости, предложенные AI, перед добавлением
• При сомнениях — спрашиваю, а не угадываю

Подпись/acknowledgment: [механизм подтверждения — форма, тикет, onboarding-чеклист]

Как внедрять: три шага без боли

Типичная ошибка — публикация policy как PDF и ожидание, что команда её прочитает. По исследованиям, gap между «есть политика» и «политика соблюдается» — главное место, где живёт compliance-риск [1].

Первый шаг: сделайте approved инструменты доступными. Если вы требуете enterprise-план, но не выдали лицензии — policy мертва на старте [9].

Второй шаг: объясните «почему», а не только «что». Команды, которые понимают причины ограничений, принимают лучшие решения в неоднозначных ситуациях [9]. Один 30-минутный sync с разбором реальных случаев (Samsung, Copilot-уязвимость в октябре 2025 с 9.6 severity [2]) работает лучше любого обязательного тренинга.

Третий шаг: встройте контроль в процесс, а не в головы. Pre-commit hooks, SAST на changed functions, автоматическое SCA на новые зависимости — это не бюрократия, это снятие нагрузки с ревьюера. Когда автоматика блокирует очевидные проблемы, человек читает действительно важное [3].

И последнее: policy, написанная в 2024 году, не покрывает EU AI Act в редакции 2025 года [1]. Расписание пересмотра в разделе 6 — не формальность. Регуляторный landscape меняется быстрее, чем хотелось бы.

Источники

[1] PolicyGuard AI Blog — "AI Acceptable Use Policy Template: A Complete Guide for 2026" — https://blog.getpolicyguard.com/ai-acceptable-use-policy-template/

[2] SoftwareSeni — "AI-Generated Code Security Risks - Why Vulnerabilities Increase 2.74x and How to Prevent Them" — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[3] Knostic — "How to Secure AI Coding Assistants and Protect Your Codebase" — https://www.knostic.ai/blog/ai-coding-assistant-security

[4] Adelia Risk — "AI Acceptable Use Policy Template" — https://adeliarisk.com/ai-acceptable-use-policy-template/

[5] Knostic — "Governance for your AI Coding Assistant" — https://www.knostic.ai/blog/ai-coding-assistant-governance

[6] Digital Applied — "AI Coding Assistants Security: Best Practices Guide" — https://www.digitalapplied.com/blog/ai-coding-assistants-security-best-practices

[7] Brian Gershon — "Securing AI Coding Tools: Permission Controls and Credential Protection for Engineering Teams" — https://www.briangershon.com/blog/securing-ai-coding-tools/

[8] OpenSSF Best Practices Working Group — "Security-Focused Guide for AI Code Assistant Instructions" — https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions.html

[9] centrexIT — "AI Acceptable Use Policy Template for Business" — https://centrexit.com/blog/ai-acceptable-use-policy-template-business/

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

[11] Augment Code — "How Can Developers Protect Code Privacy When Using AI Assistants?" — https://www.augmentcode.com/guides/how-to-protect-code-privacy-when-using-ai-assistants

[12] blueheadline / Secure AI Coding Assistants — "How To Secure AI Coding Assistants In Real Software Teams" — https://blueheadline.com/cybersecurity/secure-ai-coding-assistants/

[13] OpenSSF — "New OpenSSF Guidance on AI Code Assistant Instructions" — https://openssf.org/blog/2025/09/16/new-openssf-guidance-on-ai-code-assistant-instructions/

[14] NIST — "AI Risk Management Framework (AI RMF 1.0)" — https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf

[15] NIST — "NIST AI 600-1: Generative AI Profile" — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf