Where should outbound request decision logic live in application code?

In several systems I work with, application code builds requests that are sent to external services (APIs, AI services, partner systems).

Right before sending, we often need to decide things like: should this request go out as-is? should something be removed or altered? or should the request be stopped entirely?

Today this logic tends to live in scattered places: inline checks in application code conventions enforced via reviews partial reuse of security tools that weren’t designed for this layer

I’m curious how others approach this from an architecture perspective: Do you centralize this decision logic somewhere? Or is it better kept close to each application? Have you seen patterns that age well as systems grow?

Looking for architectural perspectives and real experiences, not tooling recommendations.