How to put generative AI directly into a dbt pipeline with plain SQL

In a dbt Summit 2026 breakout session, Alicia Williams, a developer relations engineer at Google Cloud who focuses on BigQuery's AI functions, made a case for skipping the usual path into applied AI. Instead of standing up a Python pipeline to call a model API, she showed how to call a large language model directly from a SQL SELECT statement, and then wire that call into a normal dbt project.

The core story is about what happens to a data team's AI experiments once they stop living in notebooks and start living inside the same models, tests, and incremental logic every other transformation already runs through.

A SQL function instead of a Python service

BigQuery's AI.GENERATE function takes a prompt and a column, and returns a response for every row in the table it's run against, whether that's dozens of rows or billions. Williams walked through the basic case first: extracting keywords from a table of unstructured movie reviews with a single AI.GENERATE call in a SELECT statement.

From there, the features stack up. An output_schema parameter forces the model to return strict, typed JSON instead of a blob of unstructured text, which Williams called the single biggest feature for a data practitioner working with LLM output downstream.

BigQuery also ships a set of managed functions, AI.IF for semantic filtering, AI.CLASSIFY for categorization, AI.SCORE for rating and ranking, and AI.AGG for summarizing across many rows at once, that are pre-tuned for common analytical tasks and generally cheaper to run than a hand-written prompt through AI.GENERATE.

An "optimized mode" for AI.IF and AI.CLASSIFY takes this further: it labels a small sample of rows with the full model, trains a lightweight distilled model on that sample inside BigQuery's own compute, and then runs the rest of the dataset against the distilled model instead of the LLM. "This really results in massive costs and latency gains when you're working with more and more rows," Williams said.

Making it safe to run in production

Williams's second half focused on what breaks when these functions run inside a real pipeline rather than a one-off query. The first rule: never let an AI function run inside a full refresh. Rebuilding a table from scratch resends every row back to the model, which gets expensive fast at scale.

The fix is standard dbt practice applied to a new problem: materialize the model incrementally and wrap the AI logic in an is_incremental() block, so only newly arrived rows get sent to the LLM. Cost controls layer on top of that: AI.COUNT_TOKENS for pre-execution estimates, project- and user-level daily token caps, and a max_error_ratio parameter that aborts a query outright once a set percentage of rows fail.

For output reliability, Williams recommended pairing BigQuery's output_schema parameter with standard dbt tests like not_null and accepted_values, so a model that returns something unexpected gets caught in staging rather than reaching a mart. "That way, if these things fail in staging or intermediate layers, that won't get through to your final layer," she said.

The session closed with a live demo built on a fictional pet e-commerce dataset: a three-stage dbt pipeline that joins raw review text with order data, scores each review on product, shipping, and customer service sentiment with AI.SCORE, and rolls everything up by product with AI.AGG into a plain-language summary, complaints about a leaky chinchilla water bottle nozzle included, that a product manager could act on without reading twenty individual reviews.

Watch every keynote and breakout from dbt Summit 2026 on demand. Watch dbt Summit 2026 on demand →