Seguridad, rechazos y planes de respaldo
En producción, tu código debe gestionar el caso en el que Claude no quiere (o no puede) responder como se espera. Bien hecho, esto es invisible para los usuarios; mal hecho, es un fallo o una respuesta confusa.
Dos cosas distintas
- Un rechazo del modelo — Claude declina una solicitud (p. ej., porque la considera dañina). La respuesta lo señala (normalmente mediante un
stop_reason/contenido de rechazo). Trátalo como un resultado normal, no como un error. - Un bloqueo del clasificador/de seguridad — una capa de seguridad separada puede bloquear contenido. Esto puede tener un aspecto distinto al de un rechazo del modelo.
Saber cuál de los dos has obtenido te permite responder de forma adecuada en lugar de reintentar a ciegas.
Gestiónalo con elegancia
resp = client.messages.create(...)
if getattr(resp, "stop_reason", None) == "refusal":
# Don't show a raw/empty result. Offer a safe fallback or a clarifying ask.
show_user("I can't help with that as asked. Here's what I can do instead…")
else:
render(resp)
Reduce los rechazos no deseados
- Añade contexto legítimo. Una solicitud puede coincidir con un patrón sensible aunque la intención sea benigna; indicar el propósito real y legítimo ayuda.
- Sé específico. Una redacción vaga o provocadora invita a la cautela.
- No luches contra ello. Si una solicitud está genuinamente prohibida, el rechazo es correcto: diseña un camino elegante, no intentes hacer jailbreak.
Patrones de respaldo
- Una pregunta aclaratoria en lugar de un callejón sin salida.
- Una alternativa segura ("Puedo resumir la información pública en su lugar").
- Para los pipelines, deriva a una persona cuando la confianza/elegibilidad sea baja.