Cuándo una automatización necesita IA y cuándo bastan las reglas

Esta separación se aplica a la gestión de mis campañas publicitarias. Usé un asistente de IA para ayudarme a construir la herramienta, pero la rutina que se ejecuta cada día no llama a ningún modelo de lenguaje para decidir qué hacer.

Construir con IA es distinto de ejecutar con IA

Usar IA para escribir código, diseñar la arquitectura de un sistema o conectar servicios externos es una cosa. Dejar que esa IA decida en producción, cada hora, si un valor debe subir o bajar es otra muy distinta, y rara vez resulta necesario cuando la decisión depende solo de límites numéricos.

La rutina se ejecuta sin consultar un modelo de lenguaje. Una tarea programada se activa cada hora, obtiene las métricas de la plataforma de anuncios, las compara con los límites que definí previamente y aplica la acción correspondiente. No hay ningún cerebro artificial pensando qué hacer, y eso es deliberado.

Si usas un modelo de lenguaje para evaluar si un número es mayor o menor que otro, introduces retraso, un coste continuo de tokens y el riesgo de recibir una respuesta mal formateada o inventada. Una condición sencilla en código resuelve esa comparación en milisegundos y sin coste adicional. La flexibilidad de los modelos tiene más valor durante la construcción o cuando realmente necesitas interpretar lenguaje, como describo en el artículo sobre planificar una aplicación con Claude Code.

El ejemplo práctico de las campañas de AdSummit

Una automatización de presupuestos publicitarios funciona mejor cuando se apoya en límites numéricos bien definidos y no en interpretaciones vagas. Esto ayuda al sistema a reducir o aumentar la inversión sin vacilar, pero los valores siempre proceden de decisiones humanas basadas en el historial del negocio.

La rutina horaria sigue los anuncios de la séptima edición de AdSummit. El sistema lee el retorno de la inversión, lo cruza con el gasto acumulado de cada conjunto de anuncios y ajusta el presupuesto diario según intervalos que yo mismo definí a partir de las seis ediciones anteriores del evento. La idea era sencilla: vender entradas sin tener que abrir el gestor de anuncios durante todo el día.

Los criterios seguidos en aquel proyecto específico fueron estos:

• Criterio de corte: se pausa un conjunto de anuncios con ROI inferior a 0.8, pero solo después de acumular al menos 60 € de inversión, para evitar decisiones precipitadas con poca información.
• Mínimo de exploración: ningún conjunto con un gasto total inferior a 50 € puede ver reducido su presupuesto diario por debajo de 5 €, para darle tiempo al anuncio a madurar antes de descartarlo.
• Ajuste gradual: los conjuntos con retorno demostrado suben de nivel de presupuesto, mientras los intermedios bajan a valores como 15 € o 10 € diarios.
• Aviso directo: en cada ciclo horario recibo un mensaje por WhatsApp con el gasto del día, el retorno actual y los cambios realizados.

Estas cifras pertenecen a aquel proyecto y no sirven como referencia fija para otra cuenta o negocio. Cada operación tiene su propio margen y su historial, y ahí entra el trabajo de quien gestiona la campaña, no el de la máquina.

Dónde termina la lógica determinista y empieza la IA

La lógica determinista da siempre el mismo resultado ante la misma entrada, lo que la hace previsible y fácil de auditar. La IA entra cuando la información no está tabulada, cuando hay lenguaje que interpretar o cuando la variedad es demasiado amplia para un conjunto fijo de reglas.

Imagina un sistema de atención al cliente. Si basta con conocer el plan contratado para derivar la solicitud, empieza por una regla y prueba los planes posibles, incluidos los valores ausentes. Si necesitas interpretar un mensaje, prueba un modelo de lenguaje y compara su clasificación con la lectura del equipo.

Poner un modelo a decidir reglas numéricas sencillas es pagar por una complejidad que no necesitas. Corres el riesgo de que interprete mal un número fuera de formato o invente una justificación textual en vez de limitarse a modificar una variable. Para estructurar procesos de negocio más amplios sin depender solo de conversaciones con un chatbot, conviene mirar los enfoques que describo en usar la IA en el negocio más allá de las conversaciones con un chatbot.

La responsabilidad sigue siendo humana

La automatización te quita el trabajo mecánico de revisar paneles constantemente, pero sigues siendo tú quien define los límites de gasto y los criterios de corte. Eso no cambia. Si dejas que un sistema decida sobre dinero sin supervisión ni revisión periódica, existe un riesgo real de perder capital rápidamente.

Un gestor de publicidad digital no puede eludir su responsabilidad culpando a la herramienta cuando no llegan los resultados. Si una reducción del presupuesto perjudicó una campaña o un gasto excesivo pasó sin control, el fallo estaba en los límites que alguien configuró, no en la automatización en sí. La máquina cumple órdenes; entender la economía del negocio sigue siendo trabajo de quien lo gestiona.

Un ejemplo hipotético ayuda a ilustrarlo: imagina que vendes un curso de entrada a un precio simbólico, con un retorno inmediato débil o incluso negativo en las primeras semanas de campaña. Si miraras solo el retorno a corto plazo, pausarías esas campañas. Pero si esos compradores siguen comprando productos más caros durante los años siguientes, el cálculo cambia por completo. Un sistema automático que solo mirase el ROI inmediato habría cortado la inversión antes de que apareciera ese valor; por eso importa configurar la tolerancia presupuestaria según la estrategia real de captación, no según un número aislado.

Tratar las excepciones y los datos ausentes

Una automatización se vuelve vulnerable cuando la fuente de datos se retrasa, falla o devuelve valores incorrectos. Tratar esa falta de información como si fuera un resultado real de cero conversiones puede llevar a acciones destructivas antes de que alguien se dé cuenta del problema.

Si el píxel de conversiones o la API de la plataforma sufre un fallo momentáneo, el retorno comunicado cae artificialmente a cero. Un sistema sin comprobaciones lo interpretaría como un mal rendimiento y apagaría campañas que en realidad funcionaban bien. Por eso, antes de dar autonomía total a un sistema así, conviene definir algunas protecciones:

• Ventana mínima de evaluación: evaluar solo conjuntos con datos continuos durante un periodo definido, para no reaccionar a fallos pasajeros de señal.
• Parada de emergencia: si la fuente de datos devuelve errores o respuestas vacías, el sistema debe detenerse sin cambiar presupuestos, en lugar de asumir el peor escenario.
• Registro de decisiones: guardar la fecha, la métrica utilizada y el motivo de cada cambio, para poder investigar después qué ocurrió.
• Fase de avisos antes de la autonomía total: durante las primeras semanas, es más seguro que el sistema envíe recomendaciones en vez de actuar solo, hasta ganar confianza en los criterios definidos.

Construir flujos que el equipo pueda seguir sin crear dificultades es un cuidado aplicable a varias áreas del negocio, no solo a los anuncios, como describo en la guía sobre cómo montar un embudo de leads que el equipo comercial pueda trabajar.

Cómo decidir entre reglas e IA en tu propio proyecto

La elección adecuada depende de la previsibilidad de los datos de entrada, la velocidad de respuesta que necesitas y la consecuencia económica de un error de procesamiento. Antes de añadir un modelo de lenguaje, responde a esas preguntas y compara las opciones en una pequeña prueba.

Antes de introducir llamadas a modelos de IA en un flujo automatizado, conviene preguntarse:

• ¿Los datos de entrada son previsibles y estructurados? Si lo son, suele bastar una regla condicional en código.
• ¿Existe una necesidad real de interpretar lenguaje natural o una intención ambigua? Si existe, aísla esa etapa en una llamada a un modelo y devuelve el resultado en formato estructurado, sin mezclarlo con la lógica de ejecución.
• ¿La regla trata directamente con dinero o límites presupuestarios? Si es así, el paso final de ejecución debe ser determinista, sin margen de interpretación.
• ¿Hay una forma de apagar manualmente la automatización si algo sale mal? Un botón de emergencia accesible evita que un error de red o integración se prolongue sin control.
• ¿Puedes consultar el historial de decisiones del sistema? Sin ese registro, resulta difícil entender qué motivó cada cambio cuando algo no encaja.

Esta división te ayuda a elegir dónde gastar recursos: reglas para decisiones definidas e IA para tareas de interpretación. Después mide el coste, los errores y el trabajo de revisión. En mi formación en IA y automatización, podemos debatir estas decisiones a partir del proceso que estás construyendo.

Ejemplo hipotético de clasificación de solicitudes: qué queda en las reglas y qué exige interpretación

Imagina un equipo de soporte que recibe solicitudes por correo y necesita decidir cuáles siguen reglas fijas y cuáles necesitan lectura humana o de IA. Este ejemplo es hipotético, pero sirve para mostrar cómo separar las dos partes del trabajo antes de automatizar cualquier cosa.

El primer paso es mirar el tipo de solicitud, no el canal por el que llega. Una solicitud sobre una factura vencida tiene una estructura previsible: número de cliente, importe y fecha de vencimiento. Una reclamación sobre un servicio tiene texto libre, tono y, a veces, ambigüedad sobre lo que la persona quiere resolver realmente.

Para el primer caso, la regla es sencilla de escribir. Si la fecha de vencimiento pasó hace más de siete días y el importe no se ha pagado, envía un aviso automático y marca el registro como pendiente. Aquí no hay interpretación, solo comprobación de condiciones y ejecución de una acción prevista.

Para el segundo caso, la tarea exige leer el texto, entender si es urgente, si pide un reembolso, si es una queja sobre la atención o solo una pregunta mal formulada. Aquí un modelo de IA puede ayudar a clasificar la solicitud y sugerir una respuesta inicial. Pero la decisión final de reembolsar o no sigue necesitando que alguien la valide, sobre todo si hay impacto económico.

Un error común es intentar meterlo todo dentro del mismo flujo, como si hubiera que elegir entre «reglas» o «IA» para el proceso entero. En la práctica, el mismo proceso puede tener ambas cosas en secuencia. La regla filtra lo evidente y lo resuelve por sí sola, y solo el resto pasa a una etapa de interpretación, realizada por IA o por una persona.

En el ejemplo hipotético del equipo de soporte, podría funcionar así: primero, una condición comprueba si la solicitud contiene palabras clave asociadas a urgencia, como «cancelar» o «reembolso inmediato». Si las contiene, pasa directamente a revisión humana, sin pasar por ninguna IA, porque el riesgo de equivocarse es mayor. Si no, pasa a un modelo que intenta resumir la solicitud y sugerir una categoría. Solo después alguien decide si acepta la sugerencia o la corrige.

Esta secuencia tiene una ventaja práctica: puedes medir dónde está el esfuerzo. Si la mayoría de las solicitudes cae en la parte de las reglas y solo una pequeña fracción necesita interpretación, sabes que la inversión en ajustar el modelo de IA debe ser proporcional a esa fracción. No tiene sentido complicar todo el sistema con IA si el noventa por ciento de los casos se resuelve con una condición sencilla.

También hay que decidir qué hacer cuando la IA no tiene suficiente confianza en la clasificación. Una opción es definir un límite: si la confianza es baja, la solicitud pasa automáticamente a la cola de revisión humana en lugar de avanzar sola. Esto evita que los errores de interpretación pasen inadvertidos, especialmente durante los primeros meses de funcionamiento.

Por último, conviene registrar, aunque sea solo para uso interno, cuántas veces se ha aceptado la sugerencia de la IA sin cambios y cuántas se ha corregido. Esa cifra da una idea de dónde funciona bien la interpretación automática y dónde necesita ajustes, sin depender de impresiones aisladas como «funciona bien» o «falla mucho».

Cómo diseñar una excepción, pedir revisión humana y retomar sin duplicar acciones

Una excepción bien diseñada identifica el caso imprevisto, detiene ahí la acción automática, pide confirmación humana antes de continuar y registra lo realizado para no repetir pasos al retomar el proceso. Sin esos cuatro elementos, la automatización corre el riesgo de duplicar envíos, pagos o modificaciones.

El primer paso es decidir qué cuenta como excepción. No es solo un error técnico, como una conexión que falla. También es una condición que la regla no preveía, como un valor fuera del intervalo esperado o un registro que aparece dos veces en la misma ventana temporal. Si no enumeras esos casos antes de construir la automatización, los descubrirás en producción, muchas veces demasiado tarde.

Imagina un ejemplo hipotético de una rutina que ajusta el presupuesto diario de una campaña según el coste por resultado. La regla normal indica reducir el presupuesto un diez por ciento cuando el coste supera un límite definido. Pero ¿qué ocurre si los datos de origen no se actualizan durante seis horas? Sin una excepción prevista, la rutina puede seguir aplicando reducciones basadas en cifras antiguas, distorsionando la decisión.

La forma más sencilla de tratarlo es separar la detección de la acción. La automatización comprueba primero si los datos son recientes y completos. Solo si supera esa comprobación avanza hacia la regla de negocio. Si falla, entra en estado de espera, no ejecuta nada y comunica la situación a quien sigue el proceso, por ejemplo mediante un mensaje de WhatsApp o una alerta sencilla.

Pedir revisión humana no significa detener todo el sistema hasta que alguien responda. Significa aislar únicamente el caso afectado. Si tienes diez campañas activas y una cae en una excepción, las otras nueve siguen funcionando normalmente con la regla original. Esto exige que el diseño trate cada unidad de forma independiente, en lugar de tener una rutina única que procese todo en bloque y falle por completo si algo sale mal con un elemento.

Después de que alguien revise y decida, el sistema necesita saber retomar sin repetir lo que había hecho antes de la pausa. Esto solo es posible si guardas un registro del estado, por ejemplo cuál fue la última acción aplicada y a qué hora. En el ejemplo hipotético de la campaña, significa saber si el presupuesto ya se había reducido antes del fallo de datos o si todavía tenía el valor original. Sin ese registro, puedes aplicar la reducción dos veces o, por el contrario, no aplicarla nunca.

Un criterio práctico para decidir si una situación merece una excepción es preguntar cuál es el coste de equivocarse. Si un error de interpretación solo genera un informe impreciso, quizá no merezca detener la automatización. Si un error puede duplicar un pago o apagar una campaña entera sin motivo, entonces sí merece la pena dedicar tiempo a diseñar la pausa y la revisión manual.

También conviene definir un límite de intentos antes de derivar el caso a revisión humana. Si una comprobación falla una vez, puede ser un problema momentáneo en el origen de los datos. Si falla tres o cuatro veces seguidas, ya es señal de que algo ha cambiado y necesita ojos humanos, no más intentos automáticos.

Cuando aparezca una excepción, necesitas saber dónde se detuvo el proceso, qué se ha hecho y quién decidirá el siguiente paso. Ese registro evita que el equipo tenga que reconstruir la historia a partir de mensajes sueltos. Puedes trabajar estas decisiones en mi formación en IA y automatización.

Cómo evaluar coste y calidad antes de automatizar una decisión comercial

Antes de automatizar, compara siempre el coste por ejecución con el margen de error aceptable. Una regla sencilla es casi gratuita, pero poco flexible; un modelo de IA cuesta por llamada y puede fallar. Automatiza solo después de confirmar que el resultado compensa ese equilibrio entre precio y fiabilidad.

Empieza por enumerar las decisiones que quieres automatizar y sepáralas en dos grupos. En el primero quedan las que tienen un criterio objetivo, como un valor que supera un límite o una fecha que vence. En el segundo quedan las que exigen interpretación, como evaluar si un mensaje de un cliente es una reclamación grave o una petición de información. Esta separación ya ahorra tiempo, porque el primer grupo rara vez necesita IA.

Para el grupo de las reglas, el coste de ejecución es prácticamente irrelevante. Lo que importa es la calidad de los datos que alimentan la condición. Imagina, de forma hipotética, que quieres avisar siempre que el coste por resultado de una campaña suba más del 30% en un día. Si la fuente de datos falla o duplica valores, la regla disparará avisos erróneos, aunque sea sencilla de escribir.

Para el grupo que exige interpretación, el cálculo es distinto. Cada llamada a un modelo tiene un coste, que se multiplica por el volumen de casos procesados al día o al mes. Si tu operación tiene unas pocas decenas de mensajes diarios, el coste puede ser insignificante. Si tiene miles, el coste total puede ser relevante y debe compararse con el tiempo que ahorrarías a una persona.

La calidad de la respuesta del modelo tampoco es constante. Conviene probar la misma tarea varias veces, con ejemplos parecidos, y ver si la respuesta cambia de forma significativa. Si la variación es pequeña y aceptable para tu caso, la automatización puede avanzar con supervisión puntual. Si es grande, necesitas revisar el proceso antes de dar más autonomía al sistema.

Un criterio práctico e hipotético para decidir: si el error de una automatización cuesta más que el tiempo que ahorra, todavía no está lista para funcionar sin supervisión. Por ejemplo, si una regla mal calibrada genera diez falsas alertas semanales y cada una exige diez minutos de comprobación manual, el coste de mantenimiento puede anular la ganancia. En ese caso, vale más ajustar el criterio que ampliar el alcance de la automatización.

También conviene decidir, antes de activar cualquier automatización, qué aceptas como resultado suficientemente bueno. No necesita ser perfecto, pero sí previsible. Si puedes describir en qué situaciones puede fallar la automatización y qué haces cuando ocurre, ya tienes una base sólida para avanzar con más confianza.

Por último, revisa periódicamente el coste y la calidad, no solo cuando activas la automatización. Los datos de origen cambian, el volumen de casos cambia y el comportamiento de un modelo de IA también puede cambiar con el tiempo. Mantener esa revisión como hábito es lo que separa una automatización útil de otra que acaba convirtiéndose en un problema silencioso.

Cómo probar un cambio de reglas con casos conocidos y registrar los resultados

Antes de poner una regla nueva a funcionar sola, pruébala con casos que ya conoces y cuyo resultado esperado sabes de antemano. Esto permite comparar lo que decide la regla con lo que decidirías tú y detectar diferencias antes de que cuesten dinero o tiempo de corrección.

El primer paso es reunir un conjunto de casos representativos, no solo los fáciles. Si la regla consiste en detener una campaña cuando el coste por resultado supera un valor, reúne ejemplos de campañas que detendrías, otras que mantendrías pese a un pico temporal y casos límite en los que ni tú tienes certeza absoluta. Esos casos límite son los que más enseñan, porque muestran dónde hay que ajustar la frontera de la regla.

Imagina, de forma hipotética, que pruebas una regla que avisa cuando el coste por lead sube un 30% por encima de la media de los últimos siete días. Tomas diez situaciones pasadas de esa campaña, aplicas manualmente la regla a cada una y escribes al lado qué diría la regla y qué decidiste entonces. Si en ocho casos coincide contigo, pero en dos discrepa, esos dos merecen atención antes de avanzar.

Uno de ellos puede revelar que la regla se activa por un día aislado con pocos datos, en el que una sola conversión cara distorsiona la media. Esto sugiere que necesitas añadir una condición mínima de volumen antes de activar la regla, por ejemplo exigir un número mínimo de clics o impresiones en el periodo analizado. El otro caso puede mostrar lo contrario: que la regla reacciona demasiado despacio cuando el aumento del coste es rápido y consistente, y que el periodo de siete días debería acortarse en ese escenario específico.

Después de ajustar la regla según estos casos, repite la prueba con el mismo conjunto y también con casos nuevos que todavía no hayas utilizado. Así evitas ajustarla solo a los ejemplos que ya has visto, lo que la volvería demasiado específica y menos útil para situaciones futuras. Una buena regla generaliza razonablemente bien a casos que no formaban parte de la prueba original.

Registra siempre los resultados en un lugar al que puedas volver, aunque sea una hoja sencilla con la fecha, el caso probado, la decisión de la regla, la decisión que tomarías y una nota sobre lo aprendido. Este registro tiene dos funciones: ayuda a justificar por qué confías en la regla cuando alguien pregunte y da una base de comparación para el siguiente cambio, de modo que puedas ver si estás mejorando o simplemente modificando el comportamiento sin una ganancia real.

Define también un criterio claro para saber cuándo está lista la regla para funcionar sin supervisión constante. Puede ser una tasa mínima de coincidencia con tus decisiones en los casos probados, o un periodo en el que la regla solo haya avisado, sin actuar, y los avisos hayan coincidido con lo que hacías en la práctica. Solo después de cumplir ese criterio merece la pena darle autonomía para actuar sola, y aun así con un límite claro sobre qué puede y qué no puede modificar sin confirmación.

Por último, no trates esta prueba como un ejercicio único que se hace una vez y se olvida. Las condiciones del negocio cambian, los costes cambian, el comportamiento de los clientes cambia, y una regla que tenía sentido hace seis meses puede no tenerlo hoy. Marca en el calendario una revisión periódica, aunque sea sencilla, para repetir la prueba con casos recientes y confirmar que la regla sigue decidiendo como decidirías tú.