Как использовать облачные AI модели внутри контура компании и не получить по шее от ИБ?

Или пример того, что будет, если роль пакетного менеджера доверить AI.

Короткий ответ — используйте шаблоны.

Шаблон — это общий каркас, на основе которого можно разрабатывать другие проекты с уникальной бизнес логикой ^[1].   

Шаблон — это не обязательно Open Source. Проекты вполне могут быть размещены в отдельном закрытом репозитории компании. Но! По умолчанию руководство и сотрудники компании должны помнить и понимать, что данный шаблон разрабатывается с применением облачных моделей, соответственно, быть готовы к копированию, утечке или публикации.

В итоге получается разделение:

• с шаблонами работаем в облаке

• для внутренних проектов применяем корпоративные инструменты

Вроде всё просто.

Единственный сложный момент — как развивать шаблон в долгосрочной перспективе?

Что, если шаблон невозможно упаковать в библиотеку, как в таком случае переносить изменения?

Доверить роль пакетного менеджера AI.

Пример из личного опыта ^[2].

pytest-hardware-template ^[3] — шаблон для тестирования сетевого, лабораторного, встраиваемого и другого физического оборудования.

• Копируете проект.

• Адаптируете под собственные нужды с помощью скилла “adapt-internal-infrastructure” ^[4].

• Когда появляется нужное вам обновление, переносим коммит или отдельный функционал шаблона с помощью скилла “adapt-template-change” ^[5].

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

Если ранее вы уже внесли изменения в проект, в случае конфликта ^[6], агент предложит варианты, как адаптировать изменения.

Чем больше модель и меньше объем изменений, тем лучше.

Чем более отчетливо, но недвусмысленно и коротко сформулированы правила архитектуры в AGENTS.md ^[7], тем меньше вопросов ОТ агента и К агенту возникнет в будущем.

Останется только соблюдать данные правила архитектуры самому разработчику :)

Кстати, про архитектуру.

Проект pytest-hardware-template изначально задумывался НЕ как библиотека, а именно как универсальный шаблон.

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

Как минимум, поможет сохранить токены и время. 

Поэтому для разработчиков шаблона и проектов, созданных на его основе, в документации добавлено специальное решение об архитектуре и возможной публикации в виде библиотеки ^[8]. 

Да, да, да…

Наконец-то!

Пора задать тот самый вопрос.

“Алексей, новый проект, шаблоны, звучит модно и современно. Но что делать с легаси?”

Проводить аудит проектов.

Где есть смысл и возможность — выделять части для работы с облачными моделями.

Где нет либо смысла, либо возможности — подумать еще раз.

Да, это нелегко. 

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

Пример из личного опыта.

yaml-test-params ^[9] — библиотека для динамической генерации тестовых параметров из файлов конфигурации YAML.

Проект изначально был небольшим вспомогательным модулем, примерно на 200-300 строк кода. Процедура согласования заняла месяц. В итоге получилась библиотека.

Стоит ли игра свеч?

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

Хорошо, когда знаешь, что спросить.

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

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

Возможно, даже что-то переписать с нуля.