La violencia lenta de los datos deficientes

La violencia lenta de los datos deficientes

La hoja de cálculo no gritó

La hoja de cálculo no parecía peligrosa. Así empieza casi siempre. Estaba en una carpeta compartida con un nombre sensato, tres columnas ocultas, dos formatos de fecha, un campo de comentarios que se había convertido en una pequeña novela y una pestaña llamada final que mentía de la manera tradicional. Un equipo la usaba para conciliar los registros de clientes antes de alimentar un nuevo flujo de trabajo. Nadie actuaba con imprudencia. Comprobaban los totales. Eliminaban los duplicados evidentes. Preguntaban a la persona que había heredado el archivo de la persona que lo había heredado. Las respuestas eran lo bastante plausibles para continuar.

Tres meses después apareció el daño, pero no como un único acontecimiento. A un cliente se le pidieron documentos que ya había aportado. Otro fue derivado a la cola de servicio equivocada. Apareció un indicador de riesgo en un caso porque una cuenta cerrada seguía pareciendo activa. Un agente de soporte pasó veinte minutos pidiendo disculpas por un sistema que insistía en una dirección antigua. Un responsable vio un rendimiento ligeramente mejor y una confianza ligeramente peor. Ninguno de estos incidentes parecía lo bastante grande como para detener el programa. Juntos eran el programa.

Los datos deficientes suelen describirse como una molestia técnica. Campos que faltan, códigos incoherentes, filas duplicadas, registros obsoletos, etiquetas débiles. Ese lenguaje es preciso y demasiado pequeño. Los datos deficientes se convierten en violencia lenta cuando los pequeños errores transfieren silenciosamente el coste a personas que no los crearon. Hacen que los ciudadanos demuestren lo que la institución olvidó. Hacen que los empleados reparen lo que el proceso distorsionó. Hacen que los clientes se repitan. Hacen que los auditores reconstruyan el significado después de que el significado se desechara. Hacen que los modelos parezcan inciertos, sesgados o necios cuando reflejan en parte un fallo de registro.

La violencia es lenta porque el daño está distribuido. Ninguna fila asume la responsabilidad. Ningún panel admite la deuda. El sistema sigue funcionando y, por tanto, parece exitoso desde la distancia suficiente. El daño vive en llamadas extra, solicitudes rechazadas, cartas equivocadas, acceso denegado, personal frustrado, reputación dañada y decisiones que se vuelven más difíciles de impugnar porque el registro ha aprendido a sonar oficial. Los datos deficientes no necesitan drama. Tienen paciencia.

La calidad no es limpieza

La calidad de los datos suele reducirse a la limpieza, como si el objetivo fuera una tabla sin migas visibles. La limpieza ayuda. Los formatos estándar, los valores válidos, los campos completos, las filas deduplicadas y los rangos razonables son necesarios. Pero un conjunto de datos limpio puede seguir siendo inadecuado para la tarea. Un campo puede estar perfectamente formateado y ser semánticamente incorrecto. Una fecha puede ser válida y estar obsoleta. Una etiqueta puede ser coherente e injusta. Un registro puede estar completo porque alguien rellenó no en el campo de desconocido, que es como muchos pequeños desastres se ponen corbata.

La calidad es la aptitud para un propósito con evidencia. El mismo registro puede ser suficiente para enviar un boletín, insuficiente para una decisión crediticia, peligroso para un modelo de triaje médico e irrelevante para una evaluación de políticas públicas. El contexto decide. Quién creó el registro. Bajo qué regla. Para qué tarea. Con qué método de medición. Con qué frecuencia se actualiza. Qué omisiones se esperan. Qué valores se infieren. Qué valores los proporciona el usuario. Qué transformaciones ocurrieron en el camino. Sin ese contexto, la calidad se convierte en un estado de ánimo y el panel de control en diseño de interiores.

La IA hace que esta distinción sea más difícil porque los modelos tienen hambre de escala. La escala tiene un efecto seductor en las organizaciones. Un conjunto de datos grande puede hacer que la gente deje de preguntarse si las filas siguen significando lo que creen que significan. Más datos pueden cubrir el ruido estadísticamente, pero también pueden propagar una suposición errónea más lejos. Si una etiqueta la produjo un equipo sobrecargado, un millón de etiquetas puede darte una medida muy grande de sobrecarga. Si un campo vacío significa rechazado en un sistema y desconocido en otro, fusionarlos crea una categoría que debería llevar un chaleco de advertencia.

La vieja frase basura entra, basura sale sigue siendo útil, pero es demasiado optimista. Los sistemas modernos pueden convertir la basura que entra en resultados seguros, colas priorizadas, cartas automatizadas, puntuaciones de riesgo, informes de gestión y comentarios de formación que alimentan al siguiente modelo. La basura ya no sale educadamente. Circula, aprende el organigrama y se sienta en los comités de dirección.

El valor predeterminado que se convirtió en política

Muchos fallos de datos comienzan con un valor predeterminado. En blanco se convierte en falso. Ausente se convierte en cero. Desconocido se convierte en riesgo bajo. Sin respuesta se convierte en consentimiento. La última dirección conocida se convierte en la dirección actual. El registro más reciente se convierte en el mejor registro. Una nota de texto libre se convierte en una etiqueta porque alguien tenía que publicar el panel de control. Los valores predeterminados no son malos. Los sistemas necesitan valores predeterminados. El problema es cuando los valores predeterminados se convierten en política sin ser nombrados como política.

Un valor predeterminado es una decisión sobre la incertidumbre. Dice lo que la organización hará cuando no sabe. Esa decisión puede ser inofensiva en un flujo de trabajo de bajo impacto e inaceptable en uno de alto impacto. Si una preferencia de marketing está en blanco, un valor predeterminado prudente puede simplemente evitar enviar un mensaje. Si un campo de elegibilidad para prestaciones está en blanco, tratarlo como no puede denegar el apoyo. Si un campo de alergias clínicas está en blanco, tratarlo como ninguna no es una decisión de datos. Es un día muy malo que llega temprano.

Una buena gobernanza de datos obliga a sacar a la luz los valores predeterminados. Distingue entre desconocido, no aplicable, no recopilado, rechazado, pendiente, estimado, heredado, inferido y verificado. Estas categorías parecen tediosas hasta que la alternativa convierte una celda en blanco en autoridad. Un sistema que no puede representar la incertidumbre a menudo hará que la incertidumbre desaparezca fingiendo resolverla. Esto es eficiente de la misma manera que barrer cristales bajo una alfombra es eficiente. El suelo está limpio. El pie discrepa más tarde.

La prueba práctica es sencilla: si un revisor pudiera ver dónde actuó el valor predeterminado. Si una recomendación del modelo, una ruta de flujo de trabajo o una métrica del informe depende de un valor predeterminado, el registro debería mostrarlo. Si el valor predeterminado cambia, los resultados anteriores deberían seguir siendo interpretables. Si la gente no está de acuerdo con el valor predeterminado, debería haber un responsable. De lo contrario, la organización no ha automatizado una regla. Ha automatizado una suposición que evita el contacto visual.

Las etiquetas mal puestas son política silenciosa

Las etiquetas merecen una sospecha especial porque a menudo parecen más objetivas de lo que son. Fraude, alto riesgo, elegible, conforme, urgente, mala calidad, satisfecho, inseguro, resuelto. Estas palabras comprimen el juicio humano, la política, el hábito, los incentivos, la presión del tiempo y a veces el prejuicio institucional en un campo lo bastante corto para un modelo. La etiqueta viaja entonces como si fuera un hecho. Cuando llega al entrenamiento, el argumento que la creó normalmente ya se ha ido a casa.

Una etiqueta puede ser incorrecta porque la persona cometió un error. También puede ser incorrecta porque la instrucción era ambigua, la política cambió, a la persona revisora le faltaba contexto, la categoría era demasiado amplia, la herramienta fomentaba la prisa o la organización recompensaba un resultado concreto. Una etiqueta puede ser coherente y aun así codificar una mala práctica. La coherencia no es una virtud. Es mera repetibilidad, y la repetibilidad puede repetir la necedad con admirable disciplina.

Para la IA, las etiquetas débiles se convierten en algo más que ruido en los informes. Se convierten en el objetivo que el modelo aprende. Si las decisiones anteriores estuvieron influidas por un acceso desigual, sesgos históricos, malos incentivos o registros incompletos, el modelo puede aprender el tejido cicatricial de la institución y llamarlo predicción. Eso no hace que el modelo sea malintencionado. Hace que el objetivo de entrenamiento esté insuficientemente examinado. Culpar solo al algoritmo es atractivo porque los algoritmos no asisten a las evaluaciones de rendimiento.

Una mejor práctica de etiquetado no tiene nada de glamuroso. Escribir directrices. Registrar la identidad o el rol de la persona revisora cuando proceda. Capturar el desacuerdo. Hacer muestreos de calidad. Conservar ejemplos de casos límite. Revisar las etiquetas tras los cambios de política. Separar las etiquetas creadas para operaciones de las creadas para entrenamiento. Nombrar la incertidumbre. Permitir que las personas revisoras digan no puede determinarse. Esta última opción es sorprendentemente radical en organizaciones que prefieren columnas ordenadas a la duda honesta.

La duplicación no es solo desperdicio de almacenamiento

Los registros duplicados parecen un problema de almacenamiento hasta que se encuentran con una persona. Entonces se convierten en citas perdidas, elegibilidad incorrecta, historial fragmentado, incorporación repetida, facturas múltiples, puntuaciones de riesgo contradictorias y cartas que se dirigen a un ser humano como si fueran tres clientes. La base de datos puede pensar que tiene más registros. La persona experimenta que la institución no la reconoce. Esa es una categoría diferente de defecto.

La identidad es especialmente difícil porque el mundo real es desordenado. Las personas cambian de nombre, dirección, empleador, médico, escuela y estructura familiar. Las empresas se fusionan. Los activos se mueven. Los dispositivos se reemplazan. Los departamentos renombran programas porque, al parecer, al mundo le sobraba confusión. Las reglas de coincidencia necesitan humildad. Si son demasiado estrictas, la misma persona se divide en varios registros. Si son demasiado laxas, personas distintas se fusionan en una única ficción institucional. Ambos errores causan daño.

Los sistemas de IA amplifican los problemas de identidad porque dependen de un contexto ensamblado. Un resumen de caso puede omitir antecedentes relevantes porque los registros estaban divididos. Una puntuación de riesgo puede exagerar la exposición porque los duplicados se contaron dos veces. Una recomendación puede citar un registro que pertenece a otra persona tras una fusión demasiado agresiva. La recuperación puede mostrar el archivo equivocado porque los identificadores se reutilizaron. El modelo se convierte en la cara visible de una capa de identidad que estaba discretamente enferma.

Una buena gobernanza de la identidad da a los duplicados un proceso, no solo una campaña de limpieza. Define la confianza en la coincidencia, los umbrales de revisión humana, la autoridad de las fuentes, los derechos de fusión y desfusión, las pistas de auditoría, las obligaciones de notificación y las vías de corrección. Lo más importante es que trata la desfusión como una operación de primera clase. A las organizaciones les encanta fusionar porque parece ordenar. La desfusión es donde aprenden si ordenar rompió la realidad.

La obsolescencia es un problema de gobernanza

Los datos no se mantienen verdaderos porque nadie los haya tocado. Algunos hechos se deterioran. Direcciones, situación laboral, estado de la cuenta, normas legales, condiciones clínicas, consentimiento, niveles de riesgo, posiciones de valores, elegibilidad para servicios, propiedad, calibración de dispositivos, estado de proveedores. Un valor obsoleto puede superar la validación a la perfección. Tiene el tipo correcto, el código permitido y la apariencia profesional. Sigue siendo incorrecto hoy.

La obsolescencia es peligrosa porque los sistemas suelen tratar la ausencia de actualización como evidencia de estabilidad. En muchos ámbitos, el silencio significa que nadie comprobó. Una fuente de datos puede haber fallado. Un cliente puede no haber tenido motivo para iniciar sesión. Un registro público puede ir con retraso. Un sensor puede estar desconectado. Un departamento puede seguir usando el extracto del trimestre pasado porque el trabajo de actualización pertenece a una persona que ahora está de vacaciones. Los datos no se volvieron actuales por sentarse educadamente en una base de datos.

Cada campo importante necesita un contrato de frescura. ¿Cuánta antigüedad puede tener este valor para este uso? ¿Qué fuente lo confirma? ¿Qué ocurre cuando caduca la frescura? ¿Puede el flujo de trabajo continuar con una advertencia, requerir revisión humana, consultar una fuente en vivo o detenerse? La frescura debe depender del propósito. Una dirección postal para un boletín puede tolerar más antigüedad que una dirección utilizada para notificaciones legales. Un indicador de riesgo para operaciones diarias no puede vivir en el mismo calendario que los informes anuales.

Los contratos de frescura también ayudan a la evaluación de la IA. Cuando un modelo falla, los equipos suelen preguntarse si el modelo entendió los datos. Primero deberían preguntarse si los datos seguían vivos. Un registro obsoleto pero válido es una trampa especialmente desagradable porque supera las comprobaciones técnicas y falla en la realidad. La realidad, como siempre, registra menos incidencias de las que nos gustaría.

El modelo carga con la culpa del archivo

Cuando el resultado de la IA es malo, el modelo es el sospechoso más fácil. Es visible, caro, nuevo y a veces maravillosamente arrogante. Pero muchos resultados solo son tan sólidos como los registros que pueden ver. Un modelo al que se pide resumir un archivo incompleto producirá una incompletitud pulida. Un modelo al que se pide clasificar casos a partir de etiquetas inconsistentes aprenderá la inconsistencia con excelente porte. Un modelo al que se pide recuperar una política de una base de conocimiento obsoleta citará el pasado como si todavía tuviera acceso a la oficina.

Esto importa porque las correcciones centradas en el modelo pueden hacer perder el tiempo. El reentrenamiento no reparará un consentimiento ausente. Una ventana de contexto más amplia no arreglará identidades duplicadas. Un mejor prompt no restaurará un significado eliminado. Más evaluación no ayudará si el conjunto de pruebas arrastra las mismas etiquetas rotas que la producción. El modelo puede necesitar aún trabajo. Pero la capa de datos debe investigarse como un sospechoso con medios, motivo y una larga historia.

También hay una conveniencia política en culpar al modelo. Si el modelo tiene la culpa, la solución pertenece al equipo de IA. Si los datos tienen la culpa, la solución puede pertenecer a operaciones, legal, políticas, producto, atención al cliente, gestión de registros, proveedores y dirección. Esa es una mesa más grande. Las mesas más grandes producen más puntos del orden del día. Algunas organizaciones prefieren una mesa más pequeña y una explicación peor.

Una revisión seria de incidentes empieza por tanto antes. Qué fuente aportó el dato. Si estaba actualizada. Si estaba permitida. Si se preservó el significado. Si la etiqueta era válida para este propósito. Si el emparejamiento de identidades se comportó. Si actuó un valor por defecto. Si una corrección humana llegó al sistema posterior. Si el conjunto de evaluación incluía este tipo de fallo. Solo después de esas preguntas debería invitarse al modelo a defenderse. Puede seguir siendo culpable. No debería estar solo.

La reparación tiene que llegar a la fuente

Muchas organizaciones tienen procesos de corrección que arreglan el caso visible pero no el sistema de datos. Un agente de soporte actualiza la dirección para la carta de hoy, pero el registro maestro sigue siendo antiguo. Un trabajador social anula la elegibilidad, pero el campo ausente sigue ausente. Un médico corrige un resumen, pero la regla de extracción sigue produciendo el mismo error. Una nota de atención al cliente dice que se ignore el valor anterior, que es una forma valiente pero frágil de gobernar una base de datos.

La reparación debe viajar río arriba. Si se encuentra un error en el punto de uso, la corrección debería llegar a la fuente autoritativa o al menos crear un estado reconciliado con evidencia. El sistema debería saber si el arreglo es local, temporal, disputado, verificado o estructural. Una corrección que no puede propagarse se convierte en otro dato malo. Muy eficiente, en el sentido más sombrío.

La ruta de reparación también debería proteger a las personas de convertirse en administradores de datos no remunerados de las instituciones. Es razonable pedir a alguien que aporte una información que falta una vez. No es razonable obligarle a corregir el mismo registro en cinco canales porque los sistemas de la organización disfrutan de demasiada independencia. Cuando las personas aportan datos repetidamente y la institución los olvida repetidamente, el problema no es la fricción del usuario. Es un fallo de memoria institucional.

Una buena reparación genera aprendizaje. Si muchas correcciones afectan al mismo campo, el formulario de recogida puede no ser claro. Si se producen muchas separaciones tras un cambio en la regla de coincidencia, el umbral es incorrecto. Si una etiqueta se discute a menudo, la directriz necesita revisión. Si los registros obsoletos provocan incidentes, faltan contratos de actualización. La calidad de los datos mejora cuando la corrección se trata como evidencia, no como una molestia.

Los datos incorrectos no son moralmente neutros

Es tentador tratar la calidad de los datos como una cuestión de trastienda. Los registros son caóticos, sí, pero todas las organizaciones tienen registros caóticos. Eso es cierto del mismo modo que todos los edificios tienen polvo. La cuestión es si el polvo está en una estantería o dentro del sistema de ventilación. Cuando los datos incorrectos impulsan decisiones automatizadas, trabajo priorizado, resultados de IA, informes, cumplimiento, pagos o servicios públicos, dejan de ser tareas domésticas de trastienda. Se convierten en una forma de ejercer el poder.

Eso no significa que todo error sea un escándalo. Las instituciones serias pueden cometer errores. La cuestión moral es si los errores son visibles, corregibles y se evita que se multipliquen. Un sistema de mantenimiento de registros que oculta la incertidumbre, resiste la corrección, castiga a la persona afectada con pruebas repetidas y sigue utilizando errores derivados no es simplemente desordenado. Es injusto de forma duradera.

No existe una cura única. El trabajo con datos es local, específico de cada dominio y ocasionalmente humilde. Pero la postura es clara. Trate los campos importantes como decisiones con responsables. Haga que la incertidumbre sea representable. Mantenga la procedencia cerca. Vincule la actualización al propósito. Audite las etiquetas. Gobierne la identidad. Propague las correcciones. Mida la carga de reparación, no solo la velocidad de procesamiento. Cuando la IA esté implicada, pruebe la ruta de datos con la misma exigencia que la ruta del modelo. Los registros no son decorado. Son parte de la maquinaria.

La hoja de cálculo no gritó, porque las hojas de cálculo rara vez lo hacen. El sistema hizo lo que hacen los sistemas: convirtió suposiciones silenciosas en consecuencias más ruidosas. La lección no es que todos los datos deban ser perfectos antes de empezar a trabajar. Eso acabaría con la civilización, o al menos con la planificación del martes. La lección es que los datos deficientes no deberían poder actuar con autoridad mientras sigan siendo baratos, invisibles y un problema de otro. La violencia lenta se vuelve más lenta cuando nadie la nombra. Se vuelve más pequeña cuando el registro finalmente tiene que responder por sí mismo.