Un pipeline verde no es evidencia.
Una auditoría que le pregunta a un equipo cómo trabaja devuelve lo que el equipo cree. Esta lee el pipeline, las pruebas y los ítems de trabajo, y reporta lo que hay de verdad. Incluso cuando la respuesta es incómoda.
- Cuatro dimensiones, calificadas de cero a tres
- Cada afirmación etiquetada como verificada, inferida o bloqueada
- Conteos exactos, nunca porcentajes extrapolados
Por qué la mayoría de las evaluaciones no dan
Casi todo el material de preparación para IA mide una de dos cosas. O la estrategia de negocio, que te dice si la organización está lista para invertir, o la seguridad del código, que te dice si el código generado introdujo una vulnerabilidad.
Las dos son útiles y ninguna responde la pregunta de entrega: si un agente empezara a trabajar en este repositorio el lunes, ¿algo lo detendría cuando se equivoque?
Esa pregunta tiene una respuesta medible. Vive en la configuración del pipeline, en las capas de observabilidad, en la trazabilidad entre requerimientos y pruebas, y en qué tan completo se describe el trabajo antes de que alguien construya.
Califica tu proyecto en unos diez minutos
La evaluación cubre las mismas cuatro dimensiones que describe esta página y devuelve una calificación de madurez por dimensión. Una auditoría completa va más a fondo y lee tus fuentes reales.
Las cuatro dimensiones
Cada dimensión corresponde a un estándar publicado o en progreso, así que una calificación es una posición frente a una vara escrita y no una opinión.
| Dimensión | Qué mide |
|---|---|
| Entrega | Si el pipeline impone calidad antes de que el código llegue a producción: lint, chequeo de tipos, pruebas, escaneo estático de seguridad, auditoría de dependencias, umbral de cobertura, build |
| Observabilidad | Si la aplicación en ejecución se puede diagnosticar: seguimiento de errores, monitoreo de rendimiento, logs estructurados, health checks, ruteo de alertas y telemetría de agentes |
| Validación | Si existe cobertura de pruebas en las distintas capas para cada área del producto, con trazabilidad de cada criterio de aceptación a una prueba que lo demuestre |
| Especificación | Si los ítems de trabajo cargan suficiente información para que un agente los implemente bien, medido en campos obligatorios y niveles de completitud |
Un proyecto está hecho de ocho sistemas más, y esta auditoría no los califica. Los hallazgos ahí quedan como contexto. La página de los doce sistemas cubre el panorama completo.
Cómo se fija una calificación
Cada dimensión se califica de cero a tres contra su estándar. La calificación no es una nota para el equipo. Es una afirmación sobre por dónde pasa un cambio hoy.
Las brechas se priorizan por consecuencia, no por qué tan fáciles son de arreglar.
| Severidad | Qué significa |
|---|---|
| Crítica | Código roto o una vulnerabilidad pueden llegar a producción sin ningún chequeo automático |
| Alta | Un área central sin cobertura, o herramientas mal configuradas al punto de ser engañosas |
| Media | Una práctica ausente que sube el riesgo pero tiene alternativa |
| Baja | Una mejora que vale la pena y no está bloqueando nada |
Donde el estándar de una dimensión todavía se está terminando, las brechas se marcan y no cuentan como falla. La vara no está terminada, y calificar contra ella como si lo estuviera sería injusto con el proyecto.
Cómo corre
Primero se verifica el acceso. Lo que no se pueda alcanzar queda registrado como inaccesible, y la falta de acceso se convierte en un hallazgo por sí sola en lugar de un hueco que se llena con una suposición.
Después se recoge evidencia por dimensión leyendo las fuentes directamente. La configuración del pipeline, no una descripción de ella. La suite de pruebas, no la insignia de cobertura. Los ítems de trabajo, no una muestra que alguien escogió.
Las reglas que la mantienen honesta
Estas gobiernan al auditor, no al proyecto. Son la razón por la que el resultado vale la pena.
- Evidencia primero. Una brecha nunca se llena con una inferencia. Si no se puede alcanzar una fuente, el hallazgo se etiqueta como bloqueado y la auditoría sigue.
- Cada afirmación lleva una etiqueta de fuerza. Verificada significa confirmada leyendo la fuente. Inferida significa derivada de forma indirecta, y lo dice. Bloqueada significa que la fuente no se pudo alcanzar.
- Conteos exactos sobre porcentajes. Cuando se pueden contar todos los ítems, se reporta el número exacto. Cuando hay que muestrear, se dice el tamaño de la muestra y nada se extrapola sin etiquetarlo.
- Preguntar antes de muestrear. Leer veinte de cien ítems se acuerda antes, y las conclusiones de muestra nunca se arrastran como hechos cuando aparece el conjunto completo.
- Clasificar antes de escribir. Cada dato se etiqueta antes de redactar una sección, y las clasificaciones nunca se mezclan dentro de una misma afirmación.
- Evidencia e interpretación van aparte. Los datos crudos viven en archivos de evidencia. El reporte los cita en lugar de reproducirlos.
- Re-verificar con acceso nuevo. Cuando una fuente bloqueada se abre, las secciones afectadas se rehacen desde cero en lugar de parchearse.
- Enmarcar para quien lee. La misma evidencia se enfatiza distinto para un líder de calidad que para un líder de entrega. La evidencia no cambia.
Qué recibes
- Un tablero de madurez de cuatro filas: dimensión, calificación, en qué se basa, y el hallazgo que más pesó
- Una nota de metodología con qué fuentes se leyeron y cuáles no se pudieron alcanzar
- Una comparación por dimensión del estándar contra el estado actual
- Una sola lista consolidada de brechas, priorizada por severidad
- Recomendaciones de remediación, cuando las quieras
Cómo se ve esto cuando sale mal
La razón por la que esta auditoría lee fuentes en lugar de hacer preguntas es que los hallazgos interesantes son invisibles desde adentro.
En un proyecto, el pipeline del backend invocaba un comando de pruebas de un framework que el equipo no usaba. No encontró nada, no corrió nada, y reportó verde en cada merge, mientras 93 archivos de prueba vivían en el repositorio sin ejecutarse nunca. Todos los involucrados creían que las pruebas corrían. La insignia lo decía.
El frontend del mismo proyecto no tenía compuertas de calidad en ninguna etapa, ni una sola de las cinco capas de observabilidad que buscamos, con un comentario donde debía estar el reporte de errores.
Ninguno de los dos hallazgos requirió criterio. Los dos requirieron mirar.
Y después qué
Una lista de brechas no es un plan. Si quieres cerrarlas, el AI Pod de preparación para cumplimiento y el de automatización de pruebas están definidos y con precio para exactamente este trabajo, y los estándares contra los que califica la auditoría están publicados para que las puedas cerrar sin nosotros.
Tráenos el backlog.
En 30 minutos te mostramos qué entregaría primero un Pod y cómo lo cotizaríamos.