🗺️ Qué es un blueprint de automatización
Uno blueprint es el plano de tu automatización: la especificación técnica que describe cada componente, qué entra y sale de cada uno y cómo se conecta todo — antes de abrir n8n o escribir una línea de código. Nadie construye una casa directamente sobre el terreno; primero diseñas el plano. Aquí es igual: el blueprint es donde pensar cuesta poco y los errores son fáciles de corregir.
🧱 Qué contiene un buen blueprint
- •El disparador: qué hace que la automatización comience.
- •Los componentes: cada paso, nombrado y clasificado por tipo.
- •Los datos: entrada, salida y formato de cada pieza.
- •Los planes B: qué pasa cuando algo falla.
- •La métrica de éxito: cómo sabrás que funcionó.
💡 Consejo práctico
Escribe el blueprint de forma que un colega que no vas a construir la automatización pueda entender qué hace con solo leerlo. Si lo entiende, la especificación está clara. Si necesitas explicarlo verbalmente, todavía hay ambigüedad oculta.
Describe qué hace, no cómo funciona técnicamente.
Corregir en papel cuesta minutos.
Comprensible para quien no lo construye.
Se actualiza a medida que aprendes.
🧩 Traducir el to-be en componentes
El diagrama to-be es un dibujo de intención. Para convertirse en blueprint, cada recuadro debe clasificarse en un tipo de componente: qué activa el proceso (trigger), qué mueve y transforma datos (pasos), qué razona (IA) y qué produce efectos en el mundo (acciones). Una caja del diagrama puede convertirse en uno o varios componentes.
✓ Traducción bien hecha
- ✓Cada componente tiene un nombre y un tipo claro.
- ✓Separa lo que es una regla fija de lo que necesita IA.
- ✓Enumera cuántas integraciones externas serán necesarias.
✗ Traducción perezosa
- ✗"La IA lo hace todo" — se convierte en una caja negra imposible de probar.
- ✗Usa IA cuando un IF simple resolvería el problema.
- ✗Olvidas las integraciones y solo te das cuenta al momento de construir.
Qué activa el flujo.
Mueve o transforma datos.
Interpreta y decide.
Produce un efecto en el mundo.
⛓️ Anatomía del flujo
La mayoría de las automatizaciones con IA sigue la misma estructura básica de seis etapas. Conocer este molde te evita inventar la estructura desde cero en cada caso: solo adaptas el nuevo problema a las seis etapas.
⚡ Trigger
Algo se activa: llega un correo electrónico, se envía un formulario, llega una hora programada o se llama a un webhook.
📥 Recopilación
El flujo reúne todo lo que la IA necesitará: el contenido que lo activó, más datos de APIs, bases de datos o archivos.
🧠 IA
El LLM interpreta el material recopilado y devuelve un análisis estructurado (clasificación, resumen, extracción).
🔀 Decisión
Según la salida de la IA, el flujo se ramifica: aprobar, escalar, archivar. La decisión está separada de la acción.
✅ Acción
El efecto en el mundo: enviar una respuesta, crear un registro, actualizar una hoja de cálculo, notificar a alguien.
📝 Registro
Todo queda registrado: entrada, decisión de la IA, acción realizada. Sin registro, no puedes depurar ni confiar.
💡 Consejo práctico
Mantén decisión y acción separadas. Si la IA decide y actúa en la misma etapa, no puedes insertar una aprobación humana entre ambas cuando la necesites. Decisión en un campo, acción en un paso siguiente: flexible y auditable.
Plantilla reutilizable.
Nunca es opcional.
Separadas y auditables.
No reinventar la rueda en cada caso.
📦 Datos de entrada/salida y formatos
Cada componente tiene un contrato: qué entra, qué sale y en qué formato. La mayoría de las automatizaciones falla en la conexión entre dos componentes: uno entrega en un formato que el siguiente no entiende. Definir los contratos en el blueprint resuelve ese problema antes de que aparezca.
🧾 Contrato de un componente de IA (ejemplo)
📐 Por qué JSON es la lengua franca
- •Toda herramienta de automatización lee y escribe JSON de forma nativa.
- •Los campos con nombre eliminan la ambigüedad de «dónde está cada información».
- •Es validable: puedes comprobar los tipos y los campos obligatorios antes de usarlo.
Entrada y salida por pieza.
Lengua franca entre componentes.
Marca lo que no puede faltar.
Dónde suele fallar el flujo.
🛡️ Puntos de falla y plan B
Para cada componente, pregunta: ¿qué puede salir mal? API fuera de servicio, dato faltante, IA sin certeza. Y para cada fallo, define qué hacer: reintentar, omitir, alertar a una persona o detenerse. Una automatización sin plan B es frágil: la primera excepción lo derriba todo.
✓ Resiliente
- ✓API inestable → reintento con espera creciente y luego una alerta.
- ✓Si la IA tiene poca confianza → escala a revisión humana.
- ✓Falla registrada y notificada; nunca silenciosa.
✗ Frágil
- ✗Un error de API interrumpe toda la ejecución.
- ✗La IA insegura actúa de todos modos, sin red de protección.
- ✗Falla silenciosa: nadie se da cuenta de que dejó de funcionar.
⚠️ Atención
El peor fallo es el silenciosa: la automatización se detiene o falla sin avisarle a nadie, y solo te enteras cuando se queja el cliente. Todo fallo debe quedar ruidosa — una alerta, un log destacado, una notificación. Fallar es aceptable; fallar sin que nadie lo note, no.
Detente ante fallas temporales.
Ruta alternativa segura.
Escalar cuando hay incertidumbre.
Nunca fallar en silencio.
📊 Criterios de éxito y métricas
Antes de construir, define qué cuenta como éxito: tiempo ahorrado, tasa de aciertos, porcentaje de casos que aún requieren intervención humana, costo por ejecución. Si no defines una métrica de antemano, nunca sabrás si la automatización es lo suficientemente buena — o si está creando más trabajo del que resuelve.
🎯 Métricas que vale la pena medir
- •Tiempo ahorrado: compara con la línea de base manual de la Trilha 2.
- •Tasa de acierto: % de casos resueltos correctamente sin retrabajo.
- •Intervención humana: % de casos que todavía necesitan a alguien.
- •Costo por ejecución: tokens de IA + llamadas a la API por ronda.
💡 Consejo práctico
Usa el baseline manual que mediste en la auditoría como referencia. Si el proceso llevaba 10 horas y costaba X, la automatización solo es un éxito cuando entrega el mismo resultado en una fracción del tiempo y por una fracción del costo, incluido el costo de los tokens.
Métrica definida desde el inicio.
El manual es la referencia.
Los tokens cuentan en el total.
Calidad, no solo velocidad.
🧠 Resumen del módulo
Próximo Módulo:
3.2 · Elección de herramientas y modelos — qué stack construye ese blueprint.