Как внедрить ИИ в команду: чек-лист на первый месяц

Когда вместо внедрения нужен один проверяемый сценарий

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

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

Что должно остаться к концу месяца

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

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

Что подготовить до первого запроса

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

Копируемая карточка сценария

Сценарий: [одна операция]. Вход: [разрешённые материалы]. Черновик: [точный формат]. Проверяет: [роль]. Принимаем, если: [наблюдаемые критерии]. Запрещено: [данные и действия]. Останавливаем, если: [критическая ошибка или нарушение]. Решение в конце месяца: [стоп / ещё ограниченная проверка / разрешение в этих границах].

Заполняйте критерии до первого запроса. Не подгоняйте их под уже получившийся удачный ответ.

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

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

Один маршрут на четыре недели

1. Неделя 1 — зафиксируйте границу. Назначьте владельца, запишите одну операцию и исключите всё, что меняет решения, отправляется наружу без проверки или требует неразрешённых данных.
2. Неделя 1 — проверьте готовность. Ответственный за ИБ, данные или договор подтверждает сервис, аккаунт, доступы и допустимый состав входа. Если подтверждения нет, пилот не начинается.
3. Неделя 1 — установите исходную точку. Возьмите согласованный набор заметок и подготовьте сводки обычным способом. Не превращайте наблюдение в обещание будущей экономии: оно нужно только для сравнения порядка работы и качества.
4. Неделя 2 — выполните ограниченный прогон. Используйте только утверждённые материалы и одну версию инструкции. Каждый черновик проверяйте по исходнику до копирования в рабочий документ.
5. Неделя 2 — записывайте не впечатления, а расхождения: пропущенный факт, добавленное утверждение, неверный приоритет, нарушение формата, лишнее раскрытие или необходимость переписать текст вручную.
6. Неделя 3 — исправьте только подтверждённую проблему. Меняйте один элемент инструкции за раз и повторяйте те же контрольные случаи. Не добавляйте новые отделы, документы или автоматическую отправку.
7. Неделя 4 — разберите журнал вместе с владельцем процесса. Отдельно отметьте качество, трудоёмкость ручной проверки, нарушения границ и случаи, когда обычный способ был надёжнее.
8. Неделя 4 — примите одно решение. «Разрешить» означает сохранить те же данные, проверку и ответственность; любое расширение считается новым сценарием и получает отдельную оценку.

Чек-лист решения после месяца

Не считайте число запросов доказательством пользы. Пройдите вопросы по каждому пункту и приложите к решению журнал, а не устное впечатление.

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

Где пилот ломается и как вернуться в границы

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

Этот маршрут не заменяет закупочную, юридическую, кадровую или информационно-безопасностную проверку. NIST прямо описывает свою рамку как добровольную и адаптируемую, а руководство Microsoft относится к конкретному продукту. Переносите только принцип: готовность и критерии проверяются до расширения доступа.

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