Начните с одной повторяющейся задачи, для которой понятны исходные данные, результат и способ проверки. Подготовка черновика ответа клиенту или разбор одного типа документов — возможные кандидаты. Выбор стоит подтвердить небольшим испытанием: сравнить работу с ИИ и без него, учитывая время сотрудника на проверку и исправления.
Ниже — предлагаемый порядок первого пилота, то есть ограниченного испытания на ваших задачах. Это не обещание окупаемости и не универсальный регламент для любой компании.
Опишите, что именно нужно изменить
Формулировка «хотим внедрить ИИ» не объясняет, что должно улучшиться. Попробуйте описать задачу через конкретную работу:
Менеджер читает входящее обращение, находит информацию в справочнике и составляет ответ. Нужно проверить, поможет ли ИИ готовить черновик быстрее, не добавляя неподтверждённых условий.
Это условный пример, а не история реального внедрения.
Для своего процесса запишите:
- Что запускает работу: письмо, документ, заявка, поручение.
- Что получает сотрудник на входе.
- Какой результат должен появиться.
- По каким правилам проверяется правильность.
- Кто отвечает за результат и разбирает ошибки.
У NIST в рекомендациях по управлению рисками ИИ есть сходная отправная точка: определить задачу, назначение и минимально необходимую функциональность системы. Там же предлагается рассмотреть варианты без ИИ.1
Если достаточно готового шаблона, формулы в таблице или обычного правила автоматизации, включите этот вариант в сравнение. Покупать ИИ ради самого факта его использования необязательно.
Выберите задачу, которую можно проверить без опасного эксперимента
Для первого испытания предлагаю сравнить кандидатов по четырём вопросам:
| Вопрос | Что нужно выяснить |
|---|---|
| Есть ли доступные примеры? | На чём проверять работу и можно ли использовать эти материалы |
| Понятен ли правильный ответ? | Кто сможет отличить пригодный результат от ошибочного |
| Можно ли ограничить полномочия? | Будет ли система только готовить черновик, без отправки и изменения данных |
| Есть ли исходное измерение? | Сколько времени и исправлений задача требует сейчас |
Например, можно испытывать подготовку черновиков ответов по утверждённому справочнику. Автоматическую отправку клиентам в такое испытание включать не нужно.
Другой кандидат — извлечение заданных полей из документов с последующей сверкой сотрудником. Само наличие файлов ещё не делает этот сценарий подходящим: сначала нужны примеры, правила извлечения и проверка допустимости обработки данных.
Если ошибка затрагивает деньги, обязательства перед клиентом или доступ к важным данным, заранее определите предел допустимого риска. NIST отдельно рекомендует устанавливать границу, выше которой систему не вводят в работу.2
Зафиксируйте работу без ИИ
Возьмите набор разрешённых к использованию задач и запишите, как они выполняются сейчас. Для каждого случая отметьте время работы, результат и необходимые исправления.
В тестовый набор стоит включить разные ситуации: обычное обращение, неполные сведения, противоречивый запрос и вопрос, на который в справочнике нет ответа. Отдельно сохраните примеры для итоговой проверки, которые не использовались при настройке.
Заранее договоритесь, что будете считать успехом. Например:
- Полное время сотрудника на задачу сокращается, включая проверку результата.
- Качество соответствует заранее записанным требованиям.
- Система не выполняет запрещённых действий.
- Затраты на инструмент и поддержку приемлемы для бизнеса.
Размер набора и целевые значения выбирайте под свой процесс. Несколько удачных демонстраций не следует принимать за проверку всех будущих ситуаций. В рекомендациях NIST предусмотрены документирование тестовых наборов и метрик, а также фиксация условий, в которых проверена надёжность системы.3
Дайте системе понятные источники и границы
Для условного помощника менеджера подготовьте утверждённый справочник, примеры допустимых ответов и правила обработки неизвестных вопросов.
Инструкция для испытания может выглядеть так:
Подготовь черновик ответа по приложенному справочнику. Не добавляй цены, сроки и условия, которых в нём нет. Если информации недостаточно, перечисли вопросы для менеджера. Ничего не отправляй клиенту.
Это стартовый шаблон, не гарантия правильности. Проверьте на примерах, соблюдает ли выбранная система каждое ограничение. Если есть подключённые инструменты, ограничьте права технически: у системы не должно быть доступа к отправке сообщений клиентам. Одной фразы «ничего не отправляй» недостаточно.
Не начинайте испытание с загрузки всей рабочей базы. Сначала определите допустимые данные, круг пользователей и необходимые права доступа. До выяснения того, как сервис хранит загруженные данные, кто имеет к ним доступ и используются ли они для обучения моделей, используйте искусственные примеры без клиентских сведений и коммерческих секретов. Такой тест проверяет предварительную идею, но не заменяет испытания на разрешённых рабочих материалах.
Проверьте весь путь до пригодного результата
Для каждой задачи сохраните входные данные, ответ системы, замечания сотрудника и итоговый вариант. Измеряйте не только скорость генерации: учитывайте подготовку запроса, поиск источника, чтение ответа и исправления.
Отдельно разберите ошибки:
- В источнике не было нужной информации.
- Система пропустила существенное условие.
- В ответе появилось неподтверждённое утверждение.
- Формат оказался неудобен для дальнейшей работы.
- Сотрудник не понял, что требуется проверить.
Назначьте ответственного за приёмку и определите, какие случаи обязательно передаются человеку. Разделение ролей и ответственности при работе человека с ИИ предусмотрено в NIST Playbook.4
Удачная проверка черновика не подтверждает готовность автоматической отправки, записи в CRM или изменения бронирований. Для каждого нового действия нужны отдельные ограничения и испытания.
Решите, продолжать ли внедрение
Сопоставьте результаты с исходными измерениями и требованиями. Возможны три решения:
Продолжить: результат соответствует требованиям, полные трудозатраты и расходы приемлемы. Следующий этап тоже ограничьте по объёму и полномочиям.
Доработать: понятна причина ошибок и есть проверяемый способ её устранить. После изменения повторите затронутые проверки.
Остановить: пользы не получилось подтвердить либо риск и затраты неприемлемы. Отказ от неподходящего решения — допустимый итог пилота.
До работы на реальных обращениях предусмотрите возврат к обычному процессу: кто отключает систему, по каким признакам и как сотрудники продолжат работу. Возможность обхода или отключения системы с назначенной ответственностью отдельно рассматривается NIST.5
Что подготовить для обсуждения внедрения
Вместо запроса «сделайте нам ИИ» составьте короткую карточку задачи:
- Процесс: что сотрудник делает сейчас.
- Проблема: что именно требуется улучшить.
- Примеры: какие материалы разрешено использовать для проверки.
- Результат: что система должна выдавать.
- Качество: какие ошибки недопустимы и как проверяется ответ.
- Полномочия: что система может делать и что ей запрещено.
- Измерение: с чем сравнивается результат испытания.
- Ответственный: кто принимает работу и останавливает эксперимент.
Начать можно с этой карточки и одного процесса. Она поможет предметно обсудить решение — в том числе выяснить, нужен ли для него ИИ вообще.
Источники
NIST AI RMF Playbook — добровольные рекомендации по управлению рисками ИИ. Это не обязательный стандарт внедрения и не подтверждение эффективности конкретного сервиса. Ссылки проверены при подготовке черновика 26 октября 2026 года.