Inteligencia Artificial

Antes de diagnosticar, define qué significa que la IA funcione

Decir que una IA “no funciona” es demasiado ambiguo para tomar decisiones. Puede significar que comete errores, tarda demasiado, exige mucho retrabajo, genera resultados inconsistentes o simplemente que no mejora el proceso anterior. Antes de atribuir el problema a una causa, hay que definir qué resultado debía producir el caso de uso y bajo qué condiciones podía considerarse aceptable.

Esa referencia debe traducirse en criterios observables y comparables según el caso de uso. El NIST AI Risk Management Framework plantea incorporar criterios de confiabilidad durante el diseño, desarrollo, uso y evaluación de los sistemas de IA. Sin una línea base comparable, el diagnóstico se apoya más en impresiones que en evidencia.

Separa síntomas de causas antes de intervenir

Un síntoma indica dónde mirar, pero no demuestra qué está fallando. Si un asistente interno devuelve respuestas incorrectas, por ejemplo, el modelo puede tener una limitación real, pero también puede estar recibiendo documentación desactualizada, instrucciones ambiguas o preguntas que el proceso nunca definió correctamente.

La pregunta útil no es “¿por qué falla la IA?”, sino “qué hipótesis explica mejor este patrón de fallo?”. Si los errores aparecen solo con determinados documentos, conviene investigar primero la información de entrada. Si aparecen incluso con datos controlados y tareas simples, la hipótesis tecnológica gana peso.

Fija una línea base y criterios de aceptación observables

La comparación debe hacerse contra una referencia relevante: el proceso manual anterior, un resultado elaborado por un profesional competente o un conjunto de casos previamente validados. No tiene sentido exigir perfección a la IA si el procedimiento que sustituye ya acumulaba errores, pero tampoco aceptar una mejora aparente si el retrabajo posterior elimina el ahorro conseguido.

Antes de probar cambios, conviene fijar cinco elementos:

• Resultado esperado: qué debe producir el caso de uso y para qué tarea, decisión o proceso.
• Línea base: contra qué resultado humano, proceso anterior o conjunto validado se realizará la comparación.
• Umbral de aceptación: qué nivel de calidad, tiempo, error o intervención humana permite considerar útil la salida.
• Casos de prueba: ejemplos representativos del uso real, incluidas las excepciones que puedan alterar el resultado.
• Coste del fallo: qué retrabajo, retraso, riesgo o supervisión genera una salida que no alcanza el umbral.

Esta referencia evita redefinir qué significa “funcionar” después de ver los resultados. Reducir un informe de diez a tres minutos no supone una mejora si después requiere ocho minutos de revisión. Medir solo la generación ocultaría el coste real.

Aísla si el problema está en la tecnología o en los datos

Cuando el resultado es deficiente, conviene empezar por una prueba controlada: mantener estable la tarea y modificar una sola variable. Si el mismo conjunto de entradas mejora de forma consistente al cambiar de modelo, configuración o proveedor, la hipótesis tecnológica gana fuerza. Si el resultado apenas cambia, probablemente la causa está en otra capa.

Después hay que comprobar qué información recibe el sistema. Instrucciones incompletas, documentación desactualizada o contexto insuficiente pueden limitar incluso a un modelo adecuado.

Cuándo sospechar del modelo o de la herramienta

Hay motivos para investigar la tecnología cuando los errores persisten con datos controlados, instrucciones claras y tareas bien delimitadas. También cuando el sistema falla precisamente en capacidades que el caso de uso necesita, como mantener contexto extenso, seguir formatos estrictos, trabajar con determinados idiomas o responder dentro de unos límites de latencia concretos.

La prueba útil no consiste en preguntar si otro modelo “parece mejor”, sino en ejecutar el mismo conjunto de casos con condiciones equivalentes. Si una alternativa supera de forma repetida los umbrales definidos sin introducir nuevos costes o riesgos inaceptables, existe evidencia para plantear un cambio. Un resultado aislado no basta.

Cómo comprobar si fallan los datos, el contexto o la información de entrada

Los datos deben revisarse como parte del sistema, no como un recurso externo que se da por válido. Conviene comprobar actualidad, cobertura, consistencia, permisos, formato y relación con la tarea. Una base documental extensa puede seguir siendo insuficiente si contiene versiones contradictorias o no incluye precisamente la información necesaria para resolver las consultas reales.

Un microejemplo ayuda a distinguirlo. Si un asistente responde mal sobre una política interna porque existen tres versiones diferentes del procedimiento, cambiar de modelo puede mejorar la redacción, pero no resolver la contradicción. En ese caso, la corrección prioritaria está en la fuente de información, no en la IA.

Si mejorar datos o contexto corrige el resultado sin tocar el modelo, la evidencia apunta a esa capa y debilita la necesidad de migrar.

Comprueba si el cuello de botella está en el proceso o en el equipo

Si modelo, datos y contexto superan las pruebas básicas, el siguiente paso es observar cómo encaja la IA en el trabajo real. Una solución puede producir respuestas correctas y, aun así, no mejorar el resultado porque el proceso que la rodea está mal diseñado o porque exige decisiones que nadie ha definido.

También hay que separar proceso y capacidades: no definir quién revisa una excepción es distinto de tener responsable pero no saber reconocer una salida incorrecta.

Detecta procesos mal diseñados que la IA solo está amplificando

Antes de automatizar o ampliar el uso, revisa pasos, decisiones, responsables y excepciones. Si el proceso manual ya incluía duplicidades, criterios ambiguos o transferencias innecesarias, la IA puede ejecutar esas deficiencias más rápido sin eliminarlas. En ese escenario, cambiar de modelo apenas modifica el resultado.

Una prueba sencilla consiste en ejecutar el mismo caso sin IA. Si profesionales competentes tampoco resuelven la tarea de forma consistente porque las reglas son ambiguas, el problema precede a la tecnología. Conviene rediseñar primero el flujo y después volver a evaluar la automatización. Este criterio se desarrolla en automatización con IA en empresa.

Identifica brechas concretas de criterio y capacidad, no falta de formación genérica

Una baja adopción o un exceso de errores humanos tampoco justifican automáticamente “más formación”. Hay que localizar la capacidad que falta: formular correctamente la tarea, seleccionar información relevante, verificar una salida, interpretar incertidumbre o saber cuándo escalar una excepción.

La señal aparece al comparar usuarios bajo las mismas condiciones. Si determinados perfiles consiguen resultados fiables con la misma herramienta, datos y proceso, mientras otros repiten errores previsibles, existe una brecha de capacidad específica. La respuesta debe dirigirse a esa brecha, no a una formación general sobre IA. Cuando el problema esté en evaluación y toma de decisiones, puede tener sentido una ruta como IA estratégica para líderes empresariales.

Matriz de diagnóstico: qué probar y qué corregir primero

Una vez observados los patrones de fallo, esta matriz sirve para elegir la primera hipótesis que merece una prueba, no para atribuir automáticamente una causa. La condición es mantener estables las demás variables y comprobar si el cambio modifica el resultado de forma reproducible.

Síntoma observable	Hipótesis prioritaria	Prueba para aislarla	Corrección inicial
Falla incluso con entradas controladas y una tarea bien delimitada	Modelo o herramienta	Comparar los mismos casos con otra solución	Ajustar configuración o evaluar otro modelo
Mejora de forma consistente al aportar información más fiable	Datos o contexto	Mantener el modelo y corregir fuentes o entradas	Depurar datos, contexto o documentación
La tarea sigue siendo ambigua cuando se ejecuta sin IA	Proceso	Pedir a profesionales competentes que resuelvan el mismo flujo	Rediseñar pasos, criterios y excepciones
El resultado varía de forma repetida entre usuarios	Capacidades	Comparar perfiles con iguales datos, herramienta y proceso	Desarrollar la capacidad concreta que falta

La matriz no sustituye un análisis técnico profundo ni permite confirmar una causa con una observación aislada. Corregir primero la hipótesis respaldada por un patrón reproducible reduce migraciones innecesarias, rediseños costosos y formación que no modifica el resultado.

Conclusiones

Cuando un caso de uso de IA ofrece resultados insuficientes, la prioridad no debería ser cambiar de herramienta, sino identificar qué capa explica realmente el fallo. Modelo, datos, proceso y capacidades pueden producir síntomas similares, pero requieren intervenciones distintas.

Definir qué significa funcionar, establecer una referencia y modificar una variable cada vez permite aislar mejor la causa. La intervención adecuada será la que corrija la restricción dominante: más tecnología, automatización o formación solo aportan valor cuando la evidencia demuestra que actúan sobre ella.