Туториал: подготовить данные для AI-пилота за 1 день

Формулировка «внедрить AI в коммерческий отдел» звучит бодро, но делать с ней нечего. Для пилота нужен один маршрут: обработка обращения, извлечение полей из счёта, квалификация заявки, поиск ответа по регламенту или детекция события на видео.

Чем уже процесс, тем быстрее видно, есть ли там повторяемость, данные и экономический смысл. Узко - это не бедно. Узко - это проверяемо.

Минимальный набор - 10-30 реальных входов и желаемых выходов. Для поддержки это обращения и хорошие ответы. Для OCR - документы и таблица полей. Для CV - видеофрагменты и список событий. Для квалификации лидов - заявки и решение менеджера.

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

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

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

Данные без определения результата быстро превращаются в папку «посмотрите, что можно сделать». Для пилота нужно заранее описать, как должен выглядеть выход системы. Ответ в чат, таблица полей, JSON для CRM, список событий, карточка лида, черновик письма, отчёт менеджеру - это разные продукты и разные критерии качества.

Полезно собрать 5-10 примеров «идеального выхода». Не абстрактно, а буквально: вот входящее обращение, вот хороший ответ; вот документ, вот нужные поля; вот видеофрагмент, вот событие и отметка времени. Такие пары быстрее всего показывают команде, что именно нужно автоматизировать.

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

Для каждого плохого случая напишите ожидаемое поведение: ответить, уточнить, отказать, отправить человеку, поставить статус «нужна проверка». Это сразу снижает ожидание магии и помогает построить AI-контур, который честно признаёт ограничения.

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

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

В конце дня у вас должен получиться не большой документ, а короткий brief. В нём: один процесс, 10-30 примеров, желаемый результат, список плохих случаев, ограничения данных, текущая ручная стоимость и метрика успеха. Этого достаточно, чтобы техническая команда предложила 2-3 реалистичных сценария.

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