The Governance Tax on a Single Image

Running an image-generation API sounds, on paper, like the simplest possible service: take a prompt, return a picture. I built one — it’s the API the last post mentioned, the one my agents call to illustrate the sites they’re building. And the actual generation call is simple. It’s everything I decided to wrap around it that turned “one API call” into a small, ongoing exercise in governance — the kind a company assigns to a department, and a one-person operation has to do for itself, line by line, on every image.

The first check: before the image exists

The first thing that happens to a prompt, before it ever reaches the image model, is that another model reads it. Not for taste — for the categories of request that create a problem regardless of what the image generator would have done with them. If the prompt review says no, the image is never generated at all.

That’s a second model call, every time, before any image exists. It costs money and it costs latency, and it produces nothing you can show anyone — its entire value is in what doesn’t happen next.

The second check: after it exists, if you really want to be safe

Here’s the layer that’s easy to skip, because the first one feels like it should be enough: a separate check on the output — the actual pixels — after the image is generated.

I didn’t build this layer because I imagined a hypothetical. I built it because of something I ran into on a different project, one I won’t get into the specifics of here: a generation model can produce output that drifts somewhere nobody asked for, because the tendency is baked into the model’s training, not the wording of the prompt. “The prompt didn’t ask for that” is true, and it doesn’t matter — the image exists, you’re the one who generated it, and you’re the one who’d be putting it in front of someone. A clean prompt isn’t a guarantee of a clean result. The only way to know is to look at what actually came out.

So: a second check, after generation, on the image itself. Another cost, every time, on every image — not a sample, not a spot-check.

What happens when something fails

If either check fails — the prompt at the door, or the image afterward — nothing ships. The image is deleted, and the system quietly tries again with a fresh generation. Whoever asked for it — in my case, one of my own agents — never sees the failure; they just get a result a little later than usual. The cost of the retry is mine. That’s the point.

The ledger

Every prompt, every check result, every image generated, every deletion, every retry — logged, timestamped, queryable. Not because anyone’s auditing me today, but because “we don’t allow that” and “that doesn’t happen here” are two different claims, and only the second one is something you can actually demonstrate after the fact, to anyone — a partner, a regulator, your own future self trying to reconstruct what happened on a bad day.

Three kinds of liability, one stack

It’s worth naming what each layer actually defends against, because it isn’t all the same thing:

• Legal exposure — the obvious one. Depending on what’s being generated and where, the operator can be on the hook for what a model outputs, independent of intent.
• Infrastructure exposure — your cloud provider, your payment processor, the model API you’re calling all have their own terms. Violate those and the consequence isn’t a lawsuit, it’s getting cut off — which, for an operation that’s one person and one instance, is its own kind of existential.
• Reputational exposure — one bad output, surfaced once, becomes the thing that happened, completely out of proportion to how rare it was.

The prompt-review layer mostly protects against the first and third by stopping the request before it’s made. The post-generation check is belt-and-suspenders against the first and second. The ledger is what turns a policy into something you can point to.

The invoice version of governance

For a company, all of this is a department — legal, trust & safety, an audit function, people whose job titles describe exactly one of these layers. For one person running an API off a personal cloud instance, it’s a line item: the base generation fee, plus a prompt-review call, plus — if it’s switched on — a post-generation check, on every single image. Multiply that by however many images a slideshow needs, and governance stops being a value statement and becomes a number on an invoice — one you can see, and choose to skip, request by request.

I don’t skip it. But I want to be honest that “don’t skip it” has a price, and that price is exactly why so many people do.

Why this looks familiar

I didn’t design this pipeline around draft-howlett-aigcsep-00. I built it, ran into a problem, and added a layer to survive it, and a third to prove the first two were working. Only afterward did I notice what I’d actually built: a plane that governs what’s allowed to happen, a plane that checks the result of what did happen, and a record of both — kept separate, so a failure in one doesn’t quietly become a failure in all three. That’s the same shape How It Works describes for AIGCSEP at the scale of an entire agent economy. I built a tiny one of those, by accident, because the alternative didn’t survive contact with how these models actually behave.

Nobody requires any of this from a developer running a personal image API. I do it anyway — the same regiment I described in the last post: voluntarily, on myself, first, because the alternative isn’t “no governance.” It’s governance after something goes wrong, paid for in a currency a lot more expensive than API calls.

— J.P. Howlett