Cuando un modelo de Inteligencia Artificial produce una respuesta incorrecta, nuestra primera reacción suele ser cuestionar el modelo.

¿Falló el algoritmo? ¿El modelo alucinó? ¿Necesitamos cambiar el proveedor? ¿Debemos ajustar el prompt?

Pero existe una posibilidad mucho menos sofisticada y bastante más frecuente: el problema estaba en los datos.

Datos incompletos, duplicados, desactualizados, mal clasificados o provenientes de sistemas que utilizan definiciones diferentes pueden producir decisiones equivocadas incluso cuando el algoritmo funciona exactamente como fue diseñado.

La calidad de datos está dejando de ser solamente un asunto de Tecnología o Data Governance.

Cada vez más debe analizarse como una fuente directa de riesgo operacional.

El problema empieza antes de la Inteligencia Artificial

Pensemos en una institución financiera.

Un cliente aparece con información diferente en tres sistemas. Su actividad económica está desactualizada. Un campo obligatorio fue completado manualmente utilizando una categoría incorrecta. Una base contiene información de hace tres meses y otra se actualiza diariamente. Un modelo utiliza ambas fuentes para realizar una evaluación. El resultado puede ser técnicamente correcto respecto de la información recibida. Y, al mismo tiempo, estar completamente equivocado respecto de la realidad.

Esto cambia la discusión. No estamos frente a un error del algoritmo. Estamos frente a una decisión incorrecta originada por datos deficientes.

La IA está haciendo visible un problema que ya existía

La mala calidad de datos no apareció con la Inteligencia Artificial.

Las organizaciones llevan décadas lidiando con duplicidades, inconsistencias, sistemas legados, campos incompletos y diferentes versiones de una misma información.

La diferencia es la velocidad.

Antes, una inconsistencia podía afectar un reporte que posteriormente era revisado por una persona.

Ahora esa misma información puede alimentar automáticamente un modelo que:

• Evalúa una operación.
• Prioriza una alerta.
• Segmenta clientes.
• Detecta fraude.
• Recomienda una decisión.
• Ejecuta una acción.
• Genera un reporte.
• Activa otro proceso.

La automatización amplifica tanto las buenas decisiones como los errores.

Los datos deficientes ya están frenando la adopción de IA financiera

Esto no es solamente una preocupación conceptual.

El Global AI in Financial Services Report 2026 de Cambridge señala que la disponibilidad y calidad de los datos continúa siendo uno de los principales obstáculos para escalar Inteligencia Artificial en servicios financieros. Entre los participantes consultados, el problema fue señalado por el 66 % de los proveedores de IA, el 46 % de los reguladores y el 40 % de la industria; entre instituciones financieras tradicionales, el porcentaje llegó al 49 %.

El mismo estudio identifica entre los principales riesgos percibidos la privacidad y protección de datos, los resultados no confiables, la pérdida de supervisión humana y la resiliencia operacional.

La conclusión es importante:

no podemos hablar seriamente de Gobierno de IA sin hablar de Gobierno de Datos.

¿Cuándo un problema de datos se convierte en riesgo operacional?

Cuando puede provocar una pérdida, una interrupción, una decisión incorrecta, un incumplimiento o un impacto sobre clientes.

Por ejemplo:

Un dato incorrecto puede generar un falso positivo de fraude.

Un registro duplicado puede producir una operación repetida.

Información desactualizada puede afectar una evaluación de riesgo.

Una clasificación incorrecta puede generar un reporte regulatorio equivocado.

Datos incompletos pueden llevar a una decisión automatizada incorrecta.

Una fuente externa degradada puede afectar simultáneamente cientos de procesos.

En todos estos casos, el problema técnico termina convirtiéndose en un evento operacional.

El dato también tiene una cadena de suministro

Normalmente pensamos en proveedores cuando hablamos de software, nube o infraestructura.

Pero cada vez más organizaciones también dependen de proveedores de información. Esto significa que debemos empezar a pensar en una verdadera cadena de suministro del dato.

¿De dónde proviene?

¿Quién lo transforma?

¿Con qué frecuencia se actualiza?

¿Quién valida su calidad?

¿Qué ocurre si deja de estar disponible?

¿Qué proceso consume esa información?

¿Qué decisiones dependen de ella?

Una organización puede tener perfectamente controlado su modelo y, sin embargo, desconocer suficientemente la cadena de datos que lo alimenta.

No todos los datos necesitan el mismo nivel de control

Aquí también conviene evitar extremos. No tiene sentido aplicar el mismo nivel de gobierno a todos los datos de la organización. La prioridad debería estar en los datos críticos para decisiones críticas.

Por ejemplo, aquellos utilizados para:

• Decisiones crediticias.
• Prevención de fraude.
• Prevención de lavado de activos.
• Reportes regulatorios.
• Gestión de liquidez.
• Cálculo de riesgo.
• Procesamiento de operaciones.
• Atención de clientes.
• Inteligencia Artificial.
• Automatizaciones críticas.

Cuanto mayor sea el impacto de una decisión, mayor debería ser la exigencia sobre los datos que la soportan.

El Gobierno de IA comienza con preguntas bastante simples

Antes de discutir explicabilidad, modelos fundacionales o arquitecturas avanzadas, un Comité podría empezar preguntando:

¿Sabemos qué datos utilizan nuestros modelos críticos?

¿Conocemos su origen?

¿Quién responde por su calidad?

¿Qué ocurre si esa información está equivocada?

¿Cómo detectamos una degradación?

¿Podemos detener una decisión automatizada cuando la calidad cae por debajo de niveles aceptables?

Estas preguntas están completamente alineadas con el enfoque de gestión de riesgo de IA que impulsa NIST. El AI RMF estructura la gestión alrededor de las funciones Govern, Map, Measure y Manage, y exige considerar riesgos durante todo el ciclo de vida, incluyendo componentes, datos y tecnologías de terceros.

De Data Quality a indicadores de riesgo

La calidad de datos necesita entrar en los tableros de riesgo cuando pueda afectar procesos relevantes.

Algunos indicadores podrían ser:

• Porcentaje de registros críticos incompletos.
• Duplicidad de registros.
• Antigüedad promedio de datos críticos.
• Errores detectados después de una decisión automatizada.
• Modelos operando con fuentes degradadas.
• Incidentes originados por calidad de datos.
• Fuentes críticas sin responsable definido.
• Diferencias entre sistemas sobre un mismo dato.
• Excepciones manuales provocadas por información incorrecta.
• Decisiones revertidas por problemas de datos.

El objetivo no es convertir cada métrica de Data Quality en un KRI.

Es identificar aquellas que pueden anticipar una pérdida o deterioro del proceso.

Un nuevo mapa de dependencias

Cuando realizamos un BIA o analizamos resiliencia operacional solemos mapear procesos, aplicaciones, personas, instalaciones y proveedores.

Los datos también deberían aparecer explícitamente.

Basilea establece que las entidades financieras deben identificar y mapear la información y los datos necesarios para mantener sus operaciones críticas, junto con personas, tecnología, procesos, instalaciones y terceros.

Esto significa que para un servicio crítico deberíamos poder responder:

¿Qué datos necesita para funcionar y qué ocurre si esos datos están disponibles, pero no son confiables?

Esa última parte es fundamental.

Porque disponibilidad e integridad son problemas diferentes.

El próximo incidente puede comenzar con un dato

Las organizaciones están invirtiendo enormes cantidades de recursos en modelos más avanzados, automatización y agentes de IA.

Es lógico.

Pero cuanto mayor sea la autonomía de estas tecnologías, mayor será también su dependencia de la calidad de la información que reciben.

Un modelo rápido alimentado con información incorrecta no reduce el riesgo.

Simplemente permite equivocarse más rápido.

Por eso, el desafío no consiste solamente en gobernar algoritmos.

También necesitamos gobernar aquello que los algoritmos creen que es verdad.

Reflexión final

Durante mucho tiempo, la calidad de datos fue vista como un problema técnico.

Después se convirtió en un problema de Gobierno de Datos.

Ahora está dando un paso adicional.

Se está convirtiendo en un problema de gestión de riesgos.

Porque cuando los datos alimentan decisiones automatizadas, modelos de IA y procesos críticos, una inconsistencia deja de ser simplemente una incidencia en una base.

Puede convertirse en una decisión incorrecta, un incumplimiento, una pérdida financiera o un incidente reputacional.

La próxima vez que un algoritmo se equivoque, quizás la primera pregunta no debería ser:

“¿Qué falló en el modelo?”

Tal vez deberíamos empezar por una mucho más básica:

“¿Con qué información tomó esa decisión?”