Publicar entre varios, sin perder trabajo

¿No te ha pasado que algo que publicaste en el servicio la semana pasada, a la siguiente ya no está?

No te pasa solo a ti. Y casi nunca es negligencia: el equipo no siempre puede avisarse en tiempo real. Surge un cambio urgente, o simplemente se olvida, porque todos llevamos varias cosas encima. Nadie borró nada a propósito. Alguien publicó desde una copia local que ya no era la última. Y ahí está el problema: el método dependía de que alguien se acordara.

«¿Quién publicó esto, cuándo, y cómo volvemos a como estaba antes?»

Que publiquen varias personas sobre el mismo tablero es lo normal en cuanto el equipo de BI deja de ser una sola persona. El primer instinto me llevó a buscar la configuración que lo iba a resolver. Lo investigué a fondo, y lo que encontré fue otra cosa: ninguna herramienta arregla un equipo que no ha acordado cómo trabaja. Lo que hace la herramienta es hacer cumplible el acuerdo.

Así que este artículo va en ese orden. Primero la metodología —cinco acuerdos y un protocolo de publicación—, y después las herramientas que la sostienen con licencia Pro, sin capacidad avanzada (Fabric, Premium, PPU) y sin rol de administrador del tenant. OJO, ser administrador/a de tu área de trabajo no cuenta. Incluye también detalles que me encontré en el camino y un par de conclusiones que di por firmes en mi primer análisis que ya no lo son.

Resumen

Power BI publica bajo el principio de «la última escritura prevalece». No hay detección de conflictos nativa: si publicas a partir de una versión desactualizada, el trabajo del otro desaparece sin aviso.
Cinco acuerdos: fuente única, un solo autor a la vez, todo cambio deja rastro legible, publicar es un acto anunciado, y toda restauración tiene dueño y dos pasos.
El protocolo por publicación son cinco pasos en orden obligatorio: bloquear → editar y guardar → liberar con comentario → publicar → avisar.
La red de seguridad que el equipo cree tener viene desactivada: el historial de versiones del modelo exige dos ajustes y una primera apertura en modo edición. Y guarda solo cinco versiones del modelo, no del reporte.
Herramienta principal con licencia Pro: el archivo que se usa en producción debe estar en una biblioteca documental corporativa (SharePoint, Teams, o el equivalente de repositorio de tu organización) con versionado y bloqueo de edición. Con una advertencia que casi nadie menciona: ese historial no es ilimitado.
Si tu equipo puede trabajar con .pbip + repositorio Git, no exige capacidad avanzada y es lo único que previene la pérdida, en lugar de solo permitir recuperarla.

Sección 01El fallo no es técnico, es de coordinación

La restricción que lo condiciona todo

Antes de tocar ninguna configuración conviene ser honesto/a del todo. La restricción es esta: Power BI publica bajo el principio de «la última escritura prevalece», y no detecta conflictos en ningún nivel de licencia. Da igual si estás en Pro o en una capacidad Fabric: si publicas sobre una versión desactualizada, el trabajo del otro desaparece y nadie te avisa.

No es un detalle técnico. Es lo que descarta lo que parece evidente, tratándose de una plataforma tan completa —esperar a que Power BI traiga esto habilitado por defecto—, y obliga a que la protección la ponga el equipo. Si tienes capacidad Fabric, la sección 05 se te queda corta y deberías ir directo/a a la integración Git: previene los conflictos de verdad. Pero los cinco acuerdos de la sección siguiente te aplican igual, porque Git tampoco decide por ti quién puede restaurar ni qué se escribe en cada confirmación.

Nadie hizo nada mal. El modelo de publicación simplemente no detecta que la base de B ya era vieja.

Fíjate en lo que no falló ahí: ni una licencia, ni un permiso, ni una configuración. Falló que dos personas dieron por hecho que su copia local era la última, y que nadie había acordado cómo se evita eso. Por eso este artículo empieza por los acuerdos y no por los ajustes.

Lo que el equipo necesita de verdad

En la práctica, antes de evaluar nada me pareció conveniente escribir las cinco necesidades concretas a las que me enfrentaba:

Necesidad	Qué significa en la práctica
Autoría	Saber qué persona publicó una versión determinada.
Marca temporal	Fecha y hora exacta de cada publicación.
Diferenciación	Distinguir qué modificó cada quien cuando dos personas tocan el mismo artefacto.
Recuperación	Volver a un estado anterior estable ante una publicación defectuosa.
Prevención	Evitar publicar sobre una versión desactualizada y borrar el trabajo del otro sin advertencia.

Antes de seguir

Mucha gente asume que Power BI guarda un historial de cambios «por si acaso». Lo guarda, pero no de forma automática ni visible por defecto en un espacio de trabajo compartido. Realmente hacen falta tres cosas:

El ajuste de organización que permite editar modelos de datos en el servicio, habilitado por el administrador del tenant. Si no está habilitado, la opción no aparece para nadie.
El ajuste del área de trabajo. En Mi área de trabajo viene activado; en un área colaborativa —la que usa tu equipo— hay que marcarlo a mano en su configuración.
Que alguien haya abierto el modelo en modo edición en la web al menos una vez. Hasta ese momento el panel de historial está vacío, y lo publicado antes no se recupera.

Traducido a método: encenderlo es una tarea de puesta en marcha del equipo, con responsable y fecha, no algo que se descubra el día del incidente. Los detalles y sus límites, en la sección 05.

Sección 02Cinco acuerdos, antes de tocar una sola configuración

Esto es lo que escribimos entre las dos personas que publicábamos, en una página, antes de evaluar ninguna herramienta. Si te llevas solo una sección del artículo, que sea esta: las herramientas cambian cada trimestre, los acuerdos no.

Acuerdo 1 · Hay un solo archivo en producción, y no está en tu escritorio

Lo primero: no existe «mi copia buena». Cuando vas a trabajar, lo primero es traerte la última versión de producción, no abrir la que tenías local el jueves. Parece obvio, pero recuerda: si tienes que acordarte de descargar, algún día no te acordarás.

Acuerdo 2 · Un solo autor a la vez sobre el mismo artefacto

Es un acuerdo de turnos, no una prohibición: tomas el archivo antes de abrirlo, lo tienes como mucho una jornada, y si te urge algo que tiene otro, pides el turno en lugar de abrir una copia aparte —esa copia aparte es justo el origen del problema que abre este artículo—. Si en tu caso esperar turno bloquea a alguien, te vas a ramas con proyecto .pbip y repositorio: lo trato en la sección 05.

Acuerdo 3 · Todo cambio deja un rastro que otra persona entienda

Cada publicación deja un comentario escrito por un humano para otro humano. «Actualización» no es un comentario. «Cambios» tampoco.

convención acordada

[área] resumen del cambio · motivo

[modelo]     nueva medida de margen acumulado · petición de dirección
[reporte]    página de detalle: filtro de fecha por defecto a mes actual
[correctivo] relación duplicada calendario–ventas · totales inflados

El prefijo entre corchetes es lo que después permite leer el historial en diagonal. El «motivo» es lo que te salva dentro de seis meses, cuando alguien pregunte por qué esa medida es así y el autor ya no esté en el equipo.

Acuerdo 4 · Publicar es un acto anunciado

Cuando algo llega al servicio, el equipo se entera. No por cortesía: porque el resto necesita saber que su copia acaba de quedar obsoleta. Un aviso automático en el canal del equipo con autor, fecha y comentario convierte el acuerdo en un hecho observable.

Acuerdo 5 · Recuperar tiene dueño y tiene dos pasos

Antes del primer incidente hay que tener respondido: quién decide restaurar, y qué significa restaurar exactamente.

Restaurar = recuperar la versión anterior del archivo y volver a publicarla. Escríbelo, porque en mitad de un incidente nadie lo deduce.

Los roles necesarios

No se trata de cargos, se trata de saber exactamente qué rol juega cada quien:

Dueño del artefacto: una persona por tablero. No es quien más lo edita: es quien decide en caso de duda y quien autoriza una restauración.
Autores: quienes editan y publican. Todos siguen el mismo protocolo.
Responsable de la configuración: quien se encargó de dejar los interruptores encendidos y de revisar cada cierto tiempo que sigan así.

La prueba de fuego del método

Un método de equipo no se valida cuando todo va bien. Se valida respondiendo esto sin mirar la documentación: si mañana publicas algo que rompe el tablero, ¿en cuánto tiempo se entera el equipo, quién decide volver atrás, y cuántos pasos hacen falta?

Si alguna de las tres respuestas es «depende», el acuerdo todavía no existe: es una intención.

Sección 03El terreno de juego: qué condiciona el método

El método es el mismo para cualquier equipo. Lo que cambia según el entorno son las herramientas que puedes usar para sostenerlo. Este era el mío.

El terreno de juego

Licenciamiento base: Power BI Pro (capacidad compartida)
Capacidad avanzada: Prueba temporal de Fabric, con fecha de caducidad
Origen de datos: Base relacional on-premise vía gateway
Autoría: Power BI Desktop, 2+ desarrolladores publicando
Rol administrativo: Administradora del área de trabajo, sin rol de tenant
Artefactos: Modelo semántico y reporte, en el mismo espacio de trabajo

La combinación importa más que cada dato por separado: Pro + gateway + sin rol de tenant descarta, de entrada, la mitad de lo que encontrarás si buscas «control de versiones Power BI» en internet.

Y dos características de esta arquitectura condicionan directamente todo lo que viene después:

El modelo y el reporte son artefactos distintos. En el servicio, el modelo semántico (tablas, relaciones, medidas) y el reporte (páginas, visualizaciones, formato) viven por separado y pueden cambiar de forma independiente. Cualquier mecanismo de versionado tiene que decirte cuál de los dos cubre.
El origen vía gateway introduce restricciones. Consumir datos de una base on-premise limita ciertas capacidades de edición en línea del servicio, y la edición en línea resulta ser el interruptor que enciende el historial nativo.

Sección 04Cómo elegir en tu contexto

Esta es la parte que quiero que analices con calma para decidir la forma correcta de resolver tu problema. La respuesta depende de tres preguntas, en este orden:

El destino no depende de cuál sea «el mejor», sino de qué restricción te ata primero.

Sección 05Las herramientas que sostienen el método

Una vez el equipo estableció sus acuerdos y definió qué herramientas puede usar y en qué contexto, la pregunta deja de ser «¿qué funcionalidad uso?» y pasa a ser «¿qué mecanismo hace cumplible cada acuerdo en mi entorno?». Evalué cuatro. Cada uno cubre una parte distinta y ninguno lo cubre entero, así que voy con el alcance real de cada uno, y tú decides cuál o cuáles encajan contigo y con tu equipo.

3.1 · Historial de versiones del modelo semántico

Funcionalidad nativa del servicio que conserva estados sucesivos del modelo semántico. Se abre desde el menú contextual del modelo en el área de trabajo, o desde Archivo > Historial de versiones cuando lo editas en la web.

Se guarda una versión cuando: guardas una manualmente (con descripción opcional), publicas o cargas un .pbix —y aquí se captura el estado anterior a la publicación—, abres el modelo en modo edición en la web, o restauras una versión previa.

Recreación del panel con datos de ejemplo. Es una lista de sellos de tiempo con un nombre al lado: suficiente para «quién publicó y cuándo», insuficiente para «qué cambió».

Esa ausencia de descripción es la que convierte al acuerdo 3 en imprescindible: si el rastro legible no lo pone el equipo en el comentario de cada versión, no lo pone nadie.

Otra cosa que me encontré al abrir el panel: entradas de hacía casi un mes, ahí listadas y disponibles. Me llamó la atención porque la documentación dice que restaurar más allá de 14 días no está soportado. Al mirarlo con calma, cuadra: lo dice, y añade que hoy el producto no aplica esa limitación. Me sirvió para entenderlo, no para confiarme —si algo funciona pero no está soportado, mañana puede dejar de funcionar sin aviso—. Lo desarrollo en la falla F10.

Cinco versiones, rotación FIFO. Si publicas a diario, tu «historial» dura una semana laboral.

Lo que necesitas para que funcione

Permisos de escritura y compilación (Write + Build) sobre el modelo. No está disponible con licencia gratuita.
El modelo debe estar en formato de metadatos mejorado. Si publicas encima un modelo con el formato antiguo, se borra todo el historial capturado.
El modelo debe tener habilitado el formato de almacenamiento de modelo semántico grande. La conversión ocurre automáticamente la primera vez que lo abres en modo edición en la web.
La edición de modelos en el servicio debe estar habilitada por el administrador del tenant y en el área de trabajo.

Corrección importante · esto cambió

Cuando hice el análisis, el historial de versiones exigía área de trabajo Premium, y esa fue la razón principal por la que lo descarté como solución permanente: mi capacidad era una prueba con caducidad.

Eso ya no es así. Microsoft extendió el historial de versiones a áreas de trabajo Pro, y la documentación actual ya no lista el requisito de capacidad Premium entre sus limitaciones. Si estás en Pro y no lo has mirado, ve a mirarlo: probablemente lo tengas disponible y no lo sepas.

Lo que no cambió: sigue siendo un máximo de cinco versiones, sigue cubriendo solo el modelo, y sigue sin ser un registro de auditoría.

Limitaciones que sí siguen en pie

Cinco versiones, con rotación ciega. No puedes fijar, proteger ni eliminar versiones concretas.
Cubre el modelo, no el reporte. Los cambios de páginas, visualizaciones y formato quedan fuera.
Restaurar versiones de más de 14 días no está soportado. Un matiz que conviene leer literalmente: la documentación añade que esa limitación no está siendo aplicada por el producto hoy. Traducción: puede empezar a aplicarse en cualquier momento, así que no construyas encima.
No es un registro de auditoría. No responde «quién hizo qué hace un mes».
Si desactivas el formato de almacenamiento grande, o cambia la clave de cifrado propia (BYOK) del área de trabajo, el historial se borra.

Sobre las descripciones hay un detalle que descubrí probando: la captura automática al publicar registra autor y marca temporal, pero sin descripción. Solo las versiones que guardas a mano admiten un texto. Así que si quieres que el historial diga algo, tienes que dejarlo tú, y hay una manera de encajarlo en el flujo normal de trabajo.

Cómo dejar descripción antes de publicar

Abre el modelo del tablero en el servicio (Open data model) y asegúrate de estar en modo Editing, no en Viewing.
File → Save to version history.
Escribe la descripción con una convención fija. La que uso:

convención de descripción

[Iniciales] - [Fecha] - PRÓXIMA publicación: resumen del cambio

[GPM] - 09/07/26 - PRÓXIMA publicación: nueva medida de margen acumulado

Cierra y publica desde Desktop con normalidad.
Para consultarlo: área de trabajo → el modelo semántico de ese tablero → los tres puntos (···) → historial de versiones.

La clave está en el «PRÓXIMA publicación» del paso 3. La versión que guardas es el estado anterior al cambio, y la descripción anuncia lo que viene: así, cuando dentro de un mes leas esa entrada, sabes exactamente a qué punto vuelves si la restauras.

Tiene un coste que conviene tener presente: las versiones manuales cuentan contra el límite de cinco, y al publicar se genera otra automática. Un ciclo completo puede consumir dos de las cinco ranuras, así que la ventana se agota al doble de velocidad. Por eso no lo hago en cada publicación: lo reservo para los cambios estructurales, los que de verdad querría poder deshacer.

3.2 · Registro de actividad y auditoría

El servicio registra eventos administrativos —incluidas las publicaciones— en un registro de actividad. Esta vía sí responde quién publicó y cuándo. Los eventos relevantes para trazabilidad de publicación son estos:

Operación	Qué significa
`CreateReport`	Publicación de un reporte desde Desktop al servicio.
`EditReport`	Edición de un reporte directamente en el servicio.
`UpdateDataset`	Actualización de la definición del modelo semántico.
`ApplyChangeToPowerBIModel`	Cambio aplicado al modelo desde la edición web (una medida, una relación…).
`SaveNewVersionForPowerBIModel`	Nueva versión guardada en el historial del modelo.
`RestorePreviousVersionForPowerBIModel`	Restauración del modelo a una versión previa.

Por qué se me cerró

La recuperación programática del registro de actividad (vía la API de administración o el cmdlet de PowerShell equivalente) es una API de administrador: exige pertenecer al rol de administrador de Fabric, o autenticarse con una entidad de servicio autorizada. Mi cuenta de trabajo no tenía ese rol, y el acceso al centro de administración devolvió un bloqueo explícito de permisos.

Decidí no pedirlo. Solicitar rol de administrador de la organización para resolver un problema de dos desarrolladores es pedir un privilegio mucho mayor que el necesario, y eso es una mala práctica de seguridad aunque te lo concedan.

Las tres limitaciones que hay que conocer antes de pelear por el acceso

Ventana corta. El registro de actividad conserva del orden de cuatro semanas. Si quieres histórico, tienes que extraerlo periódicamente y guardarlo tú.
Un día por solicitud. La API devuelve como máximo un día por llamada (fecha de inicio y fin deben ser el mismo día), con un tope de peticiones por hora. Cualquier extracción histórica es, sí o sí, un bucle programado.
No dice qué cambió. Registra el evento de publicación, no el contenido. No hay comparación de medidas, columnas ni visualizaciones.

La vía de menor privilegio que no había considerado

Si necesitas autoría y fecha pero no quieres —ni debes— pedir rol de administrador de Fabric, existe un camino intermedio: la búsqueda de auditoría de Microsoft Purview. Los eventos de Power BI aparecen ahí, la retención por defecto es bastante mayor que la del registro de actividad (del orden de 180 días en el nivel estándar, y hasta un año en el nivel premium para ciertas cargas de trabajo), y el acceso se delega mediante roles de auditoría específicos en lugar de con un rol administrativo completo sobre Power BI.

Es una petición mucho más fácil de justificar ante seguridad: «necesito leer registros de auditoría de esta carga de trabajo», no «necesito administrar el tenant».

3.3 · Control de código fuente con Git

Aquí está el error conceptual que cometí y que veo repetido en casi todo lo que se escribe sobre esto. «Git en Power BI» son dos cosas distintas, con requisitos distintos. Yo las traté como una sola y descarté las dos de golpe.

La integración del área de trabajo exige capacidad. El flujo de proyecto en el escritorio, no.

La diferencia práctica: al guardar el informe como proyecto (una carpeta de archivos de texto en lugar de un binario), el contenido pasa a ser legible y comparable. Un cambio en una medida se ve como un cambio de línea, con su autor y su mensaje de confirmación. Eso resuelve la necesidad de diferenciación que ninguna otra alternativa cubría.

La contrapartida es honesta y hay que decirla: exige que el equipo aprenda ramas, confirmaciones y resolución de conflictos, y la resolución sobre el archivo del modelo puede requerir intervención manual en un editor de texto incluso cuando los cambios afectan a elementos distintos. No es gratis. Es una inversión de proceso.

Es el único mecanismo que previene la pérdida de cambios en lugar de solo permitir recuperarlos después.

3.4 · Versionado de archivos en biblioteca documental

Guardar el archivo de origen del tablero en una biblioteca documental corporativa con versionado habilitado. Cada guardado genera una versión con autor, marca temporal y comentario opcional, y captura el archivo completo: modelo y reporte juntos.

Sus ventajas en un contexto Pro son difíciles de discutir: funciona sin capacidad avanzada, es independiente del tipo de origen de datos, cubre ambos artefactos, no requiere roles administrativos, y el bloqueo de edición (check-out obligatorio) serializa el trabajo de los desarrolladores.

Lo que casi nadie cuenta de este camino

Se suele presentar este historial como ilimitado. No lo es. Las bibliotecas documentales aplican límites de versión: el límite manual habitual son 500 versiones principales, y el modo automático que se despliega por defecto en bibliotecas nuevas adelgaza el historial con el tiempo —conserva las recientes, luego una diaria, luego una semanal— y lo que recorta se elimina de forma permanente, sin pasar por la papelera.

Súmale que cada versión de un .pbix es una copia completa del binario, no un incremento: un archivo de 300 MB versionado cien veces son 30 GB del almacenamiento del tenant.

Qué hacer: fijar la política de versiones de esa biblioteca en concreto en lugar de heredar la del sitio, y revisar el consumo cada cierto tiempo.

Novedad que mejora bastante este camino

Desde la actualización de mayo de 2026, Power BI Desktop tiene su propio panel de historial de versiones para archivos guardados en OneDrive o SharePoint. Se abre desde el menú superior izquierdo y lista las versiones con número, fecha de modificación, tamaño y autor; puedes abrir una versión anterior en otra ventana para comparar, sin sobrescribir la actual.

En la práctica esto elimina el paso de irse al navegador para consultar el historial, que era la fricción principal del método. Requiere tener activada la opción de guardado y compartición en OneDrive y SharePoint dentro de Desktop.

Sección 06El protocolo de publicación, paso a paso

Con las cuatro herramientas medidas contra las restricciones reales, el equipo adoptó el versionado del archivo de origen sobre una biblioteca documental corporativa como mecanismo principal, con el historial nativo como red de seguridad donde las condiciones técnicas lo permiten.

La razón no es que sea el mecanismo técnicamente superior —no lo es, Git lo supera— sino que es el único que sostenía los cinco acuerdos a la vez con lo que teníamos: funcionar con Pro, ser independiente del gateway, cubrir modelo y reporte, y no depender de privilegios que no teníamos.

De ahí sale el protocolo. Cinco pasos que se ejecutan igual siempre, los haga quien los haga, sea el cambio grande o de una línea.

Si publicas primero y guardas después, tu historial documenta un estado que nunca estuvo en producción.

Montarlo desde cero

El protocolo solo funciona si la biblioteca está configurada para sostenerlo. Son cuatro ajustes, se hacen una vez, y sin ellos todo lo anterior depende de que la gente se acuerde.

1 · Una biblioteca dedicada a los archivos de origen

No la mezcles con la documentación ofimática del equipo: sus políticas de versionado y su consumo de almacenamiento son muy distintos, y acabaréis aplicando a los .pbix reglas pensadas para actas de reunión.

2 · Versionado activado y bloqueo obligatorio

En la configuración de la biblioteca, activa el control de versiones y marca la opción que exige desproteger el archivo antes de editarlo (check-out obligatorio). Este segundo ajuste es el que convierte el acuerdo 2 en algo que se cumple solo: sin él, el bloqueo es voluntario, y lo voluntario no ocurre un viernes a las seis.

3 · Política de versiones fijada a mano

No heredes la del sitio. Entra en la configuración de esta biblioteca y decide cuántas versiones conservar y durante cuánto tiempo, sabiendo lo que ya vimos: lo que se recorta no vuelve. Y como cada versión de un .pbix es una copia completa, conviene revisar el consumo cada cierto tiempo en lugar de descubrirlo cuando alguien reciba un aviso de cuota.

4 · Acceso desde el escritorio, sin paso de copia

Cada autor debe llegar al archivo sin descargarlo a mano: o sincronizando la biblioteca como carpeta local, o abriéndolo y guardándolo directamente en OneDrive o SharePoint desde Power BI Desktop. Recomiendo lo segundo, porque es lo que habilita el panel de historial de versiones dentro del propio Desktop. Si para trabajar hay que acordarse de descargar, el acuerdo 1 se rompe el primer día con prisa.

Y una vez montada

Quedan dos tareas de puesta en marcha, con responsable y fecha, no «cuando podamos»:

Encender el historial nativo en cada modelo: abrirlo en el servicio en modo edición para disparar la conversión, y guardar una versión base con descripción. Donde la conversión falle, anótalo: ese modelo dependerá solo de la biblioteca.
Automatizar el aviso del paso 5. Un flujo que reaccione a la creación de una versión nueva en la biblioteca y publique en el canal del equipo el autor, la fecha y el comentario. Es lo que convierte el acuerdo 4 en un hecho observable y no en una cortesía.

Limitación reconocida, y hay que decirla en voz alta

El bloqueo de edición mitiga, pero no elimina, el riesgo de sobreescritura. Protege el archivo en la biblioteca; no protege el artefacto publicado. Un desarrollador que trabaje sobre una copia local desactualizada todavía puede publicar al servicio y pisar lo que había.

Quien te venda esto como «solución al problema de la sobreescritura» te está vendiendo humo. Lo que hace es reducir la frecuencia del accidente y garantizar que puedas volver atrás cuando ocurra. Cerrar la brecha del todo requiere Git.

Una variante que conviene conocer

Si subes el archivo al área de trabajo desde OneDrive o SharePoint en lugar de publicarlo, el servicio sincroniza los cambios del archivo automáticamente, del orden de una vez por hora. Eso elimina el paso «publicar» del protocolo y hace imposible el desfase entre archivo y artefacto.

No la adopté, y por razones que quizá no apliquen a tu caso: no controlas el momento exacto de la sincronización, lo cual es incómodo cuando publicas cambios que deben coordinarse con una ventana de refresco; y depende de un ajuste que el administrador del tenant debe permitir. Si tu equipo no tiene esa restricción de coordinación, es una simplificación real del proceso.

Sección 07Cuadro comparativo

Las cuatro alternativas frente a los criterios que importaban. Marco con «Pro» lo que funciona sin capacidad avanzada.

Criterio	Historial nativo	Registro de actividad	Git de área de trabajo	.pbip + Git local	Versionado documental
Funciona con Pro	Sí	Parcial (rol)	No	Sí	Sí
Compatible con gateway	Limitado	Sí	Sí	Sí	Sí
Cubre modelo + reporte	Solo modelo	Solo el evento	Sí	Sí	Sí
Registra autor y fecha	Sí	Sí	Sí	Sí	Sí
Indica qué cambió	No	No	Sí	Sí	Por comentario
Historial extenso	5 versiones	~4 semanas	Sí	Sí	Con límites
Previene sobreescritura	No	No	Sí	Sí	Mitiga
Sin rol de tenant	Requiere ajuste	No	Sí	Sí	Sí
Curva de adopción	Nula	Alta	Alta	Media-alta	Baja

Causa

Son dos planos distintos. Restaurar una versión anterior en la biblioteca deja el archivo bien y el servicio igual de roto que antes.

Solución

El protocolo de recuperación tiene dos pasos, siempre: restaurar en la biblioteca y republicar. Escríbelo en el documento de proceso, porque en mitad de un incidente nadie lo deduce.

Sección 09Checklist del equipo

Lo que tiene que estar cierto para decir que esto está montado, no a medias. Las primeras cuatro son de equipo; las demás, de configuración.

Los cinco acuerdos están escritos en una página que todos los autores han leído.
Cada tablero tiene un dueño con nombre, y todos saben quién es.
Hay una persona responsable de que los interruptores queden encendidos y sigan encendidos.
El protocolo se aplica sin excepciones por antigüedad, también para cambios de una línea.
La biblioteca de archivos de origen tiene versionado activado y check-out obligatorio.
La política de versiones de esa biblioteca está fijada explícitamente, no heredada.
Todos los autores trabajan contra la biblioteca. No existe una copia local «buena».
La convención de comentario de versión está escrita y acordada, con su prefijo de área.
El historial nativo está encendido en todos los modelos donde la conversión fue posible, con una versión base guardada.
Está documentado qué modelos no admitieron la conversión, y por qué.
El protocolo escrito incluye el orden: bloquear → editar → guardar → liberar → publicar → avisar.
El protocolo de recuperación incluye los dos pasos: restaurar en la biblioteca y republicar.
Existe un aviso automático al equipo cuando entra una versión nueva.
Alguien revisa el consumo de almacenamiento de la biblioteca cada cierto tiempo.
Está decidido —y anotado— qué se hará si en el futuro se necesita auditoría de hace tres meses.

Sección 10Glosario

Término	Qué significa
Modelo semántico	Estructura publicada en el servicio: tablas, relaciones, columnas y medidas. Es el motor de datos sobre el que se construyen los reportes.
Reporte	Artefacto de visualización: páginas, gráficos, filtros y formato. Se apoya en un modelo, pero es un objeto independiente.
Administrador (los tres)	No es un solo rol. Del área de trabajo: gestiona un workspace concreto, publica y da accesos; lo tiene mucha gente. De capacidad: gestiona una capacidad; muestra un menú reducido del portal de administración que se confunde con el rol completo. Del tenant (administrador de Fabric): gobierna toda la organización y es el único que puede consultar el registro de actividad y cambiar ajustes globales. Cuando en este artículo digo «sin rol de administrador», me refiero al tercero.
Gateway	Componente que permite al servicio en la nube consumir datos desde orígenes locales de forma segura.
Formato de almacenamiento grande	Modalidad de almacenamiento del modelo requerida para habilitar la edición en línea y el historial de versiones nativo. Su conversión puede fallar.
Formato de metadatos mejorado	Formato interno moderno del modelo. Sin él no hay historial de versiones, y publicar encima un modelo antiguo lo borra.
Registro de actividad	Registro de eventos administrativos de la plataforma, incluidas las publicaciones. Consultable por administradores de la organización.
Proyecto (`.pbip`)	Modalidad de guardado de un artefacto como carpeta de archivos de texto en lugar de un binario, que permite comparación línea a línea en control de código fuente.
Check-out / check-in	Bloqueo y liberación de un archivo en una biblioteca documental. El check-out impide que otro edite en paralelo.
Last write wins	Principio por el cual la última escritura prevalece, sobrescribiendo la anterior sin detección de conflicto.
Permiso de compilación (Build)	Permiso sobre el modelo necesario, junto al de escritura, para usar el historial de versiones.

Sección 11Lo que me llevé de todo esto

Seis ideas que aplico ahora en cualquier trabajo compartido, no solo en Power BI.

El método en su contexto primero, la herramienta después

Pasé un tiempo buscando la configuración o la herramienta correcta que arreglara esto, y realmente lo más importante pasó a ser ese acuerdo de equipo que no habíamos tenido antes, y un puñado de mecanismos que lo hacían cumplible. Cuando escribimos los cinco acuerdos, elegir el mecanismo fue lo más sencillo, de acuerdo a las condiciones reales.

Un acuerdo que depende de la memoria no es un acuerdo

«Nos avisamos antes de publicar» duró menos que un bocadillo en la puerta de un colegio. El aviso automático lleva funcionando desde entonces. Cada acuerdo necesita un mecanismo que lo sostenga sin voluntad diaria, o se convierte en una intención que alguien incumple sin darse cuenta un martes por la tarde.

Separa «recuperar» de «prevenir» desde el principio

Es lo que evitó que adoptara el historial nativo creyendo que resolvía la sobreescritura. Resuelve el otro problema. Si empiezas por el folleto, terminas ajustando tu problema a la herramienta que encontraste.

Un nombre no es un requisito

Descarté «Git» entero porque una de las dos cosas que se llaman Git exigía capacidad que no tenía. La otra no la exigía. Cuando descartes algo por licenciamiento, comprueba que estás descartando lo que crees.

Todo análisis tiene fecha de caducidad

Dos de mis conclusiones envejecieron en meses porque la plataforma se movió: el historial llegó a Pro y Desktop ganó su propio panel de versiones. No es un fallo del análisis, es la naturaleza de un producto que se actualiza cada mes. Lo que sí es un fallo es no ponerle fecha y no revalidarlo.

El mejor mecanismo no es el que gana la tabla

Git gana en casi todas las filas del cuadro comparativo. Y aun así no era nuestra respuesta, porque la columna que no aparece en ninguna tabla es «lo va a usar el equipo mañana». Un método mediocre que se practica vale más que uno excelente que se abandona a las dos semanas.

Sección 12Fuentes oficiales

Historial de versiones del modelo semántico learn.microsoft.com/power-bi/transform-model/service-semantic-model-version-history
Edición de modelos semánticos en el servicio learn.microsoft.com/power-bi/transform-model/service-edit-data-models
Formato de almacenamiento de modelo semántico grande learn.microsoft.com/fabric/enterprise/powerbi/service-premium-large-models
Acceso al registro de actividad de Power BI learn.microsoft.com/power-bi/guidance/admin-activity-log
Retención de registros de auditoría en Microsoft Purview learn.microsoft.com/purview/audit-log-retention-policies
Proyectos de Power BI Desktop e integración con Git learn.microsoft.com/power-bi/developer/projects/projects-git
Integración Git en Microsoft Fabric learn.microsoft.com/fabric/cicd/git-integration/git-get-started
Integración de Power BI Desktop con OneDrive y SharePoint learn.microsoft.com/power-bi/create-reports/desktop-sharepoint-save-share
Planificación del almacenamiento de versiones en bibliotecas documentales learn.microsoft.com/sharepoint/plan-version-storage
Actualización de un modelo semántico almacenado en OneDrive o SharePoint learn.microsoft.com/power-bi/connect-data/refresh-desktop-file-onedrive

¿Cómo se coordina tu equipo para publicar sobre los mismos artefactos? ¿Tenéis un sexto acuerdo que a mí me falta, o una falla que debería estar en el catálogo? Cuéntamelo en los comentarios y lo incorporo al artículo con tu crédito.

Glenda Piñero Muñoz

Especialista en Power BI y análisis de datos. Construyo modelos, y también los flujos de Power Automate que hacen que esos datos lleguen solos a quien los necesita: alertas, integraciones y entrega automatizada. Escribo sobre los problemas reales que me encuentro y cómo los resuelvo.