De quince taxonomías a una: un método para construir un modelo canónico de riesgo capaz de juzgar de verdad un escenario

El problema

Cualquier producto de seguridad que quiera decir “estos son los riesgos de tu despliegue de IA, y esto es lo que dicen los estándares al respecto” se enfrenta a un problema de traducción antes de poder hacer cualquier otra cosa.

Los frameworks de seguridad y gobierno de IA — OWASP Top 10, MITRE ATT&CK/ATLAS, NIST AI RMF, NIST CSF, ISO/IEC 27001/42001/23894, la Ley de IA de la UE, CIS Controls, las guías de ENISA, y otros — no comparten un modelo de datos común. Cada uno nombra sus propias unidades de conocimiento citable con su propio vocabulario.

OWASP tiene categorías de riesgo. MITRE tiene técnicas y mitigaciones. NIST tiene subcategorías organizadas bajo funciones. ISO tiene cláusulas y controles de anexo. La Ley de IA de la UE tiene artículos, considerandos y anexos. Ninguno de estos encaja de forma limpia con los demás, y ninguno encaja de forma limpia con lo que un motor de evaluación realmente necesita para razonar: un conjunto fijo y reducido de tipos de entidad con semántica de evaluación bien definida.

Un ejemplo mínimo hace tangible ese desajuste:

OWASP LLM01              MITRE ATLAS AML.T0051
"Categoría de riesgo"     "Técnica"
        │                         │
        └────────────┬────────────┘
                      ▼
             Modelo canónico
                  Riesgo

Dos frameworks distintos, dos vocabularios nativos distintos (“categoría de riesgo,” “técnica”) — pero ambos describen algo que tu motor, en última instancia, necesita tratar como una sola cosa: un riesgo. El modelo canónico es lo que hace posible ese colapso sin perder lo que cada fuente realmente decía.

Si intentas importar estos frameworks directamente — una integración a medida por cada estándar — obtienes una explosión de lógica ad hoc. Peor aún, obtienes una inconsistencia silenciosa: el mismo riesgo subyacente (digamos, la inyección de prompts) acaba representado de forma distinta según qué estándar lo describiera primero, porque tu modelo absorbió el vocabulario de ese estándar en vez de un vocabulario de diseño propio.

La alternativa — construir de antemano un único modelo canónico y forzar a cada framework a encajar en él — falla por una razón distinta. Es fácil sub-observar: diseñar el vocabulario canónico mirando uno o dos frameworks (los primeros que vas a integrar) y perder categorías enteras que solo se hacen visibles al mirar el panorama completo. También es fácil sobre-diseñar: seguir añadiendo tipos de entidad cada vez que un framework nuevo no encaja limpiamente, hasta que el modelo es tan complicado e inconsistente como los frameworks que se suponía que iba a unificar.

El método que sigue es lo que realmente funcionó para resolver esto — no como un parche puntual, sino como una disciplina repetible para ir añadiendo nuevos frameworks con el tiempo sin volver a litigar las mismas decisiones de diseño.

La idea central: separar tres planos que normalmente se confunden

El modo de fallo que más daño causa es confundir tres preguntas que son lógicamente independientes:

1. ¿Qué tipo de elemento citable contiene realmente este framework? — una pregunta puramente observacional. Simplemente estás leyendo el estándar y catalogando lo que él mismo nombra como algo distinto y referenciable individualmente.
2. ¿En qué se traduce ese tipo de elemento, una vez importado? — una pregunta de diseño/política. Dado que un framework llama a algo “técnica,” ¿en qué entidad debería convertirse dentro de tu sistema?
3. ¿Tiene tu modelo canónico sitio para esa entidad, o el propio modelo necesita cambiar? — una pregunta arquitectónica, la más cara de responder mal, porque los modelos canónicos son difíciles de revertir una vez que otros sistemas dependen de ellos.

Casi todos los errores en este tipo de trabajo vienen de responder a la pregunta 2 o 3 mientras todavía se está intentando responder a la pregunta 1 — decidir qué “es” un framework preguntando en qué debería convertirse, en vez de establecer primero qué es realmente en sus propios términos.

La solución es procedimental: responder a las tres preguntas en secuencia estricta, y no dejar que una respuesta de una etapa posterior se filtre hacia atrás en una etapa anterior.

Etapa 1 — Documentar la taxonomía de cada framework, con sus propias palabras

Para cada framework que planees soportar, inventaría los tipos de elemento citable que define, usando su propia terminología, y separa explícitamente dos cosas que es fácil confundir:

• Items hoja — unidades de conocimiento con una identidad estable y citable (un ID, una cláusula numerada, un código). Son las cosas que un tercero realmente referenciaría: “OWASP LLM01,” “MITRE ATLAS AML.T0051,” “Artículo 9 de la Ley de IA de la UE.”
• Constructos estructurales — contenedores y mecanismos de selección: tácticas, funciones, categorías, capítulos, familias, niveles, perfiles, líneas base. Estos organizan los items hoja; no son en sí mismos items. Una táctica agrupa técnicas de la misma forma en que un capítulo agrupa cláusulas — es un estante, no un libro.

Esta distinción por sí sola elimina una gran clase de errores. Es tentador tratar un contenedor como una versión ligera de un item hoja — “esta Táctica es como una especie de riesgo” — porque los contenedores a menudo llevan nombres con significado. Resiste esa tentación.

Si algo existe únicamente para agrupar otras cosas citables, es estructura, y pertenece a la jerarquía de tu snapshot, no al vocabulario de tipos de item.

Fija la versión exacta de cada framework que inventaríes, y vuelve a verificarla en cada importación real. Los estándares se revisan; una taxonomía derivada contra la versión del año pasado puede desviarse silenciosamente de lo que realmente estás importando.

Etapa 2 — Derivar un vocabulario común observando convergencia, no eligiendo un favorito

Una vez que tienes quince (o las que sean) inventarios independientes, búscales en conjunto géneros — categorías de item que se repiten a través de varios frameworks bajo nombres distintos. Un género se gana un sitio en tu vocabulario común cuando varios frameworks lo ejercen demostrablemente como algo citable individualmente y de primera clase — no cuando simplemente suena parecido a algo que ya has decidido conservar.

Dos disciplinas hacen que este paso sea fiable.

Nombra el género por observación mayoritaria, no por el primer framework que miraste. Si seis frameworks llaman a algo “control” y solo uno lo llama “mitigación,” el nombre compartido debería ser “control.” Esto suena obvio una vez dicho, pero es el sesgo más común en este tipo de ejercicio: el estándar que se analiza primero (normalmente porque es el más detallado técnicamente, o el primero en la hoja de ruta de adopción) acaba donando su vocabulario a todo lo demás por defecto. Nombrar por mayoría, deliberadamente, rompe ese sesgo.

Confía en las distinciones dentro de un mismo framework más que en las impresiones entre frameworks. La evidencia más sólida de que dos géneros candidatos son genuinamente distintos — y no solo dos nombres para lo mismo — no viene de comparar frameworks entre sí, sino de encontrar un único framework que mantenga ambos como conjuntos citables separados internamente. Si un estándar tiene tanto “cláusulas” (obligaciones de proceso) como “controles de anexo” (salvaguardas concretas) como dos listas numeradas distintas dentro del mismo documento, ese framework ya ha hecho el trabajo de desambiguación por ti. Cuando varios frameworks independientes trazan la misma frontera interna, la taxonomía debería preservarla en vez de colapsarla en “prescripción” para conseguir un vocabulario más pequeño.

Vigila también los géneros que se vuelven invisibles porque ya estás pensando en destinos. Es muy fácil, mientras inventarías frameworks, filtrar inconscientemente por “cosas que encajan con un tipo de entidad que ya tengo.” El contenido interpretativo, no vinculante — notas al pie, considerandos, guías de implementación, secciones de discusión — a menudo se salta de esta forma, porque nada en tu modelo canónico lo reclama obviamente.

Pero si un framework cita ese contenido con una identidad estable (considerandos numerados que se citan rutinariamente en la práctica legal, por ejemplo), es conocimiento citable real, sepas o no todavía qué hacer con él. Un género es real porque los frameworks lo ejercen, no porque tu modelo ya tenga un sitio para él.

Los géneros con poco respaldo entre frameworks merecen un escrutinio real, pero el respaldo débil no es una descalificación automática. Si solo un framework de tu conjunto ejerce un género, pero ese framework es un objetivo de adopción de primera prioridad y el género tiene sus propios identificadores estables y citables en la fuente, la decisión honesta es incluirlo — siendo explícito en que su justificación descansa en la fidelidad a esa fuente importante, no en el consenso. La alternativa — fundirlo en un género no relacionado, o eliminar su identidad individual para evitar un slot de vocabulario “desperdiciado” — corrompe tu capacidad de citar ese framework con precisión, que es todo el propósito del ejercicio.

Por último, somete el vocabulario resultante a una prueba de estrés frente a frameworks fuera de tu inventario original. Un vocabulario cerrado que nunca se ha comprobado contra nada más que los frameworks usados para construirlo no está cerrado — está sin probar. Un vocabulario genuinamente estable debería poder absorber unos cuantos frameworks que nunca ha visto sin necesitar una categoría nueva; documenta explícitamente qué categorías observadas-pero-excluidas existen, por qué se excluyeron, y qué condición futura justificaría revisar esa exclusión. “Cerrado, con excepciones documentadas y disparadores explícitos de revisión” es una posición defendible. “Cerrado porque no miramos más” no lo es.

Etapa 3 — Preguntar por separado si el modelo canónico puede absorber lo que encontraste

Solo ahora, con un vocabulario documentado y fundamentado en la observación en la mano, plantea la pregunta arquitectónica: para cada género, ¿pueden tus entidades canónicas existentes representarlo, o hay una brecha real?

Evalúa cada género frente a tres veredictos posibles:

• Absorción natural — una entidad canónica existente ya significa lo mismo. Un género que significa “algo que puede salir mal” encaja limpiamente en una entidad “Riesgo” existente; las variantes internas (un riesgo enmarcado como amenaza, un riesgo enmarcado como debilidad de causa raíz, un riesgo enmarcado como fuente de riesgo organizativo) no necesitan tratamiento separado — son el mismo género descrito con distinto énfasis por distintos autores, y cualquier distinción que importe operativamente puede vivir como un atributo en vez de como un tipo nuevo.

• Una cuestión de política, no una brecha del modelo — el género es real, pero dónde termina depende del contenido del item concreto, no de su género en abstracto, y tus entidades existentes son lo bastante expresivas para albergar cualquier destino que se elija. El contenido interpretativo que aclara otro item, por ejemplo, no necesita su propia entidad canónica — basta con una referencia más una relación con el item que interpreta, e inventar una entidad para “comentario” difuminaría la línea entre conocimiento y anotación.

• Una brecha de modelo genuina — ninguna entidad canónica existente, ni ninguna relación sencilla entre entidades existentes, puede representar el género sin distorsionar su significado. Este es el caso caro, y merece su propia disciplina (más abajo).

El fallo crítico que evitar en esta etapa es hacer lo contrario de lo que causó problemas en la Etapa 1: ahora que por fin se te permite pensar en destinos, es tentador dejar que la conveniencia del destino redefina silenciosamente el vocabulario que acabas de pasar dos etapas derivando honestamente. Mantén el vocabulario fijo. Si un género no encaja, eso es información sobre tu modelo canónico, no licencia para remodelar la taxonomía.

¿Qué gana el sistema con esta separación?

Antes de entrar en los casos más difíciles, merece la pena ser explícito sobre por qué esta disciplina de tres etapas justifica su coste. Mantenidos separados, estos tres planos entregan cuatro beneficios concretos:

• Se pueden añadir frameworks nuevos sin tocar el motor de razonamiento. Como el motor solo evalúa el vocabulario canónico, incorporar el framework número dieciséis es un ejercicio de inventario y traducción, no una reescritura.
• Cada hecho sigue siendo trazable hasta su fuente. Una entidad canónica “Riesgo” puede seguir apuntando a “OWASP LLM01” o al “Artículo 9” — la abstracción no borra la cita.
• Dejan de producirse entidades duplicadas. Cuando la correspondencia de género a entidad es un proceso disciplinado y comprobado, en vez de una suposición ad hoc, el mismo concepto del mundo real no acaba modelado dos veces bajo dos nombres distintos.
• La evolución de los frameworks y la del conocimiento avanzan de forma independiente. Los estándares se revisan, se sustituyen o se reinterpretan; el vocabulario canónico sobre el que razona el motor no tiene que moverse al mismo ritmo que cada uno de esos cambios.

Con esta motivación establecida, la pregunta más difícil es qué ocurre cuando un género genuinamente no encaja todavía en ningún sitio del modelo.

Cuando un género es irreducible: separar “el modelo no puede representar esto” de “el motor no puede razonar sin ello”

El caso más difícil es un género que es demostrablemente real (varios frameworks lo ejercen, posiblemente validado por un estándar independiente fuera de tu lista de frameworks) y demostrablemente irreducible (no colapsa en ninguna entidad canónica existente sin perder su significado). El género técnica de MITRE — un método concreto que usa un adversario, distinto del riesgo que produce, distinto del control que lo mitiga, distinto de cualquier señal de detección — es un ejemplo canónico.

Aquí es donde una segunda confusión causa un daño real: una brecha representacional no es la misma afirmación que una insuficiencia funcional, y solo la segunda justifica cambiar tu modelo central.

Una brecha representacional significa: este género, como concepto, no tiene un lugar en el modelo. Es una afirmación sobre la taxonomía.

Una insuficiencia funcional significa: el motor de evaluación, con el modelo tal como está, produce peores resultados — pierde riesgos reales, produce resultados poco fiables, no puede explicar su razonamiento — porque esa entidad no existe. Es una afirmación sobre el comportamiento del sistema bajo evaluación real.

La primera puede ser cierta mientras la segunda es falsa. Un género puede quedarse permanentemente como puro material de referencia — citable, útil para la trazabilidad, sin aportar nada al razonamiento automatizado — sin que eso sea un defecto. Este es, de hecho, el estado estable correcto para los géneros que están solo débilmente conectados a tu motor de razonamiento: un framework puede nombrar obligaciones o guías interpretativas que tu sistema simplemente cita sin necesitar nunca razonar sobre ellas directamente.

• Enuncia la hipótesis nula — el modelo existente, usado según lo previsto (incluyendo sus campos narrativos y sus relaciones existentes), es funcionalmente suficiente para la tarea de razonamiento en cuestión.
• Enuncia la hipótesis alternativa — el modelo existente no puede expresar el razonamiento requerido con la fidelidad, reproducibilidad y trazabilidad que el producto necesita.
• Diseña un experimento real, no un experimento mental. Reutiliza el arnés de evaluación que el motor de razonamiento ya tenga — no construyas infraestructura nueva solo para zanjar esta cuestión. Selecciona un conjunto de casos de prueba diseñados específicamente para discriminar entre las dos hipótesis: casos donde la respuesta solo es alcanzable reconociendo el patrón que representaría la entidad que falta, y donde los mecanismos de detección literales ya existentes deliberadamente no se disparan.
• Ejecuta dos brazos, no uno. Prueba el modelo tal como está (la hipótesis nula) — pero también prueba la mejor solución alternativa posible alcanzable dentro del modelo existente (documentando el concepto que falta con la entidad existente que más se le acerque, conectada con las relaciones existentes). El segundo brazo existe específicamente para evitar que la entidad nueva se apruebe por pereza de modelado en vez de por una limitación genuina: si la solución alternativa rinde igual de bien, la brecha era puramente representacional, y añadir una entidad nueva solo añadiría coste, no capacidad.
• Preregistra tus métricas y umbrales antes de ejecutar el experimento, no después. Decide qué aspecto tiene “el modelo falló” — detecciones perdidas, falsos positivos, no reproducibilidad entre ejecuciones repetidas, y uno específico que importa más de lo que parece a primera vista: ¿puede la salida del sistema citar algo con una identidad estable, o recae en prosa no estructurada? — antes de ver ningún resultado.
• Vigila el modo de fallo en ambas direcciones. Si el brazo de “mejor solución alternativa” solo tiene éxito convirtiendo una entidad ligera existente en algo que se comporta, estructuralmente, exactamente como la entidad nueva propuesta — evaluable, con relaciones tipadas de facto añadidas — eso no es evidencia de que el modelo existente sea suficiente. Es la entidad nueva disfrazada, sin las garantías de esquema que tendría una entidad real, que es el peor resultado posible: pagas el coste semántico completo del concepto nuevo sin obtener ninguno de los beneficios de integridad de formalizarlo. Por el contrario, si el modelo tal como está resuelve genuinamente los casos de prueba a través de sus campos narrativos existentes, resiste la tentación de añadir la entidad de todos modos “porque sería más elegante” — la elegancia representacional no es, por sí sola, evidencia de un requisito funcional.

Esto convierte un debate que de otro modo se resolvería por antigüedad o por poder de persuasión en algo falsable, y mantiene los cambios de modelo caros y difíciles de revertir supeditados a evidencia real del sistema haciendo trabajo real — no a lo convincente que suene el argumento en abstracto.

Traducir un género en el momento de la importación, sin fijar un destino de antemano

Incluso para los géneros que encajan de forma natural en una entidad existente, resiste la tentación de fijar esa correspondencia como una función rígida y uno-a-uno de la sola etiqueta del género. El mismo concepto subyacente suele describirse de forma distinta según el framework — la misma técnica de ataque puede ser el item hoja del género “técnica” de un framework y, independientemente, el item hoja del género “riesgo” de otro framework, simplemente porque los dos estándares eligieron niveles de abstracción distintos para describir el mismo problema del mundo real.

Si tu lógica de importación asigna “técnica” a un único destino fijo sin importar el contexto, crearás entidades duplicadas cada vez que dos frameworks describan el mismo concepto subyacente en niveles de abstracción distintos — y esa duplicación corrompe todo lo que aguas abajo depende de que tu catálogo canónico tenga exactamente una entidad por concepto del mundo real.

El diseño correcto mantiene la correspondencia género-a-entidad condicionada al contexto en tiempo de ejecución, no fijada a nivel de esquema:

1. Comprueba primero si ya existe una entidad equivalente en tu catálogo antes de crear nada nuevo. Este tiene que ser un primer paso obligatorio y ordenado — nunca crear-y-luego-reconciliar. La reconciliación posterior acepta los duplicados como un estado temporal; comprobar primero evita que lleguen a existir.
2. Recurre a una tabla heurística versionada, parametrizada por la combinación específica de framework de origen y subestructura del item (no solo por el género), para los casos en los que no se encuentra un equivalente y se requiere un juicio genuino. Esto preserva el determinismo — la misma tabla heurística aplicada a la misma importación produce siempre la misma decisión — lo cual importa porque importar frameworks tiene que ser una operación reproducible, no un juicio humano puntual cada vez.
3. Registra cada decisión de traducción — qué regla se disparó, qué equivalencia (si alguna) se detectó, cuál fue el resultado final. Esto es lo que convierte “el sistema decidió X” en algo que un operador puede auditar y, si está mal, corregir de cara al futuro sin tener que rederivar toda la heurística desde cero.

Este diseño mantiene deliberadamente la ambigüedad donde le corresponde — en la lógica de traducción en tiempo de ejecución, evaluada contra el estado real del catálogo — en vez de fingir que no existe metiendo una falsa certeza en el esquema.

Preservando los resultados negativos

El resultado más infravalorado de este tipo de análisis no es la lista de cosas que decidiste construir — es la lista de cosas que deliberadamente decidiste no construir, y por qué. Un debate sobre el modelo canónico que se zanja una vez y luego se olvida se reabre desde cero un año después, con un coste real, por alguien que no tiene forma de saber que ya se había zanjado.

Todo cambio de modelo rechazado o pospuesto merece un registro breve y permanente, separado del análisis de trabajo que lo produjo, que contenga exactamente tres cosas:

• Qué se consideró — la entidad o relación específica que se propuso.
• Por qué no se adoptó — brecha representacional sin necesidad funcional demostrada; el planteamiento de hipótesis y falsación si se usó alguno; cualquiera que fuera el razonamiento real.
• La condición que reabriría la cuestión — un disparador específico y comprobable, no un vago “revisar más adelante.” “Si el motor de razonamiento incorpora un modo de evaluación de cumplimiento” es un disparador. “Reconsiderar si hace falta” no lo es.

Este registro es documentación de arquitectura, no una lista de tareas — es conocimiento sobre la forma del dominio que sobrevive a cualquier pieza específica de trabajo que motivó el análisis. Cualquiera que toque el modelo canónico más adelante debería poder encontrarlo y entender, en menos de un minuto, si una idea concreta ya se probó y se descartó explícitamente, y bajo qué circunstancias vuelve a merecer la pena intentarla.

Por qué esto importa específicamente para la evaluación de escenarios

Nada de esto es trabajo de taxonomía abstracto por sí mismo. Todo el propósito de construir un único modelo canónico a partir de muchos vocabularios de framework incompatibles es que un motor de evaluación de escenarios solo puede razonar de forma fiable sobre un conjunto fijo y bien entendido de tipos de entidad con semántica de evaluación clara.

Un motor que tiene que tratar su lógica como un caso especial por cada framework de origen — “si este hecho viene de MITRE, razona sobre él de una forma; si viene de ISO, razona sobre él de otra” — no puede dar una respuesta reproducible y explicable a “¿aplica este riesgo a este escenario, y por qué?” Un modelo canónico le da al motor un vocabulario consistente contra el que evaluar, sin importar qué estándar suministró originalmente el conocimiento subyacente; el trabajo de traducción descrito arriba es lo que hace que ese vocabulario sea fiable en vez de meramente conveniente.

La disciplina es lo que hace que el resultado sea duradero: observa antes de traducir, traduce antes de juzgar el modelo, y nunca dejes que un cambio de modelo ocurra sin que la carga de la prueba recaiga en una necesidad demostrada en vez de en la pulcritud representacional.

Los frameworks seguirán evolucionando — nuevas versiones, nuevos estándares, nuevo lenguaje regulatorio. Esta arquitectura es lo que permite que esa evolución constante siga siendo un problema ajeno al motor: los frameworks nuevos se incorporan mediante inventario y traducción, no mediante una reescritura del motor de razonamiento, porque el vocabulario canónico que hay debajo se construyó para permanecer estable mientras todo lo que lo alimenta sigue cambiando.