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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Через несколько минут на выходе появляется убедительный документ. В нём сказано, что оборот клиента составляет 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» заменяет сотрудника.

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

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

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

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

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

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

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

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

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