Начинать стоит не с модели

У малого бизнеса обычно нет отдельной команды, которая может месяцами строить платформу данных. Поэтому разумный первый вопрос — не «какую модель купить?», а «какое повторяющееся решение или операция отнимает время, и как мы поймём, что помощник сделал её лучше?».

В исследовании OECD 2026 года об использовании цифровых инструментов и ИИ опрошено более 2 000 малых и средних предприятий из 12 стран. Авторы отдельно предупреждают, что выборка не является репрезентативной для всех компаний. Среди названных участниками препятствий цифровому внедрению — расходы на сопровождение, нехватка времени на обучение и стоимость оборудования. Это полезный ориентир по типу проблем, но не статистика российского рынка и не гарантия такого же порядка барьеров в конкретной компании.

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

Как выбрать узкую задачу

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

Оцените кандидатов по пяти признакам от 1 до 5:

  • частота операции и суммарное время сотрудников;
  • насколько стандартизированы входные материалы;
  • сколько исключений и ручных исправлений встречается;
  • доступность и качество нужных данных;
  • цена ошибки и возможность безопасно вернуть решение на проверку.

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

Сначала зафиксируйте исходный уровень

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

Минимальная базовая линия может включать:

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

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

Подготовьте данные и границы доступа

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

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

Также задайте «контракт» входа и выхода. Например, на входе — письмо и карточка заказа; на выходе — JSON с номером заказа, позицией, количеством, уверенностью и объяснением, какие поля не распознаны. Проверяйте формат и диапазоны обычным кодом. При нехватке информации модель должна вернуть «нужно уточнение», а не сочинять значение.

Минимальная архитектура пилота

Для задачи вроде разбора обращений достаточен небольшой контур:

1. Сервис получает запрос из почты, CRM или тестовой папки и проверяет тип и доступ.
2. Правила удаляют запрещённые поля, добавляют идентификатор операции и выбирают разрешённый источник данных.
3. Модель классифицирует обращение или формирует структурированный черновик; при необходимости RAG извлекает только документы, доступные этому сотруднику.
4. Валидатор проверяет схему, обязательные поля и допустимые значения.
5. Сотрудник подтверждает, исправляет или отклоняет результат. Только после подтверждения данные записываются в CRM.
6. Журнал сохраняет версию модели и промпта, идентификатор источника, решение валидатора и действие человека, но не лишний текст клиента.

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

Как провести пилот за четыре недели

**Неделя 1 — наблюдение.** Владелец процесса описывает текущий путь операции, собирает примеры и считает исходное время. ИТ фиксирует системы-источники, права, поля и ограничения данных.

**Неделя 2 — тестовый набор.** Сотрудник, хорошо знающий процесс, готовит контрольные примеры и правильные ответы. Включите обычные случаи, редкие форматы, неполные документы, конфликтующие значения и заведомо неразрешимые примеры. Отдельно отметьте, при каком сигнале задачу обязательно нужно передать человеку.

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

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

Экономика без магии

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

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

Когда не следует масштабировать

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

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

Что сделать на этой неделе

Выберите один процесс и попросите двух сотрудников показать пять обычных и пять сложных примеров. Запишите время, исключения, источники данных и решение, которое нельзя отдавать модели без подтверждения. После этого станет ясно, нужен ли здесь генеративный ИИ, локальный контур, RAG или обычная автоматизация. Такой короткий аудит часто экономит больше, чем ранняя закупка GPU или пилот на данных, которые никто не проверил.