Google Cloud Puts Data Governance on Autopilot With AI and Lineage

Introduction

Data governance often becomes harder as enterprise data estates grow. A well-documented source table can feed dozens of downstream views, but the metadata describing those columns does not always travel with the data.

Google Cloud is addressing this challenge with a Governance Agent project that combines Google Cloud Knowledge Catalog, BigQuery and column-level lineage to automate parts of the governance process.

The approach is designed to propagate trusted governance context downstream rather than requiring data teams to manually document every new view and transformed column.

The project was detailed by Sai Charan Tej Kommuri, Product Manager for Data Analytics, and Akanksha Bhagwanani, Customer Engineer, in a Google Cloud blog post published on August 19, 2026.

The data governance problem

Enterprise data typically moves through a chain of transformations.

Raw tables can be joined, filtered and reshaped into views, which can then become inputs for additional views and datasets. During that process, important metadata can be lost.

That metadata can include:

• What a column represents

• Whether it contains personally identifiable information

• Which business glossary term applies

• What data quality standards it meets

• Whether appropriate policies or masking rules apply

The result is often uneven governance. Core datasets may be carefully documented, while downstream assets become progressively less understood.

Google Cloud describes this as a form of governance debt. Teams can end up spending time rediscovering information that was already known upstream.

How the Governance Agent works

The central idea behind the project is to use column-level lineage to determine where data originated and then propagate existing governance metadata through downstream assets.

The agent focuses on four major areas.

1. Column descriptions

If an upstream column has a clear description, the agent can trace its lineage into downstream views and propose an appropriate description.

For straightforward column passthroughs, the original description can be carried forward.

More complex transformations receive additional analysis. If a column is generated through operations such as SUM(), CASE WHEN or COALESCE, the agent examines the SQL transformation and proposes a description that reflects the resulting column rather than simply copying the original metadata.

2. Business glossary terms

Technical column names do not always reflect the terminology used by business teams.

The Governance Agent uses semantic similarity to map columns to controlled business glossary terms. It can also use information from unstructured documents such as PDF policies, product specifications and Markdown design documents.

This allows the system to use explicit definitions found in organisational documentation rather than relying only on a column's technical name.

3. Policy tags and sensitive data

Policy tags are particularly important for governance and risk management.

When an upstream column has a PII tag, the agent can trace where that data travels and recommend carrying the relevant tag downstream. It can also provide a summary of current read access and masking rules.

The agent distinguishes between a sensitive value being passed through unchanged and a transformation that aggregates or anonymises the information.

This is intended to prevent indiscriminate propagation of sensitive-data classifications.

Importantly, the source describes a confidence threshold before changes are applied. The system is designed not to automatically infer PII status when there is insufficient evidence.

4. Trust and data quality scores

The agent can also derive a trust score using Data Quality and Profiling results from upstream sources.

The approach can recognise situations where a transformation improves data quality, including processes such as deduplication and null handling.

Rather than treating every downstream view as an unknown asset, the system uses information already available from upstream sources to establish context.

Governance becomes proactive

Google Cloud's approach changes where governance work takes place.

Instead of waiting for a scheduled review, an audit or a compliance problem, governance information can move as data moves through the environment.

The source highlights three practical outcomes:

1. New views can inherit existing context instead of starting completely undocumented.

2. Sensitive data can be identified as it flows through downstream assets.

3. Data stewards can focus on judgement-based decisions rather than repetitive metadata entry.

The approach does not eliminate the role of data stewards.

Instead, it shifts their attention towards ambiguous mappings, new business terms and policy exceptions while automating more repetitive work.

When lineage is not enough

Lineage is useful, but it does not cover every data asset.

Newly ingested datasets, one-off imports and older tables may not have a clean upstream lineage trail.

For these situations, the Governance Agent can use organisational documents as additional grounding.

The source identifies three approaches for providing this context.

Short documents

For smaller documents, the full text can be provided directly in the prompt.

Large documents

For longer material, such as a data classification policy, the agent can divide the document into chunks, create embeddings and retrieve relevant passages for a particular column.

This avoids processing the entire document repeatedly for every field.

Existing document repositories

Organisations that already have documentation indexed in Vertex AI Search can allow the agent to query that repository instead of repeatedly processing the original documents.

A conservative approach to AI-generated governance

One of the more important aspects of the project is its approach to uncertainty.

The source explicitly states that the agent is not designed to make plausible guesses when documentation is incomplete.

For policy tags and business glossary mappings, the supplied documentation must provide sufficient evidence.

If a column is not clearly defined, the system is expected to stop rather than invent an answer.

For PII classification, the source gives examples such as an explicit PII flag or a named sensitivity section. Column names alone are not treated as sufficient evidence.

This conservative approach is important because incorrect automation can create its own governance problems.

Over-classification can create unnecessary restrictions, while under-classification can leave sensitive information without the intended controls.

Combining lineage with AI-driven insights

Column-level lineage is the primary signal, but Google Cloud's approach also uses a second source of information.

The Data Lineage API can identify relationships that were explicitly recorded by jobs. However, data environments can contain gaps where lineage was not captured.

The Governance Agent can therefore trigger a Knowledge Catalog Data Documentation scan, described in the source as an AI-driven Gemini analysis of a table or dataset.

The resulting inferred relationships can then be extracted and cached before being loaded into the same traversal engine used for lineage.

The two signals are deliberately kept distinguishable.

Standard lineage runs first because it is based on an explicitly recorded job. The Insights pass is used afterward to fill gaps that lineage did not cover.

The source also states that propagated information can be traced back to whether it originated from a hard lineage connection or an inferred relationship.

Dashboard and CLI support

The project provides both a Gradio-based dashboard and a command-line interface.

The dashboard is intended for data stewards who want to review tables, identify metadata gaps, preview proposed changes and approve them.

The CLI provides an alternative for platform teams that want to incorporate governance operations into scheduled workflows or CI/CD processes.

The source specifically references commands such as steward_cli scan, apply and policy-propagate.

This combination reflects two different operational requirements. Governance teams may prefer a visual review experience, while engineering teams can integrate command-line operations into existing automation.

Human oversight remains important

Google Cloud does not present the system as a completely autonomous governance platform.

The source acknowledges that lineage confidence scoring can still produce incorrect results, particularly with renamed columns or unusual joins.

Semantic mismatch checks can identify obvious problems, but they remain heuristics rather than guarantees.

For this reason, propagation is designed to be previewed before it is applied.

The human review stage acts as an important safety mechanism for governance decisions.

The broader idea is not governance without effort. It is to move human effort towards the decisions that genuinely require judgement while reducing repetitive metadata work.

VodafoneThree UK Datahub experience

The source includes a testimonial from Radina-Paola Ivanova, GenAI Engineer at VodafoneThree UK Datahub.

She describes undocumented and inconsistently labelled data as a challenge for data discovery and delivery teams. According to the testimonial, the Data Steward Agent combines cataloguing, lineage and automated metadata propagation to help focus governance work on source datasets while allowing trusted context to move downstream.

The testimonial states that VodafoneThree estimates the approach could reduce cataloguing effort by up to 75%, while improving data discoverability, trust and AI readiness across its UK Datahub.

This figure is presented in the source as an estimate from the customer and should not be interpreted as an independently verified performance measurement.

What this means for enterprise data teams

The announcement highlights a broader industry shift toward using AI to assist with operational governance rather than treating governance solely as a periodic audit activity.

For enterprises with large BigQuery estates, lineage-based metadata propagation could help address a recurring problem: valuable governance information exists, but downstream teams may have to reconstruct it manually.

The approach also illustrates an important principle for AI-assisted governance: automation needs evidence and boundaries.

Where lineage or documentation provides strong evidence, the system can propose propagation. Where evidence is insufficient, the source describes a deliberate decision not to infer.

That distinction could be particularly relevant for organisations managing sensitive data, business terminology and compliance-related metadata.

The takeaway

Google Cloud's Governance Agent project aims to make data governance more continuous by allowing trusted metadata to follow data through its lineage.

The approach combines column-level lineage, Knowledge Catalog, BigQuery, AI-driven documentation analysis and organisational documentation to address metadata gaps across downstream data assets.

At the same time, the project keeps humans involved in decisions where confidence is insufficient or the business context is ambiguous.

The announcement highlights a broader industry shift toward governance that operates alongside data workflows rather than being performed only after problems appear.

For enterprises managing large and continually changing data estates, the central proposition is straightforward: govern trusted source data carefully, then use lineage and evidence-based automation to carry that context forward.