Как выстроить выпуск программ, созданных сотрудниками с ИИ

Рабочие инструменты без порядка поддержки

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

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

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

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

Какие риски остаются в AI-прототипах

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

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

Другие примеры подобных рисков разобраны в статье о программах, которые сотрудники пишут с ИИ.

Техническая ответственность до и после релиза

Я разделил задачи автора программы, технического ответственного и инфраструктурных специалистов. Сотрудник готовит доступную ему базовую часть проекта по регламенту. Технический ответственный проверяет код, выполняет необходимые доработки и отвечает за готовность продукта к выпуску. DevOps разворачивает уже подготовленный продукт через CI/CD в test/prod.

В компании не было специалиста, который мог бы принять на себя техническую сторону этих программ. Автор прототипа не обязательно умеет разрабатывать и сопровождать ПО, а DevOps и администраторы не должны отвечать за чужой прикладной код. Я убедил собственника нанять технического ответственного, который принимает проекты сотрудников, проводит ревью и готовит релизы.

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

Корпоративный репозиторий и требования к передаче проекта

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

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

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

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

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

Зачем оставили ревью специалистом

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

Как проект проходит подготовку и выпуск

После согласования с участниками процесс начали применять к проектам сотрудников. Он включает следующие шаги:

1. Сотрудник создаёт с ИИ инструмент для своей рабочей задачи.
2. Компания определяет приоритет проекта по ожидаемой прибыли.
3. Автор выполняет базовую подготовку по регламенту, прежде чем передать проект техническому ответственному. Большинство этих действий автор выполняет с теми же ИИ-инструментами, которыми сотрудник создал прототип.
4. Технический ответственный принимает проекты в порядке приоритета, проводит углублённое ревью, дорабатывает программу и готовит её к релизу.
5. Подготовленный проект через заявку в сервис-деске передают DevOps для выпуска через CI/CD в test/prod на инфраструктуре компании.

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

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

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