Arquitectura básica de un asistente de IA

¡Hola! Comenzamos el módulo de fundamentos técnicos y despliegue. Hasta ahora, el curso ha situado el foco en elegir casos de uso y definir qué valor deberían aportar. En este módulo aprenderás a reconocer las piezas de una solución de IA, conversar con el equipo técnico sobre sus dependencias y preparar un despliegue comprensible para el cliente.

Hoy construiremos un diagrama básico de un asistente de IA. No necesitas diseñar la infraestructura de producción: el objetivo es poder señalar dónde interactúa la persona, qué hace el modelo, de dónde sale la información, qué sistemas se conectan y cómo se supervisa el conjunto. Esa visión te ayudará a explicar una solución sin confundir «tenemos un chat» con «el asistente puede resolver la tarea de forma fiable».

La interfaz no es todo el asistente

Imagina un asistente para un equipo de atención al cliente de una tienda online. Una persona escribe en el chat interno: «¿Qué plazo de devolución se aplica a este artículo y cuál es el estado del pedido?». El chat es la parte visible, pero no contiene por sí solo la política de devoluciones ni puede consultar un pedido. Tampoco decide qué datos está autorizado a mostrar.

Una arquitectura útil para hablar con el cliente empieza por distinguir cuatro componentes: interfaz, fuentes de datos, modelo de lenguaje y aplicación coordinadora. Lee primero esta descripción breve; después añadiremos integraciones y supervisión.

La interfaz es el punto de contacto: un chat en una aplicación de trabajo, por ejemplo. El modelo genera o interpreta lenguaje, pero no debe confundirse con un archivo siempre actualizado de las normas de la empresa. Las fuentes de datos aportan información específica, como una política de devoluciones. La aplicación coordinadora recibe la petición y decide qué contexto proporcionar al modelo, qué consultas realizar y qué respuesta presentar.

Esta separación importa en adopción. Si un usuario afirma «la IA se inventa los plazos», la causa podría estar en el modelo, pero también en una política desactualizada, una búsqueda que no recupera el apartado correcto o una instrucción mal definida en la aplicación. Un diagrama permite preguntar en qué pieza se produce el fallo antes de prometer más formación a los usuarios.

Información, acciones y supervisión

Una manera de recordar las funciones del asistente es distinguir lo que recibe, lo que utiliza para responder y lo que puede hacer. El siguiente vídeo presenta esas funciones mediante la idea de percepción, razonamiento, acción y retroalimentación. Su enfoque es más amplio que nuestro ejemplo; quédate con las funciones, no con la idea de que todo asistente necesite ser un agente autónomo.

En el caso de la tienda, hay dos necesidades distintas:

• Consultar una fuente documental: localizar el plazo aplicable en la política de devoluciones. La aplicación puede buscar un fragmento pertinente y entregárselo al modelo como contexto para redactar una respuesta. Esta técnica suele llamarse generación aumentada por recuperación o RAG. Puede utilizar un índice de búsqueda, pero no exige representar todos los documentos como una «base de datos vectorial» en un diagrama básico.
• Consultar un sistema operativo: obtener el estado actual de un pedido mediante una integración autorizada. Una política en PDF no puede sustituir ese dato, que cambia con el tiempo. La integración puede ser una conexión con la aplicación de pedidos o su API; no equivale a dar acceso libre al modelo a toda la base de clientes.

La imagen siguiente muestra con detalle la parte de recuperación documental. Identifica el índice de búsqueda, la información añadida a la petición del modelo y las capas de evaluación y control. No muestra por sí sola la consulta transaccional de un pedido: esa conexión habrá que añadirla a nuestro esquema.

Una integración también podría realizar acciones, como crear un borrador de incidencia o tramitar un reembolso. Pero «consultar» y «modificar» no son el mismo permiso ni presentan el mismo riesgo. Para nuestro primer diagrama, el asistente solo lee el estado del pedido y prepara un borrador de respuesta; una persona lo revisa antes de enviarlo. Tramitar reembolsos queda fuera de su alcance.

En este fragmento de vídeo verás por qué conviene dibujar explícitamente tanto las conexiones con otros sistemas como la intervención humana y las métricas. El ejemplo usa varios agentes especializados; no los tomes como requisito para un asistente sencillo.

Un diagrama que puedas explicar a dirección y a tecnología

Este es un croquis lógico, no un plano de servidores. Las líneas indican qué piezas se relacionan; no representan conexiones directas sin controles ni una secuencia obligatoria de llamadas.

┌────────────────── SUPERVISIÓN TRANSVERSAL ──────────────────┐
│ Accesos · límites de uso · registros · calidad · revisión   │
│ humana · gestión de incidencias                              │
│                                                               │
│                    [Persona usuaria]                          │
│                            │                                  │
│                  [Interfaz: chat interno]                      │
│                            │                                  │
│               [Aplicación / coordinador]                      │
│                  /         │          \                        │
│ [Fuentes: política   [Modelo de    [Integración: sistema     │
│  e índice de         lenguaje]     de pedidos / CRM]         │
│  búsqueda]                                                   │
└───────────────────────────────────────────────────────────────┘

Para leer y defender el croquis, puedes contar una petición concreta sin atribuir poderes de más al modelo:

1. Una persona autorizada introduce la consulta en el chat. La interfaz muestra la conversación, pero la aplicación debe comprobar qué puede solicitar esa persona.
2. El coordinador busca el apartado pertinente de la política de devoluciones. Si se necesita el estado del pedido, consulta el sistema de pedidos con los permisos adecuados. Esas son dos conexiones con finalidades diferentes.
3. La aplicación proporciona al modelo la pregunta y el contexto necesario. El modelo redacta un borrador; no ha «aprendido» por ello una nueva política ni ha actualizado el pedido.
4. La aplicación presenta el borrador y, si corresponde, la referencia documental o el estado obtenido. Una persona comprueba la respuesta antes de enviarla. Si no hay información suficiente, la salida esperada es reconocer el límite y pedir ayuda, no inventar un dato.
5. La supervisión permite detectar errores, incidencias y patrones de uso. Sus controles pueden situarse en diferentes componentes reales; el borde del croquis significa que deben contemplarse en todo el servicio, no que exista un único producto que los resuelva.

El coordinador ocupa el centro porque hace explícitas decisiones que de otro modo quedan ocultas: qué fuente consultar, cuándo recurrir a una integración y qué hacer si falla. No tiene que ser necesariamente otro modelo o un complejo sistema de agentes; puede ser lógica de aplicación con reglas definidas.

Si trasladas este esquema a otro caso de uso, conserva los nombres de las funciones antes de añadir marcas o productos. Por ejemplo, «fuente documental: manual vigente» comunica mejor una dependencia al responsable del proceso que el nombre de un servicio de búsqueda. Después, el equipo técnico podrá indicar qué producto implementa cada función.

Qué debe revelar el diagrama durante un despliegue

Un buen esquema no solo muestra componentes presentes: también deja ver límites, responsables y preguntas pendientes. Para revisarlo con el cliente, comprueba estas distinciones:

En nuestro ejemplo, una métrica de calidad podría registrar cuántos borradores requieren corrección; una señal operativa, cuántas consultas al sistema de pedidos fallan. No sustituyen a las métricas de adopción, que desarrollarás más adelante: un asistente puede tener muchos usuarios activos y seguir dando respuestas poco fiables.

Supervisar tampoco es solo mirar un panel. Incluye definir quién atiende las excepciones, cómo se comunica un fallo, qué respuestas necesitan aprobación y quién actualiza la política documental. Si el plazo de devoluciones cambia y nadie mantiene la fuente, mejorar la redacción del modelo no arreglará el problema.

Al presentar esta arquitectura a perfiles no técnicos, una explicación suficiente sería: «El equipo pregunta desde su chat habitual; la aplicación consulta la norma vigente y, cuando está autorizado, el estado del pedido; el modelo prepara una respuesta; una persona revisa los casos previstos, y el servicio registra señales para detectar problemas». El equipo técnico podrá profundizar después en permisos, almacenamiento y conexiones concretas.

Cierre

Ya puedes diagramar un asistente distinguiendo interfaz, aplicación coordinadora, modelo, fuentes de datos, integraciones y supervisión. La distinción decisiva es que el modelo genera contenido, mientras que la aplicación organiza las consultas y aplica los límites de uso; ni los documentos ni los sistemas operativos deben quedar escondidos dentro de una caja llamada simplemente «IA».

En la próxima lección seguiremos los datos a través de esas conexiones. Eso permitirá identificar con más precisión los riesgos de privacidad, seguridad y uso indebido que este primer diagrama ha dejado a la vista.