Источники данных в статье: CodeRabbit 2025.12 / New Relic 2026, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Кейсы обобщают типичные сценарии и не привязаны к конкретным компаниям.

Ваша главная ошибка — не в том, что вы не купили инструменты, а в том, что не написали CLAUDE.md

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

Вот перевод вашего Markdown-текста на русский язык в соответствии со всеми вашими требованиями:

Анализ 470 открытых pull request’ов дал группу цифр, на которую часто ссылаются: в среднем в AI-сопровождаемых PR содержится 10,83 проблемы, в чисто ручных — 6,45. Это в 1,7 раза больше, то есть на 70% больше багов, чем при работе человека. К 2026 году сюжет не перевернулся: New Relic в своём «2026 State of AI Coding Report» обнаружил, что 78% команд сообщают о большем количестве инцидентов после выкладки AI-кода в продакшн, а 62% технических лидеров признают, что их команды «уверенно отправляют AI-код без построчного ревью» (официальный отчёт New Relic, 2026, оценка 0,866, первоисточник). Обе группы цифр говорят об одном и том же — у AI нет недостатка в способностях, есть недостаток в контексте.

В августе 2026 года все нарративы об «ускорении AI-трансформации» нужно рассматривать в паре с другим набором фактов:

| Лагерь | Прогресс (1-е полугодие 2026) | Контрпример (1-е полугодие 2026) |
|—|—|—|—|
| EY | Microsoft 365 Copilot развёрнут на 150 000 сотрудников, экономия 2,5 млн часов / 250 млн долларов; масштабирование на 400 000 сотрудников по всему миру | При этом признаёт: ускорение на 95% и снижение операционных затрат в финансовом блоке на 37% достижимы только при условии «сначала регламенты, потом инструменты» |
| Atos | Развёртывание в 54 странах / 56 000 сотрудников; одновременно работают 19 000 ИИ-агентов под единой плоскостью управления идентификацией, безопасностью, комплаенсом и управлением | Жёстко придерживается принципа «сначала вывести на productive контур возможности управления Agent 365, затем масштабировать» |
| Сама Microsoft | Work Trend Index 2026: 82% руководителей планируют в ближайшие 12–18 месяцев расширять штат за счёт ИИ-агентов | В то же время признаёт: «темп организационных изменений отстаёт от темпов индивидуального использования» — это ключевое противоречие в концепции Frontier Firm |

Источник: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

Эти два сопоставления показывают одну вещь: без стандартов масштабирование означает умножение риска на N. «Скорость» EY/Atos/Microsoft — это не скорость моделей, а скорость, с которой организация отвечает на вопрос «как мы будем использовать AI». Именно это стало фоном для того, почему Spec-Driven Development (SDD, разработка, управляемая спецификациями) по-настоящему вышел в мейнстрим в первой половине 2026 года — не потому, что инженеры любят документацию, а потому, что без написания спецификаций уже невозможно выжить в среде с 19 000 агентов.

Эта статья проясняет три вещи: 1) почему дефекты в AI-коде встречаются более чем в 1,7 раза чаще, чем в коде, написанном человеком; 2) как пять платформ — GitHub, AWS, OpenAI, Anthropic и Alibaba — в первой половине 2026 года пришли к одной и той же парадигме: ограничение поведения AI с помощью документации; 3) почему спецификационно-ориентированная разработка — это организационная способность, а не выбор инструмента, и какие три этапа внедрения прошли в первой половине 2026 года.

AI-код против человеческого кода: распределение дефектов (анализ 470 открытых PR) Отчёт CodeRabbit 2025.12｜все цифры — кратное отношение AI / человек (базовая линия 1.0)

Длина столбца = во сколько раз дефектов AI больше; базовая линия 1.0× = уровень человека

Базовая линия 1.0×

Общее число проблем

1.7×
AI 10.83 против человека 6.45 / PR

Логические / ошибки корректности

1.75×

Качество кода / поддерживаемость

1.64×

Находки по безопасности (сводно)

1.57×

Неправильная обработка паролей

1.88×

XSS-уязвимости

2.74×
↑ максимум

AI-код без нормативных ограничений выше человеческого по всем параметрам
Финансы/телеком = комплаенс-сверка, управление паролями, шифрование чувствительных полей — AI всего этого не видит

I. Дефекты ИИ — это не проблема модели, а проблема контекста

В отчёте CodeRabbit есть одна фраза, которую цитируют постоянно: «ИИ не понимает локальную бизнес-логику: модель выводит паттерны кода статистически, а не семантически. Без строгих ограничений она упускает системные правила, которые старший разработчик впитал за годы практики».

Эта фраза объясняет, почему собственная AI-платформа CodeRabbit (компания, специализирующаяся на AI-ревью кода) увидела эти данные раньше других — они ежедневно просматривают тысячи pull request’ов и видят, как выглядит код, написанный ИИ. «Ключевой» вывод — не в общих цифрах, а в распределении:

  • Логика/корректность +75%: ошибки бизнес-логики, ошибки зависимостей, ошибки потока управления, ошибки конфигурации — такие проблемы не всегда всплывают в тестах, но приводят к инцидентам в продакшене.
  • Качество кода +64%: несогласованные имена, нечёткая структура, нарушение принятых в проекте паттернов — это «категория с максимальным разрывом». Старший разработчик видит с первого взгляда: «это не наш стиль».
  • Безопасность +57% (XSS-класс — до 2,74×): некорректная обработка паролей (1,88×), небезопасные ссылки на объекты (1,91×), утечка чувствительной информации, небезопасная десериализация (1,82×) — в финансовой отрасли это вопрос не «можно ли использовать», а «можно ли выпускать в продакшен».

Проблема не в том, что ИИ недостаточно силён. Проблема в том, что он не видит.

Вернёмся к реальной боли того самого CIO. Вот три конкретных сбоя ИИ в финансовых системах ядра:

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

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

В-третьих, ИИ не видит ваш технический долг. У той 30-летней хост-системы собственный протокол интерфейсов, документация давно утеряна. ИИ пишет код по стандартному RESTful, а при запуске выясняется, что интерфейсы не сходятся — две недели переделки.

Теперь вернёмся к другим цифрам New Relic: 62% команд «уверенно выкатывают код ИИ без ревью», 78% после релиза сообщают о большем числе инцидентов. Сложите эти два числа — и получится: проблема не в уровне дефектности ИИ-кода как таковом. Проблема в том, что «я не знаю, какие дефекты в этом ИИ-коде».

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

II. Пять платформ в первом полугодии 2026: разные пути, одна цель — «управление через спецификации»

В июле 2025 года GitHub выпустил Spec Kit. В начале 2026 года AWS Kiro, OpenAI Codex и Anthropic Claude Code закрыли этот пробел. В мае 2026 года Alibaba Qoder включил «Spec-Driven Workflow» в своё позиционирование продукта. К первому полугодию 2026 года все пять платформ пришли к одной и той же парадигме — использование документации для управления поведением ИИ. Это не изобретение какой-то одной компании, а коллективный ответ индустрии на «кризис качества кода, создаваемого ИИ».

Нормативные пути пяти платформ (2025–2026 H1) GitHub Spec Kit Открытый исходный код 2025.9 constitution.md Пятиэтапный гейтинг: constitution → specify → plan → tasks → implement Не зависит от модели, 8+ агентов Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md Трёхэтапный рабочий процесс: Требования → Дизайн → Задачи Spec-driven в IDE-процесс Хуки запускают автоагентов Встроенные хуки аудита Без spec не запустится OpenAI Codex 2025-2026 AGENTS.md + Система навыков Комбинируемые наборы команд Общая конфигурация команды 5M+ активных в неделю (2026.6) 20% не разработчиков От кода к универсальному агенту Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Навыки (официальный маркет 2026.2) + Экосистема MCP CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 112 тыс. звёзд Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest Mode автономное выполнение + Expert Mode команда + RepoWiki контекст 5M+ пользователей по всему миру (2026.5) 2026.7.21 Qoder Security CLI DingTalk подключён Общий подход: явно прописать «как мы сотрудничаем с ИИ» в документе и хранить в репозитории Все люди и все ИИ-агенты работают по одному стандарту — суть стандарт-ориентированности

Рассмотрим последние действия каждой платформы в первом полугодии 2026 года:

GitHub Spec Kit: эталонная реализация с пятиэтапным гейткипом. Релиз состоялся в сентябре 2025 года, и уже к первой половине 2026-го проект стал де-факто эталоном в индустрии. 5 основных команд + 2 дополнительных: /speckit.constitution (непреложные принципы), /speckit.specify (что делаем и зачем), /speckit.plan (как меняем), /speckit.tasks (декомпозиция на задачи), /speckit.implement (исполнение), плюс /clarify и /analyze. Ключевая особенность архитектуры — модельная независимость: одни и те же файлы spec/plan/tasks не привязаны к конкретному агенту исполнения, их подхватывают Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf и Qwen Code. Благодаря этому Spec Kit превратился в «организационный протокол SDD», а не в проприетарный продукт GitHub (оценка vibecoding.app, июнь 2026, score 0.816, вторичный источник).

AWS Kiro: спецификации, встроенные прямо в IDE. Выпущен в июле 2025 года, к первой половине 2026-го эволюционировал в полноценную агентную IDE. Рабочий процесс строится в три этапа: требования → проектирование → задачи. Главное отличие от Spec Kit — «хуки»: файл спецификации в Kiro может запускать заранее заданные действия агента, закладывая в пайплайн шаги, требующие внешних систем, — комплаенс, аудит, деплой. Если вам нужно заставить команду писать спецификации, выбирайте Kiro — без spec-файла он просто не запустится (официальные материалы AWS Kiro, июль 2025; документация Kiro.dev, 2026).

OpenAI Codex: AGENTS.md + композиционные Skills. В 2025–2026 годах AGENTS.md выдвинулся в центр экосистемы. Skills — ключевое расширение первой половины 2026-го: рутинные операции вроде «прочитать Excel-таблицу», «сгенерировать SQL» или «провести миграцию данных» теперь собираются заранее и вызываются как конструктор Lego. Еженедельная аудитория Codex превысила 5 миллионов пользователей к июню 2026-го, причём 20% из них — не разработчики. Это сигнал, который легко упустить: нормативное управление больше не забота только инженерных команд — это общее дело. Продуктовые менеджеры, операционные специалисты и риск-менеджеры пишут AGENTS.md (анонс OpenAI от 02.06.2026; обзор thebcms.com, 2026, оценка 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic называет проектные инструкционные документы CLAUDE.md (вышел на официальный рынок в феврале 2026 года), .claude/rules/ (правила, организованные по директориям) и Skills (общие рабочие процессы). Claude Code — самый высоко оценённый инструмент среди разработчиков в первой половине 2026 года — по данным опроса JetBrains 2026.1, показатель CSAT составил 91%, NPS — 54, и это подтверждается двумя независимыми исследованиями (Pragmatic Engineer, февраль 2026). Это самый высокий результат в индустрии AI-инструментов для программирования на данный момент (uvik.net, май 2026, оценка 0,956, сводка первоисточников). Claude Code всего за 9 месяцев вышел на годовую выручку в 2,5 миллиарда долларов (по данным раунда G Anthropic, февраль 2026), а репозиторий Skills на GitHub собрал 112 тысяч звёзд — разработчики голосуют ногами, и это лучшее доказательство реальной ценности подхода, основанного на правилах.

Alibaba Qoder: нормативный драйвер китайского рынка. Релиз состоялся в августе 2025 года, а 15 мая 2026 года продукт был обновлён до версии 1.0, официально сменив позиционирование с «AI IDE» на «Autonomous Agent Development Workbench». Ключевая особенность — Spec-Driven Workflow — была представлена в связке с Quest Mode (автономные многофайловые задачи), Expert Mode (параллельная работа экспертных команд) и RepoWiki (граф знаний репозитория). 28 мая 2026 года появились Cloud Agents (полностью управляемая среда выполнения агентов), 21 июля — Qoder Security (комплаенс-функции безопасности), а в том же месяце вышла мобильная версия (Android/iOS/HarmonyOS). К маю 2026 года глобальная аудитория превысила 5 миллионов пользователей; CLI DingTalk включил Qoder в список поддерживаемых сред выполнения агентов (Yahoo Finance 2025; Alibaba Cloud official 2026; Baidu Baike 2026.7).

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

Почему это произошло массово в первой половине 2026 года? Потому что порог возможностей ИИ уже пройден: автономные агенты Claude Code, параллельные мультиагенты Codex, многофайловый рефакторинг в Cursor — ИИ больше не «инструмент автодополнения», а «коллега». Документ онбординга, который вы даёте новому сотруднику, обязан быть доступен и ИИ.

III. Управление через спецификации — это организационная способность, а не выбор инструмента

Это самый важный пункт для лиц, принимающих решения. Управление через спецификации — это не выбор инструмента, а определение того, «как наша организация взаимодействует с ИИ». Неважно, выберете ли вы GitHub Spec Kit или Claude Code; важно, зафиксировали ли вы спецификации в виде документа, положили ли в репозиторий и работаете ли по ним и люди, и ИИ.

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

Если смотреть на это в контексте масштабного развёртывания в первом полугодии 2026 года, доказательства становятся ещё убедительнее. В своём отчёте за 2026 финансовый год (июль 2026) Microsoft привела кейсы EY и Atos как образец шаблона «Frontier Firm» — не потому, что модели были новыми, а потому, что обе компании сначала ответили на вопрос «как мы будем использовать ИИ»:

EY: сначала нормативная база, потом масштабирование и результат. В 2024–2025 годах EY развернула Microsoft 365 Copilot для 150 000 сотрудников, сэкономив 2,5 миллиона часов и около 250 миллионов долларов. Ключевое условие — «сначала выстроить систему управления ИИ»: EY создала единый инструментальный контур на базе Power Platform, Copilot Studio, Azure, Foundry и Fabric, объединив нормативные требования, комплаенс и аудит в одной инфраструктуре. Именно это позволило добиться ускорения на 95%, снижения операционных затрат в финансах на 37% и сокращения до 90% ручных процессов. Вице-президент EY на AI Tour 2026 сформулировал предельно чётко: «Мы не разворачивали ИИ, а потом закрывали пробелы в управлении — мы сначала выстроили управление, а уже потом запускали ИИ».

Atos: единая плоскость управления для 19 000 агентов. Atos — одна из первых организаций в мире, развернувших Microsoft 365 E7 (Frontier Suite) и предоставивших Copilot 56 000 сотрудников в 54 странах. Одновременно у них работают 19 000 ИИ-агентов — от внутреннего ИТ и бизнес-подразделений до клиентских проектов, все создаются на базе Foundry и Copilot Studio. Ключ к успеху Atos — «единая плоскость управления»: Entra (идентификация) + Defender (безопасность) + Intune (устройства) + Purview (комплаенс) + Agent 365 (управление агентами), пять компонентов, связанных воедино. В финансовой отрасли такой подход соответствует связке «等保测评 (аттестация защиты информационной безопасности) + оценка трансграничной передачи данных + алгоритмическое депонирование + аудит + управление моделями» — это архитектура управления, а не просто набор ИИ-инструментов.

Парадокс организационных изменений у Microsoft. В отчёте Work Trend Index за 2026 год Microsoft прямо признаёт: «организации меняются медленнее, чем отдельные сотрудники внедряют ИИ». Среди 20 000 опрошенных пользователей ИИ 82% руководителей планируют в ближайшие 12–18 месяцев расширять штат за счёт ИИ-агентов, но лишь 24% уже завершили внедрение на корпоративном уровне. 81% руководителей ожидают, что ИИ-агенты будут в значительной или умеренной степени интегрированы в их ИИ-стратегию — и снова только 24% уже это сделали. Иными словами, большинство компаний находятся на дистанции в 12–18 месяцев между «готовимся» и «сделали». И главный инструмент, который поможет сократить этот разрыв, — нормативное регулирование и стандарты.

Источники: Microsoft FY26 retrospective, 28.07.2026; Microsoft 2026 Work Trend Index Annual Report, 05.05.2026 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, первоисточник в формате PDF); анализ Futurum Group от 26.01.2026 (вторичный источник).

Вывод первый: инвестиции в нормативное регулирование — это высокая окупаемость.

Данные CodeRabbit дают чёткую основу для расчёта ROI: частота проблем в коде, создаваемом ИИ, примерно в 1,7 раза выше, а количество уязвимостей безопасности снижается в 2,74 раза. Что это означает на практике:

  • Меньше переделок (в финансовой отрасли одна повторная проверка на соответствие требованиям — это 2–4 недели работы)
  • Меньше инцидентов безопасности (штрафы регулятора и репутационный ущерб от одной утечки данных)
  • Ниже затраты на сопровождение (сокращение технического долга на 40% — вполне типичная цифра)

Написать файл проектных стандартов CLAUDE.md/AGENTS.md — это, пожалуй, самое выгодное инженерное действие в эпоху ИИ. Кейс EY даёт наглядную иллюстрацию в реальных деньгах: 150 тысяч сотрудников с Copilot — экономия 250 миллионов долларов. Обратите внимание: EY сэкономил не потому, что «инструмент оказался мощным», а потому, что «стандарты позволили этому инструменту раскрыть свою ценность».

Вывод второй: закрепляйте стандарты в процессах организации, а не в головах отдельных людей.

Если стандарты живут только в голове у опытного инженера — они исчезнут, как только этот человек сменит работу. Их нужно фиксировать в:

  • Документации репозитория (AGENTS.md / CLAUDE.md / constitution.md)
  • CI-гейтах (автоматическая проверка соблюдения стандартов)
  • Общих конфигурациях команды (система Skills, чтобы вся команда могла ими пользоваться)

Пусть стандарты станут активом организации, а не личным навыком. Это особенно важно в финансовой отрасли — ваши требования комплаенса, правила безопасности, бизнес-правила — это активы уровня организации, а не «опыт» отдельного инженера. 19 000 агентов Atos работают в 54 странах именно потому, что управление здесь — это не «кто-то разбирается», а «система принуждает».

Вывод третий: шлюзы важнее скорости.

Пятиэтапные шлюзы GitHub Spec Kit (constitution → specify → plan → tasks → implement), правило Claude Code «не пиши код, пока тесты не падают», требование Kiro «без spec не запустишь» — всё это делает одно и то же: ставит «тормоз» между ИИ и конечным результатом. На каждом шаге есть проверяемый артефакт (spec.md, plan.md, tasks.md), который можно отклонить или изменить до генерации кода.

Чем автономнее ИИ, тем больше ему нужны шлюзы. Change Advisory Board (CAB) в финансовой отрасли, процедуры алгоритмического регулирования, оценка уровня защищённости (等保测评) — всё это по сути шлюзы перед запуском в производство. ИИ-коду нужны аналогичные шлюзы, просто в другой форме. Те 62% команд из отчёта New Relic 2026, которые «уверенно выкатывают без ревью», расплачиваются за эту уверенность повышенной аварийностью (78%).

Три этапа внедрения стандартов в финансовой отрасли (практика H1 2026) Этап 1: инвентаризация правил 2–4 недели | самый трудоёмкий, максимальный ROI Чек-лист требований комплаенса (защита/выезд/регистрация) Правила безопасности (пароли/шифрование/логи) Бизнес-правила (риск-контроль/транзакции/биллинг) Технические ограничения (старые API/версионные лимиты) Управление поставщиками (контракты/аудит/ответственность) Собрать разрозненные правила Структурировать в документацию Этап 2: внедрение в репозиторий 1-2 недели | в репозиторий, AI автозагрузка CLAUDE.md / AGENTS.md constitution.md Определение Skills (общие рабочие процессы) Проектирование гейткипинга (пять этапов) .claude/rules/ (иерархические правила) Поместить правила в репозиторий, AI автозагрузка Этап 3: институционализация Постоянно | от инструмента к организационной способности CI-гейткипинг (автопроверка) Общая конфигурация команды (Skills) Регулярное обновление (квартальный обзор) Метрики (доля дефектов/процент соответствия) Управление агентами (Agent 365 уровень 1) Стандарты становятся активом организации, Не зависят от отдельных лиц

Первый этап самый затратный по времени, но ROI самый высокий
Правила большинства финансовых организаций разбросаны по документам/почте/мозгам, первая систематизация — 3-8 недель вложений

Четыре. Реальные этапы внедрения в первом полугодии 2026 года

Ниже — трёхэтапный путь на примере финансовой отрасли. Остальные строго регулируемые сектора могут использовать его как ориентир. Практика EY и Atos в первом полугодии 2026 года как раз соответствует этим трём этапам.

Этап первый: инвентаризация правил (2–4 недели).

Самый трудоёмкий, но при этом самый рентабельный этап. Нужно собрать все правила, разбросанные по разным системам и документам:

  • Требования комплаенса: для финансовой отрасли минимальный базовый уровень = защита ИСПДн уровня 3 + оценка трансграничной передачи данных + регистрация алгоритмов (если не хватает хотя бы одного — ИИ разворачивать нельзя). Дальше — требования к регуляторной отчётности, защита данных клиентов, ограничения на трансграничные потоки данных, а также то, какие данные вообще можно показывать ИИ.
  • Правила безопасности: управление паролями, стандарты шифрования, обработка чувствительных полей, требования к журналированию.
  • Бизнес-правила: пороги риск-аппетита, условия выплат, лимиты по операциям, логика тарификации.
  • Технические ограничения: интерфейсы унаследованных систем, нейминг в базах данных, ограничения версий фреймворков.
  • Управление поставщиками: как прописать в договоре требование, чтобы вендор следовал нашим стандартам, и как проводить аудит использования ИИ у поставщика.

Типичный сценарий: на этапе инвентаризации одна securities-компания обнаружила, что правила разбросаны по множеству Word-документов, JIRA-вики, личным письмам и Excel-таблицам — только после наведения порядка получился структурированный перечень правил. Подход Atos более системный — они сразу разбили правила на пять категорий: «комплаенс, безопасность, бизнес, технологии, поставщики», для каждой завели отдельный governance-процесс и подключили всё к единой управляющей плоскости Agent 365.

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

Этап второй: загрузка в репозиторий (1–2 недели).

Правила, собранные на первом этапе, оформляются в документы и помещаются в репозиторий. GitHub Spec Kit использует constitution.md, Claude Code — CLAUDE.md, OpenAI Codex — AGENTS.md, Alibaba Qoder — Spec Workflow. Имена файлов разные, цель одна — чтобы AI подхватывал их в момент открытия репозитория.

Структура предложения (основной формат на H1 2026):

  • Обзор проекта: что делает система и кому она предназначена
  • Некомpromиссные принципы: красные линии безопасности, комплаенса и бизнеса
  • Технологический стек и ограничения: какие фреймворки, базы данных и стандарты интерфейсов используются
  • Стандарты кодирования: соглашения об именовании, структура каталогов, минимальные требования к покрытию тестами (без принудительного ритма TDD — достаточно четко прописать процент покрытия, обязательные сценарии и запрещенные пути; TDD — это организационный выбор, а не жесткое требование стандарта)
  • Бизнес-правила: логика риск-контроля, правила транзакций, правила биллинга
  • Требования комплаенса: защита информации (等保), трансграничная передача данных, регуляторная отчетность, необходимость регистрации алгоритмов ИИ
  • Правила использования ИИ: в каких сценариях ИИ допустим, где обязательна ручная проверка, правила трансграничной передачи данных
  • Управление поставщиками: условия контрактов, механизмы аудита, распределение ответственности

Приложение: каркас CLAUDE.md для финансового сектора (~200 строк, можно форкнуть и адаптировать)

Ниже представлен каркас CLAUDE.md для модернизации ядра системы акционерного коммерческого банка, организованный по принципу «некомpromиссные принципы → требования комплаенса → правила использования ИИ → бизнес-правила → инженерные ограничения». Вам не нужно начинать с нуля — достаточно заполнить пустые поля своими конкретными правилами.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
# CLAUDE.md — <имя системы> — правила взаимодействия с ИИ

> Область применения: <имя системы> v<версия>; все ИИ-агенты (Claude Code / Cursor / Copilot / Codex),
> работающие в данном репозитории, обязаны соблюдать настоящую спецификацию. Документ поддерживается
> <комитет по управлению> и пересматривается ежеквартально.
> Последнее обновление: YYYY-MM-DD

## 1. Обзор проекта
- **Бизнес-позиционирование**: имя ключевой системы / обслуживаемые сегменты клиентов / основные типы транзакций
- **Критическая цепочка**: транзакция → контроль рисков → клиринг → сверка → отчётность
- **Окно недоступности**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (любые изменения запрещены)
- **Ключевые зависимости**: вышестоящая <система>, нижестоящая <система>, платформа регуляторной отчётности

## 2. Не подлежащие обсуждению принципы (красные линии — нарушение = отказ в слиянии)

### 2.1 Красные линии безопасности
- Пароли, ключи и токены — только через KMS (Key Management Service); **жёсткое кодирование запрещено**, **вывод в журналы запрещён**
- Чувствительные поля клиента (удостоверение личности / номер карты / CVV / номер телефона) **должны храниться в зашифрованном виде**; открытый текст в базе запрещён
- В журналах запрещено появление: полного удостоверения личности, полного номера карты, пароля в открытом виде, комбинации «имя клиента + номер телефона»
- Вызовы внешних API должны проходить через API-шлюз; прямое подключение запрещено

### 2.2 Красные линии соответствия
- Код, сгенерированный ИИ и предусматривающий доступ к данным клиентов, должен содержать в описании PR пометку «доступ к данным: <поле>»
- Трансграничная передача данных запрещена; **любая передача данных за рубеж должна проходить через оценку трансграничной передачи данных** (обращаться в комплаенс)
- Алгоритмические решения (кредитование / страховые тарифы / антифрод) должны сохранять возможность ручной проверки
- Любое изменение модели требует регистрации алгоритмов; номер регистрации должен быть указан в описании PR

### 2.3 Красные линии бизнеса
- Изменение порогов контроля рисков требует двойной подписи руководителя по рискам и бизнес-руководителя
- Операции с клиентскими средствами должны иметь идемпотентность + откат при сбое
- Лимиты транзакций, тарифы и параметры продуктов управляются через платформу управления параметрами; жёсткое кодирование в коде запрещено

## 3. Технологический стек и ограничения
- **Языки**: Java 17 (ядро) / Kotlin (новые модули) / SQL (база данных)
- **Фреймворк**: Spring Boot 3.x + Spring Cloud Alibaba
- **База данных**: OceanBase 4.x (режим совместимости с MySQL); **внешние ключи запрещены**
- **Спецификации интерфейсов**: внутри — только gRPC; внешние — OpenAPI 3.0; RESTful только для административных интерфейсов
- **Соглашения об именовании**: классы Java в PascalCase, методы в camelCase, константы в UPPER_SNAKE; таблицы `t_<домен>_<сущность>`; индексы `idx_<таблица>_<поле>_<порядок>`
- **Структура пакетов**: `com.<компания>.<домен>.<поддомен>.<слой>` (например, `com.bank.pay.tx.core.service`)

## 4. Стандарты кода
- **Минимальное покрытие тестами**: критическая цепочка ≥ 80 %, утилиты ≥ 60 %; любой новый код, поставляемый в PR, должен сопровождаться тестами
- **Обязательные пути тестирования**: все контроллеры должны иметь интеграционные тесты (включая пути сбоев); все ветви enum должны иметь модульные тесты
- **Запретные пути**: запрещено изменять каталог `<модули исторического наследия>` — сначала создайте слой адаптера
- **Управление зависимостями**: добавление сторонней зависимости требует SCA-сканирования + одобрения безопасности

## 5. Бизнес-правила (по доменам)
### 5.1 Транзакции
- Лимит на одну операцию: <сумма>; лимит в сутки: <сумма>; превышение лимита — ручное утверждение
- Временное окно транзакций: <HH:MM> ~ <HH:MM>
- Определение дубликата: в пределах <временного окна> совпадение по <полю> считается дубликатом

### 5.2 Контроль рисков
- Приоритет сопоставления чёрных списков: внутренний чёрный список → нисходящий регуляторный список → судебная заморозка
- Порог срабатывания антифрод-модели: <оценка>; при превышении — обязательная ручная повторная проверка

### 5.3 Тарификация
- Изменение тарифа должно сопровождаться номером версии + датой вступления в силу
- Исторические заказы рассчитываются по тарифу, действовавшему на дату вступления в силу; обратной силы нет

## 6. Требования соответствия
- MLPS уровень 3 (等保三级): <организация оценки>, <дата следующей оценки>
- Оценка трансграничной передачи данных (数据出境评估): область применения (только модули трансграничной деятельности)
- Регистрация алгоритмов (算法备案): область применения (кредитование / страховые тарифы и иные ключевые алгоритмы), номер регистрации `<номер регистрации>`
- Регуляторная отчётность: таблица соответствия полей CBIRC / Народный банк Китая (银保监 / 人行) находится по пути `<путь>`

## 7. Стандарты использования ИИ
- **Допустимые сценарии ИИ**: шаблонный CRUD, генерация модульных тестов, черновики документации, предложения по оптимизации SQL
- **Сценарии обязательной ручной проверки**: логика контроля рисков, правила тарификации, управление правами, шифрование/дешифрование, трансграничные данные
- **Сценарии, в которых ИИ не может действовать автономно**: материалы CAB (Change Advisory Board) на утверждение, выполнение изменений в продуктивной среде, реагирование на инциденты
- **Правила трансграничной передачи данных**: обучающие данные / промпты / журналы вывода не должны покидать периметр; приоритет у локально развёрнутых версий (<поставщик>)
- **Требования к аудиту**: весь код, сгенерированный ИИ, должен содержать в описании PR пометку «ИИ-ассистент: <имя инструмента>»

## 8. Управление поставщиками
- **Допуск поставщиков**: обязательно предоставление отчёта SOC 2 / ISO 27001; модели ИИ должны сопровождаться model card
- **Контрактные условия**: принадлежность данных, объяснимость модели, условия выхода, право на аудит
- **Механизм аудита**: ежеквартальный аудит использования ИИ поставщиками; для поставщиков высокого риска — ежемесячный

## 9. Управление и обновления
- **Владелец**: <комитет по управлению> (комплаенс + безопасность + архитектура + бизнес)
- **Частота обновлений**: ежеквартальный пересмотр; экстренные изменения идут по ускоренной процедуре (двойная подпись + публикация за 24 ч)
- **Журнал изменений**: см. `CLAUDE_CHANGELOG.md`
- **Обработка нарушений**: первое нарушение = предупреждение + принудительное обучение; второе = приостановка доступа к инструментам ИИ; третье = отзыв прав

## 9. 治理与更新
- **所有者**：<治理委员会>（合规 + 安全 + 架构 + 业务）
- **更新频率**：季度评审；紧急变更走快速通道（双签 + 24h 公示）
- **变更日志**：见 `CLAUDE_CHANGELOG.md`
- **违规处理**：首次违规 = 警告 + 强制培训；二次违规 = 暂停 AI 工具使用；三次 = 取消权限

Этот скелет — не «эталонный ответ», а «шаблон для заполнения». Что именно вы впишете в каждую ячейку, важнее, чем объём текста: пустые места показывают, о чём ваша компания «ещё не подумала».

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

Важное нововведение первой половины 2026 года — Skills / определение рабочих процессов: это уже не просто документация, а инструментальная цепочка, которую ИИ может вызывать. Система Skills в Claude Code (в феврале 2026 года появилась в официальном маркетплейсе Anthropic, 112 000 звёзд на GitHub) превращает такие операции, как «прочитать Excel-таблицу», «сгенерировать SQL» или «провести миграцию данных», в переиспользуемые рабочие процессы. Это ключевая эволюция нормативного подхода в первой половине 2026 года: нормы — это не только ограничения, но и исполняемые рабочие процессы.

Третий этап: институционализация (постоянно).

Написать спецификацию — не финал, а отправная точка. Дальше её нужно встроить в организационные процессы:

  • CI-гейты: автоматическая проверка кода на соответствие спецификации (например, детекция хардкода паролей, незашифрованных чувствительных полей)
  • Общие конфиги для команды: через систему Skills вся команда работает по единому стандарту
  • Регулярное обновление: правила меняются — спецификация должна меняться вместе с ними (квартальный ревью)
  • Метрики и обратная связь: отслеживание доли дефектов в AI-коде, прохождения compliance-проверок, доли переделок
  • Губернаторство агентов: расширение практик управления с людей на AI-агентов — Atos на Agent 365 сделали это системным, а не индивидуальным уровнем

EY и Atos в первой половине 2026 года оба превратили третий этап в «организационную способность». Экономия EY в 2,5 млн часов — результат правильно выстроенных первого и третьего этапов: второй лишь перевёл правила в формат, читаемый AI.

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

В сильно регулируемых отраслях — финансы, телеком, медицина — внедрение спецификаций проходит дополнительную проверку: комплаенс — не внешняя надстройка, а встроенный код. Ниже — три подхода к встраиванию комплаенса, подтверждённые в первой половине 2026 года. CIO и руководители цифровой трансформации могут использовать их как готовую основу при проектировании организации.

5.1 Встраивание представителя комплаенса в стрим-команду: когда соответствие требованиям «присутствует», а не «согласовывается»

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

Новый подход: в каждую стрим-команду (stream-aligned team) встраивается представитель комплаенса — по принципу двойного подчинения: «сплошная» линия — в отдел комплаенса, «пунктирная» — в бизнес-команду. Как это выглядит на практике:

  • Штатная единица: один представитель комплаенса на 6–8 стрим-команд. Он числится в отделе комплаенса, но физически сидит вместе с бизнес-командой — это не «командировка» и не временное прикомандирование
  • KPI по «пунктирной» линии: 50% оценки представителя комплаенса завязано на «долю дефектов комплаенса» и «процент прохождения проверок с первого раза» в бизнес-команде, а не только на «покрытие аудитом» со стороны комплаенса
  • Включение на раннем этапе: представитель комплаенса участвует в ежедневных стендапах (достаточно раз в неделю), в ревью пул-реквестов, а код, сгенерированный ИИ, обязан пройти через него до слияния в основную ветку — а не постфактум, когда нарушение уже обнаружили
  • Инструментальная поддержка: представитель комплаенса работает через Skills с чек-листами проверок, а не сверяет требования вручную, пункт за пунктом

Типичный сценарий: один из национальных акционерных банков в первом полугодии 2026 года запустил пилотный проект — три стрим-команды с встроенными compliance-представителями, и доля отклонённого AI-кода по причинам несоответствия требованиям снизилась с 35% до 8%. Ключевой фактор — не в том, что compliance стал «строже смотреть», а в том, что он стал «смотреть раньше». Решающее условие здесь — чтобы пунктирная мотивация compliance-представителей была привязана к бизнес-целям — если KPI compliance-представителя по-прежнему определяется только задачами compliance-отдела, встраивание обречено на провал.

5.2 Compliance как enabling team: превращаем ограничения в affordance

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

Новый подход: compliance-команда перестраивается по модели enabling team из Team Topologies — она не пишет код напрямую и не ревьюит PR, но даёт бизнес-командам три вещи, которые позволяют им «соблюдать требования самостоятельно»:

  1. Проверки соответствия в конвейере CI: Частые точки комплаенса — жёстко закодированные пароли, открытые чувствительные поля, трансграничная передача данных, точки принятия алгоритмических решений — превращаются в обязательные шлюзы в GitHub Actions / GitLab CI. Pull Request от бизнес-команды автоматически запускает проверку, и при несоответствии — сразу fail, без ручного прогона со стороны комплаенс-представителя.
  2. Регуляторные требования как affordance (средовые ограничения): Например, при разработке функций, работающих с данными клиентов, плагин в IDE подсказывает: «Для этого поля рекомендуется вызов KMS»; при записи логов автоматически обнаруживается наличие чувствительной информации и выдаётся предупреждение. Комплаенс становится «естественным действием в процессе разработки», а не «уведомлением о нарушении перед релизом».
  3. Общая библиотека Skills + обучение комплаенсу: Комплаенс-команда поддерживает набор «комплаенс-Skills», который вызывается при онбординге новых сотрудников / переходе между командами — комплаенс-знания превращаются из «документации» в «исполняемый инструмент».

Типичный сценарий: региональный банк во втором полугодии 2026 года внедрил комплаенс-гейты в CI и подсказки в IDE, сократив среднее время на проверку AI-кода на соответствие с 45 минут до 8 минут на одну проверку. Суть не в том, что «проверка стала быстрее», а в том, что AI «не допускает ошибок» уже на этапе генерации.

5.3 Двухскоростной комплаенс: соответствие темпу бизнеса

Последняя деталь: комплаенс не должен быть «под одну гребёнку». Разделите правила на два уровня риска:

  • Правила высокого риска (связаны с клиентскими средствами / алгоритмическими решениями / трансграничной передачей данных / критическими требованиями безопасности) — строгий контроль: обязательная ручная проверка + повторное подтверждение ИИ + регистрация в Change Advisory Board (CAB)
  • Правила низкого риска (типовой CRUD-код / утилиты / генерация документации) — самообслуживание: достаточно автоматической проверки в CI, ручная проверка не требуется

Контрольная плоскость Agent 365 от Atos по сути и есть такое разделение — агенты разных уровней привязаны к разным требованиям управления. Когда правила комплаенса распределены по уровню риска, бизнес-команды чувствуют: «комплаенс — это не сплошные блокеры на каждом шагу».

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

Шесть. Возможные вопросы

«У нас уже есть стандарты кодирования. Чем это отличается?»

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

«Не замедлит ли написание спецификаций разработку?»

В краткосрочной перспективе — да, в долгосрочной — нет. Данные CodeRabbit дают однозначный ответ: дефекты в коде, написанном ИИ без ограничений, встречаются примерно в 1,7 раза чаще, а уязвимости — в 2,74 раза чаще. В финансовой отрасли одна итерация доработок по итогам комплаенс-проверки обходится в 2–4 недели — и одной предотвращённой такой итерации хватит, чтобы целый месяц писать спецификации. Экономия в 250 миллионов долларов у EY — это реальное доказательство того, что превращение этого процесса в организационную компетенцию работает.

«А если в нашей команде никто не умеет писать спецификации?»

Начинать с нуля не нужно. В GitHub Spec Kit, Claude Code Superpowers и AWS Kiro уже есть готовые шаблоны. Вам остаётся только добавить правила, специфичные для вашей организации — в основном это требования комплаенса и безопасности, которые ваши отделы комплаенса и ИБ давно сформулировали, просто не положили туда, где их мог бы увидеть ИИ.

«Инструментов ИИ так много — какой выбрать?»

Неважно. Беріть те, що вже використовуєте. Специфікації не прив’язані до інструментів — CLAUDE.md працює в Claude Code, Cursor і Codex; AGENTS.md працює в екосистемі OpenAI; constitution.md взагалі не залежить від моделі. Головне — писати специфікації, а не міняти інструменти. EY розгортає все в екосистемі Microsoft, Atos — теж у Microsoft. Різниця у виборі інструментів — лише зовнішня; уніфікована архітектура управління — ось що справді має значення.

«У серпні 2026 року EU AI Act набуде повної чинності. Чи це нас стосується?»

Да. EU AI Act вступает в полную силу 2 августа 2026 года и предъявляет обязательные требования к системам ИИ высокого риска — включая кредитование, страхование, отбор кандидатов на работу и критическую инфраструктуру. Речь идёт об управлении рисками (ст. 9), качестве данных (ст. 10), прозрачности документации (ст. 11–13), контроле со стороны человека (ст. 14) и точности/устойчивости системы (ст. 15). Штрафы достигают 35 млн евро или 7% глобальной выручки. Для китайских компаний, выходящих на европейский рынок, это обязательный экзамен. Но даже если вы работаете только внутри Китая, обойти EU AI Act не получится: это самый цитируемый регуляторный стандарт в мире, и его требования косвенно влияют на вас через поставщиков, партнёров и трансграничные операции (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

А что у нас? Китайский подход: регулируем не ИИ, а его применение

В Китае генеративный ИИ регулируется через три инструмента: регистрация алгоритмов (算法备案), проверка обучающих данных и оценка безопасности. Ключевой документ — «Временные меры по управлению генеративными сервисами ИИ», вступившие в силу в августе 2023 года. Главное различие между китайской и европейской системами — не в деталях, а в философии регулирования.

Аспект EU AI Act Китайские «Меры по управлению генеративными ИИ-сервисами»
Правовой статус Горизонтальный регламент (распространяется на все ИИ-системы) Вертикальные правила (фокус на генеративные ИИ-сервисы)
Классификация рисков 4 уровня (неприемлемый / высокий / ограниченный / минимальный) 2 уровня (затрагивающие общественную безопасность / общегражданское применение)
Момент регулирования Предварительный (регистрация ещё на этапе разработки) Последующий (регистрация после запуска + регистрация алгоритма)
Прозрачность Высокая (требуется публикация сводки об источниках обучающих данных, model card) Средняя (требуется соответствие данных требованиям, но раскрытие источников необязательно)
Верхний предел штрафов 7% глобальной выручки или 35 млн евро Приостановка сервиса / штраф (обычно кратно сумме незаконного дохода)
Сфера применения Все компании, превышающие порог глобальной выручки Все субъекты, предоставляющие услуги на территории Китая

На практике ИИ-системы финансовых организаций в Китае обычно одновременно регулируются тремя наборами правил — «Мерами по управлению генеративным ИИ» (базовый уровень) + «Мерами по управлению интернет-кредитованием коммерческих банков» (бизнес-уровень) + системой защиты информационной безопасности (等保, děngbǎo — китайский аналог ISO 27001) + алгоритмической регистрацией (уровень соответствия). Это означает, что при построении нормативной базы внутри страны нельзя механически копировать框架 EU AI Act — нужно заложить в CLAUDE.md все три китайские линии: «соответствие обучающих данных + регистрация алгоритмов + регуляторная отчётность».

Для компаний, выходящих на зарубежные рынки: четыре компонента EU AI Act — «управление рисками + управление данными + прозрачность документации + контроль со стороны человека» — это то направление, к которому постепенно движется и китайское регулирование. Уже в 2025 году несколько ответов на заявки по регистрации генеративного ИИ от Управления киберпространства Китая (CAC) заметно заимствовали гранулярность европейского подхода. Если сегодня писать нормативы, совместимые с EU AI Act, то с высокой вероятностью они будут совместимы и с ужесточением китайского регулирования в ближайшие 3 года (объявления CAC о регистрации 2025–2026; eu-ai-act compliance 2026.6).

7. Выводы для лиц, принимающих решения

Вывод первый: написать проектный регламент в виде CLAUDE.md/AGENTS.md — это инженерное действие с самой высокой окупаемостью в эпоху ИИ.

Вывод 2: Управляемость через стандарты — это организационная компетенция, а не выбор инструмента.

GitHub Spec Kit или Claude Code — не имеет значения. Важно, определили ли вы, как ваша организация взаимодействует с ИИ. Без этого даже лучший инструмент лишь позволит команде быстрее накапливать технический долг.

Вывод 3: Закладывайте стандарты в организационные процессы, а не полагайтесь на отдельных людей.

Если стандарты существуют только в голове одного опытного инженера, они будут утеряны при смене кадров. Их необходимо фиксировать в документации репозитория, CI-гейтах, общих конфигурациях команды и платформах управления агентами. Стандарты должны стать организационным активом, а не личным навыком. 19 000 агентов Atos работают в 54 странах именно потому, что управляемость — это не «кто-то разбирается», а «система принуждает».

Вывод 4: Гейты важнее скорости.

Пятиэтапные шлюзы GitHub Spec Kit, принцип Superpowers «не пиши код, пока тесты не упадут», требование Kiro «без spec не запустишь» — всё это про одно: поставить «тормоз» между ИИ и конечным результатом. Чем мощнее ИИ, тем раньше нужно включать управление. Те самые 78% инцидентов из отчёта New Relic 2026 — это цена того, что 62% команд «выкатывают без ревью». CIO из финансового сектора понимают это лучше всех: ваш Change Advisory Board, процедуры алгоритмического регулирования, аттестация по 6-уровневой системе защиты ФСТЭК (Приказ № 21/239) — всё это гейты перед продакшеном. Для ИИ-кода нужны такие же гейты, и они должны стоять ещё раньше.

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

Три вопроса для руководителя

Напоследок — три вопроса. Не чек-лист, а готовая основа для разговора с командой:

  1. “Якщо завтра всі інструменти ШІ зникнуть, насколько сильно снизится качество кода в вашей команде?” — этот вопрос вскрывает реальную ценность норм и стандартов: если ответ “значительно снизится”, значит, ваши регламенты ещё не устоялись; если ответ “почти не изменится” — вы уже на пути к управляемому через стандарты процессу.
  2. “В вашем проекте по внедрению норм и стандартов для ИИ-разработки — отдел комплаенс играет роль ‘контролёра’ или ‘помощника’ (enabler)?” — если ответ “контролёра”, ваша скорость упрётся в бюрократические барьеры на этапе согласований; если “помощника” — вы уже идёте по пути, описанному в разделе 5.2.
  3. “Через 12–18 месяцев как изменится размер вашей команды?” — согласно Microsoft WTI 2026, 82% руководителей планируют «расширять» штат за счёт ИИ-агентов. Если ваш ответ “никак”, то либо бизнес не растёт, либо ваша организационная структура не поспевает за выгодами от внедрения норм и стандартов.

Правильных ответов на эти три вопроса не существует. Но направление вашего ответа важнее, чем сам ответ.

Что дальше

Это шестая статья из цикла о трансформации разработки ПО в эпоху ИИ. Мы прошли путь от закона Конвея (структура организации определяет архитектуру) через Team Topologies (как проектировать саму организацию) к смещению узкого места (оно теперь в верификации, а не в написании кода). Сегодня мы говорим о том, как с помощью документации и стандартов направлять поведение ИИ-инструментов.

В седьмой части мы рассмотрим инфраструктуру, на которой всё это держится, — протокол MCP (Model Context Protocol). Почему открытый протокол от Anthropic называют «USB-C для ИИ», почему OpenAI, Google и Microsoft все последовали за ним, и как он делает возможной совместимость множества инструментов и мультиагентных систем.

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

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

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

  • Корпоративное обучение: на материале ваших реальных проектов — отработка структуры нормативных документов, проектирование CI-гейтов, маршрут внедрения комплаенса и построение механизмов управления.
  • Экспертный консалтинг: сфокусированная проработка одного конкретного решения, например «стоит ли нам начинать с CLAUDE.md / AGENTS.md» или приоритизация мероприятий по приведению унаследованного кода в соответствие с нормами.
  • Выступления для руководства и отраслевые доклады: темы — ИИ-инструменты программирования, нормативно-ориентированный подход, организационное управление и Frontier Firms.

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

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

О серии

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

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

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

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

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

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

  • CodeRabbit (2025.12). State of AI vs Human Code Generation Report. Проблемы в AI-коде встречаются в 1,7 раза чаще, чем в коде, написанном человеком (10,83 против 6,45 проблемы на PR), логика/корректность — в 1,75 раза, качество кода — в 1,64 раза, безопасность — в 1,57 раза, обработка паролей — в 1,88 раза, XSS — в 2,74 раза. Уровень доказательности: первый. Источник: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263

  • The Register (2025.12.17). Репортаж о полном отчете CodeRabbit: анализ 470 открытых PR, PR с участием AI содержат 10,83 проблемы против 6,45 у чисто ручных. Уровень доказательности: второй. Источник: тот же URL

  • CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — 2026 год станет переломным: фокус сместится со «скорости генерации кода» на «качество кода и управление». Уровень доказательности: второй. Источник: https://tfir.io/ai-code-quality-2026-guardrails

  • New Relic (2026). The 2026 State of AI Coding Report. 78% команд сообщают о росте числа инцидентов после внедрения AI-кода; 62% технических руководителей признают, что их команды «уверенно выкатывают код без ревью»; 96% считают наблюдаемость обязательным условием. Уровень доказательности: первый (отчёт вендора). Источник: https://newrelic.com/resources/report/2026-state-of-ai-coding

  • Microsoft 2026 Work Trend Index Annual Report (2026.5.5). Опрос 20 000 работников, использующих ИИ, в 10 странах; 82% руководителей планируют в течение 12–18 месяцев расширять штат за счёт ИИ-агентов; 81% ожидают умеренной или значительной интеграции ИИ-агентов; 24% уже внедрили их на корпоративном уровне; 49% диалогов с Copilot поддерживают когнитивную работу; 58% пользователей ИИ совершают «то, что было невозможно год назад», а среди Frontier Professionals этот показатель достигает 80%. Уровень доказательности: первый. Источник: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf

  • Обзор FY26 Microsoft: от экспериментов с ИИ к трансформации на переднем крае (28.07.2026). EY развернула Microsoft 365 Copilot для 150 000 сотрудников, что позволило сэкономить 2,5 млн часов и около 250 млн долларов; масштабирование на 400 000 сотрудников по всему миру дало ускорение на 95%, снижение затрат на финансовые операции на 37% и сокращение до 90% ручных рабочих процессов. Atos внедрила Copilot для 56 000 сотрудников в 56 странах, добавив 19 000 ИИ-агентов, с единой плоскостью управления для идентификации, безопасности, соответствия и управления. Уровень доказательности: первый (официальный обзор Microsoft). Источник: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Стратегическое партнёрство Atos Group и Microsoft (09.06.2026). Atos разворачивает Microsoft 365 E7 (Frontier Suite) для 56 000 сотрудников в 56 странах, а также 19 000 ИИ-агентов; единая плоскость управления на базе Entra/Defender/Intune/Purview/Agent 365. Уровень доказательности: первый (совместный пресс-релиз). Источник: https://news.microsoft.com/source/2026/06/09/atos-group-and-microsoft-expand-strategic-collaboration-to-scale-secure-agentic-ai-across-atos-group-workforce-and-clients

  • GitHub Spec Kit (открыт в сентябре 2025, развитие в H1 2026). Пятиэтапный процесс с гейтами /speckit.constitution → /specify → /plan → /tasks → /implement, плюс /clarify и /analyze; не привязан к конкретной модели (поддерживаются Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Уровень доказательности: первый. Источник: https://github.com/github/spec-kit

  • AWS Kiro (выпущен в июле 2025, развитие в H1 2026). Трёхэтапный рабочий процесс: требования → проектирование → задачи; spec запускает предопределённые действия агента; без написания spec работа невозможна. Уровень доказательности: первый. Источник: https://kiro.dev/

  • OpenAI Codex + AGENTS.md + Skills (2025–2026). Codex 2026.6 — более 5 млн еженедельных пользователей, из них 20% — не разработчики; AGENTS.md + Skills — комбинируемый набор инструкций. Уровень доказательности: первый (официальное объявление OpenAI). Источник: https://developers.openai.com/codex/skills

  • Claude Code (Anthropic, первое полугодие 2026). Система CLAUDE.md + .claude/rules/ + Skills; в феврале 2026 года появился в официальном маркетплейсе Anthropic; репозиторий Skills на GitHub — 112 тыс. звёзд; в феврале 2026 года в рамках раунда G раскрыта годовая выручка в размере 2,5 млрд долларов. Уровень доказательности: первый. Источник: https://code.claude.com/docs/en/claude-directory

  • JetBrains AI Pulse Survey (2026.1). Опрос более 10 000 профессиональных разработчиков по всему миру, локализован на 8 языках; Claude Code: CSAT 91% / NPS 54 (самый высокий показатель в отрасли); adoption rate Claude Code на рабочих местах — 18% (рост в 6 раз за 9 месяцев, с 3%), в Северной Америке — 24%; Copilot — 29% adoption на рабочих местах, но рост停滞; Cursor — 18%. Уровень доказательности: первый. Источник: https://www.jetbrains.com/lp/tools/ai-tools/

  • Pragmatic Engineer Newsletter (2026.2). Опрос 15 000 разработчиков; 46% назвали Claude Code «самым любимым инструментом», Cursor — 19%, Copilot — 9%. Уровень доказательности: первый. Источник: https://newsletter.pragmaticengineer.com/

  • Alibaba Qoder (2025.8 → 2026.7). Выпущен Alibaba в августе 2025 г.; 15.05.2026 Qoder 1.0 обновлён до Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; 28.05.2026 — Cloud Agents (управляемая среда выполнения агентов); 21.07.2026 — Qoder Security; май 2026 г. — более 5 млн пользователей по всему миру; интеграция с DingTalk CLI; 20.05.2026 — Tongyi Lima переименован в Qoder CN. Уровень доказательности: первый. Источники: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

  • vibecoding.app / thebcms.com / tfir.io (первая половина 2026 г.). Пятиэтапные команды Spec Kit, сравнительный обзор SDD-инструментов, нотация EARS. Уровень доказательности: второй (сторонние обзоры). Источник: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development

  • EU AI Act / Code of Practice (полное применение с 2 августа 2026 г.). Для высокорисковых ИИ-систем крайний срок соответствия — 2 августа 2026 г.; для существующих моделей GPAI — до 2 августа 2027 г.; штрафы до 35 млн евро или 7% глобальной выручки; ст. 9–15: управление рисками, управление данными, прозрачность документации, человеческий надзор, точность и устойчивость. Уровень доказательности: первичный (регламент + вторичный комплаенс-анализ). Источники: https://artificialintelligenceact.eu/code-of-practice-overview; https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide

  • Qodo State of AI Code Quality Report (2025). 44% проблем возникают из-за отсутствия контекста. Уровень доказательности: вторичный (отчёт вендора). Источник: https://www.qodo.ai/reports/state-of-ai-code-quality/

Методы AI: Уроки из практики

Введение

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

AI-технологии в телекоммуникациях

В телекоммуникациях AI-технологии используются для улучшения качества обслуживания клиентов, повышения эффективности работы сети и снижения затрат. Например, компания AT&T использует AI-технологии для анализа данных о работе сети и прогнозирования потенциальных проблем.

AI-технологии в финансовых услугах

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

AI-технологии в производстве

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

AI-технологии в электронной коммерции

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

Заключение

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

Ресурсы

Примечания

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