# Auditoría de Preparación para IA

> Qué mide de verdad una auditoría de preparación para IA: cuatro dimensiones calificadas con evidencia, cada hallazgo etiquetado según qué tan respaldado está, y una lista de brechas priorizada por lo que pone en riesgo.

Fuente: https://www.koombea.com/es/ai-pods/ai-readiness-audit/

---

## 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](https://www.koombea.com/es/ai-pods/standards/) cubre el panorama completo.

## Cómo se fija una calificación {#scoring}

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 {#how-it-runs}

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 {#integrity}

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 {#what-you-get}

- 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](https://www.koombea.com/es/ai-pods/catalog/compliance-readiness/) y el
de [automatización de pruebas](https://www.koombea.com/es/ai-pods/catalog/test-automation/) están
definidos y con precio para exactamente este trabajo, y los
[estándares](https://www.koombea.com/es/ai-pods/standards/) contra los que califica la auditoría están
publicados para que las puedas cerrar sin nosotros.