В Nano Banana 2 image safety не означает один переключатель. В Gemini API часть этой истории относится к настраиваемому prompt-side safety layer. Другая часть относится к более жесткому response layer, где вы видите OTHER, PROHIBITED_CONTENT и IMAGE_SAFETY. А поверх этого в Gemini Apps есть еще и product-level policy removal. Большая часть плохого дебага начинается не с того, что модель полностью непредсказуема, а с того, что все три решения смешивают в один фильтр.
Если запомнить только одно правило, пусть это будет оно: BLOCK_NONE — узкий control, а не master switch. Он меняет только четыре prompt-side категории в Gemini API. Он не переписывает built-in core protections у Google и не объясняет, почему задача может вести себя по-разному в Gemini Apps и в API.
Самый быстрый путь — сначала понять, какой контракт сработал:
- Если результат меняется после изменения
safetySettings, вы, скорее всего, все еще в настраиваемом слое. - Если API показывает
SAFETY,OTHER,PROHIBITED_CONTENTилиIMAGE_SAFETY, относитесь к этому как к routing signal, а не как к одному общему отказу. - Если одна и та же задача ведет себя по-разному в Gemini Apps и Gemini API, считайте app shell отдельной surface, а не точной копией API.
Примечание об источниках: статья основана на официальных документах Gemini API, help page для Gemini Apps, model card Gemini 3.1 Flash Image и актуальных complaint threads на 3 апреля 2026 года. Прямой Google capture в этом окружении был заблокирован, поэтому live-search observations опираются на fallback evidence, а не на притворно "чистый" снимок выдачи.
Что на самом деле означает image safety в Nano Banana 2
Nano Banana 2 в Gemini API соответствует модели gemini-3.1-flash-image-preview. Google позиционирует ее как быстрый image model с более высоким throughput. Это важно, потому что многие страницы до сих пор переносят язык безопасности из старых материалов про Nano Banana или Nano Banana Pro и описывают новый model как "то же самое, только строже". Такой shortcut ненадежен.
Более точная mental model такая: image safety в Nano Banana 2 может указывать как минимум на три разных контракта.
Первый контракт — это настраиваемая prompt-side safety system в Gemini API. Google документирует только четыре категории: harassment, hate speech, sexually explicit content и dangerous content. Когда разработчики говорят про safetySettings, они обычно имеют в виду именно этот слой.
Второй контракт — более жесткий block и response layer в самом API. Публичная schema документирует такие причины, как SAFETY, OTHER, PROHIBITED_CONTENT и IMAGE_SAFETY. Это не четыре разных слова для одного и того же отказа. Это route signals, которые подсказывают, нужно ли проверять settings, переписывать prompt, менять саму задачу или признать, что текущая surface для нее не подходит.
Третий контракт — product shell внутри Gemini Apps. Текущая документация Google показывает image generation, uploaded-image edits, image combination и personalized-image scenarios, но одновременно предупреждает, что изображения могут быть удалены по policy reasons. Поэтому Gemini Apps нельзя описывать как "просто API с более удобным интерфейсом". Это отдельная surface с другой user-facing логикой.
Как только вы разделяете эти три контракта, путаницы вокруг Nano Banana 2 становится намного меньше. Вы перестаете спрашивать, почему "safety filter такой random", и начинаете задавать единственный полезный вопрос: какой слой только что принял решение?
Что safety settings могут изменить, а что нет
Самое частое неправильное предположение вокруг Nano Banana 2 состоит в том, что BLOCK_NONE работает как выключатель модели. Текущая документация Gemini API это не подтверждает.
Что она подтверждает — так это более узкую и более полезную рамку. В Gemini API adjustable safety settings покрывают только четыре prompt-side категории:
HARASSMENTHATE_SPEECHSEXUALLY_EXPLICITDANGEROUS_CONTENT
Это означает, что BLOCK_NONE может быть правильным ходом, если запрос действительно попадает в один из этих configurable thresholds. Но это не универсальный ответ.
Google также прямо пишет, что core harms продолжают блокироваться за пределами этих adjustable settings. Поэтому если вы опустили или отключили configurable thresholds, а результат вообще не сдвинулся, сильный вывод здесь не в том, что "Google наверняка прячет еще один секретный фильтр". Более надежный вывод проще: вы, вероятно, изначально не находились в adjustable layer.
Из-за этого многие discussions по Nano Banana 2 ходят кругами. Один человек говорит: "Я уже поставил BLOCK_NONE везде." Другой отвечает: "Значит, у Google есть скрытый extra filter." Более защищаемый вывод другой: запрос, скорее всего, уже вышел за пределы configurable layer и попал в контракт, которым BLOCK_NONE никогда не управлял.
Практическое следствие простое. Используйте safetySettings только там, где наблюдаемый failure действительно похож на adjustable prompt-side layer. Если response surface говорит вам что-то другое, верьте routing signal, а не сводите любой отказ к settings problem.
Как читать SAFETY, OTHER, PROHIBITED_CONTENT и IMAGE_SAFETY
Nano Banana 2 становится заметно проще в эксплуатации, если воспринимать visible reason как инструкцию к следующему действию, а не как расплывчатую этикетку отказа.
В текущих документах Gemini API Google публично документирует причины вроде SAFETY, OTHER, PROHIBITED_CONTENT и IMAGE_SAFETY. В image-generation integrations вы можете видеть эти значения или очень близкие response-layer reasons внутри body. Более безопасный подход — читать visible reason как routing instruction.
| Visible reason | Что это обычно означает | Что делать дальше |
|---|---|---|
SAFETY | Запрос попал в configurable safety system. | Посмотрите safetyRatings, сравните их с текущими safetySettings и проверьте, действительно ли речь идет о четырех adjustable categories. |
OTHER | Запрос мог пересечь более широкую policy boundary или относиться к unsupported content. В troubleshooting docs Google прямо говорит, что BlockedReason.OTHER может означать Terms of Service или unsupported content. | Не трактуйте это как узкую threshold problem. Пересоберите задачу, упростите запрос или примите, что эта surface для него не подходит. |
PROHIBITED_CONTENT | Вы уже не в зоне мягкого false positive, а в более жесткой policy zone. | Не делайте бесконечные мелкие переписывания. Меняйте саму задачу или останавливайтесь. |
IMAGE_SAFETY | Image-generation safety layer заблокировал output. | Перепишите prompt, смените framing, поменяйте style или уйдите в более узкий troubleshooting path. Не предполагайте, что это лечится одним settings toggle. |
Главное — последняя колонка. Эти labels полезны именно потому, что они направляют к разным действиям.
Если вы видите SAFETY, docs дают вам legit settings path. Если вы видите OTHER, Google уже сигнализирует, что проблема может жить за пределами adjustable categories. Если вы видите PROHIBITED_CONTENT, нормальный ход — перестать проталкивать ту же самую задачу микроправками. А если вы видите IMAGE_SAFETY, это обычно image-layer block, а не доказательство того, что API settings были настроены неправильно.
Здесь есть и предел уверенности: Google не публикует детальную trigger taxonomy для каждого IMAGE_SAFETY или OTHER case. Поэтому не стоит делать вид, что эти labels раскрывают внутреннюю rulebook. Это route markers, а не полное объяснение.
Почему проваливаются даже benign prompts
Одна из причин, по которым Nano Banana 2 кажется непрозрачным, состоит в том, что даже нормальные use cases могут сталкиваться с friction. В актуальных complaint threads на Google developer forum до сих пор встречаются false positives на fashion, lifestyle и другие non-NSFW prompts. В model card Gemini 3.1 Flash Image Google также пишет, что продолжает снижать и false positives, и false negatives, что само по себе означает: баланс еще настраивается.
Правильное чтение этих evidence — ни "модель сломана", ни "все complaints — это ошибка пользователя". Более сильное чтение звучит так: публичный контракт по-прежнему неполон.
Например, benign reference-image edit может не пройти, даже если пользователь явно не просит sexual, hateful или violent content. Описание одежды может считываться жестче, чем ожидает автор запроса. Реалистичный portrait edit может казаться рутинным на одной surface и проваливаться на другой. Все это не доказывает существование скрытого official blacklist. Это доказывает, что operational friction сложнее, чем аккуратная публичная taxonomy.
Это различие критично. Как только пользователи начинают относиться к rumor threads как к official policy, качество дебага резко падает. Люди переобучаются на folklore, а не на evidence. Они говорят о "секретных правилах" увереннее, чем docs позволяют, а затем продолжают бить по одному и тому же prompt мелкими правками, не меняя реальную проблему.
Более здоровый workflow другой: логируйте точный failure, убирайте неоднозначность и меняйте за раз только один важный элемент. Переносите framing с identity- или body-centric language на task- или scene-centric language. Если в задаче есть люди, спросите себя, идет ли речь о photorealistic generation, editorial-style illustration или более безопасном reference transform. И если запрос продолжает проваливаться даже после этого cleanup, честный ответ иногда звучит не как "я еще не нашел магическую формулировку", а как "на этой surface это сейчас просто не поддерживается".
Gemini Apps против Gemini API
Многие плохие советы по safety начинаются с того, что Gemini Apps и Gemini API сводят к одному поведению.
Официальная help documentation Gemini Apps такую редукцию не поддерживает. Сейчас Google прямо описывает Nano Banana 2 в Gemini Apps как surface, где можно генерировать изображения, редактировать uploaded images, сочетать несколько картинок и делать personalized-image scenarios. Этого уже достаточно, чтобы отвергнуть blanket claim вида "Nano Banana 2 вообще не допускает изображения людей".
Но та же help page одновременно предупреждает, что сгенерированные изображения могут быть удалены, если system обнаружит possible policy issue. В этом и состоит ключевая оговорка. Product-level support для capability не означает, что каждый request пройдет. И app-level removal — это не то же самое, что документированный API response reason.
Именно поэтому cross-surface anecdotes так легко вводят в заблуждение. Один человек может сказать: "У меня это сработало в Gemini", другой — "API заблокировал ту же идею", и оба сообщения могут быть правдой одновременно. Shell, moderation path, user-facing messaging и enforcement timing здесь не идентичны.
Для операторов вывод практический. Если ваша задача ближе к consumer-style editing или personalized image manipulation, Gemini Apps может быть лучшей reference surface для понимания того, что сейчас вообще поддерживается. Если же ваша задача — production API integration, рассуждать нужно от documented API contracts, а не от app screenshots и forum anecdotes. Это связанные сигналы, но не взаимозаменяемые.
Когда стоит менять маршрут, а не просто retry
Один из самых полезных навыков в работе с Nano Banana 2 image safety — понимать, когда еще один retry является просто потерей времени.
Если вы получаете 200 OK, но без usable image, или видите явный IMAGE_SAFETY в response path, переходите к более узкому guide Nano Banana 2 возвращает 200 OK, но не дает изображения. Это очень конкретный operational failure mode со своей собственной debug-логикой.
Если же failure mix включает quota exhaustion, malformed requests или более широкие reliability problems, а не только safety-specific block, правильнее перейти в общий Nano Banana 2 не работает guide. Safety analysis не починит 429, bad parameter или transient service problem.
Если реальный вопрос состоит в том, насколько Nano Banana 2 вообще способен работать с людьми, portraits или personalized edits, лучше уйти в более узкую страницу ограничения Gemini image generation для людей. Она сосредоточена именно на human-image ветке, а не заставляет этот материал закрывать все сразу.
А если ваш job меньше похож на "расшифровать safety contracts Google" и больше похож на "доставить image generation через один стабильный app/API layer", уместнее смотреть на более широкий tooling surface вроде Nano Banana AI image generator. Это не отменит internal policy decisions внутри модели Google, но может снизить operational mess вокруг provider switching и fallback routing.
Более крупный вывод такой: во многих случаях правильный следующий шаг — это routing, а не еще один retry. Как только вы начинаете воспринимать Nano Banana 2 image safety как задачу по распознаванию контракта, бессмысленных повторов становится намного меньше.
FAQ
Отключает ли BLOCK_NONE все safety filters в Nano Banana 2?
Нет. Текущая документация Gemini API поддерживает более узкое прочтение: BLOCK_NONE меняет thresholds только для четырех prompt-side categories. Он не убирает built-in core protections Google и не схлопывает app-level policy behavior в тот же rule set.
Означает ли image safety, что Nano Banana 2 вообще не умеет работать с изображениями людей?
Нет. Текущая help page Gemini Apps явно показывает personalized-image и image-editing scenarios с людьми. Более осторожное утверждение такое: human-image requests находятся в более чувствительной зоне, а поведение Gemini Apps и Gemini API может расходиться.
Будет ли каждый IMAGE_SAFETY block тарифицироваться?
Безопаснее считать processed image-generation blocks потенциально billable, если только official surface не сказал прямо обратное. Google публикует текущий token-based pricing для Nano Banana 2, но в этом research pass не дает одной аккуратной публичной формулировки, которая покрывала бы все IMAGE_SAFETY cases. Поэтому статья сознательно не делает billing claim сильнее, чем это позволяет docs.
Как проще всего дебажить Nano Banana 2 image safety?
Сначала определите контракт. Спросите себя: это adjustable safety settings в Gemini API, более жесткий API response reason или product-level policy behavior в Gemini Apps? Если вы не можете назвать слой, весь остальной дебаг почти неизбежно превращается в догадки.
У Nano Banana 2 нет одного единственного image-safety filter. Есть несколько enforcement contracts, которые рынок любит называть одной фразой. Как только вы разводите их по местам, большая часть пустых retry исчезает сама собой.