Сбер, Т-Банк, Яндекс и мировые гиганты: где в ИИ-разработке образовалась опасная дыра

Но если отойти от витрины и посмотреть на эту картину глазами человека, у которого в руках бюджет, ответственность по информационной безопасности и 152-ФЗ, окажется, что один слой почти везде остается недоговоренным. Это слой управления рисками и соответствием требованиям в мире, где рядом с разработчиками работают десятки цифровых исполнителей.

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

Первая: умное автодополнение. Инструменты вроде GitHub Copilot научили редактор подсказывать фрагменты кода так, словно рядом сидит коллега, который перечитал половину открытого кода в мире. Это ускорило набор текста, помогло начинающим разработчикам, но почти не затронуло архитектуру процессов. Главное: никак не ответило на вопросы информационной безопасности. Куда уходит код? Какие данные подмешиваются в контекст? Кто объяснит аудитору, что именно предложил ассистент?

Вторая: режим автономных заданий. Появились инструменты, которые умеют не просто дописать строку, а взять на себя небольшую задачу целиком: спланировать изменения, поправить несколько файлов, прогнать тесты, открыть запрос на слияние. GitHub Copilot Workspace идет именно в эту сторону: от «подсказчика» к среде, которая связывает задачу, план, изменения и итоговый запрос на слияние.

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

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

Российский трек: модель, данные и платформа

В России уже сложились три важные точки опоры.

Первая: AI-Disrupt PDLC (цикл разработки с учетом прорывных возможностей ИИ) от Сбера. Это попытка описать целевую модель, в которой искусственный интеллект встроен в жизненный цикл разработки от намерения и спецификаций до поставки и обратной связи. Ключевой сдвиг: центральным артефактом становится не код, а спецификация, то есть формализованное описание того, что система должна делать, для кого и при каких ограничениях. Для служб информационной безопасности и комплаенса это важная деталь. Там, где раньше аудитору приходилось «читать между строк» кода и тикетов, появляется связка «требование — реализация — тест — релиз». Такой контур куда легче сверить с требованиями 152-ФЗ, отраслевыми документами по ИБ и внутренними политиками доступа.

Вторая: AI4SDLC (применение ИИ в жизненном цикле разработки программного обеспечения) от Т-Банка. Это уже не концепт, а исследование и практический контур внедрения ИИ в разработку и эксплуатацию. В нем честно показано, что ИИ ускоряет не весь цикл, а отдельные его участки. Если архитектура процессов не меняется, узкое место просто переезжает: было тесно в написании кода, стало в ревью, тестировании, согласованиях и разборе инцидентов. С точки зрения рисков это означает, что компания легко может получить ситуацию, когда ИИ уже что-то делает в боевой среде, а управленческих механизмов контроля действий, ведения журналов и пересмотра решений нет.

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

Вместе это складывается в понятный треугольник. Сбер задает целевую модель. Т-Банк показывает, где она спотыкается об реальность процессов. Яндекс демонстрирует, как выглядит платформа полного цикла, в которую можно встраивать автоматизацию и ассистентов. Но даже в этом треугольнике есть слой, о котором говорят меньше, чем стоило бы.

Мировой трек: от ассистента к управляемым агентам

На глобальном рынке картина похожая, но насыщеннее.

GitHub с Copilot и Copilot Workspace пробует закрыть путь от постановки задачи до запроса на слияние в рамках одной среды. Google запускает асинхронного агента Jules: он подключается к репозиторию, поднимает изолированную среду исполнения, выполняет задачи и возвращает результат в виде изменений в коде. Amazon развивает ИИ-помощника для разработчиков и операторов в экосистеме своих облачных сервисов: помогает писать код, мигрировать приложения, сопровождать системы. Alibaba продвигает открытые кодовые модели Qwen3-Coder как инструмент для промышленного применения в задачах анализа крупных репозиториев и автоматизации разработки. Devin от компании Cognition позиционируется как первый автономный ИИ-инженер: под капотом изолированная среда исполнения, браузер, редактор и система планирования задач, что позволяет ему проходить путь от задачи до рабочего кода без пошагового сопровождения человека.

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

Где пробел: управление цифровой рабочей силой

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

Этот пробел хорошо виден, если задать несколько простых вопросов:

1. Кто формально отвечает за результат работы ИИ-агента: разработчик, технический руководитель, владелец продукта, директор по информационной безопасности?
2. Какие именно действия разрешены той или иной «цифровой роли», а какие должны блокироваться автоматически?
3. Как через год после релиза вы покажете аудитору или регулятору полный путь: «кто, когда, на каком основании поменял этот фрагмент системы»?
4. Как вы считаете стоимость работы ИИ: по токенам, по человеко-часам, по риску штрафа или простоя?

Пока ответы на эти вопросы не формализованы, компания имеет не цифровую рабочую силу, а набор разрозненных инструментов автоматизации. Это нормально на стадии экспериментов, но плохо сочетается с требованиями отраслевых стандартов, 152-ФЗ и внутренней политики информационной безопасности там, где речь идет о критичных системах и персональных данных.

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

Зачем нужен граф кода и цифровые сотрудники

Термин «цифровые сотрудники» в российской повестке появился не случайно. Он фиксирует важный сдвиг: исполнитель на основе ИИ рассматривается не как безымянная надстройка над человеком, а как элемент штатного расписания со всеми вытекающими. У него есть доменная роль (продукт, ревью, безопасность, сопровождение инфраструктуры, финансовый контроль), четко описанный набор допустимых действий, типовые сценарии, журнал операций и связь с измеримым экономическим эффектом.

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

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

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

Что имеет смысл сделать уже сейчас

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

1. Разобрать свой PDLC/SDLC на этапы и роли, понять, где реально горит: контекст, ревью, тесты, релизы, инциденты, соответствие требованиям.
2. Составить карту рисков по каждому этапу: от регуляторных (152-ФЗ, приказы по информационной безопасности, отраслевые требования) до денежных (стоимость простоев, пересдач, внешних аудитов).
3. Определить, какие задачи вы готовы доверить цифровым исполнителям и при каких условиях: с формальными критериями «что считается успешным выполнением» и «кто подписывается под результатом».
4. Посчитать трудозатраты и фонд оплаты труда на эти участки до и после пилота. Без этого любые разговоры про ИИ остаются в жанре «нам кажется, стало быстрее».

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