Hasta ahora hemos visto lo que la IA generativa puede hacer y cómo evaluar los modelos disponibles. Esta lección completa el módulo con la parte que ningún desarrollador profesional puede saltarse: lo que puede salir mal. Los LLMs inventan información con total seguridad, tienen una memoria de trabajo limitada, ignoran todo lo posterior a su entrenamiento, no responden dos veces igual, arrastran sesgos y cuestan dinero en cada llamada. Nada de esto los hace inservibles — pero cada limitación debe influir en el diseño de tu aplicación desde el primer día. Usaremos DocuBot y Nubelia como banco de pruebas mental para cada riesgo: entenderlos ahora es lo que nos permitirá, en los módulos siguientes, construir las mitigaciones con conocimiento de causa.

1. Alucinaciones: cuando el modelo inventa con seguridad
2. La ventana de contexto y sus implicaciones
3. El corte de conocimiento (knowledge cutoff)
4. No determinismo: el mismo prompt, distintas respuestas
5. Sesgos en los datos y en las respuestas
6. Costes y consumo como restricción de diseño
7. Privacidad: qué pasa con los datos que envías

Una alucinación es una respuesta falsa o inventada que el modelo presenta con la misma fluidez y aparente seguridad que una respuesta correcta. Es la limitación más importante de los LLMs y la primera que debes interiorizar.

Recuerda el mecanismo de la lección 01-02: un LLM genera el texto estadísticamente más plausible a continuación de lo que ha recibido. En ninguna parte de ese proceso hay una verificación de hechos. Tres factores se combinan:

1. El modelo optimiza plausibilidad, no verdad. Una cifra inventada pero razonable es un texto perfectamente plausible.
2. No tiene un mecanismo interno fiable de "no lo sé". Ante una pregunta cuyo contenido no está en sus datos, la continuación más plausible sigue siendo una respuesta, no un silencio.
3. El entrenamiento con feedback humano (RLHF) premia respuestas que suenan útiles y seguras, lo que puede acentuar la tendencia a responder con confianza en lugar de admitir ignorancia.

Imagina el DocuBot "ingenuo" de la lección 01-01: un LLM genérico conectado al chat de Nubelia, sin acceso a la documentación. Ejemplos del tipo de diálogo que veríamos (ficticios, claro, como todo lo de Nubelia):

Respuesta fluida, concreta, con rutas de menú... y completamente inventada. El modelo no sabe nada de Nubelia; ha generado lo que suele ser verdad en productos SaaS parecidos. Quizá Nubelia exporta a PDF, quizá no — el modelo no lo sabe, pero responde como si lo supiera. Peor aún:

Un endpoint con aspecto impecable... de una funcionalidad que quizá no existe. Un desarrollador confiado perdería una hora antes de descubrir el engaño. Este es el patrón peligroso: las alucinaciones son más convincentes cuanto más plausible es el dominio.

Es importante entender que las alucinaciones no se limitan a datos privados: los modelos también inventan sobre conocimiento público (citas, funciones de librerías, referencias bibliográficas), especialmente en los detalles finos y en temas poco representados en sus datos.

No existe (hoy) una solución que elimine las alucinaciones por completo, pero sí un conjunto de mitigaciones que las reducen drásticamente. Las presentamos ahora y las construiremos durante el curso:

Fíjate en que la primera mitigación es exactamente la razón de ser de RAG: la diferencia entre el DocuBot ingenuo y el DocuBot final del curso será que el segundo responde con la documentación real de Nubelia delante — y citándola.

La ventana de contexto es la cantidad máxima de tokens que el modelo puede manejar en una llamada: instrucciones + historial + documentos + la propia respuesta generada, todo suma. Es, literalmente, todo lo que el modelo "ve" al responder; fuera de ella, no existe nada.

Implicaciones de diseño:

• No puedes pasarlo todo. La documentación completa de Nubelia excede cualquier ventana razonable (y aunque cupiera, pagarías todos esos tokens en cada llamada). Hay que seleccionar qué entra: es el problema que resuelve la recuperación de RAG (módulo 4).
• Las conversaciones no caben para siempre. En un chat, cada turno se acumula. Tarde o temprano hay que truncar, resumir o descartar historial — las estrategias se ven en 03-03.
• El modelo no "recuerda" entre llamadas. No hay memoria persistente: si quieres que DocuBot recuerde la conversación, tu aplicación debe reenviar el historial en cada llamada. La "memoria" de un chatbot es ingeniería tuya, no una capacidad del modelo.
• Ventana grande ≠ atención perfecta. Con contextos muy largos, los modelos pueden aprovechar peor la información situada en medio del texto (fenómeno conocido como lost in the middle). Más contexto también implica más coste y latencia. La calidad de lo que pones en el contexto importa más que la cantidad.

Como vimos en 01-02, el conocimiento del modelo procede de su pre-entrenamiento y queda congelado en una fecha: el knowledge cutoff. Todo lo posterior — versiones nuevas de librerías, eventos, cambios de APIs públicas — simplemente no está.

Consecuencias prácticas:

• Preguntas sobre "lo último" de cualquier tecnología pueden recibir respuestas desactualizadas sin ninguna señal de aviso: el modelo describe con seguridad la versión antigua.
• Combinado con las alucinaciones, es traicionero: preguntado por algo posterior a su corte, el modelo puede mezclar lo que sabía con extrapolaciones inventadas.
• Para DocuBot hay un matiz esencial: incluso si re-entrenáramos el modelo con la documentación de Nubelia, quedaría obsoleta en cada release. La documentación cambia cada semana; los modelos se entrenan cada muchos meses. Por eso la estrategia correcta no es "meter el conocimiento en el modelo" sino pasarle la información vigente en el contexto en cada llamada — otra vez, el patrón RAG del módulo 4.

Regla de diseño: para cualquier dato que cambie con el tiempo, trata el conocimiento interno del modelo como potencialmente caducado y suministra la versión actual en el contexto.

Un LLM no es una función pura: la misma entrada puede producir salidas distintas en llamadas distintas. Lo vimos en 01-02: el muestreo introduce azar deliberadamente, y ni siquiera con temperature = 0 hay garantía absoluta de reproducibilidad (entre otras cosas, por detalles de la aritmética en paralelo de las GPUs y por cambios de versión del modelo en el proveedor).

Qué implica para ti como desarrollador:

• Testing: no puedes asertar respuesta == "texto esperado". Los tests de aplicaciones con LLM verifican propiedades (¿contiene la cita correcta?, ¿es un JSON válido?, ¿menciona la funcionalidad X?) o usan evaluadores — lo veremos en 06-03.
• Depuración: un fallo puede no reproducirse a la primera. Registrar entradas y salidas de cada llamada (observabilidad, 06-04) deja de ser opcional.
• Experiencia de usuario: dos empleados de Nubelia que hagan la misma pregunta a DocuBot recibirán redacciones distintas. Aceptable en general — pero si la sustancia varía (a uno le dice que sí y a otro que no), tienes un problema de fiabilidad que debe detectarse con evaluación.
• Cambios silenciosos de modelo: los proveedores actualizan y depreca(n) modelos. La versión que evaluaste hoy puede comportarse distinto tras una actualización: fija versiones cuando sea posible y re-evalúa al cambiar.

Los LLMs aprenden de textos escritos por personas, con todos sus sesgos: culturales, de género, geográficos, lingüísticos. El modelo los absorbe y puede reproducirlos o amplificarlos.

Manifestaciones relevantes en aplicaciones reales:

• Sesgos sociales: asociaciones estereotipadas al generar descripciones, ejemplos o evaluaciones que involucren personas o colectivos.
• Sesgo lingüístico: rendimiento superior en inglés (mayoritario en los datos de entrenamiento); en español o catalán, el mismo modelo puede razonar algo peor o producir calcos del inglés.
• Sesgo de disponibilidad: lo más frecuente en los datos se convierte en la respuesta "por defecto" — soluciones técnicas populares recomendadas aunque no sean las adecuadas para tu caso.
• Sycophancy (complacencia): tendencia a dar la razón al usuario y adaptarse a sus expectativas, en vez de contradecirle cuando toca.

Incluso en un asistente "puramente técnico" como DocuBot hay que vigilarlo: si el equipo de soporte le pide redactar respuestas a clientes, los sesgos de tono y las suposiciones sobre el usuario acaban en comunicaciones reales. Mitigación a alto nivel: instrucciones explícitas sobre tono y suposiciones (módulo 2), revisión humana de textos que salgan de la empresa y evaluación con casos diversos (módulo 6).

Cada llamada a un LLM cuesta dinero (tokens de entrada + salida, como vimos en 01-03) y consume tiempo y energía. Tratado aquí como riesgo de diseño — la gestión operativa detallada (caching, optimización, monitorización de gasto) llega en 03-04.

El riesgo tiene una forma concreta: el coste de las aplicaciones LLM escala con el uso de maneras que el software tradicional no. Un endpoint REST clásico cuesta prácticamente lo mismo con 10 o 10.000 peticiones diarias; con un LLM, 1.000× más peticiones son (aproximadamente) 1.000× más coste. Errores de diseño típicos que lo disparan:

• Contexto hinchado: reenviar en cada llamada documentación o historial innecesarios. Recuerda: pagas todos los tokens de entrada en cada llamada.
• Llamadas evitables: usar el LLM para lo que resolvería una consulta a base de datos o una regla simple.
• Bucles y reintentos sin control: un fallo mal gestionado que reintenta en bucle es dinero saliendo por un grifo abierto (lo gestionaremos en 03-02).
• Sobredimensionar el modelo: usar el escalón grande para tareas del pequeño (lección 01-03).

Estimación de servilleta para DocuBot, para desarrollar el reflejo:

La cifra exacta importa poco (los precios cambian); el hábito sí: haz esta cuenta en la fase de diseño de cualquier funcionalidad con LLM, no cuando llegue la factura.

Última limitación, a menudo la primera que preguntará tu empresa: al usar un modelo vía API, el contenido de cada llamada viaja al proveedor. Prompts, documentos incluidos en el contexto, preguntas de los usuarios — todo.

Puntos clave a alto nivel (el detalle normativo — RGPD, acuerdos de tratamiento, residencia de datos — se trata en la lección 06-02):

• Lee los términos de datos del proveedor: ¿usa tus llamadas para entrenar modelos? (los planes de API empresariales de los proveedores serios, por regla general, no lo hacen, a diferencia de algunos productos gratuitos de consumo); ¿cuánto tiempo retiene los datos?; ¿dónde se procesan?
• Minimiza lo que envías: no incluyas en el contexto datos personales o confidenciales que la tarea no necesite. Si un ticket de soporte contiene datos de un cliente y el LLM solo debe clasificarlo, anonimiza o elimina esos datos antes de la llamada.
• Cuidado con el "shadow AI": empleados pegando información confidencial en chats de IA de consumo, fuera de todo control corporativo. Parte del valor de construir un DocuBot oficial es precisamente ofrecer un canal aprobado y controlado.
• Para Nubelia: la documentación interna es confidencial pero no contiene datos personales de clientes, así que una API con buenas garantías contractuales es aceptable (como decidimos en 01-03). Si DocuBot algún día procesara tickets con datos de clientes, el análisis de privacidad tendría que rehacerse — y eso es una decisión de compliance, no solo técnica.

Queda deliberadamente fuera de esta lección el otro gran frente de seguridad — usuarios manipulando al modelo mediante prompt injection y ataques relacionados — que tiene lección propia (06-01).

• Confiar en una respuesta porque suena segura. La fluidez del texto no correlaciona con su veracidad; la seguridad del tono, tampoco. Verifica todo dato accionable (endpoints, comandos, cifras) contra la fuente antes de usarlo.
• Intentar arreglar las alucinaciones solo con el prompt. Instrucciones como "no inventes" ayudan, pero no bastan: sin darle la información correcta en el contexto, el modelo no tiene alternativa a su conocimiento congelado. La mitigación de fondo es arquitectónica (RAG), no cosmética.
• Diseñar como si el modelo recordara. "Se lo dije hace tres mensajes" no existe para el modelo si tu aplicación no reenvió esos mensajes. La gestión del historial es responsabilidad de tu código.
• Descubrir los costes en la factura. Estima coste por llamada × volumen en la fase de diseño, pon límites de gasto y alertas desde el primer día.
• Enviar datos sensibles "porque es más cómodo". Pregúntate ante cada llamada: ¿necesita el modelo este dato para la tarea? Si no, fuera. La minimización es la regla más barata de la privacidad.
• Pensar que estas limitaciones desaparecerán el mes que viene. Los modelos mejoran, pero alucinaciones, contexto finito, corte de conocimiento y coste por token son características estructurales de la tecnología actual. Diseña con ellas, no contra ellas.
• Consejo: convierte esta lección en una checklist de diseño. Ante cada nueva funcionalidad con LLM: ¿qué pasa si alucina? ¿cabe el contexto? ¿los datos están vigentes? ¿tolero variabilidad? ¿hay sesgos con impacto? ¿cuánto cuesta a mi volumen? ¿qué datos salen y deben salir?

Para cada incidente de DocuBot, identifica qué limitación de la lección lo explica y una mitigación razonable:

1. DocuBot explica con detalle cómo activar la "integración con calendario" de Nubelia. Esa integración no existe; hay una similar con otro nombre.
2. Tras 40 minutos de conversación, DocuBot empieza a contradecir cosas que él mismo dijo al principio del chat.
3. Un empleado pregunta por la política de despliegues aprobada el mes pasado y DocuBot describe la política de hace dos años que aparecía en una web pública.
4. El equipo de QA ejecuta el mismo test dos veces y la respuesta menciona la fuente correcta la primera vez, pero no la segunda.

El equipo de producto de Nubelia propone que DocuBot, además de responder, resuma automáticamente cada ticket de soporte al crearse (unos 3.000 tickets/mes, entrada media 2.000 tokens, salida 200). Con los precios ilustrativos de la lección (3 €/M entrada, 15 €/M salida): calcula el coste mensual añadido, y menciona una decisión de diseño que lo reduciría sin eliminar la funcionalidad.

Escribe el texto breve (2–4 frases) que DocuBot debería mostrar de forma permanente en su interfaz para poner las expectativas correctas a los empleados de Nubelia, cubriendo al menos: posibilidad de error, necesidad de verificar información crítica y qué no pegar en el chat.

Solución 1:

1. Alucinación (agravada por la plausibilidad del dominio: "integración con calendario" es típico de un SaaS de proyectos). Mitigación: responder solo a partir de fragmentos de la documentación real recuperados para la pregunta (RAG, módulo 4) e instruir al modelo para que admita cuando la documentación no menciona algo, citando fuentes.
2. Ventana de contexto: la conversación larga excede la ventana (o el historial se truncó) y el modelo ya no "ve" sus primeras respuestas. Mitigación: estrategia de gestión de historial — truncado inteligente o resumen de la conversación previa (03-03).
3. Corte de conocimiento: la política nueva es posterior al entrenamiento (y además es interna); el modelo recurre a lo que vio en sus datos. Mitigación: suministrar la versión vigente del documento en el contexto en cada llamada, en lugar de confiar en el conocimiento del modelo.
4. No determinismo: el muestreo produce variaciones entre ejecuciones, y aquí la variación afecta a la sustancia (la cita). Mitigación: temperature baja para este caso de uso y, sobre todo, tests que verifiquen propiedades (¿incluye la fuente?) ejecutados sobre varias muestras, con umbrales de aprobación (06-03).

Solución 2:

• Coste por ticket ≈ 2.000/1M × 3 € + 200/1M × 15 € = 0,006 € + 0,003 € = 0,009 €.
• Coste mensual ≈ 0,009 € × 3.000 = 27 €/mes. Perfectamente asumible — la cuenta rápida evita tanto sustos como vetos infundados: aquí los números avalan la funcionalidad.
• Decisiones de diseño que lo reducirían (cualquiera vale): usar un modelo pequeño para resumir (tarea simple, no necesita el escalón medio); resumir solo tickets que superen cierta longitud (los cortos ya son su propio resumen); o recortar la entrada a las partes relevantes del ticket antes de la llamada.

Solución 3 (ejemplo):

"DocuBot genera sus respuestas con inteligencia artificial a partir de la documentación interna de Nubelia y puede cometer errores u omitir información. Verifica siempre contra la documentación enlazada cualquier dato que vayas a usar en producción o a comunicar a un cliente. No pegues en el chat datos personales de clientes ni credenciales. Si detectas una respuesta incorrecta, repórtala: nos ayuda a mejorar el asistente."

(Lo esencial: falibilidad admitida, verificación de lo crítico, restricción sobre datos sensibles; el canal de feedback es un extra valioso.)

Con esta lección cierras el módulo de fundamentos con una visión completa y honesta de la tecnología. Ya conoces las siete limitaciones que condicionan cualquier diseño con LLMs: las alucinaciones (el modelo optimiza plausibilidad, no verdad — como el DocuBot ingenuo inventando endpoints de Nubelia), la ventana de contexto finita y sin memoria entre llamadas, el corte de conocimiento que congela lo aprendido, el no determinismo que obliga a testear propiedades en lugar de textos exactos, los sesgos heredados de los datos, los costes que escalan con cada token y cada llamada, y la privacidad de todo lo que viaja al proveedor. Y conoces la respuesta de fondo del curso: darle al modelo el contexto correcto en cada llamada — el patrón que desarrollaremos como RAG en el módulo 4 — junto con evaluación sistemática (módulo 6) y decisiones de diseño conscientes. Ninguna de estas limitaciones invalida a los LLMs; todas exigen que el desarrollador — tú — diseñe con ellas sobre la mesa. En el próximo módulo pasamos de entender a actuar: el prompt engineering es la primera herramienta concreta para dirigir el comportamiento del modelo, y empezaremos por la anatomía de un prompt — roles, instrucciones y contexto — escribiendo ya las primeras instrucciones reales de DocuBot.