Hay un momento bastante reconocible en los equipos que empiezan a trabajar con IA.
Alguien dice que habría que “meter RAG”. Otra persona propone “hacerlo agente”. Alguien más pregunta si el sistema va a tener memoria, si conviene automatizar el flujo, si hace falta conectar herramientas externas o si no sería mejor usar un modelo más potente.
La conversación parece técnica. Y en parte lo es.
Pero no se trata sólo de lo técnico.
Ahí se está decidiendo cuánto va a recordar el producto, desde qué fuentes va a responder, qué puede tocar, qué errores son tolerables, cuánto tiempo puede demorarse, cuándo debe pedir confirmación y hasta qué punto puede actuar sin una persona aprobando cada paso.
Todo eso afecta la experiencia.
No de una manera abstracta, sino que en cosas muy concretas: si el usuario tiene que repetir lo mismo cada vez, si puede confiar en una fuente, si entiende por qué el sistema no respondió, si puede deshacer una acción, si sabe cuándo está leyendo una respuesta fundada y cuándo sólo está viendo una inferencia plausible.
Esto no es un revival de la vieja conversación sobre si los diseñadores deben programar. Porque no creo que un diseñador tenga que volverse ingeniero para participar de esa conversación, así como tampoco creo que alcance con decir “eso es técnico” y esperar a que alguien traduzca después.
Entre esas dos posiciones hay un espacio más interesante: entender lo suficiente para saber qué se está decidiendo.
Ése es el punto de esto que escribo acá.
No es un glosario para aprender siglas. Es un mapa mínimo para reconocer cuándo una decisión técnica también está diseñando producto.
Lo técnico no se queda atrás de la interfaz
En una aplicación tradicional, muchas decisiones de arquitectura quedan lejos de la superficie. No siempre, pero muchas veces es así. El usuario ve pantallas, formularios, validaciones, estados, mensajes de error. La arquitectura sostiene todo eso, pero no siempre aparece en la experiencia de manera tan directa.
En productos con IA esa distancia se acorta.
La memoria no es sólo persistencia de datos: puede hacer que una conversación se sienta continua o absurda. La recuperación de conocimiento no es sólo infraestructura: puede hacer que una respuesta sea verificable o apenas convincente. La elección de modelo no es sólo proveedor y costo: puede cambiar latencia, calidad y viabilidad comercial. La autonomía no es sólo una capacidad nueva: cambia quién controla la acción y quién responde cuando algo sale mal.
Por eso me interesa hablar de estos conceptos desde diseño, no desde implementación.
No para reemplazar a ingeniería. Para dejar de mirar la experiencia como si ocurriera sólo en la pantalla visible. Porque recordemos que un producto de IA no es sólo un modelo con una interfaz encima.
1. Contexto: qué necesita recordar el sistema
Contexto suele sonar a “darle más información a la IA”. Y sí, en parte es eso. Pero en un producto real la palabra se vuelve más delicada.
Contexto puede ser el historial de una conversación, el estado actual de una tarea, documentos adjuntos, preferencias del usuario, reglas del producto, restricciones legales, datos recuperados de un sistema interno o decisiones tomadas en pasos anteriores.
La pregunta de diseño no es cuánta información podemos meter.
Es qué información necesita el sistema para no obligar al usuario a repetir, corregir o reconstruir la interacción.
Si el sistema debe acompañar una conversación larga, mantener continuidad o adaptarse a una persona, el contexto se vuelve parte central de la experiencia. Si sólo debe resolver una tarea puntual, quizá no necesita memoria. Y esa diferencia cambia la arquitectura, el costo y el comportamiento esperado.
Un chat de soporte que mantiene el estado de un caso necesita recordar qué problema se reportó, qué pasos ya se probaron y qué información no debería volver a pedir. Un botón que redacta una respuesta puntual quizá sólo necesita el texto de entrada, el tono esperado y una confirmación antes de enviar.
En los dos casos hay IA. Pero no estamos diseñando la misma experiencia.
2. System prompt vs. user prompt: qué define el producto y qué pide el usuario
El user prompt es lo que escribe el usuario. Puede ser claro, ambiguo, incompleto o tan mínimo como “sí, dale”.
Ese “sí, dale” no significa casi nada por sí solo. Funciona porque hay una conversación previa, un estado, un producto interpretando lo que está pasando y una instrucción de sistema que enmarca la respuesta.
El system prompt es otra cosa: una instrucción estructural que define qué es el producto, cómo responde, qué límites tiene, qué tono usa, qué debe evitar y qué rol cumple.
Ahí hay una decisión de diseño enorme, aunque muchas veces quede escondida en una configuración.
¿El sistema guía o espera instrucciones? ¿Cierra rápido o explora? ¿Advierte incertidumbre? ¿Pide confirmación antes de avanzar? ¿Muestra límites? ¿Habla como especialista, asistente, tutor o herramienta operativa?
No hace falta que diseño escriba literalmente todo el system prompt. Pero si no participa de esas decisiones, una parte crítica de la experiencia conversacional queda decidida por defecto.
3. RAG: cuándo el modelo base no alcanza
RAG permite que un sistema use conocimiento externo: documentación interna, bases de conocimiento, políticas, tickets, investigaciones, artículos, datos de clientes o información actualizada.
La sigla puede intimidar un poco, pero la decisión de fondo es bastante simple: ¿la respuesta necesita estar anclada en fuentes específicas y confiables?
Si el sistema responde desde conocimiento general, puede sonar razonable y aun así estar equivocado para ese dominio. Si responde desde fuentes propias, puede volverse más útil, más trazable y más defendible. Pero también depende de la calidad, vigencia y estructura de esas fuentes.
RAG no mejora un mal problema. Sólo hace posible que el sistema responda desde un conocimiento que el modelo no trae incorporado.
Por eso, antes de discutir la técnica, conviene discutir la expectativa de la experiencia: ¿queremos una respuesta creativa, una orientación general o una respuesta verificable contra una fuente?
No es la misma promesa.
4. Embeddings: buscar por significado, no sólo por palabras
Los embeddings convierten contenido en representaciones semánticas. En simple: permiten encontrar información por cercanía de significado, no sólo por coincidencia literal.
Esto parece un detalle técnico hasta que aparece un caso real.
No es lo mismo buscar “cancelación de cuenta” que encontrar documentos relacionados con baja, churn, cierre de servicio, solicitud de eliminación o término de contrato. Una búsqueda literal puede perder relaciones importantes. Una búsqueda semántica puede recuperarlas mejor, pero también puede traer resultados cercanos que no eran los correctos.
Ahí aparece la decisión de producto: qué tipo de recuperación necesita esta experiencia para ser útil y confiable.
Cuando el sistema debe trabajar con investigación, documentación, soporte o conocimiento interno, esta pregunta importa mucho. No porque diseño deba configurar una base vectorial, sino porque debe entender que la calidad de la respuesta empieza antes de que el modelo escriba.
5. Orquestación: lo que ocurre antes de la respuesta
La orquestación es una de esas palabras que suenan más sofisticadas de lo que necesitan. En simple, es todo lo que coordina el sistema antes de responder: qué modelo usar, qué contexto enviar, qué herramienta llamar, qué datos recuperar, cómo transformar una solicitud vaga, cómo registrar memoria, cómo manejar errores.
Esto es clave porque un producto con IA rara vez es “un modelo respondiendo”.
Suele ser un sistema que toma decisiones intermedias: clasifica intención, recupera información, elige modelos, consulta herramientas, resume contexto, valida límites y recién después genera una respuesta visible.
La orquestación puede hacer invisible mucha complejidad. Pero si está mal diseñada, esa complejidad aparece como lentitud, respuestas incoherentes, pérdida de contexto o falta de confianza.
Una mala experiencia no siempre revela una mala respuesta del modelo. A veces revela una mala coordinación del sistema.
Y eso también se diseña.
6. MCP: conectar la IA con herramientas externas
MCP funciona como un estándar para conectar sistemas de IA con herramientas externas: archivos, bases de datos, Google Drive, Analytics, Figma, repositorios, CRMs u otros servicios.
No me interesa acá que el diseñador memorice el protocolo; lo importante es la consecuencia: el sistema deja de estar encerrado en la conversación y empieza a relacionarse con el entorno de trabajo.
Puede consultar datos, traer archivos, leer una planilla, interactuar con un sistema de diseño, crear un ticket o modificar algo.
Eso abre valor, pero también abre riesgo. Para diseño, la conversación no debería quedarse en “podemos conectarlo”. Debería avanzar hacia “qué debería poder hacer”, “qué no debería poder hacer” y “cómo se entera el usuario de lo que está pasando”.
Qué puede ver el sistema, qué puede tocar, con qué permisos y con qué registro no son detalles secundarios. Son parte de la experiencia de control.
7. Automatización: cuando el flujo está definido
Automatizar no significa necesariamente usar IA. Una automatización es un flujo definido: ocurre algo, se procesan datos, se ejecutan pasos, se notifica, se guarda, se clasifica, se crea una tarea.
Puede incluir IA en una parte del proceso, pero no necesita que todo sea generativo.
Para diseño, la pregunta práctica es si tenemos un flujo suficientemente claro como para automatizarlo.
Si el flujo es repetible, estable y tiene condiciones definidas, una automatización puede ser mejor que un sistema conversacional abierto. Si el problema sigue ambiguo, automatizar puede sólo escalar una mala decisión.
No todo necesita una conversación. A veces la mejor experiencia es que el sistema haga bien un proceso conocido, muestre estado, permita revisar y tenga un buen fallback cuando algo falla.
8. Agentes: autonomía con responsabilidad
Un agente no es simplemente “un chatbot más inteligente”. Ésa es una confusión frecuente y cara.
Un agente recibe un objetivo, usa herramientas, toma pasos intermedios y puede ejecutar acciones con distintos grados de autonomía.
Un asistente responde, mientras un agente actúa.
Y cuando un sistema actúa, aparecen preguntas de responsabilidad: ¿puede decidir solo?, ¿cuándo debe pedir confirmación?, ¿qué acciones están prohibidas?, ¿qué errores son tolerables?, ¿quién responde si falla?, ¿qué registro queda de lo que hizo?
Por eso los agentes no deberían ser el nivel por defecto. Son útiles cuando el retorno justifica la autonomía y cuando existen límites, supervisión y trazabilidad.
Si el sistema puede reservar, comprar, borrar, publicar, cambiar permisos o modificar datos, la conversación deja de ser sólo sobre eficiencia. Pasa a ser una conversación sobre control.
Lo mínimo técnico no es una lista de términos
Me interesa poco que un diseñador pueda recitar qué significa RAG, MCP u orquestación si después no puede usar esa distinción para mejorar una decisión.
El valor de esta alfabetización técnica mínima aparece en conversaciones concretas.
Cuando alguien propone “usar IA”, diseño puede preguntar si el problema realmente la necesita o si una solución determinista resolvería mejor, con menos costo y menos riesgo.
Cuando aparece la idea de memoria, puede preguntar qué debería recordar el sistema, por cuánto tiempo, con qué visibilidad para el usuario y con qué derecho a corrección.
Cuando alguien propone RAG, puede preguntar qué fuentes sostienen la respuesta, cómo se actualizan y qué ocurre cuando no hay evidencia suficiente.
Cuando aparecen embeddings, puede preguntar si necesitamos recuperar coincidencias literales o relaciones de significado, y cómo vamos a evaluar si la recuperación fue buena.
Cuando se habla de orquestación, puede preguntar qué pasos ocurren antes de responder y dónde puede fallar la experiencia aunque el modelo sea bueno.
Cuando se habla de MCP o herramientas, puede preguntar qué puede ver o ejecutar la IA, qué permisos necesita y cómo se informa eso al usuario.
Cuando se propone automatizar, puede preguntar si el flujo está realmente definido o si todavía estamos tratando de automatizar ambigüedad.
Cuando alguien propone agentes, puede preguntar qué autonomía estamos aceptando, qué riesgo aparece y dónde debe permanecer la decisión humana.
No son preguntas para frenar el trabajo. Son preguntas para evitar que el producto avance con una experiencia decidida por inercia.
Porque muchas iniciativas con IA no fallan por falta de modelo. Fallan porque el problema estaba mal definido, porque se eligió IA donde no hacía falta, porque no había datos suficientes, porque nadie explicitó el riesgo o porque la experiencia quedó armada a partir de decisiones técnicas que nadie tradujo a criterios de producto.
Lo mínimo técnico para diseñadores no es aprender a implementar la arquitectura.
Es aprender a reconocer cuándo la arquitectura ya está diseñando la experiencia.
