Cómo preparar los datos de una empresa para usar inteligencia artificial

«Datos listos para IA» no significa nada hasta que hay un caso de uso

La conversación suele empezar igual. Alguien quiere aplicar IA a algo, alguien del equipo de datos contesta que primero hay que ordenar la casa, y el proyecto se convierte en un programa de dieciocho meses de limpieza que nunca llega a producir nada. La otra versión del mismo error es igual de común: se arranca sin mirar el dato, el piloto funciona con veinte ejemplos elegidos a mano y muere el día que se enfrenta a la operación real.

Las dos salen de la misma confusión. La preparación de datos no es un estado absoluto de la empresa; es una propiedad de la pareja «este dato, para este uso». El mismo almacén de datos puede estar perfectamente listo para un buscador interno de documentación y ser inservible para una previsión de demanda. Preguntar «¿están nuestros datos preparados para la inteligencia artificial?» es como preguntar si un coche está preparado para un viaje sin decir adónde.

Así que la primera decisión no es técnica. Es elegir el caso de uso —uno, concreto, con un dueño— y solo entonces evaluar el dato contra él. Sobre cómo se elige ese primer caso hemos escrito aparte, en qué procesos conviene automatizar primero; este artículo empieza donde aquel termina, con el caso ya elegido.

Las cinco dimensiones que deciden si un caso es viable

Cuando ya hay un caso concreto, la evaluación se vuelve manejable. Estas son las cinco preguntas que hacemos, en este orden, porque cada una puede matar el proyecto antes de que la siguiente importe:

Dimensión	La pregunta que la resuelve	Qué la hace fallar en la práctica
Cobertura	¿El dato que el caso necesita existe y llega a todos los casos que hay que decidir, o solo a una parte?	Se registra bien el 60 % de las operaciones y el resto entra por un canal que no deja rastro
Identidad	¿Se puede saber que dos registros de sistemas distintos son el mismo cliente, producto o expediente?	Cada sistema tiene su propio identificador y nadie ha acordado cuál manda
Definiciones	¿«Cliente activo», «pedido» o «incidencia resuelta» significan lo mismo en todos los sistemas implicados?	Tres departamentos calculan el mismo indicador de tres formas y las tres son defendibles
Historial	¿Hay suficiente pasado, y suficientemente comparable, para aprender o evaluar algo?	Existen cinco años de datos, pero el proceso cambió hace ocho meses
Permiso de uso	¿Se puede usar ese dato para esto, con qué base y con qué límites?	El dato se recogió para otra finalidad y nadie lo ha revisado

La última fila es la que más proyectos frena tarde, y siempre por el mismo motivo: se mira al final. Preguntar por la finalidad y el consentimiento en la semana uno cuesta una reunión; preguntarlo cuando el modelo ya funciona cuesta el proyecto. Y no es una comprobación que se delegue al equipo técnico: es una decisión con implicaciones legales y de negocio que alguien tiene que tomar por escrito.

Un matiz sobre el historial que se subestima siempre. Lo que importa no es la antigüedad del archivo, sino cuánto de ese pasado sigue describiendo el proceso de hoy. Un cambio de política comercial, una migración de sistema o un rediseño del formulario parten el histórico en dos, y la mitad vieja puede ser peor que no tener nada, porque enseña un mundo que ya no existe.

Los tres destinos de cada problema de dato

Con las cinco dimensiones evaluadas aparece una lista de defectos. La tentación es ordenarla por gravedad y atacarla de arriba abajo. Es mejor ordenarla por cuándo hay que resolver cada cosa, que es una pregunta distinta y bastante más útil:

Dónde va cada problema de dato

• Antes de empezar — bloqueanteSin esto el caso no es viable, se haga como se haga: el dato no existe, las identidades no se pueden resolver, o no hay permiso para usarlo. Se arregla o se cambia de caso.
• Dentro del proyecto — parte del alcanceDefectos reales que se corrigen con reglas, no con voluntad: formatos inconsistentes, campos vacíos, duplicados acotados, definiciones que hay que acordar. Se presupuestan como trabajo, no como imprevisto.
• Después, o nunca — deuda conscienteLo que molesta pero no afecta a este caso. Se documenta y se deja pasar a propósito. La decisión de no arreglarlo ahora es tan legítima como la de arreglarlo, si está escrita.
• Gobierno continuoLas reglas que impiden que lo arreglado se vuelva a romper. Sin esta pata, el saneamiento caduca en un año.

El valor del reparto está en la tercera fila. Un equipo que no se permite dejar problemas sin resolver termina limpiando datos que nadie iba a usar.

La tercera categoría es la que hace viable el proyecto y la que más incomoda a los equipos de datos, con razón: aceptar deuda a propósito es distinto de ignorarla. La diferencia está en que quede escrita, con su motivo y con la condición que la reabriría.

Preparar no es limpiar

«Limpiar los datos» suena a una tarea de formato: quitar espacios, unificar mayúsculas, rellenar huecos. Esa parte existe y es la más barata. El trabajo que de verdad decide el resultado es otro, y es sobre todo trabajo de acuerdo, no de código.

• Resolver identidades. Que el mismo cliente en el CRM, en facturación y en soporte sea un solo cliente, con una regla explícita de qué registro gana cuando hay conflicto. Es un problema con suficiente sustancia propia como para tratarlo aparte, en deduplicación y resolución de identidades.
• Acordar definiciones. No «unificar» —eso suele significar que gana el departamento que más insiste— sino acordar: qué cuenta como cliente activo, desde cuándo, con qué exclusiones, y aplicarlo igual en todas partes. Cuando las definiciones difieren por un motivo legítimo, lo honesto es mantener las dos con nombres distintos.
• Documentar el origen. De dónde sale cada campo, quién lo introduce, con qué frecuencia se actualiza y qué significa que esté vacío. Un campo vacío que significa «no aplica» y otro que significa «nadie lo rellenó» son datos completamente distintos con la misma apariencia.
• Fijar el acceso. Quién puede leer qué, con qué permisos y para qué finalidad. Se resuelve antes, porque después se convierte en el cuello de botella de todas las semanas.

De estas cuatro, la única que se puede automatizar de verdad es la primera, y solo en parte. Las otras tres son conversaciones con gente que sabe cómo funciona el negocio. Es la parte del trabajo que ninguna herramienta ahorra y la que, cuando falta, hace que la herramienta más cara del mercado devuelva números que nadie se cree.

El fallo silencioso: el dato que existe pero no significa

Hay un patrón que se repite lo suficiente como para avisar. El equipo comprueba que el campo existe, que está relleno en un porcentaje alto y que tiene el formato correcto. Todo verde. Y el modelo, o el agente, o el informe, sale mal igual.

Lo que casi siempre ha pasado es que el campo se rellena por obligación y no por criterio. Un desplegable con quince opciones donde el equipo elige siempre la primera para poder guardar la ficha está técnicamente completo y semánticamente vacío. Un campo de «motivo de la baja» que el 80 % de las veces dice «otros» tiene una cobertura excelente y una utilidad nula.

La comprobación que lo detecta no es técnica, es de campo: sentarse una hora con quien introduce el dato y ver cómo lo hace. Media jornada de observación ahorra semanas de análisis sobre un campo que nunca iba a servir. Cuando el resultado de esa hora es que el dato no significa lo que dice, hay tres salidas honestas — cambiar el caso de uso, cambiar el proceso de captura, o aceptar el caso con un alcance menor. Ninguna de ellas es seguir adelante como si nada.

Cómo saber que ya se puede empezar

No hace falta un informe de cien páginas. Con estas respuestas cerradas por escrito, el caso se puede arrancar:

• Hay un caso de uso concreto, con un responsable de negocio y una decisión que hoy se toma peor de lo que se podría.
• Se sabe qué datos exactos necesita ese caso — no «los datos de cliente», sino los campos.
• La cobertura de esos campos está medida sobre los datos reales, no estimada.
• Existe una regla de identidad que permite juntar las fuentes implicadas.
• Las definiciones que el caso usa están acordadas y escritas.
• El uso previsto tiene una base legítima revisada, con sus límites documentados.
• Hay una línea base: cómo de bien se hace esto hoy, medido.
• Los defectos conocidos están repartidos entre bloqueantes, alcance y deuda aceptada.

La séptima casilla es la que más se salta y la que más cara sale. Sin línea base no hay forma de demostrar que el proyecto mejoró algo, y eso convierte cualquier conversación posterior sobre resultados en una discusión de opiniones. Es el mismo problema que hace imposible calcular el retorno de un proyecto de IA cuando nadie midió el punto de partida.

El orden que funciona

Si tuviéramos que reducirlo a una regla: elige el caso, mide el dato contra ese caso, arregla solo lo que ese caso necesita, y deja el resto documentado. Después repite con el siguiente caso, que se apoyará en parte del trabajo ya hecho y avanzará más rápido.

Es deliberadamente lo contrario del programa de gobierno del dato que se aprueba en enero y se revisa en diciembre. No porque el gobierno del dato no importe —importa, y sin él lo arreglado se degrada— sino porque un programa que no entrega nada durante un año pierde el apoyo antes de llegar a la parte útil. El gobierno se construye alrededor de casos que ya están dando resultado; es mucho más fácil defenderlo así.

Y una advertencia que vale por todo lo anterior: la IA no arregla los datos, los consume. Un agente que lee registros duplicados duplica el error con más velocidad y mejor redacción. Si al terminar la evaluación la conclusión es que el cimiento no está, esa es la conclusión — y el primer proyecto es el cimiento, no el caso de uso. Es exactamente el punto donde implantar IA en una empresa se convierte, sin dramatismo, en un proyecto de datos.

Siguiente paso

Si quieres el diagnóstico completo sobre tus sistemas —cobertura real, identidades, definiciones acordadas y el reparto entre bloqueante, alcance y deuda— eso es lo que hacemos en Datos e inteligencia. Cuéntanos tu reto y revisamos el caso antes de proponer nada.