Cómo evaluar si tu sistema de IA funciona de verdad

Introducción

Muchas pymes han implantado algún sistema de inteligencia artificial sin tener claro si está aportando valor o solo generando actividad distinta. En la práctica, la mayoría de proyectos no se miden más allá de indicadores de uso, satisfacción o impresiones subjetivas del equipo técnico.

Los marcos de gestión de riesgos de IA, como el de NIST, insisten en que los sistemas deben medirse antes y durante su operación, con métricas alineadas con el contexto de uso y la decisión que soportan (National Institute of Standards and Technology, 2023). Cuando una empresa no puede distinguir un sistema útil de uno que solo ocupa tiempo y recursos, corre tres riesgos: mantener soluciones que no mejoran nada, dejar pasar oportunidades reales de mejora y tomar decisiones estratégicas basadas en expectativas no contrastadas.

Este artículo propone una forma concreta de medir un sistema de IA ya en marcha, organizada en tres niveles: calidad de la respuesta, impacto operativo e impacto de negocio. El objetivo es que un gerente de pyme pueda pedir y revisar números que respondan a la pregunta clave: «¿está funcionando de verdad o solo está ocupando sitio?».

Estado de la cuestión

Medir modelos no basta para medir impacto

La mayoría de la literatura técnica sobre evaluación de IA se centra en métricas del modelo como precisión, recall, F1 o rendimiento en benchmarks estándar. NIST distingue entre medidas de rendimiento (lo bien que funciona la tecnología en condiciones de prueba) y medidas de efectividad (hasta qué punto esa tecnología ayuda a la aplicación final), subrayando que ambas son necesarias pero responden a preguntas diferentes (National Institute of Standards and Technology, 2022).

Los marcos de evaluación recomiendan documentar conjuntos de prueba, métricas y procedimientos, y probar los sistemas en condiciones similares a las de despliegue, incluyendo la interacción con personas cuando exista «human in the loop» (National Institute of Standards and Technology, 2023). Esto implica que un modelo con buena precisión en un benchmark puede tener un impacto limitado (o incluso negativo) en una empresa si se integra en un flujo de trabajo mal definido o se aplica a un problema que no era el adecuado.

Evidencia sobre impacto en productividad y empleo

La evidencia empírica sobre el impacto de la IA en empresas, especialmente en Europa, empieza a acumular resultados medidos. Un trabajo reciente con más de 12.000 firmas europeas encuentra que la adopción de IA se asocia con un aumento de la productividad laboral del 4 % de media, sin efectos adversos claros sobre el empleo en el corto plazo, y con beneficios concentrados en empresas medianas y grandes (Aldasoro et al., 2026).

Revisiones de la OCDE sobre productividad señalan efectos firmes pero heterogéneos: estimaciones firmes sitúan los aumentos de productividad a nivel de empresa entre 0 % y 11 %, mientras que experimentos con tareas concretas reportan mejoras en rendimiento individuales de entre 10 % y 56 % según el tipo de trabajo y la experiencia del usuario (Filippucci, 2024; Organización para la Cooperación y el Desarrollo Económicos, 2025b). Estas cifras son datos medidos en estudios concretos; las proyecciones macroeconómicas sobre crecimiento de la productividad agregada se basan en modelos que extrapolan esos resultados y deben interpretarse como estimaciones, no como valores observados (Filippucci, 2024).

Pymes europeas: adopción desigual y métricas poco maduras

Las pymes representan más del 99 % de las empresas y en torno al 60 % del empleo del sector empresarial en las economías de la OCDE, pero su adopción de tecnologías de IA sigue rezagada respecto a las grandes empresas (Organización para la Cooperación y el Desarrollo Económicos, 2023a). Los trabajos recientes sobre pymes señalan que la evidencia disponible sobre beneficios y riesgos se basa sobre todo en encuestas de percepción y estudios de casos, con menos mediciones sistemáticas de impacto operativo y de negocio que en grandes corporaciones (Organización para la Cooperación y el Desarrollo Económicos, 2025a).

Las encuestas de la OCDE muestran que alrededor del 80 % de los trabajadores que usan IA perciben mejoras en su rendimiento, pero este es un dato de percepción y autoevaluación, no una medición objetiva de productividad (Organización para la Cooperación y el Desarrollo Económicos, 2023b). La literatura coincide en que el impacto real depende de cómo se integra la IA en los procesos, del nivel de formación de los empleados y de las inversiones complementarias en software, datos y capacitación (Aldasoro et al., 2026; Organización para la Cooperación y el Desarrollo Económicos, 2025a).

Evaluar el sistema vs evaluar la decisión de implantarlo

Es importante distinguir dos niveles de evaluación que a menudo se mezclan:

• Evaluar el sistema: comprobar si el asistente, automatización o modelo está haciendo bien la tarea que se le ha asignado, con la calidad y el comportamiento esperados.
• Evaluar la decisión de implantarlo: analizar si introducir ese sistema, en ese proceso concreto, era una buena decisión en términos de coste, riesgo y alternativas.

Los marcos de gestión de riesgos de IA sugieren que la evaluación del sistema se apoye en métricas de rendimiento y confianza (validez, fiabilidad, seguridad, equidad), mientras que la evaluación de la decisión de despliegue debe considerar el contexto de negocio, el riesgo aceptable y la comparación con la situación sin IA (National Institute of Standards and Technology, 2023). Una pyme puede tener un sistema técnicamente correcto pero mal colocado en el proceso, de modo que la decisión de implantarlo sea dudosa aunque el sistema «funcione» desde el punto de vista técnico.

Qué medir en tres niveles

Nivel 1: calidad de la respuesta

La calidad de la respuesta de un sistema de IA se puede descomponer en cuatro elementos prácticos:

1. Acierto: hasta qué punto la salida del sistema coincide con la respuesta correcta o con el criterio que la empresa considera válido.
2. Respaldo en la fuente: si lo que afirma el sistema está realmente sustentado por los datos, documentos o reglas que se han definido como base.
3. Reconocimiento de incertidumbre: con qué frecuencia el sistema reconoce que no sabe o que necesita intervención humana en lugar de inventar una respuesta.
4. Comportamiento bajo revisión: cómo se comporta cuando se revisa con muestreo humano.

Los marcos técnicos proponen combinar métricas cuantitativas (tasas de acierto, falsos positivos, falsos negativos) con evaluación cualitativa de casos representativos y revisión desagregada por tipos de entrada (National Institute of Standards and Technology, 2022). En una pyme, no es realista montar un equipo permanente de evaluadores, pero sí es viable establecer un muestreo periódico: por ejemplo, revisar cada semana un 2–5 % de los casos tratados por el sistema, seleccionando una mezcla de casos sencillos y casos límite.

Un procedimiento mínimo podría ser:

• Definir qué se considera «correcto» para cada tipo de salida (por ejemplo, «respuesta útil para el cliente», «clasificación adecuada», «documento bien redactado»).
• Crear una hoja de revisión simple donde una persona marque «correcto», «parcialmente correcto» o «incorrecto», y señale si habría preferido no recibir respuesta del sistema.
• Calcular, sobre ese muestreo, tasas agregadas de acierto, errores graves y casos en que el sistema debería haber reconocido incertidumbre y no lo hizo.

Este tipo de muestreo se alinea con las recomendaciones de NIST de combinar pruebas automatizadas con evaluación humana en contextos de uso real, evitando depender exclusivamente de benchmarks predefinidos que no reflejan los datos de la empresa (National Institute of Standards and Technology, 2023).

Nivel 2: impacto operativo

El segundo nivel responde a la pregunta «¿qué ha cambiado en nuestra operación desde que pusimos la IA?». Aquí interesa medir, como mínimo:

• Tiempo de trabajo por caso: cuánto tiempo dedica una persona a cada caso con IA frente al tiempo sin IA.
• Tiempo total por caso: desde que el caso entra hasta que se cierra, incluidas las esperas. Si solo baja el tiempo de trabajo, el proceso puede seguir tardando lo mismo, porque el tiempo estaba en las colas y los traspasos (lo explicamos aquí).
• Volumen absorbido: cuántos casos puede manejar el sistema al día o a la semana.
• Errores que llegan al cliente: cuántos fallos detectables se materializan en errores visibles para clientes o proveedores.
• Derivación a personas: proporción de casos que acaban siendo tratados por una persona, aun habiendo pasado por el sistema.

La evidencia disponible sugiere que los beneficios operativos de la IA aparecen sobre todo cuando se rediseñan procesos y se combinan automatización con supervisión humana, mientras que los proyectos que se limitan a «enchufar un modelo» en un flujo existente tienden a generar fricciones y trabajo adicional de corrección (Organización para la Cooperación y el Desarrollo Económicos, 2025a; Aldasoro et al., 2026). Por eso, las métricas operativas deben medirse comparando contra una línea base clara, que represente cómo se hacía el trabajo antes de la IA (aunque sea a partir de muestras históricas de unos pocos meses).

Un esquema operativo mínimo sería:

• Medir durante varias semanas el tiempo medio por caso y el número de casos resueltos, separando los que se resolvieron íntegramente por el sistema de los que pasaron por una persona.
• Registrar de forma simple los errores que llegan al cliente, por ejemplo con un campo en el sistema de incidencias que señale si el origen fue el sistema de IA.
• Calcular la proporción de casos que el sistema deriva a una persona, distinguiendo entre derivación correcta (casos en los que efectivamente hacía falta criterio humano) y derivación por incapacidad del sistema.

Los marcos de evaluación insisten en que los sistemas deben monitorizar su comportamiento en producción y comparar métricas operativas reales con las obtenidas en pruebas, para detectar desviaciones y «drift» en datos y modelos (National Institute of Standards and Technology, 2023). En una pyme, esto se puede traducir en revisar mensualmente estos indicadores y documentar cambios de configuración o nuevas versiones del sistema junto con sus efectos en tiempos y errores.

Nivel 3: impacto de negocio

El tercer nivel aborda directamente la cuestión de si el sistema aporta valor económico y estratégico. Aquí las métricas dejan de ser puramente técnicas u operativas y pasan a ser de negocio:

• Coste por unidad atendida: coste total (incluyendo licencias, infraestructuras y tiempo humano asociado) dividido por el número de casos tratados.
• Conversión: en procesos comerciales, proporción de oportunidades en las que el sistema contribuye a cerrar una venta o lograr el objetivo deseado.
• Capacidad de absorber picos: capacidad adicional de la empresa para gestionar aumentos temporales de demanda sin deteriorar la calidad.
• Dependencia de personas concretas: grado en que el funcionamiento del sistema depende de un pequeño número de personas clave para corrección, mantenimiento o interpretación.

Los estudios sobre adopción de IA en empresas señalan que las mejoras de productividad y calidad tienden a concentrarse en organizaciones que acompañan la tecnología con cambios organizativos, inversión en formación y gobernanza clara; en otras, la IA añade complejidad sin una mejora proporcional de resultados (Organización para la Cooperación y el Desarrollo Económicos, 2025a; Aldasoro et al., 2026). Para que las cifras de negocio signifiquen algo, es imprescindible disponer de una línea base previa: datos aunque sean aproximados de costes, conversiones y capacidad antes de introducir el sistema.

En términos prácticos, una pyme puede:

• Estimar el coste completo del sistema, incluyendo tiempo de implantación, horas de supervisión y corrección, y costes recurrentes, y dividirlo por los casos atendidos.
• Comparar tasas de conversión en periodos similares con y sin IA, controlando, en la medida de lo posible, por factores externos (campañas, estacionalidad).
• Documentar episodios de pico de demanda (por ejemplo campañas o cierres de trimestre) y valorar si el sistema permitió absorberlos con menos estrés organizativo o más velocidad.

La dependencia de personas concretas es menos tratada en la literatura técnica, pero se menciona en marcos de riesgo como una dimensión de resiliencia organizativa, relacionada con la capacidad de mantener el sistema en funcionamiento cuando cambian equipos o proveedores (National Institute of Standards and Technology, 2023). Un sistema que solo «funciona» mientras está disponible un técnico específico o una consultora concreta genera una dependencia que debe considerarse parte del análisis de impacto de negocio.

Línea base, casos de prueba y regresión

Sin una línea base previa (datos históricos de cómo funcionaba el proceso sin IA) las cifras posteriores son difíciles de interpretar. La literatura sobre evaluación insiste en la necesidad de establecer medidas de referencia, incluso simples, antes de desplegar sistemas complejos, para poder comparar rendimiento y riesgos de forma razonable (National Institute of Standards and Technology, 2023; National Institute of Standards and Technology, 2022).

Para proyectos ya en marcha, donde la línea base no se recogió a tiempo, es posible reconstruirla parcialmente a partir de datos históricos disponibles (por ejemplo tiempos de ticket, registros de incidencias, informes comerciales), siendo transparentes sobre las limitaciones de esa reconstrucción. La clave es reconocer qué parte de la comparación está basada en datos medidos y cuál en estimaciones ajustadas a partir de esos datos, y no presentar estimaciones como si fueran medidas directas.

Además de la línea base, conviene definir un conjunto estable de casos de prueba representativos del trabajo real: tipos de consulta, documentos, solicitudes o expedientes que el sistema debe manejar. Los marcos de evaluación de NIST recomiendan usar estos conjuntos de casos en pruebas de regresión: volver a evaluarlos cuando se cambia modelo, configuración o datos, para detectar si una mejora en una métrica no se traduce en un empeoramiento en otra dimensión relevante (National Institute of Standards and Technology, 2023).

En una pyme, un conjunto de 50–100 casos bien elegidos, revisados periódicamente, puede ser suficiente para detectar regresiones importantes sin necesidad de infraestructuras de evaluación complejas. Lo importante es mantener ese conjunto estable a lo largo del tiempo, añadir casos solo cuando representen nuevos tipos de trabajo, y documentar cuándo se modifica el sistema y qué cambios se observan en esos casos.

Discusión: errores frecuentes al medir

Los errores más habituales al medir proyectos de IA en empresas son conceptualmente sencillos, pero muy frecuentes.

Medir solo satisfacción o uso

Muchas organizaciones se centran en métricas de satisfacción (encuestas internas o a usuarios) o de uso (número de peticiones, tiempo de conexión, usuarios activos). Las encuestas de la OCDE muestran que la mayoría de usuarios perciben mejoras de rendimiento con la IA, pero esto no garantiza que haya mejoras reales en productividad o calidad del servicio (Organización para la Cooperación y el Desarrollo Económicos, 2023b). Un caso reciente lo ilustra bien: en la prueba de Microsoft 365 Copilot del Departamento de Negocios y Comercio del Gobierno británico, con mil licencias durante tres meses, el 72 % de los participantes se declaró satisfecho o muy satisfecho, pero la evaluación no encontró pruebas sólidas de que el tiempo ahorrado se tradujera en más productividad, aunque advierte que medirlo no era su objetivo principal (Department for Business and Trade, 2025).

Las métricas de uso son importantes para saber si un sistema está integrado en los hábitos de trabajo, pero no responden a la pregunta de si compensa mantenerlo. Un sistema muy usado puede ser un productor sistemático de errores o retrabajo; si no se mide la calidad de la salida y el impacto operativo, la satisfacción y el uso pueden enmascarar problemas serios.

No haber tomado línea base antes de empezar

Otro error es arrancar un proyecto sin recoger datos previos de cómo funcionaba el proceso original. Los marcos de riesgo señalan que sin baseline es difícil priorizar riesgos y decidir si un sistema merece seguir evolucionando o debe detenerse (National Institute of Standards and Technology, 2023).

En pymes, esto suele deberse a la presión por «hacer algo con IA» y a la idea de que medir es complejo. La consecuencia es que, cuando se quiere evaluar el sistema, solo se dispone de datos con IA y se cae en comparaciones implícitas con percepciones («antes esto se hacía mal») en lugar de datos objetivos.

Confundir actividad con valor

La literatura sobre adopción de tecnologías advierte que la presencia de inversiones, proyectos y actividad en torno a IA no implica necesariamente mejora de productividad o competitividad (Organización para la Cooperación y el Desarrollo Económicos, 2025b). Es fácil confundir el volumen de automatizaciones, integraciones y dashboards con creación de valor, y calibrar la percepción de éxito del proyecto por lo ocupados que están los equipos implicados.

Separar los tres niveles de medición ayuda a evitar esta confusión: un sistema puede generar mucha actividad de revisión de respuestas (nivel 1) y mucha carga de coordinación (nivel 2), sin mejorar costes ni capacidad de absorber picos (nivel 3). La disciplina de revisar números de negocio, aunque sean sencillos, obliga a distinguir valor real de actividad interna.

Cuando una métrica se convierte en objetivo

Un riesgo conocido en gestión (a menudo resumido como «cuando una medida se convierte en objetivo, deja de ser buena medida») se aplica con fuerza a sistemas de IA. Si el sistema se optimiza exclusivamente para maximizar una métrica concreta (por ejemplo precisión en un conjunto de prueba limitado, tiempo de respuesta o satisfacción de usuarios internos), tiende a explorar estrategias que mejoran esa métrica a costa de otras dimensiones no medidas.

Los marcos de evaluación recomiendan usar conjuntos de métricas y analizar trade‑offs entre características de confiabilidad, seguridad, equidad, transparencia y rendimiento, en lugar de optimizar solo una (National Institute of Standards and Technology, 2023). Para una pyme, esto significa seleccionar un pequeño grupo de indicadores equilibrados (por ejemplo acierto, tiempo por caso, errores al cliente y coste por unidad) y resistir la tentación de declarar éxito basándose en un único número.

Conclusiones: mínimo de medición y cuándo parar

El mínimo que debería montar una pyme desde el primer día

A la luz de la evidencia disponible y de los marcos de referencia, el mínimo razonable de medición para un proyecto de IA en una pyme incluye:

• Una línea base, aunque sea aproximada, de cómo funcionaba el proceso sin IA: tiempos, volúmenes, errores visibles y costes básicos.
• Un conjunto reducido de casos de prueba representativos del trabajo real, documentados y reutilizables para pruebas de regresión.
• Un esquema de muestreo humano para revisar la calidad de la respuesta del sistema, con decisiones claras sobre qué se considera acierto, error grave y caso en que el sistema debería haber reconocido incertidumbre.
• Un pequeño cuadro de indicadores operativos (tiempo por caso, volumen absorbido, errores al cliente, derivación a personas) y de negocio (coste por unidad, conversión, capacidad de absorber picos, dependencia de personas) revisado periódicamente.

Estas prácticas se alinean con las recomendaciones de organismos de referencia para medir riesgos y desempeño de sistemas de IA y son compatibles con la realidad de recursos de una pyme europea (National Institute of Standards and Technology, 2023; Organización para la Cooperación y el Desarrollo Económicos, 2025a).

Cuándo conviene concluir que algo no funciona y pararlo

No todos los sistemas que «funcionan» técnicamente merecen seguir en marcha. Conviene plantearse seriamente detener un proyecto cuando, tras un periodo razonable (por ejemplo de seis a doce meses) se observa que:

• La calidad de respuesta no mejora hasta niveles aceptables, y el sistema genera errores graves o inventa información pese a ajustes y formación de usuarios.
• El impacto operativo es neutro o negativo: tiempos por caso similares o superiores, aumento de retrabajo, más errores que llegan al cliente o mayor dependencia de personas concretas para corregir salidas.
• El impacto de negocio es nulo: costes por unidad iguales o superiores, sin mejora en conversión ni en capacidad de absorber picos, y sin reducción de otros riesgos relevantes.

La literatura sobre productividad sugiere que los beneficios de la IA se materializan cuando se reconfiguran procesos y se acompaña la tecnología de inversiones complementarias; mantener sistemas que no muestran mejora tras sucesivos intentos puede desviar recursos de oportunidades más prometedoras (Aldasoro et al., 2026; Filippucci, 2024). En estos casos, parar es una decisión racional: permite liberar tiempo, reducir complejidad y replantear el problema desde la perspectiva de negocio, no desde la tecnología disponible.

Referencias

Aldasoro, I., Gambacorta, L., Pal, R., Revoltella, D., Weiss, C., & Wolski, M. (2026). AI adoption, productivity and employment: Evidence from European firms (BIS Working Paper No. 1325). Bank for International Settlements. https://www.bis.org/publ/work1325.pdf

Department for Business and Trade. (2025). The evaluation of the M365 Copilot pilot in the Department for Business and Trade. GOV.UK. https://assets.publishing.service.gov.uk/media/68adbe409e1cebdd2c96a19d/dbt-microsoft-365-copilot-evaluation.pdf

Filippucci, F. (2024). The impact of artificial intelligence on productivity, distribution and growth: Key mechanisms, initial evidence and policy challenges. Organisation for Economic Co-operation and Development. https://www.oecd.org/en/publications/the-impact-of-artificial-intelligence-on-productivity-distribution-and-growth_8d900037-en.html

National Institute of Standards and Technology. (2022). Artificial Intelligence Measurement and Evaluation Workshop summary. National Institute of Standards and Technology. https://www.nist.gov/system/files/documents/2022/08/25/AIME%20Workshop%20Summary%202.2.pdf

National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1

Organización para la Cooperación y el Desarrollo Económicos. (2023a). Generative AI and the SME workforce. Organización para la Cooperación y el Desarrollo Económicos. https://www.oecd.org/en/publications/generative-ai-and-the-sme-workforce_2d08b99d-en.html

Organización para la Cooperación y el Desarrollo Económicos. (2023b). The impact of AI on the workplace: Main findings from the OECD AI surveys of employers and workers. Organización para la Cooperación y el Desarrollo Económicos. https://www.oecd.org/en/publications/the-impact-of-ai-on-the-workplace-main-findings-from-the-oecd-ai-surveys-of-employers-and-workers_ea0a0fe1-en.html

Organización para la Cooperación y el Desarrollo Económicos. (2025a). The adoption of artificial intelligence in firms: New evidence for policymaking. Organización para la Cooperación y el Desarrollo Económicos. https://www.oecd.org/en/publications/the-adoption-of-artificial-intelligence-in-firms_f9ef33c3-en.html

Organización para la Cooperación y el Desarrollo Económicos. (2025b). The effects of generative AI on productivity, innovation and entrepreneurship. Organización para la Cooperación y el Desarrollo Económicos. https://www.oecd.org/en/publications/the-effects-of-generative-ai-on-productivity-innovation-and-entrepreneurship_b21df222-en.html