Cuándo usar IA en un producto (y cuándo no)
Usa IA cuando la entrada es lenguaje libre o ambiguo, y reglas cuando la respuesta se puede escribir como condiciones. Prueba práctica, tabla y errores.
¿Cuál es la prueba práctica?
La prueba más útil es sencilla: ¿la tarea tiene una respuesta correcta que se puede escribir como condiciones? Si la respuesta es sí, una regla basta. Es barata, rápida, consistente y no puede inventar nada.
Un ejemplo claro: marcar una factura que supera un umbral de aprobación es una regla. Enrutar un lead por código postal es una regla. Copiar datos de una reserva a otro sistema es una regla. Ninguna de estas tareas gana nada con un modelo de lenguaje, y cada una pierde algo: costo, latencia y la garantía de que el resultado sea idéntico cada vez.
La IA entra cuando la entrada es un texto libre que hay que entender, o cuando hay un juicio sin regla limpia. La guía de 13Labs da dos casos típicos: leer un correo de consulta en texto libre para sacar el tipo de trabajo y la dirección, y redactar una respuesta con el tono del negocio. Su regla general conviene recordarla: usa IA solo donde se requiere lenguaje o juicio genuino, y reglas para todo lo demás, que es casi todo.
¿En qué tareas suele ganar la IA?
La guía People + AI (PAIR) de Google tiene una lista útil para contrastar. Dice que la IA probablemente es mejor para:
- Recomendar contenido distinto a cada usuario.
- Predecir eventos futuros.
- Entender lenguaje natural.
- Reconocer una clase entera de cosas (por ejemplo, cualquier foto de un perro, no solo una imagen concreta).
- Detectar eventos poco frecuentes que cambian con el tiempo, como un fraude con patrones nuevos.
Y que las reglas o heurísticas probablemente son mejores cuando importa mantener la previsibilidad, cuando se da información estática o limitada, cuando hay que minimizar errores costosos, cuando se necesita transparencia completa y cuando se optimiza velocidad y costo.
PAIR añade otra pregunta, distinta de “IA o reglas”: automatizar o aumentar. Conviene automatizar cuando la tarea es aburrida, repetitiva o peligrosa, o cuando la gente no tiene el conocimiento para hacerla. Conviene aumentar (ayudar sin reemplazar) cuando la gente disfruta la tarea, cuando su responsabilidad personal importa o cuando lo que está en juego es alto.
¿Qué debe quedarse en reglas?
Hay partes del producto que no deberían depender de un modelo, aunque el modelo sea bueno en general:
- Validaciones: un correo con formato válido, una fecha que no puede estar en el pasado, un monto dentro de un rango.
- Autenticación y permisos: quién puede ver o borrar qué. Un error aquí no es un mal texto, es un incidente de seguridad.
- Cálculos financieros y de precios: el resultado debe ser idéntico cada vez y auditable.
- Transacciones: cobrar, reembolsar, cambiar un estado. Deben ser predecibles.
Un artículo de Reworked (David Barry, septiembre de 2026) reúne a varios especialistas con criterios parecidos: usa automatización determinista cuando existe una única respuesta correcta que un sistema de registro puede devolver, cuando el resultado esperado se puede escribir como una lista de verificación auditable, cuando un error es costoso y no se anuncia solo, o cuando el resultado debe ser igual siempre. El costo extra de un agente solo se paga cuando la tarea exige juicio en condiciones que cambian, como sopesar señales contradictorias con incertidumbre.
¿Cómo se combinan reglas e IA en un flujo híbrido?
Casi siempre la respuesta es combinar. 13Labs lo dice directo: la mayoría de las automatizaciones reales son híbridas. El patrón tiene dos variantes, ambas descritas también en Reworked:
- Reglas para la mayoría, IA para la parte ambigua. Las reglas gestionan los pasos fijos y solo la porción difusa va al modelo.
- IA para normalizar, reglas para decidir. El modelo convierte un texto libre en un esquema limpio, y un motor determinista aplica la lógica de negocio sobre ese esquema.
La idea es darle a la IA la porción más pequeña posible del trabajo. Esa separación es también una decisión de diseño: deja claro al usuario qué paso es interpretación y cuál es acción.
Tabla de decisión
| Pregunta | Si la respuesta es sí | Si la respuesta es no |
|---|---|---|
| ¿Hay una única respuesta correcta en un registro? | Regla | Evalúa la IA |
| ¿La entrada es lenguaje libre? | IA para extraer o entender | Regla o formulario |
| ¿Un error es caro o difícil de detectar? | Regla con auditoría | IA con revisión humana |
| ¿El resultado debe ser idéntico cada vez? | Regla | IA aceptable |
| ¿Hay un humano revisando antes de actuar? | IA puede proponer | IA no debe actuar sola |
La tabla no es un algoritmo. Es una lista de preguntas para discutir en el equipo antes de construir.
¿Cómo pruebas si la IA aporta lo suficiente?
Compara la función con IA contra una regla simple antes de comprometerte. Es el paso que más fácil se salta. Ejemplo ilustrativo: un equipo quiere un “asistente inteligente” para clasificar tickets de soporte. Antes de integrar un modelo, prueba una regla con palabras clave y una lista de categorías. Con cifras inventadas para ilustrar el cálculo: si la regla acierta el 85% de los casos, la IA solo tiene que mejorar ese 15% difícil, y el costo de mantener un modelo debe justificarse con ese margen.
Pasos sugeridos:
- Define la decisión de negocio en una frase.
- Construye la versión con regla y mídela con casos reales.
- Construye la versión con IA en una tarea acotada, no en todo el flujo.
- Compara precisión, costo, latencia y cuántos casos requieren revisión humana.
- Elige la regla salvo que la IA gane con evidencia clara.
Reworked advierte de un fallo silencioso: un agente sin barreras puede convertir un resultado nulo en una respuesta segura y plausible, pero sin respaldo en la fuente de verdad. Por eso cada paso de IA debe devolver algo verificable, o algo que el sistema pueda rechazar.
Ejemplo
Ejemplo ilustrativo: una app de logística recibe pedidos por WhatsApp en texto libre. El flujo se separa en tres partes. Un modelo lee el mensaje y extrae producto, cantidad y dirección, devolviendo un esquema con campos vacíos cuando no está seguro. Reglas validan que la dirección exista en el catálogo de zonas y que la cantidad sea un número positivo. Si la validación falla, el sistema pide el dato faltante al cliente, no lo adivina. El cobro y la asignación de ruta son reglas puras, auditables. La IA ocupa un solo paso y su error se ve en la pantalla de confirmación, que el cliente aprueba antes de cualquier acción.
Errores comunes
- Poner IA en validaciones, permisos o cálculos que deberían ser reglas.
- Construir un motor de reglas con cientos de condiciones anidadas cuando un modelo podría normalizar la entrada.
- Saltar la comparación con una regla simple.
- Dejar que el modelo actúe sin confirmación cuando el error sería caro.
- Presentar la IA como si fuera infalible en lugar de mostrar su límite.
- Añadir IA “porque suena bien” en una función que se resuelve con un formulario.
¿Cuándo NO conviene usar IA?
Cuando la tarea es repetitiva, de volumen alto y con criterios claros, o cuando los datos son sensibles y no hay forma de auditar lo que decide el modelo. También cuando el equipo no puede medir la calidad del resultado. En esos casos, una regla bien escrita, un formulario o una mejora del flujo son mejores que una IA sin control.
Para decidir cuánta autonomía dar a un sistema con IA, revisa niveles de autonomía y decide qué pasos necesitan revisión humana antes de actuar. La estrategia completa se trabaja en estrategia de producto con IA.