AI‑операционка: внедряем ИИ в реальные процессы
Один реальный процесс. Полуручной пилот с ИИ. Проверяемые выводы на реальных данных. Решение о внедрении.
Коротко
ИИ должен делать работу, а не добавлять ещё один интерфейс, в который нужно заходить.
За восемь недель каждый участник возьмёт один реальный процесс, пройдёт его вместе с ИИ в полуручном режиме и доведёт до проверенного решения: запускать, сузить, передать в разработку или остановить.
Не учебный пример. Не гипотетический кейс. Процесс, который уже существует, забирает время людей и влияет на деньги, скорость или качество работы.
Мы не будем начинать с выбора модели, сервиса или правильного промпта. Сначала определим готовый результат, который должен получать бизнес. Затем разберём всю цепочку действий и решений до этого результата, проверим её на реальных данных и только после этого будем автоматизировать.
Особый акцент в программе — evidence-first. Модель может уверенно выдать правдоподобный, но выдуманный результат. В реальном процессе такая ошибка может стоить денег, испортить данные или привести к неверному решению. Поэтому ключевые выводы и действия системы будут опираться на достоверные данные, а их основание можно будет быстро проверить.
На выходе не обязательно получится полностью автономный агент. Где-то ИИ сможет забрать почти весь процесс. Где-то — только отдельные этапы. А где-то выяснится, что автоматизировать выбранный процесс сейчас вообще невыгодно.
Это тоже результат. Лучше понять это за несколько недель, чем полгода внедрять систему, которая никому не нужна.
Подробнее
Большинство разговоров о внедрении ИИ заканчивается примерно одинаково: люди узнают про новые модели, пробуют несколько сервисов, собирают набор промптов и возвращаются в ту же операционку, которая была до этого.
Потому что модель сама по себе работу не меняет.
Чтобы ИИ начал делать реальную работу, нужно определить конечный результат, разобрать процесс до него, дать системе данные и инструменты, описать развилки, добавить независимые проверки и встроить всё это обратно в работу компании.
Этим мы и займёмся в группе.
Модель может уверенно выдать правдоподобный, но выдуманный ответ. В операционном процессе такая ошибка может стоить денег, испортить данные или привести к неверному решению. Поэтому существенные выводы, числа и действия системы будут подкреплены данными и источниками, которые можно проверить.
Каждый участник приходит с одним конкретным процессом. Например:
- подготовка управленческого отчёта;
- анализ продаж и поиск причин отклонений;
- квалификация входящих запросов;
- подготовка коммерческих предложений;
- исследование рынка или конкурентов;
- контроль качества работы команды;
- обработка документов;
- сопровождение клиента;
- сбор данных из нескольких систем;
- подготовка решения для руководителя.
Мы разберём процесс не как список привычных действий, а как последовательность получения результата:
- что должно получиться на выходе;
- какие данные для этого нужны;
- какие решения принимаются по пути;
- где есть разные сценарии;
- что можно поручить ИИ;
- где пока должен остаться человек;
- как проверить, что результат действительно правильный;
- как встроить новый процесс в текущую работу компании.
Сначала участник пройдёт этот путь вместе с ИИ в полуручном режиме. Агент будет выполнять отдельные действия, предлагать следующий шаг, собирать данные и формировать промежуточные результаты. Контекст, решения и исправления будут фиксироваться, чтобы их можно было использовать в следующей версии процесса.
И только когда процесс действительно пройден и понят, мы решим, какую его часть имеет смысл автоматизировать.
К концу группы у каждого участника будет не просто идея внедрения ИИ, а проверенный проект одного из трёх типов:
- работающий пилот, который уже можно использовать на реальных задачах;
- собранная спецификация системы, которую можно передавать в разработку;
- обоснованный вывод, почему выбранный процесс сейчас автоматизировать не стоит и по каким критериям выбирать следующий.
Главная задача группы — не внедрить ИИ ради ИИ.
Главная задача — сделать конкретную работу быстрее, дешевле или качественнее и проверить это на реальном процессе.
Для кого эта группа
Группа подойдёт:
- собственникам и руководителям компаний;
- операционным директорам;
- руководителям функций и направлений;
- продуктовым руководителям;
- предпринимателям, которые сами отвечают за существенную часть операционной работы;
- внутренним AI-лидерам, у которых есть доступ к реальным процессам, данным и людям.
Участник должен иметь возможность не только предложить идею, но и изменить выбранный процесс: получить данные, поговорить с участниками, провести пилот и принять решение по итогам.
Технический опыт не обязателен. Но понадобится готовность разбираться в устройстве собственного процесса и выполнять работу между встречами.
Кому группа не подойдёт
- тем, кто хочет просто узнать, какие сейчас есть AI-инструменты;
- тем, кто приходит без конкретного процесса;
- тем, у кого нет доступа к данным и участникам процесса;
- тем, кто хочет передать идею ведущему и получить готовую систему без собственного участия;
- тем, кто пока не готов проверять гипотезу на реальной работе;
- тем, кому нужен курс по программированию или технической разработке AI-систем.
- тем, кто не готов приходить на встречи и регулярно выполнять запланированные шаги между ними;
Результат для участника
К концу программы у каждого будет собран комплект материалов по одному реальному процессу.
1. Паспорт процесса
- владелец процесса;
- участники;
- начало и конец;
- входные данные;
- готовый результат;
- заказчик результата;
- текущие ограничения;
- цена ошибки;
- частота и объём работы;
- текущая стоимость процесса в деньгах или времени, если её можно посчитать.
2. Контракт результата
Не «ИИ помогает анализировать данные», а точное описание того, что должно появляться на выходе.
Например:
- отчёт с определённым набором показателей;
- список отклонений с подтверждающими данными;
- подготовленное коммерческое предложение;
- квалифицированный запрос с рекомендуемым следующим действием;
- решение, в котором каждый существенный вывод можно проверить по источнику.
В контракт войдут критерии качества, формат, допустимые ошибки, ограничения и условия, при которых результат должен передаваться человеку.
3. Карта процесса
- действия;
- решения;
- развилки;
- источники данных;
- инструменты;
- ручные проверки;
- возвраты и исправления;
- точки ожидания;
- исключения;
- условия остановки.
4. Полуручной пилот
Участник вместе с ИИ пройдёт процесс на реальных кейсах и зафиксирует:
- что агент уже делает хорошо;
- где ему не хватает данных;
- где он принимает неверные решения;
- какие инструкции не работают;
- какие действия нужно добавить;
- где человек пока незаменим;
- какие части процесса повторяются и уже готовы к автоматизации.
5. Пакет контекста и данных
- необходимые источники;
- правила доступа;
- словарь терминов;
- примеры правильных результатов;
- ограничения;
- правила работы с конфиденциальной информацией;
- иерархия источников;
- данные, которых пока не хватает.
6. Набор проверок
- тестовые кейсы;
- критерии приёмки;
- типовые ошибки;
- критические ошибки;
- пограничные случаи;
- правила перепроверки;
- точки обязательного участия человека.
7. Рабочая версия процесса
В зависимости от сложности это может быть:
- настроенный AI-проект внутри готового инструмента;
- цепочка из нескольких моделей и сервисов;
- агентный процесс с доступом к данным и инструментам;
- частично автоматизированный workflow;
- подробная спецификация для разработки.
8. План внедрения на 30 дней
- что запускается первым;
- кто отвечает;
- на каких задачах проходит контролируемый пилот;
- что измеряется;
- когда принимается решение о расширении;
- что должно произойти, чтобы проект был остановлен или пересобран.
9. Evidence-first
Ключевые выводы, числа и решения связаны с данными или источниками. Непроверенное не маскируется под факт.
Если после этого списка кажется, что всё слишком сложно, то на практике большую часть этой работы тоже будет делать агент.
Он поможет собрать шаги процесса, задаст недостающие вопросы, оформит карту, зафиксирует решения, найдёт противоречия и подготовит проверки. От участника нужны знания своего процесса, доступ к реальным данным и решения там, где без человека их принять нельзя.
Формат программы
Конфигурация программы
- продолжительность — 8 недель;
- 8 основных групповых встреч по 1,5 часа;
- закрытый чат для вопросов и промежуточных результатов;
- шаблоны рабочих документов и примеры;
- разборы проектов участников;
- работа между встречами — в среднем 3–5 часов в неделю;
- оптимальный размер группы — 7–8 участников.
Формат на 7–8 участников позволяет видеть разные процессы и подходы, но сохраняет достаточно времени для предметных разборов.
Как проходит основная встреча
- Короткий обзор того, что участники сделали за неделю.
- Подробный разбор двух или трёх проектов, включая обсуждение подходов и методов.
- Поиск того, как сделать работу проще и быстрее, и фиксация следующих проверяемых шагов.
Отдельного времени на теорию на встречах не будет. Полезная теория, инструменты и материалы, которые помогают сделать работу быстрее и проще, будут появляться в чате по мере необходимости.
Что понадобится
Для работы в группе не нужна готовая техническая команда или заранее собранная инфраструктура. Но без рабочего агентного инструмента пройти программу не получится.
Точно понадобится
- Платный аккаунт Claude Code или Codex.Достаточно одного из двух. Это основной рабочий инструмент между встречами.
- Доступ к реальному процессу, его данным и людям, которые в нём участвуют.
- В среднем 3–5 часов в неделю на работу между встречами.
Что не обязательно
- уметь программировать;
- разбираться в API и архитектуре;
- иметь собственного разработчика;
- заранее выбирать остальные сервисы и модели;
- приходить с готовым техническим решением.
Если для пилота позже понадобится код, интеграция или технический специалист, это станет понятно по ходу работы.
Что входит в программу — и где она заканчивается
В программу входит
- помощь в выборе и разборе реального процесса;
- шаблоны рабочих документов;
- групповые разборы проектов;
- помощь в сборке и поддержка в проведении полуручного пилота;
- подбор достаточных инструментов и архитектуры;
- проверка качества, рисков и экономики;
- помощь в принятии решения: запускать, сузить, передать в разработку или остановить.
В программу не входит
- разработка отдельной production-системы для каждого участника;
- разработка кастомных интеграций;
- полная AI-стратегия компании;
- юридический аудит или аудит информационной безопасности;
- гарантия конкретного процента автоматизации;
- выполнение работы участника вместо него.
Технический опыт не обязателен для проектирования и проверки пилота. Но если первая версия требует кода, API или изменений в корпоративных системах, участник подключает своего технического специалиста. Либо завершает программу исполнимой спецификацией для разработки.
Принципы группы
1. Результат раньше инструмента
Мы не выбираем модели, инструменты и системы до того, как поняли, какую работу они должны выполнять.
Один и тот же процесс может потребовать обычного чата, поиска, таблиц, кода, базы знаний, интеграций или нескольких агентов. Инструмент следует за задачей, а не наоборот.
2. Сначала пройти процесс, потом автоматизировать
Автоматизировать процесс до того, как его хотя бы раз прошли целиком и получили полезный результат, — так себе затея.
Поэтому первая версия будет полуручной. Человек и агент проходят путь вместе. Агент выполняет доступную ему часть работы, а человек помогает там, где процесс пока не определён или система ещё не справляется.
Пройденный путь постепенно превращается в автоматизированный.
3. Агент должен производить готовый результат
Ответ в чате сам по себе редко является операционным результатом.
Агент нужен там, где он может выполнить последовательность действий: получить данные, выбрать следующий шаг, использовать инструмент, проверить промежуточный результат, исправить ошибку и довести задачу до завершения.
4. Автоматизируется работа, а не должность
Мы не начинаем с вопроса, какого сотрудника можно заменить.
Сначала разбираем работу на действия и решения. После этого становится видно, что ИИ может забрать полностью, что частично, а что пока должно остаться у человека.
5. Проверяемость обязательна там, где ошибка стоит дорого
Для части задач достаточно правдоподобного ответа. Для важных решений — нет.
Если ошибка влияет на деньги, клиента, договор, безопасность или управленческое решение, система должна показывать, на основании чего сделан вывод, и проходить отдельную проверку.
6. Полная автономность не является целью
Человек в процессе может быть необходим. Особенно на старте.
Мы будем убирать ручную работу там, где это улучшает результат, а не ради красивого процента автоматизации.
7. Каждый проект должен закончиться решением
По итогам программы нельзя остаться в состоянии «идея выглядит интересно».
Должно быть принято одно из решений:
- запускать;
- сузить процесс и провести ещё один пилот;
- изменить архитектуру;
- заменить выбранный процесс;
- остановить проект.
Evidence-first
Модель может выдать правдоподобный результат, который невозможно отличить от реального без проверки. Поэтому убедительный ответ ещё не означает, что на него можно опереться.
Для ключевых выводов, чисел и решений мы используем один простой стандарт — без отдельной бюрократии и сложных систем.
Что утверждаем?
Какой вывод, число или решение повлияет на следующее действие человека.
На основании чего?
Какие данные, документ, запись, источник или правило это подтверждают.
Как проверить?
Где человек может быстро открыть основание и убедиться, что вывод ему соответствует.
Не каждое предложение. Только то, на основании чего человек будет действовать, отправлять что-то наружу, менять данные, тратить деньги или принимать решение.
Три статуса
Один короткий шаблон
Вывод или решение: что система предлагает считать верным или сделать дальше.
Статус: проверено / предположение / данных недостаточно.
Основание: конкретные данные, документ, запись, источник или правило.
Проверка: ссылка, файл, строка, карточка или другое место, которое можно открыть.
Что осталось неизвестным: только если это влияет на решение.
Чего здесь не будет
- источника под каждой очевидной фразой;
- сложного графа происхождения данных;
- отдельной платформы только ради проверяемости;
- процентов уверенности, которые модель придумала сама;
- повторной проверки низкорисковых действий, где цена ошибки невелика.
Где это появляется в программе
- на неделе 2 — в контракте результата;
- на неделе 4 — в журнале решений и вмешательств;
- на неделе 5 — в карте источников истины;
- на неделе 6 — в правилах принятия решений агентом;
- на неделе 7 — в простой проверке нескольких новых результатов;
- на неделе 8 — в демонстрации цепочки от вывода обратно к исходным данным.
Контрольные точки и доказательная база
Проект не должен ехать по программе только потому, что уже начался. На четырёх этапах принимается отдельное решение.
До старта
Есть владелец процесса, доступ к данным, возможность провести пилот и человек, который может изменить порядок работы.
После недели 2
Результат можно описать и принять. Если непонятно, что считать хорошей работой, процесс меняется или сужается.
После недели 4
Есть хотя бы несколько реальных прохождений, журнал вмешательств и понятная граница безопасного пилота.
После недели 7
Есть данные для решения: запускать, дорабатывать, сузить или остановить.
Минимальный пакет доказательств
- исходный результат и показатели текущего процесса;
- репрезентативные реальные кейсы, а не один удачный пример;
- отдельный набор кейсов, который не использовался для настройки;
- журнал вмешательств человека и изменений системы;
- приёмка результата его реальным заказчиком;
- стоимость моделей, сервисов, контроля и поддержки;
- известные ограничения и случаи, в которых систему использовать нельзя.
- несколько примеров, в которых ключевой вывод можно пройти обратно до конкретных данных, источника или записи;
Во время пилота система не должна самостоятельно выполнять необратимые действия. Внешние сообщения, платежи, изменение production-данных, удаление информации и юридически значимые решения проходят подтверждение человека, пока отдельный контроль не доказал обратное.
Перед началом
До подтверждения участия нужно прислать короткое описание процесса, с которым вы хотите работать.
В описании достаточно ответить на семь вопросов:
- Какой процесс вы хотите изменить.
- Кто отвечает за этот процесс сейчас.
- Что является готовым результатом.
- Какие данные и системы используются.
- Что сейчас занимает больше всего времени или создаёт больше всего проблем.
- Можно ли провести пилот на реальных задачах во время программы.
- Кто может принимать решение об изменении процесса.
Не обязательно оформлять это письменно. Всё можно просто надиктовать аудиосообщением в Telegram.
Желательно сразу предложить два варианта: основной процесс и запасной. До старта мы выберем тот, который можно пройти на реальных данных и проверить за восемь недель.
Программа по неделям
На встречах мы обсуждаем результаты, ограничения и следующие шаги. Основную работу по своему процессу участник выполняет между встречами с помощью агента.
Неделя 1. Выбираем работу, которую действительно стоит менять
Получить ответ на главный вопрос: какой процесс сейчас забирает достаточно времени, денег или внимания, чтобы имело смысл заниматься в первую очередь?
Неделя 2. Определяем готовый результат
Получить ответ на главный вопрос: что именно должно появляться на выходе и по каким признакам можно понять, что результат достаточно хороший?
Неделя 3. Разбираем путь до результата
Получить ответ на главный вопрос: какие действия, решения и развилки ведут к результату и где проходит граница первой версии?
Неделя 4. Проходим процесс вместе с ИИ
Получить ответ на главный вопрос: может ли агент вместе с человеком пройти процесс целиком и получить полезный результат на реальных кейсах?
Неделя 5. Собираем контекст, данные и инструменты
Получить ответ на главный вопрос: какой информации, правил, примеров, доступов и инструментов не хватает агенту для стабильной работы?
Неделя 6. Собираем рабочий процесс
Получить ответ на главный вопрос: какую часть процесса уже можно передать агенту, а где пока должен остаться человек?
Неделя 7. Проверяем качество и экономику
Получить ответ на главный вопрос: новый процесс действительно работает лучше прежнего, можно ли доверять его результатам и оправдывает ли эффект затраты?
Неделя 8. Принимаем решение о внедрении
Получить ответ на главный вопрос: что запускать дальше, кто отвечает за процесс и какой следующий проверяемый шаг нужно сделать?
Система контроля прогресса
Каждый проект проходит пять уровней.
Уровень 0. Идея
Есть только общее желание «использовать ИИ».
Уровень 1. Определённый процесс
Понятны вход, выход, заказчик результата, участники и показатели.
Уровень 2. Пройденный процесс
Человек и агент прошли работу в полуручном режиме на реальных кейсах. Решения и исключения зафиксированы.
Уровень 3. Проверенный пилот
Есть рабочая версия, тестовые кейсы, показатели, журнал ошибок и понятные границы участия человека.
Уровень 4. Контролируемое внедрение
Назначен владелец, изменён порядок работы, определены контроль качества и условия расширения.
Цель программы — довести подходящие проекты до третьего уровня. Если по ходу выяснится, что данных, доступа или экономики для пилота нет, полноценным результатом считается обоснованная остановка или замена процесса. Делать вид, что такой проект дошёл до проверенного пилота, не нужно.
Как работает группа
Каждую неделю два или три проекта получают подробный разбор. Остальные участники видят чужие решения, ошибки и подходы, которые можно применить к своему процессу.
Закрытый чат используется для вопросов, промежуточных результатов, полезной теории, шаблонов и инструментов, которые помогают сделать следующий шаг быстрее.
Конфиденциальность и безопасность
Группа работает с реальными процессами, но это не означает, что участники должны публиковать внутри неё все данные компании.
Основные правила:
- в общих разборах используются обезличенные данные, когда раскрытие не требуется;
- пароли, ключи доступа и персональные данные не размещаются в групповом чате;
- участник сам определяет, какие детали может показывать;
- для чувствительных процессов сначала проектируется безопасный контур;
- данные не передаются внешней модели только потому, что это технически удобно;
- при высокой цене ошибки обязательна человеческая проверка;
- группа не заменяет юридическую, информационно-безопасностную или отраслевую экспертизу.
- участник подтверждает, что имеет право использовать данные процесса в пилоте;
- до начала работы данные делятся как минимум на публичные, внутренние, конфиденциальные и запрещённые к передаче внешним моделям;
- для каждого инструмента заранее фиксируются допустимые данные, доступы и срок хранения;
- секреты и токены передаются через предназначенные для этого хранилища, а не через промпты и документы;
- после пилота лишние доступы отзываются, а тестовые данные удаляются по правилам компании;
- для критических действий заранее определяются остановка, откат и ответственный за инцидент.
Задача ведущего
Задача ведущего — помочь:
- выбрать процесс, которым действительно стоит заниматься;
- разложить его на действия, решения и развилки;
- найти текущие ограничения и точки, в которых процесс ломается;
- собрать полезный полуручной пилот;
- подобрать достаточные инструменты и архитектуру;
- проверить результат, его основания, риски и экономику;
- разобрать возникшие барьеры и найти следующий проверяемый шаг;
- принять решение о дальнейшем внедрении.
Работу по своему процессу участник выполняет сам — с помощью агента и при поддержке ведущего.
Что участник делает между встречами
Между встречами участник проходит очередной этап своего процесса с помощью агента: собирает данные, проверяет гипотезы, проводит полуручной пилот и фиксирует результат.
На встрече мы обсуждаем, что получилось, где возникли ограничения или барьеры, как их преодолеть и какой следующий шаг имеет смысл проверить.
Критерии успешного завершения
Программа считается пройденной, если участник:
- выбрал один конкретный процесс;
- определил готовый результат и критерии качества;
- восстановил цепочку действий и решений;
- прошёл процесс вместе с ИИ на реальных кейсах;
- собрал необходимый контекст;
- зафиксировал ошибки и исключения;
- создал набор проверок;
- сравнил новую версию с текущей;
- принял обоснованное решение;
- подготовил план следующих 30 дней.
- сделал ключевые выводы пилота проверяемыми по данным, источникам или журналу и отдельно обозначил предположения;
Полностью автоматизированный процесс не является обязательным критерием. Обязателен проверенный результат.
Организационные условия
1. Состав группы
Оптимальный формат — 7–8 участников. Этого достаточно, чтобы разбирать разные процессы и при этом сохранять глубину работы.
2. Правила участия
Группа строится на последовательной работе каждую неделю. Если участник не выполняет задачи, которые сам запланировал, или не приходит на встречу, он покидает группу.
3. Доступ команды участника
На отдельные встречи участник может приглашать владельца процесса, технического специалиста или ключевого исполнителя. Особенно на этапах карты процесса, данных и внедрения.
4. Запись встреч
Встречи по умолчанию записываются. После каждой встречи транскрипция доступна участникам группы. Если участник заранее сообщает, что вопрос требует повышенной конфиденциальности, запись на время его разбора отключается.
5. Индивидуальная помощь
В базовый формат входят групповые встречи и поддержка в чате. Индивидуальные сессии и отдельная разработка могут быть согласованы дополнительно.
6. Итоговая демонстрация
Финальная встреча может быть закрытой или открытой для других участников Circle. Во втором случае каждый автор сам определяет, какую часть проекта можно показывать.
Итог
За восемь недель участник не просто узнает, где в его компании можно использовать ИИ.
Он возьмёт один процесс, разберёт его до готового результата, пройдёт вместе с агентом, проверит на реальных данных и примет решение, какую часть работы можно передать системе уже сейчас.
И соберёт первую версию системы. Или поймёт на данных, почему её пока не надо строить.