Cuando un producto con IA responde mal, la explicación más rápida suele ser: “falló el modelo”.
Es entendible. Para la mayoría de las personas, la experiencia completa aparece como una sola cosa: abres una aplicación, escribes algo, recibes una respuesta. Si la respuesta es pobre, insegura, inventada, demasiado obediente o demasiado segura de sí misma, parece natural atribuirlo a “la IA”.
Pero esa explicación suele ser demasiado corta.
En muchos productos con IA, el modelo es sólo una parte del sistema. Una parte importante, sí, pero no la única que define la experiencia. La respuesta que recibe una persona depende también de qué contexto se le entregó al modelo, qué instrucciones lo gobiernan, qué historial se recuperó, qué fuentes pudo consultar, qué herramientas tenía disponibles, qué límites se diseñaron y cómo el producto decidió presentar la respuesta.
Un producto con IA no es un modelo con una interfaz encima.
Es un sistema que organiza contexto, memoria, reglas, herramientas y límites alrededor del modelo.
Y esa distinción cambia el lugar desde donde diseño mira el problema.
El modelo no recuerda
Una de las ideas que más cambia la perspectiva cuando empezamos a diseñar con IA es esta: el modelo, por sí sólo, no tiene memoria ni estado propio entre llamadas.
No “recuerda” la conversación como una persona. No conserva una historia interna estable sobre ti, tu equipo o tu producto. No sabe qué pasó antes salvo que el sistema vuelva a entregarle esa información en el momento de responder.
Lo que llamamos memoria en un producto con IA suele ser una construcción del sistema.
El producto decide qué historial guardar, qué partes recuperar, qué datos del usuario considerar, qué fuentes consultar, qué reglas incluir, qué herramientas habilitar y cómo empaquetar todo eso para que el modelo produzca una respuesta útil.
La memoria no está simplemente “dentro” del modelo.
Está en el sistema que decide qué volver a poner frente al modelo cada vez.
Ése es el punto donde la conversación deja de ser sólo técnica y se vuelve profundamente relevante para diseño. Porque si la experiencia depende de qué contexto se construye, qué se recuerda, qué se excluye y qué se permite hacer, entonces muchas decisiones de experiencia ya se están tomando antes de que exista una pantalla final.
Una aclaración antes de pasar al mapa: en este artículo uso “modelo” como atajo para hablar de modelos de IA generativa, especialmente LLMs, aunque la misma lógica puede aplicar a modelos de imagen, audio o video. La distinción importante no es el tipo de modelo, sino que el modelo no equivale al producto.
Entonces, ¿de dónde sale la experiencia inteligente?
Cuando miramos un producto basado en IA como sistema, aparece una arquitectura más completa.
Está el usuario, que llega con una intención, una expectativa y un prompt. Está la capa de experiencia, donde se decide cómo se conversa, qué interfaz aparece, cómo se gestiona la intención y qué contexto se vuelve visible. Está el orquestador, que arma la solicitud que realmente llegará al modelo. Está la memoria y estado del producto, donde se seleccionan historial, datos, documentos, outputs anteriores y estado del sistema. Están las fuentes externas, muchas veces organizadas mediante RAG. Están las herramientas, como conectores MCP o búsqueda web, que permiten consultar sistemas, ejecutar acciones o traer información actualizada. Está el system prompt, que define reglas de comportamiento. Y recién después están los modelos de IA que responden con lo que el producto les construyó como entrada.
Visto así, el output no viene “del modelo” en abstracto.
Viene de una cadena de decisiones.
Algunas son técnicas. Otras son de producto. Muchas son de experiencia, aunque no siempre se nombren así.
Por eso el gráfico importa. No porque convierta a diseño en arquitectura de software, sino porque muestra dónde se produce realmente la experiencia.
Este esquema viene del curso de IA para Diseñadores, donde lo trabajamos con más detalle. Lo importante para esta pieza es la idea de fondo: el gráfico no agrega complejidad técnica por deporte; muestra las capas donde también se toman decisiones de experiencia.
Qué diseña diseño en cada capa
La pregunta para diseño no es “¿tengo que implementar RAG, MCP o una API?”.
La pregunta es qué decisiones de experiencia viven en esas capas y qué pasa si diseño no participa en ellas.
Usuario y prompt
El prompt no es sólo un texto que alguien escribe. Es una entrada de interacción.
Diseño tiene que entender qué intención trae la persona, qué sabe formular, qué no sabe pedir, qué nivel de ambigüedad es aceptable y cuándo conviene agregar fricción útil. A veces una caja de texto abierta es suficiente. A veces no. A veces el sistema necesita guiar, pedir aclaración, ofrecer ejemplos o limitar el tipo de solicitud que acepta.
La calidad de una experiencia con IA no empieza en la respuesta. Empieza en cómo se diseña la entrada.
Capa de experiencia
La capa de experiencia es lo que diseño reconoce primero: diseño conversacional, interfaz gráfica, gestión de la conversación, gestión del contexto, gestión de la intención y personalización.
Pero en productos con IA esa capa no vive aislada. Lo que aparece en pantalla depende de decisiones tomadas más abajo: qué se sabe del usuario, qué se recupera, qué se recuerda, qué herramientas están disponibles y qué solicitud se construye para el modelo.
Por eso diseñar la interfaz sin entender el sistema puede producir una ilusión de control. La pantalla puede verse clara, pero la experiencia real se está decidiendo en otra parte.
Orquestador
El orquestador es la parte del producto que coordina qué información entra, qué herramientas se consultan, qué memoria se recupera y cómo se arma la solicitud que llega al modelo.
Para diseño, esta capa importa porque muchas decisiones de experiencia se vuelven decisiones de orquestación: cuándo pedir más información, cuándo consultar una fuente, cuándo usar una herramienta, cuándo bloquear una acción, cuándo mostrar una vista previa y cuándo responder que no hay suficiente evidencia.
El orquestador no es sólo una pieza técnica. Es una forma de convertir intención, contexto y límites en comportamiento.
Contexto
El contexto es lo que el sistema le entrega al modelo para que pueda responder.
Puede incluir información del usuario, estado actual de una tarea, datos del producto, criterios de negocio, historial relevante, reglas de marca, permisos, restricciones o decisiones anteriores.
Para diseño, la pregunta no es sólo qué información existe. Es qué información debería entrar en cada momento para que la respuesta sea útil, pertinente y segura.
Demasiado poco contexto vuelve la respuesta genérica. Demasiado contexto puede contaminarla, hacerla confusa o exponer información que no debería usarse. Contexto no es acumulación, es selección.
Memoria y estado del producto
Si el modelo no recuerda entre llamadas, la continuidad debe diseñarse en la memoria y estado del producto.
¿Qué conviene guardar? ¿Qué debe olvidarse? ¿Qué historial importa para una tarea y cuál sólo agrega ruido? ¿La persona puede ver, corregir o borrar esa memoria? ¿El sistema distingue entre preferencias estables, acciones recientes y datos sensibles?
La memoria, cuando existe, no es sólo una feature, es una decisión de confianza.
System prompt, reglas y restricciones
El system prompt y las reglas definen cómo debería comportarse el sistema: qué debe priorizar, qué tono debe usar, qué límites no puede cruzar, cuándo debe negarse, cuándo debe pedir más información y qué tipo de respuesta no debería producir.
Esto afecta directamente la experiencia.
Un chatbot que acepta instrucciones indebidas no falló sólo porque “el modelo obedeció”. También falló porque el sistema no diseñó límites, pruebas, permisos y comportamiento ante abuso.
Desde diseño, estas reglas no son un detalle invisible. Son parte del contrato de interacción.
RAG y fuentes
RAG, o retrieval augmented generation, suele aparecer como una forma de conectar el modelo con fuentes externas. En simple: el sistema busca información relevante y se la entrega al modelo para responder mejor.
En el diagrama, esa recuperación puede venir de una base de datos vectorial, una base de datos tradicional o una API. Para diseño, la diferencia importa menos como implementación que como criterio: cada fuente tiene niveles distintos de actualidad, precisión, trazabilidad, permisos y riesgo.
Pero diseñar RAG no es sólo decidir “que consulte documentos”.
Hay que decidir qué fuentes son válidas, cómo se recuperan, cómo se priorizan, cuándo una fuente alcanza para responder, cuándo no, cómo se citan y qué debe hacer el sistema cuando no encuentra evidencia suficiente.
Los casos de respuestas con fuentes inventadas no son sólo un problema de “alucinación”. Muchas veces son un problema de retrieval, verificación y comunicación de límites.
Si el sistema no distingue entre saber, inferir y no saber, la experiencia puede sonar confiable incluso cuando no lo es.
Herramientas, APIs y MCP
Las herramientas y APIs permiten que un sistema con IA haga algo más que responder texto: consultar una base de datos, crear un ticket, buscar disponibilidad, modificar un archivo, activar un flujo, traer información externa o ejecutar una acción.
MCP aparece como una forma de estandarizar el acceso a herramientas y contexto. Para diseño, el punto no es memorizar la sigla, sino entender que el modelo puede conectarse con capacidades externas y que esas capacidades cambian la experiencia, por ejemplo, conectarse a un CRM para conocer la historia de un cliente.
Cuando una IA puede actuar, buscar o conectarse con otros sistemas, no sólo conversar, aparecen preguntas de diseño más exigentes:
- qué acciones puede ejecutar;
- con qué permisos;
- con qué confirmación;
- en qué casos debe mostrar una vista previa;
- cuándo debe pedir autorización;
- cómo se revierte una acción;
- qué pasa si una herramienta falla;
- cómo se explica al usuario qué hizo el sistema.
Esto ya no es sólo diseño conversacional. Pasa a ser diseño de acción, control y responsabilidad.
Solicitud construida y modelos de IA
El usuario escribe un prompt, pero el modelo no recibe necesariamente sólo eso.
El producto puede construir una solicitud mucho más compleja: prompt del sistema, prompt de usuario, contexto seleccionado, fuentes recuperadas, estado del sistema, resultados de herramientas y restricciones. Esa solicitud construida es una de las capas más importantes de la experiencia, aunque el usuario no la vea.
También puede haber más de un modelo disponible. A veces el sistema decide qué modelo usar según costo, velocidad, tipo de tarea, nivel de riesgo o calidad esperada.
Para diseño, esto abre otra pregunta: qué tipo de experiencia queremos producir y qué criterios debería usar el producto para decidir cómo pedir, a quién pedir y con qué información pedir.
Respuesta, certeza y trazabilidad
La respuesta final no debería evaluarse sólo por si “suena bien”.
En productos con IA, la forma de responder también debe comunicar certeza, fuentes, límites y próximos pasos. A veces la mejor respuesta no es una afirmación segura. Puede ser una respuesta condicionada, una pregunta de aclaración, una negativa, una cita verificable o una explicación de por qué el sistema no puede responder con suficiente respaldo.
Cuando una IA responde con total confianza, sin fuentes ni grado de certeza, el problema no está sólo en el modelo. También está en una experiencia que no diseñó señales de confianza.
Diseñar una respuesta con IA implica decidir qué se muestra, qué se oculta, qué se atribuye, qué se puede verificar y cómo se ayuda a la persona a calibrar la confianza.
Los errores se parecen menos cuando miramos el sistema
Vistos desde fuera, los errores de IA parecen casos aislados.
Un chatbot que acepta instrucciones que no debería aceptar. Un texto profesional que cita fuentes inexistentes. Una respuesta segura que no permite verificar de dónde salió la información. Una herramienta que sorprende al usuario porque ejecuta una acción sin explicar bien qué hizo.
Pero si los miramos como sistema, empiezan a aparecer patrones.
En algunos casos falta diseño de límites y pruebas. En otros, retrieval y verificación. En otros, trazabilidad. En otros, permisos, confirmaciones o manejo de incertidumbre.
El problema no era simplemente “la IA falló”.
El problema era que la experiencia dependía de capas que no estaban bien diseñadas.
Por qué diseño tiene que estar en esa conversación
Si diseño no participa en las conversaciones técnicas para hacerse cargo de la experiencia, otras personas van a tomar decisiones de experiencia por nosotros.
Eso no significa que diseño tenga que escribir el código del sistema, definir la arquitectura completa o resolver cada decisión técnica. Pero sí significa que necesita entender el mapa mínimo: dónde se arma el contexto, dónde, cuándo y para qué se guarda memoria, dónde se definen reglas, dónde se conectan herramientas, dónde se consultan fuentes y dónde se comunican límites.
Porque en cada una de esas capas hay decisiones que afectan la experiencia.
Qué recuerda el sistema afecta confianza. Qué fuentes consulta afecta credibilidad. Qué herramientas puede usar afecta control. Qué reglas sigue afecta seguridad. Qué muestra en la respuesta afecta comprensión. Qué no dice afecta riesgo.
Diseñar con IA no significa convertirse en ingeniero.
Pero sí exige dejar de mirar el modelo como si fuera el producto.
En un producto con IA, la responsabilidad de diseño es definir el sistema que decide qué le llega al modelo, qué puede hacer con eso y cómo convierte su respuesta en una experiencia confiable.
Esa alfabetización técnica mínima no es una moda. Es una condición para seguir diseñando experiencia cuando la experiencia ya no ocurre sólo en la interfaz visible.
💡 Si llegaste hasta acá, seguramente te interesará mi curso IA para Diseñadores, desde donde sale este contenido.
