Every platform’s filter is different, and that is a production risk

Three filters, not one

When a hosted service refuses to make your picture, it is rarely a single check. Three layers are usually stacked.

The prompt filter looks at your text before anything runs. It is a keyword and pattern layer, deliberately over-inclusive, and it does not understand context. “Shoot the product against a white wall”, “kill the overhead lights”, “a child’s birthday party”, “she is bleeding out from the ears” in a medical illustration brief: all of these have been refused by mainstream services at some point. The refusal is fast and usually says something vague about policy.

The output classifier looks at the generated image before returning it. This one you notice as a black frame, a blur, or a silent re-roll. It catches things the prompt filter could not predict, which is why an innocent prompt sometimes fails on one seed and passes on the next: the classifier is judging the actual pixels, and the model produced something borderline.

The account layer counts your refusals. Several services throttle, warn or suspend after repeated blocks. This matters more than the individual refusal, because a legitimate brief that trips the filter twenty times in an afternoon can cost you the account you are delivering from.

Why this is a production problem

A filter is a business decision about the platform’s exposure, not a judgement about your work. That has three consequences on a deadline.

1. It changes without notice. A prompt that worked in March fails in September because policy tightened after an incident. Your archived workflow is not reproducible on a hosted service in the way a local one is.
2. It differs across services. Anatomy for a medical illustration, a historical war photograph, a horror film poster, a bruise for a domestic-violence charity campaign: each of these passes somewhere and fails somewhere else.
3. Named people are blocked almost everywhere. Most major services block prompts naming living public figures, and several block historical ones too. This is the filter behaving as designed, and it is not going to be argued with.

What to do about it

Do not try to defeat a filter. Leaving aside that it usually violates the terms you agreed to, evading a safety system is the fastest way to lose an account mid-project, and “my generator got suspended” is not a thing you can say to a client.

Do the boring things instead:

• Rephrase clinically. “Anatomical cross-section, medical textbook illustration” clears filters that “cut open” does not, and describes the brief more accurately anyway.
• Split the image. Generate the difficult element separately or photograph it, and composite. Most “impossible” briefs are one small region.
• Keep a fallback route. If the work is sensitive (health, conflict reporting, harm-reduction campaigns) plan for open weights on your own machine from the start, where the only filter is the one you choose to run.
• Check the filter early. If a campaign concept depends on imagery you suspect is borderline, test it in the first hour, not the night before delivery.

The limitation to be honest about

Local open weights are not filter-free either, and pretending otherwise is a disservice. Most open image models were trained on datasets that had explicit material filtered out, and several have an additional safety checker you can disable. Removing the checker does not restore what was never trained in: the model is weak at the categories the dataset excluded, and will produce distorted anatomy rather than the thing you asked for.

And the responsibilities do not disappear with the filter. Non-consensual sexual imagery, sexual content involving minors, and fabricated imagery of real identifiable people are illegal or actionable in most jurisdictions regardless of what software produced them. A local model removes a platform’s guardrail. It does not remove the law, and it certainly does not remove your name from the invoice.

The false-positive tax, in numbers

It is worth having a sense of scale. On a difficult-but-legitimate brief (trauma, conflict, medical, anything involving injury) expect somewhere between one in five and one in three attempts to be refused or silently re-rolled on a mainstream hosted service. That is not a defect report; it is the design point, because the cost of letting through one harmful image is, for the provider, much higher than the cost of annoying you.

Build that into your estimate. If a brief has four sensitive frames and you are on a hosted service, budget the time as though it has six, and tell the client early that the imagery may need to be shot or composited instead. The version of this conversation you have on day one is short. The version you have at 9pm the night before delivery is not.

Write the refusals down

Keep a short log of what was refused and where. Two lines per incident: the prompt, and the service. Within a month you will have a map of which service tolerates which subject matter, and that map is worth more than any general advice about which provider is “best”, because it is measured on the work you actually do rather than on somebody else’s.

It also gives you something to show a client when you have to explain why a concept needs rethinking, which is a far better conversation than an unsupported assertion that the tool will not do it.