Согласие, возраст и комплаенс для adult AI-изображений

Любой серьёзный разговор про adult-функцию с изображениями упирается в одно и то же, и это не модель. Это согласие, возраст и способность доказать и то и другое. Спрашивают платёжные провайдеры. Спрашивают магазины приложений. Всё чаще спрашивают регуляторы. Функция, которая не может ответить, снимается уже после запуска — в самый дорогой для этого момент.

Два вопроса, которые имеют значение

Первый: изображённый человек — совершеннолетний и дал ли он согласие? Второй: совершеннолетний ли тот, кто пользуется вашим продуктом? Это разные вопросы с разными механизмами контроля, и их смешение — самая частая ошибка проектирования в этой области. Проверка возраста посетителя ничего не говорит о человеке на фотографии.

Согласие нужно фиксировать, а не предполагать

Строчка в пользовательском соглашении — это не фиксация согласия. Работает явное подтверждение на каждый запрос: загружающий имеет права на изображение, а изображённый человек совершеннолетний и согласен, — привязанное к конкретной задаче, с меткой времени, и запрос без него API отклоняет.

Именно последнее делает механизм настоящим, а не декоративным. Если запрос без подтверждения отбивается на границе API, то каждая обработанная задача в вашей системе несёт подтверждение по построению. Вы не полагаетесь на то, что ваш же клиентский код задал этот вопрос.

Проверка возраста пользователей

Требования здесь меняются быстро и расходятся по юрисдикциям. UK Online Safety Act, немецкий режим защиты несовершеннолетних (youth protection) и растущий список штатов США накладывают обязанности на сервисы, дающие доступ к материалам для взрослых, и часть из них уже требует большего, чем галочка-самодекларация.

Практический вывод — архитектурный: спрячьте проверку возраста за интерфейс, который можно усилить, не переписывая продукт. Сегодня самодекларация, завтра — документ или сервис оценки возраста, если этого потребует рынок. Команды, зашившие чекбокс в десяток шаблонов, платят за это решение дважды.

Запрещённые сценарии, названные прямо

Два запрета не обсуждаются и должны быть в соглашении, в интерфейсе и в правоприменении: никаких несовершеннолетних, ни в каком виде и ни под каким предлогом; и никаких изображений реальных узнаваемых людей без их согласия. Второе и отделяет легитимный adult-продукт от инструмента травли, и всё чаще становится предметом отдельного законодательства о несогласованных интимных изображениях.

Что хранить, а что нет

Здесь есть реальное противоречие. Расследование злоупотреблений требует записей; приватность и законы о защите данных требуют минимального хранения. Разрешается это разделением доказательства и содержимого: храните метаданные, подтверждающие процесс — что подтверждение было дано, когда и под каким аккаунтом, — и не храните сами изображения дольше, чем нужно для выдачи.

• Хранить: идентификатор задачи, аккаунт, метку времени, подтверждение согласия, использованный пресет.
• Не хранить: исходное фото и результат — дольше короткого окна, нужного на выдачу.
• Логировать доступ ко всему этому, потому что аудит, который никто не может проверить, — не аудит.

Модерация — продуктовое решение, а не довесок

Решите до запуска, что происходит, когда что-то пошло не так: как жалоба доходит до человека, как быстро можно заблокировать аккаунт и кто принимает это решение в два часа ночи. Работающий канал жалоб, на который реально отвечают, на практике и отличает платформу, которая сохраняет платёжного провайдера, от той, которая его теряет.

Правильная последовательность

Проверка согласия на границе API, проверка возраста за сменяемым интерфейсом, названные и применяемые запреты, минимальное хранение изображений при долговременном хранении доказательств и канал жалоб, который доходит до человека. Ничего экзотического в инженерном смысле. Но именно это отличает функцию, которая выходит в продакшн, от той, которую снимают.

Частые вопросы