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