AI Landmark

Как выбрать первую задачу для ИИ-агента в офисе

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

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

Выберите работу, результат которой можно проверить

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

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

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

Договоритесь о доступах и действиях

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

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

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

Проверьте пилот на неудобных примерах

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

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

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

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

Считайте время вместе с исправлениями

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

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

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