Modificación de la IA con arreglo a la Ley de IA de la UE: Lecciones prácticas sobre clasificación y cumplimiento

Este artículo ha sido escrito por los profesionales del cumplimiento legal Øystein Endal, Andrea Vcric, Sidsel Nag, Nick Malter y Daylan Araz (véase la sección sobre los autores al final), basándose en su experiencia en la gestión o consultoría de empresas que integran la IA. Para cualquier pregunta o sugerencia, póngase en contacto con Nick Malter en nick@trail-ml.com.

Descargo de responsabilidad: Tenga en cuenta que la información proporcionada y comentada en el artículo no constituye ni pretende constituir asesoramiento jurídico. En caso necesario, solicite asesoramiento jurídico profesional. El contenido de la Ley de AI de la UE puede interpretarse de forma diferente a la indicada.

Próximamente en este post:

• Resumen
• Introducción
• Los problemas de las modificaciones con arreglo a la Ley de AI de la UE
  • Problemas habituales con las modificaciones de los modelos y sistemas de IA
• ¿Qué modificaciones pueden cualificarle como proveedor?
  • Modificaciones sustanciales de los sistemas de IA
  • Modificaciones sustanciales de los modelos GPAI
  • ¿Qué significa esto en la práctica?
• GenAI en acción: ejemplos de profesionales y retos pendientes
  • Caso 1: Proveedor de servicios informáticos a empresas
  • Caso 2: Plataforma de IA agéntica de ampliación
• De cara al futuro
  • Recomendaciones generales para las organizaciones
  • Acciones y recursos recomendados para la preparación de la Ley de AI de la UE
• Sobre los autores

Introducción

La Ley de la IA de la UE regula principalmente a los proveedores de modelos de IA de propósito general (GPAI) y sistemas de IA, estableciendo un marco global para el desarrollo y despliegue de la IA en la Unión Europea. Aunque la Ley de la IA de la UE identifica claramente como proveedor al desarrollador de un sistema de IA o modelo GPAI completamente nuevo, la situación se complica cuando alguien situado más abajo en la cadena de valor modifica un sistema de IA o modelo GPAI de terceros ya existente. Esto plantea cuestiones sobre las responsabilidades de cumplimiento, en concreto quién debe y puede cumplir las obligaciones de proveedor en virtud de la Ley de IA de la UE.

La Ley de IA de la UE reconoce los supuestos de modificación al definir las circunstancias en las que un modificador de un sistema de IA o modelo GPAI se convierte en proveedor, transfiriendo de hecho las obligaciones reglamentarias del proveedor original al modificador, ya sea parcial o totalmente.

Este cambio en las responsabilidades de cumplimiento, especialmente cuando se trata de sistemas de IA de alto riesgo o modelos GPAI, es un escenario que las empresas normalmente tratan de evitar debido al coste y la carga de cumplimiento adicionales. Clasificar erróneamente la función, la categoría de riesgo o el modelo de IA con arreglo a la Ley de IA de la UE supone un importante riesgo de cumplimiento para las empresas, ya que puede dar lugar a multas de hasta 15 millones de euros o el 3 % de los ingresos anuales globales por incumplimiento de las disposiciones sobre sistemas de IA de alto riesgo o modelos GPAI.

Con la entrada en vigor de las obligaciones de los proveedores de modelos GPAI a partir del 2 de agosto de 2025, los debates sobre las modificaciones de los modelos y sistemas de IA y las implicaciones de cumplimiento resultantes se han vuelto cada vez más urgentes y relevantes para las empresas.

En este artículo, un grupo de trabajo formado por miembros del AI Pact y pioneros en la adopción de la Ley de IA, analizamos la clasificación resultante de las modificaciones de la Ley de IA de la UE y debatimos los retos que plantea su cumplimiento desde la perspectiva de los profesionales. Nos centramos específicamente en los modelos y aplicaciones GPAI.

Los problemas de las modificaciones con arreglo a la Ley de AI de la UE

Debido a la amplitud de las definiciones de la Ley de IA de la UE, puede ser difícil para las empresas averiguar cuándo una modificación da lugar a obligaciones de proveedor para el modelo utilizado. La definición decisiva de "modificación sustancial" (véase el artículo 3, apartado 23) sigue estando vagamente descrita en la Ley de AI de la UE. Esto crea incertidumbre en las organizaciones.

El reto de una clasificación correcta es especialmente relevante cuando se consideran escenarios en los que las empresas construyen sistemas o aplicaciones sobre modelos GPAI, como el GPT-4.5 de OpenAI o el Sonnet 4 de Anthropic. Estos modelos están diseñados deliberadamente para ser adaptables a un amplio conjunto de casos de uso y para ser personalizados por los operadores posteriores de la cadena de valor. En estos casos, responder a la pregunta de quién debe cumplir qué obligaciones puede resultar difícil.

Hay iniciativas (en curso) de la Comisión Europea que pretenden aclarar conceptos de la Ley de IA. En cuanto a los sistemas de IA de alto riesgo, se están elaborando normas CEN/CENELEC cuya publicación está prevista para 2026. Estas normas proporcionarán orientaciones concretas sobre cómo obtener la presunción de conformidad con las disposiciones de la Ley de la IA de la UE sobre los sistemas de IA de alto riesgo, pero no se centran en los modelos GPAI. Por lo que respecta a los modelos GPAI, el Código de buenas prácticas GPAI de la Oficina de IA de la Comisión Europea se centra en el cumplimiento de las obligaciones de los proveedores de modelos GPAI, así como en los modelos GPAI con riesgo sistémico. El Código de buenas prácticas se ha complementado recientemente con directrices oficiales para los proveedores de GPAI (directrices GPAI). Aunque se trata de buenos primeros pasos, sigue habiendo incertidumbres sobre cuándo un modificador se convierte en proveedor en la práctica. 

Las directrices GPAI introducen un umbral de un tercio de la potencia de cálculo inicial necesaria para entrenar el modelo GPAI original (medido en FLOPs) como distinción entre modificaciones sustanciales e insustanciales. Este umbral pretende aclarar cuándo las obligaciones de cumplimiento pasan al modificador. Sin embargo, este umbral basado en la computación, aunque potencialmente útil para ciertas modificaciones como el ajuste fino, puede seguir siendo insuficiente para otros tipos de modificaciones que cambian sustancialmente el comportamiento y los riesgos del modelo sin requerir grandes recursos computacionales. Las directrices señalan que este umbral es meramente un criterio indicativo. De conformidad con el apartado 62 de las directrices GPAI, la regla general para determinar cuándo una modificación es sustancial se reduce a si las modificaciones pueden dar lugar a una modificación sustancial de la generalidad, las capacidades o el riesgo sistémico del modelo.

Dadas estas circunstancias, las organizaciones se enfrentan a retos a la hora de aplicar las medidas adecuadas para cumplir la Ley de IA de la UE, así como a la hora de determinar si sus casos de uso y modificaciones les cualifican para convertirse en un proveedor (modelo GPAI) en primer lugar.

¿Qué modificaciones pueden cualificarle como proveedor?

Antes de considerar si existe una modificación que pueda calificar a alguien de proveedor, se aconseja realizar una evaluación para determinar si el sistema o modelo en cuestión entra realmente en el ámbito de aplicación de las definiciones de sistema de IA o modelo GPAI de la Ley de IA de la UE. Esto puede parecer trivial, pero a la hora de clasificar la función operativa, a veces ha resultado difícil.

Existen varias formas de convertirse en proveedor con arreglo a la Ley de la IA de la UE, tanto a nivel de sistema de IA como de modelo de IA. En particular, la Ley de la IA de la UE esboza varios escenarios en los que una empresa que modifica o despliega un sistema de IA puede potencialmente heredar el papel y las responsabilidades de un proveedor:

• Integración de un modelo de IA existente en un sistema de IA nuevo o ya existente (véase el artículo 3, apartado 68).
• Rebranding de un sistema de IA de alto riesgo como producto propio (véase el artículo 25).
• Reutilización de un sistema o modelo de IA para que pase a ser de alto riesgo (véase el artículo 25)
• modificaciones (sustanciales) de un sistema de IA de alto riesgo existente o de un modelo de IPPVA (véase el artículo 25 y el considerando 109)

El primer caso se refiere a la definición de "proveedor intermedio " de la Ley de IA de la UE (véase el artículo 3, apartado 68), que probablemente describe mejor las circunstancias actuales de muchas organizaciones. Por ejemplo, introducir un modelo propio ("BYOM") en un sistema de IA puede considerarse una integración. Sin embargo, ser un proveedor intermedio no implica necesariamente un cambio en las responsabilidades de cumplimiento de los proveedores de modelos GPAI, ya que describe más bien el papel de un proveedor de sistemas de IA. En esta situación, una organización tendría que validar si se aplican el sistema de IA de alto riesgo o las obligaciones de transparencia, y si el proveedor ascendente del modelo GPAI ha excluido claramente la distribución y el uso del modelo dentro de la UE.

Mientras que el segundo y el tercer caso -rebranding y repurposing- suelen ser umbrales bastante sencillos para un cambio en la responsabilidad de cumplimiento, los casos que implican modificaciones sustanciales son más ambiguos y plantean importantes retos interpretativos para las organizaciones, como se ha descrito anteriormente.

Modificaciones sustanciales de los sistemas de IA

Según la Ley de IA, una modificación sustancial se refiere a un cambio de un sistema de IA que no ha sido previsto por la evaluación de conformidad del proveedor original, y que afecta al cumplimiento de los requisitos sobre sistemas de IA de alto riesgo o que afecta a la finalidad prevista del sistema de IA (véase el artículo 3, apartado 23, y el considerando 128). Obsérvese que la evaluación oficial de la conformidad de un sistema de IA de alto riesgo sólo puede realizarse cuando existen organismos notificados que realizan una auditoría externa o cuando pueden aplicarse las normas armonizadas (por CEN/CENELEC). Por tanto, en el momento de redactar el presente documento, esto no constituye todavía una orientación útil.

La Ley de IA aborda además las modificaciones explícitamente en el artículo 25, donde establece que las modificaciones sustanciales de un sistema de IA de alto riesgo desplazan el papel de proveedor al de modificador, pero sólo si el sistema sigue siendo de alto riesgo. Esto vincula el concepto de modificaciones sustanciales al impacto de la modificación en el nivel de riesgo.

Modificaciones sustanciales de los modelos GPAI

Sin embargo, cuando se trata de modificaciones de los modelos GPAI, la Ley de IA de la UE se vuelve menos definida. El considerando 109 y las FAQ de la Comisión Europea aclaran que las obligaciones del proveedor para los modelos GPAI se limitan al alcance de la modificación, pero la Ley de IA de la UE no vincula directamente las modificaciones de los modelos GPAI a niveles de riesgo específicos (sólo al riesgo sistémico o no sistémico). Además, la Ley de IA de la UE no habla explícitamente de modificaciones sustanciales en el contexto de los modelos IPAV, pero sí destaca explícitamente el ajuste fino de los modelos IPAV como modificación, lo que sugiere que la modificación también debe tener un efecto bastante sustancial en el modelo. La Oficina de AI confirma esto último en las directrices GPAI, ya que afirma que, en su opinión, las modificaciones suelen implicar el entrenamiento de un modelo con datos adicionales. Las directrices también se centran ampliamente en la puesta a punto y el reentrenamiento de un modelo GPAI.

Para apoyar aún más esta distinción, las directrices GPAI introducen un umbral basado en los recursos informáticos: si una modificación utiliza al menos un tercio de los recursos informáticos requeridos originalmente para entrenar el modelo, se presume que el modificador se ha convertido en proveedor de modelos GPAI. Aunque este umbral aporta cierta claridad, sus limitaciones se pusieron de manifiesto durante la consulta pública de las directrices y fueron reconocidas por la Oficina de IA. El umbral puede no captar las modificaciones de bajo cómputo que siguen afectando sustancialmente al perfil de riesgo de un modelo, y puede ser difícil para los modificadores estimar de forma fiable el cómputo requerido, especialmente sin acceso a la información de los proveedores anteriores. La Comisión Europea optó por fijar umbrales relativamente altos, y actualmente espera que sólo unos pocos modificadores se conviertan en proveedores de modelos GPAI.

Una vez más, el umbral es un criterio indicativo, y otras modificaciones de los modelos también podrían considerarse modificaciones sustanciales. Queda por saber si la lógica centrada en el riesgo del artículo 25 (el artículo que regula los cambios en los casos de sistemas de IA de alto riesgo) es también aplicable a las modificaciones de los modelos GPAI, como sugieren algunos.

Una modificación de un modelo de IA puede adoptar muchas formas. Como señalan Philipp Hacker y Matthias Holweg (2025), los tipos más relevantes de modificaciones de un modelo de IA pueden agruparse en las siguientes categorías:

• Sin modificaciones: Utilización de un modelo de IA preentrenado sin modificaciones.
• Modificación de hiperparámetros: Ajuste de parámetros como la temperatura.
• Generación mejorada por recuperación (RAG): Creación de aplicaciones que mejoran los resultados de un modelo haciendo referencia a una base de conocimientos externa o a datos propios.
• GPT personalizados: Creación de variantes de modelos base con instrucciones, herramientas y personalidades especificadas.
• Ajuste: Entrenamiento del modelo base en conjuntos de datos propios o específicos del dominio para adaptar su rendimiento.

Destilación de modelos o conocimientos: Entrenamiento de un modelo "alumno" más pequeño basado en los resultados de un modelo "maestro" más grande, a menudo para reducir los requisitos computacionales.

Como sostienen Hacker y Holweg (2025), las modificaciones sustanciales, es decir, los cambios sustanciales en los perfiles de riesgo o el comportamiento del modelo, se dan en casos de ajuste, destilación del modelo, "jailbreaking" mediante la manipulación de parámetros o el cambio de la arquitectura central de un modelo. Otras modificaciones, especialmente cuando no cambian el perfil de riesgo, la arquitectura, la generalidad o la finalidad prevista de un modelo de IA, son probablemente insustanciales, lo que significa que no provocan un cambio en las obligaciones del proveedor de modelos GPAI.

¿Qué significa esto en la práctica?

Siguiendo la lógica más general de la Ley de IA de la UE, es útil anclar la evaluación de si hay un cambio en las responsabilidades de cumplimiento, tanto en lo que respecta a los sistemas de IA como a los modelos GPAI, en una evaluación de si la modificación es sustancial o insustancial, lo que a su vez requiere examinar el efecto de la modificación en los riesgos.

En el caso de los sistemas de IA, el ejercicio es relativamente claro: las empresas que modifiquen los sistemas de IA deben revisar si los cambios afectan a la clasificación de riesgo del sistema, por ejemplo, aclarando si pasa a ser de alto riesgo o sigue siéndolo.

En el caso de los modelos GPAI, el ejercicio es un poco más complejo. Hasta que se disponga de más orientaciones y se establezcan normas, las empresas que modifiquen los modelos GPAI pueden considerar dos enfoques:

1. Un enfoque más conservador, tratando cualquier adaptación como un posible desencadenante de un cambio en las obligaciones del proveedor del modelo GPAI por defecto. Esto incluye esencialmente el mantenimiento de documentación y resúmenes de las modificaciones realizadas, aunque no sean obligatorios.
2. Un enfoque más pragmático, según el cual se supone que las obligaciones del proveedor del modelo GPAI sólo se aplican si la modificación altera claramente el comportamiento, la generalidad o el perfil de riesgo del modelo, o si se cumplen los umbrales de cálculo. Este enfoque limita las cargas de gobernanza, pero puede exigir justificaciones más sólidas en caso de impugnación.

En cualquier caso, las empresas deben llevar a cabo evaluaciones de riesgo e impacto al realizar cualquier cambio en los modelos GPAI o en los sistemas de IA (de alto riesgo).

GenAI en acción: ejemplos de profesionales y retos pendientes

Para dar una idea de los retos actuales a los que se enfrentan los profesionales cuando se trata de la categorización correcta, hemos reunido algunos casos de ejemplo reales (parcialmente anonimizados). También destacamos otros retos de cumplimiento de la Ley de IA relacionados con casos de GenAI, que aún están por resolver, así como otras buenas prácticas.

Caso 1: Proveedor de servicios informáticos a empresas

Un proveedor de servicios informáticos para empresas utiliza el modelo GPT-4 de OpenAI para proporcionar y vender una plataforma que orquesta diferentes chatbots en una solución centralizada. Los usuarios finales pueden entonces chatear con los bots para acceder a conocimientos generales, pero también a los conocimientos internos de su empresa, dentro de un entorno seguro. Se trata de un caso muy común de "GPT personalizada", en el que el proveedor de servicios limita sus modificaciones a cambios en los avisos y a la adición de técnicas RAG, al tiempo que distribuye el sistema con un nuevo nombre.

Las siguientes consideraciones fueron especialmente relevantes para el proveedor de servicios informáticos a la hora de evaluar el cumplimiento:

1. En primer lugar, no estaba claro si la construcción de robots personalizados en torno al modelo GPT-4 y la prestación de servicios bajo su propia marca les califica como proveedores del modelo GPAI.
2. En segundo lugar, existía confusión sobre si el plazo del 2 de agosto de 2025 del PAMI se aplica a su negocio de venta de soluciones basadas en GPT sin modificar sustancialmente el modelo básico.
3. En tercer lugar, luchan por garantizar que OpenAI entregue la documentación requerida.

Si bien el proveedor de servicios informáticos sí reúne los requisitos para ser considerado proveedor de servicios derivados, debido a la integración del modelo de OpenAI, no se califican a sí mismos como proveedores de un sistema de IA de alto riesgo (excluido en la política de uso y limitado por medios técnicos) ni como proveedores del modelo GPAI debido al alcance muy limitado de la modificación, que no cambia significativamente el riesgo del modelo. En este caso, y al menos a efectos de cumplimiento, no necesitan basarse en la documentación de OpenAI y no se enfrentan a obligaciones adicionales en virtud de las disposiciones del modelo GPAI. El proveedor de servicios informáticos consultó con la empresa de cumplimiento de uno de los autores, Trail, y decidió seguir un planteamiento conservador, es decir, conservar suficiente documentación técnica en torno a la arquitectura y funcionalidad del sistema GPAI, que de todos modos debería estar disponible para fines de desarrollo.

Caso 2: Plataforma de IA agéntica de ampliación

Unique AI, una empresa suiza, ofrece una plataforma para crear soluciones de inteligencia artificial que ayudan a bancos, aseguradoras y empresas de capital riesgo a mejorar sus operaciones financieras. Entre ellas se incluyen flujos de trabajo como la investigación de inversiones, la diligencia debida y los procesos KYC. El principal reto aquí era garantizar el cumplimiento y la seguridad adecuada de los agentes de IA capaces de realizar acciones de forma independiente. Sin embargo, el papel en virtud de la Ley de IA de la UE no estaba claro al principio.

Unique AI llevó a cabo una investigación en profundidad sobre la Ley de IA de la UE, tanto internamente como con el apoyo de un bufete de abogados, WalderWyss, donde obtuvieron un dictamen jurídico sobre el posicionamiento de Unique AI en relación con la Ley de IA de la UE. En función de la configuración del cliente y del modelo de implantación, Unique AI puede desempeñar diversas funciones con arreglo a la Ley de la UE sobre la IA.

La mayoría de los clientes optaron por un modelo de despliegue de inquilino único en el que Unique AI aloja y ejecuta el software. Basándose en la interpretación jurídica de la Ley de IA de la UE, el enfoque operativo de Unique les sitúa como distribuidor más que como proveedor, al tiempo que pone a disposición los sistemas y modelos de IA. Esto se debe a que Unique AI aprovecha los productos comerciales de IA existentes, como los modelos de Microsoft Azure y OpenAI, y los enriquece con funcionalidades específicas del contexto mediante técnicas de encadenamiento de instrucciones, RAG e instrucciones a SQL, sin alterar el Modelo de Lenguaje Amplio (LLM) original. Unique AI no utiliza datos de clientes para la formación de modelos y excluye el uso para fines de alto riesgo, lo que respalda aún más esta clasificación. Por lo tanto, la empresa no se considera un modificador del modelo GPAI y las obligaciones del proveedor del modelo GPAI siguen estando del lado de los proveedores ascendentes.

Han adoptado un marco de gobernanza de la IA, que sirve de base para el desarrollo de su IA agéntica, incorporando confianza, seguridad, responsabilidad, fiabilidad y transparencia en la arquitectura central de cada agente inteligente y flujo de trabajo, mientras que la evaluación comparativa interna periódica evita la deriva del modelo y mantiene una calidad constante en todos los casos de uso.

Para trabajar de forma proactiva en el cumplimiento de la Ley de IA, Unique AI llevó a cabo una evaluación de conformidad interna siguiendo la metodología de David Rosenthal en junio de 2024, dirigida por el Director de Seguridad de la Información y el Director de Datos de la empresa.

A medida que el panorama normativo sigue evolucionando, la empresa mantiene un enfoque orientado al futuro mediante actualizaciones continuas de su marco público de gobernanza de la IA, la participación activa en consultas normativas y la colaboración abierta y transparente con sus homólogos del sector a través de iniciativas como las mesas redondas anuales sobre gobernanza de la IA.

De cara al futuro

A medida que la Ley de Inteligencia Artificial de la UE avanza en su fase de aplicación, sigue habiendo cuestiones abiertas y problemas de cumplimiento, específicamente para las empresas que integran y modifican modelos y sistemas de IA.

En cualquier caso, las obligaciones generales para los proveedores de modelos GPAI son manejables, ya que se limitan esencialmente a mantener la documentación técnica y los resúmenes dentro del ámbito de las modificaciones. Por supuesto, los proveedores de modelos GPAI con riesgo sistémico se enfrentan a requisitos de cumplimiento más complejos. La Oficina de IA asume que, a día de hoy, sólo unas pocas modificaciones posteriores cumplirían los respectivos umbrales de cómputo que desencadenarían un cambio en las responsabilidades de cumplimiento. Se están elaborando orientaciones adecuadas, y se dispone de suficientes indicios y proxies que permiten tanto a los integradores como a los modificadores trabajar mientras tanto hacia el cumplimiento de la Ley de IA de la UE.

La Oficina de IA también ha indicado en las directrices del PAMI que los proveedores de modelos del PAMI, incluidos los que realizan modificaciones, que prevean dificultades de cumplimiento con respecto al plazo de agosto de 2025 deben ponerse en contacto de forma proactiva con la Oficina de IA a través de su servicio de atención de la Ley de IA, puesto en marcha recientemente. Los servicios de la Ley de IA creados por los distintos Estados miembros de la UE, como los de Alemania y Austria, pueden ser otra opción para ponerse en contacto de forma proactiva con las autoridades en casos complejos.

Además, muchos grandes proveedores de modelos de GPAI se han comprometido con el Código de Prácticas de GPAI, incluidos OpenAI, Anthropic, Google y Mistral, lo que indica que también existe la intención de apoyar a los operadores posteriores con la documentación adecuada sobre los modelos de IA. Esto puede ayudar a mitigar la falta de transparencia de los proveedores, como se ha destacado anteriormente, en los próximos meses.

Recomendaciones generales para las organizaciones

Si le preocupan las modificaciones de los modelos y sistemas GPAI con arreglo a la Ley de IA de la UE, revise las directrices oficiales GPAI de la Oficina de IA y empiece a evaluar los casos de uso según las interpretaciones de la Oficina de IA. Las directrices incluyen más ejemplos de cuándo una organización debe considerarse proveedora de modelos de IPPAM.

Las organizaciones que ya han empezado a pensar en el cumplimiento de la Ley de IA de la UE de forma más detallada deberían aprovechar el impulso y poner en marcha iniciativas de gobernanza de la IA de forma proactiva, teniendo en cuenta que la gobernanza de la IA es mucho más amplia que el cumplimiento de la normativa. de la Comisión Europea Los programas voluntarios como el Pacto por la IA de la Comisión Europea ofrecen oportunidades para el intercambio entre homólogos en torno a la Ley de IA de la UE y pueden ayudar a conseguir la aceptación interna y a concienciar sobre la gobernanza de la IA. Los colaboradores de este artículo, por ejemplo, crearon de forma proactiva una pequeña comunidad informal de miembros del Pacto de IA ("AIPEX") a principios de este año para debatir los retos actuales y las soluciones a los mismos en reuniones directas, y los miembros de la Oficina de IA se tomaron la molestia de participar en una de sus reuniones.

Sobre los autores

Del grupo informal AI Pact Exchange Group ("AIPEX"):

• Øystein EndalDirector de Riesgos y Cumplimiento Normativo de IA en el sector de servicios financieros y seguros.
• Andrea VrcicAsesora jurídica en materia de regulación de la IA en el sector de los servicios financieros y los seguros.
• Sidsel Nagresponsable de ética, regulación y gobernanza de la IA en el sector de la consultoría, y miembro del Comité Danés de Normalización.
• Nick MalterDirector de política y gobernanza de IA en trail GmbH, empresa de software de gobernanza de IA. Iniciador del grupo AIPEX.

De Unique AI:

Daylan Araz es Responsable de Cumplimiento de Datos en Unique AI en Zúrich. Ha desempeñado un papel decisivo en el desarrollo del marco integral de gobernanza de la IA de Unique. Ha desempeñado un papel principal en la obtención de la certificación ISO 42001, además de contribuir a las certificaciones ISO 27001, ISO 9001 y SOC 2. Si desea más información, póngase en contacto con: aigovernance@unique.ai.