Реестр ИИ-моделей (AI Model Inventory Template)

• Инвентарь покрывает production и существенные pilots.
• Есть named owner.
• Model/version можно восстановить для incident review.
• Data access описан отдельно от business description.
• Изменение модели/provider запускает review.
• Retired systems не исчезают бесследно — сохраняется history.

В него могут входить scoring, recommendation, vision, speech, forecasting и agentic systems, если они используют AI и создают существенный operational или customer impact.

Шаблон особенно важен для production AI, систем с доступом к клиентским данным или внешним инструментам и use cases, где ошибка влияет на клиента, деньги или репутацию. Для краткого sandbox-теста можно использовать минимальную карточку, но перед production запись должна содержать ownership, data access, evals и lifecycle rules.

• Начните с конкретного use case и business owner. Название модели само по себе не объясняет, зачем система существует и какой риск создаёт.
• Зафиксируйте model/provider/version, данные, permissions и доступные инструменты так, чтобы конфигурацию можно было восстановить после инцидента.
• Определите evals и acceptance criteria до production. Для значимых use cases одной субъективной проверки качества недостаточно.
• Разделите автоматическое действие и human approval. Чем выше потенциальный impact, тем яснее должны быть ограничения, fallback и escalation.
• Пересматривайте запись при смене модели, провайдера, данных, permissions или бизнес-процесса, а также перед выводом системы из эксплуатации.

Компания использует несколько LLM API, scoring model и AI-агента с CRM access. Inventory фиксирует владельцев, версии, data classes, tool permissions, evals, incidents и fallback для каждой системы.

Результат работы с шаблоном «Реестр ИИ-моделей» — не заполненная форма сама по себе, а согласованный рабочий артефакт, который можно использовать для решения, передачи контекста и последующей проверки результата. У документа должны быть понятны владелец, исходные данные, допущения, дата актуальности и следующий шаг. Если эти элементы невозможно определить, полезнее сократить документ до минимальной версии и вернуть недостающие данные, чем заполнять поля формально.

• У AI-системы есть business и technical owner.
• Зафиксированы model/version и data access.
• Есть eval status и известные limitations.
• Определены human oversight, fallback и incident path.
• Есть review trigger и decommissioning plan.

Пересмотр обязателен при смене модели или провайдера, расширении permissions, подключении новых data sources, изменении use case, инциденте или существенном обновлении evals. Retired systems следует сохранять в истории.

Нужно ли включать в реестр только генеративный ИИ?

Нет. Реестр должен охватывать существенные AI-системы: генерацию, scoring, recommendation, vision, speech, forecasting и agentic workflows.

Нужно ли фиксировать каждое обновление модели?

Для критичных use cases — да, если версия влияет на воспроизводимость, evals или risk profile. Для managed API можно фиксировать release channel и дату observed change.

Кто отвечает за запись?

Business owner отвечает за use case и impact, technical owner — за конфигурацию, data/tool access и эксплуатацию. Эти роли могут совпадать только в небольших системах.

• Risk Register
• Vendor Scorecard
• Decision Log

• AI Vendor Assessment
• AI Data & IP Leakage
• AI Agent Action Risk