Un agente de RR. HH. no debería necesitar otra copia de Workday. La federación mueve el riesgo a la conexión
La federación de Workday de Databricks, en beta, y el lakehouse de Google leen los datos en el lugar. Eso elimina la copia y mueve el control al usuario de integración.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
¿Cuántas copias de sus datos de nómina existen hoy? La respuesta honesta en la mayoría de las grandes empresas incluye la extracción al data warehouse, el mart de analítica de la plantilla, una hoja de cálculo que alguien exportó para una reorganización y una copia de seguridad de cada una. Los agentes de IA amenazan con añadir más: un índice aquí, una caché allá, un almacén de memoria que nadie planificó.
Dos anuncios del 8 de octubre apuntaron en la dirección contraria. Databricks lanzó la federación de Workday Data Connect en beta, que permite a Unity Catalog consultar las tablas de RR. HH. y finanzas de Workday sin ingerirlas. Ese mismo día, Google dijo que Gemini puede leer “directamente de Salesforce Data 360, SAP y Workday sin copiar datos”, sin dar un estado de disponibilidad. Cuando dos plataformas convergen en el mismo patrón para el mismo sistema de registro, vale la pena entender qué cambia el patrón.
Cómo funciona la conexión de Databricks
Del lado de Workday, un administrador comparte las tablas aprobadas de RR. HH. y finanzas a través de Workday Data Cloud y otorga a un Workday Integration System User, el ISU, acceso de lectura a ellas. Del lado de Databricks, un administrador crea una conexión OAuth y un catálogo externo en Unity Catalog. Unity Catalog lee los metadatos de las tablas del catálogo Iceberg REST de Workday, y el cómputo de Databricks lee los datos del almacenamiento gestionado de Workday. Databricks dice que el conector “no ingiere ni copia datos en Databricks”. El acceso es de solo lectura, y Workday sigue siendo el sistema de registro.
A partir de ahí, las tablas se comportan como cualquier otro dato gobernado: permisos de catálogo, esquema y tabla, linaje y auditoría en Unity Catalog, y preguntas en lenguaje natural a través de Genie, como el crecimiento de la plantilla por centro de costes o la rotación por región y familia de puestos.
Requiere un workspace de Unity Catalog con Databricks Runtime 19 o posterior, Workday Data Connect habilitado en el tenant, y que un administrador del workspace active la beta.
| Pregunta | Copia en la plataforma | Federar en el lugar |
|---|---|---|
| Dónde residen los datos | Un segundo almacén que debe asegurar | El almacenamiento gestionado de Workday |
| Quién decide qué es visible | Los permisos del pipeline y del warehouse | El uso compartido de Workday y el rol del ISU, luego los permisos de Unity Catalog |
| Eliminación y retención | Debe repetirse en la copia | Siguen el origen |
| Frescura | A partir de la última carga | Actual, sin garantía declarada |
| Coste principal | Almacenamiento y pipelines | Cómputo por consulta |
El usuario de integración se convierte en el techo
La federación concentra la autoridad en un solo lugar: el rol de lectura del usuario de integración. Todo lo que el ISU puede leer es lo máximo que cualquier analista, dashboard o agente aguas abajo podrá ver a través de esta conexión. Eso convierte el rol del ISU en la decisión de acceso más importante del diseño, y debería revisarse como tal, con RR. HH. y privacidad en la sala.
Por debajo del techo, el artículo describe permisos en Unity Catalog, a nivel de catálogo, esquema y tabla. No dice cómo se traslada la seguridad por persona de Workday, como que un manager vea solo a sus subordinados. Hasta que Databricks lo documente, planifique como si los permisos de Unity Catalog, los filtros de fila y las máscaras de columna fueran los únicos controles por usuario aguas abajo. La compensación, las calificaciones de desempeño y la baja médica necesitan máscaras antes de que alguien apunte un agente de lenguaje natural al catálogo, porque una pregunta como “¿quiénes son las personas mejor pagadas de este equipo?” es fácil de formular. En el ámbito europeo, las tablas de RR. HH. a menudo contienen categorías especiales de datos personales según el artículo 9 del RGPD (Reglamento (UE) 2016/679); entre otras, datos de salud, afiliación sindical y datos biométricos. Eso añade exigencia a esas máscaras.
Sin copia no significa que no haya copias
La federación elimina la copia masiva. No elimina las más pequeñas que crean los agentes: resultados de consultas, respuestas de Genie compartidas en un canal, la memoria de un agente sobre el análisis de rotación de la semana pasada, logs de prompts que contienen nombres. Esas son exactamente las copias que describimos cuando argumentamos que la custodia es la primera pregunta. Necesitan sus propias reglas de retención.
Vale la pena anotar dos límites antes del primer piloto. Los datos aún se mueven para su procesamiento: el cómputo de Databricks lee del almacenamiento de Workday, así que dónde se ejecuta el workspace importa para dónde se procesan los datos personales. Y la federación lee el estado actual. Las preguntas sobre tendencias a lo largo de años necesitan historial, algo que el artículo no aborda y que aún puede requerir snapshots.
La federación es el valor por defecto correcto para los sistemas de registro, y Workday es un buen punto de partida porque el coste de una copia extra de datos de RR. HH. es muy alto. Cambia la revisión en lugar de terminarla: de “¿cómo aseguramos la copia?” a “¿qué tan estrecha es la conexión y quién la revisa?”