Loading…
ES/EN
El mito más común antes de un proyecto de IA es que se necesitan datos perfectos para empezar. La realidad es diferente: lo que se necesita es entender qué datos existen. Los datos desordenados se pueden limpiar; los datos faltantes requieren una estrategia de captura antes de que el proyecto pueda avanzar.
"Primero necesitamos ordenar nuestros datos." Es una frase que escuchamos con frecuencia cuando una empresa comienza a evaluar un proyecto de inteligencia artificial. Y es comprensible — hay una intuición razonable de que si los datos de entrada están mal, lo que produzca el sistema también estará mal.
El problema es que "ordenar los datos" sin un objetivo específico puede convertirse en un proyecto sin fin. Los datos de una empresa mediana siempre van a tener inconsistencias, campos vacíos, formatos mixtos, y duplicados. Esperar a que estén perfectos es esperar indefinidamente.
Lo que sí importa, y que pocas empresas hacen antes de empezar, es entender qué datos tienen disponibles, en qué estado están, y cuál es la diferencia entre un problema de calidad y un problema de ausencia. Esa distinción determina si el proyecto puede empezar ahora o si requiere trabajo previo. Este diagnóstico de datos es también el complemento natural del mapa de sistemas que toda empresa debería construir antes de automatizar cualquier proceso.
Los datos desordenados existen — están ahí, en algún sistema o archivo — pero tienen problemas de formato, consistencia o completitud parcial. Un campo de teléfono que en algunos registros tiene el código de país y en otros no. Nombres de clientes ingresados de formas distintas por distintas personas. Fechas en tres formatos diferentes en la misma columna.
Este tipo de problema es manejable. No es trivial, pero tiene solución técnica: limpieza de datos, normalización, reglas de validación. En la mayoría de los proyectos de IA para empresas medianas, los datos desordenados representan trabajo adicional de días o semanas, no un bloqueante fundamental.
Los datos faltantes son otra categoría. No se trata de datos que están mal — se trata de datos que nunca se capturaron porque nadie definió que importaban, o porque el proceso no tenía un punto de captura, o porque la herramienta que se usaba no lo permitía.
Un ejemplo concreto: una empresa quiere construir un agente de IA para control de inventario o para predecir qué clientes tienen mayor probabilidad de renovar su contrato. Para eso necesita historial de interacciones por cliente — llamadas, correos, incidentes reportados, satisfacción. Si ese historial nunca se registró de forma estructurada, no existe un problema de calidad de datos. Existe una ausencia de datos. Limpiar lo que existe no va a resolver eso.
La distinción importa porque las soluciones son completamente distintas. Los datos desordenados se limpian. Los datos faltantes requieren rediseñar procesos de captura y esperar a que acumulen suficiente volumen para ser útiles.
Dependiendo del tipo de proyecto, hay conjuntos de datos específicos que deben estar en un estado razonable antes de empezar.
Lo que se necesita: historial de solicitudes o tickets con fecha, categoría, canal de entrada, y resolución. No es necesario que estén perfectamente clasificados, pero sí que exista la información básica de qué se solicitó y cómo se resolvió.
Lo que bloquea el proyecto: no tener ningún historial estructurado, o tener los datos en correos que nunca se convirtieron en registros.
Lo que se necesita: plantillas existentes o ejemplos de documentos bien formados, información de clientes con campos consistentes (nombre, industria, tamaño, servicios contratados), y catálogo de servicios o productos con descripciones.
Lo que bloquea el proyecto: información de clientes fragmentada en múltiples sistemas sin campo común de identificación, o un catálogo de servicios que vive solo en la cabeza de una o dos personas.
Lo que se necesita: datos transaccionales con fechas, cantidades, y categorías consistentes. No perfectos — pero con una lógica que sea reproducible. Si el mismo tipo de transacción aparece bajo tres nombres distintos en la base de datos, el sistema necesita una tabla de equivalencias.
Lo que bloquea el proyecto: datos que solo existen en reportes PDF generados manualmente, o registros históricos que no están digitalizados.
Lo que se necesita: catálogo de productos o SKUs con identificadores únicos, registros de movimiento con fechas, y datos de proveedores o puntos de entrega.
Lo que bloquea el proyecto: un inventario que se gestiona principalmente en hojas de cálculo locales que distintas personas actualizan de forma independiente sin sincronización. La solución más directa en estos casos es reemplazar esas hojas con una base de datos centralizada — una decisión que pasa por evaluar opciones como Airtable, Supabase o PostgreSQL según el volumen y la complejidad del inventario.
Antes de decidir si los datos de un área están listos para un proyecto de IA, hay tres preguntas que orientan el diagnóstico.
¿Existe el dato, aunque esté desordenado?
Si la respuesta es sí, el problema es de calidad. Es trabajo técnico, tiene solución, y se puede estimar el esfuerzo. Si la respuesta es no, el problema es de captura. Hay que diseñar cómo se va a recopilar ese dato antes de que el proyecto de IA pueda usarlo.
¿Hay un identificador único consistente?
El identificador único es lo que permite conectar datos de distintas fuentes. El número de cliente, el código de producto, el número de pedido. Si ese identificador existe y es consistente entre sistemas, muchos problemas de calidad se vuelven solucionables. Si no existe — si el mismo cliente tiene identificadores diferentes en el CRM, en el sistema contable y en la hoja de seguimiento — hay un problema de arquitectura de datos que hay que resolver primero.
¿Quién puede explicar la lógica del dato?
Todo conjunto de datos tiene reglas implícitas que nunca se documentaron: por qué algunos registros tienen un campo y otros no, qué significa un valor en blanco versus un valor cero, qué cambió en el proceso hace dos años que explica por qué los registros anteriores tienen un formato diferente. Esa persona — generalmente alguien del equipo que lleva años trabajando con esa información — es un recurso crítico al inicio de cualquier proyecto. Si ese conocimiento vive en una sola persona y esa persona no está disponible durante el proyecto, el equipo técnico va a tomar decisiones sobre los datos sin el contexto que las hace correctas.
Una empresa de servicios profesionales con 35 empleados quiere construir un agente que automatice la generación de propuestas comerciales. Tienen cuatro años de propuestas enviadas, un CRM con información de clientes, y un catálogo de servicios.
La revisión de datos revela lo siguiente. Las propuestas anteriores existen como archivos de Word sin estructura consistente — los primeros dos años tienen un formato, los últimos dos tienen otro. Los clientes en el CRM tienen campos de industria y tamaño llenados en el 60% de los casos. El catálogo de servicios existe en una presentación de ventas, no en un documento estructurado.
¿Cuál es el diagnóstico? Las propuestas son datos desordenados — hay trabajo de estandarización, pero el dato existe. Los campos faltantes del CRM son parcialmente recuperables — el equipo de ventas puede completar los registros más importantes en una semana. El catálogo de servicios es un dato faltante en formato estructurado — hay que crear ese documento antes de que el agente pueda usarlo.
Resultado: el proyecto no se bloquea, pero empieza con dos semanas de preparación de datos en paralelo al trabajo técnico. El agente llega a producción con una base de datos limpia y completa, y eso determina la calidad del output desde el primer día.
¿Tu empresa está considerando un proyecto de IA y no tiene claridad sobre el estado de sus datos? En una sesión de diagnóstico revisamos qué tienes disponible, identificamos qué necesita limpieza versus qué está faltando, y definimos el punto de partida real del proyecto sin suposiciones.
MÁS EN ESTA CATEGORÍA
Zapier vs Make vs n8n: cuál elegir para automatizar sin código
Comparativa técnica y práctica entre Zapier, Make y n8n para automatización empresarial sin código. Precios, capacidades y cuándo conviene cada opción en LATAM.
Cómo hacer la transición de procesos manuales a automatizados
Cómo gestionar el período de transición cuando una empresa pasa de procesos manuales a automatizados. Por qué falla la adopción y cómo evitarlo. Para LATAM.
La diferencia entre un sistema a medida y una herramienta SaaS
Cuándo tiene sentido construir un sistema a medida y cuándo comprar un SaaS. Marco de decisión para empresas medianas en LATAM que evalúan su infraestructura tecnológica.