Lista de verificación de auditoría de IA: cómo auditar un sistema de IA paso a paso

El setenta y ocho por ciento de los ejecutivos de empresas no tiene una confianza sólida en que podría superar una auditoría independiente de gobernanza de IA en un plazo de 90 días. Esa cifra procede de la Encuesta de Impacto de la IA 2026 de Grant Thornton, realizada a 950 líderes empresariales, y es una forma diplomática de decir que la mayoría de las empresas han lanzado IA que no pueden explicar por completo.

Una auditoría de IA es una revisión estructurada de los datos, el modelo, la seguridad, la supervisión y la documentación de un sistema de IA frente a un estándar definido. Para auditar un sistema de IA, siga ocho pasos en orden: definir el alcance del sistema, rastrear los datos, validar el rendimiento, probar sesgos, examinar la seguridad, comprobar la supervisión humana, verificar el monitoreo y reunir el paquete de evidencias.

Cada uno de los ocho pasos siguientes incluye las comprobaciones específicas que debe realizar, las acciones que puede asignar a un equipo y la señal de alerta que indica que el paso ha fallado. Si desea más contexto sobre los tipos de auditoría y quién necesita una, nuestra guía sobre qué es una auditoría de IA cubre ese terreno, y la página de nuestro servicio de auditoría de desarrollo de software explica cómo la lleva a cabo un equipo externo.

Qué cubre la lista de verificación de auditoría de IA

Los ocho pasos siguientes avanzan del papeleo a la producción, y esto es deliberado. Cada paso posterior depende del trabajo de definición del alcance realizado en el primero, por lo que ejecutarlos fuera de orden implica auditar un sistema que aún no ha definido. La columna de esfuerzo asume un único sistema de producción de tamaño mediano con uno o dos modelos y un equipo capaz de responder preguntas en un día.

Reserve entre tres y cuatro semanas para una primera pasada, y menos para los ciclos posteriores una vez que exista el flujo de evidencias. El riesgo de omitir todo el ejercicio es medible: el estudio de IBM de 2026 con 2000 ejecutivos de tecnología descubrió que las organizaciones con controles integrados experimentan un 25% menos de incidentes que aquellas que dependen de una gobernanza manual.

Paso 1: Definir el alcance del sistema y redactar una ficha del modelo

No se puede auditar “nuestra IA”. Se audita un sistema específico, con un número de versión, un propietario designado y un propósito por escrito. Comience con una ficha del modelo, que es una hoja informativa de una página que cubre qué hace el sistema, para qué nunca debe usarse, quién es su propietario y qué tan riesgosas son sus decisiones. La lista de verificación de auditoría de IA del Comité Europeo de Protección de Datos comienza con exactamente este artefacto y luego añade un mapa del sistema que muestra dónde se sitúa el modelo dentro del flujo de decisiones y qué personas tienen contacto con su salida.

Espere que este paso revele sistemas de los que nadie le había hablado. Un estudio del IBM Institute for Business Value con 2000 ejecutivos de tecnología encontró que el 70% afirma que los equipos de toda la empresa están implementando tecnología más rápido de lo que TI puede rastrear.

Inventario del sistema:

• Enumere todos los sistemas de IA en uso, incluidas las herramientas adquiridas con la tarjeta de crédito de un equipo
• Registre el número de versión y la fecha del último cambio
• Designe un único propietario responsable por sistema, una persona y no un departamento

La ficha del modelo:

• Escriba el propósito previsto del sistema en una sola frase clara
• Documente para qué no debe usarse y por qué
• Anote qué modelo o proveedor subyace, y qué versión

Mapa del sistema:

• Dibuje dónde entra la salida de la IA en una decisión real y quién actúa a partir de ella
• Marque cada punto en el que una persona puede revisar, editar o anular el resultado

Señal de alerta: el propósito del sistema cambia según a quién se le pregunte.

Paso 2: Rastrear el origen de los datos y si puede utilizarlos

Cada conjunto de datos que entrenó, ajustó o alimenta al modelo necesita un origen rastreable, una base legal documentada y un control de calidad. Pregunte de dónde proceden los datos, quién los recopiló, bajo qué consentimiento o licencia, y cuándo se actualizaron por última vez. Luego verifique usted mismo una muestra en lugar de aceptar el resumen, porque aquí es donde la mayoría de las auditorías encuentran su primer problema real.

El mercado ya lo sabe. En el informe State of AI in the Enterprise de Deloitte, la privacidad y seguridad de los datos es la principal preocupación de riesgo en IA, con un 73%, por delante de los aspectos legales, de propiedad intelectual y de cumplimiento normativo, con un 50%.

Origen de los datos:

• Rastree cada conjunto de datos hasta la organización que lo recopiló originalmente
• Verifique la licencia o el consentimiento que permite su uso específico
• Señale cualquier dato extraído por scraping o comprado cuyos derechos no estén claros

Datos personales:

• Identifique cualquier información personal presente en los conjuntos de entrenamiento, las instrucciones o los índices de búsqueda
• Confirme que dispone de una base legal para conservar cada categoría de esos datos
• Compruebe si las solicitudes de eliminación realmente llegan al sistema de IA

Calidad de los datos:

• Revise cómo se limpiaron los datos y quién decidió qué eliminar
• Compruebe la fecha de actualización y si datos obsoletos siguen usándose silenciosamente

Señal de alerta: la respuesta a “de dónde vienen estos datos” es una ubicación de almacenamiento en lugar de una fuente.

Paso 3: Probar el modelo con sus propios datos, no con la demo del proveedor

Los benchmarks del proveedor miden las condiciones del proveedor. Su auditoría mide las suyas. Construya un conjunto de prueba con ejemplos reales que el modelo nunca haya visto, ejecute el modelo contra él y registre con qué frecuencia acierta y cómo falla cuando se equivoca.

Para sistemas de chat y contenido, una única puntuación de precisión casi no le dice nada. En su lugar, califique las salidas con una rúbrica que cubra si los hechos son correctos, si siguió las instrucciones, si rechazó lo que debía rechazar y si se mantuvo el formato. Los equipos que desarrollan sistemas personalizados de IA y aprendizaje automático ya deberían contar con este banco de pruebas, y su ausencia es en sí misma un hallazgo.

Conjunto de prueba:

• Reúna ejemplos reales que el modelo nunca haya visto, extraídos del tráfico real
• Incluya los casos difíciles, no solo los que quedan bien en una demostración
• Mantenga el conjunto separado para que nunca se filtre de vuelta al entrenamiento

Medición del rendimiento:

• Registre con qué frecuencia el sistema acierta y con qué frecuencia se equivoca con confianza
• Ejecute cada prueba más de una vez, ya que las respuestas varían entre ejecuciones
• Desglose los resultados por segmento de cliente, no solo por el promedio general

Revisión de fallos:

• Lea una muestra de respuestas incorrectas y agrúpelas por causa
• Compruebe si los peores fallos se concentran en su caso de uso de mayor valor

Señal de alerta: la única evidencia de rendimiento es una diapositiva del proceso de adquisición.

Paso 4: Probar sesgos en los grupos afectados por su sistema

Las pruebas de sesgo son un conjunto de mediciones, no un debate filosófico. Decida qué grupos se ven afectados por las decisiones de su sistema, decida cómo es un resultado perjudicial para cada uno, y luego compare con qué frecuencia ocurre ese resultado entre esos grupos utilizando el conjunto de prueba del paso anterior. Si la diferencia es significativa, registre el tamaño de la diferencia en lugar de una impresión general.

La metodología de auditoría del Comité Europeo de Protección de Datos añade aquí una disciplina útil. Localice primero los momentos de sesgo, es decir, los puntos específicos en los que puede introducirse una desviación, como quién terminó incluido en los datos, cómo se redactaron las etiquetas, qué características usa el modelo y dónde se fijó el umbral de corte. Luego, pruebe cada uno de esos puntos por separado.

Definición de grupos:

• Enumere los grupos que realmente se ven afectados por las decisiones de su sistema
• Defina, en términos claros, cómo es un mal resultado para cada grupo

Comparación de resultados:

• Mida con qué frecuencia cada grupo recibe el resultado desfavorable
• Compare la precisión por grupo, no solo la cifra combinada
• Registre el tamaño de cualquier diferencia y quién aprobó aceptarla

Momentos de sesgo:

• Compruebe quién está sobrerrepresentado o infrarrepresentado en los datos de entrenamiento
• Revise cómo se crearon las etiquetas y quién las creó
• Examine dónde se fijaron los umbrales y si se ajustaron para favorecer a un grupo

Señal de alerta: el equipo argumenta que el sistema no puede tener sesgos porque nunca ve la raza, el género o la edad. Campos ordinarios sustituyen a esos datos, de modo que un código postal, el nombre de una escuela o un historial laboral pueden transmitir la misma señal y producir el mismo resultado sesgado.

Paso 5: Examinar la seguridad, comenzando por la inyección de instrucciones

Los sistemas de IA heredan todas las vulnerabilidades clásicas de las aplicaciones y añaden algunas propias. La inyección de instrucciones ocupa el primer lugar del OWASP Top 10 para aplicaciones LLM como LLM01, y funciona de dos maneras. La inyección directa es un usuario que escribe instrucciones para secuestrar el sistema. La inyección indirecta consiste en instrucciones ocultas que llegan dentro de un documento, una página web o un correo electrónico que el modelo lee y obedece.

Lo que convierte una mala respuesta en un incidente real es a qué puede acceder el modelo. Nuestro equipo de control de calidad en QAwerk mantiene una lista de verificación de pruebas de inyección de instrucciones previas al lanzamiento con los casos de prueba específicos que deben ejecutarse antes del lanzamiento, y cualquiera que lance un producto basado en LLM debería poder mostrarle resultados de esas pruebas y no solo intenciones.

Pruebas de inyección:

• Intente anular directamente el prompt del sistema, como lo haría un usuario hostil
• Introduzca instrucciones ocultas dentro de un documento o página web que el sistema lea
• Compruebe si el sistema revela sus propias instrucciones cuando se le pregunta con astucia

Acceso y permisos:

• Enumere cada herramienta, base de datos y API que el modelo puede invocar
• Confirme que los permisos del modelo no son más amplios que los del usuario que interactúa con él
• Exija aprobación humana antes de cualquier acción que gaste dinero o envíe mensajes

Filtración de datos:

• Compruebe si el sistema puede revelar los datos de otro cliente
• Verifique que el filtrado se aplique a las salidas, no solo a las entradas

Señal de alerta: el modelo tiene credenciales de API con permisos más amplios que los del usuario que interactúa con él.

Paso 6: Comprobar quién supervisa y quién puede desactivarlo

La supervisión falla de una manera predecible. Una persona está nominalmente en el circuito, pero no tiene ni el tiempo ni la autoridad para estar en desacuerdo con el modelo, por lo que la revisión se convierte en una formalidad. Su auditoría debe comprobar si el revisor puede evaluar realmente la salida, con qué frecuencia la anula de hecho y qué ocurre cuando lo hace.

El artículo 26 de la Ley de IA de la UE exige que quienes implementan sistemas de alto riesgo asignen la supervisión a personas con “la competencia, formación y autoridad necesarias”. La competencia y la autoridad son las partes que suelen omitirse. Grant Thornton encontró que solo el 20% de las organizaciones cuenta con un plan de respuesta a incidentes de IA probado, así que pregunte cuándo se ensayó por última vez el procedimiento de parada.

Capacidad del revisor:

• Confirme que el revisor dispone de tiempo y contexto suficientes para evaluar cada salida
• Compruebe que tiene la autoridad para anular el sistema sin necesidad de escalar
• Mida la tasa de anulación durante el último trimestre

Autoridad de parada:

• Identifique quién puede desactivar el sistema, por nombre y por función
• Verifique que existe una vía de reversión y que no requiere al desarrollador original
• Confirme que el procedimiento de parada se ha ensayado, y no solo se ha documentado

Escalado:

• Revise cómo se informa de una salida incorrecta y quién recibe ese informe
• Compruebe que los incidentes se registran en algún lugar que la dirección realmente consulta

Nuestra guía sobre gobernanza de agentes de IA empresariales profundiza en esta arquitectura de supervisión, incluida la razón por la que un plan de reversión debe existir en la puerta de lanzamiento y no en el momento del incidente.

Señal de alerta: la tasa de anulación es cero, lo cual normalmente significa que la revisión es un mero sello de aprobación.

Paso 7: Verificar el monitoreo, las alertas de desviación y la retención de registros

Un modelo que superó todas las pruebas en marzo puede degradarse silenciosamente para septiembre, a medida que el mundo real cambia debajo de él. Compruebe que alguien vigila la producción, que las alertas tienen umbrales en lugar de paneles que nadie abre, y que una persona designada las recibe. Luego revise los registros, porque el registro determina si su próxima auditoría es siquiera posible.

El artículo 12 de la Ley de IA de la UE exige que los sistemas de alto riesgo registren automáticamente eventos durante toda la vida del sistema, y el artículo 26 exige que quienes lo implementan conserven esos registros durante al menos seis meses. Investigadores de la Universidad de Brown plantean el punto con más crudeza en su trabajo sobre rastros de auditoría de LLM: sin registros a prueba de manipulación, las organizaciones no pueden reconstruir qué versión del modelo estaba en ejecución, qué datos influyeron en ella ni quién aprobó el cambio.

Monitoreo en producción:

• Confirme que alguien rastrea si las solicitudes entrantes todavía se parecen a aquello para lo que se construyó el modelo
• Vigile la calidad de las respuestas, las tasas de error y la velocidad, no solo el tiempo de actividad
• Rastree una métrica de resultado de negocio junto con las técnicas

Alertas:

• Verifique que las alertas tengan umbrales definidos y un destinatario designado
• Revise las últimas tres alertas y qué acción siguió a cada una

Retención de registros:

• Registre qué se almacena: entradas, salidas, versión del modelo, versión del prompt y quién cambió qué
• Confirme que la retención cumple con su requisito aplicable más exigente, no con el valor predeterminado de la plataforma
• Verifique que los registros no puedan editarse silenciosamente después de los hechos

No se puede recuperar retroactivamente un registro que nunca se capturó, así que trate las lagunas aquí como urgentes y no como administrativas. Nuestro artículo sobre auditoría de la colaboración entre IA y humanos profundiza en cómo capturar el lado humano de ese registro.

Señal de alerta: la retención de registros está fijada en el valor predeterminado de la plataforma y nadie ha comprobado cuál es ese valor.

Paso 8: Reunir el paquete de evidencias

El paso final convierte siete pasos de trabajo en algo que un tercero externo puede verificar. Reúna cada artefacto que produjo en un paquete indexado, y luego relacione cada uno con los marcos ante los que rinde cuentas, ya sea la Ley de IA de la UE, la ISO/IEC 42001, SOC 2 o el NIST AI Risk Management Framework y sus funciones Govern, Map, Measure y Manage. Un auditor debería poder abrir el paquete y rastrear cualquier afirmación hasta el registro que la respalda.

Limite este paso a la documentación y la trazabilidad. Decidir qué marcos se aplican a su negocio es un ejercicio distinto, y conviene terminarlo antes de que comience la auditoría.

Recopilación de evidencias:

• Reúna en un solo lugar la ficha del modelo, el mapa del sistema, los registros de datos y todos los resultados de las pruebas
• Incluya muestras de registros que demuestren que el sistema almacena lo que usted afirma que almacena
• Feche y versione cada artefacto para que un revisor pueda saber qué estaba vigente

Mapeo a marcos normativos:

• Relacione cada artefacto con el requisito específico que satisface
• Marque como brechas abiertas los requisitos sin evidencia de respaldo

Informe de hallazgos:

• Redacte los hallazgos con una calificación de gravedad y un propietario designado para cada uno
• Use el mismo formato de defectos que ya utiliza su equipo de ingeniería
• Fije una fecha de reverificación para cada hallazgo que haya aceptado

Nuestra lista de verificación de auditoría del SDLC aplica la misma disciplina al proceso de desarrollo en su conjunto.

Señal de alerta: el entregable es una presentación en lugar de un conjunto de registros.

Cuándo esta lista de verificación es excesiva

Ejecutar los ocho pasos en un sistema que lleva dos semanas en producción y que solo presta servicio al personal interno suele ser un mal uso de un mes de trabajo. Ajuste la profundidad a la exposición. Una herramienta de resumen para el equipo de marketing necesita, en realidad, tres cosas: una ficha del modelo que nombre a su propietario y su propósito, una comprobación de qué datos toca y si puede usarlos, y una prueba de seguridad que cubra la inyección de instrucciones y a qué puede acceder la herramienta. Un modelo de decisión de crédito necesita los ocho pasos, dos veces al año, revisados por alguien independiente del equipo que lo construyó.

La lista de verificación también asume que puede ver el interior del sistema. Cuando audita un modelo de proveedor cerrado, tres pasos cambian de forma. Las pruebas de rendimiento, las pruebas de sesgo y las pruebas de seguridad pasan de inspeccionar el modelo a probar su comportamiento desde el exterior y leer los compromisos contractuales del proveedor. Sigue siendo una auditoría legítima, solo necesita etiquetarse con honestidad en el informe para que nadie confunda una declaración con una medición.

Por último, una auditoría es una fotografía de una fecha concreta. Por eso el paso de monitoreo y registro tiene más peso del que parece a primera vista, ya que el monitoreo continuo es lo que mantiene vivos los hallazgos entre revisiones formales.

Por qué Redwerk es un socio adecuado para esto

Llevamos construyendo software personalizado desde cero desde 2005, lo que significa que auditamos como lo hacen los ingenieros, comprobando los puntos donde estos sistemas realmente fallan en lugar de seguir una lista genérica. Como damos soporte a clientes en todas las etapas del SDLC, también podemos revisar cada una de esas etapas, identificar las brechas y recomendar soluciones ajustadas al equipo que debe implementarlas.

Los entornos regulados son un terreno conocido para nosotros. Construimos la aplicación cívica YouTown, que recibió reconocimiento de la Casa Blanca, actualizamos la plataforma de voto electrónico EUGI para el Parlamento Europeo, y lanzamos un SaaS de prestación de asistencia social que hoy utilizan más de diez condados y estados de EE. UU. En el ámbito de la IA, hemos ayudado a construir, escalar y mantener sistemas en producción, incluidos Recruit Media y Evolv.

Si prefiere confiar esta lista de verificación a un equipo que ya la ha ejecutado antes, póngase en contacto con nosotros y delimitaremos una auditoría para los sistemas que realmente tiene en producción.

Preguntas frecuentes

Descubre cómo realizamos una auditoría en una app de mapeo de redes, comprobando la salud de la base de código y la seguridad

Este campo es obligatorio. no es un correo electrónico comercial

Obtener Caso de Estudio