Cómo funcionan los grandes modelos de lenguaje: una guía para auditores internos

Un auditor carga una política de 80 páginas en una herramienta de inteligencia artificial y pide un resumen de los controles clave. La respuesta llega en segundos, está bien escrita y parece convincente. El problema aparece después: uno de los controles descritos no existe en la política.

La reacción intuitiva es pensar que el modelo “leyó mal” el documento. Esa explicación es incompleta. Un gran modelo de lenguaje, o LLM por sus siglas en inglés, no funciona como una base de datos que localiza una respuesta exacta y luego la redacta. Funciona como un sistema que genera lenguaje a partir de patrones aprendidos y del contexto disponible en ese momento.

Esta diferencia explica tanto su utilidad como sus riesgos. Un auditor interno no necesita la matemática del modelo, pero sí cuatro ideas: tokens, contexto, generación probabilística y validación. Con ellas se entiende por qué un LLM puede resumir cientos de páginas y también producir una afirmación falsa con seguridad.

Un LLM genera lenguaje; no consulta automáticamente una fuente de verdad

Durante el entrenamiento, un modelo de lenguaje procesa grandes cantidades de texto y ajusta sus parámetros para aprender relaciones estadísticas entre secuencias. La mayoría de los LLM modernos se basa en la arquitectura transformer, introducida por Google Research en Attention Is All You Need.

En uso, el mecanismo es más sencillo de explicar: el modelo recibe una secuencia, calcula continuaciones plausibles, selecciona un siguiente token y repite el proceso. El NIST AI 600-1, Generative AI Profile, lo resume de forma especialmente útil para el riesgo: los LLM predicen el siguiente token o palabra a partir de patrones estadísticos y, por esa misma razón, pueden producir contenido correcto o contenido factual e internamente inconsistente.

Esto cambia una suposición importante para auditoría. Fluidez no equivale a veracidad y detalle no equivale a evidencia. Un modelo puede producir una explicación precisa porque la información se encuentra en el contexto, porque patrones similares fueron aprendidos durante el entrenamiento o porque generó una continuación plausible. La forma de la respuesta no revela cuál de esas posibilidades ocurrió.

Los tokens son las unidades que realmente procesa el modelo

Un LLM no recibe necesariamente las palabras tal como las percibimos. Antes de procesar el texto, este se divide en tokens: unidades que pueden representar una palabra completa, parte de una palabra, signos de puntuación, espacios u otros fragmentos. La segmentación exacta depende del modelo y de su tokenizador.

La distinción tiene consecuencias prácticas. Los límites de entrada y salida se expresan normalmente en tokens, no en páginas. Códigos, identificadores, tablas o cadenas numéricas pueden convertirse en varias unidades y no deben asumirse como datos que el modelo reproducirá sin error.

Para el auditor, la lección no es contar tokens, sino reconocer que el LLM transforma el material antes de utilizarlo. Cuando la precisión de una cifra, un número de factura, una cláusula o un identificador sea material, la salida debe contrastarse con la fuente o con una comprobación determinista.

La ventana de contexto es el espacio de trabajo, no la memoria total

La ventana de contexto es la cantidad de tokens que el modelo puede procesar conjuntamente en una interacción. En la práctica, ese contexto puede incluir instrucciones del sistema, el mensaje del usuario, ejemplos, partes de una conversación, documentos recuperados y resultados devueltos por herramientas. Google Cloud la describe como el número de tokens que un modelo fundacional puede procesar en un prompt.

Pensar en ella como un espacio de trabajo temporal es más útil que llamarla “memoria”. El modelo conserva patrones aprendidos en sus parámetros, pero la información concreta para una tarea debe llegar mediante el contexto, una herramienta o un mecanismo de recuperación.

Una ventana de contexto grande tampoco garantiza que cada elemento sea utilizado correctamente. Un procedimiento importante puede estar incluido y aun así recibir poco peso frente a otras instrucciones, ejemplos o documentos. Por eso, en soluciones empresariales, la pregunta de auditoría no debería ser solo “¿qué modelo utilizan?”, sino también “¿qué información llega al modelo para esta decisión y cómo se selecciona?”

Esta distinción es especialmente importante cuando se utiliza recuperación aumentada por generación (RAG). RAG puede incorporar políticas, contratos o normas al contexto, pero no convierte al LLM en una base de datos infalible. La calidad sigue dependiendo de los documentos recuperados, su vigencia, permisos, fragmentación y de cómo el modelo interpretó ese contexto.

La generación probabilística explica la variabilidad y las alucinaciones

Cada vez que genera un token, el modelo trabaja con una distribución de posibles continuaciones. La configuración del sistema determina cómo se selecciona una de ellas. Por eso dos ejecuciones similares pueden producir respuestas diferentes, y una misma pregunta puede admitir múltiples formulaciones plausibles.

Esto es útil para redactar, resumir, clasificar o proponer alternativas, pero se vuelve un riesgo cuando la respuesta se trata como una consulta exacta a un registro.

NIST utiliza el término confabulation para respuestas que presentan contenido erróneo o falso con confianza; en el uso cotidiano suele hablarse de “alucinaciones”. El problema no es simplemente un defecto que aparecerá solo en modelos malos. NIST vincula la confabulación con la propia naturaleza estadística de la generación. Puede reducirse mediante mejores modelos, instrucciones, recuperación de fuentes, controles y pruebas, pero no conviene diseñar un proceso crítico bajo la premisa de que desaparecerá por completo.

También existe sensibilidad al contexto. Cambiar una instrucción, el orden de los documentos, un ejemplo o la información recuperada puede modificar el resultado. Si el LLM además está conectado a herramientas, bases de datos o aplicaciones, errores de interpretación pueden dejar de ser solo texto incorrecto y convertirse en acciones incorrectas.

Lo que cambia para el auditor interno

Comprender el mecanismo permite formular mejores preguntas de control. La evaluación puede comenzar por el uso, la información que entra, la validación y las consecuencias de equivocarse.

Lo que ocurre en el LLM	Riesgo para auditoría	Qué conviene comprobar
El texto se convierte en tokens y existe un límite de contexto	Información relevante puede quedar fuera, truncarse o representarse de forma poco robusta	Límites documentados, tratamiento de documentos largos y pruebas con datos exactos o materialmente sensibles
La respuesta depende del contexto disponible	Una fuente omitida, desactualizada o mal recuperada puede cambiar la conclusión	Fuentes autorizadas, vigencia, criterios de recuperación, permisos y trazabilidad del contexto utilizado
La salida se genera probabilísticamente	Puede haber variabilidad, confabulaciones o conclusiones plausibles pero incorrectas	Conjuntos de prueba, criterios de aceptación, repetición de pruebas y validación independiente
El modelo puede cambiar de versión o configuración	El desempeño puede variar sin que el proceso de negocio haya cambiado	Inventario, versionado, gestión de cambios, pruebas antes del despliegue y monitoreo posterior
Las personas tienden a confiar en respuestas fluidas	Una revisión humana puede convertirse en una aprobación superficial	Roles de revisión, capacitación, reglas de escalamiento y evidencia de corroboración

Para el propio trabajo de auditoría, las Normas Globales de Auditoría Interna ofrecen un criterio claro. La Norma 4.3, Escepticismo profesional, exige evaluar críticamente la fiabilidad de la información y buscar evidencia adicional cuando esta pueda ser incompleta, inconsistente, falsa o engañosa. La Norma 14.1, Recopilación de información para el análisis y evaluación, exige que la información utilizada sea relevante, fiable y suficiente para sustentar los hallazgos y conclusiones.

Estas obligaciones no desaparecen porque la información provenga de una herramienta sofisticada. La guía 2026 del IIA, Understanding Data Analytics for Internal Auditors, reconoce el uso de LLM y otras tecnologías de IA en analítica de auditoría y enfatiza la importancia de la calidad, gobernanza y validación de los datos y resultados.

Antes de confiar en una respuesta, separe fuente, generación y evidencia

Un marco sencillo ayuda a evitar la confusión entre una salida útil y una conclusión sustentada:

Fuente: ¿qué información autorizada y vigente respalda la tarea?
Contexto: ¿qué parte de esa información llegó realmente al modelo y bajo qué instrucciones?
Generación: ¿qué añadió, resumió, infirió o reformuló el LLM?
Validación: ¿qué afirmaciones materiales fueron contrastadas con fuentes independientes o controles deterministas?
Decisión: ¿quién conserva la responsabilidad por la conclusión y qué ocurre cuando existe incertidumbre?

La ISO/IEC 22989:2022 aporta terminología común de IA; el NIST AI RMF y su perfil generativo llevan la conversación al contexto de uso, la medición y la gestión de riesgos. Para auditoría, lo decisivo es traducir esos conceptos en evidencia comprobable.

Un auditor no necesita reconstruir los parámetros de un modelo para hacer preguntas valiosas. Necesita comprender qué entra, cómo genera y dónde puede fallar.

El cambio mental más útil es simple: un LLM es un generador probabilístico condicionado por contexto, no una autoridad automática. Una vez entendido eso, sus capacidades dejan de parecer mágicas y sus riesgos se vuelven mucho más auditables.