1. Modelo mental
Automatizar con IA significa insertar un componente probabilístico dentro de un proceso. El resto del sistema debe compensar esa variabilidad con contratos, validaciones, reintentos y caminos alternativos.
La mejor automatización suele empezar como procedimiento manual bien entendido. Si no sabes qué entrada es válida, qué salida debe producir y qué excepciones existen, automatizar sólo vuelve más rápido el caos.
Piensa en unidades de trabajo pequeñas e idempotentes. Es preferible poder reintentar un documento concreto que repetir un lote entero y duplicar efectos.
2. Conceptos que debes dominar
Evento que inicia el proceso: archivo, formulario, horario, webhook o cola.
Comprobación determinista antes y después del modelo.
Evita duplicar acciones cuando se reintenta.
Nuevo intento controlado para errores transitorios, no para errores lógicos.
Espera creciente entre reintentos para no saturar proveedor.
Cola que desacopla entrada y procesamiento.
Destino de casos que agotaron reintentos y necesitan revisión.
Revisión explícita cuando el riesgo o incertidumbre lo requiere.
Métricas, logs y trazas para saber qué ocurrió.
Objetivo de tiempo y calidad que guía decisiones operativas.
3. Workflow paso a paso
Mapea proceso
Dibuja entradas, decisiones, salidas y excepciones.
Cada paso tiene dueño.
Separa determinista/probabilístico
Usa código para reglas exactas y modelo para ambigüedad.
No pides al LLM hacer validaciones triviales.
Diseña esquema de salida
JSON o campos verificables.
Puedes validar antes de continuar.
Añade confianza
Score, reglas o revisión en casos inciertos.
No automatizas igual todos los casos.
Implementa retries
Sólo errores transitorios y con backoff.
Un fallo lógico no entra en loop.
Protege efectos
Idempotency keys y confirmaciones.
Reintentar no duplica envíos/pagos.
Observa
Registra coste, latencia, errores y calidad.
Puedes encontrar el cuello de botella.
Escala gradualmente
Shadow → pequeño porcentaje → ampliación.
Puedes revertir rápido.
4. Ejemplo completo
Automatización:clasificar emails entrantes y crear una tarea.
El trigger recibe el email. Un filtro determinista descarta spam y tipos no soportados. El modelo devuelve JSON con categoría, prioridad, resumen y confidence. Un validador comprueba el schema. Sólo categorías conocidas pasan. Si confidence es baja, va a revisión. La creación de tarea usa una idempotency key basada en el Message-ID.
La IA decide semántica; el código controla efectos.
5. Matriz de decisión
| Decisión | Qué mirar | Señal buena | Señal de riesgo |
|---|---|---|---|
| Regla | Criterio exacto | Código | LLM innecesario |
| LLM | Clasificación ambigua | Eval estable | Sin schema |
| Batch | No urge | Más eficiencia | Esperas demasiado |
| Realtime | SLA corto | Latencia medida | Coste sin necesidad |
| Humano | Riesgo alto | Checkpoint claro | Revisión de todo por defecto |
6. Fallos y límites
Una guía útil también debe decir cuándo detenerse. Estos son los fallos que más cambian la calidad del resultado:
- Automatizar antes de entender excepciones.
- Usar texto libre cuando después necesitas campos.
- Reintentar indefinidamente.
- No usar idempotencia en acciones externas.
- No distinguir error del proveedor de mala salida.
- No tener dead-letter queue.
- Escalar 100% desde el primer día.
- No medir ahorro neto después de revisión humana.
7. Cómo medirlo
No midas sólo si “parece bueno”. Define una señal observable antes de escalar.
| Métrica | Qué mide | Cómo observarla | Umbral/alerta |
|---|---|---|---|
| Success rate | Tareas completadas | Jobs OK/total | Bajo SLO |
| Schema failures | Salidas inválidas | Validator | Sube tras cambio |
| Retry rate | Errores transitorios | Retries/job | Proveedor inestable |
| Human review | Carga humana | Revisiones/total | No disminuye |
| Latency | SLA | p95 | Incumple proceso |
| Net savings | Valor | Tiempo ahorrado-coste | Negativo |
8. Checklist de producción
9. Ejercicios para convertir lectura en habilidad
- Automatiza en papel una tarea y marca qué pasos no necesitan IA.
- Diseña un JSON schema mínimo para una clasificación.
- Define tres errores transitorios y tres lógicos.
- Escribe una idempotency key para una acción real.
- Calcula ahorro neto incluyendo minutos de revisión.
10. Qué estudiar después
No intentes memorizar toda la IA. Encadena la siguiente pieza cuando resuelva una duda que ya has encontrado en la práctica.
Apéndice A · Preguntas que deberías poder responder
- ¿Qué parte del problema es determinista y cuál necesita juicio probabilístico?
- ¿Qué dato o ejemplo cambiaría tu decisión actual?
- ¿Cómo distinguirás una mejora real de una respuesta simplemente más convincente?
- ¿Qué ocurre cuando faltan datos, la herramienta falla o la respuesta es incierta?
- ¿Qué parte del proceso debe seguir bajo responsabilidad humana?
- ¿Qué coste operativo aparece después del primer prototipo?
- ¿Qué revisarías dentro de 30, 90 y 180 días para evitar que el sistema envejezca?
Si no puedes responder todavía a varias de estas preguntas, no significa que el proyecto esté mal: significa que has encontrado exactamente los huecos que la siguiente iteración debe cerrar. Ese es uno de los usos más valiosos de una guía técnica: convertir incertidumbre difusa en decisiones explícitas.
Apéndice B · Cuatro escenarios para practicar la decisión
Pregunta:Criterio exacto.Señal favorable:Código.Alerta:LLM innecesario.
Pregunta:Clasificación ambigua.Señal favorable:Eval estable.Alerta:Sin schema.
Pregunta:No urge.Señal favorable:Más eficiencia.Alerta:Esperas demasiado.
Pregunta:SLA corto.Señal favorable:Latencia medida.Alerta:Coste sin necesidad.
No memorices la tabla como si fuera una regla universal. Cambia volumen, riesgo, disponibilidad, privacidad o coste y vuelve a recorrer la decisión. Un sistema robusto documenta qué variables sostienen la elección y cuáles podrían invalidarla.
Apéndice C · Cuaderno de campo para tu propio caso
Copia estas preguntas en un documento y complétalas con un caso real. El objetivo es que el conocimiento deje de estar en la página y pase a tu proceso.
- Problema¿Qué trabajo concreto intentas mejorar y para quién?
- Baseline¿Cómo se hace hoy, cuánto tarda y qué errores aparecen?
- Datos¿Qué entra, de dónde viene, quién puede verlo y qué no debería salir del entorno?
- Salida¿Qué formato y criterios convierten el resultado en usable?
- Prueba¿Qué 20–50 casos representarían el trabajo real?
- Riesgo¿Cuál es el fallo más costoso y cómo se detecta?
- Operación¿Quién observa, corrige, actualiza y puede detener el sistema?
- Revisión¿Qué evento o fecha obligará a reevaluar esta decisión?
Guarda también dos ejemplos que funcionaron y dos que fallaron. Con el tiempo, esos ejemplos se convierten en un pequeño dataset de evaluación mucho más útil que cualquier memoria informal de “esto parecía ir bien”.
Apéndice D · De prototipo a producción
Una demo responde a la pregunta “¿puede funcionar?”. Producción responde a otras: “¿funciona de forma repetible?”, “¿qué pasa cuando falla?”, “¿quién lo mantiene?”, “¿cómo sabemos que sigue siendo bueno dentro de tres meses?” y “¿podemos revertirlo?”. El salto entre ambas fases suele ser mayor que el salto entre dos modelos.
Antes de escalar, separa cuatro planos.Calidad:casos y métricas.Operación:latencia, cuotas, errores y costes.Gobernanza:permisos, datos, revisión y responsables.Cambio:versiones, fuentes y fechas de reevaluación. Si uno de estos planos no tiene dueño, el riesgo aparecerá precisamente cuando el uso crezca.
- Define un SLO de calidad y uno operativo.
- Registra versión de modelo, prompt, fuentes y configuración.
- Mantén una muestra estable para detectar regresiones.
- Añade un fallback para proveedor, herramienta o dato ausente.
- Decide qué errores se reintentan y cuáles se escalan.
- Presupuesta revisión humana, no sólo tokens.
- Evita permisos permanentes que sólo necesitabas para una prueba.
- Programa una revisión tras cambios de modelo, precio, política o dataset.
Finalmente, observa el sistema con tráfico real. Una mejora offline puede empeorar experiencia, coste o tasa de escalado. Las métricas de esta guía son el comienzo; adáptalas al impacto de tu caso y conserva siempre ejemplos concretos detrás de cada porcentaje.
Automatizar sólo después de estabilizar el proceso
Una automatización fiable empieza por un proceso repetible. Si cada ejecución requiere decidir manualmente qué significa la entrada o qué resultado se espera, todavía estás descubriendo el proceso. Primero ejecuta el workflow de forma asistida y registra excepciones; después automatiza las partes estables.
Mantén pasos deterministas fuera del modelo cuando puedan ser reglas. Fechas, cálculos, validación de schemas, permisos, límites y transformaciones exactas suelen resolverse mejor con código. Reserva el modelo para interpretación, clasificación, generación o decisiones que realmente necesitan flexibilidad.
Diseña idempotencia y deduplicación. Un webhook puede repetirse, una cola puede reintentar y una API puede responder tarde. La automatización debe evitar enviar dos veces un correo, crear dos tickets o ejecutar dos cobros porque el mismo evento llegó de nuevo.
Añade una dead-letter queue o una ruta equivalente para casos que no pueden resolverse. Un fallo silencioso es peor que una tarea manual. Registra entrada, versión, resultado, error y posibilidad de reintento. Decide qué errores son transitorios y cuáles requieren corrección de datos o intervención.
Mide el ahorro neto y la tasa de excepciones. Si un proceso automático ahorra tiempo en el 80% de casos pero crea incidentes caros en el 20%, no es una buena automatización. El éxito debe combinar velocidad, calidad, coste y carga de supervisión.
Una escala de madurez para automatizar sólo después de estabilizar el proceso
Resuelve un caso real de principio a fin. Conserva entrada, salida y correcciones. Aquí buscas descubrir fallos, no automatizar.
La entrada y la salida ya tienen contrato, existen ejemplos límite y puedes medir calidad, tiempo y coste con el mismo criterio.
Hay observabilidad, permisos, fallback, responsable, revisión de cambios y un mecanismo para detectar regresiones antes de afectar al usuario.
La transición entre niveles debe estar motivada por evidencia. No pases a integración o autonomía sólo porque una demo salió bien. Pasa cuando hayas repetido la tarea con casos representativos, sepas dónde falla y el ahorro neto siga siendo positivo después de incluir revisión y operación.
Para los primeros 30 días, reúne ejemplos y construye el baseline. Entre 30 y 60 días, estabiliza el contrato de entrada/salida y convierte los fallos recurrentes en tests, checklist o reglas. Entre 60 y 90 días, si el volumen lo justifica, añade automatización, monitorización y revisión de costes. Si una etapa no supera sus propios criterios, mantén el sistema en la etapa anterior.
Documenta también las condiciones de salida: qué cambio de proveedor, política, precio, modelo, volumen o riesgo obligaría a reevaluar el diseño. Una arquitectura madura no pretende ser definitiva; hace explícito cuándo deja de ser válida.
Antes de considerar el trabajo terminado, realiza una revisión adversarial: busca deliberadamente entradas ambiguas, datos faltantes, instrucciones contradictorias, límites de cuota y resultados que parezcan correctos pero no puedan verificarse. El objetivo no es demostrar que el sistema funciona, sino descubrir bajo qué condiciones deja de funcionar y comprobar que esos fallos tienen una respuesta segura. Registra cada hallazgo y conviértelo en una prueba futura.
- Guarda al menos 20 casos reales, incluidos fallos.
- Define un criterio de aprobación que otra persona pueda aplicar.
- Separa métricas de calidad, coste y operación.
- Establece quién puede detener o revertir el sistema.
- Programa una fecha de revisión aunque nada parezca haber cambiado.
Documentación que sostiene y actualiza esta guía
Las capacidades y políticas cambian. Usa estas referencias para comprobar los puntos que dependan de un proveedor o de una versión concreta.