Разговор о внедрении искусственного интеллекта в компании обычно начинается не с той стороны: сначала выбирают модель, потом ищут, куда её приткнуть. Мы в проектах идём наоборот — от задачи, у которой есть измеримая стоимость, и от данных, которые под эту задачу уже накоплены. Ниже — то, что мы проверяем до старта, как ограничиваем пилот и какие подводные камни встречаются чаще остальных.
Где ИИ окупается, а где нет
ИИ хорошо закрывает задачи, где много однотипных операций, результат допускает проверку человеком, а ошибка не стоит критически дорого. Это разбор входящих обращений, черновики ответов, извлечение данных из документов, поиск по внутренней базе знаний, классификация заявок, первичная сортировка резюме или рекламаций.
Плохо окупается всё, где ответ должен быть единственно верным и юридически значимым: расчёт налогов, окончательное решение по кредиту, медицинские заключения, финальная цена в договоре. Здесь модель может быть подсказчиком, но не источником решения. Отдельная категория — задачи, которые проще закрыть обычным кодом: если в компании есть чёткий регламент из пятнадцати правил, его дешевле запрограммировать, чем обучать модель.
Ещё один частый случай — задача редкая. Если операция выполняется десять раз в месяц и занимает пять минут, автоматизировать её нечем окупить. Считать надо не долю автоматизации, а количество операций, умноженное на стоимость одной.
Сценарии: что даёт и что требует
| Сценарий | Что даёт компании | Что нужно подготовить |
|---|---|---|
| Ответы на типовые вопросы клиентов | Снимает нагрузку с первой линии, отвечает вне рабочих часов | Актуальная база вопросов и ответов, регламент передачи сложных случаев человеку |
| Поиск по внутренним документам | Сотрудник находит регламент или договор, не спрашивая коллег | Документы в разборном виде, права доступа, единое хранилище |
| Извлечение данных из счетов и накладных | Меньше ручного ввода, меньше опечаток в учётной системе | Образцы документов всех форматов, правила проверки результата |
| Черновики текстов и описаний | Ускоряет работу редактора и контент-менеджера | Примеры принятого стиля, обязательная вычитка перед публикацией |
| Классификация обращений и заявок | Заявка сразу попадает нужному отделу | История обращений с проставленными категориями |
| Прогноз спроса и остатков | Подсказка закупщику, снижение неликвида | История продаж за несколько сезонов, данные об акциях и дефиците |
Данные: чем придётся заняться до модели
Готовность данных — это не объём, а пригодность. Мы смотрим на четыре вещи: где данные лежат, в каком они формате, кто отвечает за их актуальность и можно ли их выгружать за пределы контура. Типичная картина — часть информации в учётной системе, часть в почте, часть в таблицах у сотрудников, а самое ценное в головах.
- Полнота. Если в половине карточек не заполнено поле, модель будет угадывать на нём, а не отвечать.
- Единообразие. Один и тот же контрагент, записанный тремя способами, ломает любую аналитику ещё до ИИ.
- Актуальность. База знаний двухлетней давности приведёт к уверенным ответам по отменённым правилам.
- Разметка. Для классификации нужны примеры с проставленными категориями, а не просто архив.
- Правовой статус. Персональные данные и коммерческая тайна требуют отдельного решения по хранению и передаче.
Часто наведение порядка в данных даёт заметный эффект само по себе, ещё до подключения модели. Это нормальный результат, и мы предупреждаем о нём заранее.
Пилот: как ограничить, чтобы он закончился
Пилот без границ превращается в бесконечную доработку. Мы ограничиваем его по четырём осям: один сценарий, один отдел, фиксированный набор данных, заранее названный критерий успеха. Всё, что не входит в эти рамки, записывается в список следующего этапа, а не добавляется по ходу.
- Формулируем задачу одним предложением и указываем, кто будет пользоваться результатом ежедневно.
- Собираем набор реальных примеров и вручную готовим эталонные ответы — это будущая линейка для замера.
- Собираем прототип и запускаем в режиме подсказки: решение остаётся за человеком.
- Смотрим не только долю правильных ответов, но и характер ошибок: разовые они или системные.
- Принимаем решение — расширять, переделывать или закрывать. Закрыть пилот, который не сработал, дешевле, чем тянуть его из принципа.
Риски, о которых лучше договориться заранее
Уверенные ошибки
Языковые модели порождают правдоподобный текст, а не проверенный факт. Ссылка на несуществующий пункт регламента выглядит так же убедительно, как настоящая. Лечится это не уговорами модели, а архитектурой: ответ строится по найденным документам, в интерфейсе показывается источник, а при отсутствии источника система отвечает, что данных нет.
Утечка данных
Отправляя запрос во внешний сервис, компания передаёт туда содержимое запроса. Поэтому мы разделяем контуры: что уходит наружу, что обрабатывается внутри, что не покидает компанию вообще. Отдельно проверяется, не попадают ли в подсказку модели поля с персональными данными за компанию.
Зависимость от поставщика
Поставщик может изменить условия, поднять цену, отключить версию модели или закрыть доступ из региона. Снижает риск простая дисциплина: логика приложения не завязана на конкретный интерфейс поставщика, подсказки и настройки хранятся в коде проекта, есть проверенный запасной вариант.
Юридическая сторона
Обработка персональных данных, согласия пользователей, требования к месту хранения, ограничения по отраслям — всё это решается до запуска, а не после первой претензии. Если ИИ общается с клиентом, человек должен понимать, что перед ним автоматический ответ, и иметь возможность перейти к сотруднику.
Как измерять результат
Показатели выбираются до пилота, иначе после запуска всегда найдётся цифра, которая выглядит хорошо. Мы опираемся на пары: сколько операций закрыто без человека и сколько из них пришлось переделывать; сколько времени занимает задача до и после; сколько обращений дошло до второй линии. Отдельно фиксируется стоимость обращения к модели — при росте нагрузки она перестаёт быть незаметной.
Полезно сохранять исходный замер до внедрения. Без него сравнивать будет не с чем, а спор о пользе превратится в обмен впечатлениями.
Кто отвечает за внедрение
Проект без владельца со стороны бизнеса не доводится до конца. Нужен человек, который знает процесс, имеет право менять регламент и принимает результат. Технический подрядчик отвечает за архитектуру, интеграции и качество ответов, но не может решить за компанию, какой ответ считается верным.
Вторая обязательная роль — сотрудники, которые работают с системой ежедневно. Их замечания на пилоте важнее общих оценок: именно они первыми видят, где модель ошибается системно, а где мешает интерфейс, а не сама модель.
Если вы примеряете ИИ к конкретной задаче и хотите начать с ограниченного пилота, посмотрите, как мы это делаем: разработка ПО с искусственным интеллектом. Разберём задачу, оценим готовность данных и предложим формат первого этапа.
