Chain of thought: cuándo ayuda y cuándo estorba

Chain of thought es la técnica de pedir a un modelo que razone los pasos antes de responder. Salió de una investigación de 2022 que mostró que los modelos con espacio para trabajar pasos intermedios resolvían problemas multipaso de forma mucho más fiable que los modelos a los que se les pedía la respuesta directa.

Años después el panorama ha cambiado: los modelos frontera razonan internamente por defecto. Eso no ha hecho inútil la técnica. Ha cambiado para qué sirve. Hoy el valor no es activar el razonamiento, es dirigirlo y poder auditarlo.

Qué pasa en realidad#

Cuando un modelo responde de inmediato, se compromete con una dirección en sus primeras palabras y después la justifica. Cuando trabaja por pasos, cada paso condiciona al siguiente, y los errores afloran donde puedes verlos.

Para un perfil de negocio la diferencia aparece en tareas como estas:

• Comparar tres opciones contra cinco criterios.
• Repartir un presupuesto con restricciones.
• Diagnosticar por qué una campaña rindió por debajo.
• Decidir si una afirmación se sostiene con los datos que diste.

En las cuatro, una respuesta directa suena igual de segura y se equivoca más a menudo.

La versión 2026 de la técnica#

"Pensemos paso a paso" fue la frase que hizo famosa la técnica. En los modelos actuales es casi inofensiva y casi inútil. Lo que sí produce mejora medible es especificar tus pasos.

Débil:

Piensa paso a paso y dime qué canal recortar.

Fuerte:

Trabaja esto en orden, mostrando el desarrollo en cada fase:
1. Lista cada canal con inversión, leads y coste por lead.
2. Marca como poco fiable cualquier canal con menos de 30 leads.
3. Ordena los canales fiables por coste por lead cualificado.
4. Señala cualquier canal con una razón estratégica para
   mantenerlo pese a su eficiencia.
5. Solo entonces recomienda qué recortar, con el número que
   lo justifica.

Si falta un dato para un paso, dilo en vez de estimarlo.

La segunda versión no es un truco. Es tu proceso de análisis, escrito. Esa es la habilidad entera, y por eso la ingeniería de prompts es en realidad especificación.

Cuándo compensa el coste#

Úsalo cuando se cumplen todas estas:

• La tarea tiene varios pasos dependientes.
• Una respuesta equivocada es cara: una recomendación, un cálculo, una afirmación que vas a publicar.
• Quieres auditar la lógica, no solo la conclusión.
• La latencia no es crítica.

Casos típicos: modelos financieros, análisis de causa raíz, evaluación de ofertas, lectura cercana a lo legal, cualquier comparación con más de tres criterios.

Cuándo saltárselo#

• Consultas y recuperación. "¿Cuál es nuestra política de devoluciones?" no necesita deliberación.
• Copy corto. Razonar sobre un titular suele producir un titular peor y un párrafo de explicación.
• Clasificación con buenos ejemplos. Few shot prompting es más rápido y más preciso aquí.
• Automatización de alto volumen. El razonamiento multiplica tokens y latencia en miles de ejecuciones.
• Cualquier cosa en tiempo real. Un cliente esperando en un chat no espera a una deliberación.

Regla práctica que doy a clientes: razona sobre decisiones, no sobre borradores.

Estructurar el razonamiento para que sirva#

Tres patrones que funcionan en entregables reales.

Separa el pensamiento de la respuesta. Pide el razonamiento en una sección y la conclusión en otra, para poder pegar la conclusión sin editar el desarrollo.

Pide los supuestos explícitos. "Lista cada supuesto que has hecho antes de concluir." Esto caza la entrada inventada que habría arruinado la recomendación.

Fuerza un contraargumento. "Ahora defiende el mejor caso en contra de tu propia recomendación." Esta línea ha salvado más decisiones de clientes que ningún otro prompt que use.

Chain of thought en agentes#

La técnica importa más, no menos, cuando pasas a agentes. Un agente que planifica antes de actuar es la misma idea aplicada a llamadas de herramientas: exponer el plan, ejecutar por pasos, comprobar el resultado de cada uno antes de seguir.

Por eso un plan escrito es lo primero que produce un buen agente de terminal, y por eso cazar un plan equivocado en el paso uno es la intervención más barata disponible. Ver agentes de IA para empresas.

Un ejemplo real de una pregunta de cliente#

La pregunta era si mantener una feria que costaba 18.000 euros al año. La respuesta directa fue "sí, las ferias construyen relaciones": cierta, genérica, inútil.

La versión estructurada pidió cinco pasos. Listar cada lead atribuido a la feria en dos años. Marcar cuáles cerraron. Calcular coste por operación cerrada frente a la misma cifra en búsqueda de pago. Señalar qué aporta la feria que una comparación de canales no captura. Solo entonces recomendar, declarando supuestos.

El desarrollo reveló el problema real en el paso uno: nadie había atribuido los leads, así que el 60% estaba sin rastrear. La recomendación que salió no fue mantener ni recortar. Fue "arregla la atribución este año y decide el que viene". Esa respuesta solo existe porque el razonamiento estaba a la vista antes que la conclusión.

El coste, con honestidad#

Razonar cuesta tokens y tiempo. En una decisión importante puntual eso es irrelevante. En una tubería automatizada que se ejecuta 5.000 veces al día es tu presupuesto entero.

El patrón que funciona: un modelo barato y rápido para enrutar, extraer y clasificar, y un modelo de razonamiento solo para el paso donde hace falta criterio. La mayoría de equipos aplica razonamiento a todo y luego se queja de la factura.

Errores a evitar#

• Tratar una frase mágica como si fuera la técnica. Especifica tus pasos.
• Leer solo la conclusión. Si no vas a revisar el razonamiento, no necesitabas el razonamiento.
• Fiarte de aritmética segura de sí misma. Verifica los números aparte; un cálculo plausible no es un cálculo correcto.
• Dejar que el razonamiento se filtre al entregable del cliente. Separa las secciones y envía la respuesta.
• Usarlo como sustituto de datos. Razonar sobre información que falta produce conjeturas bien estructuradas.

La versión corta#

Chain of thought ya no es un truco que añades a los prompts. Es el hábito de escribir tu propio proceso de análisis dentro de la instrucción, pedir supuestos y contraargumentos, y leer el desarrollo antes de aceptar la respuesta.

Ese hábito es la lección cuatro de mi curso gratis de ingeniería de prompts. Si quieres a tu equipo aplicándolo a decisiones reales con alguien revisando el trabajo, para eso están mis formaciones de IA para empresas.