¿Qué quiere ver un auditor cuando en la empresa funciona la IA? Seis cosas: un inventario de los sistemas, los registros de consultas, un esquema de accesos, el origen y la licencia de los modelos, una prueba de los flujos de datos y responsables con nombre. Quien puede acreditar esos seis puntos supera una auditoría de cliente, una revisión de protección de datos y la auditoría interna sin sobresaltos.
Actualizado: 2026-09-12
El detonante es menos veces el Reglamento de IA de lo que se cree. Las obligaciones del responsable del despliegue para sistemas de alto riesgo del artículo 26 no se aplican a la mayoría de los casos hasta el 2 de diciembre de 2027. Quien audita hoy es otro: el gran cliente que ya incluye la IA en su auditoría de proveedores, el delegado de protección de datos que quiere saber adónde van los datos de empleados, la auditoría interna, la aseguradora. Las preguntas de todos ellos se parecen muchísimo, y de ahí sale esta checklist.
1. El inventario: qué IA hay funcionando
Toda auditoría abre con la misma pregunta: ¿qué sistemas de IA usan y para qué? Quien duda aquí ya empieza perdiendo, porque todo lo demás cuelga de esa lista. Un inventario útil es una tabla con una fila por sistema: nombre, modelo y versión, finalidad, tipos de datos afectados, dónde funciona y quién responde de él. El uso en la sombra también va dentro, es decir, la cuenta de ChatGPT que alguien de contabilidad se abrió por su cuenta. Un inventario que solo conoce los sistemas oficiales se cae en la primera entrevista con un empleado.
Al inventario pertenece la pregunta del rol: ¿eres para cada sistema responsable del despliegue o proveedor? Para los sistemas comprados o autoalojados que usas tal cual, eres responsable del despliegue, y conviene anotarlo por sistema.
2. Registros: quién preguntó qué y cuándo
El auditor quiere comprobar que las consultas al sistema pueden reconstruirse: marca de tiempo, usuario o rol, qué modelo respondió. Con un modelo operado en local eso es una cuestión de configuración, porque la pasarela o la capa de servicio registran de todos modos. La trampa no es la técnica sino la regla que falta: ¿cuánto tiempo se conservan los registros, quién puede consultarlos, cuándo se borran?
No existe un plazo legal general. La referencia que se ha impuesto es la del artículo 26 del Reglamento de IA, que exige al menos seis meses para los sistemas de alto riesgo. Adoptar esos seis meses como regla interna escrita da una respuesta que cualquier auditor acepta y, a la vez, un plazo de borrado que resiste la revisión de protección de datos.
3. Accesos: quién llega a qué modelo
La tercera pregunta apunta a los permisos. ¿Quién puede usar el modelo, quién puede configurarlo, quién llega a los datos conectados? Esto se vuelve crítico en cuanto hay una canalización de recuperación sobre documentos internos: si el modelo puede buscar en contratos y expedientes de personal, la búsqueda debe respetar los mismos permisos que el propio archivo documental. La auditoría lo comprueba con una pregunta sencilla: ¿puede un operario de almacén encontrar datos salariales a través del chatbot? La respuesta tiene que ser un no demostrable, impuesto por un esquema de roles en la canalización, no por confianza.
4. Origen y licencia del modelo: qué es lo que funciona ahí
Con modelos abiertos operados en local, el auditor pregunta por el origen y la base legal: ¿qué modelo, qué versión, descargado de qué fuente, bajo qué licencia? Documentarlo lleva cinco minutos y pesa mucho, porque separa la operación ordenada del taller improvisado. La diligencia incluye leer la propia licencia: no todo modelo abierto es igual de libre. Llama se distribuye bajo una licencia comunitaria propia con condiciones, muchos modelos Qwen bajo Apache 2.0, y algunos tamaños vuelven a tener licencia propia. Anota nombre del modelo, versión, fuente, suma de verificación y licencia por sistema, y esta pregunta queda respondida en una línea.
5. Flujos de datos: la prueba de que nada sale
El argumento más fuerte de la IA local es a la vez la pregunta en la que los despliegues en la nube pierden más tiempo de auditoría: ¿adónde van los datos? Con un servicio en la nube, la respuesta se compone de contrato de encargo de tratamiento, cláusulas contractuales tipo y la confianza en que el proveedor cumple su propia política. Con un sistema local, la respuesta es una prueba: una regla de salida en el cortafuegos que prohíbe al servidor de IA las conexiones salientes, o una captura de tráfico documentada que muestra cero tráfico saliente durante la inferencia.
La clave es generar esa prueba una vez, con fecha y de forma limpia, en lugar de improvisarla durante la auditoría. Ese es el núcleo de la soberanía de datos: no la promesa, sino la demostrabilidad.
6. Responsables y competencia: quién carga con esto
Por último, el plano organizativo. El auditor quiere un nombre por sistema: quién lo opera, quién aprueba cambios, quién interviene cuando produce salidas erróneas. Y después, la formación. El artículo 4 del Reglamento de IA exige desde el 2 de febrero de 2025 adoptar medidas para apoyar el desarrollo de la competencia en IA del personal, como deber de medios sin multa propia, pero deber al fin y al cabo. Un registro breve y documentado de formación por rol responde la pregunta. La supervisión humana va en la misma línea: qué salidas exigen cuatro ojos y cuáles no pueden salir nunca de forma automática.
Por qué en local la auditoría es más fácil, pero no automática
Las seis áreas valen para cualquier IA, en la nube o en servidor propio. La diferencia está en cómo nacen las pruebas. Operando en local sabes qué modelo y qué versión están en marcha, los registros se quedan en casa y la prueba del flujo de datos es una regla de cortafuegos en lugar de un tomo de contratos. Lo que en local no ocurre solo es la organización: el inventario, la regla de conservación, el esquema de accesos y los responsables los tiene que escribir alguien. Un modelo local sin esos documentos apenas queda mejor en una auditoría que una cuenta en la nube sin contrato.
Esta exposición refleja nuestro entendimiento de la práctica habitual de auditoría y no sustituye el asesoramiento legal de tu caso concreto. Si quieres dejar montados los seis puntos para tu empresa de una vez, del inventario a la prueba documentada del flujo de datos, eso es exactamente parte de nuestro proyecto piloto.
Preguntas frecuentes
¿Qué documentación pide un auditor cuando la empresa usa IA local?
En la práctica, seis cosas: un inventario de los sistemas de IA con su finalidad, los registros de consultas con una regla de conservación escrita, un esquema de accesos, el origen y la licencia de cada modelo, una prueba de los flujos de datos y responsables con nombre y formación documentada.
¿Cuánto tiempo hay que conservar los registros de un sistema de IA?
No existe un plazo legal general. El artículo 26 del Reglamento de IA exige al menos seis meses para los sistemas de alto riesgo, y esa cifra se ha convertido en la referencia que aceptan las auditorías de clientes y de protección de datos. Más importante que el número es que exista una regla escrita.
¿Basta con afirmar que la IA local no envía datos fuera?
Como afirmación, no. Como prueba, sí. El auditor quiere ver la afirmación respaldada, por ejemplo con una regla de cortafuegos que bloquee las conexiones salientes del servidor de IA, o con una captura de tráfico documentada que muestre cero tráfico saliente durante la inferencia. Esa prueba es justo la que un despliegue local permite obtener con facilidad.
¿Necesita una pyme certificarse en ISO para pasar una auditoría de IA?
No. La ISO/IEC 42001 es voluntaria e innecesaria para la mayoría de las pymes. Las seis áreas de esta checklist cubren lo que hoy preguntan de verdad las auditorías de clientes, las revisiones de protección de datos y la auditoría interna. Una certificación puede construirse después sobre esa base, pero no la sustituye.