Кто отвечает за код, который написал ИИ: регламент для агентств и команд разработки

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

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

Мы в Вебформате делаем автоматизацию на заказ: пишем код для чужих систем, ходим в продуктивные среды клиентов, держим их данные. Границы работы с ИИ на таких проектах нужно было описать документом - не потому, что что-то случилось, а потому, что без документа на вопрос клиента нечем ответить. Документ есть, его обезличенный образец выложен целиком - забрать можно в конце.

Ниже - что мы туда записали, на чём чуть не ошиблись и чего до сих пор не знаем.

Регламентов по ИИ в интернете много. Прежде чем писать свой, мы разобрали то, что уже лежит в выдаче.

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

Вторая половина - инженерные чек-листы. Как формулировать запрос, почему сначала план и только потом код, почему нельзя мержить непрочитанное. Всё по делу. Только по 152-ФЗ и по коммерческой тайне такой чек-лист не закрывает ровным счётом ничего.

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

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

Очевидный ход - слить их в один перечень требований. Мы его чуть не сделали и теперь считаем это главной развилкой документа.

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

Поэтому частей две:

Часть I защищает клиента и компанию. Часть II растит разработчика. Цена ошибки разная, поэтому и последствия разные.

Ссылка на ИИ ответственность не снимает. Отвечает тот, кто закоммитил. Фраза "так предложил ИИ" названа в документе прямо и там же объявлена недостаточной. Звучит грубовато, зато закрывает целый класс споров на ревью раз и навсегда.

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

Соответствие 152-ФЗ - свойство оператора, а не модели. Это место, где чаще всего пишут ерунду. Российский сервис сам по себе ничего не соблюдает: требования выполняет тот, кто поручил обработку. Поэтому в документе стоят условия передачи - поручение от клиента или согласие субъекта, серверы в России либо трансграничная передача по статье 12, запись в журнале обработки, - а не фраза "используем сервис, соответствующий 152-ФЗ".

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

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

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

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

Дальше в документе матрица: какие требования включаются на какой категории. У простой не требуется ничего, кроме обычного ревью. У критичной - согласование подхода с альтернативами до кода, письменный план проверки, проверка на копии данных клиента и ревью технического руководителя.

Первый шаг оказался самым спорным внутри команды. Смысл его в проверке понимания: если задачу не получается описать своими словами, она не понята - и передавать её понимание модели бессмысленно.

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

На ревью добавилось правило: проверяющий вправе спросить про любую строку и ожидать объяснения без обращения к модели. "Так предложил ИИ" ответом не считается - задачу возвращают на доработку.

В офисных регламентах такого раздела нет: они написаны про чат в браузере. Агент, который сам запускает команды и переписывает файлы, - другая история. Из цепочки между предложением модели и изменением в репозитории пропадает человек.

Четыре условия, при которых мы разрешаем автономный режим:

Последний пункт написан не из осторожности вообще, а потому что цена такой ошибки - это данные клиента, а не наш рабочий день.

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

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

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

Наказывать за то, что человек не научился работать с новым инструментом, бессмысленно: научится он от этого хуже, а скрывать начнёт лучше.

Образец - это наш рабочий документ, из которого убрано то, что нельзя отдавать как есть. Что именно:

Отдельно добавили выноску "как пользоваться образцом" и раздел о том, откуда этот документ взялся. Это образец, а не готовый приказ: перед введением его надо заполнить под себя и показать своему юристу. Трудовой договор, клиенты и поручения на обработку у всех разные.

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

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

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

Полный текст лежит на странице, оттуда же скачиваются Word и PDF:

Регламент работы с ИИ для разработчиков: готовый образец документа

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

Если у вас такой документ уже есть - интереснее всего, как вы решили вопрос с автономными агентами: пускаете ли их в продуктивные среды и под каким контролем. У нас это самое узкое место, и мы закрыли его запретом, а не процессом.