Criterios de aceptación para implantar Claude Code

Una empresa debería aceptar una implantación de Claude Code únicamente cuando el proveedor demuestre el perímetro operativo acordado. El expediente debe indicar qué repositorios y recursos puede alcanzar el flujo, qué acciones requieren aprobación, qué modelo utiliza cada trabajador delegado, qué pruebas se ejecutaron y quién responde por las excepciones. Que el agente complete una tarea no demuestra que sus accesos, registros y mecanismos de recuperación sean adecuados.

Anthropic documenta mecanismos útiles para construir esas pruebas: una regla del modo automático dirigida a determinados intentos de escape de contención, un aviso previo a la primera lectura fuera de los directorios de trabajo, un ajuste capaz de bloquear esas lecturas y una variable para imponer el modelo configurado a los subagentes. Esos son hechos oficiales. El pliego de aceptación que sigue es una metodología operativa de CreatikLab, no una garantía emitida por Anthropic.

El changelog de Claude Code describe una regla de modo automático aplicable a comportamientos relacionados con credenciales de metadatos cloud, evasión de controles de salida y alcance entre tenants. Esas acciones dejan de recibir aprobación automática salvo que el entorno las identifique como esperadas. La misma entrada recoge una decisión única antes de la primera lectura fuera de los directorios de trabajo y menciona `permissions.blockReadsOutsideWorkingDirectories` para impedirla.

También aparece `CLAUDE_CODE_SUBAGENT_MODEL_FORCE`, cuya función documentada es aplicar a los subagentes el modelo indicado en `CLAUDE_CODE_SUBAGENT_MODEL`, o el modelo principal, aunque exista otra selección al crearlos o en su definición. Si se usa `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY`, el gateway puede aportar descripciones para entradas descubiertas. Nada de ello prueba el coste, el rendimiento, la calidad del código o la seguridad global de una implantación concreta.

El pliego debe sustituir expresiones vagas como “automatizar el desarrollo” por una tabla de recursos. Para cada repositorio, ruta, variable de entorno, registro de paquetes, identidad de CI, cuenta cloud, base de datos, socket, sesión autenticada o servidor de herramientas se define una acción permitida, una acción prohibida y una acción sujeta a aprobación. Todo recurso no inventariado queda fuera del alcance hasta que exista una revisión expresa.

La autoridad también se separa por actor. Sesión principal, subagentes, gateway, herramientas conectadas, identidad de control de versiones, revisor y responsable de publicación no deben confundirse. El implantador tiene que indicar dónde se aplica cada política y cómo se observa su cumplimiento. No puede darse por supuesto que un ajuste de Claude Code se propague a un servicio externo o a la plataforma que despliega el resultado.

• Directorio de trabajo — Intento inocuo de lectura externa, con transcripción y telemetría del sistema de archivos. Se acepta si el aviso o bloqueo coincide con la política escrita.
• Contención — Simulaciones seguras dentro de un laboratorio aislado. Se acepta si no existe aprobación silenciosa de un comportamiento prohibido.
• Subagentes — Ejecuciones representativas con registro del modelo efectivo. Se rechaza cualquier diferencia que no tenga explicación y autorización.
• Gateway — Conciliación entre entradas visibles, identificadores estables y administración. La descripción no se utiliza como prueba de identidad o condiciones comerciales.
• Cambio de código — Instrucción, comandos, diff, pruebas y decisión del revisor asociados al mismo expediente.
• Publicación — Evidencia de que generar un cambio no concede automáticamente autoridad para desplegarlo, más una referencia de rollback.

Cada prueba necesita resultado esperado, evidencia primaria, observación independiente y responsable de decisión. La palabra “configurado” no demuestra comportamiento. Si un dato no se puede recuperar, el caso permanece pendiente. El comprador no debería aceptar una diapositiva resumen como sustituto de los registros que permiten repetir la prueba.

1. Versión instalada de Claude Code y copia de la configuración evaluada.
2. Inventario de repositorios, rutas, identidades, herramientas, secretos por clase y destinos externos.
3. Repositorio desechable y credenciales sintéticas sin autoridad sobre producción.
4. Casos permitidos, denegados y sujetos a aprobación escritos antes de ejecutar la prueba.
5. Registro de la lectura externa y repetición con el bloqueo correspondiente activado.
6. Simulaciones de contención realizadas sin credenciales reales ni recursos de terceros.
7. Listado de subagentes de prueba, tareas asignadas, modelos efectivos, herramientas y resultados.
8. Inventario del gateway cuando se utilice descubrimiento de modelos, conciliado con su administración.
9. Cambio controlado con instrucción, comandos, diff, pruebas, revisión y disposición final.
10. Demostración de reversión sobre un artefacto recuperable y sin impacto productivo.
11. Registro de excepciones con alcance, motivo, propietario y condición de reapertura.
12. Firma o decisión registrada de ingeniería, seguridad y propietario del proceso.

La entrega debe incluir materiales reutilizables, no solo conclusiones. El equipo comprador tendrá que repetir parte de estas comprobaciones cuando cambien configuración, herramientas o identidades. Las evidencias sensibles se protegen y minimizan: demostrar que una política funcionó no exige copiar secretos en un informe ni conservar datos innecesarios.

El estado verde exige recursos inventariados, denegaciones correctas, pausas de aprobación observables, modelos efectivos conciliados, cambios con expediente completo y rollback demostrado. El estado ámbar se utiliza cuando el caso aporta utilidad pero una dependencia no está bien aislada. La aceptación queda condicionada a reducir el alcance: solo lectura, datos sintéticos, repositorio desechable o ausencia de autoridad de despliegue.

El estado rojo corresponde a credenciales excesivas, lecturas externas sin justificar, registros incapaces de identificar modelos, herramientas que evitan el perímetro declarado, publicación sin responsable o reversión no demostrada. Rechazar la entrega no implica afirmar que Claude Code sea inadecuado; significa que el diseño presentado todavía no satisface los criterios contractuales del entorno comprador.

Después de aceptar el piloto, cada ejecución gobernada debería registrar identificador del flujo, repositorio, referencia de configuración, modelo principal efectivo, modelos de subagentes, herramientas invocadas, intentos de lectura externa, aprobaciones, denegaciones, archivos modificados, pruebas y revisor. Si interviene un gateway, se conserva su entrada o identificador estable y no únicamente el texto mostrado. Toda excepción se vincula a la persona que tomó la decisión.

Las medidas de control pueden incluir expedientes completos, intentos prohibidos correctamente denegados, acciones condicionadas con aprobación válida, cambios que satisfacen pruebas, devoluciones del revisor, discrepancias de modelo pendientes y ejercicios de rollback. Cada porcentaje necesita numerador, denominador y periodo operativo definidos por el comprador. Para estudiar utilidad, se compara el piloto con el proceso existente mediante tareas equivalentes, sin prometer mejoras que el changelog no acredita.

• No asumir que un único aviso cubre cualquier ruta, comando, herramienta o acceso indirecto.
• No equiparar el bloqueo de una lectura de archivo con bloqueo de red, herramientas o credenciales de despliegue.
• No convertir una excepción de contención esperada en autoridad cloud general.
• No deducir el modelo efectivo de un subagente únicamente a partir de su definición.
• No tratar una descripción del gateway como verificación de identidad, seguridad, precio o elegibilidad.
• No extrapolar al entorno remoto o a CI una prueba hecha solo en un puesto local.
• No sustituir aislamiento de secretos, protección de ramas, pruebas, revisión y rollback por el modo automático.
• No mantener la aceptación original cuando se amplían recursos, identidades, modelos o herramientas.
• No prometer ahorro, velocidad, disponibilidad, calidad o seguridad que Anthropic no haya demostrado.

La deriva del alcance es especialmente peligrosa: una prueba limitada recibe nuevas carpetas, integraciones y credenciales sin volver al comité de recepción. El contrato debe definir disparadores de reapertura. Una nueva herramienta, otro esquema de enrutamiento, mayor autoridad de despliegue o acceso adicional obliga a repetir las pruebas relacionadas.

Para un equipo de software, el servicio de automatización con IA de CreatikLab puede entregar el pliego de control, mapa de activos y credenciales, banco de pruebas aislado, expediente de lecturas externas, verificación de modelos de subagentes, inventario del gateway, esquema de evidencias, circuito de aprobación, registro de excepciones, hoja de medición y ensayo de rollback. Son piezas revisables para ingeniería, seguridad y compras.

Si todavía no está definido el perímetro, el traspaso explícito es a Lia. Conviene aportar tipo de repositorio, runtime, herramientas conectadas, clases de identidad, ruta de despliegue y puntos donde debe intervenir una persona. Lia puede encaminar ese contexto hacia un diagnóstico delimitado. CreatikLab no garantiza seguridad, ahorro, velocidad ni calidad; entrega un diseño comprobable y una decisión de aceptación basada en evidencias.

¿Qué se acepta realmente en un proyecto con Claude Code?

Se acepta un perímetro operativo concreto: recursos autorizados, acciones prohibidas, aprobaciones, modelos efectivos, evidencias, responsables y mecanismo de reversión. Una demostración funcional no basta.

¿Qué controles confirma Anthropic?

El changelog documenta una regla relacionada con el escape de contención en modo automático, un aviso antes de la primera lectura externa, un ajuste para bloquear esas lecturas y una variable para imponer la selección de modelo a los subagentes.

¿Superar las pruebas garantiza la seguridad?

No. El resultado solo demuestra cómo respondió una configuración identificada ante casos definidos. No certifica otros repositorios, versiones, credenciales, herramientas o cambios posteriores.

¿Cómo se acepta el control de lectura externa?

Se realiza una lectura inocua fuera del directorio autorizado dentro de un entorno desechable. Se conservan la solicitud, el punto de decisión, la respuesta y la telemetría independiente, y se repite con el bloqueo activo.

¿Por qué no basta con revisar la configuración de un subagente?

Porque la aceptación debe comprobar el modelo efectivo durante la ejecución. También conviene registrar su tarea, herramientas, resultado y relación con la sesión principal.

¿Qué entregables debe aportar un especialista?

Como mínimo, mapa de accesos y credenciales, política versionada, banco de pruebas aislado, informe de aceptación, inventario de modelos y gateways, registro de excepciones, circuito de aprobación y ensayo de rollback.