Cortex AI: Cómo llevar el modelo hasta el dato, qué se puede hacer desde SQL y por qué el coste es ahora un problema de ingeniería.

 

Durante los últimos años, incorporar IA a un pipeline de datos ha seguido casi siempre el mismo guion: extraer las filas del warehouse, enviarlas por API a un proveedor externo, esperar la respuesta y volver a cargar los resultados. Funciona, pero cada paso añade un problema: latencia, un pipeline más que mantener, tokens que pagar y —el más incómodo— datos sensibles que salen del perímetro donde tu equipo ha invertido años construyendo permisos, máscaras y auditoría.

Cortex AI invierte ese planteamiento. Integrado de forma nativa en Snowflake, en lugar de llevar el dato al modelo, lleva el modelo al dato. Es una capa de IA totalmente gestionada dentro de Snowflake que permite invocar LLMs, búsqueda semántica y agentes directamente desde SQL, sobre las tablas que ya tienes, sin mover nada y sin gestionar una sola GPU. Y no es un detalle de marketing: Snowflake documenta que todos los LLM a los que da acceso están desplegados dentro de su perímetro de servicio.

Qué encontrarás en Cortex AI (julio de 2026) • AI Functions (AISQL): LLMs invocables como funciones SQL, con modelos de OpenAI, Anthropic, Meta, Mistral AI y DeepSeek. • Cortex Search: recuperación híbrida semántica + keyword, el motor detrás de casos RAG. • Cortex Analyst: texto a SQL gobernado, apoyado en Semantic Views. • Cortex Agents: orquestación agéntica sobre datos estructurados y no estructurados, con soporte de conectores MCP. • Un modelo de coste propio: los AI Credits, separados de los créditos de plataforma.

 

1. Cortex AI y su arquitectura en tres capas

Conviene ordenar Cortex mentalmente en capas, porque el nombre comercial agrupa piezas muy distintas. Abajo están tus datos, ya gobernados en Snowflake: tablas y marts, ficheros no estructurados en stages y datos semiestructurados. En medio, la capa Cortex, que aporta la inteligencia. Y arriba, la capa de consumo: SQL y dbt para procesos batch, la REST API para aplicaciones que necesitan baja latencia, y las interfaces de usuario como Snowflake CoWork o Cortex Code.

Lo que atraviesa las tres capas es la gobernanza. Los permisos, el enmascaramiento y la auditoría que ya tienes definidos siguen aplicando cuando el que consulta es un modelo. Ese es, en la práctica, el argumento de venta real de Cortex frente a montar la integración por tu cuenta.

 

2. AISQL: ejecutar modelos de IA desde SQL con Cortex AI

Para un data engineer, esta es la puerta de entrada natural. Las Cortex AI Functions (conocidas como AISQL) convierten tareas que antes exigían un servicio aparte en una columna más de un SELECT. Las principales son AI_COMPLETE (la función general para tareas generativas), AI_CLASSIFY, AI_FILTER —que devuelve verdadero o falso, y por tanto puede usarse dentro de un WHERE o un JOIN … ON—, AI_AGG, AI_EMBED, AI_EXTRACT, AI_SENTIMENT y AI_REDACT para eliminar información personal identificable.

Un ejemplo directo: enriquecer reseñas de clientes sin salir del warehouse.

SELECT review_id, AI_SENTIMENT(review_text)                      AS sentimiento, AI_CLASSIFY( review_text, [‘envio’, ‘producto’, ‘atencion’, ‘precio’] )                                              AS categoria, AI_REDACT(review_text)                         AS texto_sin_pii FROM raw.reviews WHERE created_at >= DATEADD(day, -7, CURRENT_DATE());

Y cuando necesitas control fino sobre el modelo y sus parámetros, AI_COMPLETE admite argumentos con nombre:

SELECT AI_COMPLETE( model  => ‘claude-4-sonnet’, prompt => ‘Resume la queja en una sola frase: ‘ || review_text, model_parameters => { ‘temperature’: 0.2, ‘max_tokens’: 120 } ) AS resumen FROM raw.reviews;

Dos detalles de diseño que marcan la diferencia entre un experimento y un pipeline de producción. El primero: hay funciones, como AI_AGG y AI_SUMMARIZE_AGG, que agregan una columna de texto a lo largo de muchas filas y no están sujetas a los límites de la ventana de contexto, lo que resuelve el clásico problema de resumir miles de comentarios. El segundo, y más importante: estas funciones están optimizadas para throughput, no para latencia. Snowflake recomienda usarlas para procesar volúmenes grandes en batch y recurrir a la REST API cuando el caso de uso sea interactivo. Diseña en consecuencia.

3. Cómo integrar Cortex AI con dbt: el patrón incremental

Aquí es donde AISQL se vuelve verdaderamente útil —y donde más dinero se pierde si se hace mal. Si materializas como table un modelo que llama a un LLM, cada ejecución vuelve a procesar todas las filas y vuelve a pagar todos los tokens. En un pipeline diario sobre un histórico grande, el desperdicio es brutal.

La solución es el patrón que cualquier analytics engineer ya conoce, aplicado con una motivación nueva: la materialización incremental deja de ser solo una optimización de compute para convertirse en un control de gasto en IA. Enriqueces únicamente las filas nuevas.

{{ config( materialized = ‘incremental’, unique_key   = ‘review_id’ ) }}   with nuevas as ( select * from {{ source(‘raw’, ‘reviews’) }} {% if is_incremental() %} — solo lo que ha llegado desde la ultima ejecucion where ingested_at > (select max(ingested_at) from {{ this }}) {% endif %} )   select review_id, ingested_at, review_text, AI_SENTIMENT(review_text) as sentimiento, AI_COMPLETE( model  => ‘llama3.1-8b’,   — modelo pequeno para clasificacion masiva prompt => ‘Clasifica el motivo de queja en una palabra: ‘ || review_text ) as motivo from nuevas

Fíjate en la elección del modelo del ejemplo: uno pequeño para una tarea repetitiva y acotada. Es deliberado, y lo explicamos en la sección de costes. El resto de buenas prácticas de dbt siguen valiendo igual: tests sobre las columnas generadas (porque la salida de un LLM es impredecible y conviene validarla), documentación y control de versiones. La ventaja de meter la IA dentro de dbt es precisamente esa: el enriquecimiento pasa a ser un modelo más del DAG, con su linaje, sus tests y su revisión en pull request.

4. Cortex Search, Cortex Analyst y Cortex Agents, más allá de SQL

Además de las AI Functions, Cortex AI incorpora tres servicios especializados que resuelven problemas distintos:

• Cortex Search es el motor de recuperación: combina búsqueda semántica y por palabra clave sobre documentos, y es la pieza que alimenta los casos de RAG. La diferencia práctica frente a un LIKE es que entiende el significado: una búsqueda de «se me calienta el portátil» encuentra el documento que habla de «sobrecalentamiento».
• Cortex Analyst traduce lenguaje natural a SQL gobernado apoyándose en Semantic Views, un objeto nativo de Snowflake. Su razón de ser es resolver el desajuste entre cómo el negocio nombra las cosas y cómo están guardadas: el concepto «ingresos brutos» puede vivir en una columna llamada amt_ttl_pre_dsc. La semantic view define esa métrica una vez, con su fórmula de agregación y sus joins, y Cortex Analyst lee esa definición para generar el SQL contra las tablas físicas.
• Cortex Agents es la capa agéntica: unen datos estructurados y no estructurados en un único flujo gobernado, generando SQL mediante las semantic views de Analyst y recuperando contexto con Search, para después razonar sobre el resultado combinado. Se les pueden añadir herramientas propias construidas con procedimientos almacenados y UDFs.

Un apunte que conecta con el protocolo del que hablábamos en el artículo anterior: los agentes de Cortex admiten conectores MCP a servidores remotos, lo que les permite descubrir e invocar herramientas alojadas por proveedores externos. Las dos piezas encajan: Cortex aporta el dato gobernado y MCP el vocabulario para hablar con el resto del mundo.

Si estás pensando en la relación con dbt, la lectura correcta no es «uno u otro». La semantic view de Snowflake y la capa semántica de dbt persiguen el mismo objetivo —definir el significado una sola vez— y muchos equipos generan y despliegan las semantic views desde su propio proyecto dbt, manteniendo el control de versiones sobre la definición de negocio.

5. Costes de Cortex AI: la parte que casi nadie cuenta

Esta es la sección que separa un artículo de folleto de uno escrito por alguien que ha puesto esto en producción. En 2026 Snowflake reorganizó su modelo de precios para IA, y el cambio tiene consecuencias operativas directas.

Existen ahora dos monedas. Los AI Credits cubren las funcionalidades de IA con un precio plano, independiente de la edición que tengas contratada (Standard, Enterprise, Business Critical o VPS) y de la región. Los Platform Credits cubren el resto del uso —compute de warehouse, almacenamiento— y sí varían según edición y región. Las AI Functions se facturan en AI Credits por millón de tokens, con la tarifa variando según el modelo, y cuentan tanto los tokens de entrada como los de salida.

La consecuencia práctica es el punto ciego: al estar el consumo de IA desacoplado del compute, los resource monitors configurados sobre el uso de warehouse no se disparan cuando el gasto en IA se descontrola. Tu factura de compute puede permanecer plana mientras la de IA crece sin que salte ninguna alerta. Hay casos documentados de una sola consulta procesando más de mil millones de registros con un coste cercano a los 5.000 dólares, atribuible a tokens y no a compute.

Para auditar el consumo, la vista de referencia es CORTEX_FUNCTIONS_QUERY_USAGE_HISTORY, que permite rastrear el uso por consulta:

— Punto de partida para auditar el gasto en AI Functions. — Consulta la referencia de la vista para el detalle de columnas — disponibles en tu cuenta antes de construir tu modelo de coste. SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_FUNCTIONS_QUERY_USAGE_HISTORY WHERE start_time >= DATEADD(day, -30, CURRENT_DATE());

Cuatro palancas concretas para mantener el gasto bajo control:

• Elegir el modelo es la palanca de mayor impacto: la diferencia de coste entre un modelo pequeño y uno de frontera para la misma tarea puede ser de un orden de magnitud. Reserva los grandes para donde realmente aporten calidad.
• Materializaciones incrementales en dbt, como en el ejemplo anterior: no vuelvas a pagar tokens por filas ya procesadas.
• Prompt caching: está soportado, y las lecturas de caché se facturan a una tarifa reducida frente a los tokens de entrada estándar. Muy rentable con prompts de sistema repetitivos.
• Vigilar el índice de Cortex Search: el compute de servicio se cobra de forma continua en función del tamaño de los datos indexados, aunque nadie esté lanzando consultas. Un servicio de desarrollo olvidado sigue generando coste.

6. Seguridad y permisos en Cortex AI: quién puede invocar un modelo

Antes de la primera línea de código conviene resolver los permisos, porque no basta con tener acceso a las tablas. Para llamar a las Cortex AI Functions, el rol necesita el privilegio de cuenta USE AI FUNCTIONS y uno de los database roles CORTEX_USER o AI_FUNCTIONS_USER.

— Habilitar a un rol para consumir funciones de Cortex GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE analista_ia;

Esta granularidad es una ventaja, no un trámite: permite decidir explícitamente qué roles pueden gastar AI Credits. Combinado con la separación de monedas de la sección anterior, es tu primera línea de defensa contra sorpresas en la factura.

 

Conclusión

Cortex AI resuelve un problema real y bien delimitado: acercar los modelos a los datos gobernados en lugar de exportar los datos hacia los modelos. Para un equipo que ya vive en Snowflake, la barrera de entrada es notablemente baja —una función más en un SELECT— y la ganancia en gobernanza es inmediata, porque los permisos y las políticas que ya existen se siguen aplicando.

Pero esa misma facilidad es la trampa. Escribir AI_COMPLETE sobre una tabla de mil millones de filas cuesta lo mismo de teclear que sobre una de mil, y la diferencia solo aparece en la factura. El trabajo de ingeniería no desaparece: se desplaza. La elección del modelo, la estrategia de materialización y el diseño del prompt son ahora decisiones de arquitectura con impacto económico directo, exactamente igual que dimensionar un warehouse. Quien entienda eso sacará de Cortex mucho más que quien solo lo pruebe.

A medida que las organizaciones incorporan agentes de IA y aplicaciones basadas en modelos de lenguaje, Cortex AI se perfila como una de las plataformas más completas para acercar la inteligencia artificial al dato gobernado. Comprender cómo funcionan sus componentes, optimizar los AI Credits e integrarlo con herramientas como dbt o MCP será cada vez más importante para los equipos de Data Engineering.

 

Preguntas frecuentes sobre Cortex AI

¿Qué es Cortex AI?

Cortex AI es la plataforma de inteligencia artificial integrada en Snowflake que permite ejecutar modelos de lenguaje, búsqueda semántica y agentes de IA directamente sobre los datos almacenados en el data warehouse. Su principal ventaja es que evita mover la información a servicios externos y mantiene la gobernanza, la seguridad y los permisos definidos en Snowflake.

¿Para qué sirve Cortex AI?

Cortex AI permite incorporar inteligencia artificial a los pipelines de datos mediante funciones SQL, búsqueda semántica, generación de embeddings, análisis de sentimiento, clasificación de texto y agentes inteligentes. Todo ello se ejecuta directamente sobre los datos almacenados en Snowflake.

¿Cómo funciona Cortex AI?

Cortex AI se organiza en varias capas que permiten acceder a los datos mediante funciones SQL (AISQL), motores de búsqueda semántica como Cortex Search, traducción de lenguaje natural a SQL mediante Cortex Analyst y automatización de procesos con Cortex Agents. Todos estos componentes aprovechan la gobernanza nativa de Snowflake.

¿Qué es AISQL en Cortex AI?

AISQL es el conjunto de funciones SQL de Cortex AI que permite invocar modelos de inteligencia artificial directamente desde consultas SQL. Funciones como AI_COMPLETE(), AI_SENTIMENT() o AI_CLASSIFY() facilitan enriquecer datos sin necesidad de desarrollar servicios externos.

¿Qué es Cortex Search?

Cortex Search es el componente de Cortex AI especializado en búsqueda semántica. Combina búsqueda vectorial y búsqueda por palabras clave para recuperar información relevante y constituye la base de muchas arquitecturas RAG (Retrieval-Augmented Generation).

¿Qué es Cortex Analyst?

Cortex Analyst convierte preguntas en lenguaje natural en consultas SQL utilizando Semantic Views. Esto permite que usuarios de negocio consulten información mediante lenguaje natural respetando las definiciones y reglas de negocio establecidas por la organización.

¿Qué son Cortex Agents?

Cortex Agents son agentes de inteligencia artificial capaces de combinar datos estructurados, documentos, búsqueda semántica y herramientas externas para automatizar tareas complejas. También pueden conectarse con servidores MCP para ampliar sus capacidades.

¿Cómo integrar Cortex AI con dbt?

Cortex AI puede utilizarse dentro de modelos dbt mediante las AI Functions. Combinado con materializaciones incrementales, permite enriquecer únicamente los nuevos registros, reduciendo significativamente el consumo de AI Credits y el coste de los procesos de datos.

¿Cómo se calcula el coste de Cortex AI?

Cortex AI utiliza AI Credits independientes de los Platform Credits de Snowflake. El coste depende del modelo empleado, del volumen de tokens procesados y de servicios como Cortex Search, por lo que resulta recomendable optimizar el tamaño de los modelos, reutilizar prompts y aplicar materializaciones incrementales.

¿Es seguro utilizar Cortex AI?

Sí. Cortex AI mantiene los datos dentro del entorno gobernado de Snowflake y respeta los permisos, políticas de acceso, enmascaramiento y auditoría ya configurados. Además, permite controlar qué roles pueden utilizar las funciones de inteligencia artificial mediante privilegios específicos.

 

Nota: Cortex AI evoluciona con rapidez y algunas funciones están en preview. Verifica el estado de cada función y las tarifas vigentes en la Snowflake Service Consumption Table antes de llevar nada a producción o de construir un modelo de costes interno.