Система
Назначение, пользователи, внешние сервисы и юридические границы проверки.
Разбираем конкретный продукт: какие данные он использует, кому принадлежат код и материалы, что обещают поставщики и кто отвечает за результат. По итогам вы получаете заключение с приоритетами: что исправить сразу, что можно запланировать и какие документы понадобятся.
Автор книги «Правовой аудит ИИ-систем». Формирует методологию практики и состав команды профильных экспертов под задачи проекта.
Отметьте особенности системы. Сервис покажет, какие блоки потребуют внимания. Это ориентир для первого разговора, а не юридическое заключение.
Если отмеченных факторов нет, обычно достаточно проверить права на собственные разработки, лицензии открытого ПО и базовые договоры. Точный объём зависит от архитектуры и сценария использования.
Не начинаем с универсального чек-листа. Сначала фиксируем реальный сценарий продукта, затем проверяем только применимые блоки.
Назначение, пользователи, внешние сервисы и юридические границы проверки.
Источники, основания обработки, локализация, обезличивание и автоматические решения.
Код, модели, датасеты, open source, служебные результаты и генерации.
Условия API и облачных моделей, использование данных, гарантии и выход из договора.
Роли разработчика, владельца и пользователя, инциденты, журналы и доказательства.
Финансы, медицина, КИИ, госсектор, требования заказчика и применимые стандарты.
Лучше всего проводить проверку до того, как проект станет предметом сделки, крупного контракта или претензии. Но объём работ можно адаптировать и под уже возникшую ситуацию.
Новая модель, внешний API, дообучение или переход в промышленную эксплуатацию могут изменить состав данных, цепочку поставщиков и распределение ответственности. Эти изменения стоит зафиксировать до запуска.
В ходе due diligence обычно возникают вопросы об источниках данных, лицензиях на код, правах на результат, обучении на данных клиента и зависимости от поставщиков. Аудит помогает заранее собрать ответы и документы.
В такой ситуации важно быстро сохранить журналы, версии модели, переписку и иные доказательства, а затем отделить причину инцидента от его правовых последствий.
Если компания хочет управлять ИИ как постоянным процессом, нужны роли, порядок оценки рисков, документирование изменений и внутренние проверки. ГОСТ Р ИСО/МЭК 42001 даёт для этого структуру.
Аудит идёт от фактов к выводам: сначала фиксируем устройство системы, затем сопоставляем его с документами и только после этого оцениваем риски.
Фиксируем систему, сценарий использования, участников и нужный клиенту результат.
Изучаем документы, проводим интервью и при необходимости сопоставляем их с журналами и настройками.
Связываем каждый вывод с фактом и делим замечания по срочности и последствиям.
По согласованию обновляем договоры, согласия, регламенты и проверяем устранение критичных замечаний.
Практическое руководство для бизнеса и юристов
Практическое руководство о том, как организовать правовой аудит ИИ-системы: от инвентаризации и карты ролей до проверки данных, договоров и системы внутреннего контроля. Автор — Станислав Трофимов.
Только события и новые требования. Подробная аналитика опубликована отдельно в базе знаний.
Все новостиУведомление о взаимодействии с ИИ, машинно-читаемая маркировка, раскрытие deepfake и общественно значимого контента.
Закон регулирует большие фундаментальные модели и вступает в силу поэтапно с 1 сентября 2026 года.
Подробные материалы о персональных данных, ответственности, договорах и регулировании ИИ.
Все разборы