Cuándo usar IA y cuándo no: un árbol de decisión con casos reales
Casi todas las semanas llega una consulta que empieza con "queremos meter IA en…". En la mitad de los casos, la respuesta correcta es que el problema no necesita un modelo: necesita una integración, una consulta bien hecha o que alguien decida quién es el dueño de un dato.
Decirlo cuesta un proyecto y ahorra un fracaso. Esta nota es el criterio que usamos para decidir, con los casos que lo motivaron.
La pregunta que ordena todo
Antes de cualquier otra cosa: ¿el problema tiene una respuesta correcta verificable, o tiene una respuesta razonable entre varias?
- Respuesta correcta única → automatización determinista. Un modelo solo agrega variabilidad y costo.
- Respuesta razonable entre varias → posible caso para un modelo.
Todo lo demás es afinar esa distinción.
El árbol, en orden
Se recorre de arriba hacia abajo y se para en la primera que dé "sí". Los rombos son decisiones.
¿La entrada es estructurada y la regla se puede escribir?
Sí → automatización, y no hace falta seguir. "Clasificar facturas según monto y centro de costo" es un CASE WHEN, no un LLM.
¿El problema es que los datos no llegan de un sistema a otro?
Sí → integración. Un modelo no arregla una API que nadie conectó.
¿Existe un algoritmo clásico probado para esto?
Sí → úsalo. Búsqueda, ordenamiento, ruteo, optimización, detección de anomalías. Más baratos, más rápidos y explicables.
¿La tarea implica interpretar lenguaje, imágenes o audio sin estructura?
Sí → acá recién entra un modelo. "Resumir 400 respuestas abiertas y agruparlas por tema".
¿Un error tiene consecuencia legal, financiera o de seguridad?
Sí → el modelo propone, nunca decide solo. Persona en el medio, siempre.
¿Puedes armar 50 casos de prueba con su respuesta esperada?
No → ese es el primer trabajo, antes de elegir cualquier herramienta.
Recién acá se elige modelo
Y se empieza por el más chico que pase las pruebas.
Casos concretos
| Lo que pidieron | Lo que necesitaban | Por qué |
|---|---|---|
| "Un chatbot que responda sobre nuestros productos" | Buscador con el catálogo bien indexado | El 80% de las consultas eran por precio y stock: datos exactos, no interpretación |
| "IA que ordene los correos de soporte" | Clasificador simple + reglas de ruteo | Cinco categorías estables. Un modelo chico afinado costaba una fracción |
| "IA que arme el informe mensual" | Integración + plantilla | El informe siempre tenía la misma estructura; el trabajo manual era copiar datos entre planillas |
| "IA para revisar contratos" | Modelo, con abogado revisando | Lenguaje no estructurado, variabilidad alta, y la revisión humana ya existía |
| "IA para responder licitaciones" | Modelo + recuperación sobre respuestas anteriores | Genuinamente redacción, con base documental propia |
| "Predecir qué cliente se va a ir" | Modelo estadístico clásico | Datos tabulares. Un árbol de decisión gana en costo y explicabilidad |
Dónde conviene combinar, no elegir
El error simétrico al de usar IA para todo es no usarla en la parte donde sirve. El patrón que mejor funciona es el modelo en el borde, el determinismo en el centro:
Entrada desordenada
Un correo, un PDF escaneado, un audio, una foto.
El modelo interpreta
Convierte eso en datos estructurados: campos, montos, categorías.
Validación
Rangos, formatos, reglas de negocio. Lo que no pasa, se deriva a una persona.
La lógica decide
Determinista y auditable. Acá vive el criterio, en código que se puede leer y probar.
El modelo redacta
Solo si la salida tiene que ser lenguaje natural.
Así el criterio queda escrito en código que se puede leer y probar, y el modelo hace lo único que hace mejor que cualquier otra cosa: lidiar con lenguaje.
Buenas y malas prácticas
| Mala práctica | Buena práctica | |
|---|---|---|
| Alcance | "Meter IA en la operación" | Una tarea acotada con dueño y métrica |
| Evaluación | Probar con cinco ejemplos que salieron bien | 50–100 casos con respuesta esperada, corridos en cada cambio |
| Modelo | Empezar por el más grande | Empezar por el más chico que pase las pruebas |
| Errores | Suponer que no van a pasar | Definir de antemano qué se hace cuando pase |
| Datos | Mandar todo lo que hay | Mandar lo mínimo necesario, y saber qué sale de la empresa |
| Costo | Estimar por el precio del token | Estimar por consulta completa, con contexto y reintentos |
| Personas | Anunciar reemplazo | Definir qué revisa la persona y cuándo |
Las tres preguntas antes de firmar
- ¿Cómo vamos a saber si funciona? Si no hay respuesta, no hay proyecto.
- ¿Qué pasa cuando se equivoca? Todo sistema probabilístico se equivoca. El diseño del error es parte del diseño.
- ¿Cuánto cuesta al mes con el volumen real? No con el volumen de la demo.
Si estas tres tienen respuesta, la conversación sobre qué modelo usar recién ahí tiene sentido — y para eso está el mapa de quién es quién en los LLM.