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