CREATE AI FUNCTION¶
CREATE AI FUNCTION lets you turn custom AI logic into a reusable, governed Snowflake function that can be used across applications, workflows, and SQL queries. Use CREATE AI FUNCTION when you want to package AI-powered logic behind a stable SQL interface and manage it consistently with the rest of your Snowflake environment.
You define the function using Snowflake Cortex AI functions such as AI_COMPLETE, AI_CLASSIFY, or AI_FILTER, then invoke it like any other scalar function. Because it is a first-class Snowflake object, you can manage it using familiar Snowflake capabilities for access control, object lifecycle, discovery, and governance.
AI functions can also participate in Snowflake’s evaluation and optimization workflows. This makes it possible to measure quality and cost, improve prompts or model choices, and promote an optimized implementation into a production-ready function without changing how downstream users call it.
Syntax¶
Create an AI function from a SQL expression:
Create an AI function from the winning candidate of an optimization experiment:
Arguments¶
Required¶
nameThe identifier for the AI function. Can be fully qualified (
db.schema.name). The argument data types are part of the function’s signature, soMY_FN(VARCHAR)andMY_FN(VARCHAR, VARCHAR)are distinct functions (standard UDF overloading rules).( arg_name arg_data_type [ , ... ] )Zero or more input arguments, each an identifier plus a SQL data type (VARCHAR, FLOAT, BOOLEAN, OBJECT, FILE, and so on). The argument list may be empty:
MY_FN().RETURNS result_data_typeThe scalar SQL type the function returns (for example VARCHAR, FLOAT, BOOLEAN, OBJECT). A
TABLE(...)return type is not supported — an AI function’s body is a single scalar expression.
Exactly one body clause:
AS $$ sql_expression $$A single scalar SQL expression that calls AI_COMPLETE at least once. It may also call other AI functions (for example AI_CLASSIFY, AI_FILTER) or a nested user-defined AI function, but at least one AI_COMPLETE call is required. The expression can freely reference the function’s arguments and can post-process the AI call (for example concatenate a prompt, cast the result to the return type).
FROM EXPERIMENT experiment_name RUN run_nameInstead of an inline body, materialize the function from a specific run of an existing optimization experiment (typically the frontier / winning
ITER_<N>run). Snowflake copies that run’s tuned implementation into the new function. The declared signature and return type must match the optimized function.
Optional¶
OR REPLACEReplace an existing function with the same name and signature. Cannot be combined with
IF NOT EXISTS.IF NOT EXISTSDo nothing (no error) if a function with the same name and signature already exists.
COMMENT = 'string_literal'An optional description stored with the function (the
WITHkeyword is optional:WITH COMMENT = '...'is equivalent).
Returns¶
Creating the function returns a status row confirming creation. When invoked, the function returns a single
scalar value of <result_data_type> per input row, exactly like any scalar UDF:
Usage notes¶
- Body must be a scalar SQL expression, not a procedural block. Snowflake Scripting / multi-statement bodies
are rejected. Write one expression; use
||,CASE, casts, and nested function calls as needed. - Body must call scalar AI Functions such as
AI_COMPLETE,AI_CLASSIFYat least once. A body that never calls scalar AI Functions is rejected. Legacy non-prefixed Cortex functions (for exampleSNOWFLAKE.CORTEX.SENTIMENT) do not count — use theAI_-prefixed equivalents.AI_AGGis considered non-scalar and will be rejected. - Cast the AI result to your return type.
AI_COMPLETE(...)returns VARIANT; if your functionRETURNS VARCHAR, cast explicitly (AI_COMPLETE(...)::VARCHAR) so the declared and actual types match. - The argument list is the tunable surface. When you later optimize the function, Snowflake rewrites the body (prompt/model) while preserving this signature and return type. Design arguments to carry the inputs the model needs (the text to classify, the context, and so on).
- AI functions are UDFs. They appear in
SHOW USER FUNCTIONS, are dropped withDROP FUNCTION, and follow standard UDF resolution and overloading. - Runtime billing. Each invocation runs the underlying AI calls, which are metered as Cortex AI inference (tokens), separate from the compute that runs your query. See AI_COMPLETE for the model-level cost model.
Access control requirements¶
| Privilege | Object | Notes |
|---|---|---|
| CREATE FUNCTION | Schema | Same privilege as a regular UDF; there is no separate “CREATE AI FUNCTION” privilege. |
Database role SNOWFLAKE.CORTEX_USER | — | Required to run the AI calls in the body at invocation time. |
| USAGE | Function’s database + schema | To call the function. |
Examples¶
Classify sentiment¶
Create an AI function that classifies a product review into one of four sentiment categories:
Invoke the function like any other scalar UDF:
Classify support tickets¶
Create an AI function that categorizes support tickets into a fixed label set:
Invoke the function:
Redact PII from free text¶
Create an AI function that replaces personally identifiable information (PII) in free text with placeholders:
Materialize the winner of an optimization experiment¶
After running an AI_FUNCTION_OPTIMIZATION experiment (see Optimize an AI function), promote the best run to a new, production-ready AI function:
Limitations¶
- Scalar SQL only. Procedural (Snowflake Scripting) bodies and non-SQL languages (Python/Java/Scala handlers) are not supported for AI functions.
- Model availability. The models named in the body must be available and authorized in your account and region; otherwise calls fail at invocation time.
Legal¶
The data classification of inputs and outputs are as set forth in the following table.
| Input data classification | Output data classification |
|---|---|
| Usage Data | Customer Data |
For additional information, refer to Snowflake AI and ML.