Tener muchos datos no significa estar preparado para usar inteligencia artificial.
La calidad de datos para IA no depende solo de cuánta información tenga una empresa. Puedes acumular años de ventas, pedidos, tickets, documentos o registros de clientes y descubrir que parte de esos datos está incompleta, desactualizada o no representa correctamente el problema que quieres resolver.
La pregunta útil no es “¿nuestros datos están limpios?”, sino:
¿Los datos que tenemos son suficientemente adecuados y confiables para este caso concreto de IA?
En esta guía aprenderás a evaluar esa pregunta antes de invertir tiempo en un piloto. Revisaremos qué datos necesita el caso, cómo detectar problemas de relevancia, completitud, exactitud, consistencia, actualidad y representatividad, y cómo decidir si conviene avanzar, corregir primero o todavía no realizar la prueba.
¿Qué significa tener datos de calidad para IA?
La calidad de datos para IA indica qué tan adecuada y confiable es la información para el propósito en el que se utilizará.
Esto cambia la forma de hacer la evaluación.
No basta con comprobar que una hoja de cálculo no tenga celdas vacías o que una base no tenga registros duplicados. También debemos analizar si la información realmente permite a la IA consultar, clasificar, predecir, recomendar o responder lo que esperamos.
La norma ISO/IEC 5259-1:2024, desarrollada específicamente para calidad de datos en analítica y aprendizaje automático, plantea precisamente que los datos deben evaluarse de acuerdo con su propósito previsto y a lo largo de su ciclo de vida.
En términos simples: unos datos pueden estar ordenados y aun así no servir para el proyecto de IA que quieres desarrollar.
Datos limpios no significa datos útiles para IA
Imagina una tienda que quiere utilizar IA para estimar la demanda semanal de sus productos.
Tiene tres años de ventas ordenadas. Las fechas están completas, los productos tienen códigos consistentes, no existen registros duplicados relevantes y los importes están correctamente guardados.
A primera vista, la base parece tener buena calidad.
Pero durante la revisión aparece otro problema: la empresa nunca registró cuándo hizo promociones ni cuándo un producto estuvo agotado.
Si las ventas bajaron porque no había inventario, el sistema podría interpretar esa caída como menor demanda. Si aumentaron por una promoción, tampoco tendrá esa información para explicar el cambio.
Los datos pueden estar limpios y aun así no ser suficientemente adecuados para el problema que queremos resolver.
La calidad depende del caso de uso
Preguntar si una empresa tiene “datos de buena calidad” es demasiado amplio.
La misma información puede ser suficiente para una tarea e insuficiente para otra.
Por ejemplo, un restaurante puede tener un historial de reservas útil para analizar ocupación por día de la semana.
Pero si quiere predecir cancelaciones y nunca registró qué reservas terminaron en no show, esos mismos datos probablemente no sean suficientes para ese segundo objetivo.
La calidad de datos para IA debe evaluarse en relación con la tarea que la empresa quiere resolver, no de manera abstracta sobre toda la base de datos.
Antes de revisar los datos, define qué debe hacer la IA
Uno de los errores más comunes es comenzar limpiando información sin haber definido primero para qué se utilizará.
Eso puede generar horas de trabajo sobre campos que finalmente no tienen ninguna influencia en el proyecto.
Antes de revisar completitud, exactitud o consistencia, escribe en una frase el resultado esperado.
Define el resultado que esperas
Evita objetivos amplios como:
Queremos usar IA en servicio al cliente.
Es más útil definir una tarea concreta:
Queremos clasificar automáticamente las solicitudes de clientes según el tipo de problema.
Otros ejemplos pueden ser:
- estimar ventas semanales por producto;
- responder preguntas internas utilizando manuales y procedimientos;
- clasificar correos entre ventas, soporte y facturación;
- detectar pedidos con riesgo de retraso;
- resumir comentarios de clientes;
- sugerir una categoría para cada ticket recibido.
Si todavía no tienes claro qué tarea vale la pena intervenir, conviene revisar primero qué procesos automatizar con IA y cuáles mantener bajo control humano. La calidad de los datos solo puede evaluarse correctamente cuando sabemos para qué se van a utilizar.
Identifica qué información utilizará
Después pregunta:
¿Qué información necesitaría la IA para realizar esa tarea?
No todos los proyectos utilizan bases de datos tradicionales. La información puede estar en:
- hojas de cálculo;
- CRM;
- ERP;
- sistemas de ventas;
- tickets;
- correos;
- documentos PDF;
- manuales;
- catálogos;
- conversaciones;
- imágenes;
- registros de inventario.
Por ejemplo, un asistente interno que responde preguntas sobre políticas comerciales puede depender principalmente de documentos.
En ese caso, la calidad no consiste en buscar celdas vacías. Hay que comprobar si los documentos están vigentes, si existen versiones contradictorias y cuál debe considerarse la fuente correcta.
6 criterios para evaluar la calidad de datos para IA
No necesitas crear un sistema complejo de gobierno de datos para hacer una primera evaluación de un caso empresarial.
Estos seis criterios permiten identificar problemas importantes antes de iniciar un piloto:
| Criterio | Pregunta principal |
|---|---|
| Adecuación y relevancia | ¿Tenemos la información que realmente necesita este caso? |
| Completitud y cobertura | ¿Faltan datos, periodos o situaciones importantes? |
| Exactitud y validez | ¿Los datos representan correctamente la realidad? |
| Consistencia | ¿La información coincide entre registros y fuentes? |
| Actualidad | ¿Los datos siguen siendo vigentes? |
| Representatividad | ¿Reflejan las situaciones que la IA encontrará en la práctica? |
1. Adecuación y relevancia
Empieza por la pregunta más importante:
¿Estos datos contienen realmente la información necesaria para resolver el problema?
No importa que una empresa tenga miles o millones de registros si esos registros no contienen las variables, documentos o ejemplos relacionados con la tarea.
Supongamos que un ecommerce quiere identificar clientes con riesgo de abandonar.
Tiene nombres, teléfonos, direcciones y facturas completas, pero nunca registró frecuencia de compra, devoluciones, reclamos o interacciones recientes.
La base contiene mucha información comercial, pero quizá no la información necesaria para analizar señales de abandono.
Por eso, antes de limpiar más datos, pregunta qué necesita saber el sistema para realizar la tarea.
2. Completitud y cobertura
Después revisa qué información falta.
Pero completitud no significa que todos los campos deban estar llenos al 100 %.
Hay que distinguir entre un dato ausente que no afecta al proyecto y uno que puede cambiar el resultado.
Si quieres clasificar tickets de servicio al cliente, un teléfono vacío puede no importar.
En cambio, si gran parte de los tickets no contiene la descripción del problema, esa ausencia sí puede impedir que el sistema realice correctamente la tarea.
También debes revisar cobertura. Algunas preguntas útiles son:
- ¿faltan meses completos?
- ¿faltan determinadas sucursales?
- ¿faltan ciertos productos o categorías?
- ¿hay periodos en los que dejaron de registrarse datos?
- ¿están cubiertas las situaciones poco frecuentes pero importantes?
La pregunta no es solo “¿cuántos datos faltan?”, sino “¿qué información falta y qué consecuencia puede tener?”.
3. Exactitud y validez
La exactitud analiza si los datos representan correctamente lo que ocurrió. La validez revisa si cumplen las reglas esperadas.
Algunos ejemplos son:
- una fecha de entrega anterior a la fecha del pedido;
- un precio negativo;
- un producto asignado a la categoría equivocada;
- un ticket marcado como “facturación” cuando corresponde a “soporte”;
- una dirección de correo con un formato inválido.
En proyectos que utilizan ejemplos previamente clasificados, las etiquetas requieren especial atención.
Si quieres utilizar tickets históricos clasificados como “reclamo”, “consulta” o “venta”, pero esas categorías fueron aplicadas de forma inconsistente, la IA puede aprender de ejemplos incorrectos.
4. Consistencia
Los datos también deben ser suficientemente coherentes entre registros, documentos y sistemas.
Imagina un asistente de IA que consulta un catálogo comercial, una lista de precios y un manual de ventas.
Si un documento indica que una devolución puede hacerse en 15 días y otro dice 30 días, el problema no es que falten datos.
El problema es que dos fuentes se contradicen.
Otros ejemplos de inconsistencia son:
- “Bogotá”, “Bogota” y “BOG” tratados como categorías diferentes;
- un producto con nombres distintos entre el ecommerce y el ERP;
- estados de pedido definidos de manera diferente entre sucursales;
- políticas comerciales con versiones incompatibles.
Cuando varias fuentes alimentan un sistema, define cuál debe considerarse la referencia principal cuando aparezcan diferencias.
5. Actualidad
Un dato puede haber sido correcto y dejar de serlo.
Esto es especialmente importante cuando la IA utiliza información que cambia con frecuencia, como:
- precios;
- inventario;
- políticas;
- promociones;
- horarios;
- catálogos;
- condiciones comerciales;
- procedimientos internos.
Por ejemplo, un asistente puede responder correctamente según un manual antiguo y aun así entregar una respuesta equivocada si la política comercial ya cambió.
Pregunta:
¿Qué tan reciente debe ser esta información para que siga siendo útil en este caso?
La respuesta depende del propósito. Un histórico de ventas puede conservar valor durante años. El inventario disponible puede requerir información casi inmediata.
6. Representatividad
Este criterio suele pasar desapercibido y es especialmente importante en proyectos de IA.
Pregunta:
¿Los datos reflejan las situaciones que el sistema encontrará cuando se utilice?
Supongamos que un restaurante quiere estimar la demanda.
Tiene seis meses de información correctamente registrada, pero ese periodo no incluye temporada alta, vacaciones ni eventos especiales.
Los registros pueden estar completos y ser exactos, pero no representar todas las condiciones en las que se utilizará la predicción.
Algo parecido ocurre si una empresa quiere clasificar reclamos y casi todos sus datos históricos pertenecen a una sola sucursal, aunque el sistema vaya a utilizarse en cinco.
La representatividad también aparece en marcos regulatorios y técnicos de IA. Por ejemplo, la Comisión Europea establece requisitos de relevancia y representatividad de datos para determinados sistemas de IA de alto riesgo.
Para una PYME, la aplicación práctica es sencilla: revisa si los datos cubren razonablemente las situaciones que el sistema deberá enfrentar.
Otros controles que pueden ser necesarios
Los seis criterios anteriores sirven como base, pero algunos casos requieren controles adicionales.
- Duplicados: importan cuando pueden distorsionar frecuencias, resultados o ejemplos.
- Procedencia y trazabilidad: conviene saber de dónde proviene la información y cuál versión es válida.
- Etiquetado: es importante cuando se utilizan ejemplos históricos clasificados para entrenar o evaluar.
- Sesgos: deben revisarse cuando determinados grupos, regiones, productos o situaciones tienen una representación muy desigual.
- Privacidad y permisos: disponer de un dato no significa automáticamente que deba cargarse en cualquier herramienta de IA.
No todos los proyectos necesitan el mismo nivel de revisión. La profundidad del control debe aumentar cuando también aumenta el impacto de una respuesta equivocada.
Cómo evaluar la calidad de los datos antes de un piloto de IA
Ahora podemos convertir los criterios anteriores en un método práctico.
El objetivo no es conseguir una puntuación perfecta.
Es responder:
¿Podemos hacer una prueba razonable con estos datos?
Paso 1. Evalúa un caso concreto
No intentes auditar todos los datos de la empresa.
Empieza por una iniciativa.
Por ejemplo:
Clasificar automáticamente las solicitudes de clientes.
Esto mantiene la evaluación manejable y permite relacionar cada problema con una consecuencia concreta.
Paso 2. Identifica las fuentes de datos
Anota de dónde provendrá la información que utilizará el caso.
| Fuente | Uso esperado |
|---|---|
| Sistema de tickets | Texto de las solicitudes |
| Categorías históricas | Ejemplos para clasificar |
| Base de clientes | Contexto adicional si es necesario |
| Manual de soporte | Reglas para determinados casos |
No agregues fuentes solo porque existen. Cada una debe tener una razón clara para participar en el proyecto.
Paso 3. Revisa los seis criterios
Para cada fuente, responde:
- ¿Es relevante para la tarea?
- ¿Falta información importante?
- ¿Los datos representan correctamente lo ocurrido?
- ¿Existen contradicciones?
- ¿La información sigue siendo vigente?
- ¿Representa las situaciones que esperamos encontrar?
Cuando aparezca un problema, describe también cómo podría afectar el resultado.
Eso es más útil que marcar simplemente “bien” o “mal”.
Paso 4. Prioriza los problemas que pueden afectar el resultado
No todos los errores necesitan solucionarse antes del piloto.
Puedes clasificarlos en tres niveles:
| Nivel | Qué significa |
|---|---|
| Crítico | Puede invalidar el piloto o generar resultados poco confiables. |
| Importante | Debe corregirse o controlarse, pero no necesariamente obliga a cancelar la prueba. |
| Menor | No afecta de forma relevante el objetivo actual. |
Por ejemplo, si vas a clasificar tickets y una parte importante de las categorías históricas está mal asignada, el problema puede ser crítico.
Si falta el teléfono de algunos clientes y la clasificación no utiliza ese dato, probablemente sea un problema menor para ese caso.
Esta priorización evita gastar recursos corrigiendo todo por igual.
Paso 5. Decide si puedes avanzar
La evaluación debería terminar en una decisión comprensible para el negocio.
| Decisión | Qué significa |
|---|---|
| Apto para piloto | Los datos tienen limitaciones, pero son suficientemente adecuados para una prueba controlada. |
| Corregir antes de probar | Existen problemas concretos que pueden afectar significativamente el resultado y deben resolverse primero. |
| No apto todavía | Faltan datos esenciales o las fallas actuales impiden evaluar el caso con suficiente confianza. |
No existe un porcentaje universal que permita afirmar que una base con “85 % de calidad” está automáticamente lista para IA.
La ISO/IEC 5259-2:2024 establece un modelo y medidas para evaluar características de calidad de datos en analítica y aprendizaje automático, pero la evaluación sigue dependiendo de los requisitos del caso y de su propósito.
Por eso, la decisión debe considerar qué dato falla, cuánto puede afectar el resultado y qué consecuencia tendría una respuesta equivocada.
Ejemplo: evaluar datos para clasificar solicitudes con IA
Veamos cómo aplicar el método en una empresa de servicios.
La empresa recibe aproximadamente 800 solicitudes mensuales y quiere utilizar IA para clasificarlas automáticamente en cuatro grupos:
- ventas;
- soporte;
- facturación;
- cancelaciones.
Cuenta con 8.000 tickets históricos.
Antes de elegir una herramienta o construir una automatización, revisa la información.
| Criterio | Hallazgo | Evaluación |
|---|---|---|
| Adecuación | Los tickets contienen el texto que describe el problema. | Favorable |
| Completitud | 18 % de los tickets no tiene categoría histórica. | Revisar |
| Exactitud | Una muestra encuentra categorías mal asignadas. | Problema importante |
| Consistencia | “Cobranza” y “facturación” se usan para situaciones similares. | Revisar |
| Actualidad | Los últimos 12 meses reflejan el proceso actual. | Favorable |
| Representatividad | Existen nuevos tipos de solicitudes con pocos ejemplos históricos. | Revisar |
¿Qué debería hacer la empresa?
No necesita abandonar el proyecto, pero tampoco conviene probar el sistema directamente con toda la información existente.
Una acción razonable sería:
- acordar una lista definitiva de categorías;
- revisar una muestra de tickets históricos;
- corregir las etiquetas más problemáticas;
- incorporar ejemplos de los nuevos tipos de solicitudes;
- probar el sistema con casos separados de los utilizados para prepararlo.
Decisión: corregir antes del piloto.
Esta conclusión es más útil para un gerente que decir simplemente que la base tiene “82 % de calidad”.
Además, detectar el problema ahora evita descubrirlo después de configurar herramientas, integraciones y flujos de trabajo.
La investigación sobre data cascades en proyectos de IA ha mostrado cómo problemas originados en los datos pueden propagarse hacia etapas posteriores y generar retrabajo y fallas difíciles de corregir.
Checklist: ¿tus datos están listos para probar IA?
Utiliza estas preguntas para hacer una primera revisión de un caso concreto.
- ¿Está claramente definido lo que queremos que haga la IA?
- ¿Sabemos qué datos necesita para esa tarea?
- ¿Los datos disponibles son relevantes para ese objetivo?
- ¿Tenemos cobertura de las situaciones importantes?
- ¿Falta información que pueda cambiar el resultado?
- ¿Hay errores o etiquetas incorrectas que puedan confundir al sistema?
- ¿Los datos son consistentes entre fuentes?
- ¿La información sigue siendo suficientemente actual?
- ¿Los datos representan las situaciones que encontrará la IA en operación?
- ¿Sabemos de dónde provienen las fuentes más importantes?
- ¿Tenemos identificados los problemas que deben corregirse?
- ¿Podemos explicar por qué el caso está listo —o no— para un piloto?
Consejo: no respondas esta checklist pensando en “todos los datos de la empresa”. Utilízala para un solo caso de IA y repite la revisión cuando evalúes una iniciativa diferente.
Si varias respuestas generan dudas, registra cuáles son los problemas y qué debes corregir antes de iniciar la prueba. Ese diagnóstico es más útil que intentar obtener una puntuación general de calidad.
Errores comunes al preparar datos para IA
La calidad de los datos no mejora simplemente agregando más registros o ejecutando una limpieza automática.
Estos son algunos errores que conviene evitar.
Pensar que más datos siempre es mejor
Un conjunto grande de datos puede seguir teniendo poca utilidad si no contiene la información necesaria o no representa adecuadamente el problema.
El trabajo DataPerf, presentado en NeurIPS, refuerza precisamente la importancia de evaluar y mejorar los datos como parte central del desarrollo de sistemas de aprendizaje automático.
Para una empresa, la traducción práctica es sencilla:
primero pregunta si los datos sirven para el problema; después pregunta cuántos tienes.
Limpiar datos sin definir para qué se usarán
Puedes invertir días corrigiendo teléfonos, direcciones o nombres que no tienen ninguna relación con el proyecto.
Empieza por la tarea, identifica qué información necesita y solo entonces decide qué problemas vale la pena corregir.
Revisar duplicados pero ignorar representatividad
Los duplicados son fáciles de identificar y por eso reciben mucha atención.
Pero una base sin duplicados todavía puede representar mal el contexto real.
Por ejemplo, una empresa puede tener 20.000 pedidos perfectamente registrados, pero que 95 % corresponda a una sola ciudad.
Si quiere utilizar esos datos para tomar decisiones en cinco mercados diferentes, el problema principal puede no ser la limpieza, sino la cobertura.
Trabajar con información que ya no refleja el negocio
Los procesos cambian. También cambian productos, clientes, precios, categorías, políticas, canales y comportamientos.
Un historial antiguo puede seguir siendo útil, pero no debemos asumir que representa automáticamente la operación actual.
Antes de usarlo pregunta:
¿qué cambió entre el periodo en que se generaron estos datos y el momento en que utilizaremos la IA?
Revisar la calidad una sola vez
La revisión inicial no cierra el tema.
Los datos pueden degradarse con el tiempo. Pueden aparecer nuevas categorías, cambiar una fuente, quedar documentos obsoletos o dejar de actualizarse un archivo.
El AI Risk Management Framework de NIST plantea la gestión de riesgos y la evaluación de sistemas de IA a lo largo de su ciclo de vida, no como una actividad que termina al lanzar el proyecto.
Por eso, si el piloto avanza, define también qué datos pueden perder vigencia y quién será responsable de detectar cambios.
Qué hacer si los datos todavía no están listos
Encontrar problemas antes del piloto es útil.
Permite corregirlos antes de invertir más tiempo en configuración, integraciones y operación.
La acción depende de lo que hayas encontrado.
Si faltan algunos datos
Identifica si pueden recuperarse, corregirse o completarse.
Por ejemplo:
- incorporar meses faltantes;
- recuperar categorías;
- consolidar documentos;
- normalizar nombres;
- eliminar versiones obsoletas;
- corregir etiquetas importantes.
No necesitas corregir todo el sistema de información de la empresa. Prioriza lo que afecta directamente al caso.
Si faltan datos esenciales
A veces el problema no puede resolverse limpiando la información disponible.
La empresa simplemente nunca registró el dato necesario.
Por ejemplo, quieres predecir cancelaciones, pero históricamente nunca registraste qué clientes cancelaron.
No existe una limpieza que pueda crear ese histórico de manera confiable.
La mejor decisión puede ser comenzar a capturar correctamente la información durante un periodo y retomar el proyecto cuando exista una base suficiente para probarlo.
Si los datos permiten una prueba controlada
No esperes perfección.
Si los principales riesgos están identificados y los datos son suficientemente adecuados para la tarea, puedes avanzar con un piloto limitado.
En ese momento cambia la pregunta.
Ya no es:
¿Tenemos datos suficientemente adecuados?
Ahora pasa a ser:
¿Cómo hacemos la prueba, qué medimos, qué reglas aplicamos y quién controla el resultado?
Ese es el punto natural para continuar con la guía sobre cómo implementar IA en una PYME, donde puedes organizar responsables, reglas, métricas y condiciones del piloto.
Preguntas frecuentes sobre calidad de datos para IA
¿Cuántos datos se necesitan para un proyecto de IA?
No existe una cantidad universal.
Depende del tipo de tarea, la variabilidad del problema, la tecnología utilizada, el nivel de riesgo y la calidad de los datos.
Un asistente que consulta 30 procedimientos internos tiene una necesidad diferente a un sistema de predicción basado en miles de transacciones.
Antes de buscar más información, comprueba si los datos actuales son relevantes, correctos y suficientemente representativos.
¿Los datos deben estar perfectos antes de empezar?
No.
La meta no es conseguir una base perfecta, sino datos suficientemente adecuados para el propósito y el riesgo de la prueba.
Un error en un campo que la IA no utiliza puede tener poca importancia. Un error frecuente en la información central para la tarea puede ser crítico.
Por eso conviene priorizar los problemas según su impacto y no solamente según su cantidad.
¿Cada cuánto se debe revisar la calidad de los datos?
Depende de cuánto cambien las fuentes y el negocio.
Precios o inventarios pueden requerir revisiones muy frecuentes. Un manual de procedimientos quizá solo necesite actualizarse cuando cambia una política.
Lo importante es identificar qué información puede perder vigencia, cómo se detectará el cambio y quién será responsable de mantenerla actualizada.
De datos adecuados a un piloto de IA
La calidad de datos para IA no consiste en limpiar toda la información de la empresa ni en alcanzar un porcentaje arbitrario.
Consiste en responder una pregunta más concreta:
¿Los datos disponibles son suficientemente adecuados, confiables y representativos para el caso que queremos probar?
Primero define la tarea. Después identifica las fuentes. Revisa adecuación, completitud, exactitud, consistencia, actualidad y representatividad.
Y termina con una decisión empresarial clara:
- avanzar con un piloto;
- corregir antes de probar;
- esperar hasta disponer de mejores datos.
Si todavía estás decidiendo qué caso merece prioridad, revisa qué procesos automatizar con IA y cuáles evitar.
Si la revisión muestra que los datos permiten hacer una prueba razonable, continúa con cómo implementar IA en un negocio para definir el piloto, los responsables, los controles y los indicadores.
Así, la calidad de los datos deja de ser una revisión técnica aislada y se convierte en algo más útil para la empresa: un criterio para decidir mejor antes de invertir tiempo y dinero en IA.
Fuentes y referencias
Para desarrollar esta guía se consultaron estándares, marcos técnicos y publicaciones especializadas en calidad de datos e inteligencia artificial:
- ISO/IEC 5259-1:2024. Artificial intelligence — Data quality for analytics and machine learning — Part 1: Overview, terminology, and examples.
- ISO/IEC 5259-2:2024. Artificial intelligence — Data quality for analytics and machine learning — Part 2: Data quality measures.
- NIST AI Risk Management Framework. Marco para gestionar riesgos y confiabilidad durante el ciclo de vida de sistemas de inteligencia artificial.
- NIST Generative Artificial Intelligence Profile. Perfil complementario del AI RMF para inteligencia artificial generativa.
- Comisión Europea — AI Act. Orientaciones sobre requisitos aplicables a sistemas de inteligencia artificial, incluidos criterios relacionados con relevancia y representatividad de datos en determinados casos.
- Data Cascades in High-Stakes AI. Investigación sobre cómo los problemas de datos pueden propagarse hacia etapas posteriores de proyectos de inteligencia artificial.
- DataPerf — NeurIPS 2023. Trabajo orientado a la evaluación y mejora de datos como parte del desarrollo de sistemas de aprendizaje automático.
Discover more from
Subscribe to get the latest posts sent to your email.
