Практика внедрения
Как принять решение после ИИ-пилота: протокол масштабировать, доработать или остановить
Одностраничный протокол решения после корпоративного ИИ-пилота: фактические показатели, пороги, полная стоимость и ответственные за следующий шаг.
После корпоративного ИИ-пилота команда должна выбрать одно из трёх действий: масштабировать процесс, доработать его и повторить проверку либо остановить. Для этого недостаточно удачной демонстрации или общей оценки «стало быстрее». Нужен короткий протокол, который связывает исходные пороги, фактические результаты, ограничения доступа и полную стоимость следующего этапа.
Ниже — структура такого протокола. Заполняйте её для одного процесса и одной версии ИИ-функции. Если по важному показателю нет сопоставимых данных, фиксируйте «данных недостаточно», а не подменяйте измерение впечатлением.
Что приложить к решению
До обсуждения соберите пять материалов:
- Паспорт ИИ-функции с владельцем процесса, входами, результатом и ограничениями.
- Реестр базы знаний с версиями источников и ответственными за обновление.
- Матрицу доступа и подтверждений с результатами отрицательных тестов.
- Рабочую таблицу приёмки с исходными и фактическими значениями на одинаковом наборе операций.
- Расчёт полной стоимости следующего этапа: платформа, внедрение и использование LLM отдельными строками.
Если во время пилота менялись документы, права, модель или правила проверки, укажите версии и даты. Иначе участники могут принять результат одной конфигурации за доказательство для другой.
Одностраничный протокол
Скопируйте шаблон в рабочий документ и заполните его фактами пилота.
| Поле | Что записать |
|---|---|
| Процесс | Одна повторяемая операция и её границы |
| Владелец решения | Руководитель, который отвечает за результат и следующий шаг |
| Период и объём проверки | Даты, число операций и состав одинакового тестового набора |
| Версия функции | Ссылки на паспорт, базу знаний, матрицу доступа и конфигурацию LLM |
| Участники | Бизнес-владелец, ИТ, ИБ, проверяющие и партнёр по внедрению |
| Решение | Масштабировать / доработать / остановить |
| Обоснование | Какие пороги пройдены, не пройдены или не имеют достаточных данных |
| Следующий шаг | Действие, ответственный и дата повторной проверки |
Таблица показателей
| Показатель | Исходное значение | Порог | Факт | Статус | Подтверждение |
|---|---|---|---|---|---|
| Время до принятого результата | Пройден / не пройден / данных недостаточно | Выгрузка или журнал замеров | |||
| Доля результатов с существенными правками | Пройден / не пройден / данных недостаточно | Сохранённые версии до и после проверки | |||
| Завершённые операции | Пройден / не пройден / данных недостаточно | Реестр тестовых операций | |||
| Критические ошибки | 0 или иной согласованный порог | Пройден / не пройден / данных недостаточно | Карточки ошибок и решение владельца | ||
| Расход на LLM | Пройден / не пройден / данных недостаточно | Отчёт провайдера или прокси за тот же период | |||
| Отрицательные тесты доступа | Не применимо | Все обязательные тесты пройдены | Пройден / не пройден / данных недостаточно | Матрица и журнал проверок |
Порог задают до просмотра итогов. Если его меняют после пилота, в протоколе нужно сохранить прежнее значение, новое значение и причину изменения.
Как выбрать итоговое действие
Масштабировать
Выбирайте этот вариант, когда обязательные пороги качества и безопасности пройдены, данных достаточно, а владелец процесса понимает стоимость и операционные обязанности следующего этапа. Масштабирование относится только к проверенной функции и согласованному контуру. Оно не доказывает готовность других процессов.
Доработать
Этот вариант подходит, если причина отклонения локализована и её можно проверить повторно: например, обновить набор источников, изменить формат результата, уточнить роль подтверждающего или исправить правило доступа. В протоколе перечислите доработки, владельцев и тот же набор тестов для повторного прогона. Не объединяйте несколько неизвестных причин в формулировку «нужно улучшить ИИ».
Остановить
Останавливайте сценарий, если нарушено обязательное ограничение безопасности, критическая ошибка воспроизводится, пригодный результат не достигается в согласованных условиях либо стоимость и трудоёмкость не соответствуют задаче. Остановка одного сценария не является выводом о всех возможностях корпоративного ИИ; это решение по конкретной функции и её текущей конфигурации.
Отдельно проверьте экономику следующего этапа
Для минимальной конфигурации Тау Хаб на 20 рабочих мест платформа стоит 1 500 ₽ за место в месяц, то есть 360 000 ₽ в год. Внедрение оплачивается отдельно и составляет 1,9–2,1 млн ₽. Поэтому стоимость первого года для 20 мест — 2,26–2,46 млн ₽ без расходов на LLM. Использование LLM всегда добавляется отдельно: по ключу заказчика либо через прокси Тау. Эти значения актуальны на 22 сентября 2026 года; условия конкретного проекта нужно закрепить в коммерческом предложении.
Если в расчёте используются 800 ₽ за час и гипотеза роста производительности на 25%, пометьте их как сценарные допущения. Это не наблюдаемый результат клиента и не обещание ROI. Подробная методика расчёта приведена в статье об экономике ИИ-пилота.
Пример решения без выдуманного эффекта
Допустим, команда проверяла подготовку проекта протокола встречи. Это иллюстративный пример, а не клиентский результат.
- Порог по критическим ошибкам пройден: ни одно решение или ответственное лицо не было добавлено без источника.
- Порог по существенным правкам не пройден: проверяющие меняли смысл части формулировок.
- Отрицательный тест доступа пройден: роль без разрешения не получила расшифровку.
- Данных о времени недостаточно: часть операций измерялась от загрузки записи, а часть — от открытия задачи исполнителем.
Корректное решение в таком случае — доработать, а не масштабировать. Команда уточняет формат результата, выравнивает способ измерения времени и повторяет тот же набор операций. Причины и дата повторной проверки записываются в протоколе.
Как провести встречу по решению
- Владелец процесса подтверждает границы и версию проверяемой функции.
- Ответственный за измерения показывает исходные данные, пороги и фактические значения.
- ИТ и ИБ подтверждают конфигурацию, маршрут данных, права и результаты отрицательных тестов.
- Команда разбирает каждый непройденный порог и каждую строку «данных недостаточно».
- Финансовый владелец проверяет платформу, внедрение и LLM как отдельные части бюджета.
- Участники выбирают одно действие, назначают владельца следующего шага и дату проверки.
Решение считается завершённым, когда его можно воспроизвести по приложенным материалам. Если обоснование сводится к впечатлению от демонстрации, пилот ещё не дал достаточных данных для масштабирования.
Следующий шаг
Возьмите фактические строки из таблицы приёмки и перенесите их в одностраничный протокол. Для каждого показателя поставьте статус, приложите подтверждение и назначьте владельца следующего действия. После этого обсудите с командой Тау Хаб конфигурацию и объём следующего этапа — только для того процесса, по которому принято решение.