El checklist de IA que la mayoría se salta

No puedes entregar IA confiable sobre datos desordenados. Este es el checklist operacional que ejecutamos con cada cliente antes de que cualquier modelo toque producción — y el orden en que hay que resolverlo.

Ethan Gurbaxani · 2026-04-30 · 7 min

La mayoría de los "proyectos de IA" que nos piden arreglar nunca fueron realmente problemas de IA. Eran problemas de datos vestidos con empaque de modelo. El equipo entrenó un clasificador, el modelo rindió bien en el laboratorio, y en el momento en que tocó datos de producción empezó a alucinar, omitir campos o silenciosamente tomar decisiones confiadas pero equivocadas.

El patrón se repite en todas las industrias — finanzas, logística, salud, servicios profesionales. El liderazgo ve el demo, el demo funciona, y el despliegue se convierte en un ejercicio de seis meses depurando la capa de datos que nadie quiso financiar de antemano. Este checklist es el que corremos con cada cliente antes de que cualquier modelo vaya cerca del tráfico de producción. No es exhaustivo — pero saltarse cualquiera de estos puntos es la causa más común de proyectos de IA que entregan menos de lo prometido.

Cinco cosas que verificar antes de lanzar IA

• Tienes una fuente canónica y deduplicada para cada entidad que el modelo tocará.
• Tus etiquetas — o tus ejemplos de prompt — representan la distribución real de los datos de producción, no un subconjunto curado.
• Puedes rastrear cada predicción de vuelta al input que la produjo.
• Tienes un loop de revisión humana para outputs de baja confianza.
• Tienes una ruta de respaldo cuando el modelo no está disponible.

Verdad operacional: La IA no arregla flujos de datos rotos. Los amplifica. Invertir un mes en plumbing de datos ahorra seis meses de debugging de modelos.

Por qué cada una importa

Las fuentes canónicas son no negociables. Si "cliente" significa tres cosas distintas en tres sistemas diferentes, el modelo aprenderá tres definiciones distintas y producirá tres respuestas distintas para la misma consulta. La deduplicación es más difícil de lo que suena — la resolución de entidades entre sistemas es uno de los desafíos de ingeniería más subestimados en IA empresarial.

La distribución de etiquetas importa porque los modelos de ML aprenden exactamente lo que les muestras. Si tus datos de entrenamiento son curados, balanceados y limpios pero tus datos de producción son desordenados, dispersos y sesgados, el modelo fallará en producción de formas que no anticipaste. O bien igualas la distribución de producción en el entrenamiento o ponderas apropiadamente los casos raros.

La trazabilidad suena opcional hasta que algo sale mal en producción. Si no puedes responder "¿por qué el modelo tomó esta decisión para este input?", no puedes depurarlo, no puedes defenderlo ante un regulador, y no puedes mejorarlo. Cada modelo en producción debería poder producir sus inputs y su camino de razonamiento bajo demanda.

Human-in-the-loop es lo que separa los demos de IA de los sistemas de IA. Incluso los mejores modelos se equivocan un porcentaje no trivial de las veces. Si no tienes un camino de revisión para outputs de baja confianza, estás enviando errores como una característica.

Las rutas de respaldo son lo que separa las características de IA de los productos de IA. Los modelos se caen. Las APIs tienen outages. Las cuotas se agotan. Si tu proceso de negocio se detiene en el momento en que tu modelo no está disponible, no tienes un sistema de IA — tienes una dependencia crítica que resulta ser inteligente.

Cómo se ve hacerlo bien

Cuando la capa de datos está bien, los despliegues de IA se vuelven una preocupación normal de ingeniería: despliega, monitorea, itera. Cuando está mal, cada release es un simulacro de incendio. Los equipos que ganan con IA no son los que tienen los modelos más grandes. Son los que tienen los datos más limpios, los loops de retroalimentación más claros y la disciplina para entregar IA como sistema — no como demo.

Un plan de preparación de 30 días

Si estás empezando desde cero, el orden es: primero, audita tus fuentes de entidades y elige la canónica. Segundo, construye el pipeline de deduplicación y la capa de trazabilidad. Tercero, lanza el modelo detrás de un feature flag con un camino de revisión humana. Cuarto, instrumenta todo — latencia, exactitud, drift, tasa de fallback. Quinto, expande la superficie. Los equipos que siguen esta secuencia casi siempre entregan. Los que se saltan los primeros tres casi siempre se arrepienten.