Snowflake Cortex y la Ley de IA de la UE: los datos gobernados no te hacen cumplidor

Q: ¿Usar Snowflake Cortex hace a Snowflake responsable de mi cumplimiento de la Ley de IA de la UE?

No. Cortex es infraestructura —funciones LLM, Cortex ML y búsqueda que se ejecutan dentro de tu almacén—. Cuando compones un sistema sobre él y lo pones en servicio bajo tu propio nombre, el artículo 3(3) te hace el proveedor y las obligaciones del artículo 16 son tuyas. Cuando una función de Cortex llama a un modelo fundacional alojado, el proveedor de ese modelo soporta los deberes de GPAI del capítulo V (artículos 51-55), no tú como llamador aguas abajo. Las atestaciones de plataforma de Snowflake no son una evaluación de la conformidad del artículo 43 del sistema que construiste.

Q: Construyo con Cortex sobre mis propios datos gobernados — ¿soy el proveedor o el responsable del despliegue?

Normalmente el proveedor. El artículo 3(3) define al proveedor como quien desarrolla un sistema de IA y lo pone en servicio bajo su propio nombre, lo que cumple componer un pipeline de Cortex en un flujo de decisión. Eres responsable del despliegue bajo el artículo 26 solo cuando ejecutas una función alojada de Cortex sin modificar bajo el nombre de otro. El artículo 25 también convierte a un responsable del despliegue en proveedor ante una modificación sustancial o un cambio de finalidad prevista a alto riesgo. Si tanto lo construyes como lo operas internamente, llevas ambos sombreros.

Q: Mis datos de Snowflake ya están gobernados con etiquetas y enmascaramiento — ¿no satisface eso el artículo 10?

No, aunque ayuda. Las etiquetas de objetos, el enmascaramiento, las políticas de acceso por filas y la trazabilidad de ACCESS_HISTORY son controles de confidencialidad y acceso —prueba sólida de procedencia para tu expediente del artículo 10—. Pero el artículo 10 es un deber sustantivo de calidad de datos: los datos de entrenamiento, validación y prueba deben ser pertinentes, representativos, lo más libres de errores posible y examinados en cuanto a sesgos y lagunas. Ese análisis de aptitud para la finalidad sigue siendo tuyo para realizar y documentar; el almacén te da el rastro de prueba, no la conclusión.

Q: ¿Un sistema que construyo sobre Cortex es automáticamente de alto riesgo?

No. La Ley clasifica por finalidad prevista, no por plataforma. Tu sistema es de alto riesgo solo si cumple una función del anexo III —por ejemplo, fijación de precios de seguros (punto 5(d)), solvencia (5(b)) o decisiones laborales (punto 4)— bajo el artículo 6(2). Incluso entonces, el filtro del artículo 6(3) puede eximir tareas estrechas o preparatorias, salvo que el sistema elabore perfiles de personas. La mayor parte de la analítica de almacén —puntuación de abandono, previsión, resumen de documentos— no es de alto riesgo, y solo debe la alfabetización del artículo 4 y la transparencia del artículo 50 cuando la salida llega a terceros.

Q: ¿Qué significa el logging del artículo 12 para un pipeline de Cortex?

El artículo 12 exige que los sistemas de alto riesgo permitan técnicamente el registro automático de eventos durante una vida útil apropiada a su finalidad, para poder rastrear el comportamiento e investigar incidentes. Como la inferencia de Cortex se ejecuta como consultas dentro del almacén, es una superficie de registro natural: diseña los pipelines para capturar entradas de predicción, versiones de función y modelo, salidas y eventos de supervisión humana desde el principio —el historial de consultas y ACCESS_HISTORY ayudan—. Del lado del responsable del despliegue, el artículo 26 exige por separado conservar los registros al menos seis meses. Diseñar el logging desde el inicio supera al de adaptarlo después.

Q: ¿Cuándo aplican los plazos de alto riesgo a los sistemas construidos sobre Cortex?

El Reglamento Ómnibus Digital, adoptado en junio de 2026 (Parlamento Europeo el 16 de junio, Consejo el 29 de junio), fija los plazos de alto riesgo: los sistemas autónomos del anexo III aplican desde el 2 de diciembre de 2027 y los sistemas del anexo I integrados en producto, desde el 2 de agosto de 2028. Planifica frente al 2 de diciembre de 2027. La transparencia general del artículo 50 aplica desde el 2 de agosto de 2026, y los deberes de marcado de contenido del artículo 50(2), desde el 2 de diciembre de 2026.

Q: ¿Cuáles son las sanciones si clasifico mal un sistema construido con Cortex?

El artículo 99 fija tres niveles, cada uno en la cifra que sea mayor. Las prácticas prohibidas bajo el artículo 5 llevan hasta 35 M€ o el 7 % del volumen de negocios anual mundial total (artículo 99(3)). El alto riesgo y la mayoría de las infracciones de obligaciones, incluida la transparencia del artículo 50, llevan hasta 15 M€ o el 3 % (artículo 99(4)). La información incorrecta o engañosa a las autoridades lleva hasta 7,5 M€ o el 1 % (artículo 99(5)). Para pymes y nuevas empresas, el artículo 99(6) limita la multa a la menor entre el porcentaje y la cantidad fija.

Cumplimiento de herramientas de IA4 de agosto de 2026· 14 min de lectura

¿Construyes con funciones LLM o ML de Snowflake Cortex? Eres el proveedor (art. 16). Los datos gobernados ayudan al artículo 10, no lo sustituyen.

Ejecutas una llamada COMPLETE sobre una tabla etiquetada, enmascarada y con control de acceso y asumes que la gobernanza de tu almacén ya ha cumplido con la Ley de IA de la UE. No lo ha hecho. El Reglamento (UE) 2024/1689 regula el sistema de IA que compusiste y su finalidad prevista, no la función SQL, el cómputo ni las etiquetas de columna que aplicaste para el RGPD. Esta página cubre quién es el proveedor, cómo clasificar el sistema y por qué los datos gobernados son una ventaja inicial sobre la prueba, nunca un sustituto de la obligación.

Cortex ejecuta IA dentro de tu almacén — y la Ley se adhiere al sistema, no al SQL

Snowflake Cortex lleva funciones LLM (como COMPLETE, SENTIMENT, EXTRACT_ANSWER, TRANSLATE), Cortex Analyst, Cortex Search y Cortex ML a los datos que ya residen en tu almacén gobernado —la inferencia se ejecuta donde viven los datos, a menudo a una sola sentencia SQL de distancia—, lo que pone los sistemas en construcción y en servicio más rápido de lo que la revisión de gobernanza los alcanza.

Como SageMaker y Vertex, Cortex es infraestructura. La Ley regula el sistema de IA tal como lo define el artículo 3(1) y lo clasifica por su finalidad prevista bajo el artículo 6 y los anexos —nunca el almacén, el cómputo ni la función SQL que llamaste—. Así que la pregunta correcta nunca es «¿cumple Cortex?». Pregunta en cambio qué sistema de IA has construido sobre datos gobernados, con qué finalidad y en qué decisión influye.

¿Proveedor o responsable del despliegue? La bifurcación de Cortex depende de lo que construyas

Construyes un sistema bajo tu propio nombre — eres el proveedor (artículo 16)

El artículo 3(3) define al proveedor como quien desarrolla un sistema de IA y lo pone en servicio bajo su propio nombre o marca. Conecta una función LLM de Cortex o un modelo de Cortex ML a un producto o a un flujo de decisión interno bajo tu propio nombre, y el artículo 16 te hace el proveedor —soportando la gestión de riesgos (artículo 9), la gobernanza de datos (artículo 10), la documentación (artículo 11), la supervisión (artículo 14), la evaluación de la conformidad (artículo 43) y el resto de la batería de alto riesgo—.

Solo llamas a una función alojada sin modificar — deberes de responsable del despliegue (artículo 26)

Llama a una función LLM de Cortex alojada —COMPLETE sobre un modelo fundacional, digamos— sin modificar y bajo tu propia autoridad, y eres responsable del despliegue conforme al artículo 26: sigue las instrucciones del proveedor, mantén real la supervisión del artículo 14 y conserva los registros al menos seis meses.

El rol cambia bajo el artículo 25 — nombre, modificación o cambio de finalidad

El artículo 25 rige los cambios de rol: poner tu nombre en un sistema de alto riesgo, hacer una modificación sustancial (artículo 3(23)) o cambiar la finalidad prevista para que pase a ser de alto riesgo convierte a un responsable del despliegue en proveedor —y un proveedor fuera de la Unión debe nombrar un representante autorizado en la UE conforme al artículo 22—. El diferenciador frente a SageMaker y Vertex: Cortex a menudo combina ambas capas en una consulta —un modelo fundacional alojado (Snowflake o el proveedor del modelo soporta la capa aguas arriba) alimentando un pipeline de decisión que tú diseñaste (donde eres el proveedor)—. Clasifica el sistema que compusiste, no la función que llamaste.

Clasifica el sistema por su finalidad prevista, no por la plataforma

Alto riesgo vía anexo III (autónomo) — artículo 6(2)

Un sistema autónomo es de alto riesgo bajo el artículo 6(2) cuando cumple una función del anexo III. Los puntos más relevantes para la analítica nativa de almacén: anexo III, punto 5, servicios esenciales —5(b) solvencia y puntuación crediticia (detección de fraude excluida), 5(d) evaluación de riesgos y fijación de precios de seguros de vida y salud—; punto 4, empleo —4(a) contratación, 4(b) decisiones en el empleo y monitorización—; punto 2, componentes de seguridad de infraestructuras críticas. Por separado, las prohibiciones del artículo 5 muerden con independencia del nivel: el artículo 5(1)(f) prohíbe el reconocimiento de emociones en el trabajo y la educación, y el artículo 5(1)(g) prohíbe la categorización biométrica que infiere atributos sensibles —relevante en cuanto las funciones de texto o sentimiento de Cortex apuntan a comunicaciones de empleados—.

El filtro del artículo 6(3) y la mayoría que no es de alto riesgo

El artículo 6(3) puede sacar un sistema del anexo III del alto riesgo cuando solo cumple una tarea procedimental estrecha, mejora una actividad humana ya completada, detecta desviaciones sin reemplazar la valoración humana o hace trabajo preparatorio —pero nunca cuando elabora perfiles de personas físicas—. Documenta la evaluación y aun así regístralo bajo el artículo 49. La mayor parte de la analítica de almacén construida sobre Cortex no es de alto riesgo: puntuación de abandono, previsión de demanda, resumen, búsqueda interna, segmentación de marketing. Ahí los deberes reales son la alfabetización en IA del artículo 4, la disciplina de datos del artículo 10 y la transparencia del artículo 50 cuando la salida llega a terceros.

La ruta de producto del anexo I y la salvedad de la sección B

Si un modelo de Cortex ML es un componente de seguridad de un producto regulado, aplica la ruta de producto del artículo 6(1) y el anexo I. Para el anexo I sección A (maquinaria, productos sanitarios bajo el MDR 2017/745 y el IVDR 2017/746), el artículo 43(3) enruta la conformidad a través de los actos sectoriales. Para el anexo I sección B (vehículos de motor bajo el Reglamento (UE) 2018/858, aviación, ferrocarril, marítimo), el artículo 2(2) significa que solo el artículo 6(1), los artículos 102-109 y el artículo 112 aplican directamente —nunca la batería de los artículos 8-15, 16 y 43—.

Artículo 10 y artículo 12: los datos gobernados ayudan, pero nunca cumplen el deber

Por qué la gobernanza del almacén es una entrada al artículo 10, no un sustituto

El artículo 10 exige que los conjuntos de datos de entrenamiento, validación y prueba para sistemas de alto riesgo sean pertinentes, representativos, lo más libres de errores posible y completos, con examen de sesgos y lagunas —una obligación sustantiva de calidad de datos sobre los datos que alimentan la decisión—. La gobernanza nativa de Snowflake —etiquetado de objetos, enmascaramiento a nivel de columna, políticas de acceso por filas y la trazabilidad de ACCESS_HISTORY— es una verdadera ventaja inicial sobre esa prueba: muestra la procedencia, el control de acceso y la trazabilidad de las columnas que alimentan una función de Cortex. Pero son controles de confidencialidad; no establecen representatividad, minimización de errores ni examen de sesgos, que siguen siendo tuyos para realizar y documentar. Y como compones el sistema a partir de tablas gobernadas, no hay un proveedor aguas arriba del que heredar el artículo 10 —la obligación es tuya por completo—. El almacén te da el rastro de prueba, no la conclusión.

Diseñar pipelines de Cortex para la trazabilidad del artículo 12

El artículo 12 exige que los sistemas de alto riesgo permitan técnicamente el registro automático de eventos durante una vida útil apropiada a la finalidad prevista. La inferencia de Cortex dentro del almacén es una superficie de registro natural: diseña los pipelines para que las entradas de predicción, las versiones de modelo y función, las salidas y los eventos de supervisión se capturen desde el principio —el historial de consultas y ACCESS_HISTORY ayudan—. La documentación del artículo 11 y el anexo IV, conservada diez años bajo el artículo 18, debe cubrir aun así el modelo, la procedencia de los datos y la configuración de Cortex; la exactitud y robustez del artículo 15 se sitúa a nivel de sistema, lo que el endurecimiento del almacén no cumple.

Snowflake es tu plataforma, no tu evaluador de conformidad

Las certificaciones y atestaciones de Snowflake cubren su propia capa de plataforma y la residencia de datos. No son una evaluación de la conformidad bajo el artículo 43 del sistema que compusiste —el proveedor la realiza y la firma—. La mayoría de los sistemas autónomos del anexo III usan la ruta de autoevaluación interna del anexo VI, que termina en la declaración UE de conformidad del artículo 47 y el registro del artículo 49; la biometría suele requerir la ruta de organismo notificado del anexo VII.

Cuando consumes un modelo fundacional alojado mediante una función LLM de Cortex, las obligaciones de GPAI del capítulo V (artículos 51-55, en vigor desde el 2 de agosto de 2025) recaen en el proveedor de ese modelo, no en ti como llamador aguas abajo. Hacer llamadas a la API o SQL no cruza la presunción de riesgo sistémico del artículo 51 —el umbral de 10^25 FLOPs apunta al que entrena—. La cobertura de Confir de las obligaciones del proveedor de GPAI es parcial y está en la hoja de ruta, no completa. Para responsables del despliegue de organismos públicos, y para responsables del despliegue privados en solvencia (5(b)) y fijación de precios de seguros (5(d)), el artículo 27 añade una evaluación de impacto relativa a los derechos fundamentales obligatoria sobre la batería del proveedor.

Ejemplo práctico: una aseguradora mediana puntúa siniestros con Cortex sobre su almacén gobernado

Helvana Versicherung, una aseguradora de vida y salud de la UE de unos 900 empleados y alrededor de 310 millones de euros de volumen de negocios, ejecuta Cortex Analyst y un modelo de Cortex ML directamente sobre su almacén gobernado de siniestros y pólizas para evaluar el riesgo y fijar el precio de la cobertura de vida y salud.

La finalidad prevista es la evaluación de riesgos y la fijación de precios de seguros para personas físicas —anexo III, punto 5(d)—, así que el sistema es de alto riesgo bajo el artículo 6(2), y como elabora perfiles de personas la exención del artículo 6(3) no está disponible. Helvana lo compuso bajo su propio nombre, lo que la hace el proveedor bajo el artículo 16; sus suscriptores son responsables del despliegue internos, así que lleva ambos sombreros y aplica el artículo 27. Con un volumen de negocios por encima de los umbrales de pyme, el tope del artículo 99(6) no aplica. Sus etiquetas de columna, el enmascaramiento y la trazabilidad de ACCESS_HISTORY le dan sólidas bases de procedencia del artículo 10 y de logging del artículo 12 —pero aun así debe probar la representatividad y el examen de sesgos y firmar su propia evaluación del artículo 43—.

Artículo	Obligación para Helvana Versicherung
Artículo 9	Gestión de riesgos con pruebas de sesgo e impacto dispar
Artículo 10	Gobernanza de datos sobre los conjuntos de siniestros y pólizas (la trazabilidad del almacén como prueba)
Artículo 11 / Anexo IV	Documentación técnica del modelo, los datos y la configuración de Cortex
Artículo 12	Registro de puntuaciones, anulaciones y supervisión vía historial de consultas y acceso
Artículo 13	Instrucciones de uso
Artículo 14	Supervisión humana por los suscriptores
Artículo 15	Exactitud, robustez y seguridad
Artículo 27	Evaluación de impacto relativa a los derechos fundamentales
Artículo 43 / Anexo VI	Ruta de autoevaluación interna
Artículos 47 / 49	Declaración de conformidad y registro en la base de datos de la UE
Artículos 72-73	Vigilancia poscomercialización y notificación de incidentes

Calendario y sanciones: contra qué planificar en 2026

Las prohibiciones del artículo 5 aplican desde el 2 de febrero de 2025 (una prohibición adicional de CSAM/«nudifiers» y el marcado de contenido del artículo 50 aterrizan el 2 de diciembre de 2026), la alfabetización en IA del artículo 4 desde el 2 de febrero de 2025 y las obligaciones de GPAI de los artículos 51-55 desde el 2 de agosto de 2025.

Para los sistemas autónomos de alto riesgo del anexo III bajo el artículo 6(2), el Reglamento Ómnibus Digital aplaza la fecha de aplicación al 2 de diciembre de 2027. El texto fue adoptado en el voto del pleno del Parlamento (16 de junio de 2026) y la adopción formal del Consejo (29 de junio de 2026); entra en vigor con su publicación en el Diario Oficial, prevista antes del 2 de agosto de 2026. El aplazamiento usa fechas de calendario fijas; la variante de «parar el reloj» fue rechazada, así que no todo se aplaza. Los sistemas del anexo I integrados en producto (artículo 6(1)) marcan el 2 de agosto de 2027, aplazados al 2 de agosto de 2028.

Los niveles de sanción se fijan en el artículo 99: prácticas prohibidas hasta 35 M€ o el 7 % del volumen de negocios anual mundial total, la cifra que sea mayor (artículo 99(3)); alto riesgo y la mayoría de las infracciones de obligaciones hasta 15 M€ o el 3 % (artículo 99(4)); información incorrecta o engañosa a las autoridades hasta 7,5 M€ o el 1 % (artículo 99(5)). Para pymes y nuevas empresas, el artículo 99(6) limita la multa a la menor entre el porcentaje y la cantidad fija.

Cómo ayuda Confir

Registra cada sistema construido con Cortex como una entrada de inventario separada por finalidad prevista —no «Snowflake Cortex» como una sola línea—, luego clasifícalo bajo el artículo 6 y el anexo III con el filtro del artículo 6(3) y deriva el rol de proveedor o responsable del despliegue. Confir genera la documentación técnica del artículo 11 y el anexo IV, la declaración de conformidad del artículo 47 y una evaluación de impacto relativa a los derechos fundamentales del artículo 27 para los responsables del despliegue que cualifican, a partir de una única entrada en lenguaje sencillo. El motor de síntesis es determinista y basado en reglas —sin inferencia de modelos, sin alucinaciones—, así que la misma entrada siempre produce el mismo nivel de riesgo y rol, y la regla que se disparó es legible para las personas.

Preguntas frecuentes

¿Usar Snowflake Cortex hace a Snowflake responsable de mi cumplimiento de la Ley de IA de la UE?

No. Cortex es infraestructura. Compón un sistema sobre él bajo tu propio nombre y el artículo 3(3) te hace el proveedor; los deberes del artículo 16 son tuyos. Las atestaciones de Snowflake no son una evaluación de la conformidad del artículo 43.

Construyo con Cortex sobre mis propios datos gobernados — ¿soy el proveedor o el responsable del despliegue?

Normalmente el proveedor bajo el artículo 3(3). Eres responsable del despliegue (artículo 26) solo cuando ejecutas una función alojada sin modificar bajo el nombre de otro. Constrúyelo y opéralo internamente y llevas ambos sombreros.

Mis datos de Snowflake ya están gobernados con etiquetas y enmascaramiento — ¿no satisface eso el artículo 10?

No, aunque ayuda. Las etiquetas, el enmascaramiento y la trazabilidad de ACCESS_HISTORY son controles de acceso —prueba de procedencia—. La representatividad, la minimización de errores y el examen de sesgos del artículo 10 siguen siendo tuyos para realizar y documentar.

¿Un sistema que construyo sobre Cortex es automáticamente de alto riesgo?

No. Es de alto riesgo solo si cumple una función del anexo III —fijación de precios de seguros 5(d), solvencia 5(b), empleo punto 4— bajo el artículo 6(2). La mayor parte de la analítica de almacén no es de alto riesgo.

¿Qué significa el logging del artículo 12 para un pipeline de Cortex?

El artículo 12 necesita registro automático de eventos. Las consultas de Cortex son una superficie de registro natural: captura entradas, versiones de modelo y función, salidas y eventos de supervisión desde el principio —el historial de consultas y ACCESS_HISTORY ayudan—.

¿Cuándo aplican los plazos de alto riesgo a los sistemas construidos sobre Cortex?

El Reglamento Ómnibus Digital, ya adoptado (Parlamento el 16 de junio de 2026, Consejo el 29 de junio de 2026; entrada en vigor con la publicación en el Diario Oficial, prevista antes del 2 de agosto de 2026), aplaza los sistemas del anexo III al 2 de diciembre de 2027.

¿Cuáles son las sanciones si clasifico mal un sistema construido con Cortex?

Artículo 99: prácticas prohibidas hasta 35 M€ o el 7 % del volumen de negocios mundial (99(3)); infracciones de alto riesgo hasta 15 M€ o el 3 % (99(4)); información engañosa hasta 7,5 M€ o el 1 % (99(5)). Pymes con tope en la cifra menor (99(6)).

Guías relacionadas

Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar

Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 14 días.

Empieza la prueba gratuita →