Auditoría de seguridad de IA y LLM

Enfoques: caja negra, caja gris y caja blanca

Los tres enfoques no responden a la misma pregunta. En una aplicación de IA la diferencia está en lo que nos entregas al empezar: solo una interfaz, cuentas de prueba y la instrucción de sistema, o además el código de orquestación y la configuración de las herramientas.

Caja negra (black box)

Solo disponemos de la interfaz, como cualquier usuario anónimo o como un cliente más. Sirve para medir lo que está expuesto públicamente y para probar la prompt injection desde fuera. Su límite es mecánico: una parte del presupuesto se va en adivinar la instrucción de sistema, la lista de herramientas y la estructura del índice, y las herramientas que el agente puede invocar quedan en gran medida sin cubrir.

Caja gris (grey box)

Es nuestro enfoque por defecto en prácticamente todos los proyectos de IA. Nos entregas una cuenta por rol, la instrucción de sistema, la lista de herramientas y la descripción del pipeline RAG. Con el mismo esfuerzo apuntamos directamente a las diferencias de autorización, a las cadenas entre herramientas y a los documentos que el índice no debería devolver. La instrucción de sistema y la lista de herramientas expuestas valen varias jornadas de conjeturas.

Caja blanca (white box)

Añadimos el código de orquestación, las definiciones de las funciones, la configuración de los servidores MCP y las reglas de filtrado. Es lo indicado antes de pasar a producción un agente con permisos de escritura, y cuando la aplicación trata datos de salud, datos de menores o pagos.

Un test en caja negra no es «más realista» que uno en caja gris: solo está peor informado. Quien ataca de verdad no tiene fecha de entrega; un proyecto la tiene siempre. El trabajo del alcance consiste en colocar las jornadas donde producen más información útil.

Qué obliga realmente en España

Con la IA está pasando lo mismo que pasó con NIS2: se vende mucho servicio con un argumento normativo que nadie comprueba. Conviene separar lo que está en vigor de lo que todavía es un proyecto.

El Reglamento (UE) 2024/1689, el llamado Reglamento de IA, sí es derecho aplicable y no necesita transposición. Su art. 15 exige que los sistemas de IA de alto riesgo alcancen un nivel adecuado de exactitud, solidez y ciberseguridad, y menciona de forma expresa las medidas frente al envenenamiento de los datos de entrenamiento y del modelo, los ejemplos adversarios y los ataques contra la confidencialidad del modelo. Es, literalmente, la lista de lo que se prueba en un pentesting de IA. Ahora bien, esa obligación solo alcanza a los sistemas clasificados como de alto riesgo: si tu asistente interno no lo es, el art. 15 no te obliga, y decirte lo contrario sería venderte miedo.

NIS2 no está transpuesta en España. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad solo ha pasado una primera lectura en Consejo de Ministros, el 14 de enero de 2025, y no ha llegado a las Cortes. La Comisión Europea llevó a España ante el Tribunal de Justicia de la Unión Europea el 9 de julio de 2026 por esa falta de transposición, en el procedimiento INFR(2024)0270. Tampoco es ley todavía el anteproyecto de ley para el buen uso y la gobernanza de la inteligencia artificial, que tuvo su primera lectura en Consejo de Ministros el 11 de marzo de 2025 y que es el que fijará el régimen sancionador español del Reglamento de IA. Lo que sí existe ya es la autoridad: España creó la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) por el Real Decreto 729/2023, con sede en A Coruña.

Lo que está en vigor hoy y sí obliga a probar es esto:

• RGPD, art. 32.1.d). Exige «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento». Un asistente interno trata datos personales casi siempre —basta con que alguien pegue un correo en el chat—, y los registros de prompts son un tratamiento por derecho propio. El pentest es la forma habitual de documentar ese proceso. Si además el sistema toma decisiones con efectos jurídicos sobre personas, entra en juego el art. 22, y la AEPD publica orientaciones sobre tratamientos que incorporan inteligencia artificial.
• Reglamento de Ejecución (UE) 2024/2690. De aplicación directa, sin transposición. Su Anexo, en el punto 6.5 «Pruebas de seguridad», exige una política de pruebas documentada, un alcance y una periodicidad determinados por riesgo, una metodología y unos resultados documentados, y la corrección de los hallazgos críticos. Es la obligación de pruebas más concreta que hay hoy sobre la mesa en España, y casi nadie la cita.
• RDL 12/2018 y RD 43/2021. Trasponen la directiva NIS original y siguen siendo el marco aplicable a operadores de servicios esenciales y proveedores de servicios digitales, con sus obligaciones de auditoría y de análisis de riesgos periódicos.
• ENS, RD 311/2022. Si el asistente da servicio a una administración, o si se lo prestas tú a una, el sistema entra en el ámbito del Esquema Nacional de Seguridad. El art. 31 impone una auditoría regular ordinaria al menos cada dos años, y el art. 38 separa la autoevaluación de la categoría BÁSICA de la certificación exigida en MEDIA y ALTA. En el Anexo II, el refuerzo [op.mon.3] R6 incluye el subrequisito [op.mon.3.r6.3], titulado literalmente «Pruebas de penetración», exigible en categoría ALTA. Y ya desde BÁSICA, op.nub.1.2 a) pide la «Auditoría de pruebas de penetración (pentesting)» de los servicios cloud de terceros que no sean conformes con el ENS: es exactamente el caso de un modelo consumido como API en la nube de otro.
• DORA, Reglamento (UE) 2022/2554. Se aplica en el sector financiero desde el 17 de enero de 2025. El art. 24 obliga a mantener un programa de pruebas de resiliencia operativa digital, y el art. 26 añade, para las entidades designadas, ejercicios de pruebas basadas en amenazas al menos cada tres años.

Nuestro papel es el técnico: ejecutamos las pruebas y documentamos los resultados de forma que sirvan como evidencia ante quien tenga que valorarlos. Lo que no hacemos está escrito más abajo, con el mismo detalle. El desarrollo completo está en qué exige realmente el ENS sobre pentesting y en NIS2 en España: qué obliga hoy y qué no.

Última verificación: 12 de septiembre de 2026.

Alcance y planificación: qué se acuerda antes de empezar

Un proyecto de IA mal acotado produce un informe que no sirve, y además una factura de inferencia que nadie esperaba. Antes de la primera prueba dejamos por escrito siete cosas, y ninguna se decide sobre la marcha.

• Objetivos. Qué asistentes, qué agentes, qué modelos, qué índices RAG y qué servidores MCP entran, con su URL, su versión y la persona responsable de cada uno.
• Exclusiones. Lo que queda fuera se escribe con el mismo detalle que lo que entra: la infraestructura del proveedor del modelo, los sistemas de terceros conectados que no controlas, las herramientas que mueven dinero de verdad, los ataques de denegación de servicio y cualquier prueba capaz de destruir datos o de contaminar un índice de producción.
• Roles y cuentas. Una cuenta por rol, con datos de prueba, para poder comparar permisos entre perfiles. Es lo que hace posible verificar que un cliente no recupera los documentos de otro a través del RAG.
• Instrucción de sistema y catálogo de herramientas. En caja gris nos los entregas al empezar. No es información que debilite el test: es información que evita gastar jornadas en deducirla.
• Tope de peticiones y de gasto. Fijamos un límite de llamadas y un techo de consumo de tokens acordado contigo, para que ninguna prueba se traduzca en un cargo imprevisto. Cuando probamos la denegación de servicio económica, lo hacemos calculando el coste unitario y extrapolando, no agotando tu cuota.
• Ventana de ejecución y reglas de actuación. Fechas y franjas horarias —de 9:00 a 18:00 salvo que pidas otra cosa—, aviso previo a quien opera la plataforma, hasta dónde llegamos si un agente nos da capacidad de escritura, qué hacemos con los datos reales que veamos y a quién llamamos. Un hallazgo crítico se comunica en el momento, no al final.
• Entorno. Producción o preproducción. Con agentes que escriben en sistemas de negocio trabajamos en preproducción siempre que exista un entorno representativo; si solo hay producción, las herramientas con efectos irreversibles se excluyen o se sustituyen por versiones simuladas pactadas contigo.

En el alcance se fijan también las jornadas, porque el esfuerzo es la variable que decide la cobertura. Un chatbot sin herramientas ni base documental cabe en 3 a 5 jornadas. Una aplicación con pipeline RAG, varios roles y algunas herramientas de solo lectura pide de 6 a 10. Un agente que escribe en sistemas de negocio, o una arquitectura multiagente montada sobre servidores MCP, supera con frecuencia las 12 jornadas, a las que se suma el test de la aplicación clásica si lo incluyes. La cifra queda escrita en el presupuesto; si durante el proyecto vemos que se queda corta, te lo decimos antes de consumirla, no después.

El documento de alcance se firma junto con la autorización de pruebas. Sin esa autorización no empezamos: sin ella, el mismo trabajo sería la conducta que describen los arts. 197 bis y 264 del Código Penal. Y si el modelo que usas es de un tercero, revisamos contigo sus condiciones de uso, porque son ellas las que delimitan qué podemos probar sobre la parte que no es tuya.

Tratamiento de datos y soberanía

Una auditoría de IA genera material especialmente sensible: prompts reales, extractos de tu corpus documental, credenciales de prueba, capturas de conversaciones y un informe que describe paso a paso cómo hacer que tu asistente diga o haga lo que no debe. Dónde vive ese material y bajo qué jurisdicción es una pregunta legítima del departamento de compras, y merece una respuesta concreta en lugar de una frase de marketing.

Haxoris es una empresa establecida en la Unión Europea, con oficinas en Bratislava y en Praga. Eso tiene tres consecuencias prácticas, y las tres se pueden verificar en el contrato antes de firmarlo:

• El RGPD se aplica de forma directa, con el mismo texto y bajo autoridades de control europeas. No hace falta una capa contractual que replique garantías: el reglamento ya rige el tratamiento.
• No hay transferencia internacional de datos en el sentido del capítulo V del RGPD, porque el tratamiento no sale del Espacio Económico Europeo. No hacen falta cláusulas contractuales tipo, ni evaluación de impacto de la transferencia, ni el análisis de derecho extranjero que sí exige contratar a un proveedor de fuera de la Unión.
• Ninguna autoridad de un tercer país puede reclamar el material por la vía de su propio derecho interno. La discusión sobre acceso extraterritorial —la CLOUD Act estadounidense es el caso conocido— sencillamente no se plantea.

Hay además un compromiso propio de este servicio: tu material no entra en ningún modelo. No pegamos tus documentos, tus prompts ni tus hallazgos en un asistente comercial de terceros, no se usan como datos de entrenamiento ni de ajuste fino, y cuando en el proyecto usamos herramientas con modelos de lenguaje lo hacemos sobre instancias que no retienen ni reutilizan lo que reciben. Es un punto que conviene preguntar a cualquier proveedor de seguridad hoy, porque la tentación de ahorrarse una hora de análisis pasando tu informe por un chatbot público es real.

Sobre tu propio sistema, el informe hace un trabajo que casi nadie pide y todo el mundo agradece: dejamos escrito qué datos salen de la Unión Europea a través de tus integraciones —qué proveedor de modelo recibe qué, qué se queda en sus registros y durante cuánto tiempo, qué región de despliegue tienes configurada—, para que tu registro de actividades de tratamiento y tu análisis de transferencias se apoyen en un hecho comprobado y no en la ficha comercial del proveedor.

En el plano operativo: el material del proyecto se cifra en reposo y en tránsito, se conserva el tiempo pactado y se destruye a petición tuya con constancia escrita. Las personas que van a tocar tu aplicación están nombradas en el contrato, con sus certificaciones, y firman confidencialidad a título individual. El informe se entrega cifrado y en español.

Si tu comité de compras nunca ha contratado seguridad ofensiva fuera de España, lo tratamos punto por punto en contratar una empresa de pentesting no española.

Qué no hacemos

Decir dónde está el límite es lo que hace creíble todo lo anterior. Estas siete cosas quedan fuera, y preferimos que lo sepas antes de pedirnos un presupuesto.

• No certificamos. Haxoris no es entidad de certificación ni cuenta con acreditación de ENAC, así que no emitimos certificados de conformidad con el ENS, ni el distintivo que los acompaña, ni certificados ISO 27001. Eso lo firma un organismo de certificación acreditado. Lo nuestro es la parte técnica: el informe de pruebas que ese organismo, o quien te audite, te va a pedir como evidencia.
• No somos organismo notificado del Reglamento de IA. La evaluación de conformidad de un sistema de IA de alto riesgo, la declaración UE de conformidad y el marcado CE que la acompaña corresponden al proveedor del sistema y, cuando procede, a un organismo notificado. Nuestro informe alimenta esa documentación técnica con evidencia sobre la exactitud, la solidez y la ciberseguridad que exige el art. 15 del Reglamento (UE) 2024/1689; no la sustituye.
• No auditamos el modelo del proveedor. No probamos la infraestructura de OpenAI, Anthropic, Google o Mistral: sus condiciones de uso lo acotan estrictamente y, además, no es ahí donde está tu riesgo. Probamos tu integración. Si alojas un modelo propio, entonces sí entra su alojamiento, su exposición de red y la procedencia de los pesos.
• No evaluamos sesgo, equidad ni calidad de las respuestas. Que un modelo discrimine o alucine es un problema real, pero no es seguridad ofensiva y no fingimos cubrirlo. Nuestro informe habla de lo que un atacante consigue, no de si el modelo acierta.
• No hacemos TLPT. Los ejercicios de pruebas basadas en amenazas del art. 26 de DORA exigen proveedores que cumplan el art. 27 del Reglamento (UE) 2022/2554 y un proceso dirigido por la autoridad competente. Un ejercicio de Red Team nuestro puede servir de preparación previa, pero no lo sustituye y no nos presentamos a ese encargo.
• No trabajamos con información clasificada ni investigamos a personas concretas. El acceso a materia clasificada requiere habilitación de la Oficina Nacional de Seguridad, que no tenemos. El reconocimiento en fuentes abiertas se limita a la superficie de exposición de la organización, dentro del alcance contratado; las actividades que la Ley 5/2014 reserva en exclusiva a otras profesiones quedan fuera de lo que prestamos.
• No tenemos establecimiento en España. Somos un proveedor europeo: firmamos, facturamos y respondemos desde la Unión Europea, y trabajamos en español. Si tu pliego exige un proveedor establecido en España, dínoslo en la primera llamada y te lo diremos claro en lugar de hacerte perder el proceso.