La cuestión de si una empresa dispone de la calidad de datos y la gobernanza necesarias para usar la IA de forma efectiva es una de las preguntas más infravaloradas en la conversación de liderazgo sobre IA, y también una de las más determinantes para que el programa funcione realmente. Las demostraciones tecnológicas hacen que la IA parezca funcionar con cualquier dato, los argumentos de los proveedores refuerzan esa impresión y el primer caso de uso real dentro de la empresa suele poner de manifiesto la brecha entre los datos de la demo y los datos de producción con los que la IA se encontrará en la práctica. Esa brecha es donde muchos programas de IA pasan de prometedores a decepcionantes, y la diferencia rara vez tiene que ver con la IA.
La respuesta honesta es más útil que la fácil. La mayoría de las empresas cuentan con calidad de datos y gobernanza que son parcialmente suficientes para IA, con la suficiencia variando por dominio y las brechas apareciendo en lugares previsibles. El trabajo para cerrar esas brechas es real y más acotado de lo que algunos líderes temen, y la base que se construye beneficia a la IA y a cualquier otra iniciativa que use los mismos datos. Este texto recorre lo que la IA necesita realmente de los datos, las dimensiones de calidad que importan, la forma de gobernanza que respalda un programa de IA y la postura práctica que convierte la pregunta en un plan operativo.
Lo que la IA necesita realmente de los datos
El primer paso útil es ser preciso sobre lo que la IA necesita realmente de los datos que posee la empresa. La afirmación general de que la IA necesita buenos datos es cierta pero no lo bastante específica para orientar el trabajo. Los requisitos reales se dividen en varias categorías que merece la pena considerar por separado porque la respuesta a cada una es distinta.
La IA necesita acceso a los datos. El modelo solo puede razonar sobre lo que puede leer, y los datos que residen en sistemas a los que la IA no puede acceder son datos con los que la IA no puede ayudar. La cuestión del acceso es en parte una pregunta de integración técnica y en parte una pregunta de gobernanza sobre lo que la IA tiene permitido ver. La mayoría de las empresas descubren que el problema de acceso es mayor de lo que pensaban porque los datos están dispersos en sistemas que nunca se diseñaron para comunicarse entre sí.
La IA necesita que los datos sean inteligibles. El modelo puede leer datos estructurados mediante SQL, datos semiestructurados mediante API y contenido no estructurado mediante recuperación, y cada caso requiere que los datos estén en una forma con la que la IA pueda trabajar. La pregunta de la inteligibilidad abarca los esquemas, la documentación, las convenciones y la coherencia que permiten a la IA entender qué son los datos y cómo usarlos. Los datos que requieren conocimiento institucional profundo para interpretarse son datos que la IA utilizará incorrectamente con más frecuencia que de forma útil.
La IA necesita que los datos estén actualizados dentro de la frescura que el caso de uso exige. El modelo que razona sobre un cliente necesita ver la actividad reciente del cliente. El modelo que resume el historial de soporte necesita ver los tickets recientes. El requisito de frescura varía según el caso de uso, y la brecha entre la frescura real de los datos de la empresa y lo que el caso de uso necesita es una de las sorpresas más comunes en la primera ola de trabajo con IA.
La IA necesita que los datos sean precisos en la medida que exige el caso de uso. El modelo que redacta una respuesta al cliente necesita que la información del cliente sea correcta. El modelo que genera un resumen financiero necesita que los datos financieros sean correctos. El requisito de precisión rara vez exige perfección, pero es una barrera real que los datos deben superar para que la IA produzca resultados útiles. La IA sobre datos inexactos no produce de forma mágica resultados correctos; produce resultados que reflejan con confianza las inexactitudes.
La IA necesita que los datos estén en el contexto adecuado para la pregunta que se formula. El mismo registro de cliente puede ser el contexto correcto para una respuesta de soporte y el contexto equivocado para una conciliación financiera. El modelo que recibe el contexto equivocado para la pregunta a menudo genera un resultado plausible e incorrecto, y la disciplina de proporcionar el contexto adecuado para cada caso de uso es una parte real del trabajo con los datos.
La IA necesita que los datos tengan permisos adecuados, de modo que la IA solo vea lo que el usuario o el proceso en cuyo nombre actúa tiene permitido ver. La cuestión del permiso es en parte de gobernanza y en parte técnica, y debe resolverse en la capa de integración en lugar de dejarse a que la IA la respete por sí misma. El modelo no es un límite de seguridad.
La IA necesita que los datos estén etiquetados o clasificados lo bastante bien para que los datos correctos fluyan al modelo correcto con las protecciones adecuadas. Los datos de clientes que incluyen información regulada deben identificarse como tales. Los datos internos sensibles deben marcarse. Las etiquetas de datos son las que permiten que la gobernanza de datos escale dentro del programa de IA en lugar de chocar con él.
Las dimensiones de calidad que más importan
La conversación sobre la calidad de datos lleva décadas en las empresas y ha producido un conjunto de dimensiones que la comunidad de datos usa para describir la calidad. Vale la pena conocer estas dimensiones porque dan al programa de IA un vocabulario compartido con las funciones de datos y gobernanza, y son lo que el trabajo de base aborda en la práctica.
La dimensión de completitud es si los datos tienen los campos y los registros que el caso de uso necesita. El registro de cliente que carece de la etiqueta de industria relevante es incompleto para el caso de uso que segmenta por industria. Las lagunas de completitud suelen ser conocidas por los operativos que dependen de los datos y a menudo no son conocidas por la dirección que aprueba el programa de IA construido sobre esos datos.
La dimensión de exactitud es si los datos reflejan el estado real del mundo que representan. El registro de cliente que muestra un cargo obsoleto es inexacto para el caso de uso que decide qué contenido enviar al contacto. La exactitud se degrada cuando el proceso fuente de los datos es débil y mejora cuando el proceso fuente es sólido, y el programa de IA construido sobre datos inexactos se apoya en la misma base que el trabajo humano que lleva años compensando esa inexactitud.
La dimensión de coherencia es si el mismo hecho se representa de la misma manera en los distintos sistemas. El cliente que aparece con tres grafías diferentes del nombre de la empresa en tres sistemas distintos es el mismo cliente para el lector humano y tres clientes para la IA que no ha aprendido las reglas. Las lagunas de coherencia son algunos de los problemas de calidad de IA más comunes en los despliegues de producción, y la resolución suele requerir bien el trabajo de datos subyacente, bien una capa de resolución de entidades que gestione el mapeo en tiempo de ejecución.
La dimensión de puntualidad es si los datos están actualizados dentro de la ventana que exige el caso de uso. Los datos de pedidos que se actualizan diariamente son puntuales para el resumen semanal e impuntuales para la notificación al cliente en tiempo real. El requisito de puntualidad lo fija el caso de uso, y la infraestructura de datos debe soportar los casos de uso que el programa asume.
La dimensión de unicidad es si el mismo registro aparece una sola vez o si se ha duplicado. Los registros de clientes duplicados que se han ido acumulando durante años producen salidas de IA confusas que señalan varios registros como si fueran clientes distintos, y la resolución exige bien un ejercicio de desduplicación, bien una capa de datos maestros que resuelva los duplicados aguas abajo.
La dimensión de validez es si los valores de datos se ajustan a las reglas que deberían cumplir. Los números de teléfono que no son analizables. Las fechas que están en el formato equivocado. Los valores de categoría que no coinciden con el vocabulario controlado. Las lagunas de validez suelen ser pequeñas de forma individual pero producen grandes problemas de calidad de IA a escala porque la IA es sensible a los patrones que el lector humano filtra.
La dimensión de integridad es si las relaciones entre los datos están intactas. El pedido que apunta a un cliente que ya no existe. La transacción que referencia una cuenta que ha sido fusionada. Las lagunas de integridad hacen que la IA produzca resultados que referencian datos que no están donde la IA espera, con modos de fallo que van desde lo confuso hasta lo activamente engañoso.
La dimensión de linaje es si la empresa puede rastrear de dónde proceden los datos y cómo se transformaron. El linaje es lo que soporta la depuración cuando la IA produce algo inesperado y la revisión de cumplimiento cuando el regulador pregunta de dónde salió un número. Las lagunas de linaje hacen que el programa de IA sea más difícil de operar y de defender.
La forma de gobernanza que respalda la IA
El lado de la gobernanza cubre las prácticas y las estructuras que aseguran que los datos se manejen correctamente en toda la empresa. La gobernanza que ha funcionado para la función más amplia de datos y analítica se extiende generalmente a la IA con algunas consideraciones adicionales que el programa de IA trae consigo.
Un catálogo de datos que describa qué datos existen, dónde residen, qué significan y quién los posee. El catálogo es la base que permite al programa de IA encontrar y usar los datos correctos y permite que el trabajo de gobernanza ocurra en todos los datos que la empresa posee en lugar de solo en los datos que el equipo actual recuerda.
Un modelo de propiedad claro que nombre al responsable de cada dominio de datos. El responsable es la persona encargada de la calidad, la documentación, las decisiones de acceso y los cambios en el dominio, y la propiedad es lo que proporciona a la gobernanza a quién llamar cuando surge una pregunta. Las empresas sin propiedad clara suelen descubrir que las preguntas sobre datos se vuelven políticas porque nadie tiene la autoridad para responderlas.
Un esquema de clasificación de datos que etiquete los datos con la sensibilidad, la clase regulatoria y los requisitos de tratamiento. La clasificación es lo que permite al programa de IA aplicar automáticamente las protecciones adecuadas en lugar de confiar en que cada usuario o proceso conozca las reglas para cada dato.
Una práctica de gestión de accesos que decida quién y qué puede leer los datos y que se integre con la infraestructura de identidad de la empresa. El programa de IA hereda las decisiones de acceso de la gobernanza más amplia, y la IA recibe el acceso del usuario o proceso en cuyo nombre actúa en lugar de ejecutarse con privilegios ampliados.
Una práctica de gestión de la calidad que supervise las dimensiones de calidad en los dominios de datos relevantes, exponga los problemas a los responsables y haga seguimiento de la resolución. La práctica de calidad es la que mantiene la base de datos sana a lo largo del tiempo en lugar de permitir que se degrade a medida que evolucionan los sistemas fuente y los casos de uso.
Una práctica de gestión de cambios que gestione los cambios de esquema, los cambios en los sistemas fuente y los cambios de caso de uso de forma que preserve la integridad de los datos de los que depende la IA. La gestión de cambios evita la situación en la que una actualización rutinaria de un sistema fuente rompe el caso de uso de IA que nadie recordó que lo leía.
Una práctica de privacidad y cumplimiento que gestione los requisitos regulatorios que se aplican a los datos que usa la IA. La práctica abarca el GDPR, la CCPA, la HIPAA, las regulaciones sectoriales y las nuevas regulaciones específicas de IA que están surgiendo. La práctica la dirigen las funciones legal y de cumplimiento en colaboración con las funciones de datos e IA, y el programa de IA opera dentro de la práctica en lugar de alrededor de ella.
Una práctica de gestión de proveedores que gestione a los proveedores de IA y a otros proveedores que tocan los datos de la empresa, con contratos, revisiones de seguridad, controles de acceso y monitorización continua, todo gestionado dentro de la práctica existente en lugar de como un caso especial. Una práctica de auditoría y trazabilidad que capture lo que la IA ha hecho con los datos y que apoye la investigación, la revisión de cumplimiento y la depuración operativa.
Los patrones que han funcionado
Las empresas que han construido la base de datos y gobernanza de una manera que soporta un programa de IA sólido han hecho un conjunto reconocible de cosas, y los patrones merecen nombrarse porque son lo que separa la base que resiste de la que se derrumba.
Delimitaron el trabajo de base a los datos que el programa de IA necesita en lugar de intentar corregir todos los problemas de calidad de datos de la empresa. El alcance estuvo dirigido por los casos de uso en la hoja de ruta y no por una aspiración abstracta de tener todos los datos perfectos, y el trabajo entregó mejoras visibles en los dominios que la IA iba a utilizar.
Acompañaron el trabajo de base con los casos de uso de IA en lugar de tratarlo como un prerrequisito que debía terminar antes de que pudiera comenzar cualquier trabajo de IA. Las inversiones en la base se secuenciaron con los casos de uso que dependían de ellas, y los casos de uso heredaron el beneficio del trabajo a medida que se implementaba en lugar de esperar a que se completara una transformación de datos de varios años.
Invertieron en el catálogo de datos y en el modelo de propiedad como la columna vertebral de la gobernanza en lugar de tratarlos como proyectos de documentación que nadie mantendría. El catálogo y la propiedad se trataron como artefactos operativos vivos que las funciones de datos e IA usaban todos los días, y el mantenimiento se financiaba como parte del presupuesto operativo en lugar de como una adición opcional.
Integraron el monitoreo de la calidad de los datos en los casos de uso de IA para que el equipo viera los problemas de calidad en producción en lugar de descubrirlos por quejas de clientes o del personal. El monitoreo cubría la frescura, la integridad, la validez y los patrones de datos inusuales que afectarían los resultados de la IA, y el equipo de operaciones tenía una vía clara de acción cuando el monitoreo se activaba.
Gestionaron los permisos y la privacidad en la capa de integración en lugar de depender de que la IA respetara las reglas. La capa de integración fue el lugar donde se aplicaban las decisiones de acceso, se realizaba la minimización de datos y se capturaba la pista de auditoría. La disciplina implicaba que la IA no pudiera usarse para eludir los controles ni por accidente.
Involucraron a las funciones de datos y gobernanza como socias en el programa de IA en lugar de verlas como obstáculos a los que había que rodear. Los equipos de datos y gobernanza formaron parte del diseño del programa de IA, de la revisión de casos de uso y del modelo operativo, y el programa de IA respetó el trabajo que esos equipos habían realizado a lo largo de los años en lugar de considerarlo legado para reemplazar.
Los patrones que han fallado
Las empresas cuyos programas de IA han tenido problemas con la cuestión de los datos y la gobernanza también han hecho un conjunto de cosas reconocibles, y nombrar los patrones de fallo es útil como guía de lo que hay que evitar.
Asumieron que los datos eran lo suficientemente buenos hasta que el primer caso de uso demostró que no lo eran. El descubrimiento de que los datos tienen problemas ocurre en medio de la construcción del caso de uso en lugar de al comienzo, y el proyecto entonces tiene que pausar para el trabajo de datos o lanzar con datos defectuosos con las consecuencias previsibles. Las empresas que no examinan los datos antes de la construcción a menudo descubren los problemas en el peor momento posible.
Delimitaron el trabajo de base como una transformación de varios años que debía completarse antes de capturar cualquier valor de IA. El alcance produjo un proyecto que absorbió presupuesto y no entregó nada utilizable durante años, y el equipo directivo o perdió la paciencia o el programa fue superado por casos de uso que ignoraron la base y produjeron los problemas de calidad previsibles. El enfoque todo o nada rara vez ha funcionado ni para el trabajo de datos ni para el trabajo de IA.
Trataron el catálogo de datos y el modelo de propiedad como ejercicios de documentación que nadie usaría. Los artefactos existían y quedaban obsoletos en unos meses, y el programa de IA terminó sin apoyarse en el trabajo de base por el que la empresa había pagado. El catálogo y la propiedad solo funcionan cuando son operativos y no meramente documentales.
Delegaron los permisos y la privacidad como responsabilidad del proveedor de IA en lugar de de la empresa. La dependencia del proveedor produjo brechas que el proveedor no estaba en posición de cerrar, y los problemas salieron a la luz en hallazgos de auditoría e informes de incidentes que el programa de IA tuvo que explicar. El proveedor puede ser un socio en la gobernanza de datos y no un sustituto del trabajo propio de la empresa.
Trataron a las funciones de datos y gobernanza como obstáculos en lugar de socios y trabajaron alrededor de ellas en lugar de con ellas. El programa de IA se lanzó sin la alineación que lo habría hecho sostenible, y las funciones de datos y gobernanza o bien se opusieron mediante los procesos formales de revisión o aceptaron el programa con reticencia mientras reservaban el derecho a hacer cumplir las reglas después. Cualquiera de los dos resultados hizo que el programa de IA fuera más difícil de mantener.
No mantuvieron la base a medida que el programa escalaba. El catálogo derivó, la propiedad decayó, el monitoreo de calidad se quedó atrás y la base que había soportado la primera ola de casos de uso resultó incapaz de soportar la siguiente. El programa entonces o bien invirtió en la base bajo presión o aceptó los problemas de calidad que producían las brechas, y ninguna de las dos posiciones era la que el programa quería.
La postura práctica que convierte la cuestión en un plan
Las empresas que han resuelto bien la cuestión de datos y gobernanza comparten una postura reconocible que vale la pena describir en términos prácticos.
La postura comienza con una evaluación honesta de la base de datos frente a los casos de uso que el programa de IA está abordando. La evaluación es concreta y no abstracta, con los dominios de datos específicos, las dimensiones de calidad y las prácticas de gobernanza evaluadas frente a los requisitos de los casos de uso en la hoja de ruta. El resultado es una imagen clara de dónde la base está lista, dónde necesita inversión y dónde el programa debería ajustar la selección de casos de uso hasta que la base se ponga al día.
La postura trata el trabajo de base como una inversión sostenida en lugar de un proyecto puntual. El catálogo de datos, el modelo de propiedad, el monitoreo de calidad y las prácticas de gobernanza se financian de forma continua en lugar de como una construcción que termina. La financiación refleja la realidad de que la base debe mantenerse al día con los sistemas fuente, los casos de uso y el entorno regulatorio que se mueven con el tiempo.
La postura empareja las inversiones en la base con los casos de uso de IA que dependen de ellas. Los casos de uso que requieren un dominio de datos específico obtienen el trabajo de base para ese dominio antes que ellos, y los casos de uso heredan el beneficio a medida que el trabajo se implementa. La secuenciación evita que el trabajo de base parezca una sobrecarga que no produce valor y evita que los casos de uso se lancen sobre una base que no está lista.
La postura involucra a las funciones de datos y gobernanza como socios plenos en el programa de IA. Las funciones forman parte del diseño del programa, de la revisión de casos de uso, del modelo operativo y de los informes de liderazgo. La asociación es lo que da al programa de IA el apoyo institucional que necesita para operar a escala en lugar de la fricción institucional que habría si se descuidara la colaboración.
La postura construye las prácticas operativas que mantienen la base saludable a medida que el programa escala. El mantenimiento del catálogo, el monitoreo de calidad, las revisiones de propiedad y la actualización periódica de la gobernanza se financian como parte del modelo operativo en lugar de como adiciones discrecionales que se recortan cuando el presupuesto se aprieta. La disciplina es lo que permite al programa seguir añadiendo casos de uso sin que la base se degrade.
La postura mide e informa la salud de la base junto con las métricas del programa de IA. El equipo directivo ve el panorama de cómo la base está sosteniendo el programa, las brechas que están surgiendo y las inversiones necesarias. La visibilidad es lo que evita que el trabajo de base sea descuidado cuando las demandas inmediatas de casos de uso se intensifican.
La respuesta honesta a la pregunta del titular
Entonces, ¿tienen la calidad de datos y la gobernanza adecuadas para usar IA? La respuesta honesta para la mayoría de las empresas es que la base está parcialmente lista, con la preparación que varía según el dominio de datos, y el trabajo para cerrar las brechas es real y más acotado de lo que sugiere la peor versión.
La calidad de los datos suele ser lo suficientemente fuerte en los dominios en los que la empresa ha invertido con el tiempo y es más débil en los dominios que han sido descuidados. La gobernanza suele estar presente en forma de las prácticas existentes de datos y analítica y necesita extenderse para cubrir las consideraciones específicas de IA en lugar de una reconstrucción total. El trabajo para preparar la base para el programa de IA es real y asequible en los plazos en los que opera el programa de IA.
Las empresas que delimitan el trabajo de base según los casos de uso en la hoja de ruta, emparejan el trabajo con los casos de uso, tratan a las funciones de datos y gobernanza como socios y construyen las prácticas operativas que mantienen la base saludable pueden ejecutar un programa de IA sobre una base que lo respalde. Las empresas que asumen que los datos son suficientes, tratan la base como un prerrequisito que debe terminar primero o trabajan alrededor de las funciones de datos y gobernanza tienden a producir programas de IA que decepcionan de maneras previsibles.
Cómo ProvenROI aborda la cuestión de datos y gobernanza con los clientes
El enfoque de ProvenROI a la cuestión de datos y gobernanza en compromisos de IA comienza con una evaluación honesta de la base de datos frente a los casos de uso específicos que el cliente está considerando. La evaluación cubre los dominios de datos que los casos de uso tocarán, las dimensiones de calidad que importan para los casos de uso, las prácticas de gobernanza que deben extenderse al programa de IA y las brechas que el programa necesita cerrar antes o junto con la construcción. El resultado es una imagen de trabajo de dónde la base está lista y dónde necesita inversión.
El trabajo de base se delimita según los casos de uso en la hoja de ruta en lugar de una aspiración abstracta de datos perfectos. El trabajo se secuencia con los casos de uso que dependen de él, y las inversiones se emparejan con el valor que habilitan. La secuenciación produce mejoras en la base que el programa de IA utiliza inmediatamente y que el equipo directivo puede vincular a los resultados del programa en lugar de cargarlas como sobrecarga.
Las funciones de datos y gobernanza dentro del cliente se involucran como socias desde el inicio del compromiso en lugar de como aprobadoras al final. Las funciones contribuyen al diseño del programa, participan en las revisiones de casos de uso y se responsabilizan de las partes del modelo operativo que corresponden a su dominio. La asociación es lo que da al programa el apoyo institucional que necesita para escalar.
Las prácticas operativas que mantienen la base saludable se diseñan junto con el programa en lugar de añadirse más tarde. El mantenimiento del catálogo, el monitoreo de calidad, las revisiones de propiedad y la actualización de la gobernanza forman parte del modelo operativo que el programa ejecutará, y la financiación de estas prácticas se incluye en la economía del programa en lugar de tratarse como discrecional.
Los informes al equipo directivo incluyen la salud de la base junto con las métricas del programa de IA. Los líderes ven la imagen de dónde la base está sosteniendo el programa, dónde aparecen las brechas y dónde se necesita inversión adicional. La visibilidad mantiene el trabajo de base en la conversación del programa en lugar de dejar que se deslice cuando las demandas inmediatas de casos de uso se imponen.
La cuestión de datos y gobernanza no es una pregunta que tenga una única respuesta aplicable a todas las empresas. Es una pregunta con una respuesta conocible para cada empresa que se tome el tiempo de trabajarlo honestamente. ProvenROI ayuda a los clientes a llegar a esa respuesta y a construir la base que el programa de IA necesita, con el trabajo dimensionado a las brechas reales y secuenciado con el programa real en lugar de tratarse como una precondición abstracta. Esa es la base en la que el programa de IA puede confiar en lugar de tener que disculparse por ella.