Anthropic anunció el 1 de septiembre de 2026 Enterprise Frontier Safeguards (EFS), una arquitectura para que organizaciones que usan modelos avanzados conserven los registros de actividad en infraestructura de nube controlada por ellas, mientras aplican monitorización automatizada para detectar usos graves o credenciales comprometidas.

La propuesta intenta resolver una tensión empresarial concreta. Detectar abuso distribuido entre sesiones y cuentas requiere observar patrones durante un periodo; sectores regulados, al mismo tiempo, no quieren entregar a otro proveedor la custodia de conversaciones, código, documentos o señales de actividad sensibles. EFS separa esas funciones: el cliente conserva almacenamiento, claves, políticas de acceso y auditoría; el sistema del proveedor analiza señales y remite alertas al equipo autorizado por la organización.

La noticia no convierte automáticamente a una plataforma de IA en segura ni compatible con cada regulación. Sí aporta un patrón útil para cualquier empresa que esté desplegando agentes: la monitorización necesita datos, pero la custodia, la revisión humana y la respuesta no tienen por qué quedar concentradas en el fabricante del modelo.

Qué anunció Anthropic

Según la publicación oficial, EFS combina una experiencia equivalente a retención cero por parte de Anthropic con controles que analizan una ventana móvil de actividad. Los registros pueden guardarse en la cuenta cloud del cliente —por ejemplo, Amazon S3, Azure Blob Storage o Google Cloud Storage— bajo sus claves de cifrado, permisos y registros de auditoría.

Cuando la monitorización automatizada identifica un patrón que requiere atención, envía la señal al cliente. La revisión humana puede realizarla el propio personal de la organización; Anthropic afirma que no necesita una revisión humana por parte de sus empleados para este esquema. Los controles de almacenamiento, claves administradas por el cliente y revisión automatizada serán optativos.

El despliegue está previsto por fases, con una disponibilidad más amplia durante el otoño de 2026. La empresa indica que EFS será compatible con Claude Code, Claude Enterprise, su plataforma y ofertas de AWS, Google Cloud y Microsoft. También sostiene que no cobrará una tarifa adicional por EFS, aunque el proveedor cloud facturará almacenamiento, lecturas, escrituras y transferencia según corresponda.

El problema no es guardar menos, sino decidir mejor

Una política de retención cero reduce exposición porque el proveedor no conserva el contenido después de procesarlo. Pero también puede eliminar el contexto necesario para detectar una campaña que distribuye pequeñas acciones entre cuentas, sesiones y herramientas. Un evento aislado parece legítimo; la secuencia revela reconocimiento, abuso de credenciales o preparación de una acción ofensiva.

La alternativa no debería ser conservar la totalidad sin límite. El diseño correcto parte de finalidades: qué amenaza necesita observarse, qué campos permiten detectarla, durante cuánto tiempo, quién puede acceder, qué alerta se genera y cómo se elimina la información. Minimización y seguridad no son objetivos opuestos si la arquitectura documenta esa relación.

Para una organización, “retención cero del proveedor” y “retención controlada por el cliente” son afirmaciones diferentes. La segunda mantiene datos en un entorno propio, pero crea responsabilidades de configuración, coste, disponibilidad, borrado, investigación y acceso interno. La custodia vuelve a casa; también vuelve el trabajo.

Cinco decisiones de arquitectura que EFS vuelve visibles

  1. Ubicación. La empresa debe elegir cuenta, región, servicio y separación por entorno para los registros de IA.
  2. Claves. Debe definir quién administra el cifrado, cómo se rotan claves y qué ocurre ante una revocación.
  3. Acceso. Necesita limitar lectura a funciones autorizadas y evitar que desarrolladores, proveedores o el propio agente accedan por defecto.
  4. Observación. Debe acordar qué patrones analiza el sistema automatizado, qué datos consume y cómo se controla su desempeño.
  5. Respuesta. Cada alerta requiere propietario, nivel de severidad, evidencia, plazo y capacidad de suspender una identidad o flujo.

Estas decisiones no pertenecen únicamente al equipo de IA. Seguridad, privacidad, jurídico, datos, arquitectura, compras y responsables del proceso deben compartir criterios. Un CISO as a Service puede convertirlos en un modelo de decisión para dirección, con responsables y umbrales claros, antes de que cada área contrate o configure su propia variante.

Custodia del cliente no significa control automático

Guardar registros en una cuenta empresarial reduce la dependencia del fabricante, pero un bucket mal configurado, una clave demasiado compartida o una política de acceso extensa puede crear una exposición nueva. El control debe demostrarse con configuración, pruebas y auditoría; no con la dirección de facturación de la nube.

También existe riesgo interno. Los registros de un agente pueden contener código, conversaciones, contratos, datos personales, secretos o instrucciones que revelan procesos. La revisión humana debe limitarse por necesidad y quedar trazada. Los analistas requieren procedimientos para tratar contenido sensible sin copiarlo a tickets, chats o herramientas que amplíen el perímetro.

La recuperación merece igual atención. Si la organización necesita investigar un incidente, debe poder inmovilizar una ventana de registros sin romper las reglas ordinarias de borrado. La preservación debe ser excepcional, autorizada y documentada. De lo contrario, una política de retención bien intencionada puede eliminar evidencia o conservar datos indefinidamente por precaución.

Qué debe exigir a la monitorización automatizada

Una alerta útil explica el patrón, las sesiones relacionadas, la identidad, el periodo y la razón por la que supera el umbral. También debe indicar qué información analizó y qué quedó fuera. Una puntuación opaca sin contexto obliga al equipo a confiar ciegamente o a ignorar señales por fatiga.

La organización debería medir falsos positivos, falsos negativos conocidos, tiempo hasta la alerta, cobertura por producto y capacidad de impugnar una clasificación. Los controles deben probarse con escenarios permitidos: credencial expuesta, secuencia de reconocimiento, transferencia anómala, intento de usar herramientas no aprobadas y actividad legítima de un equipo de seguridad.

La automatización tampoco reemplaza controles preventivos. Identidades de corta duración, mínimo privilegio, aislamiento de herramientas, aprobación para acciones de alto impacto y límites de red reducen lo que un agente puede hacer. La monitorización detecta desviaciones; la arquitectura limita consecuencias.

Lo que este modelo no resuelve por sí solo

No determina si una tarea debe delegarse a un agente, si los datos son adecuados para ese uso ni si el modelo produce resultados fiables. Tampoco inventaría un inventario de aplicaciones, corregiría permisos excesivos o validaría que una integración cumple el contrato y la regulación aplicable.

No elimina la dependencia tecnológica. Aunque los registros permanezcan en la nube del cliente, la detección y el modelo siguen siendo servicios con condiciones, disponibilidad y evolución propias. La organización necesita procedimientos para cambios de versión, interrupciones, pérdida de compatibilidad y salida del proveedor.

Finalmente, no convierte una señal automatizada en una conclusión disciplinaria, legal o de fraude. Las alertas pueden contener errores y requieren contexto. El proceso debe separar detección, investigación y decisión, con revisión humana proporcional al impacto.

Lectura para España y Colombia

En España, la custodia de registros dentro de una cuenta controlada por el cliente puede facilitar requisitos internos de localización, acceso y auditoría, pero no sustituye un análisis de finalidad, base aplicable, transferencias, proveedor y periodo de conservación. Las empresas deben revisar la arquitectura concreta y no inferir cumplimiento a partir del nombre comercial de una función.

En Colombia, bancos, aseguradoras, salud, BPO, tecnología y servicios profesionales también necesitan saber qué conversaciones y datos atraviesan agentes empresariales. Mantener registros bajo claves propias puede fortalecer el control, siempre que la organización tenga capacidad real para administrar nube, identidades y respuesta. Una cuenta controlada por el cliente sin gobierno puede ser solo otra ubicación de riesgo.

Para ambos mercados, la novedad refuerza una tendencia: la seguridad de IA empresarial se está moviendo de políticas generales a controles de arquitectura. El debate ya no es únicamente si el proveedor entrena con los datos, sino quién almacena la actividad, quién la puede leer, qué abuso se detecta y quién decide qué hacer.

Cómo integrarlo en gobierno de IA y SGSI

El sistema de gestión debe registrar cada caso de uso, propietario, modelo, datos, herramientas, privilegios, controles y evidencia. La monitorización de agentes debe conectarse con gestión de incidentes, proveedores, continuidad y revisión de accesos. Un sistema de gestión de IA basado en ISO 42001 aporta el marco para gobernar propósito, riesgo, supervisión y mejora continua.

El SGSI aporta controles sobre activos, identidades, registros, proveedores, incidentes y continuidad. Ambos sistemas deben compartir evidencias para evitar dos burocracias paralelas. Un registro de actividad de agentes, por ejemplo, puede servir para seguridad, auditoría del caso de uso y análisis de impacto si sus campos, acceso y retención se diseñan desde el inicio.

La evaluación también debe cubrir responsabilidades contractuales. ¿Quién notifica una anomalía? ¿Quién preserva registros? ¿Puede el cliente exportarlos en un formato útil? ¿Qué ocurre al terminar el servicio? ¿Cómo se demuestra que el proveedor no realiza revisión humana? Las respuestas deben quedar en acuerdos, configuración y pruebas.

Plan de adopción para los próximos 30 días

  1. Inventariar agentes y modelos. Incluir pilotos, APIs, extensiones, herramientas de código y servicios contratados por áreas.
  2. Clasificar actividad. Determinar qué registros pueden contener datos personales, secretos, código, información regulada o decisiones sensibles.
  3. Definir finalidades. Asociar cada campo y periodo de retención con una amenaza, obligación o necesidad investigativa concreta.
  4. Diseñar custodia. Elegir cuenta, región, claves, permisos, inmutabilidad, borrado, copias y separación entre entornos.
  5. Probar detección. Ejecutar escenarios autorizados y medir si las alertas aportan contexto accionable sin desbordar al equipo.
  6. Preparar respuesta. Establecer quién valida, contiene, preserva evidencia, informa y autoriza el restablecimiento.
  7. Revisar al proveedor. Confirmar versiones compatibles, límites técnicos, cambios previstos, costes cloud y mecanismo de salida.

Un Security GAP Assessment puede comparar este estado con los controles ya existentes y producir una hoja de ruta priorizada. El objetivo es aprovechar la nueva capacidad sin confundir disponibilidad del producto con preparación organizacional.

Límites y afirmaciones pendientes

EFS fue anunciado el 1 de septiembre y su despliegue general está previsto para más adelante en el otoño. Por tanto, gran parte de la evaluación independiente, experiencia operativa y detalle contractual todavía no existe públicamente. Las capacidades pueden variar por producto, nube, elegibilidad y fase de lanzamiento.

Las cifras sobre clientes que participaron en el diseño y las características descritas proceden de Anthropic. AWS confirmó la integración prevista para clientes elegibles en su plataforma. No se han realizado pruebas independientes para este artículo y no debe interpretarse como una recomendación de compra.

Diseñe el control antes de entregar tareas críticas a un agente

Insylux puede ayudar a inventariar usos de IA, definir custodia y retención, evaluar proveedores, integrar monitorización con el SGSI y convertir alertas en decisiones operativas.

Diseñe su marco de seguridad y gobierno de IA con el Equipo Insylux.

Fuentes y alcance

Fuentes consultadas el 1 de septiembre de 2026. Las características y el calendario proceden del anuncio de los proveedores. La lectura de gobierno, los controles para España y Colombia y el plan de adopción son análisis del Equipo Insylux.