Garantizar la Inteligencia Artificial de Alto Riesgo - IA Segura y Cumplimiento
Por qué escribo esto. Cada vez oigo más la misma pregunta en equipos técnicos y comités de riesgos: “¿Podemos tener un asistente como ChatGPT, Gemini o Copilot, pero en nuestra casa, gratis y sin que los datos salgan de la empresa?” La respuesta corta es que sí, con matices. La larga es este artículo.
Aquí te cuento qué modelos abiertos merecen la pena a día de hoy, cuál elegiría yo según el escenario y, sobre todo, cómo montarlo para que sea seguro, trazable y defendible ante una auditoría de ISO/IEC 42001 y el Reglamento Europeo de IA. Sin humo y con datos a 31 de octubre de 2026.
Resumen
- Lo que no puedes instalar: ChatGPT, Claude, Gemini, Copilot y Perplexity son servicios cerrados. No se descargan.
- Lo que sí: modelos de pesos abiertos (open-weight), es decir, modelos cuyo “cerebro” entrenado se publica para que cualquiera lo descargue. Funcionan en tus servidores con programas gratuitos como vLLM, SGLang u Ollama.
- Mi apuesta para Europa: Granite 4.1 si mandan la auditoría y el coste, Mistral si manda la capacidad, y Apertus si necesitas transparencia total.
- La idea que más se malinterpreta: el modelo no está “al día”. La actualidad la pone tu arquitectura RAG (generación aumentada por recuperación: el sistema busca primero en tus documentos y le pasa al modelo lo que encuentra), no el modelo.
1. Primero, ajustemos expectativas
Seamos honestos: ninguno de los asistentes comerciales que conocemos (ChatGPT, Gemini, Copilot, Claude o Perplexity) se puede descargar e instalar gratis en un servidor propio. Lo que usas en el navegador es mucho más que un modelo. Hay un modelo de frontera, una infraestructura enorme, búsqueda web en tiempo real y varias capas de seguridad del proveedor.
Lo que sí puedes hacer es descargar un modelo de pesos abiertos y ejecutarlo en tu propia infraestructura. Y la buena noticia es que la distancia se ha acortado mucho. Para ponerle una cifra, he usado el ranking público de BenchLM, que reúne los resultados de muchas pruebas estándar (razonamiento, matemáticas, programación, comprensión…) y los resume en una nota de 0 a 100.
De dónde sale el “~19 puntos”. No es un cálculo mío: es la diferencia que publica BenchLM con datos del 29 de octubre de 2026.
- Mejor modelo abierto: Kimi K3, con 69,3 sobre 100 (puesto 17 de la clasificación general).
- Mejor modelo comercial cerrado: Gemini 4 Carbon, con unos 88,4 sobre 100.
- Diferencia: 88,4 − 69,3 = 19 puntos, aproximadamente.
Tómalo como una referencia, no como una verdad absoluta. Otros rankings, como Artificial Analysis o LMArena, usan pruebas distintas y dan cifras diferentes. Lo que sí coinciden en mostrar todos es la tendencia: la distancia se ha reducido mucho en el último año.
Se nota en el razonamiento más abstracto. En el trabajo de oficina de verdad (resumir, clasificar, extraer datos, consultar documentación interna, ayudar con código) la diferencia es pequeña si el sistema está bien diseñado.
Antes de seguir, dos aclaraciones que me parecen importantes:
- Abierto no siempre es open source. Que publiquen los pesos no significa que publiquen los datos con los que se entrenó. Muy pocos proyectos lo hacen (Apertus es la excepción más clara).
- Gratis en licencia no es gratis en coste. Un modelo de un billón de parámetros (un millón de millones de “ajustes” internos aprendidos durante el entrenamiento) necesita GPU (tarjetas gráficas de cálculo) de centro de datos. Dejas de pagar por token y empiezas a pagar hardware, energía y operación.
2. Los modelos que hay hoy sobre la mesa
He resumido las familias que yo tendría en cuenta en una empresa europea. No están todas las que existen; están las que tienen sentido en un entorno donde la licencia y el cumplimiento importan tanto como el rendimiento.
| Modelo (origen) | Última versión | Licencia | Para qué lo usaría |
|---|---|---|---|
| Mistral Large 4 (Francia) | Pesos publicados el 29/10/2026 · ~1 billón de parámetros, ~49.000 millones activos | MIT modificada. Libre para uso propio; si vendes el modelo como servicio a terceros, necesitas licencia comercial | Máxima capacidad con proveedor europeo. Muy orientado a código y ciberdefensa |
| Mistral Large 3 / Ministral 3 (Francia) | Dic. 2025 · 675.000 millones (41.000 activos) y versiones de 3B a 14B | Apache 2.0 | Cuando quieres Mistral con la licencia más limpia posible |
| IBM Granite 4.1 (EE. UU.) | 29/04/2026 · 3B, 8B y 30B, más modelos de visión, voz, embeddings y Guardian | Apache 2.0 | Entornos auditados. Proveedor con ISO/IEC 42001 certificada y pesos firmados. No es para razonamiento de frontera |
| Google Gemma 4 (EE. UU.) | 02/04/2026 · de 2B a 31B | Apache 2.0 | El mejor candidato no chino para una sola GPU. Multimodal y con más de 140 idiomas |
| Qwen3.8 (China) | Agosto 2026 · 27B y 2,4 billones | 27B en Apache 2.0; el grande con licencia propia | El 27B rinde muy bien en un equipo local. Revisa la licencia de cada versión |
| Kimi K3, DeepSeek V4.1, GLM-5.3, MiMo (China) | Julio a octubre 2026 · de 552.000 millones a 2,8 billones | MIT o licencias propias | Lo más potente en abierto según los rankings. Requieren centro de datos y un análisis de riesgo de proveedor |
| Meta Llama 4 / Muse Spark Open (EE. UU.) | Muse Spark Open: 15/10/2026 | Licencias propias de Meta | Con cautela: la licencia de Llama 4 restringe derechos a empresas con sede en la UE. Que lo mire Legal |
| Microsoft Phi-4 (EE. UU.) | 14B y versión mini | MIT | Tareas acotadas y dispositivos con pocos recursos |
| Apertus (Suiza) | 8B y 70B | Apache 2.0 | Cuando necesitas demostrar con qué datos se entrenó. Menos potente, pero el más transparente |
Un consejo: no te cases con ningún ranking. Cambian cada semana y cada uno mide una cosa distinta. Úsalos para hacer una lista corta y decide con tus propias pruebas.
¿El más grande, el más nuevo o el mejor?
Es lo primero que me suelen preguntar, así que voy directo:
- El más grande: Kimi K3, con 2,8 billones de parámetros, seguido de Qwen3.8 con 2,4 billones. Ojo, más grande no significa más actualizado ni más seguro, y exige cientos de GB de memoria de GPU.
- El más reciente: Mistral Large 4, cuyos pesos salieron el 29 de octubre de 2026.
- El mejor en pruebas: Kimi K3, MiMo-V2.6-Pro y GLM-5.3 se reparten el primer puesto según el ranking que mires.
- El mejor europeo: Mistral Large 4, o Large 3 si prefieres Apache 2.0 y menos hardware.
Sobre la “información actualizada”. Todos los modelos tienen una fecha de corte: no saben nada de lo que pasó después. Si Perplexity o Copilot parecen estar al día es porque buscan en Internet antes de responder. En tu casa puedes hacer lo mismo conectando el modelo a tus documentos, bases de datos o un buscador propio. Si lo conectas a Internet, recuerda que esas preguntas salen de tu perímetro: decide cuáles pueden salir y déjalo registrado.
3. Si tuviera que elegir hoy
Mi recomendación depende menos del modelo y más del contexto en el que vas a trabajar:
- Banca, seguros o Administración, con auditorías frecuentes: empezaría por Granite 4.1 (8B o 30B) con Granite Guardian. Licencia limpia, pesos firmados, un proveedor que ya ha pasado una auditoría ISO/IEC 42001 y un hardware asequible.
- Soberanía europea con la máxima capacidad: Mistral Large 4. Proveedor europeo, multilingüe y muy orientado a ciberdefensa. Solo revisa la cláusula de “modelo como servicio” si vas a ofrecerlo a terceros.
- Sector público o contratos donde te pidan explicar con qué se entrenó el modelo: Apertus 70B.
- Una prueba de concepto con una sola GPU de 16 a 24 GB: Gemma 4 o Qwen3.8-27B.
- Quiero lo más potente y el coste me da igual: Kimi K3, GLM-5.3 o DeepSeek V4.1. Técnicamente son los mejores y, ejecutados en local, tus datos no salen de casa. Pero yo haría antes un análisis serio de cadena de suministro, licencia y sesgos, y comprobaría que encajan con la política de proveedores (y con el ENS y las guías del CCN si aplican).
Lo que yo haría: no lo apuestes todo a un solo modelo. Monta un modelo principal (Mistral o Granite), uno pequeño que vigile las entradas y salidas (Granite Guardian o Llama Guard) y otro para las búsquedas en documentos. Ponlos detrás de un gateway, de forma que mañana puedas cambiar de modelo sin rehacer la aplicación.
¿Qué máquina necesito?
| Escenario | Hardware aproximado | Modelos que caben |
|---|---|---|
| Prueba en un puesto | GPU de 12–16 GB o equipo con 16–32 GB de memoria unificada | Granite 4.1 3B/8B, Gemma 4 pequeño, Ministral 3, Phi-4 |
| Servidor de departamento | 1 o 2 GPUs de 24–48 GB | Gemma 4 31B, Qwen3.8-27B, Granite 4.1 30B |
| Servidor corporativo | 2 a 4 GPUs de 80 GB | Apertus 70B, Llama 4 Scout |
| Centro de datos | Nodos de 8 GPUs H100, H200 o B200 | Mistral Large 3/4, DeepSeek V4.1, Kimi K3, Qwen3.8 grande |
Son cifras orientativas. Cambian mucho según la compresión del modelo, el tamaño de los documentos que le pases y cuántas personas lo usen a la vez.
4. Cómo lo montaría yo
Aquí está lo que más me interesa como arquitecto de seguridad: el modelo es la pieza menos crítica del sistema. Los riesgos de verdad están alrededor: quién pregunta, qué información se le entrega al modelo, qué devuelve y qué queda registrado. Este es el recorrido que yo diseñaría:
- Canal cifrado. Todo viaja cifrado con TLS 1.3 (el mismo cifrado del candado del navegador). Entre servicios internos, mTLS (TLS mutuo: los dos extremos se identifican con certificado).
- Identidad. Inicio de sesión único corporativo (SSO) con MFA (autenticación multifactor: contraseña más un segundo factor, como el móvil), con Entra ID o Keycloak. Nada de accesos anónimos ni claves compartidas.
- Gateway de IA. Decide quién puede usar qué caso de uso, pone límites de consumo y filtra intentos de manipulación del modelo y datos sensibles en la entrada con DLP (prevención de fuga de datos), usando LiteLLM o Presidio.
- Búsqueda en documentos (RAG, generación aumentada por recuperación). La regla de oro: el usuario solo recibe fragmentos de documentos que ya tenía permiso para leer. Y cada respuesta, con su cita.
- Base vectorial cifrada (donde se guardan los documentos convertidos en números para poder buscarlos por significado), por áreas o clasificación de la información (Qdrant, Milvus, pgvector).
- Servidor del modelo aislado, sin salida a Internet y con los pesos verificados por hash o firma (vLLM, SGLang, o Kubernetes con KServe u OpenShift AI).
- Filtro de salida que revisa fugas de datos, contenido inapropiado y respuestas sin respaldo (Granite Guardian, Llama Guard, NeMo Guardrails).
- Registro y SIEM (la plataforma que centraliza y correlaciona los eventos de seguridad). Quién preguntó, qué contexto se usó, qué respondió y con qué versión del modelo (Langfuse y OpenTelemetry hacia Wazuh, Elastic o Splunk).
Un apunte práctico: Ollama es estupendo para probar en tu equipo, pero para producción con muchos usuarios yo iría a vLLM o SGLang. Y por favor, nunca dejes un Ollama escuchando en todas las interfaces de red sin autenticación. Es más habitual de lo que parece.
5. Las preguntas de seguridad que hay que poder responder
Si tuviera que presentar esto ante un comité de riesgos, llevaría esta tabla. Cada fila responde a una pregunta que tarde o temprano te van a hacer. En la última columna verás referencias a ISO 27001 (seguridad de la información), ISO 42001 (gestión de la IA) y al OWASP Top 10 para LLM: la lista de los diez riesgos más importantes en aplicaciones con modelos de lenguaje (LLM), que publica la fundación OWASP.
| Propiedad | La pregunta del comité | Cómo la respondo | Referencia |
|---|---|---|---|
| Confidencialidad | ¿Pueden salir datos por las respuestas, los logs o la base vectorial? | Modelo en local sin salida a Internet, cifrado, DLP en entrada y salida, permisos heredados en la búsqueda y logs sin datos personales innecesarios | ISO 42001 A.7 · ISO 27001 8.11, 8.24 · OWASP LLM02, LLM08 |
| Integridad | ¿Cómo sé que el modelo y los documentos no han sido manipulados? | Descarga oficial, verificación de firma o hash, formato safetensors, inventario de componentes del sistema de IA (AI-BOM, la “lista de ingredientes” del modelo y sus dependencias) y control de cambios de los índices | ISO 42001 A.6, A.10 · ISO 27001 5.21, 8.32 · OWASP LLM01, LLM03, LLM04 |
| Autenticación | ¿Quién está al otro lado? | SSO con MFA, tokens de corta duración y mTLS entre servicios | ISO 27001 5.17, 8.5 |
| Autorización | ¿Puede el asistente enseñarle a alguien algo que no debería ver? | Permisos por caso de uso, filtrado de documentos antes de recuperarlos, mínimo privilegio para los agentes y aprobación humana en acciones críticas | ISO 42001 A.9 · ISO 27001 5.15, 8.2 · OWASP LLM06 |
| Trazabilidad | Si algo sale mal, ¿puedo reconstruir lo que pasó? | Registro de pregunta, fuentes, respuesta, versión del modelo y usuario, con una retención acorde al RGPD | ISO 42001 A.6.2.8 · ISO 27001 8.15, 8.16 |
| Disponibilidad | ¿Qué pasa si se satura o se cae? | Límites de consumo, réplicas, un modelo de respaldo más pequeño y copias de pesos e índices | ISO 27001 5.30, 8.13, 8.14 · OWASP LLM10 |
| Exactitud | ¿Y si se inventa la respuesta? | Lo explico en el siguiente apartado | ISO 42001 A.6.2.4 · OWASP LLM09 · AI Act art. 15 |
6. Alucinaciones: hablemos claro
Se repite mucho que “con RAG se acaban las alucinaciones”. Ojalá fuera así, pero no.
Conectar el modelo a tus documentos las reduce muchísimo. Aun así, un modelo puede ignorar el contexto, mezclar dos fuentes o rellenar un hueco con algo que suena bien. Por eso no prometo nunca “cero alucinaciones”. Prometo algo más útil: reducirlas, medirlas y contenerlas.
Reducirlas
- Obligar al modelo a responder solo con lo que ha recuperado y a citar de dónde lo saca.
- Darle permiso para decir “no tengo información suficiente” cuando lo recuperado no es relevante. Parece obvio, pero casi nadie lo configura.
- Cuidar la búsqueda: trocear los documentos con cabeza, combinar búsqueda semántica y por palabras clave, y marcar qué versiones están vigentes para no citar una norma derogada.
- Configurar el modelo para que sea conservador en las consultas sobre hechos.
Medirlas
- Un juego de 100 a 300 preguntas reales con su respuesta validada por negocio, que se ejecuta cada vez que cambias algo.
- Métricas de fidelidad y relevancia con herramientas como RAGAS o DeepEval, y pruebas automáticas con promptfoo.
- Pruebas de ataque periódicas (red teaming) con garak o PyRIT.
Contenerlas
- Un filtro de salida que bloquee o marque las respuestas sin respaldo.
- Una persona que revise siempre las decisiones con impacto: legales, económicas, de RR. HH. o de seguridad.
- Avisar al usuario de que está hablando con una IA y de que debe contrastar lo importante. Además de ser buena práctica, lo exige el Reglamento de IA.
7. ISO/IEC 42001 sin humo
Esta norma genera bastante confusión, así que lo digo claro: ISO/IEC 42001 no certifica modelos. Certifica cómo una organización gestiona la IA. Por eso, que IBM tenga certificado el sistema con el que desarrolla Granite es una muy buena señal sobre el proveedor, pero no convierte automáticamente tu despliegue en conforme. Esa parte te toca a ti.
Si ya trabajas con ISO 27001 vas a estar cómodo: la estructura es la misma (cláusulas 4 a 10) y se integran de forma natural. Así lo aterrizaría yo:
| Qué pide la norma | Cómo lo bajo a tierra |
|---|---|
| Contexto y liderazgo (cl. 4–5) | Inventario de casos de uso de IA, política de uso aceptable y un responsable claro de cada sistema |
| Riesgos e impacto (cl. 6.1) | Matriz de riesgos apoyada en ISO/IEC 23894, evaluación de impacto con ISO/IEC 42005 y evaluación de impacto en protección de datos (DPIA o EIPD) si hay datos personales |
| Operación (cl. 8) | Un ciclo de vida con puntos de control: elegir el modelo, evaluarlo, aprobarlo, desplegarlo y vigilarlo |
| Evaluación y mejora (cl. 9–10) | Un cuadro de mando sencillo: tasa de alucinación, incidentes, bloqueos del filtro y disponibilidad |
| Anexo A (9 dominios, 38 controles) | Una única declaración de aplicabilidad junto a la de ISO 27001, con su evidencia para cada control. Los explico uno a uno en el siguiente apartado |
8. Los 38 controles de ISO/IEC 42001, uno a uno
El Anexo A de la norma reúne 38 controles, agrupados en 9 dominios, cada uno con su objetivo de control. Funciona igual que el Anexo A de ISO 27001: es un catálogo de referencia. En la declaración de aplicabilidad (SoA, Statement of Applicability) indicas qué controles aplicas, por qué, y justificas los que excluyes. El Anexo B de la norma da orientación para implantarlos.
He redactado cada control con mis propias palabras, con lo que busca, cómo lo aplicaría yo para reducir el riesgo y qué evidencia te pedirá el auditor. Cuando tiene relación directa, indico el artículo del AI Act con el que enlaza. El código aparece debajo de cada título, como referencia.
Consejo de auditoría: lo que más se suele revisar en una auditoría es la evidencia. Un control sin evidencia, para el auditor, no existe. Por eso cada fila termina con lo que deberías poder enseñar.
Políticas relacionadas con la IA (A.2 · 3 controles)
Objetivo de control: Que la dirección marque el rumbo y respalde el uso de la IA de acuerdo con las necesidades del negocio.
| # | Control | Qué busca | Cómo lo aplico | Evidencia para el auditor |
|---|---|---|---|---|
| 1 | Política de IA A.2.2 | Una política de IA aprobada por la dirección. | Redacta una política breve y clara: usos permitidos y prohibidos, qué datos se pueden usar, principios (privacidad, supervisión humana, transparencia) y responsables. | Política firmada, versionada y publicada en la intranet. |
| 2 | Alineación con otras políticas A.2.3 | Que la política de IA encaje con las de seguridad, privacidad, calidad o compras, sin contradicciones. | Revisa cómo se relaciona con el SGSI, la protección de datos, el uso aceptable y la gestión de proveedores, y ajusta lo que choque. | Matriz de relación entre políticas. |
| 3 | Revisión de la política de IA A.2.4 | Que la política no se quede obsoleta. | Revísala al menos una vez al año y siempre que cambie la normativa (por ejemplo, el AI Act), la tecnología o tras un incidente relevante. | Acta de revisión e historial de versiones. |
Organización interna (A.3 · 2 controles)
Objetivo de control: Que quede claro quién responde de un uso responsable de la IA en su implantación, operación y gestión.
| # | Control | Qué busca | Cómo lo aplico | Evidencia para el auditor |
|---|---|---|---|---|
| 4 | Roles y responsabilidades de IA A.3.2 | Saber quién decide, quién opera y quién supervisa cada sistema de IA. | Define una matriz RACI con el responsable del sistema, el propietario de los datos, Riesgos, el DPO (delegado de protección de datos) y el CISO (responsable de seguridad). | Matriz RACI y nombramientos formales. |
| 5 | Comunicación de inquietudes A.3.3 | Que cualquier persona pueda avisar de un problema con la IA sin miedo. | Habilita un canal (buzón, formulario o canal ético) con confidencialidad, protección frente a represalias y plazos de respuesta. En España enlaza con la Ley 2/2023 de protección del informante. | Procedimiento y registro de casos gestionados. |
Recursos de los sistemas de IA (A.4 · 5 controles)
Objetivo de control: Conocer y documentar todos los recursos que forman el sistema de IA, para entender bien sus riesgos e impactos.
| # | Control | Qué busca | Cómo lo aplico | Evidencia para el auditor |
|---|---|---|---|---|
| 6 | Documentación de recursos A.4.2 | Un inventario de todo lo que compone el sistema. | Registra modelo y versión, datos, herramientas, infraestructura y personas implicadas. Complétalo con una AI-BOM (la lista de componentes del sistema). | Inventario o CMDB actualizado. |
| 7 | Recursos de datos A.4.3 | Saber qué datos usa el sistema. | Documenta el origen, la categoría, la clasificación, si contienen datos personales y cuánto tiempo se conservan. | Catálogo de datos. |
| 8 | Recursos de herramientas A.4.4 | Controlar el software y las librerías del sistema. | Lista los frameworks (vLLM, LangChain…), sus versiones y licencias, y analiza sus vulnerabilidades con herramientas SCA (análisis de componentes de software). | Inventario de software con licencias y SBOM. |
| 9 | Recursos de sistema y computación A.4.5 | Conocer la infraestructura que lo sostiene. | Documenta GPU, servidores, nube o local, capacidad y ubicación de los datos. | Diagrama de arquitectura y plan de capacidad. |
| 10 | Recursos humanos A.4.6 | Contar con personas con la formación adecuada. | Define los perfiles necesarios y un plan de formación, incluida la alfabetización en IA que exige el AI Act (art. 4). | Plan de formación y registros de asistencia. |
Evaluación de impactos de los sistemas de IA (A.5 · 4 controles)
Objetivo de control: Valorar cómo afecta la IA a personas, grupos y a la sociedad durante todo su ciclo de vida.
| # | Control | Qué busca | Cómo lo aplico | Evidencia para el auditor |
|---|---|---|---|---|
| 11 | Proceso de evaluación de impacto A.5.2 | Un método definido y repetible para evaluar impactos. | Crea una plantilla con criterios claros, define cuándo se aplica (antes de desplegar y ante cambios importantes) y quién la aprueba. ISO/IEC 42005 sirve de guía. | Procedimiento aprobado. |
| 12 | Documentación de las evaluaciones A.5.3 | Conservar los resultados de cada evaluación. | Guarda cada informe con su versión, fecha, decisiones tomadas y riesgo residual aceptado. | Repositorio de evaluaciones. |
| 13 | Impacto en personas o grupos A.5.4 | Analizar efectos sobre las personas: discriminación, privacidad, seguridad o derechos. | Haz pruebas de sesgo, revísalo con el DPO y coordínalo con la evaluación de impacto en protección de datos (EIPD) y, cuando aplique, con la evaluación de impacto en derechos fundamentales del AI Act (art. 27). | Informe de impacto y EIPD. |
| 14 | Impacto social A.5.5 | Valorar efectos más amplios: empleo, medio ambiente o desinformación. | Añade una valoración cualitativa, incluido el consumo energético de las GPU. | Apartado específico en el informe de impacto. |
Ciclo de vida del sistema de IA (A.6 · 9 controles)
Objetivo de control: Fijar objetivos y procesos para diseñar y desarrollar la IA de forma responsable, con criterios claros en cada etapa.
| # | Control | Qué busca | Cómo lo aplico | Evidencia para el auditor |
|---|---|---|---|---|
| 15 | Objetivos de desarrollo responsable A.6.1.2 | Objetivos medibles de calidad, equidad y seguridad. | Define indicadores: tasa máxima de alucinación aceptada, tiempos de respuesta, límites de sesgo. | Objetivos documentados y aprobados. |
| 16 | Procesos de diseño y desarrollo responsable A.6.1.3 | Un proceso con puntos de control. | Establece un ciclo con aprobaciones: idea, evaluación de riesgo, pruebas, aprobación y producción, con seguridad desde el diseño. | Procedimiento de desarrollo (MLOps/LLMOps). |
| 17 | Requisitos y especificación A.6.2.2 | Dejar claro qué debe hacer el sistema y qué no. | Recoge requisitos funcionales, de seguridad (OWASP Top 10 para LLM), de privacidad y de rendimiento. | Documento de requisitos. |
| 18 | Documentación del diseño y desarrollo A.6.2.3 | Registrar las decisiones de diseño. | Anota por qué se eligió cada modelo y arquitectura, con sus alternativas descartadas. | Registro de decisiones de arquitectura (ADR). |
| 19 | Verificación y validación A.6.2.4 | Probar el sistema antes de ponerlo en producción. | Usa el juego de preguntas de prueba, métricas de fidelidad, pruebas de sesgo, red teaming y pruebas de seguridad. Enlaza con el AI Act (art. 15). | Informes de pruebas y criterios de aceptación. |
| 20 | Despliegue A.6.2.5 | Poner el sistema en marcha de forma controlada. | Pasa por gestión de cambios, despliegue gradual, plan de vuelta atrás y verificación de la integridad del modelo. | Plan de despliegue y petición de cambio aprobada. |
| 21 | Operación y monitorización A.6.2.6 | Vigilar el sistema mientras funciona. | Monitoriza errores, abusos, rendimiento y la deriva (cuando el sistema empeora con el tiempo). Envía alertas al SIEM. | Cuadro de mando y registro de alertas. |
| 22 | Documentación técnica A.6.2.7 | Información técnica para quien usa, opera o audita el sistema. | Elabora una ficha del modelo (model card) con su propósito, limitaciones e instrucciones. Enlaza con el AI Act (art. 11). | Documentación técnica versionada. |
| 23 | Registro de eventos A.6.2.8 | Poder reconstruir qué pasó y cuándo. | Registra preguntas, fuentes, respuestas, versión del modelo y usuario, protegiendo la integridad de los logs y fijando su retención. Enlaza con el AI Act (art. 12). | Política de registro y muestras de logs. |
Datos para los sistemas de IA (A.7 · 5 controles)
Objetivo de control: Entender el papel de los datos y sus efectos en la IA durante todo el ciclo de vida.
| # | Control | Qué busca | Cómo lo aplico | Evidencia para el auditor |
|---|---|---|---|---|
| 24 | Datos para desarrollo y mejora A.7.2 | Reglas para los datos con los que se entrena, ajusta o alimenta el sistema (también el RAG). | Define qué datos se usan, con qué base legal y aplicando minimización. | Procedimiento de gestión de datos. |
| 25 | Adquisición de datos A.7.3 | Saber cómo se obtienen los datos y con qué derechos. | Revisa licencias, contratos, permisos y consentimientos de cada fuente. | Registro de fuentes y licencias. |
| 26 | Calidad de los datos A.7.4 | Que los datos sean adecuados para su uso. | Fija criterios de exactitud, vigencia, completitud y representatividad. Enlaza con el AI Act (art. 10). | Informes de calidad de datos. |
| 27 | Procedencia de los datos A.7.5 | Conocer el origen y el recorrido de cada dato. | Registra el linaje, los hashes y las versiones de los índices del RAG. | Registro de linaje de datos. |
| 28 | Preparación de los datos A.7.6 | Documentar cómo se limpian y transforman los datos. | Describe la limpieza, la anonimización o seudonimización de datos personales y el etiquetado. | Scripts y registros del proceso. |
Información para las partes interesadas (A.8 · 4 controles)
Objetivo de control: Que todas las partes implicadas tengan la información necesaria para entender y valorar los riesgos de la IA.
| # | Control | Qué busca | Cómo lo aplico | Evidencia para el auditor |
|---|---|---|---|---|
| 29 | Información para los usuarios A.8.2 | Que los usuarios sepan qué hace el sistema, sus límites y que están usando IA. | Incluye un aviso visible de IA, una guía de uso y sus limitaciones. Enlaza con el AI Act (arts. 13 y 50). | Textos de aviso y manual de usuario. |
| 30 | Comunicación externa A.8.3 | Que terceros puedan informar de efectos negativos del sistema. | Habilita un formulario o contacto externo y un proceso para gestionar lo recibido. | Procedimiento y registro de comunicaciones. |
| 31 | Comunicación de incidentes A.8.4 | Un plan para informar de incidentes a quien corresponda. | Intégralo en la gestión de incidentes: usuarios afectados, autoridades (incidentes graves según el AI Act, art. 73) y brechas de datos según el RGPD (72 horas). | Procedimiento y registro de incidentes. |
| 32 | Información para partes interesadas A.8.5 | Decidir qué información compartir, con quién y cuándo. | Identifica las obligaciones de información hacia reguladores, clientes y socios, y cúmplelas. | Plan de comunicación y registro de envíos. |
Uso de los sistemas de IA (A.9 · 3 controles)
Objetivo de control: Que la organización use la IA de forma responsable y conforme a sus políticas.
| # | Control | Qué busca | Cómo lo aplico | Evidencia para el auditor |
|---|---|---|---|---|
| 33 | Procesos para un uso responsable A.9.2 | Procedimientos claros de uso. | Define las normas de uso, la aprobación de nuevos casos de uso y la supervisión humana. Enlaza con el AI Act (arts. 14 y 26). | Procedimiento de uso responsable. |
| 34 | Objetivos de uso responsable A.9.3 | Metas concretas y medibles para el uso. | Por ejemplo: todas las respuestas con cita de su fuente y revisión humana en las decisiones con impacto. | Indicadores y su seguimiento. |
| 35 | Uso previsto A.9.4 | Usar el sistema solo para lo que fue diseñado. | Documenta el uso previsto y revisa los logs para detectar usos fuera de alcance. | Ficha de uso previsto y revisiones periódicas. |
Relación con terceros y clientes (A.10 · 3 controles)
Objetivo de control: Que la organización sepa de qué responde y reparta los riesgos de forma adecuada cuando intervienen terceros.
| # | Control | Qué busca | Cómo lo aplico | Evidencia para el auditor |
|---|---|---|---|---|
| 36 | Asignación de responsabilidades A.10.2 | Dejar claro quién responde de qué entre la organización, sus proveedores y sus clientes. | Elabora una matriz de responsabilidad compartida, considerando si actúas como responsable del despliegue o como proveedor según el AI Act. | Contratos y matriz de responsabilidades. |
| 37 | Proveedores A.10.3 | Que los proveedores de modelos, nube o hardware estén a la altura. | Evalúa la licencia del modelo, sus certificaciones, las cláusulas contractuales y el riesgo de la cadena de suministro. | Evaluaciones de proveedores. |
| 38 | Clientes A.10.4 | Tener en cuenta las necesidades y expectativas de los clientes. | Informa a los clientes del uso de IA y fija condiciones de uso y niveles de servicio. | Contratos, condiciones y documentación entregada. |
Títulos y descripciones en redacción propia, con fines divulgativos. Para una implantación o una auditoría, trabaja siempre con el texto oficial de la norma (ISO o su versión UNE publicada por AENOR).
9. Lo que dice Europa
- Reglamento de IA (UE 2024/1689). En vigor desde agosto de 2024. Las prácticas prohibidas aplican desde febrero de 2025 y las obligaciones de los modelos de propósito general, desde agosto de 2025.
- Digital Omnibus (UE 2026/1744). En vigor desde el 27 de julio de 2026, aplaza las obligaciones de alto riesgo al 2 de diciembre de 2027 para los sistemas del Anexo III (empleo, crédito, infraestructuras críticas…) y al 2 de agosto de 2028 para los integrados en productos. Aplazar no es cancelar: la transparencia y las obligaciones de los modelos generales siguen como estaban.
- Tu papel importa. Si usas un modelo de un tercero, eres responsable del despliegue. Si lo modificas a fondo o lo comercializas con tu marca, puedes pasar a ser proveedor, con bastantes más obligaciones.
- RGPD, NIS2 y DORA. NIS2 es la directiva europea de ciberseguridad para sectores esenciales y DORA el reglamento de resiliencia digital del sector financiero. La IA entra en tu evaluación de impacto, en la gestión de incidentes y en la gestión de terceros, incluidos los proveedores de modelos y de hardware.
- En España, el ENS para el sector público y sus proveedores, y la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial) como autoridad supervisora.
10. Mi plan para los primeros 90 días
| Etapa | Qué haría |
|---|---|
| Días 1–30 · Ordenar la casa | Inventario de casos de uso, clasificación según el riesgo del Reglamento de IA, política de IA, revisión de licencias, primera DPIA y el juego de preguntas de prueba |
| Días 31–60 · Prueba segura | Granite 4.1 8B o Gemma 4 sobre vLLM, búsqueda documental con permisos, SSO y gateway, filtros de entrada y salida, registros en el SIEM y primera medición de fidelidad |
| Días 61–90 · Pasar a producción | Comparativa con un modelo mayor (Mistral), pruebas de ataque, declaración de aplicabilidad conjunta 27001 + 42001, procedimiento de incidentes de IA y un cuadro de mando para la dirección |
Glosario rápido
Las siglas y términos que aparecen en el artículo
- RAG (Retrieval-Augmented Generation, generación aumentada por recuperación). Técnica presentada en 2020 por investigadores de Facebook AI Research (hoy Meta) en el artículo de Patrick Lewis y otros. Antes de responder, el sistema busca en tus documentos y le entrega al modelo los fragmentos relevantes. Así responde con tu información actual y puede citar la fuente.
- LLM (Large Language Model, modelo grande de lenguaje). El tipo de modelo que hay detrás de ChatGPT, Gemini, Mistral o Granite.
- Open-weight (pesos abiertos). El fabricante publica el modelo entrenado para que puedas descargarlo y ejecutarlo, aunque no siempre publique los datos de entrenamiento.
- Parámetros. Los valores internos que el modelo aprende al entrenarse. Más parámetros suele significar más capacidad, pero también más hardware. En español, “un billón” son un millón de millones.
- MoE (Mixture of Experts, mezcla de expertos). Arquitectura en la que, para cada palabra, solo trabaja una parte del modelo. Por eso se habla de parámetros “totales” y “activos”.
- GPU (Graphics Processing Unit). Tarjeta de cálculo que ejecuta los modelos; su memoria se llama VRAM.
- vLLM, SGLang, Ollama. Programas gratuitos para servir modelos en tus propios equipos.
- TLS / mTLS. Cifrado de las comunicaciones; en mTLS ambos extremos se identifican con certificado.
- SSO / MFA. Inicio de sesión único / autenticación con más de un factor.
- DLP (Data Loss Prevention). Controles que detectan y bloquean la salida de datos sensibles.
- SIEM (Security Information and Event Management). Plataforma que centraliza los registros de seguridad para detectar incidentes.
- Guardrails. Filtros que revisan lo que entra y sale del modelo.
- Red teaming. Pruebas de ataque controladas para encontrar debilidades antes que un atacante.
- AI-BOM (AI Bill of Materials). Inventario de los componentes de un sistema de IA: modelo, versiones, datos y librerías.
- OWASP (Open Worldwide Application Security Project). Fundación sin ánimo de lucro que publica guías de seguridad, como el Top 10 de riesgos para aplicaciones LLM.
- SoA (Statement of Applicability, declaración de aplicabilidad). Documento que indica qué controles aplicas y por qué excluyes los demás.
- RACI. Matriz que define, para cada tarea, quién la hace, quién responde, a quién se consulta y a quién se informa.
- DPO / CISO. Delegado de protección de datos / responsable de seguridad de la información.
- SBOM / SCA. Lista de componentes de software / análisis de esos componentes para detectar vulnerabilidades y licencias.
- Model card (ficha del modelo). Documento que resume para qué sirve un modelo, cómo se evaluó y cuáles son sus limitaciones.
- Deriva. Pérdida progresiva de calidad de un sistema de IA porque cambian los datos o el contexto en el que trabaja.
- ISO/IEC 42001. Norma internacional para un sistema de gestión de la IA. ISO/IEC 27001, su equivalente para la seguridad de la información (SGSI).
- AI Act. Reglamento Europeo de Inteligencia Artificial (UE 2024/1689).
- RGPD / DPIA (EIPD). Reglamento General de Protección de Datos / evaluación de impacto en protección de datos.
- ENS / CCN / AESIA. Esquema Nacional de Seguridad / Centro Criptológico Nacional / Agencia Española de Supervisión de la IA.
- NIS2 / DORA. Directiva europea de ciberseguridad / Reglamento europeo de resiliencia operativa digital del sector financiero.
Para terminar
Hoy es perfectamente posible tener un asistente potente, privado y auditable sin enviar un solo dato a ningún proveedor externo de IA. Pero si me quedo con una idea, es esta: elegir el modelo es la parte fácil. Lo que de verdad marca la diferencia es todo lo que lo rodea: identidad, permisos en la búsqueda, filtros, trazabilidad y un sistema de gestión que mida y mejore con el tiempo.
El modelo lo puedes cambiar en una tarde. El gobierno de la IA es lo que se queda.
Fuentes
- Mistral AI: Mistral Large 4 is now open weight
- IBM: Granite e ISO/IEC 42001
- IBM: Granite 4.0 y modelos firmados criptográficamente
- Google Open Source Blog: Gemma 4 con Apache 2.0
- eWEEK: Qwen3.8-27B bajo Apache 2.0
- MorphLLM: mejores modelos abiertos (octubre 2026)
- BenchLM: modelos abiertos frente a cerrados
- InfoQ: Granite 4 y la licencia de Llama 4 en la UE
- The Decoder: Apertus, un modelo totalmente abierto
- Cloud Security Alliance: Digital Omnibus y plazos de alto riesgo
- CMS: qué cambia el Digital Omnibus
- Lewis et al. (2020): Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, el artículo que dio origen a RAG
- OWASP Top 10 para aplicaciones LLM
Este artículo es divulgativo y refleja mi opinión profesional. No sustituye al asesoramiento jurídico: revisa siempre las licencias y la normativa con tu área legal y de cumplimiento.
Comentarios
Publicar un comentario