Kling API: чек-лист прав на prompt и reference media

Соберите основание до загрузки, а не после ошибки

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

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

Проверьте согласие на изображение человека отдельно

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

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

Отделите права на prompt, бренд и исходное медиа

Текстовый prompt может включать название компании, персонажа, произведения или частную информацию. Его краткость не отменяет проверки цели и прав. Reference media добавляет отдельный слой: источник файла, авторские права, доступ, изображения людей, embedded metadata и условия лицензии. Не делайте вывод о разрешении только по отсутствию watermark или по заявлению «нашли в интернете». Для брендовых материалов полезно определить разрешённые проекты и ответственного владельца.

Проверка не должна заставлять пользователя пересылать исходник туда, где он не нужен. Сначала выполните локальный preflight типа файла, размера, доступа и минимальных метаданных, затем принимайте решение о server-side отправке. Не удаляйте метаданные, если они нужны для доказательства происхождения или сохранения авторства; вопрос о редактировании решайте по политике и назначению. В журнале достаточно статуса проверки и локального ID задачи, а не копии файла или полного prompt.

Сделайте понятные ветки решения и эскалации

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

Не маскируйте неопределённость под сетевую ошибку и не обещайте компенсацию, публикацию или срок хранения результата. Пользователь должен видеть нейтральное объяснение: «задача не отправлена, пока не подтверждено основание». Это честнее, чем принять материал и рассчитывать на последующую проверку. Состояние preflight и конечной видео-задачи храните отдельно: успешная проверка прав не означает успешную генерацию, а технический отказ не отменяет необходимость проверки прав.

Тестируйте форму и журнал на синтетических примерах

На staging подготовьте нейтральные тестовые карточки: собственное изображение с подтверждённой целью, файл без источника, изображение с несколькими людьми, материал с ограниченным доступом и случай с противоречивыми ответами. Проверьте, что приложение не отправляет reference media до положительной ветки и что повтор кнопки не создаёт две задачи. Не используйте в тестах реальные документы клиентов, лица без необходимости или upstream keys.

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

Пример безопасной server-side проверки

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

export function preflightMedia(input) {
  const needsReview = !input.rightsBasis || !input.purpose || input.hasRecognizablePerson;
  if (!input.isAllowedType || !input.canAccess) return { status: 'blocked' };
  if (needsReview) return { status: 'manual_review' };
  return { status: 'ready_for_server_submission' };
}

// This classifies application-owned declarations. It does not establish
// legal rights and must run before any server-side upload.

Граница ответственности и данных

Это инженерный шаблон для вашего приложения, а не гарантия возможностей внешнего API. Не помещайте в браузер, тикет, статью или обычный журнал API-ключи, заголовок Authorization, cookie, ключи поставщиков, полный prompt или персональные данные. Условия обработки данных, права на контент и применимые требования проверяются по политике вашей организации, договору и с ответственным специалистом.

Контроль перед выпуском

Перед release проверьте синтетический сценарий, запреты на секреты и персональные данные в логах, роли и tenant boundary, понятное сообщение для пользователя и ручную ветку для неизвестного результата. Сохраните дату, версию адаптера и результат теста. При обновлении SDK, модели, schema или маршрута повторите проверку; не переносите выводы старого теста на новый контракт.

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

Полезные материалы

NIST Privacy Framework · WIPO: Copyright

FAQ

Достаточно ли ссылки на картинку, чтобы считать её разрешённой?

Нет. Техническая доступность URL не доказывает лицензию, согласие человека, цель использования или право передать файл дальше. Зафиксируйте понятное основание и остановите задачу, если данных недостаточно.

Может ли checkbox заменить юридическую проверку?

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

Нужно ли хранить полное изображение в журнале проверки?

Обычно нет. Для технического журнала достаточно локального ID, версии чек-листа и статуса ветки. Состав, срок хранения и доступ к любым материалам определяются вашей политикой, договором и применимыми требованиями.

Следующий шаг

Продолжите с материалами: Kling API: image-to-video · Kling API: согласие на изображение человека · Права на контент в Video API. Затем проверьте текущие условия и безопасно протестируйте интеграцию на staging перед production-трафиком.