Инструмент проверки ИИ по AB 853 в Калифорнии: как принять

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

Именно здесь возникает практический вопрос: как спроектировать инструмент проверки ИИ по AB 853 в Калифорнии так, чтобы он был не демонстрационной страницей, а проверяемым продуктовым сервисом? Ниже разберём требования к covered provider, различия между manifest disclosure, latent disclosure и результатом детектора, а затем соберём инженерный чек-лист приёмки.

Важное уточнение по срокам: AB 853 перенёс рабочую дату California AI Transparency Act с 1 января 2026 года на 2 августа 2026 года. Сам AB 853 не заменяет исходные требования к детектору, а меняет календарь и добавляет отдельные обязанности для крупных онлайн-платформ и производителей устройств на более поздние даты. Это следует проверять по актуальному тексту закона Калифорнии. (leginfo.legislature.ca.gov)

Почему «у нас есть водяной знак» недостаточно?

Инструмент проверки должен решать несколько разных задач, которые часто ошибочно объединяют в одну.

Во-первых, наличие latent disclosure ещё не означает успешную пользовательскую проверку. Скрытая маркировка должна быть обнаруживаема собственным AI detection tool, а результат должен объяснять, что именно найдено. Если система вставляет уникальный идентификатор, но интерфейс возвращает только «AI detected», пользователь не получает сведения о происхождении или способе изменения контента.

Во-вторых, детектор не должен превращаться в сервис сбора пользовательских данных. Закон различает system provenance data и personal provenance data. К первой категории относятся сведения о типе системы, устройства или сервиса, а также данные об аутентичности контента, если они не позволяют разумно связать их с конкретным пользователем. Персональные сведения, уникальные идентификаторы устройства и другие данные, которые позволяют установить связь с человеком, нельзя выводить пользователю как результат проверки. (leginfo.legislature.ca.gov)

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

Наконец, есть скрытые операционные расходы:

• нужно извлекать метаданные из разных форматов и не ломать файл при обработке;
• URL-проверка требует защиты от SSRF, редиректов на внутренние адреса и слишком больших загрузок;
• API нуждается в ограничении частоты запросов, идентификации клиента и журналировании ошибок;
• служба поддержки должна принимать отзывы об ошибочных результатах;
• privacy-команда должна доказать, что загруженный файл и personal provenance data не остаются в обычных логах.

Кто должен готовить такой сервис к 2 августа 2026 года?

Ключевой термин — covered provider. В действующей формулировке это лицо, которое создаёт, кодирует или иным образом производит генеративную AI-систему, имеющую более 1 000 000 ежемесячных посетителей или пользователей и публично доступную в пределах Калифорнии. Закон также исключает продукты и сервисы, которые предоставляют исключительно не пользовательские видеоигры, телевидение, потоковые или кинотеатральные сценарии. (leginfo.legislature.ca.gov)

Для первичной классификации используйте следующий порядок:

1. Определите, кто является производителем или создателем GenAI-системы.
2. Зафиксируйте, доступна ли система пользователям в Калифорнии, включая доступ через API.
3. Определите, генерирует ли система изображения, видео, аудио или комбинации этих типов контента.
4. Проверьте расчёт ежемесячных пользователей и посетителей по продукту, а не только по отдельной функции.
5. Отделите владельца модели от предприятия, которое только встраивает сторонний сервис.
6. Проверьте договоры лицензирования: обязанность поддерживать latent disclosure может лежать на провайдере модели, но ответственность за пользовательский интерфейс и обработку данных должна быть распределена явно.
7. Назначьте владельца решения: продукт, инженерия, privacy, безопасность и юридическая команда должны подписать один документ применимости.

Обычная компания, которая использует внешний генератор изображений внутри внутреннего рабочего процесса, не обязательно становится covered provider. Однако если она выпускает собственную публичную генеративную систему, масштаб и роль меняются. Не следует автоматически считать, что любой интегратор освобождён от проверки: сначала нужно определить, кто именно «creates, codes, or otherwise produces» систему.

Какие операции должен поддерживать AI detection tool?

Если вы ищете, как сделать California AI Transparency Act detection tool, мыслите не страницей, а набором измеримых пользовательских путей.

Загрузка файла

Пользователь должен иметь возможность передать изображение, аудио, видео или комбинированный файл. На этом этапе следует заранее установить:

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

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

Проверка по URL

URL-сценарий часто недооценивают. Серверу нельзя без фильтра обращаться к любой ссылке, которую передал пользователь. Нужны:

• разрешённые схемы https;
• блокировка локальных и приватных сетей;
• ограничение количества редиректов;
• тайм-аут загрузки;
• лимит размера ответа;
• запрет на выполнение пользовательского JavaScript;
• проверка типа содержимого до скачивания;
• отдельный журнал сетевых ошибок без сохранения полного URL, если он может содержать персональные параметры.

URL-контент может исчезнуть или измениться между моментом запроса и моментом проверки. Поэтому в ответе полезно разделять «контент доступен сейчас», «метаданные не найдены» и «ресурс не удалось безопасно получить». Это точнее, чем выдавать во всех случаях одно значение «не обнаружено».

API-вызов

На запрос AI detection tool API как сделать нельзя отвечать только примером HTTP-эндпоинта. Приёмка API должна включать контракт:

POST /v1/provenance/check
Authorization: Bearer <token>
Content-Type: multipart/form-data или application/json

Ответ должен иметь стабильную схему, например:

{
  "status": "detected|not_detected|inconclusive|unsupported",
  "content_type": "image",
  "system_provenance": {
    "provider": "идентификатор системы",
    "model": "название и версия",
    "created_at": "временная отметка при наличии",
    "signature": "available|not_available|invalid"
  },
  "personal_provenance": "not_returned",
  "retention": "temporary_processing"
}

Названия полей приведены как инженерный пример, а не как установленная законом схема. Важно, чтобы API не возвращал personal provenance data, не раскрывал внутренние идентификаторы пользователя и не требовал посещения веб-сайта. Предусмотрите идемпотентный идентификатор запроса, коды ошибок, ограничение размера тела и понятный статус inconclusive, когда система не может сделать надёжный вывод.

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

Что именно выводить в результате проверки?

Термины system provenance data и personal provenance data нельзя использовать как взаимозаменяемые.

System provenance data — это безопасный для публичного результата слой: тип системы или сервиса, сведения о происхождении контента, статус подписи, идентификатор модели и версия, если эти данные не позволяют связать результат с конкретным человеком.

Personal provenance data может включать персональную информацию или уникальные сведения об устройстве, системе или сервисе, которые разумно способны быть сопоставлены с пользователем. Такой слой необходимо отфильтровать до формирования ответа API и до записи в логи.

Практическая схема ответа может включать четыре уровня:

1. Результат проверки — обнаружена ли маркировка и относится ли она к собственной системе.
2. Сведения о происхождении — какой тип системы или сервиса указан.
3. Состояние доверия — подпись действительна, отсутствует, повреждена или не проверена.
4. Ограничения результата — файл был изменён, формат не поддержан или источник недоступен.

Не выводите в публичный ответ:

• адрес электронной почты автора;
• внутренний ID аккаунта;
• серийный номер устройства;
• полный IP-адрес;
• скрытые токены загрузки;
• точные внутренние трассировочные идентификаторы;
• необработанный блок метаданных, если в нём есть персональные поля.

Как связать latent disclosure и проверку?

Latent disclosure — скрытая маркировка, присутствующая в контенте, но не обязательно видимая человеку. Manifest disclosure — заметное пользователю сообщение о том, что материал создан или изменён AI-системой. Это разные механизмы.

Рабочий замкнутый цикл выглядит так:

1. Генеративная система создаёт изображение, видео или аудио.
2. В результат добавляется latent disclosure, насколько это технически возможно и разумно.
3. Скрытая маркировка содержит или связывает с названием провайдера, названием и версией системы, датой и временем, а также уникальным идентификатором.
4. Пользователь получает возможность включить manifest disclosure в понятной форме.
5. AI detection tool извлекает latent disclosure.
6. Результат преобразуется в безопасный system provenance data.
7. Система возвращает информацию о найденной маркировке, не раскрывая personal provenance data.
8. Отзыв пользователя попадает в отдельный процесс улучшения точности.

Основной тест здесь — не «есть ли водяной знак в оригинальном файле», а «может ли собственный детектор распознать его после типичных операций». Проверьте JPEG-пересохранение, изменение размера, экспорт из видеоредактора, обрезку, конвертацию аудио и публикацию через URL с несколькими редиректами.

Как оформить приватность, хранение и обратную связь?

Требования к AI detection tool privacy retention удобнее реализовать через разделение контуров данных.

Контур обработки

Исходный файл поступает во временное хранилище, проходит извлечение метаданных и проверку, после чего удаляется автоматически. Срок должен быть технически минимальным и подтверждаться журналом удаления, а не только политикой конфиденциальности.

Контур результата

В постоянной базе сохраняйте только агрегированный технический результат, если он действительно нужен для работы сервиса. Не копируйте туда исходный файл, необработанные EXIF-поля и полный ответ внешнего анализатора.

Контур обратной связи

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

Контур безопасности

URL, токены API и диагностические данные должны проходить редактирование перед логированием. Запретите запись полного тела запроса в production-логи. Для расследований используйте ограниченный доступ, короткий срок хранения и отдельную маскировку персональных полей.

В политике конфиденциальности ZilCloud можно сверить общий подход к описанию обработки данных, но для конкретного AI detection tool потребуется отдельная карта потоков: файл, URL, API-токен, результат, отзыв, журнал ошибки и запись об удалении.

Что проверять на приёмке перед запуском?

Ниже — практическая последовательность из восьми шагов.

Шаг 1. Зафиксируйте область применимости

Соберите документ с ролью компании, географией доступа, типами контента, месячной аудиторией и отношениями с лицензиатами. Отдельно отметьте, не относится ли продукт к исключениям.

Шаг 2. Опишите три пользовательских маршрута

Нарисуйте отдельные схемы для загрузки, URL и API. Для каждого маршрута укажите входные данные, размер, тайм-аут, результат, код ошибки и момент удаления.

Шаг 3. Создайте фильтр provenance data

Разделите поля на system, personal и внутренние служебные. Проверьте фильтр на реальных метаданных, включая нестандартные поля, вложенные JSON-блоки и данные цифровой подписи.

Шаг 4. Проверьте собственную latent disclosure

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

Шаг 5. Проведите тесты после редактирования

Минимальный набор включает сжатие, обрезку, конвертацию формата, изменение частоты дискретизации аудио, удаление метаданных, монтаж нескольких фрагментов и загрузку через внешний URL.

Шаг 6. Проверьте безопасность URL и API

Используйте тестовые адреса редиректов, слишком больших файлов, медленных ответов, неподдерживаемых MIME-типов и попыток обращения к внутренним сетям. В API проверьте повтор запроса, истёкший токен, превышение лимита и одновременную отправку нескольких файлов.

Шаг 7. Измерьте удаление данных

После каждого теста найдите исходный файл в объектном хранилище, временной директории, очереди, резервной копии, APM-системе и логах. Нельзя считать данные удалёнными только потому, что они исчезли из интерфейса.

Шаг 8. Подпишите доказательства

Для каждого требования сохраните тестовый сценарий, дату, версию сервиса, ожидаемый результат, фактический результат, скриншот или журнал и ответственного. Это полезнее, чем общий статус «compliant» в трекере задач.

Матрица приёмки ZilCloud для AB 853

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

Почему результат есть, а соответствия всё равно нет?

Наиболее частые ошибки выглядят следующим образом.

Детектор работает только на сайте. API отсутствует, поэтому автоматизированный пользователь не может вызвать проверку без браузера.

Система выводит всё, что нашла. Необработанные метаданные могут раскрыть пользователя, устройство или служебный идентификатор.

Файл хранится «для улучшения модели». Такая цель не отменяет требования минимизации и удаления. Сначала нужна правовая и техническая модель хранения, а не бессрочное архивирование.

Latent disclosure добавляется, но собственный детектор её не распознаёт. Это ломает замкнутый цикл верификации.

Нет процесса обратной связи. Кнопка «сообщить об ошибке» без маршрутизации, согласия и анализа не доказывает, что отзывы собираются и используются.

Все неопределённые результаты обозначаются как «не создано AI». Это опасная семантическая ошибка. «Не обнаружено» и «создано человеком» — разные утверждения.

Что можно переиспользовать для требований ЕС?

Если продукт одновременно выходит на рынок ЕС, часть технических возможностей действительно можно переиспользовать: устойчивую маркировку, машинно читаемые сведения о происхождении, проверку цифровой подписи, журналирование версий и тесты после сжатия или редактирования.

Однако не следует считать, что один детектор автоматически закрывает обе юрисдикции. Для California AI Transparency Act критичны публичный бесплатный инструмент, загрузка, URL, API, вывод system provenance data, запрет на вывод personal provenance data и минимизация хранения. В ЕС отдельное внимание уделяется прозрачности AI-контента и машинно читаемым обозначениям в рамках Article 50. Технический модуль можно сделать общим, но карту обязанностей, интерфейсные формулировки и юридические основания обработки нужно проверять отдельно.

Текущая схема против Mac-среды для тестирования

Если тестовая инфраструктура сейчас работает на разрозненных Windows или Linux-машинах, это не делает решение автоматически неправильным, но создаёт несколько практических недостатков: сложнее обеспечить одинаковые версии кодеков и библиотек, больше различий в окружении разработчиков, выше риск ручного расхождения конфигураций и труднее быстро выдать изолированную среду для QA, privacy и AppSec-команд.

Для такой задачи аренда готовой Mac-среды у ZilCloud может быть удобнее: команда получает отдельное окружение для API-тестов, обработки медиафайлов, проверки URL и воспроизводимых сценариев без покупки дополнительного оборудования. Это особенно полезно, когда нужно одновременно прогнать матрицу форматов, сохранить контроль версий и дать доступ нескольким специалистам, не смешивая тестовые данные с рабочими системами. Перед запуском можно сверить доступные варианты на странице тарифов ZilCloud, а затем согласовать рабочую конфигурацию через заказ Mac-среды.

Сохраните матрицу приёмки и проведите её совместно с продуктом, инженерией, privacy, безопасностью и юристами до 2 августа 2026 года. Отдельно подтвердите применимость статуса covered provider, протестируйте загрузку, URL и API, проверьте распознавание latent disclosure и документально зафиксируйте удаление данных. Эта статья предназначена для инженерной и продуктовой подготовки и не является юридической консультацией.

Часто задаваемые вопросы