Cada vez que sale un modelo nuevo, alguien quiere meterlo en su producto. Tiene lógica — es ruidoso, impresiona en demos, y los inversionistas escuchan "AI" y se les iluminan los ojos. Pero un LLM no siempre es la herramienta correcta. A veces, una regex y un if hacen el trabajo mejor, más barato y más rápido.

Cuándo SÍ tiene sentido

  • Procesar texto no estructurado donde las reglas explotan (resúmenes, clasificación con contexto, extracción de intenciones).
  • Generar contenido (drafts, ideas, traducciones — siempre con revisión humana).
  • Conversación en lenguaje natural donde el árbol de decisión sería gigante.

Cuándo NO

  • Reglas exactas: 'si el cliente compró X y vive en Y, mostrar Z'. Eso es código, no IA.
  • Cálculos numéricos: los LLMs alucinan números. Usa una hoja de cálculo o una función.
  • Búsqueda en una base de datos: pídele a tu DB, no a un modelo.
  • Volúmenes enormes con presupuesto chico: los tokens se acumulan.

El error más común

Tratar al LLM como una base de datos. "Hey GPT, ¿cuántos pedidos tengo este mes?". El modelo no sabe — y si responde, está adivinando. La solución es darle herramientas (function calling) para que consulte tu sistema real. Eso es ingeniería, no magia.

"Si tu problema se resuelve con un if, escribe el if. Cuesta cero tokens y nunca alucina."

Qué usar en su lugar

  • Reglas de negocio: código normal.
  • Búsqueda semántica: embeddings + vector DB (Pinecone, pgvector).
  • Clasificación con datos: un modelo pequeño tipo BERT, entrenado con tus ejemplos.
  • Recomendaciones: filtros colaborativos o reglas — solo IA si tienes muchos datos.

El mejor consejo que damos a clientes: empieza por el problema, no por la herramienta. Si después de mapearlo el LLM sigue siendo la respuesta, perfecto. Si no, te ahorramos miles de dólares en tokens y semanas de prompting.