← All platforms

AI readiness · Google BigQuery

BigQuery AI readiness assessment

Score your Google BigQuery estate against the six factors that decide whether data is ready for an AI workload — read-only, metadata only, never a row of your data. Free to run.

BigQuery makes it trivially easy to create a dataset, which is exactly why most BigQuery estates are larger than the person responsible for them believes. The readiness question is rarely whether the platform can support an AI workload. It is which fraction of the estate is described well enough to be safe to feed one.

That question is answerable without reading a single row. Every BigQuery dataset exposes an INFORMATION_SCHEMA describing tables, columns, nested field paths, descriptions, partitioning, and labels, and the policy-tag layer records which columns anyone has classified as sensitive.

The BigQuery readiness tension: sprawl — datasets accumulate faster than anyone documents them.

What the assessment reads on BigQuery

• INFORMATION_SCHEMA.TABLES and .COLUMNS — what exists, its shape, its types, and which columns were left semi-structured for a consumer to guess at.
• COLUMN_FIELD_PATHS — nested and repeated fields inside STRUCT and ARRAY columns, where undocumented personal data most often hides in BigQuery specifically.
• Descriptions and labels — documentation coverage at table and column level, which is the factor that most often decides whether a corpus is interpretable.
• Policy tags — which columns carry a data-classification tag, and therefore which sensitive columns nobody has classified.
• Partitioning and clustering metadata — whether retrieval over a table is an operation or an outage.

Those signals roll up into the six factors — Clean, Contextual, Consumable, Current, Correlated, Compliant — scored against roughly 50 requirements for the specific AI workload you pick, whether that is retrieval, agents, model training, or feature serving. The output is a readiness score, the single biggest blocker, and a prioritised fix plan with the score gain each fix earns. See the methodology for how scoring works.

Access it needs

A service account with two IAM roles on the project: BigQuery Metadata Viewer and BigQuery Job User. Metadata Viewer grants catalog visibility; Job User lets the metadata queries run. Neither grants access to table data, and the assessment never issues a SELECT against your tables. If your workspace admin has enabled Sign in with Google, a Google account works instead of a key.

The exact SQL each connector runs is published and generated from source, so a security review is a verification rather than a trust fall. If your warehouse cannot accept connections from the internet, the CLI agent runs the same metadata-only assessment inside your network. Full setup steps live in the connection guide.

The honest limits on BigQuery

• A scan cannot verify values. A description can be stale and a policy tag can be misapplied; metadata records the claim, not the truth behind it.
• Datasets the service account cannot see are not scored — they are reported as outside scope rather than silently skipped.

A metadata scan cannot verify values anywhere: a comment can be stale, a constraint can be worked around in application code, and a fresh-looking table can be full of duplicates. What it gives you is the structural truth of the estate — what exists, what is documented, what is governed, what is fresh, and what your chosen workload requires that is missing. It prepares evidence. It does not certify compliance, and no tool that reads only metadata honestly can.

Frequently asked questions

Want to see the output before connecting anything? Read a sample readiness report built entirely from metadata. For the deeper technical walkthrough, read the BigQuery assessment post. Other platforms: see all six.