Cuándo NO utilizar inteligencia artificial

Hoy casi cualquier proyecto llega con la misma pregunta: «¿dónde metemos la IA?». Es una pregunta comprensible, pero está planteada al revés. La pregunta útil es otra: ¿qué necesita este sistema?

A veces la respuesta es un modelo de IA. Muchas otras veces es una regla clara, una consulta SQL o una validación en el servidor. La IA es una herramienta muy potente, pero es eso: una herramienta. No es la arquitectura.

Una regla sencilla

Si puedes escribir la regla, escribe la regla.

El software determinista es más rápido, más barato, más predecible y más fácil de probar. Hace exactamente lo mismo cada vez. La IA aporta cuando el problema tiene algo que no cabe en reglas fijas: lenguaje natural ambiguo, imágenes, criterio experto, variación.

Por eso la aritmética, el cumplimiento normativo, los permisos, los formatos de archivo y cualquier cosa que tenga que salir igual siempre deberían quedarse del lado determinista. Estos son cuatro sistemas donde se tomó esa decisión.

Gustela CRM: funcionalidad convencional cuando la IA no aporta

Gustela CRM gestiona un proceso comercial de prospección: pipeline, campañas por lotes con límite diario, tareas de seguimiento y exclusión automática de quien no debe recibir más mensajes.

Todas esas reglas son claras. Nadie dado de baja, rebotado o marcado como no contactar puede volver a la cola, y eso se aplica en el servidor antes de encolar. Este sistema no usa IA: nada en el proceso la necesitaba, y añadirla habría sumado coste e incertidumbre sin aportar capacidad.

Caso Gustela CRM: un CRM sin IA porque no hacía falta

Zentia: reglas deterministas cuando son suficientes

Zentia permite buscar propiedades en lenguaje natural. Una frase como «villa con piscina en Marbella hasta 500k» se convierte en filtros de tipo, zona, precio y características, que aparecen como chips editables.

Parece un caso de manual para un modelo de IA, pero la interpretación se resuelve con reglas. El vocabulario de una búsqueda inmobiliaria es acotado, y las reglas son rápidas, predecibles y no cuestan nada por consulta. Si una regla se equivoca, se ve en el chip y se corrige.

Caso Zentia: búsqueda en lenguaje natural resuelta con reglas

RetoQ: IA para el criterio, software para el resultado

RetoQ sí usa IA, y mucha: un modelo de visión evalúa cada fotografía con una rúbrica editorial de cinco criterios y propone tres revelados con valores de Lightroom. Es justo el tipo de criterio que no cabe en reglas fijas.

Pero la IA no se queda con todo:

La nota la calcula el servidor, no el modelo: es la suma de los cinco criterios por dos. La aritmética no se le confía a un modelo.
Las respuestas pasan por esquemas JSON estrictos. Si el modelo devuelve una puntuación fuera de rango, la evaluación se rechaza entera.
El archivo .xmp lo escribe el sistema. Un segundo modelo propone nombres de atributo; el servidor construye el XML y descarta lo que no reconoce. El preset siempre es válido, aunque el modelo se despiste.
El producto dice lo que no hace: las máscaras del preset son geométricas, no detectan el cielo aunque se llamen «Cielo».

El modelo juzga; el servidor calcula.

AtalayaIQ: IA con acceso acotado y datos verificables

AtalayaIQ es una capa de inteligencia sobre siete años de datos operativos de una empresa de eventos nacional. Tiene un asistente para preguntar sobre el informe, pero el acceso del modelo está cerrado por diseño:

El modelo elige una operación de un catálogo cerrado; el servidor valida los parámetros y ejecuta SQL fija y parametrizada.
El modelo no escribe SQL, no ve credenciales ni tablas fuera del catálogo.
Al proveedor solo viajan la pregunta, el historial en texto y resultados agregados.
Las alertas no las decide la IA: salen de siete reglas deterministas, cada una con su evidencia.

Y todo lo que el sistema afirma se ha conciliado de forma independiente con SQL escrito a mano. La IA responde preguntas sobre datos que ya se sabe que son ciertos.

Preguntas antes de añadir IA a un proceso

Antes de decidir, conviene responder a estas preguntas:

¿Se puede escribir la regla? Si se puede, probablemente no hace falta un modelo.
¿Qué pasa cuando se equivoca? ¿Quién lo detecta y cuánto cuesta el error?
¿Qué parte tiene que ser exacta y reproducible? Esa parte, en el servidor.
¿A qué datos accede el modelo y qué sale hacia el proveedor?
¿Cuánto cuesta cada llamada y quién lo ve antes de gastar?

Si después de responderlas la IA sigue aportando algo que las reglas no pueden dar, adelante. Con límites claros, datos ordenados y software que la acote, es cuando mejor funciona.

La pregunta no es dónde meter IA, sino qué necesita el sistema.

En IA y automatización explico cómo diseño sistemas que usan IA donde aporta y software convencional donde es mejor solución.