Марк Тьюрин
Карьера 3.0: Как оставаться востребованным в эпоху ИИ

Рынок покупает не должность, а результат

В 8:47 у Елены остывал кофе, а в рабочем чате операционного блока уже появился знакомый запрос:

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

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

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

— Сводка у меня, — сказал Антон. — Но ответь на один вопрос. Что изменится после того, как я это прочитаю?

Елена посмотрела на экран. В отчёте были данные по восемнадцати регионам, девять таблиц, диаграмма динамики и отдельная страница с расшифровкой причин.

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

— Это я уже вижу. Что мы сделаем иначе?

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

— Хорошо. И что дальше?

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

— Отчёт точный, — сказала она. — Все данные выверены. Я убрала ошибки из исходных выгрузок.

— Я не спорю с качеством отчёта. Я спрашиваю, какое решение он помогает принять.

После звонка Елена ещё несколько секунд смотрела на название файла: «Просроченные доставки. Неделя 32». Оно было аккуратным, нейтральным и совершенно ничего не говорило о том, что должно произойти после прочтения.

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

Три ответа на вопрос «за что вам платят?»

У этого вопроса есть три разных ответа, и большинство карьерных ошибок начинается с того, что их смешивают.

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

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

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

Карьерой 3.0 мы называем рабочую систему, в которой человек связывает три уровня: роль, результат и развитие. Роль отвечает на вопрос: «За какую область я отвечаю?» Результат — «Что изменилось благодаря моей работе?» Система развития — «Как я регулярно развиваю способность решать более сложные задачи, используя новые инструменты и принимая больше ответственности?»

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

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

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

Рабочая неделя, в которой исчезает привычная опора

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

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

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

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

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

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

Елена усмехнулась:

— Видимо, это теперь главный вопрос.

— Он всегда был главным, — ответила Марина. — Просто раньше его можно было не задавать так прямо.

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

— Проверяю отчёт, — сказала Елена.

— Ты же уже его сделала.

Она помолчала.

— Да. Теперь пытаюсь понять, что после него должно произойти.

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

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

Она загрузила данные, указала период и попросила:

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

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

Первой реакцией было облегчение. Второй — тревога.

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

Как ИИ разбирает профессию на операции

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

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

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

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

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

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

Лестница автоматизации

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

Первый уровень — шаблон.

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

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

Второй уровень — подсказка.

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

Например, система пишет: «В двух регионах просрочка выросла сильнее, чем можно объяснить сезонной динамикой. Проверьте изменение времени комплектации и доступность транспорта». Елена решает, какие гипотезы проверять и насколько заслуживает доверия этот вывод.

Третий уровень — соисполнитель.

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

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

Четвёртый уровень — автономный контур.

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

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

Эти уровни не являются ступенями, по которым вся профессия целиком поднимается от ручного труда к автономии. Одна задача может работать как шаблон, другая — требовать совместной работы с ИИ, третья — оставаться полностью человеческим решением. Поэтому вопрос «Заменит ли ИИ мою профессию?» слишком масштабный. Рабочий вопрос звучит иначе: «До какого уровня автоматизации может дойти каждая операция в моей работе и что останется на моей стороне?»

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

Что именно покупает компания

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

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

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

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

На практике одна работа может создавать все три вида ценности. Например, с помощью ИИ Елена получает сводку за десять минут вместо двух часов. Это скорость. Она быстрее замечает пропущенные строки и расхождения. Это качество. Затем она говорит Антону: «В этом регионе проблема не в общем дефиците машин. Просрочка возникла из-за позднего окна комплектации на одном складе. Если добавить перевозчика, мы увеличим расходы и не устраним источник задержек. Сначала нужно изменить порядок передачи заказов». Это решение.

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

Личный инвентарь работы Елены

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

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

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

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

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

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

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

Контролировать исполнение. Здесь входными данными были договорённости, сроки и статусы. На выходе появлялись напоминания и список рисков, которые нужно было эскалировать. Система могла отслеживать сроки и отправлять сигналы в автономном режиме. Елена решала, когда вмешаться и кому передать вопрос.

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

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

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

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

Реплики, которые переводят работу в результат

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

Когда Антон просит очередную сводку, Елена теперь может ответить:

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

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

На встрече по итогам квартала вместо фразы «Я подготовила сорок отчётов» можно сказать:

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

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

В резюме или на собеседовании вместо «готовила отчётность по логистике» сильнее звучит:

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

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

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

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

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

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

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

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

Дальше используйте простую развилку.

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

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

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

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

В конце сформулируйте одну фразу:

«Мне платят не за то, что я выполняю [набор операций], а за то, что благодаря моей работе [измеримое или наблюдаемое изменение], особенно когда [контекст или ограничение]».

Например:

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

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

Дефицитный контекст плюс ответственность

После инвентаря Елена вернулась к Антону. Она показала ему не новый красивый отчёт, а карту процесса.

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

Антон посмотрел на список.

— Тогда что нужно оставить за тобой?

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

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

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

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

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

ИИ может увеличить скорость и качество работы Елены. Он может освободить её от сбора, сверки и первичного описания данных. Но он не отменяет вопроса «что делать дальше?». Более того, чем дешевле становится подготовка информации, тем заметнее человек, который умеет превратить её в выбор, объяснить компромисс и проверить последствия.

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

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

Карта своей заменяемости

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

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

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

Тест одного глагола

На десять минут запретите себе слова «подготовить», «сделать», «проанализировать», «проверить», «проконтролировать», «согласовать» и «организовать». Они слишком широки и скрывают детали. Записывайте только наблюдаемые действия: найти, выгрузить, очистить, сопоставить, посчитать, классифицировать, объяснить, запросить, выбрать, утвердить, отправить.

Например, вместо «проанализировать еженедельный отчёт» получится примерно такая запись:

Найти данные за нужный период в трёх внутренних источниках.

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

Удалить дублирующиеся записи и отдельно отметить пропуски.

Сопоставить фактический результат с планом и предыдущим периодом.

Посчитать отклонения по заранее заданным формулам.

Выделить показатели, которые вышли за допустимый диапазон.

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

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

Сформулировать вывод для руководителя, не перегружая его техническими деталями.

Предложить действие, срок и ответственного.

Проверить итоговый текст и отправить его в нужный канал.

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

Пять удобных заблуждений

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

На деле заменяется не должность целиком, а отдельные операции внутри неё. Даже в одной должности могут одновременно существовать полностью стандартизируемые действия, редкие экспертные решения и коммуникации, где цена неверно понятого контекста выше выигрыша в скорости. Аналитик не бывает «заменяемым» или «незаменимым» целиком. Сбор данных в его работе можно передать системе, а интерпретацию результатов и ответственность за решение — нет.

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

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

Третий миф: рутинное не имеет ценности, а сложное защищено.

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

Четвёртый миф: человек всегда исправит ошибку ИИ.

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

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

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

Правильная единица анализа

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

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

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

Удобная последовательность декомпозиции выглядит так.

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

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

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

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

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

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

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

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

Когда задача действительно уязвима для автоматизации

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

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

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

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

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

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

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

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

Простота действия не означает низкую цену ошибки

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

Поэтому для каждого действия нужно задавать не один вопрос: «Можно ли это автоматизировать?» Важнее спросить: «Как будет обнаружена ошибка до того, как она повлияет на решение?»

О высокой цене ошибки говорят несколько сигналов.

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

Результат невозможно сравнить с надёжным эталоном.

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

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

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

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

Три рабочих контекста

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

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

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

Матрица ценности и уязвимости

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

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

Вторая ось — уязвимость задачи к стандартизации и передаче. Здесь уязвимость означает не слабость, а податливость формализации: можно ли отделить задачу от контекста, описать правила, проверить результат и исправить ошибку до того, как возникнут последствия?

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

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

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

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

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

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

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

«Усиливать человеком» — самый интересный вариант. В этом квадранте ИИ действительно способен резко повысить производительность, но не должен становиться самостоятельным носителем ответственности. Человек сохраняет право остановить результат, запросить подтверждение и изменить вывод.

Разбор: еженедельный отчёт

Рассмотрим типовой еженедельный отчёт операционного подразделения. На выходе — две страницы для руководителя и приложение с показателями. Формулировка задачи звучит просто: «Подготовить отчёт к началу недели».

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

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

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

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

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

Теперь распределение работы выглядит иначе.

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

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

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

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

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

Формирование черновика и приведение отчёта к нужному формату сочетают высокую уязвимость и высокую ценность результата. Здесь модель усиливает человека: создаёт первую версию, но не утверждает её.

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

Краш-тест перед первым пилотом

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

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

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

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

Алгоритм состоит из семи шагов.

Шаг 1. Назовите не всю задачу, а один участок.

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

Шаг 2. Зафиксируйте, что не входит в пилот.

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

Шаг 3. Опишите входные данные.

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

Шаг 4. Опишите приемлемый результат.

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

Шаг 5. Назначьте человеческую точку контроля.

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

Шаг 6. Определите условие остановки.

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

Шаг 7. Примите одно из четырёх решений.

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

Усиливать — если результат ценен, а отдельные операции хорошо стандартизируются. Модель ищет, считает, группирует и готовит черновик. Человек интерпретирует, согласует и утверждает. Так обычно и выглядит безопасный рабочий союз.

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

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

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

Короткий чек-лист перед запуском

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

Есть один конкретный владелец результата.

Входные данные перечислены и доступны в разрешённом контуре.

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

Ошибка обнаруживается до отправки или исполнения решения.

Ошибка обратима либо заранее установлен способ восстановления.

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

Необязательные персональные и конфиденциальные сведения исключены.

Сравнение с текущим способом будет проведено на одном и том же объёме работы.

Есть условие остановки и дата пересмотра результата.

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

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

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

Человек, модель и зона ответственности

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

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

Инцидент начинается не с ошибки модели

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

Через несколько минут на выходе появляется убедительный документ. В нём сказано, что оборот клиента составляет 48,6 миллиона рублей, просрочка — 1,1 миллиона, доля просрочки — 2,3 процента, число жалоб снижается, а риск дальнейшего сотрудничества оценивается как низкий. В финале модель рекомендует увеличить кредитный лимит и предоставить ещё тридцать дней отсрочки.

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

При сверке исходных данных обнаруживается совсем другая картина.

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

Сумма просрочки в 1,1 миллиона взята из устаревшего снимка реестра. В актуальной выгрузке просрочено 2,4 миллиона. Если пересчитать долю от оборота нужной организации, получится около 7,7 процента, а не 2,3.

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

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

Ни одна из этих ошибок не выглядит фантастической. Модель не допустила одной грандиозной ошибки. Она собрала гладкий вывод из данных, которые относились к разным периодам и объектам учёта и опирались на разные определения показателей. Такой результат опаснее очевидной бессмыслицы: его легче принять за настоящий анализ.

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

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

Четыре роли вместо одного пользователя

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

Постановщик задаёт цель и ограничения. Он отвечает не за красивый запрос, а за точность самой задачи. Его вопрос должен звучать не так: «Сделай анализ клиента». Лучше сформулировать его следующим образом: «Подготовь черновик для решения о продлении отсрочки платежа по юридическому лицу А за период с 1 января по 31 декабря. Покажи динамику задолженности, фактическую маржинальность, риски и недостающие сведения. Не предлагай одобрение без указания порогов и оснований».

Постановщик определяет:

1. Какое решение предстоит принять.

2. Для кого готовится материал.

3. Какие данные относятся к задаче, а какие случайно оказались рядом.

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

5. Что считается приемлемым результатом.

6. Какие действия запрещены без дополнительного согласования.

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

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

Удобно требовать от результата модели четыре слоя:

Факты — то, что прямо следует из источников.

Расчёты — какие операции выполнены и по какой формуле.

Допущения — что принято за основу из-за неполноты данных.

Выводы — какое значение эти данные имеют для поставленного вопроса.

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

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

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

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

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

Полезно держать карту ролей перед глазами:

Постановщик отвечает за вопрос и рамки.

Исполнитель отвечает за подготовленный вариант и прозрачность его происхождения.

Проверяющий отвечает за тестирование фактов, расчётов и выводов.

Владелец решения отвечает за действие и последствия.

Модель может быть исполнителем. Владельцем решения она быть не может.

Пульт управления: контекст, критерии, ограничения

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

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

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

Ограничения очерчивают границу допустимого. Они могут касаться:

состава данных;

срока их актуальности;

доступа к персональным данным;

правил использования конфиденциальных сведений;

допустимых финансовых порогов;

запрета на автоматическую отправку;

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

Рабочую постановку можно собрать так:

«Цель: подготовить черновик для решения о …».

«Вопрос решения: нужно определить …».

«Объект: …».

«Период и дата актуальности: …».

«Источники: использовать только …; если источник не содержит нужных сведений, указать это отдельно».

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

«Ограничения: не раскрывать …; не делать …; не рекомендовать … без проверки …».

«Формат: сначала краткий вывод, затем факты, расчёты, риски, альтернативы и перечень недостающих данных».

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

Такой скрипт не делает модель безошибочной. Он делает ошибку заметной и создаёт условия для проверки.

Сигналы опасного результата

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

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

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

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

Сигнал второй: точный процент без формулы.

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

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

Сигнал третий: на файл есть ссылка, но нет версии и даты.

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

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

Сигнал четвёртый: одно и то же слово используется в разных значениях.

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

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

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

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

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

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

Значит, в запросе не была проведена граница между аналитическим материалом и распоряжением. Совет «одобрить», «отказать», «уволить», «сообщить клиенту» или «перечислить деньги» уже относится к зоне решения.

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

Сигнал седьмой: результат не содержит сомнений.

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

Добавьте в запрос обязательный раздел «Что может сделать вывод неверным». Проверяющий должен заполнить его независимо от модели.

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

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

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

Проверка фактов, расчётов и выводов

Проверка должна идти в три этапа, и каждый отвечает на свой вопрос. Их нельзя свести к одной фразе: «Точно ли это правильно?»

Проверка фактов

Сначала выпишите все утверждения, на которых держится результат. Не только цифры, но и фразы вроде «договор допускает», «клиент ранее нарушал», «срок уже истёк», «показатель снизился».

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

источник;

дату источника;

объект, к которому оно относится;

статус данных;

соответствие формулировки оригиналу.

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

Проверка расчётов

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

Проверяющий отдельно смотрит на:

числитель и знаменатель;

периоды;

налоги и включённые сборы;

валюту и единицы измерения;

округление;

дублирование строк;

пропуски;

изменение правил учёта.

В описанном примере нужно было не просто выяснить, откуда взялись 2,3 процента. Следовало проверить, что сумма задолженности относится к тому же юридическому лицу и периоду, что и оборот. После этого пересчёт 2,4 миллиона к 31,2 миллиона дал 7,7 процента. Даже этот показатель нельзя автоматически трактовать как вероятность неплатежа, но он уже меняет предмет обсуждения.

Проверка выводов

Здесь проверяется переход от данных к решению. Правильная арифметика сама по себе не превращает рекомендацию в правильную.

Цепочка рассуждения должна выглядеть так:

Наблюдение — просрочка по нужному юридическому лицу выросла.

Интерпретация — нужно выяснить причины роста и понять, насколько он устойчив.

Ограничение — одной доли просрочки недостаточно для решения о кредитном лимите.

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

Решение — принимает уполномоченный владелец с учётом установленных порогов.

Проверка на опровержение ищет не подтверждение, а способ разрушить вывод. Для этого полезны пять вопросов:

Какое утверждение здесь наиболее уязвимо?

Какая ошибка в источнике сильнее всего изменит результат?

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

Не объясняется ли изменение показателя сменой методики?

Какие данные должны быть верны, чтобы рекомендация имела смысл?

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

Конфиденциальные сведения и персональные данные

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

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

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

Для рабочего процесса нужны четыре проверки.

Цель. Какие сведения действительно необходимы для ответа? Если задача состоит в сравнении месячных сумм, модели не нужны фамилии клиентов и телефоны менеджеров.

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

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

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

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

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

«Организация А» заменяет название клиента.

«Юридическое лицо 1» заменяет конкретную компанию.

«Менеджер 4» заменяет сотрудника.

Телефоны, адреса, паспортные и банковские сведения удаляются.

Суммы и даты сохраняются только в объёме, необходимом для расчёта.

В запросе прямо указывается: «Не восстанавливай удалённые данные и не делай выводы о конкретных людях».

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

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

Когда модель не может быть владельцем решения

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

К таким решениям относятся:

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