EU AI Act и California AI Transparency Act 2026: что менять разработчикам

2 августа 2026 года в календарях технических команд появятся сразу две отметки, связанные с прозрачностью генеративного AI. Одна относится к статье 50 европейского регламента, другая — к California AI Transparency Act, изменённому законом AB 853. На первый взгляд обе нормы требуют «помечать AI-контент». Но при разборе рабочего процесса обнаруживаются разные адресаты обязанностей, разные типы раскрытия и разные сроки для платформ и устройств. Поэтому вопрос для CTO звучит не так: «Нужен ли нам водяной знак?», а так: «Какие данные должны пройти через весь конвейер — от модели до публикации, проверки и аудита?»

Ниже — практическое сравнение EU AI Act и California AI Transparency Act 2026 для команд, которые создают, размещают или используют генеративные сервисы в ЕС и Калифорнии.

Что именно начинает действовать 2 августа 2026 года?

Для EU AI Act дата 2 августа 2026 года является датой применения требований статьи 50 о прозрачности. Европейская комиссия указывает, что правила затрагивают взаимодействие человека с AI, машинно читаемую маркировку синтетического контента, раскрытие deepfake и публикаций, созданных или изменённых AI. (digital-strategy.ec.europa.eu)

Для California AI Transparency Act эта же дата стала новой точкой начала действия основного режима после принятия AB 853. Закон отложил применение соответствующей главы с 1 января на 2 августа 2026 года. Covered provider должен предоставить пользователю бесплатный инструмент, позволяющий оценить, был ли контент создан или изменён его генеративной системой, а также показать обнаруженные данные происхождения системы. (leginfo.legislature.ca.gov)

Но это не означает, что все обязанности обеих юрисдикций появляются одновременно:

• требования ЕС к large online platform по обнаружению и отображению provenance data начинают действовать с 1 января 2027 года;
• запрет для GenAI hosting platform сознательно распространять систему без необходимых раскрытий также установлен с 1 января 2027 года;
• обязанности производителей capture device по скрытому раскрытию данных начинаются с 1 января 2028 года;
• для некоторых уже размещённых в ЕС генеративных систем предусмотрен ограниченный переходный период по машинно читаемой маркировке до 2 декабря 2026 года, но это не отменяет необходимости подготовить новый поток заранее. (leginfo.legislature.ca.gov)

Практический вывод для планирования: 2 августа следует считать датой готовности продуктового конвейера, а не датой начала аналитической работы. Если команда начнёт проверку только после вступления правил в силу, она столкнётся с неучтёнными форматами, потерей метаданных и несогласованными текстами уведомлений.

Кто обязан соблюдать правила: поставщик, deployer или платформа?

В европейском режиме важно разделить provider и deployer.

Provider — сторона, которая разрабатывает или выводит AI-систему на рынок. Для генеративной системы это обычно означает ответственность за то, чтобы аудио, изображения, видео и текст имели машинно читаемую маркировку, позволяющую определить искусственное происхождение или изменение. Обязанность относится не только к крупным моделям и не сводится к высокорисковым системам. (digital-strategy.ec.europa.eu)

Deployer — организация, использующая систему в конкретном процессе. В её зоне ответственности могут оказаться видимое раскрытие deepfake, информирование о некоторых AI-системах распознавания эмоций и биометрической категоризации, а также маркировка текста, опубликованного для информирования общества по вопросам общественного интереса.

В Калифорнии ключевым субъектом является covered provider — лицо или организация, создающая, кодирующая или иным образом производящая публично доступную GenAI-систему с более чем 1 000 000 ежемесячных посетителей или пользователей в пределах штата. Закон также отдельно описывает large online platform, GenAI hosting platform и capture device manufacturer. (leginfo.legislature.ca.gov)

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

1. сервис доступен пользователям в ЕС или Калифорнии;
2. компания продаёт доступ к генерации через публичный интерфейс;
3. продукт встраивается в B2B-платформу клиента, который находится в регулируемой юрисдикции;
4. модель или API передают дальше данные происхождения, но контракт не определяет, кто отвечает за их сохранность;
5. публикация контента осуществляется от имени европейского или калифорнийского deployer.

Регуляторная связь может возникать не из-за места регистрации компании, а из-за рынка, доступности продукта и роли в цепочке.

В чём разница между требованиями ЕС и Калифорнии?

Вместо попытки найти одно универсальное «AI-обозначение» полезно разложить различия по пяти вопросам.

1. Что именно нужно раскрыть?

EU AI Act охватывает взаимодействие с AI, машинно читаемую маркировку синтетического аудио, изображения, видео и текста, а также отдельные случаи пользовательского раскрытия. Для deepfake нужно сообщить человеку, что изображение, звук или видео были искусственно созданы или изменены. Для текста, публикуемого по вопросам общественного интереса, также предусмотрено видимое раскрытие, если не применяется исключение, связанное с человеческим контролем и редакционной ответственностью. (digital-strategy.ec.europa.eu)

California AI Transparency Act делает сильный акцент на бесплатном AI detection tool, provenance data и latent disclosure. Закон требует, чтобы covered provider включал в созданные системой изображения, видео и аудио постоянное или чрезвычайно сложное для удаления скрытое раскрытие, насколько это технически возможно. (leginfo.legislature.ca.gov)

2. Кто должен видеть информацию?

В ЕС часть сведений должна быть понятна обычному человеку. Например, пользователь должен понимать, что перед ним deepfake или AI-система. Одновременно провайдер должен обеспечить технический слой, который может прочитать программный инструмент.

В Калифорнии часть требований направлена на проверяемость через инструмент: пользователь должен иметь возможность оценить контент и получить обнаруженные system provenance data. Это не то же самое, что обещание точного определения «AI или не AI» по визуальным признакам.

3. Какой контент охватывается?

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

4. Когда появляются платформенные обязанности?

В Калифорнии large online platform с 1 января 2027 года должна обнаруживать соответствующие provenance data, показывать пользователю сведения о происхождении и, насколько технически возможно, не удалять такие данные. В том же году GenAI hosting platform не должна сознательно предоставлять систему без требуемых раскрытий. (leginfo.legislature.ca.gov)

5. Какова роль проверки?

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

Важно. Видимый текст «создано AI» и machine-readable marking решают разные задачи. Первый рассчитан на человека, второй — на программную проверку и сохранение происхождения при передаче файла.

Как маркировать текст, изображение, аудио и видео?

Текст

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

Для обычного ответа чат-бота ключевым вопросом становится уведомление о взаимодействии с AI. Оно должно быть заметным до того, как пользователь начнёт полагаться на ответ как на сообщение человека.

Изображения

Для изображения разумно сочетать:

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

Нельзя считать JPEG-экспорт безопасным по умолчанию: промежуточный редактор или CDN может удалить исходные поля.

Аудио

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

Видео и deepfake

Для deepfake нужна отдельная логика deployer. Если система создаёт лицо, голос или сцену, которую можно принять за реальную, видимое раскрытие должно быть связано с конкретным местом показа, а не спрятано только в справочном разделе.

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

Как внедрить требования в продуктовый конвейер?

Ниже — последовательность, которую можно превратить в технический backlog.

Шаг 1. Составьте карту ролей и рынков

Для каждого сервиса запишите, кто является provider, deployer, платформой или поставщиком модели. Отдельно укажите, доступен ли продукт пользователям в ЕС и Калифорнии, где физически выполняется генерация и кто публикует результат.

Результат — матрица ответственности, а не общий документ «компания соблюдает AI-закон».

Шаг 2. Инвентаризируйте все выходные модальности

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

Именно на этом этапе часто обнаруживается, что основной генератор пишет происхождение, а сторонний модуль синтеза голоса — нет.

Шаг 3. Введите единый объект происхождения

Создайте внутреннюю запись, связанную с каждым результатом:

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

Внутренний объект не обязан полностью совпадать с публичными метаданными. Он нужен для расследования инцидента и ответа на запрос регулятора или корпоративного клиента.

Шаг 4. Добавьте маркировку до потери данных

Записывайте machine-readable marking сразу после генерации, до изменения размера, перекодирования или передачи в редактор. Для каждого преобразования проведите тест: сохраняется ли маркировка, переносится ли она в новый контейнер и можно ли её обнаружить после скачивания.

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

Шаг 5. Разделите видимый и скрытый уровни

Видимая подпись должна зависеть от контекста, а не только от наличия AI в цепочке. Для deepfake она обычно обязательнее, чем для обычного фонового улучшения фотографии. Скрытая маркировка должна быть постоянной или трудной для удаления в пределах технической реализуемости, как требует калифорнийская схема. (leginfo.legislature.ca.gov)

Шаг 6. Создайте GenAI latent disclosure verification tool

Инструмент проверки должен принимать файл и отвечать минимум на четыре вопроса:

1. обнаружены ли данные происхождения;
2. соответствуют ли они поддерживаемой спецификации;
3. какое имя системы и тип операции указаны;
4. были ли данные повреждены или удалены после экспорта.

Для пользовательского интерфейса полезно разделять «данные найдены», «данные не найдены» и «файл изменён так, что проверка невозможна». Нельзя превращать отсутствие метаданных в уверенный вывод, что контент создан человеком.

Шаг 7. Проведите тесты на передачу

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

Каждая операция должна иметь ожидаемый результат: сохранить, перенести, повторно записать или явно обозначить потерю происхождения.

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

Сохраняйте результаты автоматической проверки, версию алгоритма, время, идентификатор файла и решение оператора. Для ЕС добровольный код практики может помочь выбрать меры, но его использование не заменяет собственную способность доказать соблюдение требований. (digital-strategy.ec.europa.eu)

Сколько стоит такая доработка и что делать первым?

Точную цену нельзя определить без архитектуры. На трудоёмкость влияют четыре фактора:

• количество модальностей;
• число внешних моделей и API;
• наличие собственного файлового конвейера;
• объём пользовательского контента и число точек публикации.

Небольшой текстовый B2B-сервис обычно начинает с уведомления о взаимодействии, журнала генераций и договорных требований к поставщику модели. Медиа-платформе потребуется более сложная работа: сохранение provenance data, проверка после перекодирования, пользовательский интерфейс и процесс рассмотрения спорных результатов.

Приоритеты лучше определить так:

1. заблокировать генерацию без записи внутреннего идентификатора;
2. внедрить маркировку изображений, аудио и видео;
3. создать бесплатный инструмент проверки;
4. добавить видимое раскрытие для deepfake;
5. проверить downstream-поставщиков и договоры;
6. подключить отчётность и регулярный аудит.

Наименее рациональная стратегия — сначала рисовать красивый значок, а затем выяснять, что исходные данные исчезают во время экспорта.

Почему одного водяного знака недостаточно?

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

Другие типичные ошибки:

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

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

Как выглядит разрыв на практике: международный сервис для маркетинговых роликов

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

Для европейского пользователя команда должна проверить:

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

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

• достигает ли система порога covered provider;
• доступен ли бесплатный AI detection tool;
• показывает ли он system provenance data;
• включается ли latent disclosure в созданные изображения, аудио и видео;
• не удаляется ли provenance data при последующей обработке.

Один общий pipeline может покрыть обе территории, но только если он реализует более строгий набор функций. При этом интерфейс и тексты уведомлений должны учитывать различие между «контент создан AI», «контент существенно изменён AI» и «источник не удалось проверить».

Что проверить перед запуском 2 августа?

Сохраните этот список как задачу для совместного совещания продукта, инженерной команды и юристов:

1. Определены роли provider, deployer, платформы и поставщика модели.
2. Зафиксированы пользователи и рынки, включая косвенную доступность в ЕС и Калифорнии.
3. Перечислены все модели, API, редакторы, конвертеры и места публикации.
4. Для текста, изображения, аудио и видео определены отдельные правила раскрытия.
5. Машинно читаемая маркировка записывается до экспорта.
6. Скрытое раскрытие проверяется после перекодирования и скачивания.
7. Deepfake получает видимую подпись в точке показа.
8. Работает бесплатный инструмент проверки для применимого калифорнийского сценария.
9. Интерфейс не выдаёт ложный вывод при отсутствии provenance data.
10. Контракты с поставщиками моделей определяют передачу и сохранность данных происхождения.
11. Хранятся журналы генерации, проверки, публикации и ручной модерации.
12. Есть план на переходные и последующие сроки 1 января 2027 года и 1 января 2028 года.

Практический совет. Проведите не только позитивный тест — «маркировка появилась», но и негативный: «что произойдёт, если пользователь загрузит файл без данных, изменит контейнер или удалит видимый знак». Именно такие сценарии показывают реальный уровень готовности.

Если текущая инфраструктура собрана на разрозненных Windows- или Linux-узлах, дополнительными проблемами становятся разные версии кодеков, ручная настройка окружений, нестабильные удалённые сессии и сложное воспроизведение ошибки между командами. Облачная виртуальная машина решает часть вопросов, но добавляет задержку при обработке медиа, расходы на постоянный диск и необходимость отдельно контролировать передачу конфиденциальных файлов.

Для команд, которым нужно быстро провести gap analysis, воспроизводить тесты экспорта и держать единое окружение для инженерии и проверки, аренда Mac у SpinMac может оказаться практичнее разрозненной локальной инфраструктуры. Вы получаете предсказуемую рабочую среду для скриптов, тестов API, локальной обработки файлов и совместной проверки результатов без закупки оборудования. Перед выбором конфигурации стоит сопоставить требования проекта с условиями аренды Mac, а технические ограничения уточнить через раздел помощи SpinMac.

EU AI Act и California AI Transparency Act 2026 требуют не декоративной надписи, а управляемого жизненного цикла происхождения контента. Поэтому до 2 августа 2026 года разумно назначить совместную проверку продукта, инженерии и compliance-функции, сохранить результаты тестов и отдельно подтвердить готовность к последующим этапам. Этот материал предназначен для технического планирования и не является юридической консультацией.