El propietario de datos que nadie asignó

El fallo que parece un problema de ingeniería

El sistema está construido, la canalización se ejecuta y la evaluación es aceptable. Luego el corpus se desvía: un sistema de origen cambia un campo, una carpeta se reorganiza, un conjunto de documentos deja de actualizarse porque la persona que lo mantenía se mudó a otro equipo. La calidad de las respuestas se deteriora durante semanas, y el equipo de ingeniería no puede solucionarlo, porque la solución no es código.

Nada en esta historia es difícil. Simplemente no tiene dueño.

Por qué la propiedad es la dependencia real

Una característica de inteligencia artificial construida sobre datos empresariales tiene una dependencia de personas fuera del equipo de construcción, y esas dependencias se comportan de manera diferente a las dependencias de software. No están versionadas, no fallan ruidosamente y cambian cuando la organización cambia. Tres de ellas accountan para la mayoría del riesgo de calendario.

Actualización. ¿Quién es responsable de que el corpus refleje el estado actual del negocio, con qué frecuencia y cómo alguien se daría cuenta si se detuviera?

Esquema. ¿Qué campos existen, cuáles están obsoletos y quién es informado cuando uno cambia de significado. Un campo renombrado es un fallo de recuperación silencioso, no un bloqueo.

Habilitación. El mapeo entre el modelo de permisos del sistema de origen y la lista de control de acceso del índice debe ser mantenido por alguien con autoridad sobre el sistema de origen. Eso rara vez es un ingeniero.

Hacerlo explícito

• Nombre a una persona, no a un equipo, para cada fuente de datos, y nombre a un respaldo. La propiedad no asignada es sin dueño.
• Escribe la frecuencia de actualización en el plan del proyecto como una dependencia con una fecha, para que una actualización detenida aparezca en el mismo lugar que una integración de API detenida.
• Acuerda un canal de alertas para los cambios de esquema antes de que comience la ingesta, no después del primer fallo silencioso.
• Pon la frescura del corpus en el mismo panel de control que la latencia y el costo, para que la decadencia de la calidad sea visible antes de que los usuarios la informen como un problema de calidad.
• Revalida la propiedad en cada reorganización. Los acuerdos de propiedad solo sobreviven mientras las personas que los firmaron.

Por qué vale la pena la documentación

Dos documentos cambian el resultado: una página de flujo de datos que nombra cada fuente, su propietario y su frecuencia, y un registro de riesgos que lista lo que el sistema puede hacer mal con la mitigación para cada uno. Ambos son aburridos, ambos toman una tarde, y ambos convierten una clase de problema que habría sido descubierto en el mes cuatro en un conjunto de decisiones que se pueden tomar en la semana uno.