Gobierno de Data Products en SAP BDC: acceso por solicitud
Qué cambia con el gobierno de Data Products en SAP Business Data Cloud (wave 2026.20): solicitudes, data stewards, acuerdos de acceso y cómo prepararlo.
Índice del artículo
Con la wave 2026.20 de SAP Business Data Cloud, cuyo despliegue SAP tenía planificado para el 23 de septiembre de 2026, llega el gobierno de Data Products: el acceso a un Data Product deja de ser algo que se concede “por detrás” y pasa a ser una solicitud que alguien revisa y que queda registrada. Si tu equipo BI va a compartir Data Products con otras áreas o plataformas, esto te afecta más de lo que parece.
Qué es exactamente
Según SAP, la nueva capacidad introduce un proceso estructurado y auditable para controlar quién accede a qué Data Product. Las piezas son:
- Solicitudes de acceso: quien quiere consumir un Data Product lo pide, y la petición se sigue, se revisa y se guarda.
- Área de Governance centralizada: el sitio donde los data stewards revisan las solicitudes entrantes y las aprueban o rechazan.
- Términos y condiciones que se pueden definir a nivel de dominio y a nivel de Data Product.
- Aprobación automática, pensada para dar acceso sin fricción en entornos de desarrollo y test.
- Acuerdos de acceso (access agreements): al aprobar, BDC convierte la solicitud en un acuerdo que registra quién pidió acceso, el motivo, el entorno de destino, los endpoints aprobados y la fecha de caducidad.
El detalle importante: aunque la aprobación sea automática, el acuerdo se genera igual. Es decir, puedes quitar fricción sin perder trazabilidad.
Por qué importa a un equipo BI
En BW estábamos acostumbrados a que la seguridad fuera autorizaciones de análisis y roles: técnica, fina y, casi siempre, gestionada por el propio equipo BI a golpe de ticket. Con los Data Products el problema cambia de escala. Un mismo producto puede acabar consumido desde Datasphere, desde una plataforma de terceros o desde otro tenant, y la pregunta ya no es solo “¿puede este usuario ver esta sociedad?”, sino “¿quién está usando este producto, para qué y hasta cuándo?”.
Ahí es donde un modelo por solicitud aporta valor:
- Auditoría sin Excel: el motivo y el entorno de destino quedan guardados junto a la aprobación.
- Caducidad: los accesos tienen fecha de fin, algo que en la práctica casi nunca se revisa cuando los permisos se conceden a mano.
- Responsabilidad clara: aprueba el data steward del dominio, no el administrador técnico que “tenía permisos para hacerlo”.
Cómo lo prepararía en proyecto
La herramienta es la parte fácil. Lo que hace que funcione es la organización previa. Este es el checklist que yo cerraría antes de activarlo:
| Decisión | Pregunta que hay que responder | Mi recomendación |
|---|---|---|
| Dominios | ¿Qué dominios de negocio tenemos y quién es su dueño? | Pocos y alineados con el negocio (Finanzas, Ventas, Operaciones) |
| Data stewards | ¿Quién aprueba en cada dominio y quién le sustituye? | Una persona de negocio con suplente, no solo IT |
| Términos y condiciones | ¿Qué uso está permitido? ¿Datos personales? | Texto corto a nivel de dominio; excepciones en el Data Product |
| Aprobación automática | ¿En qué entornos se aprueba sin revisión? | Solo desarrollo y test, nunca productivo |
| Caducidad | ¿Cuánto dura un acceso por defecto? | Plazos cortos y renovación explícita |
| Revisión periódica | ¿Quién revisa los acuerdos vigentes? | Revisión trimestral por dominio |
Dos consejos más:
- Empieza por un dominio piloto. Elige uno con pocos consumidores y un steward implicado. Verás rápido si los tiempos de aprobación son asumibles.
- Define un SLA de aprobación. Si una solicitud tarda dos semanas, la gente buscará atajos (extracciones, copias en un sandbox) y el gobierno se queda en papel.
Qué no resuelve (y qué preguntaría a SAP)
El gobierno de acceso decide quién puede consumir un Data Product. No sustituye a la seguridad a nivel de fila ni a la calidad del dato. En un grupo con varias sociedades, que alguien tenga acceso aprobado a un producto no significa que deba ver todas las sociedades que contiene.
Antes de diseñar el modelo definitivo, estas son las preguntas que yo llevaría a SAP o al partner:
- ¿Cómo convive este gobierno con los permisos a nivel de fila que ya tengamos en Datasphere?
- ¿Qué ocurre exactamente cuando un acuerdo caduca en cada tipo de consumidor?
- ¿Se pueden exportar los acuerdos para auditoría interna o para el delegado de protección de datos?
- ¿Aplica igual a los Data Products estándar de SAP y a los que creamos nosotros?
No tengo todavía respuesta verificada a estas preguntas, y precisamente por eso conviene hacerlas antes de prometer nada a auditoría.
Mi recomendación
Si ya estás compartiendo Data Products, no esperes a tener un incidente para ordenar el acceso. Nombra dueños y stewards por dominio, redacta unos términos y condiciones breves, limita la aprobación automática a desarrollo y test y arranca con un piloto. La configuración es lo de menos; ponerse de acuerdo sobre quién aprueba lleva semanas, así que empieza por ahí.