Зачем компании опись нейросетей
Три практические задачи, которые без учёта не решаются:
- Применимость закона. Порог большой фундаментальной модели — 1 млрд параметров и четыре признака одновременно. Не зная своих моделей, невозможно доказать, что вы вне периметра — а именно это первый вопрос аудиторов и заказчиков после 01.03.2027.
- Контроль данных. Каждая система так или иначе касается информации: обучается на ней, обрабатывает её или отправляет во внешний сервис. Опись превращает невидимый теневой ИИ в управляемый список.
- Договоры и закупки. Госсектор и крупные корпорации включают требования к ИИ-компонентам в ТЗ и договоры. Ответ «не знаем, что у нас внутри» стоит сделок.
Что говорит закон
Прямой нормы «ведите учёт» нет ни в законе от 26.07.2026, ни где-либо ещё. Но косвенно учёт предполагается всем его механизмом: чтобы проверить признаки большой модели, нужно её знать; чтобы получить статус — описать; чтобы подтверждать соответствие — документировать. Поэтому компании, которые ждут внешнего реестра, просто переносят ту же работу на более жёсткие сроки.
Карточка учёта: семь полей
| Поле | Что писать | Пример |
|---|---|---|
| Название и версия | Как система называется внутри | Ассистент поддержки v2 |
| Тип и источник | Своя / открытая / API чужой модели | API провайдера X |
| Назначение | Зачем используется | Ответы на типовые обращения |
| Данные | Что обрабатывает, классификация | Текеты клиентов, без ПДн |
| Владелец | Ответственный за систему | Департамент поддержки |
| Признак БФМ | Проверен / неприменим + обоснование | Неприменим: 120 млн параметров |
| Статус | В проде / пилот / выведена | Пилот |
Заполнение на команду из десяти систем занимает день. Главный принцип — лучше неполная карточка сегодня, чем идеальная никогда: опись живая и дополняется по мере находок.
Как не превратить в бюрократию
Три правила против вырождения учёта. Первое: одна таблица, а не три несовместимых реестра у ИБ, разработки и юристов. Второе: владелец карточки — тот, кто эксплуатирует систему, а не служба комплаенса. Третье: ревизия привязана к событиям (новый сервис, договор, релиз), а не к календарю — календарный аудит откладывается вечно.
Связь с AI BOM
Если карточка учёта описывает «что у нас есть», то концепция AI BOM отвечает на вопрос «из чего это состоит»: модели, датасеты, библиотеки, внешние API и их версии. BOM полезен для оценки рисков цепочки поставок — от отравления данных до исчезновения провайдера. Логика та же, что у билля материалов в производстве: сначала опись, затем анализ зависимостей. Начать стоит с концепции AI BOM, а карточки учёта станут её фундаментом.
Порядок внедрения за месяц
- Неделя 1: собрать список систем — опрос отделов, сканирование сервисов, анализ счетов на ПО.
- Неделя 2: заполнить карточки по семи полям, отметить пробелы как «уточнить».
- Неделя 3: прогнать тест признаков БФМ по каждой системе, зафиксировать выводы письменно.
- Неделя 4: назначить владельцев, согласовать порядок обновления, приложить к политике использования ИИ.
Дальше опись обслуживается по событиям. Если нужны внешние глаза — обсудите аудит ИИ-контура: проверим и опись, и реальные потоки данных.
Учёт и инциденты
Опись окупается в самый дорогой момент — при инциденте. Когда срабатывает таймер 24 часов на уведомление, вопросы решаются минутами: какие данные затронуты (поле «Данные»), кто владелец системы (поле «Владелец»), где границы доступа. Без описи те же ответы собираются сутками — и просрочка уведомления стоит 1–3 млн ₽ сама по себе.
Поэтому связку «учёт + регламент реакции» стоит внедрять вместе: карточка системы — это одновременно и сценарий реагирования.
Типичные пробелы первой ревизии
Опыт первых инвентаризаций предсказуем: в описи забывают расширения браузера с ИИ-функциями, встроенные ассистенты офисных пакетов, тестовые доступы к сервисам, оставшиеся после пилотов, и «личные» подписки сотрудников, оплаченные корпоративной картой. Отдельная категория — подрядчики, обрабатывающие ваши данные своими нейросетями: их инструменты тоже часть вашего контура.
Закрывать пробелы лучше сразу в карточках, а не отдельным списком — иначе через квартал появится вторая, третья опись, и учёт перестанет быть единственным источником правды.
Итог: учёт как основа комплаенса
Внутренний учёт — точка, из которой вырастает весь ИИ-комплаенс: тест порога берёт из него параметры моделей, договоры — список компонентов, регламент инцидента — владельцев и данные. Одна таблица с семью полями, заполненная за неделю, экономит месяцы авральной работы при появлении любых новых норм — от статусов до маркировки. Не ждите внешних реестров: они опоздают, а ваши заказчики уже сегодня спрашивают, что у вас внутри. Начните с обнаружения теневого ИИ, соберите карточки и назначьте владельцев — остальное приложится.