Datos listos para IA
La brecha entre tener datos y que la IA los use de verdad.
Todo piloto de IA que se estanca tiene la misma autopsia: los datos no estaban listos. Medimos la brecha —calidad, estructura, acceso— y construimos lo que la cierra, en el orden que desbloquea tu primer caso de uso.
Qué construimos
- Diagnóstico de qué tan listos están tus datos frente a tus casos de uso reales de IA
- Pipelines de limpieza y estructuración para los datos que importan primero
- Preparación para recuperación: chunking, indexado y evaluación donde se gana su lugar
- Acceso moldeado alrededor de tus permisos y controles
Cuándo nos buscan los equipos
- Un piloto de IA estancado por la calidad de los datos
- Un proveedor dijo “basta con conectar tus datos” y nunca fue tan simple
- El Discovery Sprint encontró que el primer paso real eran los datos: este es ese paso
Cómo lo construimos
Diagnosticar contra el caso de uso
estar listo es relativo a lo que se quiere construir
Arreglar en orden de valor
primero el subconjunto que desbloquea el primer valor
Preparar acceso y recuperación
permisos, estructura, indexado
Verificar con la IA misma
evaluación sobre consultas reales, no sobre supuestos
Las cuatro preguntas
Estar listo no es una propiedad de una base de datos. Es la respuesta a cuatro preguntas, hechas sobre un caso de uso a la vez:
Acceso
¿El sistema que va a usar los datos puede realmente alcanzarlos, con los permisos que esos datos ya tienen? "Está en el warehouse" y "el modelo puede leerlo" son estados distintos, y la brecha suele ser un mes de trabajo que nadie presupuestó.
Calidad
¿Son verdaderos? Duplicados, registros viejos, campos que significan cosas distintas en sistemas distintos. Un modelo entrenado con eso se va a equivocar con total seguridad exactamente en lo que los datos se equivocan.
Estructura
¿Tienen la forma que el caso de uso necesita? La recuperación quiere chunks y un índice; un predictor quiere una tabla con una etiqueta; un agente quiere registros sobre los que pueda actuar. Los mismos datos están listos para uno y no para el otro.
Un camino
¿Hay un camino desde donde nacen los datos hasta donde los lee el modelo que corra sin una persona? Un pipeline que alguien vuelve a correr a mano es una demo, no estar listo.
La mayoría de los pilotos estancados falla en una de las cuatro. Casi ninguno falla en las cuatro, y por eso el arreglo suele ser más chico que el miedo.
Qué resultó significar “listo”
El error que más vemos es tratar el estar listo como un proyecto que termina antes de que la IA empiece: limpiar todo, estructurar todo y después arrancar. Nunca termina, y el piloto espera un año por una base de la que necesitaba un décimo. Estar listo es relativo a un caso de uso. Un asistente que responde preguntas sobre tu documentación necesita esos documentos indexados y al día, y nada más. Un modelo que predice la fuga de clientes necesita una tabla, unida, etiquetada y actualizada, y nada más.
Así que el trabajo corre en orden de valor: el subconjunto de datos que desbloquea el primer caso de uso, hecho confiable primero, con la IA misma como prueba. Si el asistente responde bien preguntas reales con los datos tal como quedaron preparados, los datos estaban listos. Si no, la evaluación dice cuál de las cuatro preguntas sigue abierta, y eso es el trabajo de la semana que viene, no una reescritura del plan.
Funciona bien con
Preguntas frecuentes
¿Cuánto tarda estar listo?
Depende de lo que el caso de uso necesite: estar listo para un asistente no es estar listo para todo. Por eso dimensionamos hasta el primer valor.
¿Nuestros datos están demasiado desordenados para la IA?
El desorden es el estado por defecto de las empresas reales. La pregunta es qué subconjunto importa primero.
¿Necesitamos que todo esté listo antes de empezar?
No. Estar listo y el piloto avanzan juntos.
¿Qué entregan realmente?
Para el caso de uso en alcance: un diagnóstico que nombra cuáles de las cuatro preguntas están abiertas y cuánto cuesta cerrar cada una; los pipelines y las estructuras que cierran las que están en el camino crítico; y un conjunto de evaluación de consultas reales con respuestas conocidas, para que "listo" sea una medición y no una opinión.
Tenemos un data warehouse. ¿No alcanza con eso?
Es un buen comienzo, y a menudo no es el problema. Los warehouses están construidos para reportar: agregados, actualizados de noche, con la forma de un dashboard. La recuperación necesita documentos indexados al momento de la consulta; los agentes necesitan registros sobre los que puedan actuar. El warehouse nos dice que los datos existen; estar listo es sobre la forma que necesitan para lo que se quiere construir.
¿Nuestros datos tienen que salir de nuestro entorno?
No. El trabajo pasa donde los datos ya viven: tu cloud, tus permisos, tu registro de auditoría. Los pipelines que construimos corren ahí, y lo que nos llevamos es el diagnóstico y el conjunto de evaluación, no los datos.
Que sepas exactamente en qué estado están tus datos.
El sprint incluye factibilidad técnica y requisitos de datos.