Gobierno del dato en GCP: el guardaespaldas de BigQuery

Daniela RBR
16 jun
16 Min. de lectura

Actualizado: 20 jun

"Saber es poder", es una antigua frase que hoy esta más vigente que nunca. Vivimos en la era del Big Data, y como dice Stephen Baker en su libro: «Los Numerati lo saben todo de ti». Pero cuando él escribió esto, allá por el 2008, hablaba de un grupo reducido de expertos. Hoy, casi 20 años después, se estima que hay más de 97 millones de profesionales trabajando en el mundo de los datos: un sector enorme, en auge, pero con escasez de talento. Al mismo tiempo, muchas empresas se volvieron altamente dependientes de los datos -las llamadas data-driven companies- lo que significa que manejan grandes volúmenes de información.

Dónde hay mucho dato, hay mucho poder. Como bien le dijo la tía May a Peter: «un gran poder conlleva una gran responsabilidad».

En esta nota te voy a mostrar:

Por qué es clave limitar el acceso a los datos.
Qué responsabilidades asumís al asignar permisos.
Cómo gestionar accesos en BigQuery cumpliendo con GDPR.
Cómo auditar quién dio accesos a qué, a quién y cuándo.

¿Por qué se debe limitar el acceso a los datos que se almacenan?

Limitar el acceso a los datos que almacenamos no es solo una buena práctica de seguridad o de gobierno del dato. Es también una obligación legal.

Desde 2018 —y plenamente en vigor desde 2023 en todos los sistemas europeos— rige en Europa el Reglamento General de Protección de Datos, más conocido como GDPR [link a la ley]. Esta ley establece que todas las empresas que procesan datos personales deben aplicar el principio de minimización: recolectar y exponer solo los datos necesarios, y solo a las personas que realmente los necesitan para su función.

El artículo 5 del GDPR establece los principios fundamentales que deben guiar el tratamiento de datos personales.

Artículo 5 – Principios relativos al tratamiento de datos personales: 1. (c) Adecuados, pertinentes y limitados a lo necesario en relación con los fines para los que se traten (“minimización de datos”); (e) Conservados de forma que permitan la identificación de los interesados durante no más tiempo del necesario para los fines del tratamiento (“limitación del plazo de conservación”); (f) Tratados de manera que se garantice la seguridad de los datos, incluyendo protección contra el tratamiento no autorizado o ilícito y contra su pérdida, destrucción o daño accidental (“integridad y confidencialidad”) 2. El responsable del tratamiento será responsable de y deberá demostrar el cumplimiento del apartado 1 ("responsabilidad proactiva"). [Artículo 5 - link]

En resumen, indica que los datos deben usarse con fines legítimos, ser limitados a lo estrictamente necesario, mantenerse actualizados, conservarse solo durante el tiempo que hagan falta y, sobre todo, protegerse adecuadamente contra accesos no autorizados.

Por otro lado, el artículo 32 se enfoca en la seguridad del tratamiento y exige que las empresas implementen medidas proporcionales al riesgo para garantizar la confidencialidad, integridad y disponibilidad de los datos. [Artículo 32 - link]

Y cuando mencionaba la parte de «una gran responsabilidad» me refería directamente a las consecuencias del incumlimiento de esta ley. El artículo 83 del GDPR establece el régimen de sanciones por incumplimiento de la normativa de protección de datos.

Artículo 83 – Condiciones generales para la imposición de multas administrativas 2. Las multas se impondrán según las circunstancias específicas del incidente, considerando factores como la gravedad, duración, carácter intencional, medidas correctivas y cooperación con la autoridad 4. Infracciones “menos graves” (e.g., obligaciones de los responsables según los artículos 8–11, 25–39, 42–43) pueden sancionarse hasta 10 millones € o el 2 % del volumen de negocio global, lo que sea mayor. 5. Infracciones “más graves” (e.g., los principios básicos del tratamiento, derechos del interesado, transferencia internacional de datos, incumplimiento de órdenes) pueden sancionarse hasta 20 millones € o el 4 % del volumen de negocio global, lo que sea mayor. [Artículo 83 - link]

Entonces, el incumplimiento se salda con multas que pueden llegar hasta 20 millones de euros o el 4 % del volumen global de facturación anual, lo que sea mayor. Definitivamente, mucho dinero.

¿Qué responsabilidad asumís cuando das acceso a datos en BigQuery?

El título de esta nota ya lo anticipa: no se trata solo de almacenar datos, también hay que custodiarlos y protegerlos, como un guardaespaldas. Quien administra accesos en BigQuery no solo decide quién puede consultar una tabla: también está asumiendo un rol clave en el cumplimiento legal, en la protección de datos sensibles y en la prevención de filtraciones.

En el apartado anterior mencioné el Artículo 5 del GDPR, que establece principios como la minimización de datos y la responsabilidad proactiva. En la práctica, esto implica que una empresa debe saber qué datos recolecta, justificar por qué los guarda y quién accede a ellos, y evitar almacenar o exponer más de lo necesario.En un entorno como BigQuery, esto se traduce en tener una estructura clara de datasets, definir accesos por proyecto o rol, y aplicar políticas de minimización tanto técnicas como organizativas.

También hablamos del Artículo 32, que convierte la seguridad en una obligación activa, no solo en una recomendación técnica. Esto exige limitar accesos con Row o Column Level Security, cifrar la información siempre que sea posible, tener respaldos, garantizar resiliencia, y auditar periódicamente la eficacia de estas medidas. Además, quien accede a los datos debe hacerlo bajo instrucciones claras y registradas.

En definitiva, dar accesos en BigQuery es una tarea técnica, sí, pero también una responsabilidad legal y ética. Por eso existe un rol específico para garantizar su cumplimiento: el data governance.

Jerarquía de recursos

Aunque BigQuery es un producto dentro de Google Cloud Platform (GCP), no vive aislado: su seguridad y sus accesos se rigen por la jerarquía de recursos de GCP [docu: jerarquías]. Es importante tenerla presente dado que los permisos se heredan hacia abajo.

En el caso de BigQuery, los niveles relevantes para otorgar permisos son:

Organización (opcional): acceso general a todos los proyectos, solo si la empresa está conectada a un dominio.
Proyecto: acceso a todas las APIs habilitadas, incluyendo BigQuery; suele ser el nivel donde se define el uso general.
Dataset: acceso a grupos de tablas; se puede controlar lectura, escritura, creación de vistas, etc.
Tabla: acceso granular; se puede permitir o restringir consulta, inserción, actualización.
Fila/Columna: control fino mediante Row-Level Security y Column-Level Security, útil para aplicar reglas dinámicas según el usuario.

Jerarquía de roles

Así como los recursos de BigQuery están organizados jerárquicamente, también lo están los roles y permisos [docu: roles y permisos]. Comprender esta jerarquía es clave para aplicar una política de seguridad efectiva y control de acceso basado en el principio de menor privilegio.

Roles básicos en GCP

En Google Cloud Platform existen tres roles básicos que definen el acceso general a un proyecto:

Rol	Detalle
Propietario (Owner)	Control total: puede crear, modificar y borrar recursos, administrar permisos IAM y facturación.
Editor	Crear, editar y eliminar recursos de todos los servicios, pero no puede administrar permisos ni facturación.
Visor (Viewer)	Solo permite ver recursos y metadatos dentro del proyecto. No puede hacer cambios.
Navegador (Browser)	Solo permite ver la jerarquía de proyectos y carpetas. No puede ver ni acceder a los recursos dentro del proyecto.

Los mismos podrán ser elegidos desde IAM al seleccionar "grant access" y elegir "Basics"

Para que una persona pueda encontrar y navegar un proyecto desde la consola de Google Cloud, es necesario asignarle un rol básico a nivel de proyecto, como Viewer o Browser. Estos roles permiten que el proyecto aparezca en su lista y sea accesible desde la interfaz gráfica [Consola de GCP].

En cambio, cuando le das a alguien acceso a un recurso específico en GCP, como BigQuery, puede usarlo solo si tiene el link directo a este recurso de dicho proyecto. Si no cuenta con este, al intentar entrar por su cuenta a la consola de GCP y buscar el proyecto no lo va a encontrar. El acceso existe, pero queda oculto.

Entonces, al darle accesos a personas (no aplica a cuentas de servicio) es fundamental combinar roles básicos con roles específicos, asegurando tanto el acceso técnico como la visibilidad en el entorno de trabajo.

Roles predefinidos en BigQuery

Los roles predefinidos son los que administran los Google Cloud servicios. Estos roles contienen los permisos necesarios para realizar tareas comunes para cada servicio determinado. En el caso de BigQuery, existen diversos roles asociados, los cuales se pueden englobar en 4 grupos:

Roles de datos: dataOwner, dataEditor, dataViewer, metadataViewer
Roles de ejecución: jobUser, user, readSessionUser
Roles de administración: admin, resourceAdmin, connectionAdmin, connectionUser
Rol compuesto: studioUser (varios servicios integrados)

Al igual que lo mencionado anteriormente, los mismos se pueden brindar desde la consola de IAM y se pueden encontrar fácilmente buscando por recurso.

Si nos enfocamos solo en los roles vinculados a la consulta o visualización de datasets y tablas en BigQuery, encontramos los siguientes (ordenados de mayor a menor poder):

Rol	Qué permite hacer
BigQuery Data Owner	🧱 Accede, modifica, y administra todos los datasets y tablas. Puede dar permisos sobre ellos.
BigQuery Data Editor	✍️ Puede leer, crear, actualizar y eliminar datasets y tablas, pero no gestionar permisos.
BigQuery Data Viewer	👁️ Puede consultar datos y metadatos, pero no modificar nada. No puede lanzar queries.
BigQuery User	🔧 Puede listar proyectos y ejecutar consultas si tiene acceso a los datasets.
BigQuery Job User	🏃 Puede lanzar jobs (como consultas), pero solo si ya tiene acceso a los datos.

Es fundamental entender los alcances de los roles de forma individual. Para que esto sea posible, la documentación oficial de google, cuenta con un índice de IAM roles y permisos para poder encontrar leer en detalle cada uno: índice de roles y permisos.

¿Cómo otorgar permisos a BigQuery y no morir en el intento?

El subtítulo de esta sección no está elegido al azar. En los últimos meses, dentro de mis tareas se sumó la gestión de permisos en GCP —principalmente sobre datos en BigQuery—, y aunque a simple vista parece una tarea sencilla, al meterse en detalle descubrís que tiene más complejidad de la que uno espera. Aun así, como todo en la vida, una vez que le encontrás el truco, todo empieza a ordenarse.

Tal como se explica en la documentación, otorgar permisos a alguien en IAM implica los siguientes tres componentes:

Principal: ¿es a una persona o una cuenta de servicio?
Rol: ¿qué tanto poder le vamos a dar?
Recurso: ¿con qué va a estar trabajando?

Paso 1: siempre dar rol de navegador

Tal como expliqué en el apartado anterior, es necesario otorgar un rol básico para que la persona sea capaz de encontrar el proyecto sin tener un link particular. Partiendo de la premisa que solo queremos que trabaje con BigQuery el rol apropiado básico será Navegador, de esta forma podrá buscar los recursos, ver la lista, pero al entrar a cualquier recurso le dirá que no tiene permisos.

Navegador (roles/browser) Acceso de lectura para navegar por la jerarquía de un proyecto, incluida la carpeta, la organización y la política de permisos. Este rol no incluye permiso para ver recursos en el proyecto. [link]

Este paso solo aplica para usuarios humanos, si es una cuenta de servicio no es necesario.

Paso 2: Definir accesos

Una vez que se garantiza que la persona pueda encontrar el proyecto, el siguiente paso es decidir a qué puede acceder exactamente. Acá es donde entra en juego el famoso Principio de Menor Privilegio, es decir, si necesita consultar una tabla, no hace falta que pueda ver o editar todas. Si solo necesita correr queries, no tiene por qué poder crear datasets.

En resumen, dar solo los permisos estrictamente necesarios para que una persona cumpla con su tarea, ni más ni menos. Para ello es clave definir el recurso y el rol.

Flujo de decisión: tipo de rol

Flujo de decisión: Acceso a Nivel Recurso

Paso 3: Dar accesos

Los árboles de decisión nos facilitan la tarea de tener claro qué permiso queremos otorgar y sobre qué recurso; el siguiente paso es hacerlo realidad.

Pero dar accesos puede ser igual —o incluso más— complicado que definirlos. No todos los permisos se otorgan de la misma manera: algunos se resuelven con un simple clic en IAM; otros requieren condiciones más finas o configuraciones específicas dentro de BigQuery.

Es ahí donde se empieza a jugar la diferencia entre dar acceso y dar acceso bien.

Accesos Generales: Asignar roles sin complicaciones

Cuando una persona necesita trabajar con todos los datos de un proyecto en BigQuery, lo más directo es asignar el rol desde el panel de IAM. Basta con hacer clic en “Grant access”, elegir el usuario o grupo correspondiente y asignarle el rol correspondiente.

Este tipo de acceso se aplica a todos los datasets, tablas y vistas dentro del proyecto, por lo que es ideal cuando se requiere una visión completa del entorno de datos.

Accesos Condicionales: permisos con reglas

No todos los accesos son blanco o negro. A veces necesitás dar permisos, pero bajo ciertas condiciones. Por ejemplo: que una persona pueda consultar datos solo en determinados horarios, hasta determinada fecha, dentro de un dataset en específico o solo si los recursos tienen una etiqueta específica. Aqui entran en juego las IAM conditions.

Las IAM Conditions (o condiciones de IAM) en Google Cloud permiten agregar reglas condicionales a las políticas de acceso, lo que te da un control más granular sobre quién puede hacer qué, cuándo y bajo qué condiciones.

Al momento de seleccionar el rol se debe agregar las condiciones (no aplica para roles básicos).

Hay dos maneras de hacerlo: utilizando el «Condition builder» o «Condition editor».

Si bien hay dos formas de definir estas condiciones, el "Condition builder" es la más amigable: ofrece una interfaz guiada para construir reglas simples sin necesidad de escribir código. Al elegir esta opción, lo primero que te pide es elegir el tipo de condición. Ahí vas a encontrar dos grupos principales:

Condiciones basadas en tiempo (Time-based conditions), que te permiten definir desde cuándo y hasta cuándo se aplicará el acceso. Esto es útil, por ejemplo, para otorgar permisos temporales a contratistas o para proyectos con fechas límite.
Condiciones basadas en recurso (Resource-based conditions), que permiten limitar el acceso según atributos del recurso, como su nombre (resource.name) o etiquetas (resource.matchLabels). Es la opción ideal si querés restringir el acceso a un dataset específico o a un subconjunto de recursos.

Por otro lado, el "Condition editor" permite trabajar directamente con expresiones escritas en CEL (Common Expression Language), una sintaxis más poderosa y flexible, ideal cuando necesitás combinar múltiples condiciones o aplicar lógica más compleja [link a la documentación]

Ejemplo:

resource.name == "projects/{project_id}/datasets/{dataset_id}" 
&& 
request.time < timestamp("2025-12-31T23:59:59Z")

Antes de cerrar esta parte, hay algunos detalles importantes que vale la pena tener en cuenta cuando trabajás con IAM Conditions o accesos más personalizados en BigQuery. Son pequeñas cosas que, si no las sabés, te pueden volver loco más adelante.

Evitá usar más de 12 operadores lógicos en una misma condición. Aunque no está documentado como un límite estricto, en la práctica puede hacer que la condición no se guarde o falle silenciosamente.
Si das acceso a una tabla específica, asegurate también de dar acceso al dataset que la contiene. Caso contrario, la persona podrá consultar la tabla (si tiene la ruta de la misma), pero no la verá listada ni podrá navegar hasta ella desde la consola.
Las condiciones no se aplican a roles básicos, como Viewer o Editor. Solo funcionan con roles personalizados o predefinidos compatibles.
Si usás etiquetas (labels) en condiciones, no podrás mezclar con otro tipo de condiciones, entonces puede que tengas que dar más de una vez el mismo rol de acceso. También tené en cuenta que deben estar correctamente aplicadas y sincronizadas en los recursos, de lo contrario la condición fallará y el acceso no funcionará.
Si das accesos con condiciones a varias personas al mismo tiempo, cuando edites una podes editar el de todas al mismo tiempo o no.
Y como buena práctica: documentá qué condiciones aplicás, cuándo y por qué, para que otras personas del equipo puedan entender la lógica de accesos (o para vos mismo, dentro de tres meses). Esto lo podes hacer mismo en la descripción.

Accesos Restringidos: proteger datos sensibles

En escenarios donde se necesita limitar el acceso a porciones dentro de una tabla —ya sea por filas, columnas o transformaciones— entran en juego los mecanismos de acceso restringido. BigQuery ofrece tres herramientas muy potentes para esto: Row-Level Security, Column-Level Security y Vistas autorizadas. Cada una cumple un rol distinto, y usarlas correctamente es clave para proteger los datos sin entorpecer el trabajo del equipo.

Column-Level Security (CLS)

CLS en BigQuery es una funcionalidad que te permite restringir el acceso a columnas específicas dentro de una tabla, sin bloquear el acceso a toda la tabla. Sirve para ocultar columnas sensibles según el perfil del usuario. Se aplican etiquetas (policy tags) a las columnas desde Data Catalog y se controlan los permisos sobre esas etiquetas. Así, dos personas pueden consultar la misma tabla y ver distintos niveles de detalle.

Para poder aplicar CLS se deben cumplir los siguiente requisitos:

El proyecto debe formar parte de una organización en GCP.
Tener habilitada la Data Policy API.
Tener permisos como:
- Policy Tag Admin para gestionar las etiquetas (configurarlo desde IAM).
- Fine-Grained Reader o Masked Reader sobre las etiquetas.

Link: documentación CLS

Row-Level Security (RLS)

Permite que cada persona vea solo ciertas filas de una tabla, según reglas definidas (por ejemplo, customer_id = 19). Es útil para mantener una sola tabla compartida entre muchos usuarios, sin exponer todo su contenido.

Este tipo de permisos se configura dentro de BigQuery mediante código, Por ejemplo:

CREATE ROW ACCESS POLICY only_customer_19
ON `mi_proyecto.mi_dataset.transactions`
GRANT TO ("user:persona@empresa.com")
FILTER USING (customer_id = 19);

Una vez otorgado, vamos a poder visualizarlos desde la pestaña «Schema» de la tabla.

Parece simple, pero no lo es tanto. Cuando una tabla tiene políticas de RLS, solo las personas incluidas en alguna de ellas pueden ver datos. Si alguien no está contemplado, no verá nada, aunque tenga otros permisos. Además, todas las políticas se evalúan con lógica OR: si una persona cumple al menos una condición, podrá ver esas filas. Por eso, si primero le das acceso limitado a alguien y después creás otra política que permite ver todo para quienes tienen acceso al proyecto, esa persona también verá todo. En la práctica, siempre se aplica la condición más permisiva que le corresponda.

Link: documentación RLS

Vistas autorizadas

Ya con solo leer lo que estoy poniendo, podemos llegar a la conclusión de que dar accesos a con RLS o con CLS no es tan simple. Sin embargo, hay una solución alternativa: vistas autorizadas.

Una vista común en BigQuery funciona como una consulta guardada, pero para poder ver sus resultados, el usuario también debe tener acceso a la tabla de origen. Es decir, si una persona no tiene permisos sobre la tabla base, aunque tenga acceso a la vista, no podrá ver los datos. En cambio, una vista autorizada rompe esa dependencia: permite que una persona consulte la vista aunque no tenga ningún permiso sobre la tabla original. Esto se logra autorizando explícitamente a la vista para que acceda a los datos de la tabla, y luego compartiendo únicamente la vista con quien querés.

Una vista autroizada es una alternativa al RLS y al CLS. Al filtrar nuestra consulta en la línea del «WHERE» se estaría aplicando algo equivalente al RLS, mientras que al elegir determinadas columnas en el «SELECT» nos da la posibilidad de evitar mostrar ciertas columnas con en el CLS.

Para que una vista se transforme en una vista autorizada se deberá otorgar permiso explícito para acceder a las tablas de origen. Esto se hace configurando el dataset que contiene la tabla original para que autorice a la vista, incluso si está en otro dataset o proyecto.

A partir de ese momento, cualquier usuario con acceso a la vista podrá consultar los datos que esta expone, sin necesidad de tener acceso directo a la tabla original.

Link: documentación vistas autorizadas

Auditar accesos

Otorgar permisos es parte fundamental del trabajo de gobernanza, pero no termina ahí. Muchas veces, la asignación de accesos las hace un equipo o a veces hay personas que no están en el equipo de gobernanza pero también tienen el poder de dar accesos. Para esto puede ser de gran ayuda llevar un seguimiento de quién dio acceso a quién, cuándo y cómo.

Google Cloud Platform genera automáticamente registros (logs) sobre las actividades que ocurren en sus servicios y recursos. Esta funcionalidad se conoce como Cloud Logging y forma parte del conjunto de herramientas de observabilidad de GCP. Si alguien da acceso a algún usuario, podremos ver los detalles dentro log correspondiente en el log explorer. [documentación logging ]

Revisar los logs en el Log Explorer no es una tarea imposible, pero tampoco es la forma más cómoda para hacer seguimiento regular. Los registros se muestran en formato JSON, lo que los vuelve poco amigables a simple vista y dificulta filtrarlos o analizarlos de manera estructurada. Por suerte, GCP permite crear un sink, es decir, un canal que redirecciona automáticamente esos logs hacia una tabla en BigQuery, donde podemos consultarlos con SQL y cruzarlos con otras fuentes de datos si fuera necesario. Esta estrategia transforma los registros técnicos en una fuente de auditoría clara, trazable y fácilmente explotable.

Para empezar, hay que ir a la sección Log Router en GCP y crear un nuevo sink. El sistema nos va a pedir que elijamos el destino: ahí debemos seleccionar BigQuery dataset como lugar donde queremos guardar los logs.

Luego, en la parte de filtros, es fundamental restringir solo a los logs que estén relacionados con asignación de permisos. Para eso, podemos usar este filtro:

protoPayload.methodName="SetIamPolicy"
logName="projects/{project_id}/logs/cloudaudit.googleapis.com%2Factivity"

Con esto, solo se almacenarán en BigQuery los eventos en los que se modificaron políticas de acceso. Lo mismo lo veremos volcado en una tabla por día, que se actualiza con cada cambio de permisos.

A simple vista esa tabla puede parecer interminable y poco legible.

Sin embargo, con la siguiente consulta la transforma en algo mucho más útil y claro.

SELECT distinct timestamp as modification_date
        ,protopayload_auditlog.authenticationInfo.principalEmail
        ,pi.permissionType
        ,bindingDeltas.action
        ,bindingDeltas.role
        ,bindingDeltas.member
        ,bindingDeltas.condition.title
        ,bindingDeltas.condition.expression
FROM `project_id.controles_gcp.cloudaudit_googleapis_com_activity_*`,
UNNEST(protopayload_auditlog.authorizationInfo) as pi,
UNNEST(protopayload_auditlog.servicedata_v1_iam.policyDelta.bindingDeltas) as bindingDeltas
order by 1 DESC

Pero esto no termina ahí, a veces se dan accesos de más y GCP nos lo muestra de forma simple en IAM en la columna de "Security insights"

Cuando ves algo como "9941/9972 excess permissions" se refiere a una métrica de seguridad que indica cuántos permisos asignados a un usuario, servicio o cuenta no se han utilizado en un periodo de observación reciente. [docu recommender] En el ejemplo vemos el caso dos personas una usó 121 de los más de 9mil, mientras la otra solo 31, siendo un claro indicio de permisividad excesiva.

Te paso la idea en limpio y resumida

Dar acceso en BigQuery no es solo una cuestión técnica: implica cumplir con responsabilidades legales como las que exige la ley GDPR, que obliga a limitar y justificar quién accede a los datos y por qué.

GCP permite controlar accesos en distintos niveles (proyecto, dataset, tabla, columna o fila) y con diferentes tipos de roles. Para hacerlo bien, es clave aplicar el principio de menor privilegio: dar solo el acceso necesario, sobre el recurso justo, con el mínimo poder requerido.

Cada permiso en IAM se compone de tres elementos: a quién se lo das (principal), qué puede hacer (rol) y sobre qué (recurso). Además, podés agregar condiciones específicas o usar mecanismos como RLS, CLS y vistas autorizadas para una gestión más precisa.

Finalmente, GCP permite auditar accesos con logs exportables a BigQuery, facilitando el seguimiento y reforzando una política de acceso segura, controlada y alineada con la ley.

¡Gracias por leer!

y no te olvides que le podés dar "me gusta" a esta nota sin haberte logueado.

Muchas gracias Carlos Clement por la propuesta de trabajar con sink para auditar los accesos.

Hola, soy Daniela. Durante muchos años fui docente de matemáticas en colegios y universidades, además de editar y escribir libros educativos. Hoy trabajo como Data Science Engineer y divulgo contenido sobre matemática, estadística y ciencia de datos en este sitio y en redes sociales. Crear y compartir conocimiento es mi forma de seguir conectada con la docencia. Creo firmemente en dos ideas que me acompañan desde siempre: "adquirir nuevos conocimientos te mantiene vigente" y "compartir es vivir".