Роли в компании, ориентированной на ИИ: как меняются ревьюеры, операторы и эксперты

Почему эти роли меняются первыми

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

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

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

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

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

Что делают ревьюеры сейчас

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

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

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

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

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

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

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

Полезные заметки ревью остаются конкретными. «Неправильно» никому не говорит, что исправлять. «Использован старый прайс-план» — говорит.

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

Как операторы управляют потоком

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

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

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

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

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

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

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

Где предметные эксперты приносят больше пользы

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

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

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

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

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

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

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

Простой способ перепроектировать роли

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

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

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

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

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

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

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

Реалистичный пример из команды поддержки

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

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

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

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

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

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

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

Ошибки, которые команды совершают в первый месяц

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

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

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

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

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

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

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

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

Быстрые проверки перед изменением обязанностей

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

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

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

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

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

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

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

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

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

Следующие шаги для небольшого и безопасного запуска

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

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

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

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

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

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

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

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