# Auditoría de IA: entregables y criterios de aceptación

> Una auditoría de IA solo termina cuando sus hallazgos tienen evidencia, responsable, criterio de aceptación y una decisión de cierre verificable.

- Author: Viktor Berthelius (BRTHLS)
- Published: 2026-10-07
- Category: ai operating models
- Tags: auditoria-ia, criterios-aceptacion, ai-governance, evidencia
- Language: es
- Canonical: https://www.brthls.com/magazine/auditoria-ia-entregables-criterios-aceptacion-es
- Source: BRTHLS Magazine — https://www.brthls.com

---

## Problema

Muchas auditorías de IA terminan con una presentación convincente y una lista de recomendaciones. El comité entiende que existen riesgos, pero no sabe qué debe aceptar, quién tiene que corregirlo ni qué evidencia demuestra que el trabajo está cerrado.

El fallo no está en el diagnóstico. Está en tratar la auditoría como una opinión experta en vez de como un proceso de aceptación. Un hallazgo sin evidencia reproducible se discute. Una recomendación sin responsable se aplaza. Una corrección sin prueba de cierre vuelve a aparecer en la siguiente revisión.

## Tesis

Una auditoría de IA no está terminada cuando se entrega el informe. Está terminada cuando cada hallazgo puede convertirse en una decisión verificable: aceptar el riesgo, corregirlo, transferirlo o detener el sistema.

El entregable valioso no es el PDF. Es la cadena que conecta alcance, evidencia, hallazgo, criterio de aceptación, responsable y fecha de revisión. Si uno de esos elementos falta, la empresa ha comprado visibilidad, pero todavía no ha comprado control.

## Framework

El paquete de cierre debe permitir que una persona ajena al proyecto reconstruya qué se revisó y por qué se tomó cada decisión.

| Entregable | Qué debe contener | Criterio de aceptación |
| --- | --- | --- |
| Alcance e inventario | Sistemas, modelos, proveedores, datos, decisiones y exclusiones | Cada elemento tiene owner y uso previsto; las exclusiones están justificadas |
| Registro de hallazgos | Riesgo, impacto, condición observada y control afectado | El hallazgo apunta a evidencia concreta y evita lenguaje ambiguo |
| Paquete de evidencia | Configuraciones, trazas, pruebas, contratos, logs y entrevistas | La evidencia es accesible, fechada, versionada y atribuible |
| Matriz de aceptación | Resultado esperado, prueba, umbral y condición de rechazo | Otra persona puede repetir la prueba y llegar al mismo veredicto |
| Plan de tratamiento | Acción, responsable, dependencia y mecanismo de escalado | Cada acción tiene una decisión posible, no solo una intención |
| Memorando de cierre | Riesgos aceptados, pendientes, excepciones y siguiente revisión | El responsable con mandato firma la decisión y asume el riesgo residual |

La matriz de aceptación es la pieza que suele faltar. Debe indicar qué se prueba, con qué muestra o escenario, qué resultado es aceptable, quién valida y qué ocurre si el sistema no pasa. No todos los riesgos se pueden reducir a una métrica; cuando la evaluación sea cualitativa, el criterio debe seguir siendo explícito y trazable.

Un buen hallazgo tampoco confunde ausencia de documento con ausencia de control. Primero comprueba cómo opera el sistema. Después verifica si esa operación deja evidencia suficiente. La documentación debe explicar el control real, no sustituirlo.

## Por qué importa ahora

El AI Risk Management Framework de NIST organiza la gestión en Govern, Map, Measure y Manage. En su función de medición pide documentar métodos, métricas, conjuntos de prueba, resultados, limitaciones y eficacia de controles. Esa lógica convierte una evaluación en algo repetible, no en una impresión del auditor.

El Reglamento de IA de la Unión Europea refuerza el mismo principio para los sistemas de alto riesgo. Sus artículos sobre documentación técnica y registro de eventos exigen información capaz de demostrar conformidad y trazabilidad. Esto no convierte cada auditoría interna en una evaluación legal de conformidad, pero sí eleva el estándar práctico: una conclusión importante debe poder apoyarse en evidencia mantenida y comprensible.

La auditoría, por tanto, tiene que servir a dos lectores. El comité necesita saber qué decidir. El equipo que opera el sistema necesita saber qué cambiar y cómo demostrar que lo cambió.

## Anti-ejemplo

El anti-ejemplo es un informe con semáforos. “Gobernanza: ámbar”, “datos: rojo”, “seguridad: ámbar”. El documento parece claro, pero no especifica qué sistema produjo el riesgo, qué evidencia se revisó, quién puede aceptar la excepción ni qué prueba convertiría el rojo en verde.

El equipo responde creando políticas, capturas y carpetas. En la siguiente auditoría hay más documentos, pero el evaluador no puede reproducir una decisión ni comprobar si el control funciona en producción. La organización ha optimizado el aspecto de la evidencia, no su capacidad de demostrar operación.

## Protocolo (3 pasos)

1. **Define la aceptación antes de recopilar evidencia.** Escribe para cada área qué resultado permitiría cerrar, escalar o rechazar el hallazgo. Así evitas adaptar el criterio a lo que encuentres.
2. **Prueba la cadena de trazabilidad.** Selecciona decisiones reales y reconstruye datos de entrada, versión, reglas, intervención humana, salida e incidente o resultado posterior.
3. **Cierra con decisiones, no con recomendaciones.** Cada hallazgo debe terminar en una acción aprobada, una aceptación explícita del riesgo o una orden de pausa, con responsable y revisión.

| Pregunta de cierre | Evidencia mínima | Resultado posible |
| --- | --- | --- |
| ¿Qué se evaluó? | Inventario y alcance versionado | Incluido, excluido o pendiente |
| ¿Qué ocurrió? | Traza, prueba o registro verificable | Conforme, no conforme o indeterminado |
| ¿Quién decide? | Owner con mandato documentado | Corregir, aceptar, transferir o parar |
| ¿Cómo se reabre? | Evento, umbral o cambio relevante | Nueva prueba o revisión extraordinaria |

## Relacionado

- [Auditoría IA empresa: las preguntas que un consultor debería hacer antes de proponer](/magazine/auditoria-ia-empresa-27-preguntas-consultor-deberia-hacerte-antes-proponer-es)
- [Eval-driven development: el prototipo debe descubrir el benchmark](/magazine/eval-driven-development-prototipo-antes-benchmark-es)
- [AI Decision Ledger: el registro que separa aprendizaje de opinión](/magazine/ai-decision-ledger-registro-decisiones-ia-es)

## Fuentes consultadas

- [NIST Artificial Intelligence Risk Management Framework 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) — publicación oficial; revisadas las funciones de gobierno, mapeo, medición y gestión, incluidos los requisitos de documentación de pruebas y métricas.
- [Reglamento (UE) 2024/1689 de Inteligencia Artificial](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) — texto oficial; revisados los artículos sobre documentación técnica, registros y trazabilidad de sistemas de alto riesgo.

## Próximo paso

Toma el hallazgo más importante de tu última auditoría e intenta escribir su prueba de aceptación en una frase. Si no puedes definir qué evidencia lo cerraría y quién emitiría el veredicto, el hallazgo todavía no es ejecutable. Una [auditoría de IA orientada a decisiones](/auditoria-ia-empresa) debe resolver precisamente ese vacío.

---

_Cite as: Berthelius, V. (2026). "Auditoría de IA: entregables y criterios de aceptación". BRTHLS Magazine. https://www.brthls.com/magazine/auditoria-ia-entregables-criterios-aceptacion-es_