Что показывает программа для 100 малых компаний

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

AI Sweden описывает другой маршрут. В рамках проекта AI Change Agent West организация помогла 100 малым и средним предприятиям западной Швеции начать путь к работе с данными и ИИ. Для участников был предусмотрен проект длительностью 6–8 недель: вводные занятия, оценка AI-зрелости и воркшоп по поиску практических сценариев с бизнес-пользой. В материалах подчёркнуты доменная экспертиза, качество данных и принцип «большая цель, маленький старт».

Это не доказательство одинаковой окупаемости для всех 100 компаний: опубликованная страница не даёт сопоставимых цифр экономического эффекта по каждому участнику. Ценность примера — в структуре пилота. Сначала компания проверяет готовность и выбирает задачу, затем решает, какая технология нужна. Ниже — адаптация такого маршрута для российского МСП с явными воротами качества, безопасности и экономики.

Неделя 0: зафиксировать процесс без ИИ

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

Зафиксируйте минимум:

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

Формулировка «помочь отделу продаж» слишком широка. Рабочая формулировка звучит так: «сформировать черновик ответа по заявке из CRM, используя утверждённый каталог и историю клиента; менеджер проверяет и отправляет». Здесь понятны вход, выход, владелец и граница ответственности.

Неделя 1: оценить готовность, а не энтузиазм

Пилотный инструмент OECD для оценки AI-готовности МСП рассматривает цифровую основу, навыки, способ хранения данных, текущий уровень использования ИИ, правила, риски и барьеры. Для российской компании важна не итоговая метка инструмента, а перечень вопросов.

Проведите короткую инвентаризацию:

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

Если данные приходят в виде неразобранных сканов, версии документов смешаны, а права доступа существуют только «по договорённости», пилот следует сузить. Иногда лучший результат первой недели — не модель, а нормализованный справочник, шаблон документа или порядок доступа.

Неделя 2: выбрать один сценарий по четырём критериям

Соберите пять–семь кандидатов и оцените каждый по шкале от 1 до 5:

1. **Частота и трудоёмкость.** Процесс должен повторяться достаточно часто, чтобы эффект можно было измерить.
2. **Готовность данных.** Нужны доступные и законно используемые примеры входов и правильных результатов.
3. **Цена ошибки.** Для первого пилота лучше задача, где человек может недорого проверить черновик.
4. **Простота интеграции.** Один источник и один выход лучше цепочки из пяти систем.

Не выбирайте сценарий только за «вау-эффект». Автономная отправка писем, изменение цен или проведение платежей добавляют риск и усложняют измерение. Черновик ответа, поиск фрагмента регламента или заполнение карточки дают более чистый эксперимент.

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

Неделя 3: выбрать минимальную архитектуру

Архитектура следует из задачи.

**Обычная автоматизация без LLM** подходит, если правила стабильны и результат можно получить формулами, регулярными выражениями или справочником. ИИ не нужен только потому, что поле содержит текст.

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

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

**RAG** нужен, если ответы должны опираться на изменяемые внутренние документы. Тогда проект включает не только LLM, но и извлечение, очистку, разбиение, метаданные, фильтры прав, поиск и ссылки на источники.

**Агент** оправдан только для многошагового процесса с инструментами. В первом пилоте оставьте агенту чтение и подготовку черновика; запись в CRM, отправку сообщения или изменение заказа выполняйте после явного подтверждения человека.

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

Неделя 4: собрать теневой режим

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

Журналируйте не весь конфиденциальный текст, а необходимые события:

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

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

Неделя 5: проверить качество и риск

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

NIST AI Risk Management Framework предлагает встраивать управление надёжностью в проектирование, использование и оценку AI-систем. Для небольшого пилота это можно свести к практической карте:

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

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

Неделя 6: принять решение по воротам

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

Решение о продолжении возможно, когда одновременно выполнены условия:

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

Экономика считается относительно базового процесса:

**эффект за период = сэкономленные часы + предотвращённые потери − все расходы пилота и эксплуатации.**

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

Что подготовить руководителю к старту

Потребуется не техническое задание на платформу, а короткий пакет:

  • паспорт одного процесса;
  • базовые метрики за две–четыре недели;
  • 50–200 разрешённых примеров для теста;
  • владелец процесса и ответственный за данные;
  • перечень запрещённых действий и чувствительных полей;
  • лимит бюджета и времени команды;
  • дата решения go/no-go.

Шестинедельный формат не гарантирует внедрение. Он ограничивает стоимость неопределённости. Если компания не может собрать примеры, назначить владельца или определить полезный результат, это становится видно до закупки оборудования и лицензий.

Управленческий вывод

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

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