Preparación de Datos: El Prerrequisito que la Mayoría de los Proyectos de AI Omiten

Priya dirige una empresa de servicios B2B de 120 personas. Los ingresos son sólidos. Su equipo lleva cuatro años creciendo de forma constante.

Hace seis meses aprobó un piloto de 60.000 dólares: una herramienta de lead scoring predictivo integrada con el CRM que su equipo de ventas usaba desde 2021. El proveedor tenía confianza. La demo era impresionante.

A los tres meses, los scores parecían aleatorios. Los representantes dejaron de confiar en ellos. Nadie podía explicar por qué dos de sus cuentas con mejor perfil aparecían con baja prioridad mientras una docena de contactos fríos figuraban como "hot." El equipo de soporte del proveedor revisó la configuración y envió un documento de dos páginas sobre requisitos de completitud de datos que ella nunca había visto antes de firmar el contrato.

La AI no estaba rota. Los datos sí lo estaban.

Gartner indica que hasta 2026, las organizaciones abandonarán el 60% de sus proyectos de AI por falta de datos preparados para la AI. No por la calidad del modelo. No por las habilidades del equipo. No porque la tecnología no sea lo suficientemente madura. Los datos no estaban listos.

Este es el prerrequisito poco glamoroso que la mayoría de los equipos omiten porque resulta aburrido. Y es determinante.

Este artículo es para Priya, y para cada fundador, responsable de operaciones o jefe de área que quiera saber si sus datos están listos antes de gastar otro dólar en herramientas de AI.

Qué significa realmente la preparación de datos

"Preparación de datos" no significa datos perfectos. Significa datos suficientemente buenos para la capacidad de AI específica que usted quiere utilizar.

Con más precisión: datos que son localizables, accesibles, estructurados, actualizados y autorizados para su uso con AI.

• Localizables: usted sabe dónde viven los datos y puede acceder a ellos sin que ello represente un proyecto de varias semanas
• Accesibles: la herramienta de AI puede leerlos a través de API, exportación o conector nativo
• Estructurados: tienen suficiente esquema y consistencia para que un modelo pueda aprender patrones
• Actualizados: reflejan la realidad actual, no lo que era cierto hace dos años
• Autorizados: el área legal, de seguridad y cumplimiento los ha habilitado para su uso con AI

La mayoría de los equipos descubren que son débiles en una o dos de estas dimensiones. Eso suele bastar para hundir un piloto.

Los cinco modos de fallo

Conocer qué hace que los datos no estén preparados es más útil que saber qué los hace correctos. Estos son los cinco modos de fallo que matan los proyectos de AI antes de que el modelo tenga una oportunidad.

Modo de fallo 1: datos en silos

Su CRM tiene el historial de negocios, pero no puede ver los tickets de soporte. Su plataforma de marketing conoce cada recurso que descargó un prospecto, pero sus herramientas de ventas no pueden verlo. Su sistema financiero tiene tres años de historial de pagos, pero su plataforma de Customer Success no sabe qué cuentas llevan 60 días de retraso.

Este es el modo de fallo más común en empresas del mercado medio, y es invisible hasta que intenta construir algo que depende de datos conectados. Una capacidad Ingest puede extraer de un único sistema. Pero en el momento en que su AI necesita ver el cuadro completo del cliente (historial de compras más interacción de soporte más engagement por email más señales de renovación), necesita que esos sistemas se comuniquen entre sí.

Generalmente no lo hacen. No sin un trabajo de integración real que ocurre antes de comprar la herramienta de AI, no después.

Modo de fallo 2: campos no estructurados sin esquema

Su CRM tiene un campo "Notas." También lo tienen su plataforma de soporte, su herramienta de gestión de proyectos y su hoja de seguimiento. Cada representante lo usa de forma diferente. Algunos escriben párrafos. Algunos no escriben nada. Algunos escriben "llamó, dejó mensaje de voz" y otros escriben "14/2: hablé con J. Chen, interesado pero necesita aprobación del CFO, presupuesto ~$40K, timing Q2."

Los campos de texto libre sin esquema son casi inútiles para una AI que necesita aprender patrones. La capacidad Analyze puede extraer señal de texto no estructurado, pero solo si hay suficiente cantidad y es lo bastante consistente para que un modelo distinga señal de ruido. Los equipos suelen descubrir este problema solo después de integrar la herramienta. Los resultados del modelo se sienten equivocados, pero el modelo está haciendo lo mejor que puede con entradas inconsistentes.

Modo de fallo 3: contexto faltante en los registros

Un registro existe en su base de datos, pero le faltan los campos que le dan significado.

Su CRM tiene 8.000 registros de empresas, pero el 40% no tiene etiqueta de sector. Su historial de negocios se remonta a cuatro años, pero el motivo de ganancia/pérdida solo se volvió obligatorio hace 18 meses.

Para una capacidad Predict que construye un modelo de lead scoring, esos campos faltantes no son una inconveniencia menor. Son la señal de entrenamiento. Si no tiene resultados vinculados a entradas, no puede entrenar un modelo de predicción significativo. El contexto es el tejido conectivo. Los registros sin él son puntos de datos sin significado.

Modo de fallo 4: problemas de calidad

Duplicados. Errores tipográficos. Entradas obsoletas. Un campo "nombre de empresa" con siete ortografías del mismo cliente enterprise. Etapas de negocio que nunca cambiaron porque un representante olvidó actualizarlas.

Los problemas de calidad confunden a los modelos de maneras difíciles de diagnosticar. Una capacidad Generate alimentada con material de referencia inconsistente produce borradores inconsistentes. Un modelo de lead scoring entrenado con registros duplicados sobre-pondera ciertas características porque aparecen varias veces. Una herramienta de detección de anomalías que aprende de datos de referencia obsoletos marca comportamientos normales como anómalos. Los resultados se sienten equivocados, pero el problema no es el modelo. Son las entradas.

Modo de fallo 5: datos con acceso restringido

Sus datos existen. Son suficientemente limpios. Son accesibles para los humanos. Pero su equipo legal o de seguridad tiene una política que impide introducirlos en herramientas de AI.

"Nada de PII en ChatGPT" es una política razonable. Pero si los datos que su AI necesita contienen nombres de clientes, direcciones de correo electrónico o datos de comportamiento vinculados a personas, esa política puede bloquear todo el caso de uso. Una capacidad Execute que envía emails automáticamente necesita información de contacto. Una herramienta de clasificación de soporte necesita leer el contenido del ticket. Una herramienta de revisión de documentos necesita el documento.

Antes de pilotar cualquier cosa, verifique si los datos que alimentaría a la herramienta están autorizados. No solo técnicamente accesibles, sino legalmente autorizados y con política documentada. Esa conversación debe ocurrir antes del piloto, no después.

La auditoría de cinco preguntas

No necesita un equipo de ciencia de datos para realizar esta auditoría. Necesita 30 minutos con alguien que conozca sus sistemas.

Pregunta 1: ¿Puedo descargar los datos que mi AI necesitaría, hoy, sin contactar a IT? Si no es así, tiene una dependencia de acceso que resolver antes de que cualquier herramienta de AI pueda ser útil.

Pregunta 2: ¿Cada registro tiene los campos que la AI necesita, o están al 40% en blanco? Tome 100 registros al azar. Si más del 20-30% de los campos clave están vacíos o claramente incorrectos, tiene un problema de completitud.

Pregunta 3: ¿Los datos son lo suficientemente recientes como para reflejar la realidad actual? El lead scoring necesita los últimos 12-18 meses de datos de negocios. Si sus datos limpios tienen dos años y su proceso de ventas cambió hace 18 meses, el modelo aprende el proceso antiguo.

Pregunta 4: ¿Hay una fuente autorizada única, o cuatro versiones en conflicto? "El CRM es la fuente de verdad, pero ventas mantiene una hoja de cálculo y finanzas tiene números distintos en el ERP" es un problema de coherencia. La AI no puede reconciliar fuentes en conflicto. Alguien tiene que decidir qué sistema prevalece.

Pregunta 5: ¿El área legal o de seguridad tiene una política para introducir estos datos en herramientas de AI? Pregúntelo explícitamente. En muchas empresas del mercado medio, la política de datos para AI todavía no se ha redactado. Créela antes de proceder, no después.

Si puede responder las cinco con claridad, sus datos están suficientemente listos para empezar. Si dos o más le generan dudas, ahí es donde debe ir su inversión previa a la AI.

La pirámide de preparación de datos

Piense en la preparación de datos como una pirámide con cinco niveles. La mayoría de los equipos necesitan subir desde la base antes de que los niveles superiores aporten valor.

La mayoría de los equipos del mercado medio que inician un proyecto de AI están en el Nivel 1 o a mitad del Nivel 2. Eso está bien. Se puede iniciar trabajo de AI en el Nivel 1 o 2. Pero debe saber en qué nivel está, porque las capacidades que puede desplegar dependen de ello.

Un equipo en el Nivel 1 puede ejecutar flujos de trabajo de Analyze a partir de texto o registros estructurados relativamente limpios, y experimentar con Ingest para llevar documentos y audio a un formato utilizable. Aún no puede ejecutar flujos de trabajo serios de Predict, porque estos requieren el Nivel 3 (datos históricos etiquetados).

Un equipo en el Nivel 3 que no ha completado el Nivel 4 está a una auditoría de proveedor de distancia de tener que detener sus flujos de trabajo de AI. La gobernanza no es un lujo. Es lo que le permite escalar sin reconstruir cuando las políticas alcancen la realidad.

El Nivel 5 es lo que distingue a los equipos que mantienen valor en la AI a lo largo del tiempo de los equipos cuyos pilotos se degradan en silencio. La observabilidad significa tener monitorización en marcha para detectar caídas en la calidad de los datos: campos que se vuelven nulos, registros duplicados que se acumulan, datos que pierden vigencia. Sin ella, un modelo que funcionó hace seis meses puede estar produciendo resultados deficientes ahora, y usted no lo sabrá hasta que un representante llame a una cuenta inactiva.

Preparación mínima viable por capacidad ACE

No todas las capacidades necesitan la misma base de datos. Aquí está el mínimo para cada una de las cinco:

Esta tabla es práctica para la secuenciación. Si tiene datos de CRM limpios pero sin etiquetas históricas, empiece con Analyze y Generate, no con Predict. Construya el hábito de etiquetado mientras ejecuta las capacidades de menor riesgo. Cuando tenga 12-18 meses de resultados etiquetados, Predict estará a su alcance.

Qué hacer cuando sus datos no están preparados

La mayoría de los equipos están en esta situación. Esto es lo que realmente funciona.

Empiece con el único sistema que sí está listo. La mayoría de las empresas tienen una fuente de datos más limpia que las demás. Su sistema de tickets de soporte puede ser más desordenado que su CRM, pero si el CRM tiene tres años de historial de negocios limpio con resultados, empiece su trabajo de AI ahí. Elija el caso de uso que se ajuste a sus mejores datos, no el caso de uso que más desearía poder hacer.

Ejecute primero Ingest y Analyze. Estas son capacidades de solo lectura que producen insights sin cambiar el estado externo. Ejecutarlas antes de Predict o Execute le permite generar valor con menores requisitos de datos mientras mejora la calidad para las capacidades de mayor riesgo.

Construya hábitos de etiquetado antes de necesitar un modelo. Si quiere lead scoring en 12 meses, empiece hoy a exigir los campos de motivo de ganancia/pérdida en su CRM. Hágalos obligatorios. Cuando esté listo para entrenar, las etiquetas ya estarán ahí.

Considere AI de proveedores que traiga su propia línea base. Productos como Salesforce Einstein, el lead scoring predictivo de HubSpot o Gong vienen con modelos preentrenados que aportan alguna señal antes de que usted añada sus propios datos, lo que reduce la penalización del arranque en frío para equipos más pequeños.

La preparación de datos como ventaja competitiva

Esta es la parte que no resulta obvia cuando está en medio de un piloto frustrante.

Los equipos que hacen el trabajo de integración poco glamoroso (limpiar su CRM, insistir en campos obligatorios, conectar sus sistemas, documentar sus políticas de datos) están construyendo una ventaja competitiva que las mejoras de modelo no pueden borrar.

La calidad del modelo es una commodity. OpenAI, Anthropic y Google compiten para ofrecerle mejores modelos. En 18 meses, los modelos a los que puede acceder vía API serán mucho más capaces que los actuales. Pero un modelo mejor alimentado con datos sucios y en silos seguirá produciendo resultados deficientes.

Las empresas que ganen la carrera de la AI en los próximos tres años no serán necesariamente las que adoptaron el modelo más reciente con mayor rapidez. Serán las que construyeron la base de datos que hace que los modelos funcionen. Datos limpios más un modelo básico supera a datos desordenados más el último modelo, casi siempre.

El trabajo aburrido que hace que los proyectos de AI tengan éxito

Estas son las tareas poco glamorosas que determinan si su piloto de AI realmente aporta valor:

• Deduplique sus contactos y cuentas del CRM antes de conectar cualquier herramienta de AI
• Haga del motivo de ganancia/pérdida un campo obligatorio en sus registros de negocios (y rellene retroactivamente 12 meses si puede)
• Audite sus campos de texto libre más importantes: ¿los están completando los representantes? ¿Son consistentes?
• Mapee sus flujos de datos: qué entra y qué sale en cada sistema clave
• Pida a su equipo legal o de seguridad que redacte su política de uso de datos para AI antes de firmar un contrato con un proveedor
• Identifique su fuente de verdad autorizada para cada tipo de datos clave: registros de clientes, historial de negocios, tickets de soporte
• Construya un hábito de monitorización: ¿quién revisa la calidad de los datos mensualmente y qué busca?

Ninguna de estas tareas es técnicamente compleja. Todas requieren una voluntad organizacional sostenida para llevarse a cabo de verdad. Esa es la razón real por la que la mayoría de los equipos omiten este trabajo. Es aburrido, lento y no parece "AI." Pero es el trabajo más importante que realizará en su programa de AI.

Qué leer a continuación

El ACE Framework se construye a partir de la base de datos tratada aquí:

• Los 7 tipos de datos que consumen sus flujos de trabajo de AI
• Su AI no es tonta: cómo diagnosticar problemas de calidad de datos en despliegues activos
• El ACE Framework: la pila completa de seis capas, con los datos como fundamento
• Ingest: la primera capacidad, y la más directamente vinculada al acceso a datos
• Por qué fracasan la mayoría de los marcos de AI: lo que la mayoría de los marcos no tienen en cuenta sobre el problema de datos

Lo aburrido supera a lo brillante. Haga bien los datos, y la AI le sorprenderá. Omítalos, y pasará seis meses preguntándose por qué el modelo está "roto" cuando el modelo está funcionando exactamente como debería.