Embeddings sin matemáticas: cómo funciona la búsqueda semántica y qué debe auditarse

Un empleado pregunta a un asistente interno: “¿Qué concluimos el año pasado sobre el Proyecto Atlas?”. El sistema responde en segundos y cita un hallazgo de auditoría todavía confidencial. La respuesta es pertinente. El problema es que el usuario nunca debió verla.

Ese escenario explica por qué los embeddings importan a auditoría. No son solo una técnica para mejorar búsquedas. En muchas aplicaciones de IA empresarial, son parte de la capa que decide qué información se considera relevante y qué contenido llega al modelo. Cuando esa capa falla, el resultado puede ser una respuesta pobre; cuando falla el control de acceso, puede convertirse en una exposición de información.

La idea central es sencilla: un sistema de recuperación debe responder dos preguntas distintas: “¿esto es relevante?” y “¿este usuario puede verlo?”. Los embeddings ayudan con la primera. Nunca deben sustituir la segunda.

Qué es un embedding, sin entrar en matemáticas

Un embedding es una representación numérica de contenido diseñada para conservar relaciones útiles entre elementos. En lugar de tratar una frase solo como una cadena de palabras, un modelo la convierte en una representación que permite comparar su significado aproximado con el de otras frases, documentos, imágenes u objetos, según el tipo de modelo utilizado.

Pensemos en un mapa conceptual. “Segregación de funciones en cuentas por pagar” debería quedar más cerca de “conflicto de roles en pagos a proveedores” que de “política de vacaciones”. El sistema no necesita que ambos textos compartan exactamente las mismas palabras para reconocer que están relacionados.

Por eso los embeddings habilitan la búsqueda semántica. La documentación técnica de Google AI describe precisamente ese uso: transformar contenido en representaciones numéricas para tareas como búsqueda semántica, recuperación, clasificación y agrupamiento.

Esto no significa que el sistema “entienda” el contenido como una persona. La representación refleja patrones aprendidos por el modelo y puede producir coincidencias excelentes, mediocres o engañosas. Para auditoría, esa limitación es importante: similitud semántica no equivale a relevancia de negocio, evidencia suficiente ni autorización.

Cómo los embeddings cambian una búsqueda empresarial

Una arquitectura típica de recuperación aumentada por generación, o RAG, puede simplificarse así:

La organización selecciona documentos o registros que formarán parte de la base de conocimiento.
Los documentos se dividen en fragmentos manejables.
Cada fragmento se transforma en un embedding y se almacena en un índice o almacén vectorial junto con metadatos.
La pregunta del usuario también se convierte en un embedding.
El sistema busca los fragmentos semánticamente más cercanos.
Los fragmentos recuperados se entregan al modelo generativo para construir una respuesta.

Esta arquitectura puede mejorar la capacidad de localizar información útil sin depender de coincidencias exactas de palabras. Pero también desplaza parte del riesgo hacia el proceso de recuperación. El NIST AI RMF y su Generative AI Profile tratan la IA como un sistema que debe gestionarse a lo largo de su ciclo de vida y recomiendan reevaluar riesgos cuando un modelo es adaptado mediante mecanismos como RAG.

Para el auditor, la unidad de análisis ya no es solamente “el modelo”. También importan el corpus documental, la lógica de fragmentación, el modelo de embeddings, los metadatos, el índice, los filtros, las reglas de recuperación y el proceso que mantiene todo eso actualizado.

El riesgo más fácil de pasar por alto: relevante no significa autorizado

Imaginemos una base de conocimiento con políticas generales, contratos, investigaciones internas y papeles de trabajo de auditoría. Semánticamente, dos fragmentos pueden estar muy cerca aunque sus permisos sean completamente distintos.

Si el sistema divide un documento restringido en fragmentos y pierde sus metadatos de acceso, una consulta legítima puede recuperar contenido que el usuario no tiene derecho a ver. También puede ocurrir que los permisos del documento fuente cambien, pero que el índice vectorial conserve durante semanas una copia o representación derivada accesible con reglas antiguas.

La guía de seguridad de OWASP para RAG recomienda preservar metadatos de autorización en los fragmentos, aplicar los controles en el momento de la recuperación y propagar los cambios de permisos y eliminaciones a los índices derivados. OWASP también trata las debilidades de vectores y embeddings como un riesgo específico en aplicaciones con LLM.

Esto lleva a una regla de diseño especialmente útil para auditoría:

La recuperación semántica determina qué contenido parece útil; la capa de autorización determina qué contenido puede entrar en la conversación.

El filtro de permisos debe ejecutarse antes de que el fragmento restringido llegue al modelo. Pedir al LLM que “no revele información confidencial” no sustituye un control técnico de acceso.

Cuatro riesgos que el auditor debe separar

El primer riesgo es la calidad del corpus. Un motor de recuperación puede funcionar perfectamente y traer, con gran precisión, una política obsoleta. ISO/IEC 42001:2023 aborda la gestión de datos para sistemas de IA desde una perspectiva de sistema de gestión, incluyendo temas como procedencia, actualización, calidad, seguridad y uso previsto. La ficha oficial de ISO/IEC 42001 confirma su enfoque de gestión de riesgos y mejora continua.

El segundo es la calidad de la recuperación. Una mala fragmentación puede separar una excepción de la regla principal, eliminar contexto o hacer que una cláusula irrelevante parezca la mejor coincidencia. El auditor debería pedir métricas o pruebas que demuestren que el sistema recupera información útil para las preguntas reales de los usuarios, no solo para ejemplos de demostración.

El tercero es el control de acceso. Los permisos deben acompañar al contenido a través de la ingestión, fragmentación, indexación y recuperación. Si se combinan repositorios con diferentes niveles de sensibilidad, el diseño debe impedir que la similitud semántica atraviese límites que el sistema de identidad sí pretendía mantener.

El cuarto es la trazabilidad del ciclo de vida. Si un documento se elimina, expira o cambia de clasificación, ¿qué ocurre con sus fragmentos, embeddings, copias en caché y respuestas derivadas? La gestión de datos no termina cuando el archivo original desaparece.

Qué puede pedir y probar Auditoría Interna

Una revisión no necesita convertirse en una evaluación de ciencia de datos. Puede empezar con evidencia que conecte arquitectura, permisos y resultados.

Área	Pregunta de auditoría	Evidencia o prueba útil
Corpus y vigencia	¿Qué fuentes pueden ser recuperadas y cómo se mantienen actualizadas?	Inventario de fuentes, propietarios, fechas de actualización, reglas de retención; probar documentos vencidos o sustituidos.
Recuperación	¿El sistema trae contenido realmente pertinente para escenarios representativos?	Conjunto de consultas de prueba, resultados esperados, métricas de recuperación, revisión de errores y casos límite.
Autorización	¿Los permisos del usuario se aplican antes de entregar contenido al modelo?	Metadatos por fragmento, reglas de filtrado, pruebas con perfiles autorizados y no autorizados, registros de recuperación.
Cambio y eliminación	¿Los cambios en la fuente se propagan a los datos derivados?	Evidencia de reindexación, eliminación en cascada, sincronización de permisos y monitoreo de fragmentos huérfanos.

Para la propia función de Auditoría Interna, la exigencia es todavía más concreta. La Norma 5.2 de las Normas Globales de Auditoría Interna exige proteger la confidencialidad, privacidad y propiedad de la información, cumplir los requisitos aplicables de seguridad y gestionar el riesgo de divulgación involuntaria. Si Auditoría Interna utiliza RAG sobre informes anteriores, papeles de trabajo o información sensible, ese deber no desaparece porque el contenido haya sido convertido en embeddings.

El Artificial Intelligence Auditing Framework del IIA añade una perspectiva específica para evaluar gobierno, gestión, riesgos y controles relacionados con IA. No convierte cada problema de embeddings en un requisito normativo independiente, pero ayuda a situarlo dentro de una evaluación más amplia de gobierno y control.

La pregunta correcta no es “¿tenemos una base vectorial?”

Una organización puede tener una arquitectura técnicamente sofisticada y seguir gestionando mal la información. También puede utilizar un servicio administrado muy simple y mantener controles sólidos. La madurez no depende de cuántas dimensiones tenga un vector ni de qué producto se utilice.

Para el auditor, la pregunta más valiosa es otra: ¿puede la organización demostrar que el contenido recuperado es pertinente, vigente, autorizado y trazable para el uso previsto?

Los embeddings hacen posible que una máquina encuentre relaciones que una búsqueda literal perdería. Esa es su utilidad. Pero, en un entorno empresarial, encontrar algo no es lo mismo que tener derecho a usarlo. Ahí empieza el verdadero problema de control.