Por: Alejandro Urueña
Ética e Inteligencia Artificial (IA) - Founder & CEO Clever Hans Diseño de Arquitectura y Soluciones en Inteligencia Artificial. Magister en Inteligencia Artificial.
Por: María S. Taboada
Lingüista y Magíster en Psicología Social. Profesora Titular de “Linguística General I” y “Política y Planificación Linguísticas” de la Fac. de Filosofía y Letras de la UNT.
Dos preguntas definen en parte el éxito o el fracaso de cualquier sistema de IA: ¿cuánto error podemos tolerar? ¿Y sobre qué problema exactamente estamos trabajando? La metodología que enseñan las mejores escuelas de datos del mundo arranca —siempre— por ahí.
Cada semana se anuncian nuevos proyectos de inteligencia artificial en empresas, organismos públicos y estudios profesionales de la región. Y cada semana, en silencio, varios de esos proyectos fracasan. No por falta de datos. No por falta de tecnología. Fracasan en el minuto cero, antes de encender una computadora.
El error más común no es técnico: es conceptual. Los equipos se lanzan a construir modelos sin haber respondido dos preguntas básicas que determinan si el proyecto tiene sentido o no: ¿sobre qué tarea específica, concreta y medible queremos que actúe la inteligencia artificial? ¿Y cuánto error estamos dispuestos a tolerar? Responder mal —o no responder— cualquiera de estas dos preguntas garantiza el fracaso. No el fracaso dramático y visible, sino el peor: el fracaso silencioso, el proyecto que se arrastra meses sin que nadie sepa bien si funciona. El error que estamos dispuestos a sobrellevar está en relación con el tipo y la especificidad de la tarea. Y la magnitud de su impacto es correlativa a lo que se quiere lograr. No es comparable el error de un LLM que, al no encontrar una referencia bibliográfica, la inventa (fenómeno técnicamente conocido como “alucinación”: cuando el modelo produce información falsa con apariencia de verdadera), con el error de un algoritmo que direcciona un arma mortal y termina destruyendo una escuela con más de un centenar de niñas. La magnitud del error está en relación al qué y para qué del modelo a diseñar.
En el vocabulario de la inteligencia artificial, error tiene un significado preciso: es cuando el modelo se equivoca. Se le muestran mil fotos de documentos y el sistema clasifica mal cincuenta. Se le proporcionan datos de clientes y predice incorrectamente quién va a incumplir un contrato. Eso es error. Lo que pocos equipos discuten antes de empezar es que no todos los errores cuestan lo mismo, y que existe un límite determinante por debajo del cual ningún sistema —humano o artificial— puede llegar.
Ese límite está vinculado al error humano, y es el primer número que cualquier proyecto serio debería calcular. Consiste en medir cuánto se equivoca el mejor experto humano realizando exactamente la misma tarea que se quiere automatizar. Tomemos un ejemplo cercano al lector argentino: supongamos que se quiere construir un sistema de IA para clasificar demandas laborales según su probabilidad de condena. Antes de diseñar el modelo, la pregunta que hay que responder es: ¿en cuántos casos diez jueces expertos estarían en desacuerdo? Si coinciden en 92 de cada 100 fallos, el 8% restante representa la incertidumbre propia de la tarea, no de la herramienta. Y cuando decimos “propia de la tarea”, nos estamos refiriendo a que el desarrollo del algoritmo —por lo menos hasta el presente— depende de humanos en su fase de diseño, construcción y monitoreo. Pedirle al sistema de IA un error menor al 8% es pedirle algo que ni los mejores juristas pueden alcanzar. Sin conocer ese piso, se está esperando del modelo algo imposible.
Una vez establecido ese piso de referencia, la metodología distingue tres métricas que deben analizarse en orden, porque cada una revela algo diferente sobre la “salud” (operatividad y escalabilidad) del sistema. El primero es el error de entrenamiento: cuánto se equivoca el modelo con los datos que ya procesó. Si este número es alto, el sistema ni siquiera aprendió los patrones básicos, un fenómeno que los especialistas llaman underfitting o sub-ajuste. Es equivalente al alumno que reprueba el examen de práctica con las mismas preguntas que ya estudió: algo salió muy mal en el proceso de aprendizaje.
El segundo es el error de test: cuánto se equivoca con datos que nunca vio. Este es el examen real. Aquí aparece el problema opuesto: el overfitting o sobre-ajuste. Un modelo que en entrenamiento acierta 95 de cada 100 casos pero en el test sólo acierta 60 memorizó las respuestas sin “entender” establecer relaciones más allá del registro. Operativizó los 200 fallos laborales que estudió, pero se pierde ante 50 casos nuevos. No “aprendió”: archivó. La clave no está en mirar cada número de forma aislada, sino en la diferencia entre ambos. Una brecha grande entre error de entrenamiento y error de test es la señal de alarma más confiable que existe en cualquier proyecto de aprendizaje automático. Conviene detenerse en ese término, porque suele generar confusión en el lector no especializado. Pensemos en una cadena de supermercados que quiere entender por qué algunos clientes cargan el changuito con productos de alto margen y otros se van con lo mínimo.
Un programa tradicional aplicaría reglas escritas por el equipo comercial: “ubicá la leche y el pan al fondo del local para que la clienta atraviese todas las góndolas antes de llegar a lo esencial”. El aprendizaje automático (en inglés, machine learning, una rama de la inteligencia artificial donde el sistema deduce reglas a partir de ejemplos en lugar de recibirlas escritas) funciona al revés: en vez de entregarle un manual al equipo comercial, le damos al sistema los registros de un millón de compras —qué productos miró cada cliente, cuántos segundos se detuvo frente a cada góndola (medido con cámaras y sensores), qué música sonaba, a qué temperatura estaba el local, qué promociones había activas, qué compró finalmente y cuánto gastó— y dejamos que descubra los patrones por su cuenta. Con el tiempo, el sistema aprende que los clientes que se detienen más de ocho segundos frente a la góndola de chocolates cuando suena música instrumental lenta gastan un 22% más, o que la iluminación cálida en la sección de panadería dispara la compra impulsiva de productos dulces. Nadie le dictó esas reglas; las infirió de los datos. Eso es, en esencia, lo que hace un modelo de aprendizaje automático aplicado al neuromarketing: descubre patrones (relaciones estadísticas entre variables) que ningún gerente comercial habría podido formular por escrito. Y por eso mismo es tan delicado: si los datos provienen sólo de sucursales de zonas acomodadas, el “patrón descubierto” no será una verdad sobre el consumo humano, sino un reflejo sesgado de un segmento particular vendido como regla universal.
Pero hay una dimensión del error que va más allá de los porcentajes: el costo de equivocarse en una dirección versus en la otra. Esta es la diferencia entre quien entiende la tecnología y quien entiende el negocio. Tomemos un banco que usa IA para aprobar préstamos. Un falso negativo ocurre cuando el sistema dice «no va a pagar» pero el cliente sí iba a pagar: se pierde un cliente rentable. Molesta, pero no es catastrófico. Un falso positivo ocurre cuando el sistema dice «va a pagar» pero el cliente no paga: el banco pierde dinero real, enfrenta un juicio, ejecuta garantías. Es un daño concreto y medible.
En el mundo jurídico el razonamiento es idéntico. Un sistema que clasifica demandas laborales como de alta o baja probabilidad de condena comete errores en ambas direcciones. Decir «baja» cuando era «alta» puede costarle al cliente decenas de miles de pesos en una sentencia que podría haberse negociado. Decir «alta» cuando era «baja» es un error tolerable: se negoció un acuerdo innecesario, se perdió tiempo, no dinero. La pregunta que todo proyecto de IA debería responder antes de construir nada no es cuánto error tiene el modelo, sino qué tipo de error nos podemos permitir y cuál nos destruye. La respuesta define cómo calibrar el sistema, qué métricas priorizar y qué umbrales de decisión usar.
La pregunta fundacional define el alcance: decidir con precisión quirúrgica qué tarea específica va a resolver el sistema. No «mejorar la atención al cliente» ni «optimizar los procesos». Una cosa concreta, medible, que pueda evaluarse cuando termina. La diferencia práctica es enorme. «Queremos usar IA para mejorar la atención al cliente» no es un proyecto: es un deseo. No se puede construir, no se puede medir y no se puede evaluar. Distinto es cuando se usa IA para complementar la atención al cliente y ahorrar tiempo en los reclamos usuales que pueden categorizarse como patrones, sin dejar de lado la necesaria intervención del humano que es capaz de comprender, entender y encontrar vías de resolución de un problema que no responde a esos patrones usuales. Por ejemplo, «clasificar correos de reclamo en cinco categorías para que lleguen al área correcta en menos de dos horas». Se sabe exactamente cuándo funciona y cuándo no. La conexión entre alcance y error es directa: si el alcance es preciso, el error se puede medir. Si el alcance es vago, el error es inmensurable. Y sin poder medir el error, nadie sabe si el modelo funciona. Ahí termina cualquier proyecto. Sin alcance preciso no hay métricas posibles, sin métricas no hay evaluación posible, y sin evaluación el proyecto no termina: simplemente se abandona.
La metodología que se enseña en las mejores universidades de datos del mundo arranca siempre por el mismo lugar: antes de abrir un entorno de programación, antes de hablar de algoritmos, antes de discutir arquitecturas de redes neuronales, hay que definir el alcance del problema y el error aceptable. No es una formalidad burocrática. Es la diferencia entre un proyecto que termina y uno que no. Entre un sistema que el cliente puede usar y uno que nadie sabe cómo evaluar. Entre tecnología que resuelve un problema real y tecnología que acumula horas de trabajo sin dirección.
En un momento en que la inteligencia artificial está siendo adoptada con velocidad creciente por empresas, estudios jurídicos, organismos públicos y cooperativas del NOA, esta discusión importa. No para frenar la adopción, sino para hacerla bien. Porque el fracaso de un proyecto de IA no es sólo un problema técnico: es un problema de confianza. En la tecnología, en el equipo que la implementó y —a veces— en la institución que la avaló. Y la mayoría de esos fracasos se evitan respondiendo dos preguntas antes de escribir la primera línea de código.
