← All posts

Platforms · July 16, 2026

Is your Snowflake data AI-ready? The metadata already knows.

By the MortarIQ Founder · 6 minute read

Snowflake ships one of the richest governance surfaces of any warehouse: object tags, masking policies, row access policies, and an ACCOUNT_USAGE schema that records nearly everything about how the account is structured and governed. Which makes Snowflake accounts a strange thing to audit, because the gap is almost never capability. It is uptake. The features are sitting right there, and the median account uses a fraction of them.

That gap is precisely what an AI readiness assessment measures, and on Snowflake all of it is measurable without reading a single row. Here is what the metadata surface can tell you, what real accounts get wrong, and the least-privilege access that makes the audit safe enough to not die in security review.

What Snowflake metadata answers, factor by factor

MortarIQ scores six factorsfrom 50 requirements, and Snowflake’s catalog answers all of them:

Contextual. Comments on tables and columns, straight from the catalog. This is where most accounts score worst: schemas built by dbt at high speed, where the descriptions live in YAML that never made it into COMMENT clauses, so the warehouse itself is mute. If a machine reads your catalog and not your repo, your documentation coverage is what the catalog says it is.

Compliant. The showpiece. Object tags tell you what has been classified as sensitive; masking policy references tell you what is actually protected. The difference between those two sets is your exposure, and it is computable from governance metadata alone. The most common finding in real accounts is not zero governance; it is a masking policy applied to the three columns everyone remembered, with the same PII unmasked in the staging schema one layer down.

Current. Last-altered timestamps for every table, no query against the table required. Stale tables in an AI corpus are wrong answers with a confident tone, and on Snowflake staleness is visible at a glance if anyone looks.

Clean and Correlated. Snowflake accepts primary and foreign key declarations without enforcing them, which tempts teams to skip them entirely. Skipping them throws away the only machine-readable statement of what a row means and how tables join. Declared-but-unenforced keys are still documentation, and for an AI consumer they are the difference between joining on evidence and joining on a hunch.

Consumable. Clustering keys, table sizes, and naming conventions, all in the catalog. A retrieval workload pointed at an unclustered multi-terabyte table is a credit bill waiting to be explained.

The access model, honestly

A readiness audit is only worth running if the access it asks for is boring. On Snowflake, MortarIQ’s grant script creates a dedicated MORTARIQ_READER role and a service user that authenticates with a key pair rather than a password. The role gets USAGE on the databases and schemas in scope, plus two Snowflake-defined database roles: OBJECT_VIEWER, which exposes catalog structure, and GOVERNANCE_VIEWER, which exposes the ACCOUNT_USAGE governance views, including tag references and masking policy coverage.

One thing worth stating plainly, because your security team will notice and should: the GOVERNANCE_VIEWER grant opens read access to governance views account-wide, not per database. That is how Snowflake scoped the role, and it is the blast radius of the audit. What the role never gets is SELECT on your data. The exact queries each connector runs are published and generated from source, so the claim is verifiable rather than promotional. The metadata-only method post covers why that boundary is the whole design.

What we keep finding in Snowflake accounts

Three patterns repeat. First, governance concentrated in the presentation layer: masking and tags on the marts, nothing on staging and raw, even though every schema is one grant away from an AI pipeline. Second, documentation living in dbt YAML while the catalog comments sit empty, so the estate is documented for the team and undocumented for every tool. Third, freshness failures hiding in plain sight: load jobs that died quietly weeks ago on tables nobody queries until, suddenly, a retrieval corpus does.

None of these are exotic. All of them are invisible until someone without the tribal knowledge, a new hire or a model, tries to use the account cold. That is the test an AI workload applies on day one.

The honest boundary

Metadata cannot verify values. A tag can be present and wrong; a fresh table can be full of duplicates; no scan that refuses to read rows can tell you otherwise, and this one refuses on purpose. The assessment measures whether your Snowflake account is structured, documented, and governed well enough for an AI workload to use safely, and produces the evidence trail. It does not certify compliance, and nothing that reads only metadata honestly can. If your deadline is regulatory, start with Article 10, whose high-risk obligations become enforceable December 2, 2027.

Frequently asked questions

Want to see the output before granting anything? Read a sample readiness report, or run the CLI inside your network with no account at all.