Готовность к пилоту: чек-лист без произвольного балла

Опрос «готов ли бизнес к ИИ» часто заканчивается суммой баллов. Но одинаковый итог может скрывать противоположные риски: у одной команды нет источника данных, у другой — владельца эскалации. Среднее число создаёт уверенность, не подсказывая, что исправлять.

Готовность лучше оценивать по блокирующим условиям и доказательствам. Практический вопрос: можем ли мы безопасно проверить одну гипотезу в ограниченной области? Ответ «нет» не закрывает проект; он превращается в короткий список предпосылок.

Есть ли конкретный процесс

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

Соберите типичные и сложные примеры. Отметьте исключения, ручные решения и причины передачи. Если команда сама расходится в правильном ответе, сначала нужен процесс или источник, а не более убедительная модель.

Определите, что не входит в пилот. Явная граница защищает от случайного расширения после красивой демонстрации.

Доступны ли проверяемые данные

У источника есть владелец, дата и правила обновления. Для статуса используется система учёта, для регламента — канонический документ, для расписания — календарь. Переписка и память сотрудника не становятся источником истины автоматически.

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

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

Определены ли права и последствия

Разделите чтение, черновик и действие. Первый пилот часто может ограничиться чтением и передачей. Учётная запись получает минимальные разрешения; секрет хранится отдельно от подсказки и журнала.

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

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

Моделируемый сценарий

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

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

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

Есть ли эксплуатационный маршрут

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

Проверьте /healthz, /readyz с фактическими проверками, внешний маршрут, журнал и пользовательский путь. Восстановите резервную копию в изолированной среде. Техническая зелёная лампа не заменяет процесс.

Запишите, кто меняет подсказку, интеграцию и документ, как проходит повторная приёмка и где хранится версия.

Как принять решение

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

Пилот готов, когда ограниченная гипотеза, данные, права, эскалация, измерение и остановка согласованы. Это не означает готовность ко всем отделам и каналам. Расширение проходит новую проверку.

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

Карта обязательных доказательств

Чек-лист полезен, когда каждый пункт связан с наблюдаемым артефактом. «Безопасность проверена» ничего не говорит; «секрет отсутствует в тестовом журнале после ошибки аутентификации» можно воспроизвести. Для канала доказательством станет внешний идентификатор и подтверждённый статус, для резервной копии — восстановление в изолированной среде, для передачи человеку — запись в очереди владельца.

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

Моделируемый сценарий: перед пилотом команда проходит карту внутреннего справочного агента. Канал, источники и чтение работают, но тестовый пользователь другой группы видит документ вне своей области. Хотя большинство пунктов зелёные, запуск блокируется. После исправления повторяют именно проверку изоляции и сквозной маршрут, прикладывая результаты к версии конфигурации. Старые доказательства не переносят автоматически на изменённые права.

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

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

Перед подписью владелец процесса читает список исключений и подтверждает, что сопровождение способно их обработать. Формулировка «будет исправлено позже» получает задачу и временное ограничение, иначе это не принятое предупреждение. При истечении срока пункт снова становится блокирующим. Такой цикл не позволяет красной проблеме раствориться в старом протоколе.

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

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

Результат просмотра снова связывают с активной версией и областью допуска.