Cuándo usar IA y cuándo no

Un product manager dice: "agreguémosle IA". El equipo asiente, pero la pregunta útil viene después: ¿IA para qué, y por qué? Hay problemas que el machine learning transforma. Hay otros que se vuelven más lentos, más caros y menos confiables cuando les atornillas un modelo encima. El examen de AI Practitioner mide si sabes distinguirlos, y lo mismo hace cualquier reunión de presupuesto real. Esta lección te da el criterio para decir que sí por las razones correctas y para decir que no sin titubear.

El tema anterior te enseñó qué son la IA y el ML y cómo aprenden los modelos. Este arranca la mitad práctica: dado un problema de negocio, ¿el machine learning es siquiera la herramienta adecuada? Si te equivocas en esa decisión, ningún modelado brillante salva el proyecto.

Dónde la IA y el ML se ganan su lugar

El machine learning aporta valor en tres patrones que se repiten. Cuando un problema encaja en alguno, vale la pena considerarlo. Cuando no encaja en ninguno, desconfía.

El primer patrón es asistir decisiones humanas. El modelo no decide; muestra una predicción y una persona actúa sobre ella. El radiólogo sigue firmando el estudio, pero un modelo marca las tres zonas con más probabilidad de necesitar una segunda mirada. El analista de crédito sigue aprobando el préstamo, pero un modelo califica primero el riesgo de impago. El valor es un humano más rápido y mejor informado, no un humano reemplazado.

El segundo patrón es escalar una solución más allá de la capacidad humana. Hay tareas triviales para un elemento e imposibles para millones. Leer una reseña de producto es fácil; leer 4 millones de reseñas al día para seguir el sentimiento no lo es. Un modelo que clasifica cada reseña en milisegundos convierte una tarea imposible en una rutina. La señal aquí es un volumen que ningún equipo podría cubrir con personal.

El tercer patrón es automatizar juicios repetitivos. No mecánica repetitiva, que un script ya resuelve, sino decisiones repetitivas que antes necesitaban a una persona: enrutar un ticket de soporte a la cola correcta, etiquetar fotos por contenido, transcribir llamadas. Cuando la misma decisión difusa ocurre una y otra vez y se tolera una tasa pequeña de error, automatizar con ML libera gente para trabajo que sí la necesita.

Fíjate en lo que une a los tres: el patrón es complejo o de alto volumen, y una respuesta buena aunque imperfecta de verdad sirve. Guarda esa idea, porque los casos donde el ML fracasa son justo donde eso se rompe.

El lado del costo

El examen menciona explícitamente el análisis costo-beneficio como razón para decir que no, y la trampa está en contar solo la mitad del costo. Los equipos calculan la primera corrida de entrenamiento y ahí se quedan. Un modelo en producción es un sistema vivo con costos recurrentes que muchas veces superan a la construcción.

Pagas por recolectar y etiquetar datos antes de poder entrenar cualquier cosa, y el etiquetado suele ser la línea más cara. Pagas por entrenar, y para modelos grandes esa cuenta es real. Después del lanzamiento empiezan los costos continuos: monitorear el modelo para notar cuándo se degrada su precisión, reentrenarlo con datos frescos a medida que cambia el mundo (un modelo de fraude entrenado con el fraude del año pasado se queda viejo) y el tiempo de ingeniería para mantener el pipeline en pie. Un modelo que tomó dos semanas construir puede tomar años mantener.

Así que la pregunta real nunca es "¿puede el ML hacer esto?". Es "¿el valor supera el costo total de vida?". Un modelo que sube la conversión 0.1% puede ser un resultado técnico brillante y una pésima inversión si necesita tres ingenieros para seguir vivo. Pesa el beneficio contra datos, entrenamiento y mantenimiento juntos, no contra la corrida de entrenamiento sola.

Cuando una predicción es la forma equivocada de respuesta

Esta es la idea más valiosa de la lección y la que más prueba el examen. El machine learning produce predicciones, y las predicciones son probabilísticas: casi siempre correctas, a veces equivocadas, nunca garantizadas. Cuando la tarea exige un resultado específico, exacto y demostrable, una predicción es la forma equivocada de respuesta por más preciso que sea el modelo.

Calcular el impuesto sobre ventas es el ejemplo limpio. El impuesto sigue reglas publicadas, y la cifra en la factura debe ser exactamente correcta y defendible en una auditoría. Un modelo "99.7% preciso" en impuestos es un sistema roto, porque ese 0.3% es un problema legal. La herramienta correcta es una regla: busca la tasa, multiplica, listo. La misma lógica cubre calcular el saldo de una cuenta, aplicar un descuento fijo, verificar una contraseña o hacer cumplir una política dura de negocio. Lógica conocida más respuesta exacta obligatoria significa escribe la regla, no entrenes el modelo.

Contrasta eso con pronosticar las ventas del próximo trimestre. Ninguna regla puede producir la cifra exacta, una predicción aproximada de verdad sirve, y quedar cerca es un éxito. Ese es el terreno del ML. La prueba que te llevas al examen: si la tarea necesita una única respuesta demostrablemente correcta a partir de lógica conocida, descarta el ML; si necesita una buena estimación de algo incierto, el ML es candidato.

Otras razones para decir que no

Más allá de la regla del resultado exacto, hay cuatro señales de que un problema no necesita ML.

• La lógica es simple y conocida. Si puedes escribir la regla en pocas líneas y no va a cambiar, escríbela. Un modelo para decidir si un número es par es absurdo; n % 2 == 0 es exacto, gratis y permanente.
• No tienes suficientes datos de calidad. El ML aprende de ejemplos. Cuarenta registros parciales no van a enseñar un modelo de abandono confiable. Sin datos no hay patrón, y sin patrón no hay modelo, por bien que suene el caso de uso.
• Los errores son intolerables y nadie los revisa. Si una salida equivocada causa daño real y ninguna persona la revisa, la naturaleza probabilística del ML es un pasivo. O agregas revisión humana o usas un método determinista.
• No puedes definir el éxito. Si no puedes decir cómo se ve una buena predicción ni medirla, no puedes entrenar ni evaluar un modelo. Una meta difusa produce un sistema difuso en el que nadie confía.

Una guía rápida de decisión

El machine learning necesita que las tres primeras se inclinen al sí y que la trampa del resultado exacto esté ausente. Si falla alguna, la respuesta honesta es que el ML es la herramienta equivocada.

Consejos para el examen

El examen pone trampas que premian la regla del resultado exacto y castigan el entusiasmo de "IA para todo".

• La palabra clave más fuerte para descartar el ML es "se necesita un resultado específico" o "un resultado exacto o preciso". Cuando la veas, la respuesta es que el ML no es apropiado; elige la opción basada en reglas o determinista.
• "Costo-beneficio" en el enunciado suele señalar que la respuesta correcta pesa el mantenimiento y los costos de datos continuos, no solo la precisión. Busca la opción que mencione el costo total de vida.
• Patrones de valor que debes reconocer como pro-ML: "asistir la toma de decisiones", "escalar", "automatizar", "manejar alto volumen", "detectar patrones que los humanos no ven".
• No te dejes llevar por "la tarea es repetitiva". Repetición con lógica simple y fija es un script, no un modelo. El examen planta esto para ver si confundes automatización con ML.

La regla que te llevas: el machine learning cambia exactitud por capacidad de manejar complejidad y escala, así que encaja cuando el patrón es difícil y una estimación sirve, y falla cuando la respuesta debe salir exacta de una lógica conocida. Una vez que decidiste que el ML es la herramienta correcta, la siguiente pregunta es qué técnica encaja, y ahí empieza la próxima lección sobre regresión, clasificación y clustering.