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

Почему команды игнорируют политики по ИИ

Команды обычно не игнорируют политику потому, что ненавидят правила. Они игнорируют её, потому что политика замедляет работу.

Разработчик исправляет баг и хочет понять, можно ли вставить лог ошибки в одобренный инструмент. Вместо понятного ответа он получает две страницы расплывчатых формулировок. Слова вроде чувствительное, внутреннее и ограниченное использование звучат осторожно, но оставляют слишком много пространства для споров. Люди прекращают читать и начинают догадываться.

Длина делает всё ещё хуже. Инженеры работают быстро. Если политика требует десяти минут, чтобы её расшифровать, люди спросят коллегу, скопируют поведение команды или вовсе пропустят документ. Так у одной команды появляются пять разных привычек и никакого стандарта.

Путаница с инструментами — ещё одна распространённая проблема. Многие политики разрешают ИИ, но не перечисляют, какие инструменты одобрены, какие заблокированы и какие данные можно вставлять в каждый из них. Тогда один человек пользуется публичным чат-ботом для кода, другой — корпоративным планом, и оба думают, что действовали по правилам.

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

Копирование текста от поставщика не помогает. Юридические формулировки из документации провайдера редко соответствуют тому, как продуктовая команда реально выпускает софт. Стартапу нужны прямые ответы на реальные вопросы: можно ли вставлять стектрейсы в инструмент, можно ли использовать ИИ для тестового кода, помогает ли он при миграциях в продакшне, кто подписывает код, написанный ИИ, и какие данные всегда вне доступа?

Хорошие политики читаются как командные привычки, а не как юридическое домашнее задание. Человек должен просканировать страницу, найти свой кейс и понять, что делать, меньше чем за минуту.

Начните с узкого охвата

Первая версия должна сознательно оставаться узкой. Политике проще работать, когда она покрывает места, где люди касаются дела каждый день, вместо попытки решить сразу все редкие кейсы.

Начните с задач, где люди уже копируют, вставляют, суммируют и пишут черновики. Для большинства продуктовых команд это означает исходный код и pull request’ы, внутренние документы и спецификации, тикеты и баг-репорты, заметки поддержки и командный чат. Это уже покрывает большую часть повседневного использования ИИ, не втягивая HR-файлы, финансовые записи или юридические контракты.

Первая страница также должна указывать, к кому относится правило. Держите формулировку простой: сотрудники, подрядчики, стажёры и вендоры, которые имеют доступ к системам компании или данным клиентов. Если кто-то может вставить стектрейс, письмо клиента или заметку дорожной карты в инструмент ИИ, правило к нему применяется.

Будьте конкретны насчёт систем. Не пишите "внутренние инструменты" и не надейтесь, что все поймут одинаково. Назовите реальные места, где живёт чувствительный материал: репозиторий кода, система тикетов, воркспейс для документов, чат, файловое хранилище, CRM, аналитическое хранилище и продакшн-база данных. Люди реже совершают ошибки, когда могут сопоставить правило с открытым у них экраном.

Не решайте все редкие случаи сразу. Редкие кейсы раздувают документ, и почти никто потом их не помнит. Если одна команда работает с регулируемыми записями или документами по слияниям, добавьте краткую заметку для этой группы, когда она действительно понадобится.

Одностраничная политика может казаться слишком короткой. Это обычно хороший знак. Инженеры прочитают одну страницу. Они не прочитают шесть страниц расплывчатых предупреждений. Если предложение никак не меняет поведение в коде, документах, тикетах или чате, вырежьте его.

Используйте простые классы данных

Трёх–четырёх меток достаточно. Если вы создадите семь — люди перестанут проверять и начнут догадываться.

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

Простой модель обычно работает:

• Public: всё, что можно открыто публиковать — маркетинговые тексты, публичная документация, фрагменты с открытым исходным кодом или пример кода с фейковыми данными.
• Internal: обычные внутренние материалы, не публичные, но не раскрывающие клиентов или секреты — заметки по архитектуре, бэклог, шаблоны кода без реальных учётных данных или пользовательских данных.
• Confidential: реальные бизнес-данные — код из приватных репозиториев, логи с данными клиентов, инцидентные заметки или тикеты поддержки с именами, email и историей аккаунта.
• Regulated: данные с юридическими или контрактными ограничениями — платежные данные, медицинские записи, гос. идентификаторы, приватные ключи и клиентские данные, защищённые контрактом.

Примеры важнее определений. Стектрейс с фейковыми значениями может быть internal. Тот же стектрейс становится confidential, если в нём есть email клиента, IP или токен. Тикет поддержки про баг с логином остаётся internal, если там тестовые данные, и немедленно поднимается в более высокий класс, когда появляется реальный человек или регулируемая запись.

Держите метки согласованными в ревью кода, шаблонах тикетов, правилах логирования и рабочих процессах поддержки. Люди могут выучить одну систему один раз. Четыре слегка разные версии они будут игнорировать.

Перечислите одобренные инструменты и ограничения

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

Не сваливайте все AI-продукты в одну кучу. Ассистент в IDE, браузерный чат и API в бэкенде несут разные риски. Назовите точные инструменты, которые вы разрешаете, включая плагины и API. "AI coding tools" — слишком размыто.

Дайте каждому инструменту чёткие границы

Для каждого одобренного инструмента перечислите одни и те же базовые факты: точное название продукта и план, где его можно использовать, какой класс данных он может обрабатывать, сохраняет ли он подсказки или логи, и нужно ли использовать корпоративный аккаунт или ключ API компании.

Последний пункт важнее, чем кажется. Личные аккаунты не должны использоваться для работы. Как только кто-то вставляет данные клиента в личный чат-бот, компания теряет контроль над доступом, отыгнорингом, логированием и хранением.

Будьте просты насчёт ограничений. Вы можете разрешить один ассистент для подсказок в IDE в приватных репозиториях, другой — для написания документов с internal-заметками, и блокировать оба от обработки клиентских секретов или регулируемых данных. Большинство инженеров будут следовать правилам, когда границы соответствуют реальной работе и сформулированы ясно.

Небольшой пример помогает больше, чем общая строка политики. Можно разрешить один кодовый ассистент в IDE для внутренних репозиториев, позволить один API для генерации тестов в CI и запретить браузерные чат-инструменты для всего, кроме публичных кусочков кода. Это гораздо проще, чем широкое заявление про "одобренные AI-инструменты".

Один человек должен владеть списком. Назначьте engineering manager, staff engineer или CTO, который будет пересматривать его ежемесячно. У поставщиков меняются настройки ретеншна, появляются плагины, и безопасные настройки не остаются такими навсегда.

Установите обязанность по ревью для работы, сделанной ИИ

Если инструмент написал часть кода, за результат отвечает человек. Поместите это правило ближе к началу.

Ни одно изменение, созданное ИИ, не должно попадать в продакшн без человеческого ревью, и ни один pull request не должен сливаться потому, что код "выглядит нормально". Держите правило простым: каждая правка с помощью ИИ требует ревью перед мёрджем, а для изменений с высоким риском нужен названный утверждающий перед релизом.

Ревьюеры должны знать, что проверять. В большинстве команд это значит искать риски безопасности: секреты, аутентификацию, права доступа и небезопасные зависимости; покрытие тестами, соответствующее риску; вопросы лицензирования, если изменение добавляет пакеты, фрагменты кода, модели или сгенерированные артефакты; и базовую корректность, особенно по граничным случаям и тихим ошибкам.

Отмечайте AI-assisted PR простым способом. Префикс в названии вроде [AI-assisted] или одна галочка в шаблоне PR достаточно. Не превращайте это в бюрократию. Ревьюерам нужен явный сигнал, чтобы они замедлились и внимательнее посмотрели на изменения.

Нужно прямо запретить формальные "штампы" ревью. Скажите, что ревьюеры должны читать код, запускать проверки, соответствующие риску, и оставить хотя бы один комментарий, показывающий, что они проверили. Это звучит строго, но предотвращает обычный режим, когда все думают, что кто-то другой посмотрел внимательно.

Для изменений высокого риска требуется более сильное утверждение. Если код касается платежей, данных клиентов, контроля доступа, инфраструктуры, юридических условий или миграций в продакшне, укажите роль, которая утверждает такие изменения. Например: engineering lead утверждает продуктовую логику, security owner — аутентификацию и обработку данных, CTO или head of engineering — инфраструктурные изменения в продакшне.

Это не требует большого процесса. Стартап может написать в три строки: помечать AI-assisted PR, требовать человеческое ревью перед мёрджем и требовать названного утверждения для рискованных изменений.

Создайте первую версию шаг за шагом

Первая политика должна помещаться на одной странице. Пишите её как внутренний README: простые слова, короткие секции, несколько примеров.

Начните с цели в двух предложениях. Например: "Мы используем инструменты ИИ, чтобы ускорять рутинную работу, не подвергая риску чувствительные данные и не пропуская человеческое ревью. Эта политика говорит, какие инструменты мы одобряем, какие данные можно передавать и какую работу человек должен проверить перед выпуском."

Затем добавьте небольшую таблицу для классов данных:

После этого перечислите одобренные инструменты и их ограничения. Назовите инструмент, укажите, кто может его использовать и что нельзя туда вставлять. Короткая строка вроде "Использовать только корпоративные аккаунты" предотвратит многие плохие привычки.

Правила ревью оформите в том же простом стиле. Если ИИ написал код, ревьюер читает diff, запускает тесты и проверяет на небезопасные вызовы, странную логику и скопированный код. Если ИИ написал документацию, владелец документа проверит факты, команды и примеры перед публикацией.

Не переводите вопросы в почтовый ящик или расплывчатое "инженерная команда". Назначьте одного человека: staff engineer, tech lead или engineering manager. Людям нужно знать, к кому обратиться по неочевидным случаям в одном сообщении.

Вам не нужна сложная кампания по внедрению. Опубликуйте драфт там, где команда уже работает, дайте неделю на комментарии по непонятным формулировкам и упущенным кейсам, исправьте фразы, которые ставят людей в тупик, решите споры письменно и опубликуйте версию 1. Потом обновляйте её после реального использования.

Политика, которую люди запоминают, лучше идеальной политики, которую никто не открывает.

Простой пример от продуктовой команды

Тест чек-аута начинает падать после небольшого рефактора. Разработчик хочет быстрое второе мнение, но не вставляет реальные заказы, имена или платежные данные в подсказку.

Вместо этого он использует фиктивные данные: фейковый ID заказа, примерные цены и короткий стектрейс. Запрашивает у ассистента причину падения теста после изменения налогов и делает это через корпоративный аккаунт, одобренный для этой работы.

Ассистент указывает на вероятную причину: теперь одно значение округляется раньше, чем ожидал тест. Это не делает ответ верным автоматически. Разработчик проверяет код, обновляет тестовый фикстур и прогоняет весь тестовый набор.

Изменение всё равно требует человеческого ревью. Перед мёрджем другой инженер читает diff построчно и проверяет четыре вещи: использовались только фиктивные данные, аккаунт и инструмент соответствовали правилам команды, изменение исправляет реальную ошибку и в предложенный патч не было внесено лишней логики.

Это ревью важнее самой подсказки. Правила ревью кода с участием ИИ должны явно говорить, что ассистент может объяснять, черновать и предлагать, но человек решает, что попадёт в релиз.

После фикса команда сохраняет короткую запись кейса в политике. Не длинный отчёт — пара строк о том, что произошло, какие данные были безопасны, какой инструмент использовали и какое ревью требовалось.

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

Ошибки, которые делают политику бесполезной

Большинство слабых драфтов терпят неудачу по одной и той же причине: стараются снизить риск общими запретами. На бумаге это выглядит безопасно, но инженерам всё равно нужно помогать отлаживать, генерировать тесты и выполнять небольшие исследовательские задачи. Если правило говорит "никогда не используйте ИИ", люди перейдут на личные аккаунты и приватные вкладки в браузере. Тогда компания теряет ревью, логирование и контроль.

Плотное юридическое письмо вызывает ту же проблему. Если инженеру нужно читать три страницы, чтобы понять, можно ли вставлять стектрейс, он начнёт догадываться. Политика должна читаться как командное правило, а не как юридический спор.

Ещё одна ошибка — смешивать политику и инструкции по настройке. Классы данных для использования ИИ должны быть отдельны от шагов установки, советов по подсказкам или инструкций по IDE. Политика отвечает, что разрешено. Сопровождающие документы объясняют, как это делать.

Команды также забывают людей. Пишут правила для штатных инженеров и исключают подрядчиков, стажёров, саппорт и вендоров. Эти люди всё ещё могут работать с исходным кодом, тикетами, логами и данными клиентов. Если они вне политики, в ней остаётся дырка.

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

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

Если политика короткая, актуальная и ясно указывает обязанности по ревью, инженеры будут её использовать. Если она кажется пустой формальностью — её будут обходить.

Быстрая проверка перед публикацией

Хорошая политика должна прочитываться за пять минут. Если новому инженеру нужна встреча, чтобы её расшифровать, сократите документ. Уберите очевидные определения, вынесите редкие кейсы в отдельный раздел и держите реальные правила вверху.

Проверьте документ на человеке, который его не писал. Дайте ему пять минут, заберите документ и спросите, что он понял. Он должен суметь назвать, какие инструменты можно использовать, какие данные можно передавать и какую работу нужно проверять вручную.

Нечёткие формулировки вокруг данных клиентов — самая частая ошибка. Не говорите "будьте осторожны" или "избегайте чувствительных данных". Назовите классы данных, которые можно отправлять в одобренные инструменты, и те, которые нельзя. Если человек не может понять, разрешён ли тикет поддержки, дамп краша, скриншот или фрагмент кода с секретами, политика не готова.

Поток ревью требует той же ясности. Ревьюер должен быстро заметить работу, сделанную с помощью ИИ, и знать, что проверять. Это может быть простая пометка в PR, тег коммита или одна строка в шаблоне. Если ревьюерам приходится расследовать — они что‑то пропустят.

Короткий чеклист перед публикацией помогает. Новый инженер должен суметь простыми словами пересказать правила после одного прочтения. Люди должны знать, куда можно отправлять данные клиентов, а куда нельзя. Ревьюеры должны уметь безошибочно определить AI-assisted код. Менеджеры должны помнить одобренные инструменты. Команда должна легко находить текущую версию политики, а не копаться в истории чатов.

Ещё один полезный тест: попросите двух человек из разных команд прочитать документ самостоятельно. Если их ответы отличаются — продолжайте редактировать.

Что делать после развёртывания

Политика работает только когда она соответствует реальной работе. На первой командной встрече после запуска разберите два реальных запроса вместе. Возьмите один явно безопасный кейс, например черновик теста, и один ближе к грани — тикет с данными клиента.

Это упражнение быстро показывает, одинаково ли люди понимают классы данных и выявляет правила по инструментам, которые выглядели ясно на бумаге, но ломаются на практике.

В первый месяц обращайте внимание скорее на места трения, чем на показатели соответствия. Если люди задают один и тот же вопрос — политика требует переработки, а не ещё одного напоминания.

Простая схема работает: фиксируйте исключения, где метка данных была неясна, записывайте случаи, где ревью поймало ошибку ИИ, и превращайте повторяющиеся вопросы в короткие примеры.

Исключения заслуживают особого внимания. Если инженер использовал неразрешённый инструмент во время инцидента, не позволяйте этому случаю исчезнуть в чатах. Добавьте короткую заметку в политику или сопутствующий документ: что произошло, какие данные были задействованы и что команда должна сделать в следующий раз.

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

Через примерно месяц пересмотрите части, которые вызывали сомнения. Если люди спорят о словах вроде "чувствительное", замените их на термины, которые команда уже использует: логи продакшна, контракты, счета или приватные репозитории.

Держите политику короткой по мере изменения стека. Регулярно пересматривайте список одобренных AI-инструментов, удаляйте те, что не используются, и добавляйте ограничения для новых до того, как они разойдутся по команде. Короткий документ открывают. Длинный — игнорируют.

Некоторым командам полезен внешний просмотр перед тем, как правила начнут расходиться. В таком случае Oleg Sotnikov на oleg.is может проверить список инструментов, правила по данным и план внедрения как часть услуг Fractional CTO или консультации для стартапов. Этот второй взгляд наиболее полезен, когда команда меняет способ разработки, ревью и доставки ПО.

Если политика по‑прежнему умещается на одном экране и отвечает реальным вопросам — оставляйте её. Если она растёт каждый раз, когда кто-то ошибается, сократите текст и замените лишнее лучше примером.