Governance AI-асистентів для кодування: шаблон політики для enterprise-команд

Розмова, яку зараз веде кожен VP Engineering

Зараз 2026 рік, і питання більше не "чи варто нам дозволяти AI-асистентів для кодування". Кожна серйозна інженерна організація вже їх має — офіційно чи неофіційно. Питання в тому, як керувати ними відповідально: які інструменти, у яких репозиторіях, з якою телеметрією, з якими запобіжниками та що робити, коли хтось випадково вставить PII клієнта у промпт.

Ця стаття — шаблон для такої розмови. Вона ґрунтується на політиках, які ми писали з клієнтами від Series B SaaS компаній до регульованих галузей. Вона охоплює Copilot, Cursor, Claude Code, Windsurf і все інше, що виявиться встановленим на чиємусь ноутбуці наступного вівторка. Ми не вдаватимемося до ілюзії, що існує одна правильна відповідь, але робоча має доволі послідовну форму.

Перші принципи

П'ять принципів, які мають бути фундаментом політики:

Ставтеся до AI-асистентів як до будь-якого іншого інструменту розробника — з security review, procurement та SSO.
Припускайте, що промпти залишають вашу мережу — бо так і є, якщо ви не налаштували приватний ендпоінт.
Згенерований код — це ваш код — модель не несе відповідальності, ви несете.
Ризик ліцензій реальний — GPL-код у пропозиціях можливий, малоймовірний, але можливий.
Opt-in командами, а не індивідуально — пілоти, потім ешелони, потім загальна доступність.

Ризики, просто і чітко

Перед політикою назвіть ризики. Кожен інженер має вміти їх перерахувати.

Ризик	Як це виглядає	Радіус ураження
Викрадення секретів	API-ключ у промпті потрапляє у лог	Високий
Розкриття PII	Дані клієнтів вставлені для дебагу	Високий (регуляторний)
Витік IP	Пропрієтарні алгоритми у context window	Високий (конкурентний)
Забруднення ліцензіями	Запропонований GPL-код змерджено у пропрієтарну базу	Середній
Supply chain	Запропонована назва пакета — typosquat	Середній
Якість / галюцинації	Впевнена нісенітниця потрапила в продакшн	Середній
Надмірна залежність	Джуніори перестають вчити основи	Довгостроковий
Телеметрія	Вендор зберігає натискання клавіш або сніпети коду	Середній (контрактний)

Хороший governance — це перетин контролів, що зменшують кожен з цих ризиків до прийнятного рівня, не роблячи інструмент непридатним.

Шаблон політики

Нижче — документ політики, який ви можете адаптувати. Розгляньте його як відправну точку.

1. Область

Ця політика застосовується до всього інженерного персоналу, підрядників та embedded-консультантів, які використовують AI-асистентів для кодування у зв'язку з кодом компанії. Вона охоплює IDE-плагіни (GitHub Copilot, Cursor, Windsurf, Zed AI), CLI-асистентів (Claude Code, Aider, OpenAI Codex CLI), чат-асистентів, що використовуються для коду (ChatGPT, Claude.ai) та будь-який інший інструмент, що надсилає вихідний код чи технічний контекст до сторонньої моделі.

2. Затверджені інструменти

Лише інструменти зі списку затверджених можуть використовуватися з кодом компанії. Список переглядається щокварталу і супроводжується командами platform та security.

Станом на цю версію:

GitHub Copilot Business або Enterprise — enterprise tenancy, SSO, увімкнений zero-retention.
Cursor Business — з кастомними OpenAI/Anthropic ендпоінтами та privacy mode.
Claude Code — з Anthropic business tier та дефолтною обробкою даних.
GitHub Copilot Chat (через той самий Business tenancy).

Персональні акаунти і безкоштовні тарифи не дозволені для будь-якого робочого використання. Інструменти, яких немає у списку, вимагають security review перед використанням.

3. Дозволені та заборонені контексти

AI-асистентів можна використовувати в репозиторіях, позначених ai: allowed або ai: limited у каталозі репозиторіїв. Їх не можна використовувати в репозиторіях, позначених ai: forbidden.

Дозволені контексти

Код застосунку (frontend, backend, сервіси).
Інфраструктурний код (Terraform, Helm, маніфести Kubernetes).
Внутрішній тулінг та скрипти.
Тестовий код та генерація тестових даних (лише синтетичні дані).

Заборонені контексти

Репозиторії, що містять експорти даних клієнтів.
Репозиторії з криптографічними реалізаціями, не схваленими security.
Репозиторії з ключами підпису, KMS bootstrap або root-of-trust матеріалами.
Будь-який репозиторій чи файл, що містить PII, PHI або регульовані дані.
Security research проти наших власних систем без письмового дозволу.

4. Гігієна промптів

Інженери не повинні вставляти у промпт будь-якого AI-асистента:

API-ключі, токени, паролі чи інші секрети.
Дані клієнтів, навіть часткові чи анонімізовані.
Personally identifiable information.
Непублічні фінансові дані чи прогнози.
Непубічний roadmap чи HR-інформацію.

Коли сумніваєтесь — редагуйте.

5. Review згенерованого коду

Увесь AI-згенерований чи AI-модифікований код проходить той самий процес review, що й людський: PR review, CI-перевірки та security scanning. Інженери відповідальні за код, який вони коммітять, незалежно від походження.

6. Гігієна ліцензій

Інженери не повинні свідомо приймати пропозиції, які відтворюють істотні частини зовнішнього вихідного коду. Де інструмент пропонує public-code фільтр (Copilot's duplication detection), він має бути увімкнений. Пропозиції, що виглядають як дослівний сторонній код, слід відхиляти і повідомляти про них.

7. Телеметрія

Телеметрія та налаштування retention вендорів налаштовуються централізовано, щоб мінімізувати експозицію:

Copilot: Organization policy з "Allow suggestions matching public code" встановленим у Block і вимкненим "Prompt and suggestion collection".
Cursor: Privacy mode примусово застосований через configuration management.
Claude Code: Дефолтна поведінка (без навчання на бізнес-даних) плюс явне керування claude-code-settings.

8. Інциденти

Про будь-який підозрюваний витік секрету, розкриття PII або занепокоєння щодо ліцензій, що стосуються AI-асистента, має бути повідомлено команді security протягом 24 годин. Застосовується стандартний incident response runbook.

9. Review та зміни

Ця політика переглядається кожні 6 місяців або при істотній зміні інструментарію чи регулювання.

Як зробити її такою, що виконується

Політика, яку ніхто не читає — це не політика. Виконання забезпечують три рівні: pre-commit hooks на ноутбуці розробника, CI-перевірки в кожному PR та OPA-правила у самому CI.

Pre-commit hook: блокувати секрети до того, як вони потраплять у git

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.0
    hooks:
      - id: gitleaks
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
      - id: detect-secrets
        args: ["--baseline", ".secrets.baseline"]
  - repo: local
    hooks:
      - id: block-ai-forbidden-paths
        name: block AI-forbidden paths
        entry: scripts/check-ai-allowed-paths.sh
        language: script
        pass_filenames: true

Невеликий скрипт, що відмовляє у коммітах, які торкаються заборонених шляхів:

#!/usr/bin/env bash
set -euo pipefail

FORBIDDEN=(
  "services/crypto/"
  "secrets/"
  "customer-exports/"
)

for file in "$@"; do
  for path in "${FORBIDDEN[@]}"; do
    if [[ "$file" == "$path"* ]]; then
      echo "refusing commit: $file is in an AI-forbidden path"
      exit 1
    fi
  done
done

CI-перевірка: виявити AI-згенерований код із сумнівним походженням

Ви не можете ідеально детектувати AI-авторський код, але можете помічати очевидні ознаки: підозрілі copyright-хедери, великі блоки без відповідної історії або нові залежності, яких не було в описі PR.

name: ai-governance

on:
  pull_request:

jobs:
  secret-scan:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  license-scan:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: fossas/fossa-action@v3
        with:
          api-key: ${{ secrets.FOSSA_API_KEY }}

  dependency-review:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: moderate
          deny-licenses: "GPL-3.0,AGPL-3.0"

OPA-політика: гейт на merge на основі каталогу репозиторіїв

Кожен репозиторій має запис у центральному каталозі з класифікацією. OPA перевіряє, що поточний репозиторій має дозвіл на використання AI-асистентів і що PR, які торкаються заборонених шляхів, не проскакують.

package ai.repo_policy

default allow_merge := false

allow_merge if {
  input.repo.ai_classification in {"allowed", "limited"}
  count(forbidden_changes) == 0
}

forbidden_changes contains path if {
  some change in input.changes
  path := change.path
  startswith(path, "services/crypto/")
}

forbidden_changes contains path if {
  some change in input.changes
  path := change.path
  contains(path, "customer-exports")
}

Стратегія розгортання

Примус — це останній крок. Перший — дати інструмент інженерам у руки, нічого не зламавши. Ми рекомендуємо трирівневе розгортання.

Tier 0: Пілот (4–6 тижнів)

Візьміть одну команду, 5–10 інженерів, на non-customer-facing сервіс. Дайте їм інструмент, політику і прямий канал до platform team. Виміряйте:

PR throughput
Defect rate
Time-to-merge
Якісний фідбек (чи було це нетто-позитивно?)

Ще без примусу. Лише спостереження.

Tier 1: Opt-in команди (6–8 тижнів)

Відкрите зарахування для команд, які opt in. Вимагайте підтвердження політики, вимагайте pre-commit hooks, вмикайте CI-гейти в їхніх репозиторіях. Розширюйте список затверджених інструментів на основі пілотного фідбеку.

Tier 2: Загальна доступність (Quarter 3)

Уся інженерія. Політика у handbook. CI-гейти примусові всюди. Центральний дашборд ліцензій інструментів та утилізації. Incident runbook оновлений для покриття AI-related інцидентів.

Як вимірювати, чи воно працює

Governance без вимірювання — це відчуття. Метрики, які ми відстежуємо на клієнтських проєктах:

Adoption rate — % інженерії з активними сидами.
Acceptance rate — для Copilot, частка прийнятих пропозицій.
Зафіксовані порушення політики — pre-commit і CI на місяць.
Security-інциденти, пов'язані з AI — в ідеалі нуль.
Developer satisfaction — через квартальне опитування.
DORA metrics до/після — чи покращився lead time?

Типові помилки

Речі, які ми бачили, як йдуть не так:

Політика написана юридичною мовою, ніхто не читає. Виправлення: одна сторінка, простою мовою.
Список затверджених інструментів надто обмежений. Інженери використовують персональні акаунти. Виправлення: будьте щедрими, але вимагайте SSO та privacy-налаштувань.
Примус лише на CI. Секрети вже в git-історії. Виправлення: pre-commit не обговорюється.
Немає плану rollback. Інструмент, розгорнутий широко, а потім визнаний непридатним, — це боляче. Виправлення: спершу пілот.
Ставитись до інструменту як до дива продуктивності. Нереалістичні очікування ROI ведуть до розчарування. Виправлення: вимірюйте чесно.

Наступні кроки

AI-асистенти для кодування тепер є частиною дефолтного набору розробника. Governance-фреймворк для них — це частина дефолтної security та engineering operations постави. Почніть з принципів, адаптуйте політику, встановіть hooks та розгортайте по ешелонах. Якщо хочете допомоги з написанням кастомної політики, пілотуванням з командою чи побудовою примусового пайплайну, напишіть нам.

у категорії

copilotcursoraipolicygovernance