IA generativa explicada: modelos, recuperación, herramientas y aplicaciones no son lo mismo

La IA generativa no es un solo componente. Un sistema de IA generativa en producción normalmente combina un modelo generativo con código de aplicación que proporciona instrucciones y contexto, recupera conocimiento externo cuando es necesario, expone herramientas para leer o modificar sistemas externos, gestiona el estado de ejecución y los permisos, y convierte el resultado en un producto utilizable. Tratar el modelo, la recuperación, las herramientas, el contexto, el entorno de ejecución y la aplicación como si fueran lo mismo oculta las fronteras que determinan la frescura, la seguridad, la fiabilidad, el coste y el control.

¿Qué significa realmente “IA generativa”?

A nivel de modelo, la IA generativa se refiere a modelos de IA que generan contenido sintético derivado, como texto, imágenes, audio, vídeo, código u otra salida digital. NIST AI 600-1 utiliza este significado orientado al modelo y analiza por separado los riesgos a nivel de modelo, sistema, aplicación y caso de uso.

Esa distinción importa porque un modelo de IA no es lo mismo que el sistema de IA completo. El glosario actual del NIST define un modelo de IA como un componente que produce salidas a partir de entradas utilizando técnicas computacionales, estadísticas o de aprendizaje automático, mientras que un sistema de IA puede incluir software, hardware, aplicaciones, herramientas o utilidades que operan utilizando IA.

El modelo útil más simple de un sistema de IA generativa

Como primer modelo mental, imagina un asistente empresarial que responde: “¿Puede este cliente recibir un reembolso hoy?”. Una respuesta útil puede requerir varias responsabilidades diferentes. El modelo de lenguaje puede interpretar la pregunta y redactar la explicación, pero el estado actual del pedido puede provenir de una herramienta de base de datos, la política de reembolsos puede provenir de la recuperación de documentos, los permisos pueden ser aplicados por la aplicación, y la acción final puede requerir una llamada a API controlada.

Los sistemas reales no siempre siguen esta secuencia exactamente. La recuperación puede ocurrir antes de la primera llamada al modelo, las herramientas pueden seleccionarse durante un bucle de agente, la lógica determinista de la aplicación puede evitar por completo el modelo, y la validación puede ocurrir en varias etapas. El objetivo es separar responsabilidades, no imponer un flujo de trabajo universal.

Las seis fronteras que importan

1. El modelo: la generación es su responsabilidad principal

Un modelo generativo asigna las entradas proporcionadas a salidas generadas. Para un modelo de lenguaje, eso puede incluir texto en lenguaje natural, JSON estructurado, código, clasificaciones, resúmenes, planes o argumentos de llamadas a herramientas. Los modelos generativos multimodales pueden trabajar con tipos adicionales de entrada y salida.

El modelo puede contener un conocimiento aprendido sustancial en sus parámetros, pero el conocimiento parametrizado no es una base de datos en vivo. El modelo no sabe automáticamente sobre un documento creado hace cinco minutos, el nivel de stock actual, un registro privado de un cliente o el estado de una aplicación, a menos que esa información se proporcione a través de la ruta de entrada actual.

Por eso, cambiar el modelo no resuelve automáticamente el conocimiento obsoleto, los permisos faltantes, la recuperación rota, la propiedad incorrecta del estado o la ejecución insegura de herramientas. Esos fallos a menudo pertenecen a otras capas.

2. Recuperación: encontrar evidencia externa es una operación separada

La recuperación selecciona información de una fuente externa antes o durante la generación. El trabajo de Generación Aumentada por Recuperación de 2020 de Lewis et al. hizo explícita la separación al combinar un modelo generativo paramétrico con memoria no paramétrica recuperada. Los sistemas de producción modernos utilizan muchas variantes de recuperación, pero la idea arquitectónica sigue siendo la misma: se puede obtener evidencia útil en el momento de la inferencia en lugar de depender únicamente de lo que el modelo aprendió durante el entrenamiento.

La recuperación puede utilizar búsqueda léxica, embeddings, búsqueda vectorial, búsqueda híbrida, SQL, grafos de conocimiento, filtros de metadatos, APIs u otros mecanismos de selección. Una base de datos vectorial es, por lo tanto, un posible componente de recuperación, no la definición de RAG.

3. Herramientas: el acceso y la acción no son conocimiento del modelo

Una herramienta es una interfaz a través de la cual un entorno de ejecución de IA puede solicitar funcionalidad fuera del modelo. Una herramienta puede consultar una base de datos, buscar en la web, leer un archivo, calcular un valor, llamar a un servicio interno, crear un ticket, enviar un mensaje, modificar un registro o desencadenar otra operación controlada.

La documentación actual de llamada a funciones de OpenAI hace explícito este límite: la llamada a funciones permite que los modelos interactúen con sistemas externos y accedan a datos o acciones proporcionados por la aplicación. El modelo puede proponer o seleccionar una llamada, pero el sistema externo realiza la operación real.

El uso de herramientas, por lo tanto, crea dos preguntas separadas: ¿Puede el modelo solicitar esta capacidad? y ¿Autorizará y ejecutará la aplicación dicha solicitud? Un sistema de producción no debe confundir la intención del modelo con el permiso para causar un efecto secundario.

4. Contexto: lo que el modelo puede ver en este momento

El contexto es la información disponible para el modelo en un paso de inferencia particular. La guía de ingeniería de contexto de Anthropic describe el contexto como el conjunto de tokens incluidos al muestrear de un LLM. En la práctica, ese conjunto puede contener instrucciones del sistema, mensajes del usuario, historial de conversación, evidencia recuperada, definiciones de herramientas, resultados de herramientas, resúmenes de memoria y estado de aplicación seleccionado.

El contexto, por lo tanto, no es ni la base de conocimiento completa ni la memoria a largo plazo. Una empresa puede almacenar diez millones de documentos mientras solo unos pocos pasajes entran en una llamada al modelo. Un entorno de ejecución puede persistir un año de historial de conversación mientras expone solo las piezas necesarias para la tarea actual.

La ventana de contexto también crea una restricción de ingeniería. Agregar más texto no garantiza una mejor respuesta; la información irrelevante, desactualizada, contradictoria o de baja autoridad puede diluir la evidencia que realmente importa.

5. Entorno de ejecución y orquestación: coordinar el bucle

La capa de entorno de ejecución u orquestación coordina cómo participa el modelo en una tarea. Dependiendo de la arquitectura, puede gestionar sesiones, solicitudes al modelo, descubrimiento de herramientas, bucles de llamadas a herramientas, reintentos, transferencias, eventos de streaming, tiempos de espera, puntos de control, compactación o entornos de ejecución.

Algunos entornos de ejecución son código de aplicación ligero alrededor de una API de modelo. Otros son arneses de agente completos. Un entorno de ejecución gestionado por un proveedor puede poseer parte del bucle mientras la aplicación sigue siendo dueña de la verdad del dominio, la autorización, los efectos secundarios del negocio y el ciclo de vida del producto.

Este límite es importante porque dónde se ejecuta el entorno de ejecución y dónde se ejecuta la inferencia son decisiones separadas. Un cliente o proceso de agente que se ejecuta localmente aún puede llamar a un modelo remoto, mientras que una aplicación remota puede llamar a un modelo alojado en infraestructura bajo el control de la organización.

6. La aplicación: donde la IA se convierte en producto

La aplicación es el límite del producto en torno a los componentes de IA. Es responsable de la experiencia de usuario, el modelo de dominio, el estado actual, la identidad, el alcance del inquilino, los permisos, la persistencia, las integraciones de servicios, la validación, la observabilidad, la lógica de facturación o cuotas cuando corresponda, y las reglas que determinan qué puede ver o hacer la IA.

Esta es la capa que convierte "un modelo puede producir resultados útiles" en "un sistema puede ofrecer una capacidad fiable". El mismo modelo puede participar en un asistente de investigación privado, un flujo de trabajo de soporte, un agente de código o una aplicación de comercio porque la aplicación circundante cambia los datos, las herramientas, las políticas, el estado y el contrato de ejecución.

Cómo funcionan las partes juntas en una solicitud real

Consideremos un asistente de soporte al que se le pregunta: "Reembolsa el pedido 4711 si aún es elegible, y explica por qué". La solicitud combina conocimiento, estado actual, autorización, razonamiento y un efecto secundario.

Si el asistente solo tiene el modelo de lenguaje, puede hablar sobre reembolsos pero no puede saber de forma segura si el pedido 4711 es actualmente elegible ni realizar la transacción. Si solo tiene recuperación, puede encontrar la política pero aún carece del estado en vivo del pedido. Si tiene herramientas sin autorización de la aplicación, puede volverse capaz pero inseguro. La fiabilidad proviene de componer las capas con una propiedad explícita.

Diferentes productos de IA usan combinaciones diferentes

Estos son patrones de arquitectura, no clasificaciones de madurez. Una función solo con modelo puede ser el diseño correcto cuando la tarea no necesita hechos o acciones externas. Añadir recuperación, herramientas, memoria o un bucle de agente solo se justifica cuando la tarea requiere esas capacidades.

Evidencia de implementación: Aaasaasa AI Client

Aaasaasa AI Client es un espacio de trabajo de IA de escritorio local-first construido con Nuxt 4, Electron y TypeScript. Su AI Hub separa deliberadamente agente/cliente, proveedor, modelo, ubicación de tiempo de ejecución, permisos y cliente web en lugar de tratarlos como una única configuración de "IA".

Esa separación crea un comportamiento concreto. Direct Chat puede hablar con modelos sin herramientas de sistema de archivos o shell. Un agente Codex puede usar un espacio de trabajo seleccionado y un perfil de permisos. Ollama puede proporcionar inferencia local directa, mientras que LM Studio y los endpoints configurables compatibles con OpenAI representan otras rutas de proveedor. Un proceso Codex que se ejecuta localmente aún puede usar un modelo en la nube, por lo que la interfaz y la arquitectura no equiparan el tiempo de ejecución local con la inferencia local.

La implementación también contiene soporte de Qdrant/vectores, capacidades de extracción de documentos y un broker MCP de directorio autenticado. Esos componentes ilustran otro límite: la infraestructura de recuperación y el acceso a herramientas pueden vivir en el mismo producto sin convertirse en propiedades del modelo en sí.

Errores de categoría comunes

Modos de fallo cuando los límites se desdibujan

Los errores de límites no son meramente problemas de terminología. Crean fallos de producción distintos que requieren soluciones diferentes.

¿Qué es estable y qué es sensible a la versión?

Las distinciones arquitectónicas de este artículo son intencionalmente neutrales respecto al proveedor. Los ejemplos actuales a continuación son hechos de implementación que deben volver a verificarse cuando las API evolucionen.

Un artículo de referencia debería, por lo tanto, preservar ambos niveles: conceptos estables para la arquitectura y evidencia fechada para las implementaciones actuales. Mezclar los dos hace que un artículo envejezca innecesariamente rápido.

La prueba de límites de componentes de IA

Al evaluar una función de IA, haz las siguientes preguntas en orden. Las respuestas revelan qué componentes tiene realmente el sistema y qué responsabilidades siguen siendo implícitas.

Lo que la IA generativa no es

La IA generativa no es sinónimo de un LLM, aunque los LLM son una clase importante de modelo generativo. Tampoco es sinónimo de RAG, una base de datos vectorial, un agente, un protocolo de herramientas, una interfaz de chatbot o una aplicación.

Esos conceptos pueden estar conectados, pero cada uno responde a una pregunta arquitectónica diferente. Un LLM pregunta cómo se produce la salida de lenguaje. La recuperación pregunta de dónde proviene la evidencia externa. Las herramientas preguntan cómo se exponen las capacidades externas. El contexto pregunta qué puede ver el modelo. El runtime pregunta cómo se coordina la ejecución. La aplicación pregunta cómo la capacidad se convierte en un producto controlado.

A dónde ir después en el grafo de conocimiento

Una vez que estos límites están claros, los temas más profundos se vuelven más fáciles de ubicar. RAG pertenece a la recuperación y a la construcción de contexto. Retrieval Trigger decide cuándo se requiere evidencia externa. La memoria del agente se refiere a lo que persiste a lo largo del tiempo. La llamada a herramientas y MCP pertenecen al acceso a capacidades. Los harness de agentes pertenecen a la orquestación del runtime. RBAC, el aislamiento de inquilinos y la autorización de dominio pertenecen al límite de seguridad de la aplicación y la plataforma.

Limitaciones

El modelo de seis capas es un mapa de responsabilidades, no un requisito de que cada producto despliegue seis servicios separados. Una aplicación pequeña puede implementar la construcción de contexto, la recuperación y la orquestación dentro de un solo proceso. Una plataforma gestionada puede agrupar varias responsabilidades detrás de una sola API. El despliegue físico puede combinarse mientras la propiedad semántica permanece distinta.

La terminología también varía entre proveedores e investigaciones. “Agente”, “runtime”, “memoria”, “herramienta”, “conector” y “contexto” pueden definirse de manera diferente. Las definiciones aquí se eligen para hacer explícita la propiedad operativa y el diagnóstico de fallos, en lugar de afirmar que todos los frameworks utilizan un vocabulario idéntico.

La sección del Cliente de IA de Aaasaasa documenta un patrón de implementación. Demuestra que los límites explícitos son prácticos, pero no prueba que la misma disposición de componentes sea óptima para todos los productos de IA.

¿Qué cambiaría esta respuesta?

El mapa de responsabilidades necesitaría revisión si las propias arquitecturas de modelos comenzaran a poseer estado externo autoritativo, permisos, efectos secundarios transaccionales duraderos y acceso verificable a fuentes como propiedades intrínsecas en lugar de capacidades proporcionadas por un sistema circundante. Las arquitecturas de producción actuales no hacen que eso sea una suposición general segura.

Los ejemplos de implementación individuales cambiarán mucho antes. Las herramientas de recuperación alojadas, las APIs de agentes, las integraciones MCP, las funciones de gestión de contexto y las capacidades de los proveedores evolucionan rápidamente. Esos detalles deben actualizarse sin colapsar las distinciones subyacentes entre generación, evidencia, acceso a capacidades, contexto, ejecución y control de la aplicación.

Conclusión

La IA generativa se vuelve más fácil de diseñar una vez que “la IA” deja de tratarse como una sola caja negra. El modelo es el componente generativo, no el producto completo. La recuperación proporciona evidencia externa. Las herramientas exponen capacidades. El contexto lleva información seleccionada a la inferencia actual. El runtime coordina la ejecución. La aplicación posee el límite autoritativo del producto.

Esa separación es útil para más que la explicación. Les dice a los ingenieros dónde se originan los hechos obsoletos, dónde pertenece la autorización, por qué un runtime local aún puede usar inferencia en la nube, por qué RAG no equivale a una base de datos vectorial, por qué las llamadas a herramientas requieren validación y por qué cambiar el modelo no puede reparar todos los fallos del sistema.

La pregunta arquitectónica duradera, por lo tanto, no es “¿Qué modelo de IA estamos usando?” Es: ¿Qué responsabilidad posee cada componente, qué evidencia cruza cada límite y qué capa tiene permitido cambiar el estado real?

Preguntas frecuentes

Glosario

Fuentes primarias y evidencia de implementación

Las definiciones estables a continuación están ancladas en estándares/investigación; los ejemplos de implementación de rápida evolución utilizan documentación de ingeniería oficial actual. Aaasaasa AI Client es evidencia de implementación original y se verificó contra el estado de su base de código/documentación con fecha del 26 de julio de 2026.