Cyber Verification Program de Anthropic: cómo evaluar el acceso en tu empresa

1. La noticia: acceso con condiciones

El 6 de octubre de 2026, Anthropic amplió el Cyber Verification Program (CVP), con niveles Defense, RedTeam y Specialized y verificación de elegibilidad. Fuente: anuncio de Anthropic.

La pregunta útil para una organización es qué necesidad justifica solicitar ese acceso. «Queremos usar IA para seguridad» resulta demasiado amplio para definir permisos o evaluar un piloto. «Queremos ayudar a un analista a ordenar hallazgos de una aplicación de pruebas» permite delimitar un flujo, identificar sus datos y observar si el resultado sirve. Esa precisión debería preceder a cualquier elección de nivel.

2. Tres niveles: qué sabemos y qué debemos preguntar

Esta tabla separa los nombres acreditados de las preguntas que una empresa debería resolver. Las preguntas son una guía editorial propia; no describen permisos concedidos por el proveedor.

No conviene convertir el nombre de un nivel en una autorización técnica. El equipo debe pedir el alcance aplicable a su caso y documentar las restricciones antes de diseñar una operación. Una prueba autorizada en un entorno propio tampoco entrega permiso para intervenir sistemas de terceros.

3. Verificación del proveedor y autorización interna

Propongo trabajar con dos expedientes: la solicitud de acceso y la aprobación interna del caso de uso. En el segundo deberían figurar el responsable del servicio, los activos permitidos, las acciones excluidas, la ventana de pruebas y la persona que puede detenerlas. Así, el equipo sabe qué puede hacer aunque cambie el estado de su solicitud.

Una ficha de una página puede bastar para comenzar: problema, alcance, datos admitidos, resultado esperado y criterio de cierre. Si no es posible completar esos campos, todavía falta definir el trabajo. La revisión interna también debe preguntar quién recibe los hallazgos y cómo se evita que una recomendación del modelo llegue directamente a producción. El acceso solicitado y la responsabilidad sobre el sistema necesitan decisiones explícitas.

4. Leer las pruebas sin convertirlas en una garantía

Anthropic reporta pruebas con Claude Opus 5.5 en CyScenarioBench: 50 por nivel; Defense bloqueó 46 en algún punto y RedTeam completó 34. No contamos con validación independiente de esos resultados. Fuente: Anthropic.

Esos conteos no permiten calcular cuánto mejorará la seguridad de tu empresa. Para tomar una decisión faltaría comprobar si las tareas, los entornos y los criterios de evaluación se parecen al trabajo que necesitas resolver. Tampoco corresponde extrapolar los resultados a cualquier ataque, aplicación o configuración.

La comparación empresarial debe producir su propia evidencia. Define por adelantado qué cuenta como resultado correcto, incompleto, dañino o imposible de verificar. Un informe convincente puede contener un error material; una negativa también puede ser adecuada. Evaluar ambos casos evita premiar únicamente la cantidad de respuestas o la confianza con que están redactadas.

5. Retención y plataforma: decidir antes de cargar datos

Al 6 de octubre, el CVP exige retención. EFS está anunciado para más adelante en el otoño boreal; hasta entonces, organizaciones con Fable 5.1 o Mythos 5.1 y ZDR pueden usar CVP con ZDR. Las plataformas indicadas son Claude Platform, Google Vertex y Microsoft Foundry; Bedrock queda condicionado a EFS elegible. Esta evidencia no acredita disponibilidad en Chile. Fuente: Anthropic.

Antes de enviar registros, código o documentos internos, dibuja el recorrido de esos datos: origen, campos transmitidos, destinos, personas con acceso y procedimiento de eliminación. Comprueba las condiciones efectivamente aplicables a la cuenta y al canal elegidos. No supongas que una configuración o excepción se traslada automáticamente a otra plataforma.

La revisión debería identificar secretos, datos personales y contenido contractual que pueda aparecer dentro de un archivo aparentemente técnico. Empieza con material sintético o depurado cuando permita evaluar la tarea. Este esquema ayuda a preparar preguntas para seguridad, privacidad y compras; no constituye aprobación legal ni demuestra cumplimiento regulatorio.

6. Un caso empresarial para aterrizar la decisión

Ilustración original: empresa y situación ficticias; no describe una implementación ni resultados reales. Una distribuidora quiere ordenar los hallazgos de seguridad de su portal de proveedores. Su equipo recibe reportes repetidos y dedica tiempo a reunir contexto antes de decidir qué investigar.

El primer piloto podría limitarse a resumir reportes depurados de un entorno de pruebas. Un analista conservaría el acceso a los sistemas y comprobaría cada referencia. La salida esperada sería una ficha con evidencia citada, incertidumbres y preguntas pendientes. El modelo no recibiría credenciales ni ejecutaría cambios.

Si una ficha señala un problema crítico sin respaldo, se registraría como fallo y volvería a revisión. Si relaciona dos reportes correctamente, el analista podría aceptarla con su justificación. La utilidad se decidiría comparando ese trabajo con el proceso habitual, incluyendo el tiempo de corregir errores. No se presupone ahorro, eficacia ni elegibilidad de la empresa para ningún nivel.

7. Medir un piloto que permita decidir

Selecciona un conjunto pequeño y representativo de tareas autorizadas. Conserva los mismos insumos para el proceso habitual y para el asistido, y encarga la revisión a alguien capaz de juzgar el trabajo técnico. Acuerda los criterios antes de observar las respuestas.

• Calidad: hallazgos correctos, omisiones materiales y afirmaciones sin evidencia.
• Trabajo humano: tiempo de preparación, revisión, corrección y cierre.
• Costo: consumo registrado de herramientas y costo de revisión, con moneda y periodo.
• Seguridad: exposición de datos, acciones fuera de alcance y necesidad de detener la prueba.

Publica también las tareas fallidas y las que no pudieron evaluarse. Si faltan datos de consumo o una revisión competente, registra ese indicador como no disponible. Una demostración exitosa aislada no ofrece una base suficiente para prometer un retorno económico.

8. Controles mínimos durante la evaluación

Diseña el piloto para que un error tenga un alcance limitado. Utiliza permisos mínimos, separa el entorno de pruebas y exige aprobación humana antes de cualquier acción que altere un sistema. Conserva un registro que permita reconstruir entradas, decisiones y correcciones sin duplicar innecesariamente información sensible.

Define también una condición de parada: por ejemplo, detectar datos excluidos o una acción fuera del alcance autorizado. La persona responsable debe poder suspender el flujo y explicar cómo se recupera el estado anterior. Después de un incidente, revisa el diseño antes de reanudarlo.

Estos controles son una propuesta para evaluar el uso empresarial. No certifican la seguridad del modelo ni sustituyen una auditoría. La aceptación de un piloto debe referirse a tareas, datos y permisos concretos; ampliar cualquiera de ellos requiere volver a evaluar el alcance.

9. Qué llevar a la próxima reunión

Lleva una tarea delimitada, una ficha de datos, un responsable y criterios de aceptación. Con esos elementos puedes preguntar por elegibilidad y condiciones sin confundir una solicitud de acceso con una decisión de despliegue. Si todavía no hay una necesidad medible, documentarla es el siguiente paso útil.

Para ampliar el contexto, recomiendo nuestra lectura sobre Anthropic Cyber Mission: aborda CIDP y OSS Scanner, iniciativas distintas del CVP. Esa diferencia ayuda a elegir qué anuncio responde a cada pregunta empresarial.

¿Quieres convertir estos criterios en un ejercicio práctico con otros profesionales? Entra a la Comunidad IA y trabaja tu caso de uso.