Automatización de procesos con IA: desarmé uno real

Automatización de procesos con IA explicada con un caso real de un inversionista inmobiliario: qué falló, con cifras, y qué preguntar a quien lo construya.

Por Carlos Familia, Experto en CRM y automatización con IA. Actualizado el 19 de octubre de 2026. 6 min.

Un inversionista inmobiliario en Estados Unidos tenía un problema que parecía pequeño. Cada llamada de su sistema telefónico creaba una nota y una tarea en el CRM. Tres llamadas con la misma persona eran tres notas y tres tareas.

Abrí el proceso y confirmé exactamente eso. Armé un trabajo nocturno que, por cada contacto con actividad, junta las llamadas, los mensajes de texto y los resúmenes de llamada del día, y escribe una sola nota con un resumen hecho por IA, una tarea y una etiqueta.

Automatizar un proceso con IA es tomar un trabajo repetitivo con pasos claros y dejar que el programa haga los pasos fijos, mientras la IA hace solo el paso que necesita leer o resumir texto. En este caso, la IA era un único paso: el resumen. Todo lo demás era código normal. Eso importa para el costo y para saber dónde mirar cuando algo falla.

La primera versión no escribió nada en una noche de 32 contactos. Esto es lo que desarmé.

¿Qué problemas había, y cuántos?

Problema 1: una nota por cada llamada

Por qué pasa. Mi impresión es que quien construye automatiza el evento, no la necesidad. Entra una llamada, se crea una nota. Nadie pregunta qué necesita leer la persona que abre el contacto.

Cómo se arregla. La unidad pasa a ser el contacto por día. El trabajo nocturno recorre solo los contactos con actividad, trae llamadas, mensajes y resúmenes de llamada, y deja una nota, una tarea y una etiqueta. Es idempotente por día: si lo corres dos veces, no escribe una segunda nota. Esa propiedad es la que te deja reintentar sin miedo.

Problema 2: el trabajo se corta a los 300 segundos

Por qué pasa. Los nodos de código tienen un tiempo máximo. En la documentación de n8n, el valor por defecto de N8N_RUNNERS_TASK_TIMEOUT es 300: es el tiempo máximo, en segundos, que una tarea puede correr antes de que el ejecutor la detenga y se reinicie. Lo leí el 14 de octubre de 2026, y tu versión o tu instalación pueden tener otro valor.

En mi caso, la primera versión, en una noche de 32 contactos, terminó con 0 escrituras. El modo "por elemento" no reinicia ese reloj, así que cada contacto sumaba al mismo tiempo total.

Cómo se arregla. Se divide el trabajo en lotes, y cada lote tiene su propio tiempo. Con eso, los 32 contactos terminaron en 354 segundos en total, más que el límite de 300 de un solo nodo, y sin cortarse.

Problema 3: el disparador quedó viejo

Por qué pasa. Una actualización parcial de un flujo que ya estaba activo dejó su webhook sin registrar, y el flujo dejó de recibir.

Algo parecido vi con otro cliente: en su n8n en la nube, activar un flujo por la API pública no registró sus disparadores.

Cómo se arregla. Desactiva y vuelve a activar el flujo después de cada edición, y confirma que se registró con una ejecución de prueba.

Problema 4: una rama que apunta a la nada

Por qué pasa. En el camino de borrado había una referencia a un nodo que nunca corría. Es el tipo de error que no se ve en el camino normal.

Cómo se arregla. Después de cada edición a un flujo en vivo, lo corro una vez y leo la ejecución completa, incluidas las ramas raras. Un flujo "sin errores" en la lista de ejecuciones no prueba que todas sus ramas funcionen.

Problema 5: la fuente de datos tiene sus propias reglas

Para una empresa de Nuevo México que compra propiedades en remate, armé cuatro flujos en su cuenta de n8n en la nube. Uno extrae las hojas de ejecuciones hipotecarias y las pasa a Airtable. Otro sigue las subastas, con aplazamientos y cancelaciones. El tercero completa los datos de contacto de cada propietario y el cuarto envía todo a la aplicación que usa el equipo que toca puertas. Tres detalles:

• La aplicación de campo solo aceptaba datos en formato de formulario, y exigía los campos de teléfono y correo aunque fueran vacíos.
• El nodo de actualización de Airtable era frágil. Lo reemplacé por una llamada HTTP PATCH.
• Completar los datos tiene costo, así que corre con un tope de 25 registros por corrida. En una prueba de 3 registros, los 3 se completaron, a unos $0.12 cada uno.

Resultado: 95 subastas extraídas, 378 registros en cola ya enviados a la aplicación y un panel sobre 517 registros. Antes, ese equipo copiaba las hojas a mano.

Otro proceso, otra cuenta: el Excel que se cuadra a mano

Una empresa hipotecaria cuadraba los reportes de agentes inmobiliarios a mano, con tablas dinámicas de Excel. Armé una carga: subes la hoja, ves una vista previa, confirmas, y el sistema aplica una clave única por agente y prestatario y recalcula los totales. Un archivo de 330 filas dio 106 agentes y 325 referidos, con 5 duplicados ignorados. Subir el mismo archivo otra vez agregó 0.

El camino tuvo tres errores. El lector solo leía la primera hoja del archivo. Una columna de sí o no ("tiene agente inmobiliario") creó 33 agentes llamados "Yes" y 48 llamados "No". Y había que contar por préstamo, no por persona. Con un caché en el panel, la carga bajó de 8.7 a 0.46 segundos. Nada de esto usó IA, y por eso lo menciono: la mayor parte de un proceso automatizado es esto.

¿Dónde sí vale la pena la IA?

En el resumen de llamadas, la IA ahorra lectura, porque convierte varias llamadas en un párrafo. Otro caso, de una academia de inglés para hispanohablantes: el bot nativo de GoHighLevel contestaba todos los mensajes directos, hasta los emojis. Armé un clasificador con un modelo local pequeño (3B) que corre en mi servidor: recibe el mensaje, lo asigna a una de 8 categorías y decide si el bot responde. Tarda unos 22 segundos si el modelo estaba apagado y unos 7 si ya estaba cargado.

Allí también falló lo de siempre, no la IA. GoHighLevel disparaba dos webhooks por el mismo mensaje. El n8n en Docker no alcanzaba el modelo en la dirección 127.0.0.1. Un paso de quitar etiquetas se calculaba pero nunca se enviaba. Y un texto con comillas rompía el cuerpo de la petición.

Mi regla: usa IA donde haya que leer o clasificar texto libre, y código normal para todo lo demás. Y cada paso debe fallar de forma segura y poder repetirse sin duplicar nada.

¿Qué preguntarle a quien construya el tuyo?

• ¿Cuál es el único paso que usa IA, y qué pasa si ese paso falla o se demora?
• ¿Se puede repetir el proceso sin duplicar notas, tareas ni mensajes?
• ¿Qué límites de tiempo, de volumen y de costo tiene cada paso, y cómo los probaste con tu volumen real?
• ¿Cómo me entero si una noche no escribió nada?
• ¿Probaste todas las ramas, no solo la principal?
• ¿Quién es dueño de la cuenta de n8n y del servidor donde corre?

Si todavía no sabes qué es la herramienta, empieza por qué es n8n y para qué sirve. Para el lado del CRM de este caso, mira CRM para inmobiliarias y, en inglés, el CRM para inversionistas inmobiliarios y n8n para captar clientes. Si buscas quién lo construya, lee cómo contratar a un desarrollador de n8n, o usa el calendario.

Sobre el autor

Carlos Familia, Experto en CRM y automatización con IA. GoHighLevel, n8n, agentes de IA, servidores. Desarrollador full stack.

Construyo sistemas de CRM en GoHighLevel, automatizaciones de n8n en mis propios servidores y agentes de IA de voz y chat para negocios de servicios. Desarrollador full stack: escribo el workflow, la integración con la API, la base de datos y el servidor donde corre, y pruebo cada sistema con recorridos reales antes de entregarlo.