Блог
Core SAFe, AI-Native и AI-Native SAFe: в чём разница и как выбрать подход

Core SAFe, AI-Native и AI-Native SAFe: в чём разница и как выбрать подход

13 августа 2026

Почему купить Copilot недостаточно, чтобы стать AI-Native организацией, и какую задачу решает новая операционная модель AI-Native SAFe?

Автор статьи: Алексей Ионов – первый в России и СНГ Certified Advanced SAFe® Practice Consultant и аккредитованный AI-Native Trainer, основатель «Ионов и Партнёры». Компания – официальный партнёр Scaled Agile, Inc. с 2019 года и первый в России и СНГ AI-Native Partner Scaled Agile, Inc.

Если компания купила всем сотрудникам Copilot, стала ли она AI-Native? Вообще-то нет.

Если эта же компания уже применяет SAFe, а затем начала активно использовать ИИ-инструменты, перешла ли она тем самым на AI-Native SAFe? Тоже нет.

Core SAFe, AI-Native и AI-Native SAFe – не три версии одного фреймворка. Это понятия разных уровней. Путаница между ними мешает увидеть главное: ИИ меняет не только скорость выполнения работы, но и способ выбирать, проектировать, проверять и масштабировать её.

Если совсем коротко:

Понятие

Что это

Главный вопрос

Core SAFe

Операционная модель для масштабирования Lean и Agile в организации

Как согласовать стратегию, портфель, ART и команды, чтобы устойчиво создавать и поставлять ценность?

AI-Native

Cпособ мышления и работы, при котором ИИ изначально встроен в то, как мы выбираем и выполняем работу

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

AI-Native SAFe

Операционная модель для AI-Native организации, построенная на Lean-Agile фундаменте

Как в масштабе предприятия согласовать работу людей и ИИ вокруг измеримых клиентских и бизнес-результатов?

ionovpartners.ru

Именно эту разницу я предлагаю разобрать подробнее.

Использовать ИИ – ещё не значит быть AI-Native

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

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

Это AI-усиление существующей работы, но ещё не AI-Native подход.

AI-Native начинается раньше – с условного «шага номер ноль»:

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

То есть речь идёт не о той же самой работе быстрее, а о другой работе.

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

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

На обучениях по SAFe я часто объясняю взаимосвязь Lean, Agile и Lean-Agile мышления. SAFe – один из способов воплотить этот фундамент в операционной модели средней и крупной организации. Здесь можно провести похожую, хотя и не буквальную, аналогию. AI-Native шире какого-либо конкретного фреймворка. И AI-Native SAFe – это один из способов превратить AI-Native логику в согласованную операционную модель предприятия.

Что решает Core SAFe – и почему он никуда не исчезает

Core SAFe – это операционная модель масштабирования Lean и Agile. Она помогает связать стратегию, инвестиции портфеля, потоки ценности, Agile Release Trains и команды, чтобы большое количество людей могло согласованно создавать и поставлять ценность.

Важно сделать оговорку: Core SAFe – ни в коем случае не фабрика никому не нужных фич.

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

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

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

AI-усиленный Core SAFe – ещё не AI-Native SAFe

Если ИИ лишь ускоряет существующие процессы, а планирование, инвестиции, измерение успеха и управленческие решения остаются прежними, организация продолжает использовать Core SAFe – просто с AI-усилением.

И это не плохо и не «недостаточно современно». AI-Native SAFe сам по себе не исправит отсутствие базовой прозрачности, согласованности и связи стратегии с реальной работой.

Scaled Agile поэтому сохраняет и развивает обе операционные модели. Например, AI-Native ART – это не отдельный набор AI-инструментов и не замена классическому ART. Это развитие Agile Release Train для ситуации, когда ИИ ускоряет работу команд, но организация должна сохранить согласованность, управляемость и ответственность.

Core SAFe остаётся фундаментом масштабной Lean-Agile работы. AI-Native SAFe показывает, как этот фундамент эволюционирует, когда ИИ меняет скорость обучения, поставки и принятия решений.

ИИ создаёт другое узкое место системы

Главная причина появления AI-Native SAFe – перемещение узкого места.

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

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

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

Поэтому главный вопрос меняется. Уже недостаточно спросить: «Успеем ли мы это сделать?» Теперь нужно ответить на другие вопросы:

То ли мы создаём?
Какое изменение это должно вызвать для клиента и бизнеса?
Как мы поймём, что изменение действительно произошло?
Безопасно и этично ли решение?
Стоит ли продолжать инвестировать в эксперимент?
Нужно ли масштабировать решение, изменить подход или остановить работу?

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

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

Outputs и outcomes: что именно становится объектом управления

Outputs – конкретные выходные результаты, которые производят организация, ART или команда. На уровне портфеля – это продукты и решения; на уровне ART и команд – фичи, энейблеры, прототипы и эксперименты.

Outputs отвечают на вопрос: «Что мы сделали и поставили?»

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

Outcomes отвечают на вопрос: «Что изменилось для клиента и бизнеса благодаря тому, что мы сделали?»

Важно также различать ожидаемые и фактические outcomes. Ожидаемый результат – это наша гипотеза о ценности: изменение, которого мы хотим достичь. Фактический результат – уже подтверждённый данными эффект. Между ними находится работа по созданию outputs, измерению реакции и обучению.

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

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

В AI-Native SAFe клиентские и бизнес-результаты становятся центральным объектом планирования, инвестирования, измерения и обучения на всех уровнях – от портфеля до ART и команд. Outputs не исчезают: они воплощают гипотезы и служат способами достижения результатов. Работу над решением продолжают, масштабируют, меняют или прекращают в зависимости от полученных свидетельств.

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

Подробнее о том, как формулировать и связывать результаты ART, читайте в материале: «Клиентские и бизнес-результаты ART в AI-Native SAFe».

Как меняется разделение труда между человеком и ИИ

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

Человеческая работа при этом всё сильнее смещается к другим задачам:

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

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

Это не означает, что человек обязан вручную утверждать каждое действие любого агента. Механизм контроля должен соответствовать риску: где-то достаточно наблюдения и последующего аудита, а где-то необходим явный human-in-the-loop – человек в контуре принятия решения.

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

Намерение, спецификации, продуктовый контекст и курированные данные

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

Людям и агентам нужна общая система продуктового знания. В AI-Native SAFe она строится вокруг трёх взаимосвязанных элементов:

Намерение (Intent) – почему? Какое изменение мы хотим создать, какую проблему выбираем для решения и почему именно эта ставка имеет смысл.
Спецификации (Specifications) – что и как? Как выглядит хорошее решение, какие требования, правила, критерии качества и границы оно должно соблюдать. Эти артефакты должны быть живыми и пригодными для использования не только людьми, но и ИИ.
Продуктовый контекст (Product Context) – где? В какой клиентской, рыночной, операционной, экосистемной и регуляторной среде решение должно быть успешным и как быстро эта среда меняется.

AI-Native SAFe не даёт эти ответы готовыми. Он показывает, что их нужно сделать явными, связанными и доступными, независимо от того, кто принимает следующее решение – человек или агент.

Подробнее: «Намерение, спецификации и контекст в AI-Native SAFe».

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

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

Подробнее: «Курированные данные для ИИ: как корпоративные данные становятся конкурентным преимуществом».

Как меняется управленческий ритм

Когда команды и агенты работают быстрее, нельзя сохранять прежнюю скорость обучения и принятия решений. Поэтому в AI-Native SAFe меняется не только работа команд, но и общий ритм Agile Release Train.

PI Outcome Planning

Двухдневное PI Planning базового SAFe в AI-Native ART заменяется однодневным мероприятием PI Outcome Planning – планированием клиентских и бизнес-результатов PI.

В центре события находятся:

PI Outcomes – результаты, которых ART намерен достичь за интервал планирования и которые должны продвигать его долгосрочную стратегию;
Team Outcomes – вклад отдельных команд в эти результаты;
ключевые вехи, позволяющие сформировать реалистичный общий план;
риски, понимание сложности и готовность участников принять обязательства.

Техническое исполнение не исчезает, но его не пытаются детально зафиксировать на весь PI. Команды договариваются о клиентских и бизнес-результатах (outcomes), намерении и значимых вехах, а конкретные outputs могут меняться по мере поступления данных.

Подробнее: «PI Outcome Planning в AI-Native SAFe».

Customer Demo

Если ИИ позволяет быстро создавать несколько вариантов решения, организация должна так же быстро проверять их на реальных клиентах и пользователях.

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

Sense and Respond

Между событиями PI Outcome Planning ART не ждёт конца интервала, чтобы понять, работает ли выбранный подход. Не реже одного раза за итерацию проводится двухчасовое мероприятие Sense and Respond – «Выявлять и реагировать».

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

В AI-Native SAFe Sense and Respond заменяет проводимое раз за PI мероприятие Inspect and Adapt и включает активности, которые в Core SAFe выполнялись в рамках System Demo. Это не просто новая встреча, а переход к более короткому циклу обучения на уровне всего ART.

При этом ART может периодически проводить Problem-Solving Workshop – часть проводимого в Core SAFe мероприятия Inspect and Adapt, посвящённую системному решению проблем, – если это необходимо для его подхода к совершенствованию.

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

Чем выше скорость, тем важнее governance

AI-Native SAFe – не про снятие контроля и не про предложение «дать агентам делать всё, что они хотят».

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

Организации необходимо заранее определить:

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

Задача – масштабировать инновации, не масштабируя одновременно хаос и риск.

Именно поэтому AI-Native SAFe нужен не только командам разработки. Он связывает командную работу с уровнем ART и портфеля, где определяются инвестиционные приоритеты, общие guardrails и правила ответственного применения ИИ.

Можно ли быть AI-Native без SAFe

Да, конечно.

Небольшая команда может стать AI-Native, не применяя SAFe. Крупная компания также может самостоятельно спроектировать операционную модель, основанную на AI-Native принципах: провести эксперименты, определить новые процессы, договориться о ролях людей и агентов, построить контуры данных, обратной связи и governance.

Точно так же организация может строить собственную модель на Lean- и Agile-мышлении, не используя SAFe.

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

Именно здесь появляется ценность AI-Native SAFe: он предлагает общий язык, структуру и набор развивающихся практик для масштабной организации AI-Native работы на Lean-Agile фундаменте.

Метафора фабрики и электромотора

Добавить Copilot в старый процесс – всё равно что заменить паровой двигатель мощным электромотором, но оставить прежнюю фабрику без изменений.

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

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

AI-Native SAFe – это операционная модель управления такой фабрикой в масштабе крупной организации. Она помогает связать высокую скорость с общими результатами, коротким обучением, согласованностью и ответственностью.

Три понятия в одной формуле

Core SAFe масштабирует согласованную Lean-Agile работу и поставку ценности, связывая стратегию, портфель, ART и команды.

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

AI-Native SAFe помогает перенести эти возможности на уровень предприятия: организовать совместную работу людей и ИИ вокруг клиентских и бизнес-результатов, ускорить обучение и инновации, сохранив согласованность, governance и человеческую ответственность.

Главный вопрос AI-Native организации поэтому не звучит как: «Как с помощью ИИ сделать больше?»

Он звучит иначе:
«Как с помощью ИИ быстрее находить и создавать то, что действительно даёт ценность – и так же быстро прекращать всё остальное?»

Если вы хотите определить, какие знания и изменения в операционной модели в первую очередь нужны вашей организации, можете обратиться к нам – мы в «Ионов и Партнёры» поможем выбрать практическую траекторию: от развития AI-Native мышления и рабочих процессов до перехода к AI-Native SAFe. Напишите нам: info@ionovpartners.ru

Частые вопросы

AI-Native – это просто использование ChatGPT или Copilot?

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

Заменяет ли AI-Native SAFe Core SAFe?

Нет. Core SAFe остаётся операционной моделью масштабирования Lean-Agile работы. AI-Native SAFe развивает этот фундамент для условий, когда ИИ существенно ускоряет определение, выбор, создание, проверку и изменение решений.

Можно ли использовать AI-Native SAFe без применения полностью автономных ИИ-агентов?

Да. AI-Native SAFe не требует немедленной полной автономности агентов. Организация может развивать подход постепенно: от AI-усиления работы и качества данных до изменения управленческого ритма, системы результатов и контуров governance.

Нужен ли AI-Native SAFe только ИТ-командам?

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