Casi todas las empresas que contratan un proveedor tecnológico exigen un compromiso de disponibilidad: que el sistema esté operativo el 99% del tiempo, por ejemplo. Muy pocas exigen el mismo nivel de compromiso sobre la calidad de los datos que ese sistema entrega o recibe. Y sin embargo, un sistema perfectamente disponible que entrega datos incompletos, desactualizados o incorrectos puede causar tanto daño como uno que directamente no funciona, con el agravante de que ese daño pasa desapercibido más tiempo porque el sistema "sí que está funcionando". Un contrato de nivel de datos, o data SLA, es la herramienta que cierra exactamente ese hueco.
Qué es un contrato de nivel de datos, en términos sencillos
Un contrato de nivel de datos, conocido en inglés como data SLA (data service level agreement), es un acuerdo formal que establece compromisos medibles sobre la calidad, la actualización y la disponibilidad de un conjunto de datos concreto, entre quien los produce o los suministra y quien depende de ellos para tomar decisiones o alimentar un sistema automatizado. Define, con cifras y plazos concretos, cosas como con qué frecuencia se actualizan los datos, qué porcentaje de completitud se garantiza, cuánto tiempo puede pasar como máximo desde que ocurre un evento hasta que ese dato queda reflejado en el sistema, y qué ocurre si esos compromisos no se cumplen.
La diferencia con un SLA técnico tradicional es el objeto del compromiso. Un SLA técnico habitual garantiza que un sistema esté disponible y responda en un tiempo determinado; no dice nada sobre si la información que ese sistema entrega es correcta, está completa o llega a tiempo. Un contrato de nivel de datos pone el foco justo ahí: no en si el sistema funciona, sino en si los datos que produce merecen confianza para tomar una decisión sobre ellos.
¿Por qué un data SLA importa especialmente cuando hay un sistema de IA de por medio?
Un data SLA se vuelve especialmente relevante cuando un sistema de IA depende de datos que produce otra área de la empresa, otro sistema o un proveedor externo, porque sin ese acuerdo explícito nadie asume la responsabilidad formal de que esos datos lleguen con la calidad y la puntualidad que el sistema automatizado necesita para funcionar bien. Sin un contrato claro, si el sistema de IA falla porque recibió datos incompletos o desactualizados, la conversación posterior se convierte en una discusión sobre de quién fue la culpa, en lugar de una corrección rápida del problema, porque nunca se definió con antelación qué se esperaba exactamente de esos datos. Con un data SLA, la responsabilidad y el umbral aceptable quedan fijados de antemano, lo que convierte cualquier incumplimiento en un hecho objetivo y accionable, no en una discusión.
Qué elementos debe incluir un contrato de nivel de datos
Un data SLA útil no necesita ser un documento legal extenso; necesita cubrir con precisión un puñado de compromisos concretos.
Frecuencia de actualización
Especifica cada cuánto tiempo se actualizan los datos —en tiempo real, cada hora, cada día— y qué margen de retraso se considera aceptable antes de que se active una alerta o una escalada.
Umbral de completitud y exactitud
Fija qué porcentaje mínimo de los registros debe estar completo y correcto, con una definición clara de qué significa "completo" y "correcto" para ese conjunto de datos concreto, evitando ambigüedades que luego generen discusiones.
Disponibilidad de la fuente
Establece qué porcentaje del tiempo debe estar accesible la fuente de datos, y qué ocurre —a quién se avisa, en qué plazo— si esa fuente deja de estar disponible temporalmente.
Proceso ante incumplimiento
Define qué pasos se siguen cuando no se cumple alguno de los compromisos anteriores: quién debe ser notificado, en qué plazo debe corregirse, y qué consecuencia tiene para el sistema que depende de esos datos mientras el problema se resuelve.
¿Un data SLA solo tiene sentido con proveedores externos o también entre departamentos de la misma empresa?
Un contrato de nivel de datos tiene sentido en ambos casos, y de hecho suele ser igual de necesario, si no más, entre departamentos internos de la misma empresa que entre una empresa y un proveedor externo. Cuando el proveedor es externo, suele existir ya una relación contractual donde añadir compromisos de datos resulta natural. Cuando la dependencia es interna —por ejemplo, un agente de IA de atención al cliente que depende de que el equipo comercial mantenga actualizado el estado de cada cuenta en el CRM—, la falta de un acuerdo formal es mucho más habitual, precisamente porque "somos la misma empresa" genera la falsa sensación de que no hace falta formalizar nada. En la práctica, esa falta de acuerdo interno es una de las causas más frecuentes de que un sistema automatizado reciba datos de peor calidad de la que necesitaría, simplemente porque nadie en el departamento que los genera sabía que otro sistema dependía críticamente de su puntualidad y su exactitud.
Cómo negociar un data SLA con un proveedor externo
Negociar un contrato de nivel de datos con un proveedor externo funciona mejor cuando se plantea en términos del impacto de negocio, no en términos técnicos que el proveedor puede diluir con facilidad. En lugar de pedir de forma genérica "datos de buena calidad", conviene llevar a la negociación las cifras exactas que el proyecto necesita —por ejemplo, actualización cada cuatro horas como máximo y un 97% de campos obligatorios completos— y preguntar directamente qué compromiso está dispuesto a asumir el proveedor sobre esas cifras concretas, con qué penalización si no se cumplen. Muchos proveedores ya ofrecen SLA técnicos de disponibilidad por defecto, pero pocos incluyen compromisos de calidad de datos si no se les pide explícitamente, así que conviene tratarlo como un punto de negociación propio, no como algo que viene incluido de serie en cualquier contrato tecnológico estándar.
Aplicación práctica en una pyme
Imagina una empresa donde un agente de IA genera cada mañana un resumen de riesgo de impago para el equipo comercial, basado en los datos de facturación y en el histórico de pagos de cada cliente. Sin un data SLA, si el departamento de administración retrasa la actualización de los pagos recibidos, el agente puede señalar como moroso a un cliente que ya ha pagado, generando una gestión comercial incómoda e innecesaria. Con un contrato de nivel de datos sencillo entre ambos departamentos —los pagos deben registrarse en un plazo máximo de 24 horas, con un compromiso de exactitud del 98%—, cualquier desviación se detecta y se corrige antes de que llegue a afectar a la relación con el cliente, y queda claro desde el principio quién es responsable de qué parte del proceso.
Formalizar este tipo de compromisos, aunque sea con un documento breve entre dos departamentos de la misma empresa, es lo que convierte una dependencia de datos implícita y frágil en una relación clara con responsabilidades definidas.
MG Solutions puede ayudarte a definirlo
En MG Solutions ayudamos a las empresas a definir contratos de nivel de datos claros entre los sistemas y los equipos de los que depende cada proyecto de IA, para que la calidad de la información no dependa de la buena voluntad de nadie. Si tu agente de IA depende de datos que produce otro departamento o un proveedor externo, pide un diagnóstico gratuito y lo formalizamos juntos.