🛠️ Máquina — Cómo construir y operar
Boring es hermoso. Aprende a montar pipelines de IA como líneas de ensamblaje: cada bloque hace un trabajo, cada salida se valida antes de pasar a la siguiente y todo el sistema se puede apagar sin culpa.
Lego Principle + línea de ensamblaje: bloques modulares, validación en cada eslabón, IA solo donde sea necesario
Contenido detallado
Lego Principle — El paso más pequeño posible
Cada bloque de tu sistema debe tener exactamente 1 entrada y 1 salida. La salida del bloque 1 es la entrada del bloque 2. Esta modularidad no es solo elegancia: es la diferencia entre un sistema que entiendes y uno que te domina.
🧱 Principio central
Empieza por los pasos sin IA — los determinísticos. Si puedes hacerlo con código simple (parseo, validación, formato), hazlo así. La IA solo entra donde realmente agrega valor. Esto reduce el costo, la latencia y los puntos de falla.
✓ Qué HACER
- ✓1 entrada → transformación → 1 salida por bloque
- ✓Nombra los bloques según lo que hacen («clasifica la intención», «da formato a la respuesta»)
- ✓Mantén los bloques lo suficientemente pequeños para probarlos de forma aislada
- ✓Documentar el contrato de I/O de cada bloque
✗ Qué NO hacer
- ✗Crear un "mega prompt" que haga parse + razonamiento + formato + envío
- ✗Bloques con 3+ entradas de diferentes fuentes simultáneas
- ✗Usar IA cuando el código determinístico resuelve igual de bien
- ✗No documentes el esquema de salida esperado
Línea de ensamblaje — Especialización por llamada
No construyas un generalista. Una llamada de IA debe hacer UN trabajo especializado: o escribe textos publicitarios, o razona sobre datos, o clasifica la intención. Mezclar tareas hace que el sistema sea difícil de depurar y mejorar.
📊 Por qué gana la especialización
- • Prompt más corto → menor costo
- • Evaluación directa: resultado correcto o incorrecto
- • Cambia de modelo sin reescribir todo
- • Fine-tuning posible en una tarea aislada
- • Prompt gigante → contexto saturado
- • Un fallo en A → afecta a B y C
- • Imposible sustituir solo la parte mala
- • Latencia alta para tareas simples
💡 Consejo práctico
Si necesitas cambiar el prompt porque la clasificación empeoró, no debería ser necesario revalidar la parte de formato. Si ambos están en el mismo paso, avanzas. Sepáralos.
Validation Chain — Valida antes de encadenar
No construyas todo el pipeline para probarlo al final. Valida el resultado de cada bloque antes de conectar el siguiente. Bloque 1 → ejecútalo → confirma → bloque 2 con el resultado real → confirma → encadena.
🔗 El protocolo de encadenamiento seguro
✓ Validation Chain correcta
- ✓Ejecuta cada bloque con datos reales antes de conectarlo
- ✓Define el esquema de salida esperado (JSON schema, regex, enum)
- ✓Falla rápido y explícitamente en cada eslabón
- ✓Usa output real (no mock) para probar el siguiente bloque
✗ Antipatrón frecuente
- ✗Armar el pipeline completo y probar al final
- ✗Usar datos simulados para simular el output intermedio
- ✗Asumir que «si el bloque 1 funciona, el bloque 2 también funcionará»
- ✗Sin un esquema definido → no sabes qué validar
Mentalidad de iteración — No hay un producto terminado con IA
Los scripts deterministas PUEDEN estar «listos». Los pasos de IA evolucionan constantemente: el modelo mejora, el contexto cambia y el uso real revela casos límite. El perfeccionismo es enemigo del deploy. Publica el POC y amplíalo a partir del uso real.
🚀 La regla de empezar por el POC
Un sistema de IA en producción con un 70% de calidad, funcionando y generando datos reales, enseña más en 1 semana que 2 meses de iteración offline. El uso real revela lo que el entorno de pruebas nunca mostrará.
✓ Mentalidad de iteración
- ✓Pon el POC en marcha cuanto antes y observa el uso real
- ✓Mejora basada en datos de producción, no en suposiciones
- ✓Acepta que los pasos de IA nunca están «completos»
- ✓Versionado de prompts como código
✗ Perfeccionismo paralizante
- ✗Semanas iterando sin conexión antes del primer deploy
- ✗"Tiene que estar 100% listo antes de pasar a producción"
- ✗Medir la calidad solo con benchmarks artificiales
- ✗Tratar el prompt como código final sin control de versiones
Bike Method — implementación en 4 fases
Incluso un sistema con un 90% de confianza debe empezar con el 10% del volumen. El Bike Method define cuatro fases de autonomía creciente, y solo avanzas cuando los datos lo justifican.
🚲 Las 4 fases de autonomía
Umbrales: confianza alta → automático, media → cola de borradores, baja → humano
🚼 Rueditas — Manual con supervisión total
Fase 1El sistema lo genera y tú lo ejecutas o lo corriges manualmente.
Validas el 100% de los outputs. El objetivo es entender dónde se equivoca el sistema antes de soltar el control. Nunca te saltes esta fase.
🧑🏫 Guiado — Funciona, pero tú revisas todo
Fase 2El sistema redacta un borrador; tú lo apruebas antes del envío.
Redacta, pero no envía. Revisas cada elemento antes de que pase a producción. Empieza con el 10% del volumen aunque estés en la fase 2.
👁️ Supervisado — Autónomo con monitoreo activo
Fase 3El sistema ejecuta; tú supervisas + alertas configuradas.
Alertas y dashboards activos. Aún revisas muestras con regularidad, no solo cuando algo falla. Las alertas no sustituyen la revisión periódica.
🙌 Manos Libres — Autónomo con revisión periódica
Fase 4Confianza establecida a partir de datos históricos.
Revisión quincenal o mensual de los registros. El sistema está en «producción confiable», pero sigue evolucionando (Iteration Mindset). La revisión periódica es sagrada.
Intern Rule — Trata a la IA como a una persona contratada desde el día 1
"No confiarías tu cuenta bancaria a alguien que acabas de conocer." Trata a la IA exactamente como a una nueva contratación: identidad propia, solo lectura por defecto, sin credenciales personales y con un registro de auditoría completo.
🧑💼 Lista de verificación de permisos del contratista
🔑 Por qué esto importa ahora
Los agentes de IA con amplio acceso a correos electrónicos, calendarios y sistemas pueden causar daños irreversibles por un solo error de juicio. La protección no es desconfianza: es arquitectura responsable. El alcance mínimo es un estándar de la industria para cualquier sistema con autonomía.
Kill Switch + principios rectores
Si una automatización necesita parches constantemente, produce baja calidad o cuesta más de lo que ahorra: desmóntala. Sin costos hundidos. Tres principios fundamentales rigen todas las decisiones de Machine.
🔴 Atención: el costo hundido es una trampa
"Ya invertí 3 semanas en esta automatización" no es motivo para mantenerla en marcha cuando cuesta más de lo que aporta. El tiempo invertido no recupera — solo cuenta el valor futuro. Si aparecen las siguientes señales: desármalo sin culpa.
- ⚠Pasas más tiempo reparando la automatización que usándola
- ⚠La calidad del output se mantiene por debajo del threshold
- ⚠El costo (tiempo + dinero + estrés) supera el beneficio generado
⚖️ Los 3 principios rectores
Boring es hermoso
El sistema más confiable no es el más sofisticado, sino el más predecible. Resiste la tentación de complicarlo. Si una regex lo resuelve, usa regex. Si lo resuelve un script sencillo, usa un script sencillo.
Los pasos determinísticos terminan; los pasos de IA evolucionan siempre
Trata tus bloques de IA como organismos vivos: necesitan revisiones periódicas. Los bloques determinísticos pueden tener un SLA de "funciona hasta que cambie el schema". Los bloques de IA necesitan revisión incluso si el código no cambia.
Fail fast, learn faster
Las fallas rápidas en un entorno controlado son baratas. Las fallas lentas en producción son caras. Diseña tus sistemas para que fallen de forma explícita y temprana, con mensajes de error claros, logs detallados y puntos de interrupción.
🛠️ Resumen del módulo
Siguiente: Ruta 2 — La arquitectura (4 Cs)
Context · Connections · Capabilities · Cadence. Los 4 pilares de un sistema operativo de IA completo.