Lo esencial
- El riesgo más material de los modelos de IA generativa es la salida infiel, que el NIST denomina formalmente confabulación y que los equipos operativos conocen como alucinación.
- La alucinación domina por dos motivos: es el modo de fallo más reportado en entornos de producción y amplifica cualquier otro riesgo, porque un texto fluido pero falso esconde sesgos, fugas de datos e infracciones de propiedad intelectual hasta hacerlos más difíciles de detectar.
- La taxonomía de referencia defendible es NIST AI 600-1: doce riesgos específicos de la IA generativa o agravados por ella, cada uno asignado a las cuatro funciones del marco NIST de gestión de riesgos (Govern, Map, Measure, Manage).
- En el Reglamento europeo de IA, el mismo riesgo aparece en el artículo 9 (sistema de gestión de riesgos), el artículo 13 (transparencia), el artículo 15 (exactitud, robustez y ciberseguridad), el artículo 50 (etiquetado de contenidos sintéticos) y los artículos 53 y 55 (obligaciones aplicables a los modelos de IA de propósito general y a los que presentan riesgo sistémico).
- Un patrón de gobernanza factible se estructura en cuatro capas: evaluación previa al despliegue, anclaje mediante recuperación documental con umbrales de confianza, mediación de salidas con presencia humana en flujos críticos y vigilancia posterior al despliegue con notificación de incidentes.
El riesgo principal: la salida infiel (alucinación)
Si debe elegir una sola respuesta, la respuesta es alucinación: la tendencia de un modelo generativo a producir contenidos que suenan seguros pero resultan factualmente erróneos, fabricados o no sustentados por ninguna fuente que el modelo haya recibido. El NIST emplea el término confabulación en su perfil dedicado a la IA generativa, en parte para subrayar el carácter estructural y no accidental del fenómeno: el modelo no miente, muestrea de una distribución de probabilidad que también asigna masa a enunciados falsos (NIST AI 600-1).
Tres razones convierten este riesgo en el riesgo dominante en 2026.
La primera atiende a la frecuencia en producción. La investigación académica que cartografía incidentes reales de IA generativa identifica la salida infiel como el modo de fallo más reportado en sistemas desplegados, por delante del sesgo, la fuga de datos o la inyección de prompt (arXiv 2505.22073). Varios precedentes ya actúan como jurisprudencia implícita en el razonamiento de los responsables de cumplimiento: la decisión Air Canada, en la que un tribunal canadiense atribuyó responsabilidad a la aerolínea por una política de reembolso inventada por su asistente conversacional; la sanción Mata contra Avianca, mediante la cual un juez federal de Nueva York sancionó a abogados que presentaron un escrito con seis sentencias enteramente ficticias generadas por ChatGPT; y los expedientes australianos de 2024 y 2025 en los que letrados fueron deferidos a sus colegios profesionales por citaciones alucinadas similares.
La segunda razón es el efecto de composición. Un incidente de sesgo en un sistema determinista se manifiesta como un desvío medible en los resultados. El mismo incidente en un modelo que alucina puede ocultarse dentro de un párrafo fluido y de aspecto autorizado. Lo mismo ocurre con la confidencialidad: un resumen infiel de un historial clínico puede inventar un diagnóstico, mezclando exposición real y fabricada de datos. La alucinación es el modo de fallo que dificulta la auditoría de los demás modos de fallo.
La tercera razón se refiere al peso regulatorio. El Reglamento UE no emplea la palabra alucinación, pero obliga a los proveedores de sistemas de IA de alto riesgo a diseñar los sistemas para que alcancen un nivel adecuado de exactitud, robustez y ciberseguridad y lo mantengan a lo largo de todo su ciclo de vida (artículo 15). Además, los proveedores deben facilitar instrucciones de uso que expongan el desempeño y las limitaciones conocidas (artículo 13). Para los modelos de propósito general, las obligaciones aumentan en el artículo 53; para los modelos con riesgo sistémico, el Código de buenas prácticas GPAI de la Oficina europea de IA exige un marco completo de seguridad (Código GPAI, julio de 2025).
Un riesgo es el titular. Doce constituyen la estructura subyacente.
El panorama completo: la taxonomía en 12 categorías del NIST
Por qué NIST AI 600-1 sirve como referencia
La mayoría de los artículos competidores enumera ocho, diez o doce riesgos sin una columna vertebral común, lo que dificulta la comparación y, más aún, la operacionalización. NIST AI 600-1, publicado el 26 de julio de 2024, cubre ese vacío. Elaborado por un grupo de trabajo público con más de 2.500 contribuyentes, identifica 12 riesgos específicos de la IA generativa o agravados por ella. Cada riesgo está asignado a las cuatro funciones del NIST AI RMF 1.0 (Govern, Map, Measure, Manage), con más de 200 acciones recomendadas distribuidas entre ellas.
Los 12 riesgos, mapeados al Reglamento UE y al Top 10 LLM de OWASP
| Riesgo NIST AI 600-1 | Definición breve | Ancla en el Reglamento UE | Equivalente OWASP LLM Top 10 (2025) |
|---|---|---|---|
| CBRN | Reducción de la barrera a capacidades químicas, biológicas, radiológicas o nucleares | Art. 51, 55 (GPAI con riesgo sistémico) | (ninguno) |
| Confabulación (alucinación) | Generación segura pero infiel de hechos, citas o código | Art. 13, 15 | LLM09 Desinformación |
| Contenidos peligrosos, violentos u odiosos | Salidas que incitan, enseñan o normalizan el daño | Art. 5, 50 | LLM05 Manejo inadecuado de salidas |
| Protección de datos | Memorización y divulgación de datos personales o sensibles | Art. 10, 26 y RGPD | LLM02 Divulgación de información sensible |
| Impactos ambientales | Huella energética, hídrica y de carbono del entrenamiento y la inferencia | Considerando 142, art. 53(1)(d) | (ninguno) |
| Sesgo dañino y homogeneización | Desvío sistemático según atributos protegidos | Art. 10, 15, 27 | (parcial, LLM09) |
| Configuración humano-IA | Niveles de automatización mal calibrados y dependencia excesiva | Art. 14 (supervisión humana) | LLM06 Agencia excesiva |
| Integridad de la información | Contenidos mediáticos fabricados, deepfakes, desinformación sintética a escala | Art. 50 (etiquetado de contenidos sintéticos) | LLM09 Desinformación |
| Seguridad de la información | Superficies de ataque propias de la IA, incluidas las basadas en prompts | Art. 15(5) ciberseguridad | LLM01 Inyección de prompts, LLM04 Envenenamiento de datos y modelos |
| Propiedad intelectual | Vulneraciones en datos de entrenamiento y reproducciones en salidas | Art. 53(1)(c) resumen de los datos de entrenamiento | LLM03 Cadena de suministro |
| Contenidos obscenos, degradantes o abusivos | CSAM, imágenes íntimas no consentidas, material de abuso | Art. 5 y reglamento CSAM | LLM05 Manejo inadecuado de salidas |
| Cadena de valor e integración de componentes | Propagación del riesgo del proveedor del modelo fundacional al desplegador | Art. 25, 53 | LLM03 Cadena de suministro |
La tabla cumple dos funciones a la vez. Para un equipo anclado en Estados Unidos preserva el vocabulario NIST ya en uso. Para un equipo anclado en Europa muestra qué obligación del regulador se vincula a cada riesgo. La columna OWASP construye el puente con los arquitectos de seguridad, que adoptan en general el LLM Top 10 v2025 como lengua compartida.
Cómo usar la tabla para priorizar
La taxonomía no es una lista de comprobación. El trabajo real está en la priorización. Para cada riesgo, plántese dos preguntas: cuánta probabilidad tiene este fallo dado el diseño de su sistema y su contexto de despliegue, y qué gravedad alcanza si se produce. Un asistente de apoyo a la decisión clínica debería priorizar confabulación, sesgo dañino y configuración humano-IA. Un asistente de generación de código debería priorizar confabulación, seguridad de la información y propiedad intelectual. Un chatbot de gran consumo debería priorizar contenidos peligrosos, integridad de la información y protección de datos. La taxonomía permite que cada equipo parta del mismo vocabulario y llegue a órdenes de prioridad distintos.
Qué hace diferente el perfil de riesgo de la IA generativa
Tres propiedades de la IA generativa invalidan las hipótesis sobre las que se asienta la gestión de riesgos aplicativa clásica.
Escala y velocidad. Un único prompt produce contenido a escala de Internet. Un asistente de cliente mal configurado puede publicar miles de compromisos de reembolso incorrectos antes de que alguien lo detecte, como experimentó Air Canada. El radio de impacto de un mal despliegue ya no está limitado por el volumen de usuarios sino por el volumen de generación.
Salidas estocásticas. El software clásico dispone de un oráculo de prueba determinista: dada una entrada, la salida correcta está fijada y es verificable. Los modelos generativos muestrean de una distribución. El mismo prompt produce salidas distintas entre ejecuciones, y el mismo modelo se comporta de forma diferente tras un ajuste fino rutinario. Esta propiedad rompe los tests unitarios, los tests de regresión y la mayoría de los criterios de aceptación escritos para software determinista. La evaluación debe migrar de «la salida es igual a X» a «la salida queda dentro de una distribución aceptable», pregunta más difícil de instrumentar.
Capacidades emergentes y opacidad de la cadena de valor. Pueden aparecer a gran escala comportamientos ausentes en los datos de entrenamiento, a veces sin previo aviso entre versiones. A la vez, la responsabilidad es estratificada: un proveedor de modelo fundacional lo entrena, un integrador lo afina y lo encapsula, un desplegador lo pone frente a los usuarios. El Reglamento UE atiende esta cadena con el artículo 25 y con las obligaciones GPAI del artículo 53, pero en la práctica el desplegador sigue siendo propietario del fallo visible al usuario. El Código GPAI traza una línea adicional en el umbral de riesgo sistémico de 10^25 operaciones en coma flotante para el entrenamiento, por encima del cual los proveedores deben mantener un Marco de Seguridad y Protección con evaluaciones de modelo y ejercicios de red teaming.
Gobernar el riesgo dominante: un patrón de cuatro capas
Una postura de gobernanza defendible para el riesgo dominante encaja con las funciones Measure y Manage del marco NIST y con los artículos 9, 14, 15, 17 y 72 del Reglamento UE.
Capa 1: evaluación previa al despliegue
Antes de que un sistema generativo llegue a los usuarios, debería superar una batería de evaluación documentada que cubra sus modos de fallo previstos. Para la confabulación, esto significa adoptar puntos de referencia dedicados (TruthfulQA, HaluEval, evaluaciones de dominio construidas sobre su propia verdad de base), prompts de red team diseñados para provocar citaciones fabricadas y pruebas adversariales inspiradas en técnicas de MITRE ATLAS. El NIST AI RMF Playbook describe la función Measure en términos operativos; el artículo 15 del Reglamento UE codifica la obligación al exigir que los sistemas de alto riesgo se diseñen y desarrollen para alcanzar un nivel adecuado de exactitud, robustez y ciberseguridad (artículo 15). En España, las orientaciones de la AESIA y las guías de la AEPD sobre tratamientos automatizados componen un marco operativo útil para incluir en este punto del ciclo.
Capa 2: anclaje por recuperación documental y umbrales de confianza
El patrón arquitectónico que reduce de forma más fiable la alucinación en tiempo de ejecución es la generación aumentada por recuperación con anclaje estricto. El modelo se obliga a responder a partir de documentos recuperados, con citación explícita, y a abstenerse cuando la confianza de la recuperación cae por debajo de un umbral configurado. El modo de fallo pasa de «responder mal» a «rehusar responder», transición mucho más barata de operar. El umbral de confianza también es uno de los pocos patrones que cumplen el deber de transparencia del artículo 13, que exige que el diseño permita a los usuarios interpretar correctamente la salida del sistema.
Capa 3: mediación de salidas
En flujos críticos, la recuperación no basta. La mediación añade una capa de validación entre el modelo y el usuario: un segundo modelo verifica la salida del primero, un validador basado en reglas impone restricciones estructurales, o una persona revisa la salida antes de su ejecución. La elección del punto de mediación depende del impacto. Las decisiones clínicas, jurídicas y financieras exigen una persona en el bucle. Las salidas informativas pueden tolerar solo controles automatizados. Esta elección materializa el artículo 14 (supervisión humana): los proveedores deben diseñar los sistemas de alto riesgo para que personas físicas puedan supervisarlos con eficacia y prevalecer sobre sus salidas.
Capa 4: vigilancia posterior al despliegue y notificación de incidentes
Nada en las capas 1 a 3 capta la deriva que emerge solo después del despliegue, cuando los prompts se separan del conjunto de evaluación y los usuarios descubren casos límite no previstos. El artículo 72 del Reglamento UE codifica la vigilancia poscomercialización y el artículo 73 fija las obligaciones de notificación de incidentes graves. La definición de trabajo de la OCDE de incidente de IA aporta vocabulario compartido (OECD AI Paper No. 16), y la función Manage del marco NIST enumera las prácticas operativas: evaluación viva contra puntos de referencia rodantes, bucles de retroalimentación con usuarios, detección de anomalías en las distribuciones de entrada y un proceso maduro de respuesta a incidentes propiedad de una función nombrada en la organización.
Preguntas frecuentes
¿Cuáles son los cuatro tipos de riesgo de IA? La división en cuatro más citada se apoya en las características de IA confiable del marco NIST. Las funciones Govern, Map, Measure y Manage describen el ciclo de vida, mientras que las características de confiabilidad agrupan los riesgos en cuatro categorías prácticas: riesgos de seguridad y protección, riesgos de equidad y sesgo, riesgos de transparencia y rendición de cuentas, y riesgos de protección y gobernanza de datos. Otras taxonomías (OCDE, categorías de riesgo del Reglamento UE, ISO 23894) parten de cortes distintos. Para la toma de decisiones operativa, la taxonomía más fina en 12 riesgos de NIST AI 600-1 resulta más útil que cualquier modelo de cuatro cubetas.
¿Cuál es la preocupación principal en el uso de la IA generativa? La preocupación principal es la salida infiel: el modelo entrega una respuesta segura que es falsa, fabricada o no respaldada por evidencia. Las consecuencias concretas van desde la responsabilidad civil cuando un asistente tergiversa la política corporativa, las sanciones profesionales cuando citaciones fabricadas terminan en escritos judiciales, el daño reputacional cuando contenido sintético se toma por reportería auténtica, hasta el daño clínico o financiero cuando se sigue una recomendación alucinada. La preocupación no es teórica: entre los precedentes documentados figuran el caso Air Canada y la sanción Mata contra Avianca.
¿Qué preocupación afecta específicamente a la IA generativa en el desarrollo de software? La preocupación más aguda en el desarrollo de software es la generación de código inseguro. Los asistentes de codificación producen sin reparos fragmentos que importan bibliotecas obsoletas, codifican credenciales en duro, omiten la validación de entradas o reproducen patrones vulnerables memorizados de los datos de entrenamiento. OWASP encuadra la familia en LLM05 Manejo inadecuado de salidas y LLM01 Inyección de prompts; el NIST SP 800-218A extiende el Secure Software Development Framework al desarrollo asistido por IA. Los controles concretos incluyen revisión obligatoria del código generado por IA, escaneo de secretos, control de dependencias y patrones de rechazo cuando se solicita al asistente la generación de código crítico en seguridad.
¿Cómo regula el Reglamento UE específicamente la IA generativa? El Reglamento UE aborda la IA generativa en tres planos. El artículo 50 fija obligaciones de transparencia para contenidos sintéticos (etiquetado de deepfakes, marcas legibles por máquina). El artículo 53 establece obligaciones de base para los proveedores de modelos de IA de propósito general: documentación técnica, política de derechos de autor, resumen de los datos de entrenamiento y asistencia a proveedores aguas abajo. El artículo 55 añade deberes para los modelos con riesgo sistémico: evaluaciones de modelo, pruebas adversariales, notificación de incidentes graves a la Oficina europea de IA y ciberseguridad. El Código GPAI operacionaliza los artículos 53 y 55 para los proveedores que superan el umbral de 10^25 FLOPs de entrenamiento.
¿Qué distingue al sesgo de la alucinación? El sesgo es un desvío sistemático de las salidas según atributos protegidos o grupos: el modelo se inclina más a recomendar un candidato masculino, más a reconocer mal un rostro de piel oscura, más a producir un estereotipo. La alucinación es la generación infiel: el modelo inventa una citación, una política de reembolso, una persona, una causa. Ambos aparecen en NIST AI 600-1 como riesgos distintos y requieren remedios distintos: el sesgo se aborda mediante la curaduría de conjuntos de datos, evaluaciones de equidad y auditorías de resultados; la alucinación se aborda mediante anclaje por recuperación, umbrales de confianza y mediación de salidas.
¿Hay marcos de gobernanza diseñados específicamente para la IA generativa? Sí. Los cuatro más operativos a la fecha son NIST AI 600-1 (Estados Unidos, julio de 2024), el Código de buenas prácticas GPAI (Unión Europea, julio de 2025), OWASP Top 10 for LLM Applications (industria, noviembre de 2024) y MITRE ATLAS (industria, en evolución). NIST AI 600-1 es la taxonomía canónica con su catálogo de acciones. El Código GPAI operacionaliza el Reglamento UE para proveedores de propósito general. OWASP aporta la lista de vulnerabilidades del lado del desarrollador. MITRE ATLAS cataloga las técnicas adversariales. Combinados, cubren taxonomía, operacionalización regulatoria, seguridad aplicativa y modelado de amenazas.
¿Los modelos más grandes resolverán la alucinación? Probablemente no por escala. Los modelos más grandes reducen ciertos tipos de alucinación y amplifican otros, sobre todo afirmaciones seguras en dominios poco representados durante el entrenamiento. La posición académica seria en 2025 sostiene que la alucinación es intrínseca a la generación autorregresiva y debe gobernarse a nivel de sistema, mediante anclaje, mediación y vigilancia, en lugar de esperarse a nivel de modelo (arXiv 2504.08526).
Conclusión
Si necesita una sola respuesta para llevar a un examen, a una reunión de dirección o a una revisión de proveedores, la respuesta es esta: el principal riesgo de los modelos de IA generativa es la salida infiel, también llamada alucinación o confabulación. Si necesita defender esa respuesta u operacionalizarla, debajo encontrará un paisaje de doce riesgos en la taxonomía NIST AI 600-1, cada uno anclado en artículos concretos del Reglamento UE y gobernable mediante un pequeño conjunto de patrones arquitectónicos comprendidos. El error frecuente consiste en tratar los riesgos uno a uno. La oportunidad consiste en adoptar una taxonomía, mapearla sobre una biblioteca de controles y ejecutar el patrón de cuatro capas en un bucle de mejora continua.
En AI Sigil entregamos un registro de riesgos premapeado a NIST AI 600-1 y a las obligaciones de alto riesgo y GPAI del Reglamento UE, con controles por categoría y recolección de evidencias lista para auditoría. El riesgo es una parte del trabajo. La otra parte consiste en mantenerlo bajo gobierno.