AI-native компания v2

Определение и границы #

Рабочее определение #

Авторское определение. AI-native компания — это организация, в которой ИИ встроен в операционную модель, а не добавлен как набор отдельных инструментов. Работа строится как управляемый цикл:

сигнал → решение → действие → проверка → обучение

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

Это определение не является термином из закона или стандарта. ISO/IEC 42001 описывает систему управления ИИ, NIST — управление риском, OECD — ответственность и прослеживаемость.

Ни один из этих источников не устанавливает нормативное определение AI-native компании. [ISO-IEC-42001-2023] [NIST-AI-RMF-1-0] [OECD-AI-accountability]

В определении важны пять частей.

1. Организация, а не модель. Результат зависит от процесса, данных, инструментов, прав, проверок и людей.
2. Операционная модель, а не число лицензий. ИИ включён в повторяемый способ создавать ценность.
3. Управляемый цикл, а не отдельный ответ. У цикла есть вход, решение, действие и наблюдаемый исход.
4. Явные полномочия, а не обещание послушания. Права задаются вне текста инструкции там, где ошибка может причинить существенный вред.
5. Обучение через контроль изменений, а не самопроизвольное изменение правил. Результаты и инциденты пополняют доказательства. Новое правило проходит проверку и получает версию.

Что определение исключает #

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

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

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

В первой версии руководства такая зависимость использовалась как сильный признак AI-native компании. В v2 этот тезис отвергнут. [V1-ch12]

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

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

Шесть принципов, на которых держится модель #

1. Результат важнее внедрения #

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

2. Механизм должен быть минимально достаточным #

Порядок выбора прост:

1. Убрать ненужный шаг процесса.
2. Проверить обычное правило или автоматизацию.
3. Использовать ИИ как советника.
4. Разрешить подготовку изменения для человека.
5. Разрешить ограниченное действие только после оценки риска.

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

3. Ответственность остаётся у людей и организации #

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

4. Самостоятельность следует за доказательствами #

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

5. Контекст и правила являются производственными активами #

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

6. Обучение не отменяет контроль изменений #

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

Когда ИИ не нужен #

Отказ от ИИ является нормальным решением в пяти случаях.

• Результат нельзя проверить до того, как ошибка причинит вред.
• Обычное правило покрывает задачу с меньшими расходами.
• Данных недостаточно, их происхождение неизвестно или использовать их нельзя.
• Процесс встречается настолько редко, что содержание системы дороже ручной работы.
• Цена и необратимость ошибки выше ожидаемой пользы от ускорения.

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

Два коротких примера #

Пример: обработка входящих обращений. ИИ классифицирует тему и предлагает ответ. Оператор проверяет текст и отправляет его.

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

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

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

Рабочая карточка главы #

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

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

Ответственный. Владелец результата процесса. В стартапе это обычно основатель или руководитель функции. В зрелой компании — владелец потока создания ценности с полномочиями менять процесс.

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

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

Показатели результата.

• время от входного сигнала до принятого результата;
• доля результатов, принятых без исправления;
• объём завершённой полезной работы;
• удовлетворённость получателя результата;
• полная стоимость одного принятого результата.

Показатели риска.

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

Типичные ошибки.

• выбирать модель до результата;
• считать активность сотрудников эффектом;
• присваивать системе ответственность;
• ставить целью A3;
• скрывать отсутствие исходных показателей красивой демонстрацией.

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

Чек-лист.

• Результат назван словами клиента или получателя.
• Есть один ответственный владелец и конкретный человек.
• Граница процесса и исключения записаны.
• Проверена возможность обойтись без ИИ.
• Действия ИИ отделены от решений человека.
• Названы исходные показатели и цена ошибки.
• Есть условие отказа или безопасной остановки.

Карта зрелости #

Карта зрелости оценивает конкретный процесс или поток создания ценности. Она не выставляет компании общий ранг и не превращает разные проблемы в одно удобное число.

Процесс оценивается по восьми измерениям. Они совпадают с восемью системами операционной модели:

1. ценность и портфель;
2. люди и полномочия;
3. контекст и память;
4. среда исполнения;
5. контур управления;
6. проверка и наблюдаемость;
7. поставка и эксплуатация;
8. управление и экономика.

Главный результат оценки — профиль из восьми баллов. Например: 3 / 2 / 2 / 1 / 1 / 2 / 2 / 1. Такой профиль показывает разрыв. Среднее значение 1,75 скрыло бы его и создало бы ложное чувство порядка.

Пять уровней #

Уровень 4 означает способность безопасно учиться. Он не означает работу без людей и не требует A3.

Что считать доказательством #

Балл засчитывается по артефакту, журналу, показателю или истории решений. Фраза «мы обычно так делаем» не является доказательством.

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

Правила выставления оценки #

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

Правило 2. Оценивать фактический процесс. Демонстрационная среда и планы на квартал не повышают оценку производственного процесса.

Правило 3. Не смешивать процессы. Хорошая проверка кода не компенсирует слабые права в поддержке клиентов.

Правило 4. Хранить ссылку на доказательство. Рядом с каждым баллом записывают адрес артефакта, владельца и дату проверки.

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

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

Блокирующие разрывы #

Некоторые разрывы нельзя сгладить сильными соседними измерениями.

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

Если обнаружен такой разрыв, команда сначала ограничивает права или возвращает действие человеку. Затем она исправляет основу.

Зрелость и самостоятельность — две разные оси #

Уровни A0–A3 описывают полномочия конкретного действия: от совета без действия на A0 до ограниченного цикла на A3. Канонические определения и обязательные условия каждого уровня приведены в главе 8.

Карта зрелости отвечает на вопрос: «Насколько процесс измерим и управляем?» Шкала A0–A3 отвечает на другой вопрос: «Какое действие система вправе выполнить сама?»

Связь между ними не монотонна. Процесс уровня 4 может оставаться на A0. Процесс уровня 2 не должен переходить на A2 только ради опыта. Доказанная зрелость создаёт условия для обоснованного решения, но не выдаёт право автоматически.

Как провести оценку за девяносто минут #

1. Владелец называет границы одного процесса и один результат.
2. Представители работы, технологий, безопасности и финансов собирают ссылки на доказательства.
3. Каждый сначала выставляет восемь оценок независимо.
4. Группа обсуждает только расхождения и отсутствие доказательств.
5. Для каждого балла записывают основание, а для каждого разрыва — владельца исправления.
6. Назначают дату следующего пересмотра и события для внеплановой оценки.

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

Условный пример #

Команда оценивает подготовку еженедельного прогноза поставок.

Ценность и портфель получают 3: прогноз используется, точность и задержка измеряются. Люди и полномочия получают 2: владелец есть, но исключения утверждают в переписке.

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

Команда не объявляет весь процесс уровнем 2. Она сохраняет профиль и сначала исправляет происхождение данных и согласования. Самостоятельная отправка прогноза не повышается: до исправления контекста действие остаётся A1.

Рабочая карточка главы #

Решение. Выбрать измерение с опасным или ограничивающим разрывом и определить следующий наблюдаемый уровень.

Минимальный механизм. Восемь оценок 0–4 со ссылками на доказательства. Без сводного рейтинга.

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

Артефакт. Карта зрелости с профилем, ссылками, блокирующими разрывами, владельцами действий и датой пересмотра.

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

Показатели результата.

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

Показатели риска.

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

Типичные ошибки.

• оценивать компанию целиком;
• усреднять восемь измерений;
• выдавать план за действующий механизм;
• повышать автономию вслед за баллом зрелости;
• использовать карту для премирования и тем самым поощрять завышение.

Различия маршрутов. Стартап оценивает первый цикл небольшой группой и хранит простые ссылки на документы. Зрелая компания оценивает сквозной поток с участием всех функций и отдельно фиксирует регулируемые участки. Форма одна; объём доказательств разный.

Чек-лист.

• Границы одного процесса записаны.
• Оценены все восемь измерений.
• У каждого балла есть ссылка и дата.
• Среднее не используется как статус.
• Блокирующие разрывы показаны отдельно.
• Зрелость не смешана с A0–A3.
• Назначены плановый и событийный пересмотры.

Первый управляемый цикл #

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

Начните с результата #

Подходящий первый процесс отвечает шести условиям.

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

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

Паспорт цикла #

До технической работы владелец заполняет паспорт.

Паспорт остаётся коротким. Подробные правила, наборы проверок и реестр данных хранятся отдельными версионируемыми артефактами.

Зафиксируйте исходный уровень #

Сравнение с ощущением почти всегда бесполезно. До пилота измерьте хотя бы один полный рабочий период или репрезентативную выборку.

Минимальный набор:

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

Исследование METR показало, что опытные разработчики в исследованной выборке с инструментами начала 2025 года работали медленнее, хотя ожидали ускорения.

Это не универсальный вывод о разработке. Это сильное напоминание измерять фактический эффект в своём классе задач. [METR-2025-experienced-developers]

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

Наблюдаемая связь не доказывает одинаковый причинный эффект для каждой компании, но поддерживает решение измерять весь процесс, а не скорость генерации. [DORA-2025-report] [DORA-2025-capabilities-model]

Разложите цикл по ролям #

Для каждого шага выберите один из четырёх исполнителей:

1. человек;
2. обычная программа;
3. ИИ без права действия;
4. ИИ с ограниченным правом действия.

Пример для обработки заявки:

Такое разложение обычно уменьшает область ИИ. Это полезный результат: меньше прав, контекста и вариантов поведения проще проверять.

Выберите самостоятельность для каждого действия #

Не назначайте один уровень всему агенту.

Для первого цикла A0 означает анализ без права действия, а A1 — подготовку изменения, которое отдельно применяет человек. A2 допускает только ограниченное обратимое действие. A3 относится к узкому циклу с защищёнными переходами.

Канонические определения и полный набор условий находятся в главе 8. Для первого пилота исходно выбирайте A0 или A1. Переход к A2 или A3 требует отдельного договора о самостоятельности и доказательств именно для этого действия.

Спроектируйте проверку до пилота #

Проверка должна отвечать на два вопроса.

1. Получился ли допустимый результат?
2. Был ли путь к нему допустимым?

Удачный ответ может скрывать обращение к запрещённому источнику, пропущенное согласование или лишнюю запись данных. Поэтому отдельно проверяйте итог и допустимость пути. [G1-D1-p22], The New SDLC With Vibe Coding_Day_1.pdf, с. 22.

В план входят:

• эталонные обычные случаи;
• пограничные и редкие случаи;
• намеренно вредоносные или вводящие в заблуждение входы;
• детерминированные запреты;
• выборочная независимая проверка человеком;
• пороги остановки;
• проверка отката и резервного режима.

Тесты, созданные той же системой, полезны, но не служат единственным доказательством для существенного риска. [G1-D5-p29], Day_5_v3.pdf, с. 29.

Проведите ограниченный пилот #

Пилот начинается на исторических данных или в режиме наблюдения. Затем ИИ помогает реальным пользователям без права необратимого действия. Только после серии проверок команда может расширить область.

У пилота заранее определены:

• число или период наблюдений;
• допустимые сегменты;
• запрещённые действия;
• дневной предел расходов;
• ответственный наблюдатель;
• порог ручного вмешательства;
• дата решения о продолжении.

Один красивый прогон не считается серией. Для вероятностной системы нужна повторяемая проверка, включая редкие сценарии. [G1-D3-p27], Agent Skills_Day_3.pdf, с. 27.

Завершите пилот решением #

Возможны четыре честных исхода.

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

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

Оставить на текущем уровне. A0 или A1 дают большую часть пользы без риска самостоятельного действия.

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

Остановка сохраняет знания: исходные показатели, набор случаев, причины отказа и условия возможного возврата.

Условный заполненный пример #

Процесс: подготовка ответа на типовой вопрос клиента.

Результат: оператор отправил точный ответ, соответствующий действующим правилам.

Сигнал: новое обращение в очереди поддержки.

Решение: определить тему, найти действующую статью и выбрать допустимый ответ.

Действие ИИ: сформировать черновик и ссылки на источники. Уровень A1.

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

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

Резерв: оператор отвечает по прежнему процессу.

Решение после пилота: сохранить A1, потому что отправка редких и чувствительных ответов требует человеческого решения. Зрелость процесса можно повышать через качество контекста и проверок без перехода на A2.

Рабочая карточка главы #

Решение. Запустить, изменить или остановить один ограниченный цикл на основании исходных и пилотных данных.

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

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

Артефакт. Паспорт первого цикла с приложенными исходными показателями, договором о самостоятельности и решением после пилота.

Критерий готовности. Команда может воспроизвести серию, сравнить её с исходным процессом, показать каждое действие и выполнить резервный сценарий.

Показатели результата.

• изменение времени цикла;
• изменение человеческого времени;
• доля принятых результатов;
• объём завершённой работы;
• полная стоимость принятого результата.

Показатели риска.

• ошибки по тяжести;
• нарушения маршрута или прав;
• доля ручных вмешательств;
• время до обнаружения;
• срабатывания остановки;
• максимальный ущерб одного действия.

Типичные ошибки.

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

Различия маршрутов. Стартап ограничивает первый цикл одной командой и использует существующие инструменты.

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

Чек-лист.

• Первый результат и получатель названы.
• Исходный уровень измерен до пилота.
• Каждый шаг назначен человеку, программе или ИИ.
• A0–A3 назначены конкретным действиям.
• Проверяются результат и ход действий.
• Есть редкие и вредоносные случаи.
• Пределы расходов и ущерба записаны.
• Откат и резервный режим испытаны.
• Дата решения и четыре возможных исхода согласованы.

Восемь систем операционной модели #

Операционная система компании (Company OS) — это восемь связанных управленческих систем. Они описывают, как организация выбирает ценность, даёт полномочия, исполняет работу, проверяет результат и учится.

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

Первая версия руководства предлагала шесть слоёв. Аудит показал, что такая схема смешивала технические компоненты и управленческие обязанности. V2 заменяет её восемью системами, у каждой из которых есть решение, владелец и доказательство. [V1-ch3]

1. Ценность и портфель #

Эта система отвечает на вопрос: какие результаты достойны инвестиций?

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

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

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

2. Люди и полномочия #

Эта система отвечает на вопрос: кто принимает решение, кто исполняет и кто отвечает за итог?

Для каждого значимого действия команда обозначает:

• владельца результата;
• инициатора;
• исполнителя;
• согласующего;
• проверяющего;
• роль, которая может остановить процесс.

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

Материалы OECD связывают ответственность и прослеживаемость со всем жизненным циклом ИИ. NIST отдельно рассматривает учётные записи и полномочия программных агентов.

Это поддерживает разделение ролей, но конкретная схема остаётся решением организации. [OECD-AI-accountability] [NIST-2026-agent-id]

Минимальный артефакт — карта полномочий человека и ИИ.

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

3. Контекст и память #

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

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

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

Минимальный артефакт — реестр источников контекста.

Проверка системы: можно ли для значимого вывода показать использованный источник, его версию и право доступа?

4. Среда исполнения #

Среда исполнения (execution harness) соединяет модель с инструкциями, навыками, инструментами, состоянием, порядком шагов, изоляцией и наблюдением.

Агентом в производственном смысле является вся эта составная система. Свойство модели нельзя переносить на систему без испытания. [G1-D1-p27], The New SDLC With Vibe Coding_Day_1.pdf, с. 27.

Минимальная среда содержит:

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

Рост числа инструментов может ухудшить выбор действия. Из этого не следует, что нужен второй агент. Сначала сузьте инструменты и контекст. [G1-D2-p18], Agent Tools & Interoperability_Day_2.pdf, с. 18.

Минимальный артефакт — версия состава среды с зависимостями.

Проверка системы: может ли другой участник воспроизвести тот же состав без личной сессии разработчика?

5. Контур управления #

Контур управления (control plane) задаёт служебные учётные записи, права, согласования, политики, секреты, пределы расходов и журнал действий.

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

Детерминированное ограничение следует закреплять программой. [G1-D3-p42], Agent Skills_Day_3.pdf, с. 42; [G1-D5-p27], Day_5_v3.pdf, с. 27.

Подключение по стандартному протоколу не создаёт доверия автоматически. Публичный сервер протокола контекста модели нужно проверить как кодовую зависимость и границу доверия до доступа к файлам или учётным данным. [G1-D2-p15] [G1-D2-p16]

Минимальный артефакт — договор о самостоятельности с матрицей прав.

Проверка системы: может ли система физически выполнить запрещённое действие, даже если инструкция просит этого не делать?

6. Проверка и наблюдаемость #

Эта система отвечает на вопросы: допустим ли результат, допустим ли путь и не ухудшается ли поведение?

Она объединяет обычные тесты, наборы оценочных проверок, проверку хода действий, трассировку вызовов инструментов, производственные показатели и разбор отклонений.

Журнал не обязан и не должен обещать доступ к скрытым рассуждениям модели. Достаточно записывать намерение, версии компонентов, входы в допустимом объёме, вызовы инструментов, согласования, состояния и результат.

Для расследования фиксируйте путь от намерения к вызовам инструментов и результату. [G1-D4-p24], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 24.

Минимальный артефакт — план проверок качества и схема наблюдения.

Проверка системы: можно ли воспроизвести существенный сбой и понять, какое действие, право или источник к нему привели?

7. Поставка и эксплуатация #

Эта система отвечает на вопрос: как изменение безопасно проходит от намерения до рабочей среды и как организация восстанавливается после сбоя?

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

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

Минимальный артефакт — маршрут выпуска с условиями для классов риска.

Проверка системы: кто и по какому сигналу остановит выпуск, откатит изменение и сообщит владельцу результата?

8. Управление и экономика #

Эта система отвечает на вопрос: остаётся ли процесс приемлемым по пользе, расходам, риску и требованиям?

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

ISO/IEC 42001 задаёт требования к системе управления ИИ, ответственности, целям, контролю и улучшению. NIST AI RMF предлагает функции управления, описания контекста, измерения и работы с риском.

Эти источники не предписывают архитектуру из восьми систем, но поддерживают управляемый жизненный цикл. [ISO-IEC-42001-2023] [NIST-AI-RMF-1-0]

Минимальный артефакт — совместный обзор результата, полной стоимости и риска.

Проверка системы: может ли руководитель показать, какую пользу купили расходы и какой остаточный риск принят?

Как системы образуют один цикл #

Представьте процесс подготовки предложения клиенту.

Ценность и портфель задают ожидаемое сокращение времени и уровень качества. Люди и полномочия оставляют цену и юридические условия за человеком. Контекст предоставляет актуальный каталог и правила.

Среда исполнения формирует черновик и вызывает расчёт. Контур управления запрещает менять скидку выше порога. Проверки сверяют расчёт и источники.

Поставка выпускает новую версию инструкции. Управление и экономика решают, окупается ли механизм.

Если убрать любую систему, проблема проявится в другом месте. Без контекста ответ устареет. Без полномочий система применит лишнюю скидку. Без экономики команда будет ускорять черновик, не зная стоимости его проверки.

Минимальная конфигурация первого цикла #

Первому процессу не нужны восемь платформ. Ему нужны восемь ответов.

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

Рабочая карточка главы #

Решение. Определить минимальную конфигурацию восьми систем для выбранного процесса и назвать два опаснейших разрыва.

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

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

Артефакт. Карта восьми систем с текущим состоянием, ссылками, разрывами и зависимостями.

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

Показатели результата.

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

Показатели риска.

• число систем без владельца;
• число личных учётных записей в производственном пути;
• доля правил без версии;
• число общих компонентов без подтверждённого потребителя;
• время восстановления после отказа зависимости.

Типичные ошибки.

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

Различия маршрутов. Стартап собирает минимальные механизмы вокруг одного цикла и избегает платформенной команды.

Зрелая компания наносит восемь систем на один сквозной поток, выявляет дублирование и согласует общие правила. Она не обязана немедленно заменять локальные компоненты.

Чек-лист.

• Все восемь систем нанесены на один процесс.
• Для каждой системы есть владелец и артефакт.
• Безопасность и наблюдение проходят через весь путь.
• Личные сессии не используются для производственных действий.
• Критические запреты закреплены вне инструкции к модели.
• Общие компоненты обоснованы повторившейся потребностью.
• Два опаснейших разрыва получили владельцев и срок.

Контекст, память и навыки #

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

Постоянный и оперативный контекст следует разделять и версионировать. [G1-D1-p16], The New SDLC With Vibe Coding_Day_1.pdf, с. 16.

Постоянный контекст #

Постоянный контекст меняется сравнительно редко и применяется ко многим задачам:

• цели и границы продукта;
• архитектурные решения;
• стандарты разработки;
• правила безопасности;
• определения показателей;
• допустимые источники;
• требования к выпуску;
• инструкция и примеры для повторяемой работы.

У постоянного контекста есть владелец, версия, дата действия и порядок изменения. «Постоянный» не означает вечный.

Оперативный контекст #

Оперативный контекст относится к текущей задаче:

• запрос пользователя;
• затронутые записи или файлы;
• свежие показатели;
• состояние процесса;
• результаты вызванных инструментов;
• история действий этой сессии;
• текущие согласования и ограничения времени.

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

Реестр источников #

Для каждого источника запишите:

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

Отбор контекста #

Рекомендация. Отбирайте контекст по решению, а не по принципу «всё, что помещается».

Для каждого фрагмента задайте четыре вопроса:

1. Какое решение он меняет?
2. Кто отвечает за его точность?
3. Насколько свежим он должен быть?
4. Можно ли показать, что система действительно его использовала?

Плотный релевантный контекст обычно полезнее большого неотобранного. Это практический принцип, а его состав и пределы нужно проверять на задачах команды. [G1-D1-p42], The New SDLC With Vibe Coding_Day_1.pdf, с. 42.

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

Память как управляемая запись #

Полезная память отвечает на один из трёх вопросов:

• что произошло;
• какое решение было принято и почему;
• что нужно проверить в следующий раз.

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

Для критического процесса запретите автоматическое превращение результата в правило. Система может предложить изменение.

Владелец проверяет его на наборе случаев, получает согласование и выпускает новую версию. Такой порядок принят и для изменений навыка. [G1-D3-p37], Agent Skills_Day_3.pdf, с. 37.

Навык агента #

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

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

Минимальная карточка навыка содержит:

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

Официальная спецификация Agent Skills описывает каталог, файл SKILL.md, метаданные и постепенную загрузку материалов. Соответствие формату не доказывает правильность или безопасность поведения. [AGENT-SKILLS-spec]

Постепенная загрузка #

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

Такая постепенная загрузка уменьшает постоянный контекст и делает выбор навыка наблюдаемым. [G1-D3-p10], Agent Skills_Day_3.pdf, с. 10.

Такой механизм создаёт отдельный объект проверки — маршрутизацию. Нужно узнать:

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

Как проверять навык #

Проверка навыка состоит из пяти частей.

1. Маршрутизация. Правильно ли распознаны условия применения и отказа?
2. Результат. Соответствует ли выход критериям задачи?
3. Ход действий. Использованы ли допустимые инструменты, порядок и права?
4. Расход. Как изменились время, контекст, вызовы и человеческая проверка?
5. Регрессии библиотеки. Не ухудшились ли соседние навыки?

Такой набор покрывает ошибки, которые не видны при проверке одного удачного ответа. [G1-D3-p20], Agent Skills_Day_3.pdf, с. 20.

SkillsBench и SWE-Skills-Bench показывают, что навыки можно оценивать на повторяемых наборах задач. Их результаты не переносятся автоматически в другую среду и не являются производственной сертификацией. [SKILLSBENCH-2026] [SWE-SKILLS-BENCH-2026]

Универсального порога «90 процентов» для всех навыков нет. Утверждение об отраслевом стандарте не имеет независимого основания. [G1-D3-p22], Agent Skills_Day_3.pdf, с. 22.

Внешние навыки и подключения #

Внешний навык может читать контекст, запускать программу и меняться независимо. Поэтому:

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

Поэтому внешний навык проверяют как кодовую зависимость. [G1-D3-p43], Agent Skills_Day_3.pdf, с. 43.

Условный пример #

Команда создаёт навык подготовки описания изменения.

Постоянный контекст содержит стандарт описания, классы риска и правила доказательств. Оперативный контекст содержит задачу, изменённые файлы, результаты тестов и список зависимостей. Навык готовит черновик, но не утверждает риск.

Владелец навыка — инженер по качеству процесса разработки.

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

Рабочая карточка главы #

Решение. Определить минимальный постоянный и оперативный контекст для одного решения, а повторяемую процедуру оформить как проверяемый навык.

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

Ответственный. Владелец процесса отвечает за достаточность. Владельцы данных подтверждают происхождение и доступ. Владелец навыка отвечает за версию и проверочный набор.

Артефакт. Реестр контекста и карточка навыка с версией, совместимостью и доказательствами проверки.

Критерий готовности. Для любого значимого результата можно восстановить версии постоянного контекста, оперативные источники и выбранный навык. Обновление можно проверить и откатить.

Показатели результата.

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

Показатели риска.

• доля источников без владельца;
• число устаревших правил в рабочем контексте;
• обращения к источникам вне разрешённой области;
• необъяснимые изменения маршрутизации;
• регрессии после обновления навыка;
• объём чувствительных данных в журналах и памяти.

Типичные ошибки.

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

Различия маршрутов. Стартап начинает с короткого реестра и одного общего навыка после подтверждения повторяемости.

Зрелая компания назначает владельцев доменов данных, правила свежести и совместимость библиотек навыков. Общая библиотека появляется после работающих локальных навыков.

Чек-лист.

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

Жизненный цикл разработки программного обеспечения с ИИ #

Эта глава связывает самостоятельность ИИ с маршрутом разработки и выпуском по риску. Определения A0–A3 и обязательные условия для каждого уровня приведены в разделе «Уровни A0–A3».

Жизненный цикл разработки программного обеспечения с ИИ (AI SDLC) нужен не для того, чтобы генерировать больше кода. Его задача — быстрее превращать согласованное намерение в небольшое проверенное изменение и сохранять контроль до и после выпуска.

Формальные спецификации, автоматические проверки и контрольные точки создают основу производственной разработки. Сам процесс не делает риск низким: нужны права, наблюдение, откат и оценка цены ошибки. [G1-D1-p13], The New SDLC With Vibe Coding_Day_1.pdf, с. 13.

1. Согласуйте намерение #

Короткая спецификация изменения отвечает на вопросы:

• какую проблему решаем;
• кто получит результат;
• что входит и не входит в работу;
• какие ограничения уже действуют;
• как проверить результат;
• что может сломаться;
• как откатить.

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

Спецификация в репозитории задаёт общее намерение, но не отменяет более точные ограничения кода, тестов и записей решений. [G1-D5-p8], Day_5_v3.pdf, с. 8.

2. Соберите постоянный и оперативный контекст #

Постоянный контекст содержит правила проекта. Оперативный — задачу, затронутые файлы, свежие данные и результаты инструментов.

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

3. Спланируйте небольшое изменение #

Небольшое изменение легче понять, проверить, рецензировать и откатить. План перечисляет:

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

Ускорение генерации может перенести часть ограничения в постановку, архитектуру и проверку. Это зависит от задачи и команды и не отменяет сложность реализации. [G1-D1-p19]

4. Создайте изолированную рабочую среду #

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

Минимальные ограничения:

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

Список разрешённых доменов не является достаточной защитой. Разрешённый ресурс может вернуть вредоносный материал или принять лишние данные. [G1-D4-p15], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 15.

Имена новых пакетов проверяют по происхождению и закрепляют по версии. Галлюцинация имени зависимости создаёт риск цепочки поставок. [G1-D4-p14], тот же материал, с. 14.

5. Реализуйте с явными зависимостями #

Среда фиксирует:

• модель и её режим;
• версию инструкции;
• навыки и вспомогательные материалы;
• доступные инструменты;
• внешние серверы;
• пределы прав и расходов;
• историю существенных действий.

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

6. Выполните обычные тесты и независимые проверки #

Обычные тесты проверяют детерминированные свойства. Набор оценочных проверок исследует вероятностное поведение. Оба вида нужны вместе. [G1-D5-p30], Day_5_v3.pdf, с. 30.

Проверки включают:

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

Успешная сборка и тесты являются нижней границей, но не полным доказательством. [G1-D4-p30], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 30.

Если система исправляет серьёзный дефект, она не должна незаметно ослабить воспроизводящий тест. Изменение такого теста получает отдельное обоснование и рецензию. Для обычной разработки тест можно менять, когда изменилось согласованное поведение. [G1-D4-p23]

7. Проверьте результат и ход действий #

Рецензент проверяет:

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

Для интерфейса проверяется отрисованный результат, управление с клавиатуры и поведение на нужных экранах. Исходный код не показывает все визуальные и интерактивные дефекты. [G1-D4-p36]

8. Подготовьте описание запроса на слияние #

ИИ может подготовить черновик. Автор изменения подтверждает его точность.

Обязательные поля:

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

ИИ может подготовить сводку, точки возможной поломки и оценку риска. Автор изменения отвечает за их точность. [G1-D5-p19], Day_5_v3.pdf, с. 19.

9. Выберите условия выпуска по риску #

Условное автоматическое слияние допустимо для заранее определённого низкого риска. Прохождение тестов само по себе не разрешает любой выпуск. [G1-D5-p20]

10. Наблюдайте после выпуска #

Команда заранее знает:

• какие показатели должны измениться;
• какие ошибки считать существенными;
• кто получает сигнал;
• когда выпуск останавливается;
• как откатить;
• сколько длится усиленное наблюдение.

Техническая успешность выпуска не заменяет проверку результата для пользователя. Если время сократилось, но выросла доля исправлений, эффект нужно считать целиком.

11. Превратите инцидент в улучшение #

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

Цепочка:

инцидент → воспроизведение → причина → исправление → проверка → обновление правила или контекста → наблюдение

Начинайте исправление с воспроизведения и сохраняйте подходящий случай как регрессионную проверку. [G1-D5-p14], Day_5_v3.pdf, с. 14.

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

Когда нужен MCP #

Протокол контекста модели (Model Context Protocol, MCP) стандартизует подключение контекста и инструментов. Проверенная на дату среза стабильная редакция — 2025-11-25. [MCP-2025-11-25]

Используйте MCP, если:

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

Не вводите MCP для одного простого внутреннего вызова, если прямой интерфейс дешевле и понятнее.

Формула N × M → N + M описывает сокращение числа интерфейсов, но не убирает адаптацию схем, авторизацию, семантику и эксплуатацию. [G1-D2-p13], Agent Tools & Interoperability_Day_2.pdf, с. 13.

Стабильное расширение централизованного управления доступом было объявлено 18 июня 2026 года. Оно решает часть авторизации и не заменяет проверку сервера, данных, действий и журналов. [MCP-2026-managed-auth]

Когда нужен A2A #

Протокол взаимодействия агентов (Agent-to-Agent, A2A) предназначен для связи автономных удалённых участников. Проверенный выпуск на дату среза — 1.0.0 от 12 марта 2026 года. Запись о 1.0.1 не подтвердилась. [A2A-1-0-0]

Используйте A2A, если участники:

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

Не используйте A2A только потому, что в схеме нарисовано два агента. Внутренней функции или инструменту часто хватает обычного вызова. A2A предназначен для распределённых специализированных участников. [G1-D2-p22]

Юридическая и управленческая ответственность не передаётся удалённому агенту вместе с задачей. [G1-D2-p23]

Когда нужен A2UI #

Протокол интерфейса от агента к пользователю (Agent-to-User Interface, A2UI) передаёт декларативное описание интерфейса, которое клиент отображает из доверенного каталога компонентов.

На дату среза текущая производственная версия — 0.9.1. Семейство 0.9 представлено 17 апреля 2026 года. Версия 1.0 остаётся кандидатом и не называется стабильной. [A2UI-0-9] [A2UI-0-9-1-current]

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

Декларативный каталог уменьшает поверхность атаки по сравнению с произвольным кодом, но не отменяет проверку схемы, данных, событий и прав действий. [G1-D2-p33]

Сгенерированную структуру нужно проверить по схеме до отображения и исполнения. [G1-D2-p40]

A2UI может передаваться через A2A, но не зависит от него архитектурно. Тезис об обязательной связи отвергнут. [G1-D2-p29]

Дерево выбора протокола #

1. Нужен только текстовый ответ? Верните текст.
2. Нужны структурированные данные? Используйте обычную схему данных.
3. Модель должна вызывать локальный инструмент? Начните с прямого ограниченного интерфейса.
4. Несколько клиентов подключаются к общим инструментам? Рассмотрите MCP.
5. Взаимодействуют независимые удалённые участники с длительными задачами? Рассмотрите A2A.
6. Пользователю нужен динамический интерфейс из доверенного каталога? Рассмотрите A2UI.
7. Для каждого «да» отдельно проверьте доверие, права, наблюдение, стоимость и резерв.

Протокол — вариант интерфейса. Он не заменяет операционную модель.

Рабочая карточка главы #

Решение. Установить маршрут от согласованного намерения до наблюдаемого выпуска для каждого класса риска.

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

Ответственный. Автор изменения отвечает за доказательства. Владелец компонента отвечает за выпуск. Владелец продукта подтверждает результат. Специалист по безопасности задаёт обязательные проверки для риска.

Артефакт. Версионируемая спецификация, план изменения, журнал проверок, описание запроса на слияние и план наблюдения.

Критерий готовности. Независимый рецензент может связать намерение, код, тесты, права, риск, выпуск и фактический результат. Откат воспроизводим.

Показатели результата.

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

Показатели риска.

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

Типичные ошибки.

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

Различия маршрутов. Стартап закрепляет простой маршрут для одного репозитория и класса изменений.

Зрелая компания согласует классы риска, общие доказательства и изолированные среды для сквозного потока. Она не навязывает один инструмент всем командам, если общий механизм ещё не доказан.

Чек-лист.

• Намерение и границы изменения согласованы.
• Постоянный и оперативный контекст разделены.
• Изменение мало и имеет точки остановки.
• Среда изолирована от личных и производственных секретов.
• Обычные тесты дополнены независимыми проверками.
• Результат и ход действий проверены.
• Описание изменения содержит доказательства и риск.
• Условия выпуска зависят от класса риска.
• Наблюдение и откат назначены до выпуска.
• Инцидент превращается в подходящее постоянное улучшение.
• MCP, A2A или A2UI выбраны только по задаче.

Проверки качества и наблюдение #

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

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

1. проверка до выпуска;
2. наблюдение в эксплуатации;
3. обновление постоянных проверок по результатам и инцидентам.

Начните с решения #

Перед созданием теста запишите, какое решение он изменит.

Плохая формулировка: «оценить качество ответов».

Рабочая формулировка: «решить, можно ли разрешить системе готовить ответы для сегмента X на A1 при доле критических фактических ошибок ниже согласованного порога и обязательной ссылке на источник».

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

Проверяйте составную систему #

Результат создаёт не модель в изоляции. Его создают:

• модель и её настройки;
• постоянный и оперативный контекст;
• инструкция;
• навыки;
• инструменты;
• порядок выполнения;
• права;
• проверки и обработка ошибок.

Проверка хода действий исследует составную систему «агент плюс навык», а не навык в отрыве от среды. [G1-D3-p24], Agent Skills_Day_3.pdf, с. 24.

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

Семь видов проверок #

1. Детерминированные проверки #

Они проверяют точные свойства:

• формат и схема;
• обязательные поля;
• арифметика;
• допустимый диапазон;
• отсутствие запрещённого действия;
• права доступа;
• сборка и тесты кода.

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

2. Эталонные примеры #

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

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

3. Проверка человеком #

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

Человеческая оценка тоже ошибается. Для существенного решения проверяют согласованность экспертов и сохраняют обоснование.

4. Проверка другой моделью #

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

Такую оценку калибруют по человеческим решениям и применяют там, где правил недостаточно. [G1-D4-p33], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 33.

5. Проверка хода действий #

Она исследует:

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

Хороший финальный результат не оправдывает запрещённый путь. И наоборот, не каждый иной порядок является ошибкой. План задаёт обязательные и запрещённые переходы, а остальное оценивает по результату и расходу.

6. Испытания безопасности #

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

OWASP перечисляет такие классы риска для агентных приложений. Перечень помогает искать угрозы, но не доказывает достаточность выбранных мер. [OWASP-AGENTIC-TOP10-2026]

Статический анализ, анализ зависимостей и испытания поведения покрывают разные ошибки. Их следует сочетать. [G1-D4-p32]

7. Проверка в эксплуатации #

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

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

Проверка результата #

Критерии результата зависят от процесса, но обычно охватывают:

• фактическую правильность;
• полноту;
• соответствие правилам;
• полезность получателю;
• своевременность;
• отсутствие запрещённых данных;
• возможность проверить источник;
• корректное действие в системе.

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

Проверка хода действий #

Наблюдаемость должна фиксировать внешне доступные события. Не обещайте чтение скрытых рассуждений модели.

Минимальная запись:

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

Для проверки хода задачи нужны наблюдаемые события и состояния, но не заявление о полном доступе к «мыслям» системы. [G1-D4-p35]

Показатели надёжности #

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

Сходимость всей сессии полезна, но она не скрывает опасный промежуточный шаг. [G1-D4-p37]

Сегменты важнее среднего #

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

• типу задачи;
• языку или рынку, если это влияет;
• источнику данных;
• уровню риска;
• версии модели и навыка;
• обычному и редкому случаю;
• автоматическому и ручному пути.

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

Как обнаруживать ухудшение #

Ухудшение может появиться после смены модели, данных, инструкции, инструмента или состава входов.

Используйте три сигнала:

1. повторный прогон постоянного набора;
2. производственные показатели по сегментам;
3. выборочная человеческая проверка свежих случаев.

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

Разбор ошибки #

Не записывайте «модель ошиблась» как корневую причину. Проверьте:

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

Гипотеза о том, что большинство сбоев агентов вызвано конфигурацией среды, в материалах Google не подтверждена репрезентативной выборкой. [G1-D1-p31], The New SDLC With Vibe Coding_Day_1.pdf, с. 31. Поэтому расследование не должно заранее выбирать виновника.

Рабочая карточка главы #

Решение. Определить достаточное доказательство для запуска, сохранения или расширения конкретного действия.

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

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

Артефакт. План проверок качества с версиями набора, шкалой, сегментами, порогами, журналом прогонов и решением.

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

Показатели результата.

• принятие результата по сегментам;
• время и объём завершённой работы;
• доля корректных отказов;
• согласованность независимых рецензентов;
• скорость превращения инцидента в постоянную проверку.

Показатели риска.

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

Типичные ошибки.

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

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

Чек-лист.

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

Полномочия, безопасность и устойчивость #

Безопасный процесс начинается с ясного разделения: ИИ-система получает права на действие, а люди и организация сохраняют ответственность за решение, границы и последствия.

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

Четыре роли в одном действии #

Для значимого действия запишите:

1. Инициатор — кто поставил цель.
2. Владелец результата — кто отвечает за итог и меняет границы.
3. Исполнитель — человек, обычная программа или ИИ-система.
4. Проверяющий или согласующий — кто независимо подтверждает допустимость.

При низком уровне риска один человек может совмещать роли. При высоком уровне риска выдачу права, выполнение и проверку разделяют.

Отдельная служебная учётная запись #

ИИ-система не должна наследовать полные права разработчика или оператора.

Служебная учётная запись позволяет:

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

NIST рассматривает отдельные учётные записи, полномочия и границы программных агентов. Это концептуальный материал, а не отраслевой норматив. [NIST-2026-agent-id]

Для рабочего процесса используйте отдельную наблюдаемую учётную запись с ограниченными делегированными правами. [G1-D4-p18], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 18.

Нулевые фоновые полномочия #

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

В записи права есть:

• разрешённое действие;
• ресурс и область;
• максимальный объём;
• срок;
• инициатор;
• основание;
• обязательная проверка;
• событие отзыва.

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

Политика вне инструкции #

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

Запрет закрепляют:

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

Контекст влияет на поведение, но не заменяет такую защиту. Тезис Google о контексте как новой границе безопасности отвергнут. [G1-D4-p10], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 10.

Модель угроз #

Минимальная модель угроз рассматривает:

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

NIST в аналитическом материале 2026 года рассматривает риски инструментов, идентичности, данных и действий. Сводка ответов не является окончательным стандартом, но помогает построить перечень вопросов. [NIST-2026-agent-security]

OWASP дополняет его открытой отраслевой моделью угроз. [OWASP-AGENTIC-TOP10-2026]

Изоляция #

Недоверенный код и инструмент запускаются в краткоживущей среде с минимальными правами и ограниченной сетью. [G1-D4-p13], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 13.

Изоляция проверяется действием:

• попыткой прочитать запрещённый файл;
• попыткой обратиться к закрытому адресу;
• превышением времени или памяти;
• попыткой использовать отсутствующий секрет;
• удалением среды и повторным чистым запуском.

Наличие контейнера в схеме не доказывает изоляцию.

Уровни A0–A3 #

Уровень назначается конкретному типу действия в конкретном процессе.

A0 — советует #

Система анализирует или готовит материал для чтения. Она не запускает действие и не подготавливает привилегированную операцию к немедленному выполнению.

Примеры: объяснить отклонение, предложить варианты, подготовить черновик отчёта.

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

A1 — подготавливает #

Система создаёт готовое изменение. Человек проверяет его и отдельно запускает применение.

Примеры: подготовить изменение кода, платёжное поручение, письмо, изменение прав.

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

Человек должен совершить осмысленное действие. Кнопка «подтвердить» без видимого содержания создаёт видимость контроля.

A2 — исполняет в заданных границах #

Система выполняет обратимые низкорисковые действия в ограниченном наборе систем.

Примеры: запустить тесты в изоляции, создать запрос на слияние, обновить метку внутренней записи.

Обязательные условия:

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

A3 — ведёт ограниченный цикл #

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

Обязательные условия:

• все условия A2;
• узкая и стабильная область;
• показатель надёжности по сегментам;
• постоянное наблюдение;
• автоматические условия остановки;
• ручной или ограниченный режим;
• подтверждённая история работы на A2;
• отдельное решение о каждом опасном переходе.

Универсального уровня «делай всё» нет.

Почему зрелость не повышает A автоматически #

Зрелость показывает способность управлять процессом. Автономия показывает право системы действовать.

Управляемая медицинская рекомендация может навсегда остаться на A0. Зрелая система подготовки платежа может оставаться на A1.

Процесс автоматического запуска тестов может работать на A2 уже при умеренной зрелости, если среда изолирована и действие не затрагивает рабочую систему.

Повышение A требует доказательств именно для действия. Общий балл процесса не подходит.

Договор о самостоятельности #

Перед A2 или A3 владелец подписывает рабочий договор:

Смена модели, ухудшение показателя или инцидент могут автоматически понизить уровень. Возврат требует нового доказательства.

Устойчивость #

Критический процесс должен пережить три класса отказа:

1. модель недоступна;
2. качество ухудшилось;
3. источник или инструмент недоступен либо скомпрометирован.

Варианты:

• ручной режим;
• обычная автоматизация;
• чтение без действия;
• сокращённая область;
• очередь до восстановления;
• безопасная остановка.

Резерв проверяют на практике. Документ «перейдём вручную» не доказывает, что люди, доступ и время действительно есть.

Правовая навигация #

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

Персональные данные в России #

Федеральный закон № 152-ФЗ устанавливает обязанности оператора при обработке персональных данных. Выводы о согласии, поручении обработки, трансграничной передаче и мерах защиты зависят от фактов. [RU-152-FZ]

С 1 июля 2025 года действуют изменения требований к первичной записи и хранению персональных данных граждан России.

Из этого не следует универсальное правило «использовать локальную модель по умолчанию». Архитектура зависит от роли организации, состава данных и операций. [RU-PD-localization-2025]

Вопросы для проверки:

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

Регламент ЕС об ИИ #

Регламент ЕС об ИИ использует риск-ориентированный подход и распределяет обязанности между участниками. Применимость зависит от роли и системы. [EU-AI-ACT-framework]

Разъяснения Европейской комиссии по статье 50 опубликованы 20 июля 2026 года. Требования прозрачности статьи 50 в общем случае начинают применяться 2 августа 2026 года.

Для отдельных ранее выпущенных систем, подпадающих под статью 50(2), действует переходный срок до 2 декабря 2026 года. [EU-AI-ACT-2026-transparency-guidelines] [EU-AI-ACT-timeline]

Проверьте:

• роль поставщика или пользователя системы;
• относится ли система к регулируемой категории;
• какие уведомления и маркировка нужны;
• какие записи и инструкции необходимо хранить;
• какой срок применим к конкретной системе.

Финансовый рынок России #

Банк России опубликовал 16 июня 2026 года рекомендации по безопасному применению ИИ на финансовом рынке. Они отражают отраслевые ожидания к риску, безопасности и контролю. Их нельзя автоматически переносить на организацию вне финансового рынка. [CBR-2026-safe-ai]

Рабочая карточка главы #

Решение. Назначить A0–A3 каждому действию и закрепить права, ответственность, остановку и резерв вне инструкции к модели.

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

Ответственный. Владелец результата принимает остаточный риск в пределах своих полномочий. Владелец безопасности проверяет меры. Владелец системы выдаёт права. Юрист определяет применимые требования.

Артефакт. Карта полномочий, реестр рисков и договор о самостоятельности для A2/A3.

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

Показатели результата.

• доля действий с явным владельцем;
• время выдачи и отзыва права;
• доля процессов с испытанным резервом;
• время восстановления;
• доля согласований, содержащих достаточно информации.

Показатели риска.

• чрезмерные или бессрочные права;
• производственные действия через личные учётные записи;
• попытки обхода политики;
• утечки и нарушения области данных;
• действия без журнала;
• превышения лимитов;
• время от сигнала до остановки.

Типичные ошибки.

• передавать ответственность системе;
• выдавать права агента через сессию сотрудника;
• держать запрет только в инструкции;
• считать контейнер доказательством изоляции;
• повышать A по зрелости процесса;
• делать согласование формальным;
• трактовать регуляторную ссылку как готовый юридический вывод.

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

Зрелая компания добавляет разделение обязанностей, централизованный отзыв и доказательства соблюдения требований. Обе начинают с минимальных прав.

Чек-лист.

• Инициатор, владелец, исполнитель и проверяющий различимы.
• У системы отдельная служебная учётная запись.
• Фоновые привилегированные права отсутствуют.
• Критические запреты действуют вне инструкции.
• Модель угроз охватывает данные, инструменты, память и действия.
• A0–A3 назначены конкретным операциям.
• Для A2/A3 подписан договор с пределами и остановкой.
• Резервный режим испытан.
• Применимые требования подтверждены профильными специалистами.

Экономика и полная стоимость результата #

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

Главная единица экономики — принятый результат. Это ответ, изменение, решение или действие, которое прошло критерий процесса и принесло пользу получателю.

Формула #

Для выбранного периода:

полная стоимость результата =
  модели и внешние сервисы
  + вычисления и хранение
  + разработка и сопровождение
  + подготовка и обновление данных
  + человеческая проверка и согласования
  + исправления и повторная работа
  + эксплуатация, наблюдение и безопасность
  + ожидаемая стоимость ошибок
  ------------------------------------------------
  число принятых результатов

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

Скорость написания кода не отражает полную экономику процесса. [G1-D1-p40], The New SDLC With Vibe Coding_Day_1.pdf, с. 40.

Сначала исходный процесс #

До ИИ измерьте тот же результат в текущем процессе:

• число принятых результатов;
• календарное и человеческое время;
• возвраты и исправления;
• прямые расходы;
• ошибки по тяжести;
• незавершённую работу;
• ограничения объёма.

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

Разделите постоянные и переменные расходы #

Постоянные или ступенчатые расходы:

• проектирование процесса;
• интеграции;
• набор проверок;
• безопасность;
• обучение команды;
• минимальная платформа;
• договоры и юридическая работа.

Переменные расходы:

• запросы к модели;
• вызовы инструментов;
• вычисления;
• хранение;
• человеческая проверка;
• повторные попытки;
• внешние услуги.

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

Считайте человеческое время #

Человек участвует до, во время и после ответа:

• формулирует задачу;
• подбирает контекст;
• ждёт;
• проверяет;
• исправляет;
• согласует;
• расследует ошибку;
• поддерживает правила.

Если инженер сэкономил десять минут генерации и потратил двадцать минут на проверку, эффект нельзя записать как экономию десяти минут.

Считайте качество вместе со скоростью #

Полезно разложить результат на четыре показателя:

1. время цикла;
2. человеческое время;
3. доля принятых результатов;
4. тяжесть ошибок.

Ускорение при росте исправлений может быть полезно, если общий расход снизился и риск приемлем. Оно может быть вредным, если незавершённая работа переместилась к рецензенту.

Считайте отказ и резерв #

В полную стоимость входят:

• содержание ручного или ограниченного режима;
• переключение при отказе;
• потеря времени во время недоступности;
• восстановление очереди;
• повторная проверка после возврата.

Резерв кажется лишним расходом до первого отказа. Для критического процесса он является частью продукта.

Считайте возможный ущерб #

Не все ошибки равны. Введите категории, например:

• косметическая;
• требующая повторной работы;
• влияющая на клиента;
• нарушающая права или договор;
• создающая существенный финансовый или безопасностный ущерб.

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

Сравнивайте варианты механизма #

Для одного результата сравните:

Более высокий A часто увеличивает расходы на контроль. Автоматизация применения не бесплатна.

Условный пример расчёта #

Это пример метода, а не факт о типовой компании.

За месяц процесс подготовил 1 000 черновиков. Получатели приняли 700. Расходы составили:

• 40 000 рублей на модели и сервисы;
• 60 000 рублей на инфраструктуру и сопровождение;
• 180 000 рублей человеческого времени проверки;
• 35 000 рублей повторной работы;
• 35 000 рублей оценённого ожидаемого ущерба и восстановления.

Полные расходы: 350 000 рублей. Стоимость принятого результата: 500 рублей.

Сравнивать её нужно со стоимостью принятого результата исходного процесса, а не с ценой одного запроса. Если исходный результат стоил 480 рублей, пилот пока не доказал экономию. Он может сохранить ценность по скорости или объёму, но это нужно показать отдельно.

Решение об инвестиции #

Раз в установленный период владелец выбирает:

• расширить объём;
• оставить процесс как есть;
• сузить область;
• заменить механизм более простым;
• пересмотреть цену или качество поставщика;
• остановить.

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

Границы выводов о производительности #

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

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

Вместе эти источники поддерживают локальное измерение, но не дают одного процента для вашей команды. [DORA-2025-report] [METR-2025-experienced-developers]

Утверждения Google «от идеи до агента за часы вместо недель» и «ИИ устранил узкое место производства кода» получили статус «Не доказано». [G1-D1-p39] [G1-D5-p36]

Рабочая карточка главы #

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

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

Ответственный. Владелец результата подтверждает объём и качество. Финансовый партнёр проверяет метод расходов. Технический владелец предоставляет потребление. Владелец риска оценивает последствия.

Артефакт. Таблица полной стоимости результата с источниками данных, допущениями, диапазонами и решением.

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

Показатели результата.

• полная стоимость принятого результата;
• время цикла;
• человеческое время;
• доля принятых результатов;
• доступный объём;
• ценность для получателя.

Показатели риска.

• стоимость исправлений;
• ожидаемый и максимальный ущерб;
• волатильность расхода;
• зависимость от одного поставщика;
• доля расходов без связи с результатом;
• стоимость и время резервного режима.

Типичные ошибки.

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

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

Чек-лист.

• Единица принятого результата определена.
• Исходный процесс измерен тем же способом.
• Постоянные и переменные расходы разделены.
• Человеческая проверка и исправления учтены.
• Ошибки разделены по тяжести.
• Резерв и отказ входят в расчёт.
• Допущения и диапазоны видны.
• Решение и дата следующего обзора записаны.

План стартапа: 30 и 90 дней #

Цель первых девяноста дней — доказать один управляемый цикл и подготовить основу для второго. Стартапу не нужна общая агентная платформа до повторяемой потребности.

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

Результат к 30-му дню #

К 30-му дню команда должна уметь показать:

• один выбранный результат и исходные показатели;
• паспорт цикла;
• ограниченную роль ИИ на A0 или A1;
• несколько разрешённых источников;
• набор обычных, редких и вредоносных случаев;
• расчёт расхода на принятый результат;
• решение продолжить, изменить или остановить.

Дни 1–5: выбрать цикл #

Кандидат с самым большим воображаемым эффектом не обязательно лучший. Первый цикл должен быстро дать честные данные.

Дни 6–10: измерить исходный процесс #

Если исходный процесс не измеряется, пилот откладывается. Сначала команда упрощает результат и сбор данных.

Дни 11–15: спроектировать минимальный механизм #

Дни 16–20: собрать проверки #

Дни 21–27: провести пилот #

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

Дни 28–30: принять решение #

Владелец проводит короткий обзор.

Артефакт дня 30 — подписанная запись решения с данными и следующей датой.

Результат к 90-му дню #

К 90-му дню первый процесс работает в ограниченной эксплуатации либо закрыт с ясной причиной. У общих активов есть владельцы и версии. Второй процесс выбран только после разбора повторяющейся потребности.

Дни 31–45: укрепить первый цикл #

Дни 46–60: ограниченная эксплуатация #

Переход на A2 возможен только для отдельного обратимого действия и только после выполнения условий главы 8. Часто A1 остаётся лучшим решением.

Дни 61–75: проверить повторяемость #

Дни 76–90: решить, что переносить #

Команда рассматривает второй процесс и сравнивает его потребности с первым.

Общий компонент появляется, если повторилась проблема. Второй процесс не должен копировать архитектуру первого целиком.

Команда на первые девяносто дней #

В маленьком стартапе один человек может совмещать роли, но названия решений всё равно разделяются.

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

Рабочая карточка главы #

Решение. За 30 дней решить судьбу первого пилота, а за 90 дней доказать ограниченную эксплуатацию и переносимость отдельных активов.

Минимальный механизм. Один цикл, существующие инструменты, A0/A1, общий набор проверок, отдельная учётная запись и еженедельное решение по данным.

Ответственный. Основатель отвечает за инвестицию и остановку. Владелец процесса отвечает за принятый результат.

Артефакт. План на 90 дней с владельцами, паспорт первого цикла, решение дня 30 и обзор дня 90.

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

Показатели результата.

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

Показатели риска.

• расходы сверх предела;
• критические ошибки;
• зависимость от одного сотрудника;
• личные права в рабочем пути;
• число непроверенных переносов;
• дни без решения при ухудшении.

Типичные ошибки.

• строить платформу в первые 30 дней;
• выбирать сразу несколько процессов;
• переходить на A2 ради демонстрации;
• не учитывать время основателя и эксперта;
• объявлять личную инструкцию общим активом;
• переносить компонент без повторной приёмки.

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

Чек-лист.

• Один процесс выбран и имеет владельца.
• Исходный уровень измерен до дня 10.
• Пилот ограничен A0/A1 до доказательств.
• Решение принято к дню 30.
• Личные инструкции переведены в версионируемые активы.
• Отдельная учётная запись действует до ограниченной эксплуатации.
• Резерв испытан.
• Экономика обновлена к дням 30, 60 и 90.
• Второй процесс выбран после подтверждения повторения.

План зрелой компании: 30, 90 и 180 дней #

Зрелая компания обычно начинает не с пустого места. У неё уже есть помощники, пилоты, поставщики, правила и теневое использование. Главная задача — связать их с одним сквозным потоком создания ценности и убрать опасные разрывы.

План не требует немедленной централизации. Общими становятся только правила, доказательства и компоненты, потребность в которых повторилась.

Результат к 30-му дню #

Организация выбирает один поток, показывает его исходное состояние и ограничивает опасные права.

Дни 1–10: инвентаризация #

Инвентаризация не должна задерживать выбор на месяцы. Достаточно найти существенные действия, данные и расходы.

Дни 11–20: выбрать сквозной поток #

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

Дни 21–30: оценить и ограничить #

Результат к 90-му дню #

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

Дни 31–45: спроектировать целевой цикл #

Дни 46–60: собрать проверки и права #

Дни 61–75: провести ограниченный выпуск #

Дни 76–90: закрепить минимальные общие правила #

Общими на этом этапе обычно становятся не продукты, а требования:

• отдельная служебная учётная запись;
• происхождение контекста;
• минимальные события журнала;
• классификация риска изменений;
• описание доказательств выпуска;
• порядок остановки и разбора инцидента.

Результат к 180-му дню #

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

Дни 91–120: стабилизировать #

Дни 121–150: перенести подтверждённое #

Дни 151–180: принять портфельное решение #

Что может стать общим компонентом #

После повторения организация может централизовать:

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

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

Управление портфелем #

Раз в квартал или при существенном событии руководящий комитет рассматривает каждый производственный сценарий:

• результат относительно исходного уровня;
• полную стоимость;
• профиль зрелости;
• действующие A0–A3;
• серьёзные ошибки и инциденты;
• зависимость от поставщиков;
• применимые требования;
• решение расширить, сохранить, сузить или закрыть.

Квартал — рекомендуемая начальная частота, а не обязательный норматив. Высокий риск или быстрые изменения требуют более частого просмотра.

Рабочая карточка главы #

Решение. За 30 дней выбрать поток и закрыть опасные права, за 90 дней запустить управляемый участок, за 180 дней перенести только доказанные механизмы.

Минимальный механизм. Инвентаризация, карта потока, профиль зрелости, паспорт цикла, общие обязательные правила, маршрут разработки с ИИ и портфельный обзор.

Ответственный. Исполнительный куратор даёт полномочия. Владелец потока отвечает за результат. Владельцы восьми систем отвечают за механизмы. Руководящий комитет принимает портфельные решения.

Артефакт. План на 180 дней, карта потока, профиль зрелости, договор цикла и обзоры дней 30, 90 и 180.

Критерий готовности. Один поток показывает измеримый результат и управляемый риск. Второй потребитель отдельно принял переносимый компонент. Платформенное решение имеет доказанную потребность.

Показатели результата.

• результат сквозного потока;
• время между функциями;
• стоимость принятого результата;
• время от изменения до проверенного выпуска;
• повторное использование после приёмки;
• число закрытых опасных разрывов.

Показатели риска.

• сценарии без владельца;
• личные или чрезмерные права;
• неизвестные потоки данных;
• общие компоненты без владельца сервиса;
• время восстановления;
• сценарии без актуального правового разбора;
• концентрация поставщика.

Типичные ошибки.

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

Различия маршрутов. Этот план предназначен зрелой компании. Стартап использует укороченный путь главы 10.

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

Чек-лист.

• Реестр существенных сценариев собран к дню 10.
• Сквозной поток выбран к дню 20.
• Профиль зрелости и права проверены к дню 30.
• Один участок выпущен ограниченно к дню 75.
• Общие правила и маршрут разработки действуют к дню 90.
• Резерв и инцидент отработаны к дню 120.
• Второй участок повторно принял компонент к дню 150.
• Портфельное и платформенное решения приняты к дню 180.

Практический комплект и следующий шаг #

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

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

1. Паспорт цикла с ИИ #

Когда нужен: перед первым пилотом и при изменении границ.

Кто отвечает: владелец результата.

Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.

# Паспорт цикла: [название]
Получатель и принятый результат:
Сигнал:
Решение:
Действие:
Проверка результата:
Проверка хода:
Обучение и порядок изменения правил:
Владелец:
Роль человека:
Роль обычной программы:
Роль ИИ:
Исключения:
Исходные показатели:
Максимальный ущерб:
Резерв:
Дата решения после пилота:

Короткий пример: система готовит ответ на A1; оператор проверяет источник и отправляет; редкие претензии всегда уходят старшему специалисту; резерв — прежняя очередь.

Критерий готовности: каждый шаг цикла имеет исполнителя, проверку и границу.

2. Карточка сценария применения #

Когда нужна: при выборе и сравнении инвестиций.

Кто отвечает: предложивший сценарий вместе с владельцем результата.

Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.

# Сценарий: [название]
Получатель:
Проблема:
Принятый результат:
Частота и объём:
Исходный уровень:
Более простой механизм:
Предлагаемая роль ИИ:
Цена ошибки и обратимость:
Нужные данные:
Ожидаемая польза:
Полная стоимость:
Гипотезы:
Условие остановки:
Решение и дата:

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

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

3. Карта полномочий человека и ИИ #

Когда нужна: до доступа к рабочей системе и при повышении A.

Кто отвечает: владелец результата; владелец системы подтверждает фактические права.

Сокращённый пример формы. Полная форма с ценой ошибки, условием остановки и резервом — в Markdown.

# Полномочия: [процесс]
| Действие | Инициатор | Владелец результата | Исполнитель | A0–A3 | Согласующий | Проверяющий | Техническое право | Остановка |
|---|---|---|---|---:|---|---|---|---|
| | | | | | | | | |

Короткий пример: создать запрос на слияние | разработчик | владелец компонента | ИИ-система | A2 | не требуется | разработчик | только ветка задачи | три сбоя проверки.

Критерий готовности: организационная ответственность и техническое исполнение различимы; уровень назначен действию.

4. Реестр источников контекста #

Когда нужен: до передачи внутренних данных и при смене источника.

Кто отвечает: владелец данных; владелец процесса подтверждает пригодность.

Сокращённый пример формы. Полная форма с резервным сценарием на случай недоступности источника — в Markdown.

# Реестр контекста: [процесс]
| Источник | Владелец | Происхождение | Разрешённое использование | Чувствительность | Свежесть | Версия/время | Доступ | Отзыв | Проверка |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

Короткий пример: каталог продукта; владелец — коммерческий директор; обновление ежедневно; только подготовка предложения; чтение служебной ролью; отключение через группу доступа.

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

5. Навык агента #

Когда нужен: когда одна процедура повторилась и должна работать у нескольких участников.

Кто отвечает: владелец навыка.

Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.

# Навык: [название]
Версия:
Владелец:
Назначение:
Применять, когда:
Не применять, когда:
Вход:
Выход:
Разрешённые инструменты:
Предел полномочий:
Порядок действий:
Обычный пример:
Пограничный пример:
Проверки результата:
Проверки хода:
Совместимость:
Порядок отключения:
Журнал изменений:

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

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

6. План проверок качества #

Когда нужен: до пилота, выпуска и повышения полномочий.

Кто отвечает: владелец качества вместе с владельцем результата.

Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.

# План проверок: [система и версия]
Решение, которое принимает проверка:
Состав системы:
Сегменты:
Обычные случаи:
Пограничные случаи:
Редкие случаи:
Вредоносные случаи:
Детерминированные правила:
Человеческая выборка:
Проверка другой моделью и калибровка:
Проверка хода:
Показатели:
Порог предупреждения:
Порог остановки:
Резерв:
Результат прогона:
Решение:

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

Критерий готовности: набор воспроизводим, пороги заданы заранее, решение следует из результата.

7. Реестр рисков #

Когда нужен: с первого производственного использования и при существенном изменении.

Кто отвечает: владелец результата; владельцы мер подтверждают выполнение.

Сокращённый пример формы. Полная форма с ценой ошибки, реакцией и резервом — в Markdown.

# Реестр рисков: [процесс]
| Риск | Причина | Последствие | Затронутые лица | Вероятность/неопределённость | Тяжесть | Предотвращение | Обнаружение | Реакция | Владелец | Остаточный риск | Пересмотр |
|---|---|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | | | |

Короткий пример: устаревшая цена приводит к неверному предложению; предотвращение — источник не старше суток; обнаружение — сверка расчёта; реакция — блокировка отправки.

Критерий готовности: каждый существенный риск имеет предотвращение, обнаружение, реакцию и владельца.

8. Договор о самостоятельности #

Когда нужен: перед A2 и A3, а также после инцидента или смены модели.

Кто отвечает: владелец результата; владельцы безопасности и системы подтверждают ограничения.

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

# Договор о самостоятельности: [действие]
Уровень A:
Разрешённые действия:
Разрешённые системы:
Владелец результата:
Служебная учётная запись:
Максимальный ущерб одного действия:
Обратимость и срок отката:
Обязательные проверки:
Предел расходов:
Предел времени:
Предел числа действий:
Обязательные согласования:
События журнала:
Условия остановки/понижения:
Ручной или ограниченный режим:
Доказательства стабильной работы:
Дата и события пересмотра:

Короткий пример: A2 разрешает создать запрос на слияние только в ветке задачи; запрещает слияние; предел — один запрос и 20 минут; остановка — любая попытка изменить защищённую ветку.

Критерий готовности: технические права соответствуют тексту, а остановка и откат испытаны.

9. Описание изменения с ИИ #

Когда нужно: для изменения, подготовленного или существенно изменённого ИИ.

Кто отвечает: автор изменения.

Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.

# Изменение: [краткая цель]
Спецификация:
Результат для пользователя:
Что изменено:
Что намеренно не изменено:
Затронутые данные и права:
Новые зависимости:
Выполненные проверки и ссылки:
Проверка отрисованного результата:
Риск и точки возможной поломки:
Известные ограничения:
Откат:
Наблюдение после выпуска:
Что подготовил ИИ:
Что независимо проверил человек:

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

Критерий готовности: каждое заявленное доказательство существует, риск и откат понятны независимому рецензенту.

10. Инцидент → улучшение проверки #

Когда нужен: после серьёзного или повторяющегося сбоя.

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

Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.

# Разбор инцидента: [идентификатор]
Наблюдаемый ущерб:
Время обнаружения и ограничения:
Версии системы:
Воспроизведение:
Последовательность внешних событий:
Причина:
Содействующие условия:
Почему проверки не остановили:
Исправление:
Новая постоянная проверка:
Изменение прав/контекста/процесса:
Владелец:
Срок:
Подтверждение:

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

Критерий готовности: сбой воспроизводится до исправления и не воспроизводится после; выбранный механизм закрывает причину.

11. Полная стоимость результата #

Когда нужна: до пилота, при решении о продолжении и при существенном изменении объёма или поставщика.

Кто отвечает: финансовый партнёр и владелец результата.

Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.

# Полная стоимость: [процесс, период]
Принятый результат:
Количество принятых результатов:
Исходный процесс:

Модели и внешние сервисы:
Вычисления и хранение:
Разработка и сопровождение:
Данные:
Человеческая проверка:
Исправления:
Эксплуатация и безопасность:
Ожидаемая стоимость ошибок:
Резерв:

Итого:
Стоимость принятого результата:
Диапазон неопределённости:
Неучтённые факторы:
Решение:
Дата пересмотра:

Короткий пример: 350 000 рублей расходов и 700 принятых результатов дают 500 рублей на результат; это условный пример из главы 9, а не отраслевой ориентир.

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

12. План стартапа на 30 и 90 дней #

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

Кто отвечает: основатель отвечает за инвестицию и остановку; владелец процесса — за действия команды и принятый результат.

Сокращённый пример формы. Полная форма с этапами, резервом и решениями дня 30 и дня 90 — в Markdown.

# План стартапа: [процесс]
Основатель:
Владелец процесса:
Цель и границы:
Исходный профиль и показатели:

| Горизонт | Действие | Владелец | Артефакт | Критерий завершения |
|---|---|---|---|---|
| Дни 1–30 | | | | |
| Дни 31–90 | | | | |

Условия остановки:
Резервный сценарий:
Решение дня 30:
Решение дня 90:

Короткий пример: к дню 30 команда измеряет и ограничивает первый цикл; к дню 90 решает, переносить ли подтверждённый механизм во второй сценарий.

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

13. План зрелой компании на 30, 90 и 180 дней #

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

Кто отвечает: исполнительный куратор задаёт полномочия; владелец потока отвечает за результат; руководящий комитет принимает портфельные решения.

Сокращённый пример формы. Полная форма с этапами, повторной приёмкой, резервом и тремя решениями — в Markdown.

# План зрелой компании: [поток]
Исполнительный куратор:
Владелец потока:
Цель и границы:
Исходный профиль и показатели:

| Горизонт | Действие | Владелец | Артефакт | Критерий завершения |
|---|---|---|---|---|
| Дни 1–30 | | | | |
| Дни 31–90 | | | | |
| Дни 91–180 | | | | |

Условия остановки:
Резервный сценарий:
Решение дня 30:
Решение дня 90:
Решение дня 180:

Короткий пример: к дню 30 компания выбирает поток и ограничивает права; к дню 90 проводит ограниченный выпуск; к дню 180 проверяет общий компонент во втором потоке и решает, масштабировать ли его.

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

Короткий глоссарий #

AI-native компания — авторский термин для организации, где ИИ встроен в управляемый цикл операционной модели.

Агент — модель вместе со средой, состоянием, инструментами, обратной связью и ограничениями.

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

Постоянный контекст — общие правила, архитектура, стандарты и ограничения.

Оперативный контекст — данные и история текущей задачи.

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

Среда исполнения — состав моделей, инструкций, навыков, инструментов, порядка выполнения и изоляции.

Контур управления — учётные записи, права, согласования, политики, секреты и журнал действий.

Проверка хода действий — проверка использованных источников, инструментов, прав, шагов и согласований.

Полная стоимость результата — все расходы и ожидаемый ущерб, разделённые на число принятых результатов.

Резервный сценарий — заранее испытанный способ продолжить или безопасно остановить процесс при отказе.

Следующий шаг #

Не заполняйте весь комплект сразу.

1. Назовите один процесс.
2. Заполните карточку сценария и паспорт цикла.
3. Измерьте исходный уровень.
4. Проведите карту зрелости.
5. Закройте один блокирующий разрыв.
6. Составьте план проверок.
7. Запустите ограниченную серию на A0 или A1.
8. Через заранее заданный срок примите решение.

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

Рабочая карточка главы #

Решение. Выбрать минимальный набор форм для ближайшего решения и отказаться от документов без владельца.

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

Ответственный. Владелец процесса ведёт комплект. Каждый профильный владелец подтверждает свой раздел.

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

Критерий готовности. По комплекту можно восстановить решение, исполнителя, доказательство, риск и следующий момент проверки.

Показатели результата.

• время от идеи до решения;
• доля форм, использованных в реальном обзоре;
• доля решений со ссылкой на доказательство;
• время обновления после события;
• повторное использование без потери смысла.

Показатели риска.

• формы без владельца;
• противоречащие версии;
• пустые обязательные поля;
• секреты и лишние персональные данные;
• планы без критериев завершения;
• права без договора.

Типичные ошибки.

• заполнять все формы ради полноты;
• копировать пример как факт;
• хранить доказательство только в переписке;
• допускать разные названия одного процесса;
• не обновлять связанные артефакты после смены границы;
• считать подпись доказательством работающего механизма.

Различия маршрутов. Стартап хранит короткие формы рядом с рабочим процессом. Зрелая компания связывает их с системами управления документами и контролем доступа. Одинаковая структура облегчает сравнение, но объём доказательств соответствует риску.

Чек-лист.

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

Источники и стандарт доказательности #

Иерархия источников #

Руководство использует пять уровней:

1. законы, регуляторы, официальные стандарты и спецификации;
2. независимые исследования и испытания с раскрытой методологией;
3. описания промышленной практики и технические материалы поставщиков;
4. случаи отдельных компаний;
5. авторская практика и гипотезы.

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

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

Регуляторные ссылки помогают найти норму и сформулировать вопрос профильному специалисту. Они не заменяют юридический анализ конкретной системы.

Материалы проверены на 24 июля 2026 года. Более поздние источники в эту версию не включены.

Первая версия #

Первая версия проверена по локальному ai_native_book/v1/index.html. Идентификаторы V1-ch1…V1-ch12 соответствуют прежним главам #ch1…#ch12.

Локальный корпус Google #

Проверено пять PDF, 241 страница. Файлы использовались как исследовательский материал и не публикуются.

Статусы:

• Принять — использовать без существенного изменения смысла;
• Адаптировать — сохранить идею и добавить границы;
• Отвергнуть — не включать как рекомендацию;
• Не доказано — оставить гипотезой либо не использовать.

День 1: новый жизненный цикл разработки #

День 2: инструменты и взаимодействие #

День 3: навыки агентов #

День 4: безопасность и проверки #

День 5: разработка по спецификации #

Не принятые универсальные утверждения #

Следующие формулы не используются как факты:

• «генерация кода решена»;
• «код стал одноразовым»;
• «большинство сбоев вызвано средой»;
• «от идеи до готового агента всегда можно дойти за часы»;
• «90% — отраслевой порог навыка»;
• «многоагентная архитектура нужна по умолчанию»;
• «A2A нужен для любой кооперации»;
• «контекст является достаточной границей безопасности»;
• «тесты той же системы достаточны для автоматического выпуска»;
• универсальный процент прироста производительности.

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

Исследования и промышленная практика #

GOOGLE-2026-five-day-agents #

Тип источника

технические материалы поставщика

Опубликовано

2026-06

Проверено

2026-07-24

Ограничение

авторские рекомендации Google и отдельные кейсы не доказывают универсальные архитектурные или экономические правила

Google, пять локальных материалов курса 5-day-agents, июнь 2026 года. Проверено 24 июля 2026 года.

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

GOOGLE-SRE-2026-agentic-ai #

Тип источника

описание промышленной практики поставщика

Опубликовано

2026-05-29

Проверено

2026-07-24

Ограничение

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

Google Cloud, How Google SRE is using agentic AI to improve operations, 29 мая 2026 года. Проверено 24 июля 2026 года. Это описание практики одной организации; исходные условия нельзя переносить автоматически.

GOOGLE-RESEARCH-secure-agents #

Тип источника

исследовательский материал поставщика

Опубликовано

дата на странице не зафиксирована в спецификации

Проверено

2026-07-24

Ограничение

подход отражает архитектуру и терминологию Google; конкретные механизмы требуют независимой проверки в среде читателя

Google Research, An Introduction to Google’s Approach for Secure AI Agents. Проверено 24 июля 2026 года. Материал поддерживает многоуровневую защиту и минимальные полномочия, но отражает архитектуру Google.

DORA-2025-report #

Тип источника

исследование с раскрытой методологией

Опубликовано

2025

Проверено

2026-07-24

Ограничение

наблюдаемые связи не доказывают одинаковый причинный эффект для каждой компании

Google Cloud DORA, State of AI-assisted Software Development 2025, 2025 год. Проверено 24 июля 2026 года. Исследование с раскрытой методологией связывает результаты ИИ с возможностями команды. Наблюдаемая связь не гарантирует одинаковый причинный эффект.

DORA-2025-capabilities-model #

Тип источника

исследовательская модель возможностей

Опубликовано

2025

Проверено

2026-07-24

Ограничение

модель возможностей не является нормативной шкалой зрелости AI-native компании

Google Cloud DORA, DORA AI Capabilities Model, 2025 год. Проверено 24 июля 2026 года. Модель показывает роль внутренних платформ, процессов, пользовательского фокуса и обратной связи. Она не является нормативной картой зрелости AI-native компании.

METR-2025-experienced-developers #

Тип источника

независимое контролируемое исследование

Опубликовано

2025-07-10

Проверено

2026-07-24

Ограничение

выборка, инструменты и задачи исследования не описывают всю разработку программного обеспечения

METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10 июля 2025 года. Проверено 24 июля 2026 года. Независимое контролируемое исследование поддерживает локальное измерение эффекта. Его выборка и инструменты не описывают всю разработку.

METR-2026-frontier-risk #

Тип источника

независимое исследование и оценка риска

Опубликовано

2026-05-19

Проверено

2026-07-24

Ограничение

оценки передовых моделей не заменяют анализ конкретного процесса, прав и цены ошибки

METR, Frontier AI Risk Report, 19 мая 2026 года. Проверено 24 июля 2026 года. Исследование поддерживает проверку возможностей и опасного поведения перед расширением самостоятельности. Оно не заменяет оценку конкретного процесса и прав.

SKILLSBENCH-2026 #

Тип источника

исследовательская работа и бенчмарк

Опубликовано

2026-02

Проверено

2026-07-24

Ограничение

результат бенчмарка не гарантирует качество навыка в другом агенте, контексте или производственной среде

Авторы SkillsBench, SkillsBench, февраль 2026 года. Проверено 24 июля 2026 года. Работа показывает возможность повторяемой оценки навыков. Результат не переносится автоматически в другую среду.

SWE-SKILLS-BENCH-2026 #

Тип источника

исследовательская работа и бенчмарк

Опубликовано

2026-03

Проверено

2026-07-24

Ограничение

бенчмарк покрывает ограниченный набор задач и не является производственной сертификацией

Авторы SWE-Skills-Bench, SWE-Skills-Bench, март 2026 года. Проверено 24 июля 2026 года. Работа поддерживает отдельную оценку навыков разработки и воспроизводимости. Она не является производственной сертификацией.

Управление, риск и безопасность #

ISO-IEC-42001-2023 #

Тип источника

официальный международный стандарт

Опубликовано

2023-12

Проверено

2026-07-24

Ограничение

стандарт не определяет термин AI-native и не предписывает архитектуру агентной системы

ISO и IEC, ISO/IEC 42001:2023, декабрь 2023 года. Проверено 24 июля 2026 года. Стандарт задаёт требования к системе управления ИИ, ответственности, целям, контролю и улучшению. Он не определяет AI-native и не предписывает агентную архитектуру.

OECD-AI-accountability #

Тип источника

межправительственный первичный источник

Опубликовано

постоянно обновляемый справочный раздел

Проверено

2026-07-24

Ограничение

обзор принципов не заменяет применимое право и отраслевые требования

OECD.AI, Accountability. Проверено 24 июля 2026 года. Межправительственный источник связывает ответственность и прослеживаемость с жизненным циклом ИИ. Обзор принципов не заменяет применимое право.

NIST-AI-RMF-1-0 #

Тип источника

официальный первичный источник

Опубликовано

2023-01

Проверено

2026-07-24

Ограничение

добровольная рамка не задаёт определение AI-native и не заменяет обязательные нормы

NIST, Artificial Intelligence Risk Management Framework, январь 2023 года. Проверено 24 июля 2026 года. Добровольная рамка описывает управление, контекст, измерение и работу с риском. Она не заменяет обязательные нормы.

NIST-2026-agent-id #

Тип источника

первичный источник

Опубликовано

2026-02-05

Проверено

2026-07-24

Ограничение

концептуальный материал, не отраслевой норматив

NIST, Identity and Authority of Software Agents, 5 февраля 2026 года. Проверено 24 июля 2026 года. Концептуальный материал поддерживает отдельные учётные записи и границы полномочий. Это не отраслевой норматив.

NIST-2026-agent-security #

Тип источника

официальный первичный аналитический материал

Опубликовано

2026-05-18

Проверено

2026-07-24

Ограничение

сводка ответов на запрос информации не является окончательным стандартом или обязательным правилом

NIST, Summary and Analysis of Responses to the Request for Information Regarding Security Considerations for Artificial Intelligence Agents, 18 мая 2026 года.

Проверено 24 июля 2026 года. Материал систематизирует риски инструментов, идентичности, данных и действий. Это аналитическая сводка, а не окончательный стандарт.

OWASP-AGENTIC-TOP10-2026 #

Тип источника

открытая отраслевая модель угроз

Опубликовано

2026

Проверено

2026-07-24

Ограничение

перечень помогает находить угрозы, но не доказывает достаточность конкретного набора контролей

OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications 2026, 2026 год. Проверено 24 июля 2026 года. Открытая модель угроз помогает искать классы риска. Она не доказывает достаточность конкретного набора мер.

Протоколы и спецификации #

MCP-2025-11-25 #

Тип источника

официальная техническая спецификация

Опубликовано

2025-11-25

Проверено

2026-07-24

Ограничение

совместимость протокола не гарантирует доверие к серверу, корректные права или качество инструмента

Model Context Protocol, MCP Specification, редакция 2025-11-25, 25 ноября 2025 года. Проверено 24 июля 2026 года. Спецификация подтверждает интерфейсы контекста и инструментов. Совместимость не гарантирует доверие, правильные права и качество.

MCP-2026-managed-auth #

Тип источника

официальное объявление стабильного расширения

Опубликовано

2026-06-18

Проверено

2026-07-24

Ограничение

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

Model Context Protocol, Enterprise-Managed Authorization Extension, 18 июня 2026 года. Проверено 24 июля 2026 года. Официальное объявление подтверждает стабильное расширение централизованного управления доступом. Оно решает только часть задачи безопасности.

A2A-1-0-0 #

Тип источника

официальный выпуск спецификации

Опубликовано

2026-03-12

Проверено

2026-07-24

Ограничение

A2A нужен не для любой кооперации; версия 1.0.1 на дату среза не подтверждена

A2A Project, Linux Foundation, A2A Specification 1.0.0, 12 марта 2026 года. Проверено 24 июля 2026 года. Это последний подтверждённый официальный выпуск до даты среза. Версия 1.0.1 не подтверждена. A2A не нужен для любой кооперации.

A2UI-0-9 #

Тип источника

официальное объявление технической спецификации

Опубликовано

2026-04-17

Проверено

2026-07-24

Ограничение

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

Google Developers, A2UI v0.9: Generative UI enters a new era, 17 апреля 2026 года. Проверено 24 июля 2026 года. Материал подтверждает семейство 0.9 и декларативный каталог компонентов. Он не делает A2UI обязательным интерфейсом.

A2UI-0-9-1-current #

Тип источника

официальный первичный источник

Опубликовано

постоянно обновляемый сайт спецификации

Проверено

2026-07-24

Ограничение

версия 1.0 на дату среза остаётся кандидатом и не должна называться стабильной

A2UI Project, сайт спецификации A2UI. Проверено 24 июля 2026 года. Версия 0.9.1 указана как текущая производственная. Версия 1.0 остаётся кандидатом на дату среза.

AGENT-SKILLS-spec #

Тип источника

официальная техническая спецификация

Опубликовано

2026-07-10

Проверено

2026-07-24

Ограничение

соответствие формату не гарантирует правильность, безопасность или переносимость поведения

Agent Skills Project, Agent Skills Specification, проверенный коммит `38a2ff82958afee88dadf4831509e6f7e9d8ef4e`, 10 июля 2026 года.

Живая навигация по спецификации. Проверено 24 июля 2026 года. Формат не гарантирует качество, безопасность или переносимость поведения.

Регулирование #

EU-AI-ACT-framework #

Тип источника

официальный регуляторный источник

Опубликовано

постоянно обновляемый официальный раздел

Проверено

2026-07-24

Ограничение

обзор не заменяет текст Регламента, подзаконные материалы и анализ применимости

Европейская комиссия, AI Act regulatory framework. Проверено 24 июля 2026 года. Официальный раздел описывает риск-ориентированную структуру и обязанности участников. Обзор не заменяет анализ применимости.

EU-AI-ACT-2026-transparency-guidelines #

Тип источника

официальные разъяснения регулятора

Опубликовано

2026-07-20

Проверено

2026-07-24

Ограничение

требования статьи 50 в общем случае начинают применяться 2026-08-02; разъяснения не являются юридическим заключением для конкретной системы

Европейская комиссия, Guidelines on transparency obligations for providers and deployers of certain AI systems, 20 июля 2026 года.

Проверено 24 июля 2026 года. Разъяснения относятся к прозрачности статьи 50 и не являются заключением для конкретной системы.

EU-AI-ACT-timeline #

Тип источника

официальный регуляторный источник

Опубликовано

постоянно обновляемый официальный справочный раздел

Проверено

2026-07-24

Ограничение

календарь не определяет применимость конкретной обязанности к конкретной организации

EU AI Act Service Desk, EU AI Act implementation timeline. Проверено 24 июля 2026 года. Календарь подтверждает этапы применения, но не определяет применимость обязанности к организации.

CBR-2026-safe-ai #

Тип источника

официальный отраслевой регуляторный источник

Опубликовано

2026-06-16

Проверено

2026-07-24

Ограничение

отраслевые рекомендации нельзя автоматически переносить на компании вне финансового рынка

Банк России, Рекомендации по безопасному применению искусственного интеллекта на финансовом рынке, 16 июня 2026 года. Проверено 24 июля 2026 года. Отраслевые ожидания нельзя автоматически переносить за пределы финансового рынка.

RU-152-FZ #

Тип источника

закон

Опубликовано

2006-07-27; используется редакция, доступная на дату проверки

Проверено

2026-07-24

Ограничение

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

Российская Федерация, Федеральный закон № 152-ФЗ «О персональных данных», официальный консолидированный текст, 27 июля 2006 года.

Используется редакция на дату проверки; дополнительная навигация. Проверено 24 июля 2026 года. Выводы зависят от фактов обработки.

RU-PD-localization-2025 #

Тип источника

закон

Опубликовано

2025-02-28; действует с 2025-07-01

Проверено

2026-07-24

Ограничение

архитектурное решение зависит от роли организации, состава данных и операций; правило «локальные модели по умолчанию» из него не следует

Российская Федерация, Федеральный закон от 28 февраля 2025 года № 23-ФЗ; дополнительная навигация.

Изменения действуют с 1 июля 2025 года. Проверено 24 июля 2026 года. Требования локализации не создают универсального требования локальной модели.

Как обновлять источники #

Перед содержательным выпуском владелец редакции:

1. проверяет доступность ссылок;
2. сверяет версии MCP, A2A, A2UI и Agent Skills;
3. сохраняет прежнюю дату среза для этой версии;
4. создаёт новую версию руководства, если использует материалы после даты среза;
5. записывает изменение тезиса в журнал.

Версия и дата среза #

Версия содержания

2.0

Дата среза

24 июля 2026 года

Язык

русский

Статус определения AI-native

авторское рабочее определение

Статус правового раздела

навигация, не юридическое заключение

Контрольные версии #

Область версии #

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

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

Материалы после 24 июля 2026 года требуют новой даты среза и записи в журнале. Обновление ссылки без изменения тезиса можно оформить как редакционное исправление.

Что изменилось относительно v1 #

Сохранено #

• управляемый цикл «сигнал → решение → действие → проверка → обучение»;
• операционная модель компании;
• разные маршруты стартапа и зрелой компании;
• постоянная дисциплина проверок;
• экономика использования ИИ;
• российский контекст.

Переписано #

Добавлено #

• карта зрелости по восьми измерениям без единого маскирующего балла;
• уровни A0–A3 для конкретных действий;
• паспорт первого управляемого цикла;
• постоянный и оперативный контекст;
• среда исполнения и контур управления;
• навыки как версионируемые проверяемые зависимости;
• проверка результата и хода действий;
• изолированная среда и отдельная служебная учётная запись;
• жизненный цикл небольших изменений с выпуском по риску;
• подготовленное ИИ описание запроса на слияние с ответственностью автора;
• превращение инцидента в подходящую постоянную проверку;
• деревья выбора MCP, A2A и A2UI;
• полная стоимость принятого результата;
• планы стартапа на 30 и 90 дней;
• план зрелой компании на 30, 90 и 180 дней;
• тринадцать практических шаблонов.

Удалены или отвергнуты #

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

Исправления быстро меняющихся сведений #

• A2A: подтверждён официальный выпуск 1.0.0 от 12 марта 2026 года. Более ранняя запись о 1.0.1 не подтвердилась и удалена.
• A2UI: текущей производственной версией на дату среза указана 0.9.1. Версия 1.0 остаётся кандидатом и не называется стабильной.
• Статья 50 Регламента ЕС об ИИ: общий срок начала применения требований прозрачности — 2 августа 2026 года. Для отдельных ранее выпущенных систем, подпадающих под статью 50(2), указан переходный срок до 2 декабря 2026 года.

Изменение стандарта доказательности #

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

Дата этой записи: 24 июля 2026 года.