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

Руководители Middle Office в электронной коммерции в последнее время задают мне один и тот же вопрос: бизнес-подразделения за неделю собирают три внутренних инструмента на базе ИИ, а в IT очередь на разработку расписана до следующего квартала. Где именно буксует процесс?

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

За этой фразой стоят два процесса, которые происходят одновременно.

Bolt.new — продукт StackBlitz, анонсированный в октябре 2024 года одним твитом без лишнего шума. За пять месяцев — $40 млн ARR. Sacra и Growth Unhinged фиксируют его как второй по скорости роста продукт в истории (после ChatGPT). По итогам фискального 2026 года CEO StackBlitz Эрик Саймонс сообщил в LinkedIn: Bolt.new используют три четверти компаний из Fortune 500, корпоративный ARR вырос в 10 раз год к году (официальный пост Эрика Саймонса, итоги фискального 2026 года). Lovable — команда из Стокгольма (основатель — Антон Осика). В ноябре 2025-го — раунд A на $200 млн при оценке $1.8 млрд, в конце декабря 2025-го — раунд B при оценке $6.6 млрд: за полгода оценка выросла почти в 4 раза (данные сходятся у Forbes, CNBC, Bloomberg, TechCrunch). В июне 2026 года ARR Lovable превысил $500 млн (репортаж Forbes, параллельно — TechCrunch от 2026-06-09). В тот же день Forbes со ссылкой на четыре источника сообщил, что компания ведёт новый раунд при оценке $12 млрд (примерно вдвое выше предыдущей). Инструменты этого класса сжимают путь «от идеи до работающего приложения» с нескольких месяцев и целой команды до одного человека и одного afternoon.

Но пока порог разработки рухнул, самые дорогие и самые узкие места в вашей компании — те, что реально тормозят процесс, — не сдвинулись ни на дюйм: оценка трансграничной передачи данных, 等保测评 (děnɡ bǎo cè pínɡ — аттестация защиты информационной безопасности по китайскому стандарту MLPS), алгоритмическое регулирование (регистрация алгоритмов рекомендации), согласование изменений (Change Advisory Board, CAB) и сверка с аудитом. Эти этапы почти не связаны с самим кодом, но каждый съедает недели. Генератор приложений выбил первую дверь — бизнес-подразделения теперь могут собирать приложения сами. Но вторая дверь — кто имеет право трогать производственные данные и кто может менять ядро транзакционной системы — не сдвинулась ни на миллиметр.

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

Реальный сценарий из нашей практики (электронная коммерция, данные обезличены): группа операторов по работе с блогерами в одном интернет-магазине мебели за два месяца самостоятельно собрала на Lovable 7 внутренних мини-инструментов: подбор блогеров, расчёт комиссий, отслеживание хитов, атрибуция возвратов. Техническую платформу никто не уведомил. В середине года при инвентаризации shadow IT выяснилось: 4 из этих инструментов читали широкие таблицы заказов с номерами телефонов и адресами доставки, а 2 выгружали данные в личные облачные хранилища. С середины 2025 года команды платформ в e-commerce при инвентаризации активов сталкиваются с этим повсеместно — это не единичный случай.

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

Сначала посмотрите на схему, чтобы увидеть масштаб проблемы.

Два порога: один рушится, другой стоит Высокий Низкий 2020 2024 2026 Высота порога Порог разработки (писать код) ИИ-генератор: один день Порог соответствия (экспорт данных / MLPS / регистрация алгоритма / CAB / сверка) Почти не сдвинулся Подверженность риску Разрыв между порогами = Люди, умеющие делать приложения Не обязательно вправе касаться данных Быстрая разработка ≠ быстрая поставка — неподвижная красная линия сверху и есть узкое место

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

1. Сначала расставим эти пять инструментов по своим местам

Многие смешивают эти инструменты в одну кучу и называют всё это «AI-программированием». Но на самом деле они обслуживают две совершенно разные аудитории. Пока вы не разделите их, любые дальнейшие выводы будут неверными.

Первая группа — «люди, которые умеют писать код». Им нужен более быстрый редактор: инструмент, который понимает контекст вашей кодовой базы, умеет вносить изменения в несколько файлов, автоматически запускать тесты и объяснять ошибки. Типичные представители — Cursor, Trae от ByteDance, Tongyi Lingma от Alibaba, GitHub Copilot. Их главное допущение — вы уже инженер, а инструмент просто берёт на себя рутину. Этой категории мы посвятили четвёртую часть серии, так что здесь останавливаться не будем.

Вторая группа — «люди, которые не умеют писать код». Вот о них эта статья. Речь пойдёт о генераторах приложений. Вы описываете на естественном языке, что хотите получить, — и получаете готовое работающее приложение: фронтенд, бэкенд, база данных, деплой — всё включено. Никаких предположений о том, что вы умеете программировать, не делается.

В этой статье мы разберём четыре генератора приложений, а из AI-IDE отдельно выделим Trae — потому что он задевает один критически важный для строго регулируемых отраслей момент.

Bolt.new (от StackBlitz). В октябре 2024 года продукт был тихо анонсирован через твит, после чего Sacra и Growth Unhinged зафиксировали его как второй по скорости роста продукт в истории (уступающий только ChatGPT): $1 млн ARR за первую неделю, $4 млн через месяц, около $20 млн через два месяца и $40 млн через пять. Зарегистрированных пользователей — примерно 5 млн (по публичным данным CEO StackBlitz). В основе лежит технология WebContainers, которая запускает полноценное окружение Node.js прямо в браузере: ИИ-агент может работать с файлами, ставить пакеты и поднимать сервер без какой-либо локальной настройки. К закрытию 2026 финансового года Bolt.new использовали три четверти компаний из списка Fortune 500, а корпоративный ARR вырос в 10 раз год к году (официальный пост Эрика Саймонса в LinkedIn). В январе 2025-го StackBlitz привлек раунд B на $105,5 млн при оценке около $700 млн (по данным Business Insider и других изданий). Типичный сценарий — быстро собрать небольшое приложение или лендинг, который сразу можно открыть и посмотреть.

Lovable (основана в Стокгольме Антоном Осикой; проект напрямую связан с open-source инициативой GPT Engineer). Позиционируется как решение «от одной фразы до полностью готового к продакшену приложения» — по сути, ближе к полноценным бизнес-приложениям полного цикла, чем Bolt. В ноябре 2025 года компания привлекла раунд A на $200 млн при оценке $1.8 млрд, а уже в конце декабря 2025-го — раунд B на $330 млн при оценке $6.6 млрд: за полгода оценка выросла почти в четыре раза. К июню 2026 года ARR достиг $500 млн (по данным Forbes от 05.06.2026, параллельно писали в TechCrunch). В тот же день Forbes со ссылкой на четыре осведомлённых источника сообщил, что компания ведёт переговоры о новом раунде с оценкой около $12 млрд (примерно удвоение; Forbes / Rashi Shrivastava). В числе корпоративных клиентов Lovable — Workday, Asana и NVIDIA (сводка ARR.club за 2026 год).

Vercel v0. Выпущен в октябре 2023 года, 3 февраля 2026 года официально переименован с v0.dev на v0.app — эволюционировал из генератора UI-компонентов в полноценный генератор full-stack приложений (sandbox runtime + интеграция с GitHub + поддержка баз данных Snowflake/AWS). По официальным данным Vercel на март 2026 года, сервисом пользуются более 6 миллионов разработчиков, а ежемесячная аудитория команд составляет около 80 тысяч (по оценкам аналитиков конкурентов, ARR — примерно $42 млн; сводка Taskade, март 2026).

Replit Agent 4. Выпущен 13 марта 2026 года — самое значимое обновление в истории Replit. Изменились сразу три вещи: ① Design Mode превратился в Infinite Design Canvas — теперь можно править код прямо в процессе проектирования; ② коллаборация перешла с модели fork-and-merge на «один проект, многопоточные задачи» — несколько sub-agent’ов работают параллельно, а отдельный sub-agent по разрешению конфликтов автоматически объединяет результаты. Официальные данные: Agent 4 автоматически разрешает 90% конфликтов слияния (по данным AlphaSignal, 2026; подтверждено в официальном changelog Replit за март 2026); ③ планирование и исполнение больше не последовательны — можно планировать и выполнять одновременно. В тот же период Replit привлек раунд D, оценка компании — почти $9 млрд (Atal Upadhyay, 2026; подтверждено TechCrunch/Bloomberg). Replit начинался как онлайн-среда разработки, поэтому коллаборация и хостинг у него в крови; Agent 4 сжал путь от «несколько человек собирают продукт» до скорости, близкой к индивидуальной разработке.

Общее у всех четырёх: стоимость создания приложения снижается с командо-месяцев до человеко-часов.

Trae заслуживает отдельного разбора, потому что для корпоративных клиентов в телекоме, финансах и e-commerce это конкретный вендорский риск. По форме Trae — это IDE (редактор кода), но по сути — среда разработки, жёстко привязанная к серверам ByteDance. Для предприятия это не «обычный редактор», а инструмент, который нужно проходить через процедуру допуска как канал передачи данных за пределы периметра. ByteDance выпустила Trae в январе 2025 года как прямой ответ Cursor: стратегия — бесплатно давать доступ к моделям уровня Claude и GPT-4o. За 12 месяцев — 6 млн зарегистрированных пользователей, 1,6 млн месячной аудитории, суммарно сгенерировано около 100 млрд строк кода (сводные данные OpenAI Tools Hub, май 2026). Но в июле 2025 года исследователь безопасности под псевдонимом segmentationf4u1t опубликовал проект telemetry_research, который доказал: даже если отключить телеметрию в настройках, Trae продолжает в фоновом режиме передавать данные на серверы ByteDance, включая mon-va.byteoversea.com — аппаратную информацию, версию ОС, постоянные идентификаторы устройства и машины, данные об активности в проектах. Одна телеметрическая посылка достигает 53 606 байт; примерно за 7 минут обычной работы фиксируется 500+ вызовов и около 26 МБ переданных данных (первичные данные GitHub segmentationf4u1t/trae_telemetry_research; освещение — The Register и Cybernews, 28 июля 2025).

Ответ ByteDance заслуживает отдельного упоминания. В обновлении Cybernews от 2026-08-01 говорится: официальное заявление ByteDance признаёт, что переключатель telemetry в настройках IDE управляет только телеметрией VS Code-фреймворка, а сбор данных другими инструментами Trae от этого переключателя не зависит — если говорить по-человечески: вы думали, что отключили, а на самом деле нет. Исследователи, напрямую связавшись с командой Trae, подтвердили, что отдельный Privacy Mode планируется к выпуску примерно в августе 2026 года. В то же время в феврале 2026 года Trae ввёл “token-based paywall”, нарушив обещание “forever free”, из-за чего многие разработчики, использующие его в продакшене, пересмотрели свои решения (сводка исследования OpenAI Tools Hub, май 2026).

Для индивидуального разработчика бесплатный Claude — это отличная возможность. Для вас как для лица, принимающего решения, это классическая проблема трансграничной передачи данных: ваши инженеры загружают корпоративный код, а возможно, и конфигурации, и интерфейсы, в инструмент, который пересылает данные на серверы ByteDance. В таких отраслях, как телеком и финансы, где действуют《Закон о безопасности данных》и《Закон о защите персональной информации》, уже сам этот шаг может стать триггером инцидента соответствия. Подробнее об этом — в четвёртом разделе.

II. Разработка переписана: от «написания кода» к «рецензированию, оркестрации и контролю качества»

Генераторы приложений чаще всего воспринимают неправильно — как будто «инженеры больше не нужны». Это неверное направление мысли.

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

Эти три вещи более дефицитны и более ценны, чем «написание кода». Людей, способных написать React-компонент, пруд пруди; тех, кто может оценить, можно ли AI-сгенерированному промо-приложению давать доступ к данным о заказах, не является ли его аутентификация фиктивной и не отправляет ли оно логи в зарубежный сервис, — единицы.

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

Какие приложения отдать генератору, какие — никогда Низкая сложность ←────────────→ Высокая сложность Чувствительность данных: низкая ↑ высокая ↓ Смело отдавайте генератору Лендинги, кампанийные страницы Внутренние дашборды без чувствительных данных (без входа, только чтение) Прототип / демо Требует: обезличенные данные + комплаенс-канал Можно попробовать, но инженеры забирают Внутренние операционные инструменты (заказы / склад) Рабочее место менеджера по клиентам B2B-бэкенд самообслуживания Требует: прототип от генератора, рефакторинг инженерами для прода Генератор строит, жёсткая governance ловит Фронтенд базы знаний службы поддержки Страницы запросов с персональными данными Внутренние порталы с логином (идентификация + уровни доступа) Требует: аутентификация, аудит, MLPS — ничего нельзя упустить Никогда не отдавать генератору Торговые системы / платежи / клиринг Риск-движок / антифрод Базовый учёт / регуляторная отчётность Требует: профессиональная инженерная команда, контроль end-to-end Критерий: ось x = логическая сложность, ось y = касается ли денег или персональных данных

Смысл этой схемы сводится к одной фразе: по горизонтали — насколько сложна логика приложения, по вертикали — касается ли оно денег и персональных данных. В правом нижнем углу (высокая сложность плюс высокая чувствительность) генератору приложений не место, каким бы умным он ни был. Посадочную страницу для промоакции можно доверить Lovable — без проблем; ваш платёжный шлюз — тоже доверить? Это лишь вопрос времени, когда случится беда.

Зафиксируйте эту красную линию — и тогда смотрите на то, что происходит в электронной коммерции.

Три. Настоящая боль электронной коммерции: теневые приложения добрались до данных заказов

Отойдём на шаг назад и посмотрим на цифру, которую Gartner опубликовал во второй половине 2025 года: к концу 2026 года 40% корпоративных приложений будут включать в себя узкоспециализированных ИИ-агентов, тогда как в 2025 году этот показатель не достигал и 5% (официальный прогноз Gartner, продублирован Process Excellence Network 27.08.2025). В паре с этим идёт ещё более показательная статистика: по данным Gartner, с Q1 2024 по Q2 2025 количество запросов от компаний по мультиагентным системам выросло на 1445% — это самая быстрорастущая тема в консалтинговом направлении Gartner по ИИ, без единого конкурента (сводные данные RAPIDCLAW / Hendricks.ai / Arion Research).

Переведём эти две группы цифр на язык электронной коммерции: 40% корпоративных приложений будут содержать AI-агентов, и в паре с ними — ещё одна цифра: рост числа консультационных запросов по мультиагентным системам для предприятий — +1445% (это динамика обращений в AI-консалтинг Gartner, а не показатель внедрений, но направление уже очевидно): AI-агенты перестали быть просто «помощниками в написании кода» — теперь несколько агентов работают совместно и выполняют целые бизнес-процессы. Когда AI-агенты начинают реально использоваться в корпоративных приложениях — работают с данными, выполняют операции, пишут логи, — генераторы приложений перестают быть «инструментом» и становятся «системой».

Исследовательский отчёт UpGuard за 2025 год («State of Shadow AI», освещался изданием Cybersecurity Dive) содержит две цифры, которые выглядят куда тревожнее, чем гартнеровские 40%: более 80% сотрудников используют на работе несогласованные ИИ-инструменты, и даже в самих командах безопасности так поступают почти 90%. И ещё один пункт: примерно половина сотрудников признаёт, что вставляла конфиденциальные корпоративные данные прямо в эти несогласованные инструменты. Mimecast даёт 51%, Teramind — 49%: цифры сопоставимые. Другая сторона от Gartner: 69% организаций подозревают или точно знают, что сотрудники пользуются запрещёнными ИИ-инструментами, и лишь у 37% есть регламент по использованию ИИ (со ссылкой на The Hacker News).

Переведём эти цифры на язык e-commerce: ваши операционщики, маркетологи и организаторы акций уже собирают себе приложения с помощью Bolt, Lovable, v0 и подобных инструментов. Конфигуратор правил промоакций, дашборд для отбора товаров у блогеров, мини-приложение для проверки остатков, инструмент для обработки заявок в поддержке. Они быстрые, удобные и решают реальные задачи. И они почти все в обход IT и data governance.

1П 2026: четыре цифры показывают срочность 5% Корпоративные приложения 2025 со встроенными ИИ-агентами 40% Прогноз 2026 Gartner 2025-08 +1445% Корпоративные запросы Мульти-агент 2024Q1→2025Q2 80%+ Сотрудники используют несогласованные ИИ-инструменты (UpGuard 2025) ~50% Сотрудники вставляют конфиденциальные данные в эти инструменты Корпоративные приложения полностью агентизируются + сотрудники используют ИИ тайно = теневые приложения будут только множиться Окно решения для руководителей: 3-6 месяцев Предупреждение Gartner: определите стратегию ИИ-агентов сейчас, иначе более быстрые конкуренты вас обойдут Данные — ориентировочные; методики различаются, направление едино

Реальный сценарий из нашей практики (электронная коммерция, данные обезличены): во второй половине 2025 года мы проводили инвентаризацию shadow IT у четырёх средних и крупных e-commerce компаний (масштаб middle-office — 50–200 человек), и ни у одной не оказалось пустого результата. Самый показательный случай — интернет-магазин товаров для дома: за два месяца команда блогеров-партнёров самостоятельно собрала 7 внутренних инструментов на Lovable, из них 4 работали с широкими таблицами заказов (с номерами телефонов и адресами доставки), а 2 выгружали данные в личные облачные хранилища. В день инвентаризации руководитель по безопасности сказал буквально следующее: «Мы тогда едва не остановили проверку — боялись, что результаты доложим, а их никто не сможет “переварить”».

Такую ситуацию можно назвать «теневой ИТ-инфраструктурой данных». Последние десять с лишним лет всех беспокоил shadow IT в виде SaaS, который бизнес-подразделения покупали самостоятельно (отдел продаж приобрёл CRM, маркетинг — инструмент для email-рассылок). Теперь же shadow IT — это приложения, которые бизнес-подразделения создают сами. Используется неутверждённый инструмент — и, что ещё хуже, он порождает новую систему, работающую с чувствительными данными, которой нет в реестре активов ИТ-отдела.

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

Это не закрыть. Те 80% от UpGuard уже показывают: запретами это не решается. Люди найдут самый удобный инструмент, чтобы сделать работу, — это человеческая природа, это KPI. Поэтому вопрос не в том, «как запретить бизнес-подразделениям пользоваться генераторами», а в том, «как дать им пользоваться безопасно». В четвёртом разделе — про compliance-барьеры, в пятом — про то, как выстроить канал.

4. Какие compliance-барьеры придётся пройти: это не тесты

Этот раздел — самый важный в статье, и самый лёгкий для ошибки.

Многие, кто пришёл из интернет-компаний, под словом «контроль» автоматически понимают автоматизированное тестирование в CI/CD: юнит-тесты, интеграционные, регрессионные — зелёная галочка, и можно выкатывать. Для техкоманд, которые гоняют большие распродажи в e-commerce, это привычная история.

Но в телекоме, финансах, регулируемом производстве и e-commerce «верификация» — это далеко не только тесты. Настоящие узкие места — это несколько этапов, которые почти не связаны с самим кодом, но каждый съедает по несколько недель. Описывать их как «тесты» — это предвзятость интернет-индустрии, которая вводит руководителей в заблуждение и заставляет недооценивать сроки поставки.

Разберём по порядку.

Оценка трансграничной передачи данных.[^1] Если ваше приложение использует зарубежные ИИ-сервисы (многие генеративные модели работают на инфраструктуре OpenAI, Anthropic) или инженеры применяют IDE вроде Trae, которые передают данные за пределы КНР, — при наличии в данных персональной информации или сведений, отнесённых к категории важных, вступают в силу требования Закона КНР о защите данных и Закона КНР о защите персональной информации. Прохождение полной процедуры оценки безопасности трансграничной передачи данных или заключение стандартного договора занимает от одного-двух месяцев до полугода и более. Обнаруженный факт, что Trae передаёт телеметрию даже при отключённой опции, означает: даже если вам кажется, что передача не ведётся, она всё равно происходит. В отраслях со строгим регулированием таким инструментам не место в среде разработки.

Аттестация по уровню защищённости.[^2] В соответствии с Законом КНР о кибербезопасности действует система уровней защиты 2.0. Публично доступное приложение с высокой вероятностью подпадает под третий уровень защиты. Процедура включает определение уровня, регистрацию, устранение недостатков и аттестацию — в сумме обычно занимает от трёх до шести месяцев. Это требование закона, а не опция. Тот факт, что приложение создано с помощью ИИ, не освобождает вас от аттестации.

Регистрация алгоритма.[^3] Если ваше приложение ориентировано на широкую аудиторию и использует генеративный ИИ (например, автоматическая генерация описаний товаров, автоподготовка ответов в поддержке, AI-контент в персонализированных рекомендациях), вы обязаны зарегистрировать алгоритм в соответствии с «Временными мерами по управлению сервисами генеративного ИИ» и нормативными актами об алгоритмических рекомендациях. Запуск без регистрации — это нарушение, которое классифицируется как инцидент в сфере комплаенса.

Утверждение изменений (CAB) и план отката.[^4] В финансовом и телеком-секторе любой релиз в критически важных системах проходит через согласование в Change Advisory Board: оценка зоны влияния, план отката, подтверждение окна. Вся эта процедура съедает календарное время, а не машинное — не успел в окно, жди следующей недели.

Сверка и аудит.[^5] После релиза в пиковые распродажи в e-commerce или при клиринге и расчётах в финансах необходима сверка с денежными потоками и вышестоящими системами, а также аудиторский журнал, по которому можно проследить каждую операцию. AI-генерируемые приложения здесь чаще всего беззащитны: они работают, но в них не заложена сверка, и при расхождении данных следов не найдёшь.

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

Это та самая красная линия, которая не сдвинулась на графике из первого раздела. Порог разработки рухнул — экономия на времени инженеров; порог соответствия требованиям не изменился — оценки, проверки, согласования занимают столько же. Главное заблуждение руководителей — думать, что ускорение первого автоматически ускорит второе. Не ускорит.

V. Дайте бизнесу легальный путь соответствия, не оставляйте его на самотёк

Раз уж не получается заблокировать — дайте канал. Это один из немногих рабочих подходов к управлению shadow IT.

Два пути для теневого IT: нельзя заблокировать — дайте канал Сейчас: дикий рост Операции сами делают приложения на Lovable ↓ никто не знает Касается заказов / телефонов / адресов ↓ без регистрации Данные уходят в личные облака ↓ без сканирования Обнаруживается только после утечки Сотни приложений работают, ни одного в реестре → С управлением: быстрый канал Компания даёт санкционированный генератор ↓ само-регистрация (5 минут) Данные по уровням: только обезличенные / тестовые ↓ автоматическое сканирование безопасности Касается чувствительных данных → оценка экспорта + MLPS ↓ в реестр активов Аудитируемо, отключаемо, отслеживаемо Бизнес остаётся быстрым, но каждое приложение — в реестре

Как именно выстроить этот канал — четыре шага.

Первый шаг — компания сама предоставляет сотрудникам генератор, прошедший оценку безопасности. Вместо того чтобы позволять командам идти во внешний мир и использовать какой-нибудь Lovable, компания закупает или создаёт собственную версию, соответствующую требованиям MLPS / Dengbao (китайский стандарт многоуровневой защиты информационной безопасности) и гарантирующую, что данные не покидают периметр. Такому инструменту даётся внутренняя точка входа. Если бизнес-подразделениям удобно работать с ним, они не пойдут искать что-то на стороне — это «отвод» в дополнение к «заслону».

Показательный пример того, как это делается, есть в отчёте Microsoft за FY26: EY развернула Copilot для 150 000 сотрудников и получила 15% прирост производительности; Atos внедрила Copilot для 56 000 сотрудников в 54 странах и управляет 19 000 AI-агентов под единой системой контроля, охватывающей идентификацию, безопасность, соответствие требованиям и управление агентами (обзорный пост Microsoft FY26 от 2026-07-28 и официальный пресс-релиз Atos от 2026-06-09 — в обоих случаях это совместные заявления вендора и клиента). Общее в действиях обеих компаний: они интегрировали AI-инструменты в корпоративный контур управления безопасностью и комплаенсом. Это и есть живой пример «санкционированного» канала. В Китае аналогичные подходы закреплены в «Руководстве по комплаенсу применения больших языковых моделей в финансовой отрасли» (CAICT — China Academy of Information and Communications Technology) и в пилотных программах Министерства промышленности и информатизации по теме «AI для ускорения новой индустриализации» (пилотные программы Министерства промышленности и информатизации). Локальный путь уже проторён — не хватает лишь того, чтобы сделать его обязательным элементом корпоративных процессов.

Шаг второй: обязательная регистрация. Кто создал приложение, к каким данным обращается, для каких пользователей предназначено — всё это заносится в реестр. Регистрация должна быть лёгкой: одна форма, пять минут. Не надо превращать её в двухмесячный бюрократический квест — иначе никто не заполнит, и всё снова уйдёт в тень. Цель регистрации — не одобрять каждое приложение, а иметь полный список.

Шаг третий: маршрутизация по уровню чувствительности данных. Используем матрицу из второго раздела. Приложения, работающие только с обезличенными или тестовыми данными, проходят автоматически. Как только заявка касается реальных заказов или персональных данных — автоматически запускается процедура оценки передачи данных за рубеж и проверка соответствия требованиям безопасности (аналог оценки по стандартам типа GDPR / NIS2). Процесс следует за чувствительностью данных, а не применяет один шаблон ко всем приложениям.

Шаг четвёртый: автоматическая проверка безопасности. В приложениях, сгенерированных ИИ, доля уязвимостей заметно выше, чем в коде, написанном человеком. В отчёте CodeRabbit за 2026 год эта цифра обновлена: количество проблем (включая логические ошибки и баги корректности) в коде, созданном при помощи ИИ, в 1,7 раза выше, чем в традиционном коде, написанном вручную (методология CodeRabbit, учитывает коммерческую позицию компании; данные синхронизированы с вебинаром DORA 2026-02 и横向测评 Kunal Ganglani 2026). Отчёт Veracode 2025 по безопасности GenAI-кода ещё более прямолинеен: в протестированной выборке примерно 45% ИИ-сгенерированного кода содержат уязвимости уровня OWASP Top 10 (для Java-кода доля неудач превышает 70%; методология Veracode, учитывает коммерческую позицию). Крупномасштабный эмпирический анализ публичных репозиториев GitHub (arXiv:2510.26103) подтверждает ту же тенденцию. Так что этап сканирования для ИИ-сгенерированных приложений — обязателен, а не опционален. Подключите SAST, сканирование зависимостей и проверку секретов к пайплайну релиза генератора: зелёный свет — только после полной проверки. В июне 2026 года CodeRabbit был публично подтверждён как самый устанавливаемый ИИ-инструмент ревью кода на GitHub/GitLab: более 15 000 платящих клиентов, проверено 6 миллионов репозиториев, а генеральный директор NVIDIA Дженсен Хуанг публично заявил: «Вся NVIDIA использует CodeRabbit». Так что рассматривать его как базовый ориентир для корпоративного контроля качества ИИ-кода — вполне разумно.

Шесть. Когда не следует использовать генератор приложений

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

Для критически важных транзакций или управления рисками. Это самый опасный вариант. Кто-то думает: «Генератор такой мощный, почему бы не попробовать и платёжный шлюз». Нижний правый угол той самой матрицы — красная зона: сложная логика плюс работа с деньгами. Отдать это генератору — всё равно что доверить критическую систему безответственному стажёру. При инциденте с денежными средствами не будет ни сверки, ни аудита, ни плана отката.

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

Здесь нужно отдельно прояснить одну искажённую цифру. В исходном материале фигурировал «45% уровень внедрения теневого ИИ» — это ошибочная атрибуция. 45% — это доля дефектов в ИИ-сгенерированном коде из отчёта Veracode, а не уровень внедрения инструментов; уровень внедрения теневого ИИ смотрите в UpGuard — там 80%+. Это две совершенно разные метрики, не путайте их.

Код, сгенерированный ИИ, по умолчанию безопасен. Результаты CodeRabbit (в 1,7 раза больше уязвимостей) и Veracode (45% кода содержат проблемы) уже дали ответ на этот вопрос. Между «выглядит работающим» и «безопасно работающим» приложением, созданным ИИ, лежит целая инженерная дисциплина безопасности. Относиться к ИИ-генерации иначе, чем к коду, написанному человеком, и снижать для неё стандарты безопасности — значит создавать больше уязвимостей с большей скоростью.

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

Установка IDE с передачей данных за рубеж, таких как Trae, всем инженерам компании по умолчанию. Соблазн бесплатных высококлассных моделей велик, и инженеры установят их сами. Как только ваш основной код, конфигурации и интерфейсы попадут на серверы ByteDance (или любого другого зарубежного субъекта), исправлять что-либо будет уже поздно. Внедрение таких инструментов в среду разработки требует оценки допуска совместно с отделом безопасности и юристами — это не то решение, которое техническая команда может принимать единолично.

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

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

Переключим фокус на четыре отрасли — по одному реальному сценарию из нашей практики на каждую.

Электронная коммерция. Самые частые источники инцидентов — «конфигуратор промо-акций», «дашборд подбора товаров у блогеров», «мини-приложение для проверки остатков». Выглядят как безобидные утилиты, но по факту читают широкие таблицы заказов с номерами телефонов и адресами. Такие приложения обязаны проходить регистрацию через sanctioned-канал из третьей секции — при касании реальных данных автоматически срабатывают требования по защите персональных данных и оценке трансграничной передачи. Мы своими глазами видели, как за два месяца операционная команда одного e-commerce игрока собрала семь внутренних инструментов, из которых четыре читали таблицы заказов. Это не единичный случай.

Финансы. Красная линия — «торговые системы / платежи / клиринг и расчёты / риск-менеджмент / антифрод / регуляторная отчётность». Генератор нормально подходит для рабочего места клиентского менеджера, конфигуратора маркетинговых кампаний, фронтенда сверки счетов. Категорически нельзя использовать его для движка риск-менеджмента или антифрод-правил — тот самый коэффициент логических багов 1,7× у CodeRabbit (методология самого CodeRabbit, с учётом их коммерческой позиции) в финансовом контексте превращается в прямой рост денежных рисков. Компания в кейсе анонимизирована: один из акционерных банков в конце 2025 года начал применять AI-программирование для вспомогательной генерации регуляторной отчётности. В итоге в скриптах под отчётность по методологии финансового регулятора обнаружились три несоответствия в маппинге полей — банк вызвали на разговор в надзор. Одна из корневых причин — «выглядящий правильным код» от AI никто не перепроверил.

Телеком/операторы связи. Среди региональных операторов, с которыми мы работали, маркетинговые подразделения на местах самостоятельно собирали на Bolt «быстрый поиск по профилю клиента»: вводишь номер телефона — получаешь историю тарифов, жалоб и рекомендаций за последние 90 дней. Это прямое нарушение границ доступа к данным по закону «О персональных данных» (аналог GDPR в России — 152-ФЗ). В телекоме генеративные инструменты уместны для «рабочего стола менеджера по клиентам», «фронтенда базы знаний для поддержки» и «конфигуратора маркетинговых акций» — но категорически не для биллинга, выставления счетов и просмотра детализации звонков. Это святая святых оператора: одна ошибка — и ты в новостях.

Производство. MES/ERP-интеграция, контроль качества и отчётность — это ядро системы, и генератору здесь место только на периферии: цеховые дашборды, маршрутные карты, демо-версии по OEE. Категорически нельзя доверять генератору: алгоритмы производственного планирования, правила приёмки, интерфейсы сверки с ERP. Пример обезличен: один поставщик автокомпонентов (в открытых источниках есть несколько похожих случаев отзыва продукции; детали собраны из публичных уведомлений об отзыве и личного опыта автора — для иллюстрации логики решений, а не указания на конкретную компанию) поручил IT-отделу собрать на Bolt «дашборд для ИИ-контроля качества». Задумка была простая — показывать фото образцов и результат проверки. Но при рендеринге фронтенда пороговое значение уверенности модели ИИ захардкодили в клиентскую часть. Сотрудник случайно изменил 0.85 на 0.6 — и за три дня более 200 деталей, которые должны были уйти в брак, ушли на линию как годные. Итог — отзыв трёх партий. Типичная ошибка среднего производителя — отдать генератору даже «фронтенд для ИИ-контроля качества». А ведь за этим фронтендом стоит отзыв продукции: одна ошибка — и вот уже официальное уведомление.

VIII. Что это значит для руководителей

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

Урок второй: проверка на соответствие регуляторным требованиям — это входной фильтр, а не запоздалое дополнение. Прежде чем закупать любой ИИ-инструмент, который будет касаться кода или данных, прогоните его через два фильтра: требования к трансграничной передаче данных и оценку защищённости (в китайском контексте — 等保测评, dĕngbǎo cèpíng, аттестация по уровням защиты информационной безопасности; в европейском — аналогично GDPR и NIS2). Проблема инструментов вроде Trae не в том, «можно ли их использовать», а в том, «можно ли их использовать в вашей регуляторной среде». Решение нужно принимать заранее: цена ошибки — переделки, предписания и даже отключение сервиса. Конкретные шаги: включите закупку ИИ-инструментов в общий процесс согласования со службой безопасности и юристами, заведите два списка — «можно заносить в среду разработки» и «требует индивидуального согласования».

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

Урок четвёртый: смените метрику, иначе весь бюджет уйдёт на инструменты, а узкое место так и останется. Это адресовано первому лицу. Сегодня многие советы директоров оценивают успех ИИ-трансформации по числу закупленных AI-лицензий или по тому, насколько ускорилась разработка. У такого подхода есть прямое следствие: бюджет утекает на покупку инструментов, а те этапы, которые реально держат поставку (служба оценки трансграничной передачи данных, отдел соответствия требованиям информационной безопасности, инженеры по безопасности, сверка и аудит), остаются без денег и без людей. В итоге инструментов накопилось — хоть отбавляй, а поставка как была медленной, так и осталась. Чтобы вылечить болезнь «знаю, но не могу пошевелиться», нужно менять саму метрику — наверху. Добавьте такие показатели, как «какая доля приложений покрыта合规-каналом», «число теневых приложений снизилось с N до M», «срок от прототипа до合规-запуска для ключевых приложений». Метрика изменится — и бюджет потечёт туда, где он действительно нужен.

Самопроверка наоборот (отвечайте честно): Сколько у вас сейчас приложений, которые бизнес-подразделения собрали сами с помощью ИИ, — можете назвать цифру? Сколько из них касаются заказов, номеров телефонов, адресов? Тот AI-IDE, который вы по умолчанию поставили инженерам, — вы проверяли, куда он отправляет данные? Те несколько цифр, которыми вы измеряете эффективность ИИ, — они поощряют «покупку инструментов» или «ускорение поставки»? Если хотя бы на один из четырёх вопросов вы ответили с сомнением — значит, риск, о котором пойдёт речь ниже, уже наступил в вашей компании.

Что дальше

Это пятая статья из 18-серийного цикла о трансформации разработки ПО в эпоху ИИ. Мы уже разобрали, как генераторы приложений и AI-IDE обрушили порог входа в «создание приложения» — и почему порог работы с данными при этом не снижается.

В следующей, шестой статье мы рассмотрим противоположное направление, которое всё чаще становится отраслевым консенсусом: Spec-Driven Development (разработка на основе спецификаций). Почему GitHub Spec Kit, Claude Code, AWS Kiro и AGENTS.md от OpenAI независимо друг от друга пришли к одному и тому же подходу: сначала зафиксировать требования в документации, и только потом давать ИИ зелёный свет. В прошлом разделе мы говорили, что у AI-сгенерированного кода уровень уязвимостей выше, чем у написанного человеком; спецификации — один из способов это лечить: превратить размытые устные пожелания в проверяемые требования, и только тогда появляется возможность контролировать ИИ.

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

Хотите применить эти выводы в своей компании?

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

Сейчас мы предлагаем три формата сотрудничества:

  • Корпоративное обучение: на основе реальных проектов вашей компании — выбор генератора приложений, определение границ использования, комплаенс-процедуры и проектирование механизмов управления.
  • Адресный консалтинг: фокус на конкретном решении, например «давать ли бизнес-подразделениям доступ к санкционированному генератору приложений» или определение приоритетов исправлений после инвентаризации теневых приложений.
  • Выступления для руководства и отраслевые доклады: темы — AI-инструменты программирования, управление теневыми приложениями, AI-трансформация предприятия и организационное управление.

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

Дополнительное чтение: «Методология „Вывеска“ v1.0» (慢慢学 AI 187) — системное описание 7-шаговой рамки AI-трансформации предприятия.

О серии

«Трансформация разработки ПО в эпоху ИИ» — исследовательская серия для CIO, CDO, CTO и руководителей цифровой трансформации в телекоме, финансах, производстве и e-commerce. Всего 18 статей о том, как AI-инструменты программирования, генераторы приложений и управление теневыми приложениями влияют на процесс поставки ПО, организационную структуру, механизмы управления и метрики менеджмента.

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

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

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

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

Источники (все проверены, по каждому указан уровень доказательности + позиция)

  • StackBlitz CEO Эрик Саймонс (LinkedIn, итоги 2026 финансового года). Bolt.new используют три четверти компаний из списка Fortune 500, корпоративная выручка ARR выросла в 10 раз год к году. Официальная позиция компании (взгляд вендора). https://www.linkedin.com/posts/eric-simons-a464a664-a-growth-update-as-we-close-out-our-fiscal-activity-7425263313049026560-5tdV

  • Sacra / Growth Unhinged (2025). Отслеживание роста ARR Bolt.new (примерно 5 месяцев до $40 млн ARR, около 5 млн пользователей, второй по скорости роста продукт в истории после ChatGPT). Первичное исследование/мониторинг. https://sacra.com/c/bolt-new/ 、https://www.growthunhinged.com/p/boltnew-growth-journey

  • Taskade (2026-03) / Business Insider. StackBlitz 2025-01 раунд B на $105,5 млн, оценка около $700 млн; Bolt V2 запущен на Bolt Cloud. Сводка отраслевых публикаций.

  • Forbes / Rashi Shrivastava (2026-06-05). Lovable ведёт переговоры о новом раунде финансирования с оценкой в $12 млрд; ARR превысил $500 млн (подтверждено TechCrunch 2026-06-09). Материал уровня ведущего отраслевого издания. https://www.forbes.com/sites/rashishrivastava/2026/06/05/ai-coding-startup-lovable-in-talks-to-raise-funding-at-a-12-billion-valuation

  • CNBC / Bloomberg (2025-12) / TechCrunch (2025-11). Lovable: раунд B — $330 млн при оценке $6,6 млрд, раунд A — $200 млн при оценке $1,8 млрд. Отраслевые публикации.

  • ARR.club (2026-07). Кривая роста ARR у Lovable: $17M (02.2025) → $100M (07.2025) → $200M (11.2025) → $400M (02.2026) → $500M (06.2026); среди корпоративных клиентов — Workday, Asana, NVIDIA. Отраслевая аналитика.

  • Vercel (03.02.2026, официальный блог, “Introducing the new v0”). v0 переехал с v0.dev на v0.app и превратился из генератора UI-компонентов в генератор полноценных full-stack приложений (песочница runtime + GitHub + интеграции со Snowflake/AWS). Первичный источник — сам вендор. https://vercel.com/blog/introducing-the-new-v0

  • Taskade (03.2026) / Vercel. По состоянию на март 2026 у v0 более 6 млн пользователей, около 80 тыс. активных команд в месяц, оценочный ARR — примерно $42M. Совокупные отраслевые оценки.

  • Replit (2026-03-13 официальный журнал изменений + официальный блог “What’s changed from Agent 3 to Agent 4”). Agent 4 выпущен 2026-03-11; Infinite Design Canvas; совместная работа через fork-and-merge заменена на многопоточные задачи в рамках одного проекта + автоматическое разрешение конфликтов (90% решаются автоматически). Первичный источник — сам вендор. https://docs.replit.com/updates/2026/03/13/changelog

  • AlphaSignal (2026). Детальный репортаж о том, как Replit Agent 4 автоматически разрешает 90% конфликтов слияния в командной работе. Отраслевое издание. https://alphasignal.ai/news/replit-s-agent-4-resolves-90-of-team-merge-conflicts-automatically

  • Atal Upadhyay (2026-03-19). Replit на той же неделе объявила о раунде D на $400 млн с оценкой в $9 млрд (рост втрое за полгода). Сводка отраслевых публикаций. https://atalupadhyay.wordpress.com/2026/03/19/replit-agent-4-replit-just-changed-everything

  • Cybernews (обновлено 01.08.2026) / The Register (28.07.2025) / segmentationf4u1t (первичное исследование на GitHub). Trae продолжает передавать на серверы ByteDance данные об оборудовании, идентификаторах устройств и активности в проектах, даже когда телеметрия отключена; объём одной партии данных может достигать 53 606 байт; за 7 минут — более 500 вызовов, около 26 МБ. ByteDance официально признала, что переключатель управляет только частью VS Code. Режим Privacy Mode планируется к выпуску примерно в августе 2026 года. В феврале 2026 Trae отменила условия «forever free» и перешла на платную модель на основе токенов. Первоклассное исследование в области безопасности + отраслевые репортажи + заявление производителя. https://cybernews.com/security/bytedance-ai-coding-tool-trae-data-collection 、https://www.theregister.com/software/2025/07/28/bytedance-ai-ide-trae-telemetry-continues-even-after-opt-out/ 、https://github.com/segmentationf4u1t/trae_telemetry_research

  • OpenAI Tools Hub / Jim Liu (2026-05-18). Trae за 12 месяцев: 6 млн регистраций, 1,6 млн месячной аудитории, 100 млрд строк кода суммарно; в феврале paywall на токены положил конец «бесплатно навсегда». Комплексное исследование (аналитическая позиция).

  • Gartner (цит. по Process Excellence Network, 2025-08-27 / DevOpsDigest / UC Today). К концу 2026 года 40% корпоративных приложений будут включать узкоспециализированные ИИ-агенты (в 2025-м — менее 5%); к 2035 году агентный ИИ займёт около 30% рынка корпоративного ПО ($450 млрд). Официальный прогнозный документ. https://www.processexcellencenetwork.com/ai/news/gartner-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026

  • Gartner (цит. по RapidClaw / Hendricks.ai / Arion Research, 2025–2026). С Q1 2024 по Q2 2025 число запросов от предприятий по multi-agent системам выросло на 1445% — это самая быстрорастущая тема в AI-консалтинге Gartner. Первичный уровень исследования / пересказ.

  • Microsoft (обзорный пост по итогам FY26, 28.07.2026). EY развернула Copilot для 150 000 сотрудников, получив 15% прирост производительности, и масштабирует решение на 400 000 сотрудников по всему миру; Atos внедрила Copilot для 56 000 сотрудников в 54 странах и управляет 19 000 AI-агентов через единую консоль. Первичные данные от вендора + подтверждение клиентов (позиция вендора и интегратора). https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Atos Group (2026-06-09, официальный пресс-релиз). Atos расширяет сотрудничество с Microsoft, разворачивая Copilot E7 (Frontier Suite) для 56 000 сотрудников, унифицируя контур управления через Entra/Defender/Intune/Purview/Agent 365 и эксплуатируя 19 000 агентов. Первичная информация от самой компании. https://www.atosgroup.com/en/press/atos-group-and-microsoft-expand-strategic-collaboration-scale-secure-agentic-ai-across-atos

  • UpGuard / Cybersecurity Dive (2025). Более 80% сотрудников и почти 90% руководителей по безопасности используют несогласованные ИИ-инструменты; около половины сотрудников вставляли конфиденциальные данные в такие инструменты (аналогичные отчёты Mimecast и Teramind дают схожие оценки, что подтверждает картину). Первичное исследование + отраслевая журналистика. https://www.cybersecuritydive.com/news/shadow-ai-employee-trust-upguard/805280/

  • Gartner (цит. по The Hacker News, май 2026). 69% организаций подозревают или подтверждают использование сотрудниками запрещённых ИИ-инструментов; лишь 37% имеют регламенты применения ИИ. Пересказ отраслевого издания.

  • CodeRabbit (совместный вебинар с DORA, февраль 2026 г. + независимое сравнительное исследование Kunal Ganglani, июнь 2026 г.). Количество дефектов (включая логические ошибки и баги корректности) в коде, сгенерированном с помощью ИИ, примерно в 1,7 раза выше, чем в коде, написанном человеком традиционным способом. CodeRabbit — самый устанавливаемый инструмент AI-ревью кода на GitHub/GitLab: более 15 000 платящих клиентов, проверено 6 миллионов репозиториев. Публичная поддержка со стороны генерального директора NVIDIA Дженсена Хуанга. Первичные исследования / данные вендора / отраслевое сравнительное тестирование. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report

  • Veracode (отчет GenAI Code Security за 2025 г.). Около 45% образцов кода, сгенерированного ИИ, содержат уязвимости из OWASP Top 10 (доля неудачных результатов для Java-кода превышает 70%). Первичное исследование. https://www.veracode.com/blog/genai-code-security-report/ （Примечание: в исходной версии эти «45%» ошибочно трактовались как «уровень внедрения теневого ИИ», что было неверно и исправлено — 45% относятся к доле дефектов в коде, созданном ИИ, а не к уровню внедрения инструментов; показатель внедрения теневого ИИ см. в отчете UpGuard — 80%+.）

  • arXiv:2510.26103. Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories.（Эмпирическое исследование уязвимостей в коде, сгенерированном ИИ, на основе публичных репозиториев GitHub.）

Примечание о данных: все количественные данные в этой статье сопровождаются указанием источника. Отдельные цифры, по которым вендоры не публиковали первичные данные или которые не были независимо подтверждены (например, раунд финансирования Lovable на $12 млрд, находящийся на стадии переговоров, или точное время инвентаризации 19 000 агентов Atos), были понижены в статусе достоинства. Клиентские кейсы деперсонализированы (группа операционного управления e-commerce, маркетинговый центр регионального филиала оператора связи и т.п.), источник — реальные сценарии, наблюдавшиеся автором в ходе сопровождения внедрений, без привязки к конкретным компаниям. Регуляторные требования (трансграничная передача данных, оценка уровня защищённости, регистрация алгоритмов) приводятся по действующему законодательству; конкретное применение зависит от вида деятельности и типа данных, перед внедрением следует руководствоваться заключением юридического/комплаенс-подразделения.

[^1]: Передача важных данных за рубеж регулируется статьёй 31 Закона КНР о безопасности данных (оценка безопасности передачи важных данных за рубеж); передача персональных данных за рубеж — статьями 38–43 Закона КНР о защите персональной информации (условия передачи, типовой контракт, механизм сертификации, уведомление и согласие). Сопутствующие нормативные акты: «Положения об оценке безопасности передачи данных за рубеж» (вступили в силу 01.09.2022, приказ Государственной интернет-администрации КНР № 11), «Положения о типовом контракте на передачу персональных данных за рубеж» (вступили в силу 01.06.2023).

[^2]: Статья 21 Закона КНР о кибербезопасности (система многоуровневой защиты), национальный стандарт GB/T 22239-2019 «Информационные технологии безопасности — Базовые требования к многоуровневой защите кибербезопасности» (MLPS 2.0); согласно «Положениям об управлении многоуровневой защитой информационной безопасности» (гунтунцзы [2007] № 43), для систем третьего уровня оценка уровня защиты проводится ежегодно, для систем второго уровня — обычно раз в два года.

[^3]: Следует различать три разных требования: ① Статья 24 «Положения об управлении алгоритмическими рекомендациями в интернет-информационных услугах» (вступило в силу 01.03.2022) — регистрация алгоритмических рекомендаций; ② Статья 17 «Положения об управлении услугами глубокого синтеза в интернет-информационной сфере» (вступило в силу 10.01.2023) — регистрация глубокого синтеза; ③ Статья 17 «Временных мер по управлению генеративными ИИ-сервисами» (вступило в силу 15.08.2023) — генеративные ИИ-сервисы, ориентированные на широкую публику и формирующие общественное мнение, обязаны проходить оценку безопасности — это именно оценка, а не регистрация. Сам по себе код, сгенерированный App-генератором, не обязательно подпадает под эти три категории, но если созданное приложение предоставляет генеративные ИИ-сервисы наружу или содержит функции алгоритмических рекомендаций/глубокого синтеза, оно обрабатывается по соответствующим статьям.
[^4]: Общая рамка управления изменениями — ITIL 4 Change Enablement; для финансового сектора актуальны «Меры регулирования аутсорсинга ИТ-рисков банковских и страховых организаций» (银保监发〔2021〕46号) и соответствующие уведомления Государственного управления финансового регулирования за 2024 год; для страхового сектора дополнительно действует «Руководство по управлению информатизацией страховых организаций» (保监发〔2009〕17号, редакция 2024 года).

[^5]: Хранение записей о транзакциях: первоисточник — статья 31 Закона КНР об электронной коммерции (платформы обязаны фиксировать и хранить данные о транзакциях не менее 3 лет) + статья 26 Положения о надзоре за интернет-торговлей (уточняет срок в 3 года). Журналы аудита: для систем третьего уровня защиты по стандарту 等保 2.0 (китайский стандарт классифицированной защиты информационной безопасности) требуется хранение сетевых журналов не менее 6 месяцев (в соответствии со статьей 21 Закона КНР о кибербезопасности), однако для критически важных систем в финансовом секторе согласно статье 19 Руководства по управлению данными банковских организаций и Положению о внутреннем контроле коммерческих банков обычно требуется не менее 5 лет — 6 месяцев это лишь минимальный порог, а не рекомендуемое значение.