У компании может быть один договор с поставщиком AI и десятки способов использования его сервиса. Кто-то готовит черновики писем, кто-то загружает договоры, а кто-то подключил модель к системе заявок. В платёжном отчёте это одна строка. По составу данных, полномочиям и последствиям ошибки — разные процессы.
Чтобы решить, что развивать, ограничивать или отключать, нужен реестр фактического использования AI. Его полезность определяется тем, можно ли по записи найти владельца процесса, понять движение данных и безопасно остановить работу системы.
Что считать отдельной системой
Начните с выполняемой операции. «Используем языковую модель» слишком широко. «Готовим ответ на обращение из сервисной системы; сотрудник проверяет и отправляет» уже позволяет обсуждать качество и ответственность.
Разделяйте записи, когда меняются разрешённые данные, полномочия или ответственный за результат. Черновик ответа и автоматическое изменение клиентского тарифа должны проходить отдельную оценку, даже если работают на одной модели.
Общие компоненты при этом стоит связывать: одна платформа, несколько сценариев, общий договор. Так реестр помогает увидеть зависимости и не заставляет несколько раз учитывать одну инфраструктурную статью расходов.
Инвентаризация AI-систем и назначение ответственных предусмотрены в NIST AI RMF Playbook, GOVERN 1.6. Предлагаемая ниже карточка — рабочий формат для небольшой команды, а не обязательная форма NIST.
Минимальная карточка, с которой можно принять решение
Ниже — условный пример для помощника службы поддержки. Он описывает вымышленную конфигурацию.
| Поле | Содержание записи |
|---|---|
| Операция и результат | Подготовить черновик ответа по зарегистрированному обращению |
| Владелец процесса | Руководитель поддержки; утверждает правила обработки |
| Технический ответственный | Команда сервисной платформы; отвечает за интеграцию и отключение |
| Пользователи | Сотрудники первой линии |
| Входные данные | Текст обращения и разрешённые статьи базы знаний |
| Запрещённые данные | Платёжные реквизиты и вложения вне согласованного перечня |
| Полномочия | Чтение обращения и создание черновика; отправка недоступна |
| Проверка результата | Сотрудник сверяет условия ответа и источник |
| Экономика | Общий договор платформы и отдельно измеряемое потребление сценария |
| Аварийный режим | Генерация отключается; обращения продолжают обрабатываться вручную |
К карточке полезно привязать версию конфигурации, сведения о хранении данных и ссылку на журнал изменений. Секреты, ключи доступа и реальные клиентские сообщения в реестр не переносят. Для обнаружения зависимости достаточно указать её тип и владельца.
Как найти то, чего нет в официальном списке
Сопоставьте три источника: закупки, технические подключения и разговор с исполнителями процесса. Ни один из них отдельно не показывает полную картину.
В закупках видны лицензии и счета, но может отсутствовать эксперимент, оплаченный сотрудником. В технических настройках видны интеграции и разрешения, но ручная загрузка файлов в сторонний сервис может проходить вне этих подключений. Исполнитель знает реальный маршрут задачи, включая копирование между окнами и дополнительную проверку ответа.
Попросите показать конкретную операцию на обезличенном примере: откуда появляется вход, куда уходит результат, что человек исправляет и что делает при отказе сервиса. Такой проход выявляет условия, которые теряются в ответе «мы только пишем тексты».
Обнаруженный инструмент сначала описывают и оценивают. Действующие ограничения безопасности сохраняются, но инвентаризация не должна превращаться в сбор личной переписки или скрытое наблюдение за сотрудниками. Границы проверки, доступ к результатам и допустимые способы сбора сведений следует согласовать заранее.
Как решать судьбу найденных сценариев
Неизвестный владелец — повод приостановить расширение полномочий. Неясное происхождение данных — повод разобраться с доступом до новых загрузок. Отсутствие подтверждённой пользы — повод измерить результат на ограниченном объёме.
Два внешне похожих инструмента не обязательно дублируют друг друга. У них могут различаться требования к данным, доступность или обязательные интеграции. Решение об объединении принимают после проверки этих различий.
Для каждого сценария зафиксируйте один ближайший шаг: сохранить, доработать, объединить или вывести из эксплуатации. У шага должны быть исполнитель и проверяемое условие завершения. Формулировка «продолжить изучение AI» оставляет запись без движения.
Отключение тоже требует плана
Удаление учётной записи может оставить действующий токен в интеграции, потерять историю обработки или нарушить зависимый процесс. Перед отключением проверьте, где используются результаты системы, кто хранит нужные материалы и как выполняется операция без неё.
В рабочем плане вывода должны присутствовать отзыв доступа, остановка интеграций, решение по сохранению и удалению данных, прекращение оплаты и проверка резервного процесса. Эти действия выполняют с учётом договоров и применимых требований к хранению.
Реестр обновляют при подключении нового источника, расширении действий, смене поставщика и владельца. Периодическая сверка с оплатами помогает обнаруживать забытые сервисы, но не заменяет обновления по событиям.
Тему накопления разрозненных AI-инструментов рассматривает Вадим Владымцев в статье об AI-пилотах внутри компании. Практический результат инвентаризации — набор решений по конкретным процессам. Количество заполненных строк само по себе ничего не улучшает.
Если система уже выполняет действия, следующая проверка — её доступ к рабочим инструментам.