No todo lo que se puede automatizar debería automatizarse. La regla de decisión que aplico antes de construir cualquier flujo de trabajo, y las cuatro automatizaciones que eliminé después de que funcionaran perfectamente.
He eliminado más automatizaciones de las que actualmente tengo en marcha. No porque fallaran, sino porque funcionaban perfectamente y empeoraban las cosas.
Esa frase merece que te detengas en ella, porque es justo lo que la comunidad del “automatiza todo” nunca menciona. Una automatización que corre de forma confiable y degrada la calidad de tu trabajo no es una victoria de productividad. Es un pasivo disfrazado de activo. La única señal que lo delata es notar, varias semanas después, que los resultados que estás produciendo se han vuelto silenciosamente peores, y que la automatización estaba encubriendo esa caída.
Esta es la regla de decisión que hoy aplico antes de construir cualquier cosa. Es una sola pregunta con tres subverificaciones, y me ha ahorrado más tiempo que la mayoría de las automatizaciones que habría construido sin ella.
Construí cuatro automatizaciones que luego eliminé. Las cuatro funcionaban. Esto es lo que hacían y por qué se fueron.
Resúmenes automáticos de reuniones. Un modelo corriendo sobre cada transcripción de reunión: resúmenes instantáneos enviados treinta minutos después de cada llamada. El problema: los resúmenes eran precisos e inútiles. Las notas de reunión necesitan curaduría, no compresión. La automatización mostraba lo dicho en proporción a cuánto se había dicho. Lo que realmente importaba en la mayoría de las reuniones era una frase pronunciada una sola vez, con dudas, que yo habría anotado y sobre la que habría construido el brief. Esa frase no destacaba en un resumen. Se veía igual que las otras cuarenta y nueve frases. La automatización producía documentación limpia y con formato profesional de las partes menos importantes de cada reunión.
Reemplazado por: el sistema de anotación de tres etiquetas. Manual. No automatizable.
Borradores automáticos de seguimiento con clientes. Un modelo redactando correos de seguimiento a partir del resumen de la reunión. El problema: aplicaba un registro profesional uniforme a relaciones que requerían un trato diferenciado. Un cliente quería brevedad y directo al punto. Otro necesitaba calidez y contexto. Otro estaba en una posición políticamente sensible que exigía un encuadre cuidadoso. El modelo producía seguimientos correctos, fluidos, profesionales. Estaban mal para la relación de la misma forma en que una tarjeta de pésame prefabricada está mal: gramaticalmente correcta, situacionalmente fuera de lugar. Tres clientes respondieron en un tono que me dejó claro que habían notado la ausencia de una persona real del otro lado. La automatización era técnicamente correcta; los resultados eran profesionalmente incorrectos.
Reemplazado por: nada. Algunos seguimientos hay que escribirlos a mano.
Resúmenes diarios de briefing. Un digest diario de todo lo etiquetado como importante en mis notas de la semana anterior. El problema: el hábito del digest diario me hizo menos selectivo sobre qué etiquetaba como importante. Cuando un sistema va a agregarlo todo, pierdes la disciplina de decidir qué importa antes de capturarlo. El digest se acumulaba. La exhaustividad reemplazó a la selectividad, y la selectividad era justamente el punto.
Reemplazado por: una revisión manual semanal de quince minutos sobre las notas crudas de la semana. Elijo las tres cosas que realmente movieron algo. Esa restricción es estructural.
Puntajes de confianza. Le pedí al modelo que calificara sus propios resultados de investigación en una escala de confianza del 1 al 10. El problema: los números eran inventados. El modelo hacía pattern-matching de cómo se ve un puntaje de confianza y producía números plausibles. Yo confiaba en ellos. Había automatizado la imitación del juicio y la había confundido con juicio real.
Reemplazado por: mi propio etiquetado de incertidumbre. Cuando no estoy seguro de que algo sea correcto, escribo “CHECK:” antes. Cuando estoy seguro, escribo la afirmación. Ese sistema es binario y honesto. No cuesta nada.
Las cuatro se eliminaron no porque fallaran, sino porque optimizaban la eficiencia en lugares donde la eficiencia no era la restricción limitante.
Antes de construir cualquier automatización, me hago una sola pregunta:
¿El cuello de botella en esta tarea es el tiempo que toma, o el juicio que requiere?
Si la respuesta es tiempo, vale la pena considerar la automatización.
Si la respuesta es juicio, vale la pena evitarla, o al menos, el paso que contiene el juicio debería ser lo único que la automatización no toque.
De ahí se desprenden tres subverificaciones:
Subverificación uno: ¿cómo se ve el fallo, y qué tan rápido sale a la superficie? Algunos fallos son obvios y rápidos: la automatización se rompe, nada funciona, lo notas de inmediato. Otros son invisibles y lentos: la automatización sigue corriendo, produce resultados plausibles, y degrada la calidad durante semanas. Los lentos son peores. Antes de construir, me pregunto: si esta automatización produce mal resultado en silencio, ¿cuánto tardaré en notarlo? Si la respuesta es “más de una semana”, quiero un punto de control humano antes de que el resultado se use, no después.
Subverificación dos: ¿estoy automatizando la representación del trabajo, o el trabajo mismo? Es la distinción más importante que he encontrado, y es fácil pasarla por alto porque un buen resultado de IA se ve como buen trabajo. Formatear un brief, redactar un resumen, estructurar un documento: eso son representaciones del pensamiento, no el pensamiento en sí. Automatizarlas es de bajo riesgo si el pensamiento subyacente es tuyo. Pero si la automatización produce la representación antes de que ese pensamiento haya ocurrido, obtienes algo que parece completo y no lo es. La automatización que debería construir es la que le da formato al resultado después de que ya hice el trabajo de juicio. La que debería evitar es la que produce el resultado en lugar de él.
Subverificación tres: ¿esta tarea compone? Algunas actividades se vuelven más valiosas cuanto más las repites: desarrollas reconocimiento de patrones, construyes conocimiento de la relación, afinas un modelo de la situación de un cliente. Si automatizas una actividad que compone, dejas de componer. La máquina hace las repeticiones y tú no. En un año, la diferencia es significativa. En tres años, es la brecha entre alguien con una visión genuinamente profunda de su dominio y alguien con buenas herramientas. Todo lo que compone lo mantengo en mis manos.
Para que quede claro: automatizo mucho. Esta regla no produce un escéptico que hace todo a mano. Produce especificidad sobre dónde va la automatización.
Automatizo el formato y la estructura. Automatizo la compresión de material que ya curé y anoté. Automatizo la recuperación: construyendo sistemas que muestran pensamiento pasado a demanda. Automatizo la programación y el enrutamiento: la capa administrativa de cualquier flujo de trabajo que consiste puramente en mover cosas de un lugar a otro.
No automatizo la primera articulación de mi postura sobre nada. No automatizo el manejo de relaciones. No automatizo el paso que requiere que yo decida qué importa. Y no automatizo nada donde el modo de fallo sea una incorrección con sonido confiado, porque ese modo de fallo es invisible hasta que deja de serlo.
La pregunta nunca es “¿se puede automatizar esto?”. Es “¿cuál es el costo real si esto produce una respuesta plausible pero equivocada, y quién lo nota?”.
Mantengo un documento breve, un registro de decisiones, donde anoto cada automatización que consideré y no construí, y por qué. Tiene unas dos docenas de entradas. Es, genuinamente, más útil que la lista de automatizaciones que tengo corriendo, porque las entradas contienen el razonamiento sobre por qué una tarea dada es trabajo de juicio, y ese razonamiento se traslada a nuevas decisiones. Cada vez que tengo la tentación de construir algo para una tarea similar, reviso primero el registro.
La decisión de no automatizar es tan deliberada como la decisión de automatizar. Tómala a propósito, documéntala, y deja de ser una oportunidad perdida. Se vuelve política.
Ese documento, la matriz de decisión de herramientas y el formato de registro de decisiones que uso, está disponible como plantilla. La lógica del formulario es la misma lógica que describí aquí; la plantilla la hace reutilizable en decisiones recurrentes.
→ Tool Decision Framework: $39. Matriz de decisión estructurada + registro de decisiones. Para usar en Obsidian o Notion. (Se enviará primero a la lista del newsletter; suscríbete abajo.)
Cuatro automatizaciones eliminadas. Cada una enseñó algo que la comunidad del “construye primero” no dice en voz alta: la pregunta no es si puedes automatizarlo. Es si, dentro de dos meses, te alegrarás de haberlo hecho.
Siguiente en Systems → Cómo mantengo honestos los resultados de la IA: las verificaciones que corro antes de que algo llegue a un cliente.
La plantilla exacta de Obsidian y la cadena de prompts completa: la nota de recepción estructurada, el prompt de contraste, y el checklist de provocación. Ponla en tu vault y corre tu próximo prospecto en cuarenta minutos.
Sin calendario. Sin relleno. Sin patrocinios. Una nueva entrega sale solo cuando vale tus diez minutos: usualmente cada 2 a 4 semanas.
"Solo te enviaré algo que habría escrito incluso si nadie me pagara por hacerlo. El día que eso pare, el newsletter para."