Суть задачи

Результат дня

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

Исходные данные

Пригласите правильных людей

Нужны представители ИТ, безопасности, юрист, операционный руководитель и два активных пользователя. Не просите всех заполнять длинную анкету заранее. Проведите короткие интервью по пятнадцать минут: какую задачу решаете, что копируете в систему, куда переносите ответ, кто проверяет. Люди часто не считают встроенный переводчик или расшифровку «ИИ», поэтому спрашивайте о действиях, а не о брендах.

Рабочий маршрут

Поля, без которых реестр бесполезен

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

Проверка

Найдите теневое использование

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

Практический пример

Расставьте приоритеты

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

Риски

Проверьте одну красную строку

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

После запуска

Назначьте решения, а не статусы

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

Внедрение

Как поддерживать реестр

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

План на день

Как показать результат руководителю

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

Вывод

Частые вопросы

Нужно ли учитывать личные бесплатные аккаунты? Да, если через них проходит рабочая информация. Включать ли обычные алгоритмы? Реестр можно ограничить генеративными и автономными системами, но границу запишите. Кто владеет строкой: ИТ или бизнес? Владелец процесса отвечает за применение, ИТ — за технический контур. Хороший реестр остаётся коротким, обновляемым и связанным с реальными действиями.