Карта пилота ИИ в компании

Пилот ИИ нужен, чтобы проверить один прикладной сценарий, а не сразу “внедрить нейросети в компанию”. Хороший пилот длится 2–6 недель, использует ограниченный набор данных, имеет владельца процесса, метрики качества, правила доступа и заранее описанные условия остановки.

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

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

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

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

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

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

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

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

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

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

• прототип или проверяемый demo-контур;
• отчет по метрикам, ошибкам и ограничениям;
• карта данных и доступов;
• backlog доработок;
• архитектурное решение: RAG, LLM-agent, обычная автоматизация или отказ;
• решение о масштабировании, ограничении или остановке.

Если пилот связан с документами и базой знаний, используйте чек-лист подготовки RAG-системы. Если нужен ассистент с доступом к внутренним источникам, проверьте доступы и безопасность. Для developer workflow есть отдельный чек-лист пилота AI coding agents.

Общую рамку внедрения описывает материал про внедрение искусственного интеллекта в бизнес. Для проектного обсуждения можно перейти к разработке и внедрению RAG-систем.