Esta pregunta tiene una respuesta corta, y ahí está la trampa. La lista de herramientas es fácil de recitar y no dice casi nada de la calidad de lo que se construirá. Aun así damos la nuestra, porque un proveedor que se niega a darla tiene un problema.

Lo que utilizamos

  • Modelos de lenguaje. Principalmente los de Anthropic y OpenAI, elegidos tarea por tarea. Una clasificación de gran volumen no pide el mismo modelo que una redacción. La elección es reversible: el código nunca presupone un único proveedor.
  • Interfaces de programación. Las de sus herramientas de negocio, las de las plataformas publicitarias, las de la mensajería y los sistemas de pago. Ahí está el verdadero trabajo de integración.
  • Base de datos. Una base relacional con reglas de acceso por fila, que sigue siendo la fuente de verdad. Los modelos leen y escriben a través de ella, nunca al margen.
  • Ejecución. Funciones desplegadas en la periferia de la red, tareas programadas y colas de espera para todo lo que sea largo, caro o susceptible de fallar.
  • Bases de conocimiento. Sus documentos troceados, indexados y citados, para que el modelo responda a partir de su material y no de su memoria.
  • Permisos y autenticación. Una identidad por usuario, roles y habilitaciones verificadas en el servidor. Nunca solo en el navegador.
  • Registro y supervisión. Cada acción automatizada deja un rastro legible, con su coste, su resultado y su autor. Se envían alertas en los casos anómalos.

Por qué la lista no es la respuesta

Dos proveedores pueden citar exactamente las mismas tecnologías y entregar dos cosas radicalmente distintas. Lo que los separa cabe en cinco preguntas, que conviene hacer justo después:

  • ¿Qué ocurre cuando falla una llamada? Reintento, espera progresiva, cola, abandono con alerta: hace falta una respuesta precisa, distinta según el caso.
  • ¿Quién tiene derecho a lanzar qué? Una automatización que funciona con una cuenta todopoderosa es un incidente en espera.
  • ¿Cómo se sabe qué ha pasado? Sin un registro consultable no hay diagnóstico posible, y por tanto tampoco corrección.
  • ¿Cuánto cuesta su uso? El coste de los modelos se mide por llamada. Una arquitectura que no lo mide no lo controla.
  • ¿Qué sigue siendo determinista? Todo lo que pueda ser una regla debe seguir siendo una regla. El modelo solo interviene donde hace falta juicio.
El modelo es el componente más visible de una automatización. Rara vez es el que decide su éxito.

Sobre las plataformas sin código

Plataformas como n8n, Make o Zapier son excelentes herramientas y no tenemos nada en su contra. Encajan perfectamente en encadenamientos simples, de poco volumen y sin lógica condicional profunda. Se vuelven caras y frágiles cuando el proceso se complica, cuando sube el volumen o cuando hace falta una recuperación fina tras un error.

El verdadero tema no es «código contra sin código», sino: en qué momento se cambia de vehículo y quién se lo dirá con honestidad.

Un detalle que lo cambia todo: en qué cuenta se ejecuta la IA

Cuando pilotamos sus automatizaciones, las llamadas a los modelos se ejecutan con sus propios accesos, su cuenta y su factura. Usted ve el consumo, puede limitarlo y puede cortarlo. Este punto parece administrativo: en realidad determina quién controla la herramienta y enlaza directamente con la cuestión de la propiedad.

Para ver cómo encajan estas piezas en la práctica, la página Orquestador IA describe el trabajo de pilotaje, y este artículo levanta el capó.