Prompt & Product
EN ES
Confianza y seguridad

Punto de control de permitir/denegar antes de que el modelo se ejecute

Un punto de control previo a la inferencia puede detener prompts gobernados y resultados de herramientas antes de que el modelo los vea, con un motivo visible para el usuario cuando la respuesta es denegar.

AutorPrompt & Product — Redacción
Publicado14 septiembre 2026
Lectura4 MIN
Illustration: Allow/deny checkpoint before the model runs

La decisión de seguridad debe ocurrir antes de que el modelo comience. Una solicitud denegada por el servidor de seguridad no llegó al modelo de Claude. El punto de control se sitúa entre la solicitud del usuario y la inferencia, y cuando responde que no, el usuario ve por qué. Este patrón convierte un control de seguridad en una superficie de producto.

Coloca el punto de control antes de la inferencia

Un prompt gobernado no debería ser juzgado después de que el modelo ya lo haya visto. El punto de decisión pertenece antes de la inferencia, donde la solicitud puede detenerse antes de convertirse en una llamada al modelo. Anthropic ofreció Inference hooks en beta a las organizaciones de Claude Enterprise. Las organizaciones de Claude Enterprise podían enviar cada prompt gobernado a un servidor de seguridad de IA operado por la organización antes de la inferencia.

La función se basaba en un protocolo de webhook abierto y un esquema publicado, permitiendo a las organizaciones conectar servidores existentes de prevención de fuga de datos de Netskope, Palo Alto Networks, Proofpoint o Zscaler. La función no estaba disponible en Amazon Bedrock ni en Google Cloud.

  • Delimita el tráfico gobernado. Decide qué prompts, resultados de herramientas, usuarios y clases de datos deben pasar por el punto de control, y luego redacta una política que nombre el chat, las acciones del agente, la salida de herramientas y cualquier contenido que salga del producto.
  • Dirige el producto a un webhook de seguridad, de modo que la solicitud se envíe a un servidor operado por la organización antes de la inferencia. El punto de extremo debe recibir la carga del prompt y devolver una decisión sin alterar la redacción del usuario.
  • Utiliza un esquema de permitir/denegar sobre un protocolo abierto, con un contrato de solicitud y respuesta que tu equipo de seguridad pueda inspeccionar en la revisión de código. La respuesta debe incluir una decisión legible por máquina y una breve explicación legible por humanos.
  • Establece un timeout corto para que el producto falle de forma segura y predecible cuando el servidor de seguridad sea lento o esté no disponible. La alternativa debe ser una espera acotada, una decisión segura y una alerta cuando el punto de control se degrade.
  • Despliega desde modo sombra hasta modo de aplicación, comenzando con una fase que registra las denegaciones que habrían ocurrido y luego cambiando gradualmente con una alternativa clara.
  • Muestra un motivo de denegación visible para el usuario en una carga que pueda registrarse, probarse y mostrarse al usuario sin exponer detalles de la política interna.
  • Mantén un registro de auditoría que respalde el motivo mostrado al usuario.

Haz que la denegación se explique a sí misma

Una pantalla de denegación debe decirle al usuario qué ocurrió, qué se bloqueó y qué puede hacer a continuación. El mensaje debe ser calmado, específico y breve. No debe asustar al usuario, ni debe fingir que el modelo se ejecutó de todos modos. La interfaz puede decir la detención con claridad. El motivo debe estar escrito para la persona, no para el auditor. Este prompt contiene una credencial es mejor que violación de política. El motivo puede ser lo suficientemente genérico para evitar filtrar la política, pero lo suficientemente específico para guiar la siguiente acción. Si el usuario puede reintentar, indica qué cambiar. Si no puede, indica a quién contactar.

Los resultados de herramientas necesitan el mismo tratamiento. El sistema inspeccionaba las respuestas de herramientas antes de devolverlas a Claude, cubriendo las llamadas a herramientas realizadas a través de MCP, skills y plugins. El usuario puede no ver la respuesta de la herramienta directamente, pero el producto aún debe registrar la decisión y, cuando corresponda, mostrar un aviso de que un resultado de herramienta fue retenido.

Despliega desde modo sombra hasta aplicación

No cambies el punto de control a modo de aplicación de inmediato. Comienza en modo sombra: registra lo que el servidor de seguridad habría denegado, pero deja que la solicitud continúe. El modo sombra le da al equipo una lista de falsos positivos sin bloquear usuarios. Luego aplica gradualmente, con una alternativa clara si el punto de control se comporta de forma incorrecta.

Andrew Grimmett, Vicepresidente de Seguridad de la Información de Bandwidth, dijo que la función le dio a su equipo un punto de inspección en tiempo real antes de que Claude procesara contenido. Antes de la aplicación, el equipo debe poder responder las preguntas fundamentales: ¿Qué vio el punto de control? ¿Qué decidió? ¿Por qué? El registro de auditoría debe almacenar el prompt o una referencia segura a él, la decisión, el motivo, la marca de tiempo y la versión de la política. El registro hace que el motivo sea defendible.

Publicidad