El 5 de agosto de 2026 Anthropic lanzó inference hooks en beta para Claude Enterprise: un punto de inspección, controlado por tu organización, que revisa cada prompt —y cada respuesta de herramienta— antes de que llegue al modelo y decide permitir o bloquear. Es la primera vez que un proveedor frontier mete prevención de fuga de datos (DLP) en línea dentro del propio flujo de inferencia. Si tu equipo ya usa Claude, ChatGPT o Copilot a diario, esto no va de otra función de productividad: va de gobernar qué datos salen de tu empresa. Aquí tienes qué es, qué todavía no resuelve, y qué haríamos nosotros con un cliente.

Qué ha pasado

El blog oficial de Anthropic describe el mecanismo así: antes de que el modelo empiece a generar, Claude envía el prompt y su contexto al servidor de seguridad de tu organización a través de una conexión firmada. Ese servidor devuelve un veredicto —allow o deny— y Claude solo continúa cuando lo recibe. La misma inspección se aplica a las respuestas de herramientas: cuando Claude llama a una tool —incluidas las conectadas por MCP, skills y plugins—, la respuesta se revisa antes de volver al modelo.

Los detalles que importan:

  • Cobertura: chat, Claude Code y Claude Cowork, con una única configuración a nivel de organización.
  • Protocolo abierto: es un protocolo basado en webhooks con esquema publicado. Puedes enrutar los veredictos a plataformas DLP existentes (Netskope, Palo Alto Networks, Proofpoint, Zscaler) o a un servidor propio.
  • Latencia y fallo: el servidor debe responder dentro de un timeout configurable, con 5 segundos por defecto. Tú decides qué pasa si no responde: bloquear o dejar pasar.
  • Despliegue gradual: modo shadow (permite todo y solo observa), exclusiones por rol, rollout por porcentaje y política de fallo configurable.

En paralelo, el 6 de agosto Anthropic añadió escaneo automático de skills y plugins de terceros para planes Enterprise. La dirección es clara: cerrar el perímetro alrededor del uso corporativo de IA.

Qué implica para tu producto y tu empresa

El problema real que ataca esto no es técnico, es organizativo: shadow AI. Tu gente ya pega fragmentos de código propietario, datos de clientes y documentos internos en asistentes de IA, y hasta ahora no tenías un control en línea equivalente al que llevas años aplicando en email y tráfico web. Inference hooks te da, por primera vez, ese punto de inspección antes de que el dato salga hacia el modelo.

Hay un segundo ángulo que a menudo se pasa por alto y que a nosotros nos interesa especialmente: la inspección de respuestas de herramientas. Si construyes agentes que leen de sistemas internos vía MCP, el riesgo no es solo lo que el usuario escribe, sino lo que una tool inyecta en el contexto (prompt injection, datos que no deberían viajar). Que el veredicto cubra también ese tramo es lo más relevante para quien tiene agentes en producción, más allá del caso de uso "empleado en el chat".

Para verticales reguladas —FinTech, HealthTech, seguros— encaja además con las obligaciones del deployer que ya comentamos a propósito del AI Act de agosto de 2026: poder demostrar que hay controles y trazabilidad sobre qué entra y sale del modelo deja de ser opcional.

Lo que todavía NO resuelve

Aquí es donde toca ser honestos, porque la nota de prensa vende más tranquilidad de la que hay:

  • El veredicto es binario: allow o deny. No redacta ni enmascara. Un prompt con un número de tarjeta se bloquea entero; no se limpia y se deja pasar. En la práctica, o afinas mucho las reglas o generas fricción.
  • Solo cubre la entrada (por ahora): la validación de las salidas del modelo está anunciada como futura. Hoy inspeccionas lo que entra, no lo que Claude responde.
  • Solo superficies Enterprise: aplica a chat, Code y Cowork. No cubre el acceso por API, ni despliegues sobre Amazon Bedrock o Google Cloud/Vertex. Si tu producto llama a la API directamente —el caso de casi cualquier app que construimos—, inference hooks no te toca: la gobernanza sigue siendo responsabilidad de tu arquitectura.
  • Es DLP, no seguridad de agentes: no sustituye al sandboxing de código, la gestión de credenciales efímeras ni el control de egress de un agente que ejecuta acciones. Eso es otra capa (lo tratamos en cómo aislar agentes de IA que ejecutan código y en seguridad MCP).

Nuestra recomendación

Para quién sí, ya: si tu empresa está en Claude Enterprise y operas en un sector regulado, actívalo —pero empieza en modo shadow. Observa dos o tres semanas qué se bloquearía antes de imponer deny; casi siempre las reglas iniciales son demasiado agresivas y acabas rompiendo flujos legítimos. Enrútalo a tu DLP existente si ya tienes uno; no montes un servidor nuevo por montarlo.

Para quién no es la respuesta: si tu exposición está en el acceso por API o en agentes que construyes tú (Bedrock, Vertex, API directa), inference hooks no te cubre y no debes esperar a que lo haga. Ahí la solución es de arquitectura: un gateway de LLM propio que centralice inspección, políticas y trazabilidad en el egress, independiente del proveedor. Es justo lo que defendemos para evitar el vendor lock-in, y ahora suma un motivo más: la gobernanza no puede depender de la superficie concreta de un vendor.

Dicho de forma directa: inference hooks es una buena primera pieza para el shadow AI del empleado, pero no la confundas con una estrategia de gobernanza de IA. La entrada cubierta, la salida no; el chat cubierto, tu producto no. La foto completa sigue siendo tuya.

En Dribba llevamos desde 2011 construyendo producto (somos Partner oficial de Flutter de Google desde 2017) y los últimos años montando agentes y gateways de IA para clientes con datos sensibles. Si estás decidiendo dónde poner la frontera de gobernanza —en el vendor o en tu arquitectura—, hablémoslo: la respuesta honesta suele ser "en las dos, pero no confíes en una sola".