Así que vamos a aclararlo, porque resulta que entender dónde reside el contexto (la sesión) en las arquitecturas de IA es tremendamente importante. Y sabes que lo es porque he usado la palabra «tremendamente» en un blog. Sí, lo digo muy en serio.
Si estás desarrollando tu propia aplicación basada en un LLM y utilizas la API de OpenAI para ello, no estás usando ChatGPT. Estás interactuando con un modelo. Uno sin más. Y si crees que tu aplicación va a comportarse como ChatGPT solo porque utiliza GPT-4, ya vas por mal camino.
ChatGPT no es un modelo; es un entorno de ejecución.
La gente se equivoca constantemente con esto, porque la estrategia de marca de OpenAI no ha ayudado. La experiencia de «ChatGPT» —la memoria, el tono, el contexto, la forma en que sigue con naturalidad lo que dijiste hace seis preguntas y no se inventa de repente un doctorado en botánica marina— no es magia. Es arquitectura. Y esa arquitectura no viene incluida sin más cuando utilizas la API.
La aplicación ChatGPT es una experiencia gestionada y estructurada en capas. Integra:
- Ingeniería de prompts
- Gestión del contexto
- Memoria persistente
- Guardrails y mecanismos alternativos
- Lógica de resumen, truncamiento y control
La API no incluye nada de eso de forma predeterminada. Absolutamente nada.
Cuando llamas directamente a GPT-4 (o a cualquier otro modelo, en realidad), le proporcionas una secuencia de mensajes sin procesar en un formato sin estado y esperas que la ventana de contexto no se desborde ni se fragmente por el camino. Es un modelo en blanco, no un mayordomo digital.
La ventana de contexto corre por tu cuenta.
En ChatGPT, el servidor de inferencia gestiona toda la ventana de contexto. Tú escribes, él lo recuerda (hasta que deja de hacerlo) y puedes confiar en que la aplicación mantendrá, en gran medida, el control de lo que es relevante. Además, hay un sistema de memoria superpuesto, y OpenAI selecciona discretamente qué fragmentos se vuelven a incluir.
¿Y si usas la API? Tú eres el servidor de inferencia. Eso significa que:
- Tú construyes la pila de mensajes.
- Tú decides qué incluir.
- Tú gestionas el presupuesto de tokens.
- Truncas, resumes o pierdes coherencia.
Y si te equivocas (y lo harás, a todos nos pasa al principio), será responsabilidad tuya cuando el modelo olvide el nombre del usuario a mitad de la sesión o empiece a inventarse datos que nunca le proporcionaste.
La memoria no es una funcionalidad. Es infraestructura.
ChatGPT tiene memoria. Tú no. A menos que la implementes. Cuando utilizas la API, esta no conserva el estado. Tú gestionas todo el contexto, la memoria y el flujo. Cuando utilizas la aplicación ChatGPT, OpenAI se encarga de todo por ti. Viene integrado.
La «memoria» de ChatGPT no es simplemente una nota añadida a un prompt. Es un sistema que almacena datos, preferencias, objetivos y restricciones del usuario entre distintas sesiones, y los incorpora al prompt de forma contextual en el momento adecuado. Si quieres algo parecido en tu aplicación, necesitarás:
- Un almacén de datos
- Esquema para las entradas de memoria
- Lógica de control para determinar cuándo incluir cada elemento
- Una forma de evitar que dispare tu número de tokens
En otras palabras: infraestructura.
Por eso, la mayoría de las aplicaciones de IA desarrolladas internamente parecen poco robustas. Porque interactúan con un LLM como si fuera un chatbot, en lugar de tratarlo como una herramienta integrada en un sistema. ¿El resultado? Hilos de conversación perdidos, instrucciones repetitivas, regresiones extrañas y frustración para los usuarios.
¿Y qué?
Si estás desarrollando sobre la API, estás creando infraestructura, tanto si era tu intención como si no. Y si tus usuarios esperan una experiencia similar a la de ChatGPT, tendrás que ofrecerles:
- Memoria persistente
- Compresión inteligente del contexto
- Gestión del estado por turnos
- Guardrails, mecanismos de respaldo y lógica de inyección
Pero eso es solo el principio. Porque, si estás desarrollando esto sobre una infraestructura de entrega de aplicaciones de nivel empresarial —y lo estás haciendo, ¿verdad? ¿VERDAD?—, más vale que el resto de la plataforma también esté a la altura.
Aquí es donde entran en juego los equipos de entrega y seguridad de aplicaciones.
Entrega de aplicaciones: ya no se trata solo de servir HTML o JSON
Las aplicaciones nativas de IA mantienen el estado, se basan en conversaciones y, a menudo, funcionan en tiempo real. Esto significa que:
- La afinidad de sesión vuelve a ser importante. No puedes distribuir el estado de una conversación entre backends sin estado a menos que gestiones los tokens de sesión como si estuviéramos en 2009.
- La latencia acaba con la experiencia de usuario. Estás transmitiendo interacciones de varios turnos, no sirviendo páginas estáticas. Más vale que tus balanceadores de carga y tu lógica perimetral sepan priorizar los flujos conversacionales de baja latencia.
- Coste de los tokens = ancho de banda + computación + dinero. Ahora es fundamental ofrecer una entrega eficiente. El tamaño de la carga útil no solo afecta a la red; también repercute en la factura.
Esto no es un sitio web meramente informativo. Es una interfaz viva. No basta con ponerle una CDN delante y darlo por terminado.
Seguridad: si no controlas el prompt, asumes el riesgo
Los LLM se pueden programar mediante prompts. Esto significa que el prompt es ahora la superficie de ataque.
- Los ataques de inyección son reales y ya están ocurriendo. Si no depuras correctamente las entradas, estás permitiendo que los usuarios reprogramen tu IA sobre la marcha.
- La manipulación de prompts puede filtrar información confidencial de la memoria, alterar los flujos de trabajo o falsear la intención.
- La salida del modelo puede ser exfiltrada, manipulada o contaminada si no se protege mediante la aplicación de políticas y la observabilidad.
Los controles de seguridad deben evolucionar:
- Necesitas WAF que comprendan el tráfico de IA. Bloquear JSON malicioso no es suficiente. Necesitas mecanismos de protección para los conjuntos de instrucciones, no solo para la estructura de la carga útil.
- Necesitas registros de auditoría de las decisiones de los LLM, especialmente en entornos regulados.
- Necesitas limitación de solicitudes y protección contra abusos, no solo para las llamadas a la API, sino también para controlar la complejidad de los prompts y los picos de costes.
Y eso sin mencionar siquiera la pesadilla de la gobernanza de datos que supone introducir registros de usuarios en las ventanas de contexto.
Crea ahora la infraestructura tecnológica adecuada antes de que la IA agéntica se descontrole.
En pocas palabras, ChatGPT es un producto refinado. La API de OpenAI es una herramienta en bruto. Si confundes ambos, tu stack va a reventar.
Desarrolla con criterio. Crea una infraestructura de seguridad y entrega de aplicaciones de nivel empresarial que respalde tu creciente cartera de IA. Créeme, será aún más importante cuando empieces a crear agentes de IA y luego adoptes con entusiasmo una arquitectura agéntica. Porque, si crees que la pérdida de contexto y las alucinaciones son problemas en las aplicaciones de IA orientadas al usuario final, espera a ver lo que la IA agéntica puede hacer con tus aplicaciones empresariales y operativas de IA.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Las 10 claves para la entrega de aplicaciones de IA: requisitos de las aplicaciones a medida
La IA convierte lo «personalizado» de caso excepcional en opción predeterminada: las solicitudes pasan a ser cadenas componibles (selección de modelos, recuperación, políticas y herramientas), por lo que la entrega debe adaptarse a cada solicitud, no a cada aplicación.
Las 10 principales amenazas para la entrega de aplicaciones de IA: observabilidad incompleta
La IA no escalará por sí sola. Sin un plano de control unificado que elimine las barreras entre herramientas y responsabilidades, la inferencia se convierte en la capa más frágil y que más coordinación requiere.
Las 10 principales amenazas en la entrega de aplicaciones de IA: prácticas de DNS deficientes
Para los sistemas de inferencia y los sistemas agénticos, la resiliencia del DNS es fundamental para la disponibilidad y el rendimiento: una resolución deficiente provoca errores de enrutamiento, picos de latencia e interrupciones del servicio en distintas regiones.
Comportamiento y límites: el cambio hacia la seguridad agéntica
Los agentes generan secuencias emergentes y sin límites en las que el riesgo se acumula con el tiempo. La seguridad debe pasar de validar solicitudes individuales a supervisar continuamente el comportamiento en flujos de varios pasos que evolucionan con el tiempo.
La IA está impulsando la aparición de nuevos tipos de tráfico
La adopción de la IA está dando lugar a nuevos tipos de tráfico de primer nivel: solicitudes de inferencia, tráfico de automatización generado por máquinas y tráfico de telemetría de gran volumen que alimenta los bucles de control.
La compresión ya no es una cuestión de velocidad, sino del coste de pensar
En la era de la IA, la compresión reduce el coste de pensar, no solo el ancho de banda. Descubre cómo la compresión de prompts, resultados y modelos permite controlar los gastos de inferencia de la IA.