Gemini может отклонить промпт, загрузку или правку изображения, хотя задача выглядит безобидной. В русской рабочей переписке это обычно описывают как “Gemini не создает изображение”, “контент не разрешен”, “фильтр сработал ошибочно” или “безопасный запрос отклонен”. Полезная реакция не в том, чтобы протолкнуть запрос любой ценой. Сначала определите, какой слой сказал “нет”: Gemini Apps, API-фильтр входного промпта, текстовый отказ модели, фильтр уже сгенерированного изображения, неподдерживаемая image-ветка, лимит аккаунта или жесткая граница политики.
| What you see | Likely layer | Evidence to inspect first | Safe next action |
|---|---|---|---|
| The Gemini app says it cannot create or edit the image | Gemini Apps refusal | Prompt wording, uploaded subject, face or person context, account, age, work or school controls, plan and feature availability | Clarify the allowed goal, try one fresh session, preserve the message, or report with evidence |
| API or AI Studio returns safety feedback | API prompt or model-safety branch | promptFeedback.blockReason, finishReason: SAFETY, safetyRatings, model, project and settings | Inspect the response object before changing the prompt |
| The prompt passes but no image returns | Output image safety or request-shape branch | IMAGE_SAFETY, IMAGE_PROHIBITED_CONTENT, BlockedReason.OTHER, response parts and model support | Simplify the request or stop when the visual goal is disallowed |
| The message mentions caps, heavy use or 429 | Account, plan, quota or rate branch | App plan, daily cap, API project quota, 429 body, retry delay and usage | Use the limit or 429 path, not a policy workaround |
| The request involves real people, public figures, minors, sexual content, violence, IP, privacy, deception or filter evasion | Hard policy or rights boundary | Subject, consent, source rights, intended use and prohibited category | Stop; do not rewrite the request to sneak it through |
A safe retry clarifies an allowed request. It names the non-deceptive purpose, removes likeness or rights ambiguity, simplifies the edit and avoids sexual, violent, privacy-sensitive or identity-confusing context. A bypass request does the opposite, so it should stop rather than be rephrased.
If the refusal still looks like a false positive, save the prompt, uploaded-image context, visible message, model or app surface, timestamp, account or project route and API fields before repeated retries. Community posts can show that false positives happen, but only your own evidence can support a useful report.
Start from the product surface
The same visible refusal can belong to different systems. Gemini Apps is a consumer product surface. Gemini API and AI Studio expose developer response objects. Vertex or Cloud routes may expose image-specific response filtering. A 429 or “limit reached” message is usually quota, capacity or account state, not proof that the image itself violated policy.
This distinction prevents three bad repairs. First, an app user should not start by changing API safety settings. The app has no promptFeedback object; the right checks are account, feature access, uploaded subject and visible app message. Second, an API developer should not rewrite prompt words before reading the response. The input may pass while the output image is blocked later. Third, a user should not treat every refusal as a Gemini bug. Some requests involve consent, privacy, identity, IP, sexual content, violence, child safety, deception or attempts to bypass abuse protections.
Official sources own different facts. Gemini Apps Help owns app image generation and editing behavior. Google policy pages own prohibited uses and safety categories. Gemini API safety settings own configurable categories and response fields. Image responsible AI docs explain model refusal, prompt filtering and generated-image filtering. Сообщения сообщества полезны как словарь симптомов, но они не доказывают, что каждый отказ является ошибкой.
| Diagnostic question | Why it matters | If yes |
|---|---|---|
| Did the refusal happen in Gemini Apps? | There are no API fields to tune | Check account, upload, feature availability and visible message |
| Did it happen in API or AI Studio? | The response can identify the layer | Save fields before rewriting |
| Did the prompt pass but image output fail? | Output filtering is separate | Check response parts and image finish reasons |
| Did the error mention quota or 429? | This is not a policy refusal | Use backoff, quota and limit diagnosis |
Diagnose Gemini Apps messages
For Gemini Apps, begin with the visible context. A prompt may sound safe in isolation, but the uploaded image can include a face, public-figure cue, child, private room, medical context, intimate context, brand mark or edit that could mislead viewers. App behavior can also change with account age restrictions, work or school controls, region, language, plan, feature rollout, daily caps or current demand.
The practical app-side question is not “which word should I replace”. It is “what might the product be seeing”. If the prompt says “make this more dramatic”, the model may need more context. If the actual task is a product-background cleanup, say that directly. If the image is your own face or an authorized subject, say that the edit is consented and non-deceptive. If it is a public figure, a child or a private person without consent, do not try to push it through.
| App check | Look for | Safe action |
|---|---|---|
| Uploaded subject | Person, public figure, minor, private setting, medical or intimate image | Confirm consent and rights; stop if uncertain |
| Prompt goal | Could the edit deceive, sexualize, harass, violate privacy or confuse identity? | Rewrite as a narrow benign edit |
| Account route | Personal account, managed account, age limit, plan feature | Confirm the feature is available in that route |
| Conversation context | Earlier turns may make the request look unsafe | Try one fresh session with clearer context |
| Limit signal | Cap, redo limit, heavy use, temporary availability | Move to the limit branch |
False positives are possible. Face edits, pet or person misclassification, public-figure wording and old conversation context can all make a benign task look risky. But possible false positive is not permission to bypass the filter. Preserve the message and context before you test many variations, because a clean evidence trail is more useful than a list of failed rewrites.
Read API and AI Studio fields before editing the prompt
For API work, the response object is the first diagnostic artifact. promptFeedback.blockReason points to input blocking. finishReason: SAFETY means a candidate stopped on safety. safetyRatings can show which configurable category was involved. IMAGE_SAFETY or IMAGE_PROHIBITED_CONTENT points closer to generated-image filtering. BlockedReason.OTHER may indicate unsupported request shape, terms-related handling or a condition outside ordinary safety thresholds.
| Signal | Practical meaning | Next action |
|---|---|---|
| promptFeedback.blockReason | Input was blocked before generation | Compare prompt, category and prohibited-use boundary |
| finishReason: SAFETY | Candidate stopped for safety | Review ratings and context before changing settings |
| IMAGE_SAFETY | Generated image was filtered | Reduce visual ambiguity or stop when the goal is unsafe |
| IMAGE_PROHIBITED_CONTENT | Output or request hit a prohibited boundary | Stop; do not treat it as prompt polish |
| BlockedReason.OTHER | Unsupported, terms-related or route-shape issue is possible | Check model support, request parts, project and docs |
| No image part | Text route, unsupported model, malformed request or filtering | Check model capability, response parts and SDK parameters |
BLOCK_NONE is not a universal off switch. It relates to configurable API safety filters for supported categories. Core protections, Terms-related blocks, unsupported requests and image-output safety can still stop the request. If the prompt was accepted but the generated image disappeared, a text safety threshold change may not touch the real layer.
Use a dedicated API safety guide only after the branch is confirmed. If the exact problem is a Nano Banana Pro policy-blocked error, use the Nano Banana Pro troubleshooting owner. Широкая диагностика нужна только до классификации слоя; после этого лучше перейти к узкому владельцу проблемы, а не смешивать app limits, API settings и hard-policy stop в один ремонт.
Safe clarification versus evasion
A safe retry makes a legitimate request more understandable. It can say that the edit is for a product catalog, that the person is the uploader with consent, that the goal is lighting cleanup, that the result should not change identity, or that the output is fictional and non-deceptive. It does not ask the model to hide a public figure, remove safeguards, imitate a protected character, sexualize a subject, expose private information or bypass a filter.
| Request type | Retry? | Discipline |
|---|---|---|
| Product image, background, lighting, layout or harmless creative edit | Usually yes | State the concrete edit and remove unnecessary sensitive context |
| Own photo or authorized person | Sometimes | Mention consent, purpose and identity handling |
| Public figure, minor, private or intimate context | High caution | Stop unless the allowed basis is clear |
| Brand, logo, protected character or rights-sensitive style | Often risky | Use original descriptive direction |
| Sexual, violent, extremist, self-harm, privacy-invasive, deceptive or bypass request | No | Stop |
The difference is not just wording; it is the underlying job. “Clean the white background of my product photo” clarifies an allowed task. “Make the public figure look like they endorsed my product but avoid the filter” is evasion. Такая поломка часто ошибочно сводится к замене слов, но замена слов без проверки согласия, прав и цели не является надежным или безопасным workflow.
Preserve a false-positive evidence packet
If the branch still looks like a false positive, collect evidence before the context disappears. A useful report should let another person reproduce the issue without guessing the route, model or account state. It should also avoid exposing private uploads in a public forum.
| Evidence | Why it matters |
|---|---|
| Surface | App, AI Studio, API, Vertex or wrapper determines the owner |
| Time | Models, limits and policy behavior can change |
| Model and route | The same prompt can behave differently by route |
| Prompt and upload context | Multimodal context affects classification |
| Visible message | App text and API fields point to different branches |
| API fields | promptFeedback, finishReason, safetyRatings, response parts and block reasons make the report actionable |
| Account or project state | Plan, managed account, quota, billing and region can change symptoms |
| Minimal reproduction | A shorter prompt separates hidden context from a real false positive |
Do not post private photos, client assets, children, documents or sensitive personal material publicly. Redact, describe only necessary context, or use an internal support channel. The goal is a reproducible false-positive report, not a public dump of the original image.
Use a narrower owner after the branch is clear
Once the layer is known, the next guide should be narrow. API safety settings are not the same as app caps. Nano Banana Pro policy-blocked errors are not the same as general Gemini Apps refusals. 429 is an operational quota problem. Output image safety is not always fixable by changing the text prompt.
| Confirmed branch | Better owner |
|---|---|
| API safety categories, thresholds and response fields | Gemini API safe content policy |
| Exact Nano Banana Pro content blocked or policy blocked error | Nano Banana Pro policy and blocked errors |
| App caps, plan limits, project quota or image-per-minute limit | Gemini image generation rate limits |
| API 429, RESOURCE_EXHAUSTED, retry delay or quota metric | Gemini image generation 429 fix |
This split protects the reader from wasted work. An app account issue should not become a code change. A quota error should not become a policy complaint. A hard safety or rights boundary should not become a prompt engineering challenge.
Operational protocol before another retry
Before another retry, write down the surface, model, account route, exact message, and whether the prompt or output was blocked. Then decide whether the next action is clarification, waiting for a reset, checking an API field, reporting a possible false positive, or stopping. If you cannot name the branch, do not run a long series of near-duplicate prompts.
For teams, store this protocol in the product logging path. Save the response body for API calls, but avoid storing private uploads unless there is a clear legal and access-control reason. Add a label for “possible false positive” only after the hard-stop categories and quota branches have been checked. A disciplined log prevents the same incident from being explained three different ways by support, engineering and content teams.
Часто задаваемые вопросы
Why can Gemini reject my own photo?
Because own-photo edits can still involve identity, privacy, intimate context, medical context or misleading before-and-after transformations. Clarify consent and non-deceptive purpose, then stop if the output would mislead or expose sensitive information.
Why does Gemini treat a harmless image as a public figure or real person risk?
Faces, names, filenames, conversation context and requested edits can create identity cues. Check those cues before calling it a false positive. Save the message and context for reporting.
Does a paid Gemini plan remove image safety refusals?
No. A paid plan may affect feature access, image caps or model availability, but it does not remove Google policy boundaries. If the message is about limits, use the limit branch; if it is a safety refusal, diagnose the safety layer.
Does BLOCK_NONE disable Gemini image safety?
No. BLOCK_NONE relates to configurable API safety filters. Core protections, terms-related blocks, unsupported requests and output-image filtering can still stop the result.
Why did the same prompt work yesterday?
Model routing, app rollout, account state, conversation context, uploaded-image interpretation, quota and safety behavior can change. Compare the route, timestamp, model, prompt, upload and response fields.
Why did Gemini answer with text instead of an image?
The call may have used a text route, a model that does not support the requested image output, wrong SDK parameters, an unsupported request shape or filtered output. Check response parts and model capability.
How should I report a false positive?
Include surface, time, model, prompt, upload context, exact message, account or project route, API fields and minimal reproduction. Redact private material.
Can I bypass Gemini image safety filters?
No. Do not disguise prohibited content, evade protections, violate consent or use another route to remove privacy, identity, IP, sexual, violence or child-safety boundaries. Clarify allowed work or stop.
