Genius-bot · 12 минут чтения
Когда подключается api для генерации изображений, техническая часть обычно занимает несколько строк кода, а вопросы после генерации начинаются уже с файла: кто может его использовать, можно ли разместить его на сайте, передать заказчику или включить в коммерческий макет. Отдельно стоит решить, где хранить промт, дату запуска и идентификатор задачи, чтобы через полгода было понятно, откуда взялась конкретная картинка.
У результата генерации нет универсального ответа в стиле «файл принадлежит тому, кто нажал кнопку». Права зависят от применимого законодательства, условий конкретной сделки и того, что именно было создано человеком помимо машинной генерации. Поэтому хозяйственную часть процесса лучше организовать так, чтобы вместе с изображением сохранялись исходные данные и история его получения.
В этом материале разберём практическую схему: что фиксировать при генерации, как отделять исходные материалы от результата, какие публикации требуют дополнительной проверки и как посчитать хранение на примере 10 000 файлов. Для подключения ключа и просмотра доступных операций используется раздел API.
Кому принадлежит сгенерированное изображение
Первое, что важно разделить, — право владения файлом и авторские права на произведение. Наличие PNG или JPEG на диске само по себе не отвечает на вопрос, возникло ли на него исключительное право и у кого именно оно находится. Для коммерческого проекта это особенно важно: передача файла заказчику и передача исключительных прав — разные юридические действия.
При машинной генерации не стоит автоматически записывать в договор формулировку «исполнитель является автором всех созданных нейросетью изображений». Юридический статус результата зависит от законодательства соответствующей юрисдикции и конкретного уровня человеческого творческого вклада. Если изображение прошло существенную ручную переработку, результат этой работы нужно рассматривать отдельно от первоначальной генерации.
На практике полезно фиксировать минимум четыре вещи: кто запустил генерацию, какой текст был передан модели, какие исходные материалы использовались и какой файл получен на выходе. В API задача запускается через POST /generate, после чего её состояние и результат можно получить через GET /tasks/{id}. Эти данные позволяют восстановить техническую историю создания файла.
Для команды это можно оформить как внутреннюю запись:
{
"task_id": "12345",
"operation": "image",
"prompt": "Минималистичная иллюстрация рабочего стола...",
"created_at": "2026-09-22T10:15:00Z",
"file": "image-12345.png"
}Сам JSON не создаёт и не передаёт никаких прав. Его задача хозяйственная: сохранить доказуемую связь между заданием и полученным результатом. Если картинка попадает в рекламу, упаковку, презентацию или платный продукт, такие записи удобнее хранить вместе с проектной документацией, а не в переписке отдельного сотрудника.
Отдельно нужно учитывать исходные изображения. Если для изменения фотографии используется файл клиента, наличие разрешения на его обработку не означает автоматически наличие разрешения на любые дальнейшие способы использования полученного результата. Поэтому для проектов с клиентским контентом лучше фиксировать назначение обработки и разрешённые способы публикации.
Что можно публиковать и продавать, а что рискованно
Технически сервис возвращает результат операции, но техническая возможность скачать файл не равна юридическому разрешению использовать любой контент любым способом. Перед публикацией нужно проверить не только способ генерации, но и исходные данные: фотографии людей, логотипы, тексты, элементы фирменного стиля и другие материалы, которые могли попасть в запрос.
Особенно осторожно стоит относиться к изображениям, созданным на основе чужой фотографии. Операция «Изменить фото по описанию» стоит 35 ₽ за запуск, однако цена обработки ничего не говорит о наличии у пользователя права на исходную фотографию или изображённых на ней людей. Эти вопросы должны решаться отдельно от API.
Есть и более простой случай: вы создаёте иллюстрацию по собственному описанию без загрузки чужих материалов. Риск здесь не исчезает полностью, поскольку юридический статус машинно сгенерированного результата зависит от применимого права, но цепочка происхождения получается заметно проще. Поэтому в коммерческом процессе полезно хранить не только готовый файл, но и информацию о способе его создания.
Для публикации на сайте или в социальных сетях удобно завести внутреннюю классификацию:
| Ситуация | Что зафиксировать | Что проверить до публикации |
|---|---|---|
| Картинка создана по текстовому описанию | Промт, дата, задача, результат | Правовой статус результата в нужной юрисдикции |
| Изменена фотография клиента | Исходный файл и разрешение на обработку | Права на фото и условия использования результата |
| Изображение используется в рекламе | Версию файла и сведения о генерации | Права на исходные материалы и требования к рекламному размещению |
| Файл передаётся заказчику | Финальный файл и историю генерации | Условия договора и объём передаваемых прав |
Такой журнал особенно полезен, если один и тот же результат проходит несколько этапов. Например, сначала создаётся изображение по описанию за 9 ₽, затем оно дорабатывается операцией image-edit за 35 ₽, а потом увеличивается в качестве за 50 ₽. В этом случае разумно хранить не только последнюю версию, но и связь между версиями.
При большом количестве файлов можно присваивать им внутренний ID и не переименовывать файлы вручную. Например, `project-042-task-12345-v03.png` сразу показывает проект, задачу и версию. Рядом можно хранить JSON с промтом и техническими параметрами.
Описание рядом с файлом: зачем хранить промт
Промт — это не просто текст, который когда-то отправили в API. Для рабочего архива он выполняет функцию метаданных: помогает понять происхождение изображения, повторить генерацию и установить, какая версия описания использовалась.
Если хранить только `final.png`, через несколько месяцев восстановить историю будет сложно. Если рядом лежит `final.json`, где записаны операция, промт, идентификатор задачи и дата, происхождение файла становится значительно прозрачнее.
Минимальная структура каталога может выглядеть так:
project-042/
├── image-12345.png
├── image-12345.json
├── source/
│ └── reference.jpg
└── versions/
├── image-12345-v01.png
└── image-12345-v02.pngДля JSON достаточно хранить данные, необходимые именно вашему процессу. Например:
{
"task_id": "12345",
"operation": "image",
"prompt": "Предметная иллюстрация...",
"created_at": "2026-09-22T10:15:00Z",
"version": 1,
"status": "completed"
}Если изображение генерируется автоматически, эти данные можно сохранять сразу после получения результата. API предоставляет GET /tasks/{id> для проверки состояния и результата задачи, а при необходимости можно передать параметр `callback_url`: после готовности задачи на указанный адрес приходит POST. Это позволяет построить процесс, в котором запись об операции создаётся автоматически, без ручного копирования промта.
Например, базовый запрос на генерацию можно отправить через curl:
curl -X POST "https://genius-bot.ru/wp-json/genius/v1/generate" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"operation": "image",
"prompt": "Минималистичная предметная иллюстрация белой кружки на столе"
}'Ключ передаётся в заголовке Authorization. Ключ выдаётся после входа в разделе API и показывается один раз, поэтому его не стоит записывать непосредственно в JSON с промтом или коммитить в исходный код.
Тот же подход можно использовать из Python:
import requests
API_KEY = "YOUR_API_KEY"
url = "https://genius-bot.ru/wp-json/genius/v1/generate"
response = requests.post(
url,
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
},
json={
"operation": "image",
"prompt": "Минималистичная предметная иллюстрация белой кружки на столе",
},
timeout=60,
)
response.raise_for_status()
print(response.json())В рабочем приложении ключ лучше получать из переменной окружения или другого закрытого хранилища. Сам промт при этом можно сохранять в базе данных или в отдельном JSON, если он не содержит конфиденциальных сведений.
Пометка о машинной генерации: когда она обязательна
Отдельный вопрос — нужно ли сообщать аудитории, что картинка создана с помощью нейросети. Универсального правила для всех публикаций нет: требования зависят от страны, площадки, отрасли, типа контента и конкретного способа использования.
Поэтому внутреннюю пометку о происхождении изображения и публичную маркировку лучше не смешивать. Внутренний журнал может содержать запись «generated: true» для каждого файла, даже если на самой картинке никакого знака нет.
Для команды полезно также различать метку в интерфейсе и водяной знак нейросеть. Первая может быть обычной подписью рядом с материалом, вторая непосредственно изменяет изображение, добавляя визуальный элемент. Это разные способы обозначить происхождение контента и применять их следует в соответствии с требованиями конкретного проекта.
Если маркировка требуется правилами площадки или условиями публикации, лучше заранее определить её место и формат. Не стоит добавлять водяной знак во все изображения автоматически только потому, что они были сгенерированы: сначала нужно понять, действительно ли такая отметка нужна именно для данного использования.
При этом техническую отметку происхождения имеет смысл сохранять всегда. Она может быть полезна при передаче файла между сотрудниками: новый редактор видит, что перед ним результат генерации, и понимает, где искать промт, исходники и историю изменений.
Сколько стоит хранить десять тысяч картинок
Здесь важно отделить стоимость генерации от стоимости хранения файлов. В предоставленном API цена операций указывается за запуск, а отдельной цены за хранение файлов в справке сервиса нет. Поэтому стоимость хранения 10 000 картинок в конкретном объектном или файловом хранилище нельзя вывести из тарифов API и корректно называть без цены самого хранилища.
Зато стоимость создания такой коллекции можно посчитать напрямую. Операция «Картинка по описанию» стоит 9 ₽ за один запуск, поэтому 10 000 запусков обойдутся в 90 000 ₽. Это не стоимость диска: это только стоимость десяти тысяч операций генерации.
| Операция | Цена за запуск | 10 000 запусков |
|---|---|---|
| Картинка по описанию (image) | 9 ₽ | 90 000 ₽ |
| Изменить фото по описанию (image-edit) | 35 ₽ | 350 000 ₽ |
| Увеличить качество фото (upscale) | 50 ₽ | 500 000 ₽ |
| Оживить фото (photo-video) | 25 ₽ | 250 000 ₽ |
| Видео по описанию (video) | 119 ₽ | 1 190 000 ₽ |
Для самой оценки дискового пространства нужна средняя масса одного файла. Если условно принять её за 5 МБ, то 10 000 изображений займут около 50 000 МБ, то есть примерно 50 ГБ в десятичном расчёте. При среднем размере 2 МБ получится около 20 ГБ, при 10 МБ — около 100 ГБ.
Формула простая: количество файлов × средний размер файла. Для 10 000 изображений по 5 МБ это `10 000 × 5 = 50 000 МБ`. Но итоговый счёт конкретного хранилища зависит от его собственных тарифов, резервных копий, репликации и дополнительных операций, поэтому цену диска нужно считать по выбранной инфраструктуре отдельно.
Есть ещё одна практическая статья расходов — версии. Если сохранять исходную генерацию, две отредактированные версии и финальный файл, четыре изображения на один результат увеличат объём примерно в четыре раза. Поэтому правило хранения версий стоит определить до запуска массовой генерации.
Сам API работает по модели оплаты за запуск: абонентской платы и минимального платежа нет. При выпуске первого ключа на баланс начисляется 50 ₽ для пробы, а ограничение частоты составляет не более 60 запросов в минуту на один ключ.
Чистка: что удалять и через сколько
Хранить абсолютно все промежуточные файлы бесконечно обычно неудобно. Но удалять их сразу после получения финального изображения тоже рискованно для рабочего процесса: вместе с ними могут исчезнуть промты, исходные материалы и сведения, которые позволяют разобраться в происхождении результата.
Практичнее разделить архив на три категории. Первая — финальные материалы, которые используются или были переданы заказчику. Вторая — данные происхождения: промт, ID задачи, дата и версия. Третья — временные файлы, которые нужны только для обработки и могут удаляться по внутреннему регламенту.
Например, после завершения проекта можно оставить финальный файл и JSON с историей генерации, а неудачные варианты удалить. Если над изображением велась существенная ручная работа, промежуточную версию перед удалением стоит сохранить, если она нужна для подтверждения этапов работы или восстановления результата.
Сроки хранения лучше задавать не одной цифрой для всех файлов, а по назначению. Для активного проекта файлы нужны до завершения работ, для бухгалтерских или договорных подтверждений — столько, сколько требует соответствующий документооборот, а временные результаты можно удалять после того, как проверен финальный файл и сохранены необходимые метаданные.
Если генерация идёт автоматически, очистку можно привязать к статусу проекта. Например, задача переходит в `completed`, финальный файл и JSON сохраняются в постоянный архив, а временные варианты получают дату удаления. Это проще контролировать, чем периодически чистить общий каталог вручную.
Для большого объёма полезно считать не только количество файлов, но и их версии. Каталог из 10 000 финальных изображений может быстро превратиться в 30 000–40 000 объектов, если каждое изображение хранить вместе с несколькими промежуточными вариантами. В таком случае политика удаления влияет на объём сильнее, чем сама генерация.
Наконец, не стоит использовать название файла как единственное хранилище истории. Имя вроде `final2-new.png` через год мало что говорит. Связка «файл + промт + ID задачи + дата + версия» значительно лучше подходит для архива, особенно когда над проектом работают несколько человек.
Частые вопросы
Можно ли считать сгенерированную картинку своей собственностью только потому, что я оплатил генерацию?
Оплата запуска подтверждает факт оказания технической услуги, но сама по себе не определяет авторско-правовой статус результата. Для конкретного проекта нужно учитывать применимое законодательство, договорные условия и человеческий творческий вклад.
Нужно ли хранить промт после публикации изображения?
Это полезно для внутреннего учёта и восстановления происхождения результата. Минимально стоит сохранить промт, идентификатор задачи, дату, операцию и связь с финальным файлом.
Сколько стоит создать 10 000 картинок через API?
Если использовать операцию «Картинка по описанию» по цене 9 ₽ за запуск, 10 000 запусков стоят 90 000 ₽. Это расчёт стоимости генерации, а не дискового хранения.
Сколько стоит хранение 10 000 изображений?
По предоставленной информации отдельный тариф на хранение не указан, поэтому точную сумму определить нельзя. Она зависит от среднего размера файлов и тарифа используемого хранилища: при среднем размере 5 МБ 10 000 изображений займут около 50 ГБ без учёта дополнительных копий и служебных данных.
Нужно ли ставить на картинку водяной знак нейросеть?
Не во всех случаях. Требование о маркировке зависит от законодательства, правил площадки и конкретного способа публикации; внутреннюю запись о машинной генерации при этом имеет смысл сохранять независимо от наличия публичной отметки.
Как восстановить историю конкретной генерации?
Сохраните ID задачи, промт, дату, операцию и полученный файл. Состояние и результат задачи доступны через GET /tasks/{id}, поэтому идентификатор задачи удобно использовать как связующее поле между API и внутренним архивом.
Для подключения и просмотра списка доступных операций и цен используйте страницу API и выпуска ключа. В рабочем архиве при этом имеет смысл хранить не только саму картинку, но и её промт, ID задачи, версию и сведения об исходных материалах: это не решает юридические вопросы автоматически, зато позволяет восстановить происхождение каждого результата.
