Mapa de la ruta
Contenido detallado
📋 Del proceso al blueprint
Cómo convertir el diagrama to-be de la T2 en un blueprint de automatización: componentes, anatomía del flujo, datos, puntos de falla y métricas de éxito.
Un blueprint es la especificación técnica de la automatización: un documento que describe cada componente, los datos que entran y salen, y cómo se conectan las piezas, antes de tocar cualquier herramienta.
Construir sin blueprint es improvisar en el editor: te pierdes, vuelves a hacer trabajo y descubres fallas tarde. El blueprint hace que el problema sea visible y barato de corregir en papel.
Especificación ≠ implementación · pensar antes de construir · un plan legible para quien no lo va a construir.
Tomar cada cuadro del diagrama to-be y clasificarlo en un tipo de componente: lo que dispara (trigger), lo que mueve o transforma datos (pasos), lo que razona (IA) y lo que produce un efecto en el mundo (acciones).
Sin esta traducción, el diagrama es solo un dibujo bonito. Clasificar en componentes revela exactamente cuántas integraciones, prompts y nodos vas a necesitar.
1 caja = 1 o más componentes · separar la lógica determinística de la IA · nombrar cada componente.
La estructura básica de casi toda automatización con IA sigue seis etapas: algo la activa, se recopilan datos, la IA interpreta, se toma una decisión, se ejecuta una acción y todo queda registrado.
Conocer la anatomía estándar te da un molde reutilizable: encajas cualquier caso nuevo en estas seis etapas en lugar de inventar la estructura desde cero.
6 etapas canónicas · el registro nunca es opcional · la decisión va separada de la acción.
Para cada componente, define explícitamente qué entra y qué sale, y en qué formato (texto, JSON, archivo, número). Es el contrato que conecta una pieza con la siguiente.
La mayoría de las interrupciones del flujo ocurre en la integración: un componente entrega un formato que el siguiente no entiende. Definir los formatos en el blueprint elimina este problema antes de que exista.
Contrato de datos · JSON como lengua franca · campos obligatorios vs. opcionales.
Mapea, para cada componente, qué puede salir mal (API fuera de servicio, dato faltante, IA sin certeza) y define el comportamiento de fallback: repetir, omitir, alertar a una persona o detenerse.
La automatización sin plan B es frágil: la primera excepción lo derriba todo. Anticipar fallas en el blueprint es lo que transforma un prototipo en algo realmente confiable.
Reintentos vs. alternativa · intervención humana · fallar de forma visible, nunca silenciosa.
Define, antes de construir, qué cuenta como éxito: tiempo ahorrado, tasa de aciertos, % de casos que requieren intervención humana, costo por ejecución.
Sin definir una métrica de éxito de antemano, nunca sabes si la automatización es lo suficientemente buena para entregarla o si, en realidad, está creando más trabajo.
Métrica antes de la construcción · línea base manual · el costo por ejecución cuenta.
🧰 Elección de herramientas y modelos
¿n8n, Make o código? ¿Qué LLM? Cuándo entran RAG, MCP, APIs y bases de datos. Criterios de decisión y trade-offs para armar el stack adecuado para el blueprint.
Tres caminos para orquestar la automatización: n8n (low-code, self-host, flexible), Make (visual, SaaS, rápido para empezar) y código puro (máximo control, máximo mantenimiento).
Elegir mal la base sale caro después: te topas con límites de licencia, falta de un conector o una complejidad que el low-code no soporta. Elegir con criterio evita una migración futura.
Low-code vs. código · self-host vs. SaaS · el costo de mantenimiento es parte del costo.
Decidir si la tarea realmente necesita un LLM (frente a una regla/regex) y, si lo necesita, qué modelo usar: uno pequeño y económico para clasificar, uno grande y costoso para razonamientos complejos.
Usar el modelo más caro en todo quema el presupuesto; usar el más barato en una tarea difícil quema la confiabilidad. Adaptar el modelo a la tarea es lo que mantiene los costos y la calidad bajo control.
Un LLM no es la respuesta para todo · modelo pequeño para tarea simple · costo por token × volumen.
RAG (Retrieval-Augmented Generation) busca fragmentos relevantes de una base de conocimiento propia y los inyecta en el prompt, para que la IA responda con base en tus documentos y no solo en su entrenamiento.
Cuando la automatización depende de información que solo existe en tu empresa (políticas, catálogo, historial), RAG es lo que evita que la IA invente cosas y la mantiene anclada en la realidad.
Recuperar antes de generar · embeddings y búsqueda semántica · RAG solo cuando hay conocimiento propio.
MCP (Model Context Protocol) es un estándar para conectar la IA con herramientas externas —leer archivos, consultar bases de datos, llamar APIs— de forma uniforme, sin código de integración para cada conexión.
Cuando la automatización requiere que la IA actúe (no solo responda), MCP estandariza ese acceso. Entender cuándo usarlo evita reinventar conectores y mantiene la stack escalable.
Protocolo estandarizado · IA que usa herramientas · reutilización de conectores.
Las tuberías de la automatización: APIs (pides datos), webhooks (el sistema te avisa) y bases de datos (guardas y consultas el estado), con Supabase como ejemplo de base de datos + API + auth en un solo paquete.
Casi toda automatización útil necesita obtener, recibir o persistir datos. Saber la diferencia entre API y webhook, y cuándo necesitas una base de datos, es lo que conecta el flujo con el mundo real.
Pull (API) vs. push (webhook) · el estado necesita una base de datos · Supabase como atajo.
Un conjunto de criterios para comparar opciones: costo, velocidad de entrega, mantenimiento, control, límites de escalabilidad y dependencia del proveedor, además del reconocimiento de que cada elección implica un intercambio.
Tomar decisiones sobre la tecnología por moda o costumbre cuesta caro. Un cuadro explícito de ventajas y desventajas te obliga a justificar cada elección y a defenderla ante el cliente.
No existe una opción sin costo · criterio explícito · si hay empate, gana la opción simple.
🎯 Diseño de prompts y lógica de decisión
El prompt es el corazón de la automatización con IA. Estructura confiable, salida en JSON validable, guardrails, ramificación a partir de la IA y el ciclo de pruebas e iteración.
Tratar el prompt no como una conversación, sino como una parte de la especificación: instrucciones precisas y sin ambigüedades que definan exactamente el comportamiento esperado de la IA dentro del flujo.
En la automatización no hay una persona que corrija la IA en tiempo real. El prompt debe estar bien desde el principio: es código que se ejecuta solo mil veces.
Prompt = código en lenguaje natural · cero ambigüedad · escribir para la máquina, no para conversar.
Una estructura reutilizable: definir el rol de la IA, darle el contexto necesario, especificar la tarea, fijar el formato de salida y enumerar las reglas y restricciones.
Los prompts ad hoc dan resultados inconsistentes. Una estructura fija hace que el comportamiento sea predecible y que el prompt sea fácil de revisar y mantener.
Papel + contexto + tarea + formato + reglas · secciones con nombre · plantilla reutilizable.
Pedirle a la IA que responda en un JSON con campos fijos y validar esa respuesta antes de usarla, para garantizar que el siguiente paso del flujo siempre reciba la misma estructura.
El texto libre rompe la automatización: el siguiente paso no sabe dónde está cada dato. Un JSON validado es lo que hace que la salida de la IA sea lo bastante confiable como para alimentar una acción automática.
JSON con schema · validar antes de usar · rechazar y repetir si no es válido.
Las salvaguardas son límites en el prompt y en la validación (lo que la IA no puede hacer y lo que debe rechazar); la alternativa es lo que ocurre cuando la IA no está segura o se sale de las reglas: pedir confirmación, escalar o usar un valor predeterminado.
La IA comete errores y alucina. Las barreras de seguridad y el fallback son lo que impide que un error se convierta en una acción irreversible ejecutada automáticamente.
Limitar lo que la IA puede hacer · campo de confianza · ruta segura cuando hay incertidumbre.
Usar un campo de la salida JSON de la IA (p. ej., categoría, prioridad) como clave de una decisión IF/switch en el flujo, y dirigir cada caso a una acción diferente.
Aquí es donde la IA deja de ser un adorno y se convierte en el cerebro de la automatización: clasifica y el flujo se ramifica. Saber diseñar este puente es lo que hace que la automatización sea realmente inteligente.
La IA decide, el flujo ejecuta · el campo categórico como clave · una rama por caso + rama predeterminada.
Crear un conjunto de casos de prueba (incluidos casos difíciles y adversariales), ejecutar el prompt con todos, medir la tasa de aciertos y ajustar el prompt hasta que se estabilice.
Un prompt que funciona en un ejemplo puede fallar en diez. Solo un ciclo de pruebas con casos reales te da confianza para poner a la IA a decidir sola en producción.
Conjunto de pruebas · primero los casos difíciles · iterar hasta estabilizar la tasa de acierto.