Чтобы выбрать задачу для внедрения ИИ, сначала опишите работу команды, а затем сравните возможные сценарии. Для каждой повторяющейся операции зафиксируйте входные данные, ожидаемый результат, частоту, время сотрудника, способ проверки и цену ошибки. Первым пробным запуском обычно становится задача, которую легко проверить, можно выполнить на разрешённых данных и поручить конкретному сотруднику. Покупка сервиса — один из последних, а не первых шагов.
Ниже — рабочая карта такого аудита. Она помогает выбрать процесс для пилота, но не заменяет проверку информационной безопасности или требований, которые действуют в вашей отрасли.
Чем этот аудит отличается от общего плана внедрения
Общий план внедрения ИИ отвечает на вопрос, как пройти путь от идеи до оценки пилота. Здесь задача уже: сравнить реальные операции компании и выбрать одну для проверки.
Например, «использовать ИИ в продажах» — ещё не задача. «После согласованной встречи готовить черновик письма из заметок менеджера, а перед отправкой сверять договорённости» — задача с понятными входом, результатом и ответственным. Даже для неё сначала нужно выяснить, какие сведения разрешено передавать выбранному инструменту.
Шаг 1. Составьте карту работы, а не список нейросетей
Поговорите с теми, кто выполняет работу ежедневно. Попросите показать несколько обычных задач и одно сложное исключение. Записывайте не названия отделов, а действия:
- что запускает задачу;
- какие документы и сведения нужны;
- что сотрудник делает вручную;
- каким должен быть готовый результат;
- кто принимает или исправляет его;
- сколько раз задача повторяется и сколько времени занимает целиком;
- какие ошибки возникают и что происходит после них.
Достаточно простой таблицы. Не нужно описывать всю компанию до последней операции. Начните с одного направления, где есть заинтересованный руководитель и возможность проверить результат.
| Поле карты | Что записать |
|---|---|
| Задача | Конкретное действие, например подготовка справки к встрече |
| Вход | Откуда приходят сведения и кто вправе их использовать |
| Результат | Как выглядит пригодный для работы ответ |
| Частота и время | Как часто задача возникает; время вместе с проверкой и исправлениями |
| Ответственный | Кто выполняет работу и кто принимает результат |
| Ошибка | Что может пойти не так и как это обнаруживают |
Для каждой задачи зафиксируйте путь от входа до проверки результата.
На этом этапе может оказаться, что проблему решает шаблон документа, ясный регламент или исправление маршрута согласования. Это тоже полезный результат аудита: не каждой повторяющейся задаче нужен ИИ.
Шаг 2. Отсейте сценарии, к которым компания пока не готова
До сравнения ожидаемой экономии задайте четыре вопроса.
- Есть ли ответственный? Сотрудник должен показать образец хорошего результата, проверить ответы и сообщить об ошибках.
- Доступны ли данные? Нужно понимать, кому принадлежат исходные сведения, где они находятся и можно ли использовать их в конкретном сервисе. Если это не ясно, не загружайте их в публичный инструмент ради эксперимента.
- Можно ли проверить ответ? Если ошибка обнаружится только после ущерба клиенту или компании, такой сценарий не подходит для простого первого пилота.
- Можно ли измерить исходную работу? Без времени, объёма и доли исправлений до запуска невозможно честно оценить изменение.
Перед сравнением пользы проверьте четыре обязательных условия пилота.
Если один ответ отрицательный, не обязательно отказываться от идеи навсегда. Сначала назначьте ответственного, подготовьте разрешённые данные, добавьте человеческую проверку или выберите более узкий этап процесса.
Шаг 3. Сравните оставшиеся задачи по пяти критериям
Для короткого списка достаточно шкалы «низко / средне / высоко». Не складывайте оценки в красивый балл, который скрывает критический риск. Сравнивайте сценарии по смыслу:
| Критерий | Вопрос для команды |
|---|---|
| Повторяемость | Возникает ли задача достаточно часто, чтобы улучшение было заметно? |
| Трудозатраты | Сколько времени уйдёт на весь процесс, включая проверку результата ИИ? |
| Проверяемость | Может ли сотрудник быстро отличить пригодный ответ от ошибки? |
| Готовность данных | Есть ли достаточные, актуальные и разрешённые примеры? |
| Цена ошибки | Чем обернётся неверный ответ и можно ли остановить его до применения? |
Частоту и выигрыш по времени оценивайте вместе с данными, возможностью проверки и ценой ошибки.
Высокая частота сама по себе не делает сценарий лучшим. Если для ответа требуется недоступная информация или его нельзя безопасно проверить, начните с другой задачи.
Такой подход согласуется с рамкой управления рисками ИИ NIST: она предлагает учитывать контекст использования, измерять результаты и управлять рисками на протяжении работы системы. Это добровольная рамка, а таблица выше — практический способ обсудить выбор внутри команды, не официальная оценка NIST.
Пример карты: подготовка менеджера к встрече
Представим команду, где менеджер перед каждой встречей собирает сведения из собственных заметок и открытых материалов о компании клиента. Возможный пилот — черновик одностраничной справки: тема встречи, уже известные договорённости, вопросы, которые нужно уточнить, и ссылки на исходные записи.
ИИ готовит черновик справки из доступных источников; менеджер сверяет факты до использования.
Что проверить до запуска: есть ли доступ к этим заметкам; какие данные нельзя передавать внешнему сервису; кто проверит имена, цифры и выводы; сколько времени занимает подготовка сейчас. Для первого теста подойдут вымышленные или обезличенные примеры, если реальные сведения использовать нельзя.
Что будет результатом теста: не «нейросеть написала справку», а ответ на два вопроса: сократилось ли общее время менеджера с учётом проверки и стало ли меньше пропущенных важных пунктов. Если ИИ уверенно добавляет неподтверждённые факты, сценарий нужно ограничить извлечением сведений из предоставленных записей или остановить.
Это иллюстрация метода, а не описание проекта клиента и не обещание экономии.
Шаг 4. Проверьте одну задачу на небольшой серии примеров
Сохраните несколько типичных и нетипичных входов, образцы хорошего результата и короткие критерии проверки. Не оценивайте сценарий по одному удачному ответу. Для каждого прогона отмечайте:
- сколько времени заняли подготовка данных, получение ответа, проверка и исправление;
- какие обязательные сведения сохранены или потеряны;
- какие утверждения нельзя подтвердить исходником;
- сколько раз сотруднику пришлось переделывать ответ;
- смог ли другой сотрудник повторить процесс по инструкции.
Сравнивайте полный цикл работы, включая проверку и исправления.
Для сравнения используйте полное время выполнения задачи. Если раньше сотрудник тратил время на составление справки, а теперь столько же уходит на подготовку запроса и исправление ошибок, экономию заявлять нельзя. Кроме скорости, фиксируйте качество и возможные последствия ошибки.
NIST отдельно рекомендует подбирать показатели под выявленные риски и решать, стоит ли продолжать применение системы с учётом цели и ограничений конкретного сценария. Компания может адаптировать этот принцип к своему небольшому пилоту без сложной системы отчётности.
Примеры задач из проектов ИИ41
В кейсе CNC66 для работы с нейросетями выбрали сметы, расчёты, исследование рынка и персональную коммуникацию. В кейсе PLOV Project × РЫБАLOVE сотрудники практиковались на документах, регламентах, аналитике и визуальном контенте. Эти примеры помогают конкретизировать карту процессов; результаты отдельных компаний не гарантируют такой же эффект в другом бизнесе.
Что должно остаться после аудита
Хороший результат — короткая рабочая папка, а не каталог популярных сервисов:
- карта рассмотренных задач и их владельцев;
- список сценариев, отложенных из-за данных или цены ошибки;
- одна задача для пилота и причина её выбора;
- исходные показатели и критерии успеха;
- разрешённые примеры входа и образец результата;
- порядок проверки ответа человеком;
- решение после пилота: продолжить, изменить процесс или остановиться.
Если задачу предстоит передать нескольким сотрудникам, следующий шаг — обучить команду на её собственных рабочих сценариях. Для предварительного выбора процесса можно обсудить задачу на консультации.
Частые вопросы
Сколько процессов нужно изучить до первого пилота?
Столько, чтобы сравнить несколько реальных альтернатив. Не требуется сначала описывать всю компанию. Один отдел и ограниченный список повторяющихся операций позволяют начать проверку быстрее и увидеть, каких данных не хватает.
Подходит ли задача с конфиденциальными данными?
Возможно, но сначала нужно определить допустимый способ обработки и проверить условия конкретного инструмента. До этого используйте разрешённые или обезличенные примеры. Нельзя считать, что публичный чат автоматически подходит для клиентских документов и внутренних сведений.
Почему не выбрать задачу с максимальной экономией времени?
Потенциальная экономия ничего не говорит о качестве ответа, цене ошибки и возможности проверки. Сначала исключите сценарии, в которых команда не может контролировать результат, затем сравнивайте трудозатраты.
Когда аудит показывает, что ИИ пока не нужен?
Когда работа уже описывается жёсткими правилами и надёжно решается шаблоном или обычной автоматизацией; когда нет пригодных данных, ответственного или возможности проверить результат. Остановить неподходящую идею до закупки и внедрения — полезный итог.