Operaciones de coma flotante (FLOP): el patrón de medida del riesgo sistémico de la Ley de IA

Una operación de coma flotante (FLOP) es un único cálculo aritmético sobre un número decimal: una multiplicación, una suma. Por sí sola es una unidad de la ingeniería informática, no del derecho. Pero la Ley de IA la toma prestada para una función precisa: es la métrica que decide si se presume que un modelo de IA de uso general (GPAI) conlleva riesgo sistémico. Conforme al artículo 51(2) del Reglamento (UE) 2024/1689, se presume que un modelo GPAI tiene capacidades de gran impacto (y, por tanto, riesgo sistémico) cuando el cómputo acumulado utilizado para entrenarlo supera las 10²⁵ FLOP. Esa cifra es el umbral más citado de la Ley, y es la razón entera por la que un término de glosario sacado de la aritmética se gana un sitio en una norma de cumplimiento.

Esta página explica el umbral, qué cuenta para alcanzarlo, por qué el legislador eligió un indicador de cómputo y la facultad de la Comisión para mover la línea.

La presunción del artículo 51(2)

El artículo 51 establece cómo un modelo GPAI pasa a ser un modelo de riesgo sistémico. El artículo 51(1) dice que un modelo tiene riesgo sistémico si posee capacidades de gran impacto (evaluadas frente a metodologías apropiadas) o si lo designa la Comisión. El artículo 51(2) aporta entonces el indicador de línea clara: se presume que un modelo GPAI tiene capacidades de gran impacto cuando la cantidad acumulada de cálculo utilizada para su entrenamiento, medida en FLOP, es superior a 10²⁵.

Tres rasgos de esa redacción importan:

• Es una presunción, no una regla irrebatible. Un proveedor por encima de 10²⁵ FLOP se presume de riesgo sistémico, pero puede argumentar, a través del procedimiento del artículo 52, que su modelo no presenta de hecho capacidades de gran impacto. La carga recae en el proveedor.
• Es el cómputo de entrenamiento acumulado: el total a lo largo de la(s) ejecución(es) de entrenamiento, no la capacidad pico del hardware ni el coste de inferencia.
• Cruzarlo activa un deber de notificación. Un proveedor que sepa, o pueda razonablemente prever, que su modelo cruzará las 10²⁵ FLOP debe notificarlo a la Comisión sin demora y, en cualquier caso, antes de que transcurran dos semanas desde que se cumpla el umbral o se sepa que va a cumplirse, conforme al artículo 52(1).

La consecuencia de ser un modelo de riesgo sistémico es el conjunto de obligaciones más pesado del artículo 55 (evaluación del modelo, pruebas de adversación, notificación de incidentes graves a la Oficina de IA y ciberseguridad), superpuesto a los deberes del artículo 53 que recaen sobre todos los proveedores de GPAI.

Qué significa de verdad 10²⁵ FLOP

10²⁵ es diez cuatrillones: un 1 seguido de 25 ceros. Para ponerlo en términos humanos: un único chip acelerador de IA de gama alta funcionando a pleno rendimiento durante un año entero produce del orden de 10²² a 10²³ FLOP. Alcanzar las 10²⁵ requiere, por tanto, miles de chips así funcionando durante semanas o meses: la escala de las mayores ejecuciones de entrenamiento de modelos fundacionales, las que operan un puñado de laboratorios bien financiados. Está fijado deliberadamente alto. La intención del legislador era capturar la frontera de los modelos más grandes, no el ajuste fino corriente, no el modelo empresarial habitual y, desde luego, no los sistemas que una pequeña empresa de la UE construye sobre el modelo de otro.

Qué cuenta para el total acumulado

La Ley vincula la medida al cómputo "utilizado para entrenar" el modelo, acumulado a lo largo del proceso de desarrollo. En la práctica, las preguntas con las que lidian los proveedores son:

• Preentrenamiento más entrenamiento posterior. El total es acumulado, así que la ejecución principal de preentrenamiento es el grueso, pero el cómputo añadido en etapas posteriores de entrenamiento a gran escala cuenta para el total corriente.
• Ajuste fino y adaptación. La mayor parte del ajuste fino es órdenes de magnitud más pequeño que el preentrenamiento, así que rara vez mueve a un modelo a través de la línea por sí solo. Pero un proveedor que realice un entrenamiento continuado muy grande o reentrenamientos repetidos debe calcular la cifra acumulada y documentar el resultado, porque el umbral va del total, no de una sola ejecución.
• Estimación, no medición perfecta. El cómputo de entrenamiento se estima normalmente a partir de la arquitectura del modelo, el tamaño del conjunto de datos y el número de pasos de entrenamiento (la conocida aproximación de unas seis FLOP por parámetro y por token de entrenamiento), en vez de contar operación de hardware por operación de hardware. La Ley espera una estimación defendible y documentada.

El punto práctico de cumplimiento: un proveedor cercano al umbral debe ser capaz de mostrar sus cálculos. La cifra, el método y los supuestos pertenecen a la documentación técnica, porque el procedimiento del artículo 52 puede exigir al proveedor que demuestre si el umbral aplica.

¿Por qué un indicador de cómputo?

Lo que de verdad le importa al derecho es la capacidad: un modelo que pueda habilitar materialmente daños a gran escala. Pero la "capacidad" no tiene unidad de medida acordada, y esperar a que el daño se manifieste antes de regular un modelo fronterizo frustraría el propósito. El cómputo es un indicador imperfecto pero medible, objetivo y prospectivo: se correlaciona con la capacidad, puede estimarse antes incluso de que un modelo se publique y no depende del juicio subjetivo de un regulador sobre lo peligroso que "parece" un modelo.

Las contrapartidas son reales y el legislador las conocía. Un umbral de cómputo infravalora los modelos que logran una capacidad alta de forma eficiente (con mejores datos, arquitectura o postentrenamiento) con menos cómputo. También puede sobrevalorar un modelo grande pero anodino. Por eso, precisamente, el artículo 51 acompaña la presunción de FLOP con dos vías correctoras: la designación de la Comisión basada en la capacidad conforme al artículo 51(1) para modelos por debajo del umbral que, no obstante, tienen capacidades de gran impacto, y la alerta cualificada del artículo 90 del grupo de expertos científicos para modelos que el umbral no detectaría. La cifra es un cable trampa, no la prueba entera.

La Comisión puede mover el umbral

La cifra de 10²⁵ FLOP no está congelada. El artículo 51(3) faculta a la Comisión para adoptar actos delegados que modifiquen los umbrales del artículo 51 y completen los parámetros e indicadores, a la luz de la evolución tecnológica (como las mejoras algorítmicas o el aumento de la eficiencia del hardware), de modo que el umbral siga reflejando el estado de la técnica. A medida que el cómputo se abarata y los modelos se vuelven más capaces por FLOP, el legislador previó que la línea habría que revisarla. Así que trata las 10²⁵ FLOP como la cifra actual, sujeta a modificación por acto delegado, y no como una constante permanente.

Por qué la mayoría de las pymes están muy lejos de esto

Para las pequeñas y medianas empresas de la UE que forman el público central de Confir, este umbral es casi siempre académico, y conviene decirlo con claridad, porque la cifra de 10²⁵ se malinterpreta muy a menudo como un disparador general de la Ley de IA. No lo es. Rige quién entrena modelos GPAI fronterizos. Si tu empresa despliega ChatGPT, construye un producto sobre la API de OpenAI, hace ajuste fino de un modelo abierto de tamaño medio o ejecuta el modelo de un proveedor en su flujo de trabajo, no cruzas las 10²⁵ FLOP y la presunción de riesgo sistémico no te toca. Tus obligaciones vienen de un lugar completamente distinto: tu papel como proveedor o responsable del despliegue de un sistema de IA, clasificado por su uso conforme al artículo 6, no por el cómputo de entrenamiento.

Ejemplo trabajado: un equipo de SaaS comprueba si el umbral le afecta

Tessadat GmbH, una empresa alemana de SaaS de analítica con unos 55 empleados y unos 11 millones de euros de facturación, hace ajuste fino de un modelo de lenguaje de pesos abiertos de tamaño medio con sus propias transcripciones de atención al cliente para alimentar un asistente integrado en el producto. Su responsable de cumplimiento se hace la pregunta correcta: ¿el umbral de 10²⁵ FLOP convierte a Tessadat en proveedor de un modelo GPAI de riesgo sistémico?

La aritmética lo responde. El preentrenamiento del modelo base lo realizó un tercero; el ajuste fino de Tessadat consumió del orden de 10²⁰ FLOP, cinco órdenes de magnitud por debajo de 10²⁵. Incluso acumulando cada ejecución de entrenamiento que Tessadat haya hecho jamás, el total está muy lejos de la línea. Así que el artículo 51(2) no aplica, no hay notificación del artículo 52 y no hay deberes de riesgo sistémico del artículo 55. Las obligaciones reales de Tessadat fluyen de su papel: es un proveedor posterior de una funcionalidad de IA, clasifica el asistente por su uso conforme al artículo 6 (un chatbot de soporte suele ser de riesgo limitado, con la transparencia del artículo 50 de que los usuarios interactúan con una IA) y cumple los deberes de proveedor de lo que despacha. El responsable de cumplimiento documenta la estimación de FLOP y la conclusión de no aplicabilidad (registrada, no asumida en silencio) y pasa a los deberes que de verdad se aplican.

Cómo ayuda Confir

El motor basado en reglas de Confir delimita si tu organización se sitúa siquiera en la capa de los modelos GPAI, de modo que un proveedor o responsable del despliegue posterior nunca se enrute por error hacia un territorio de riesgo sistémico que no ocupa. Cuando la cuestión es genuinamente real, el motor marca el umbral del artículo 51(2) y la vía de notificación del artículo 52; cuando no lo es, te enruta limpiamente hacia tus deberes reales de proveedor o responsable del despliegue. La lógica es determinista: el mismo cuestionario produce la misma conclusión, y la regla que se activó es legible.

Preguntas frecuentes

¿Qué es el umbral de FLOP en la Ley de IA?

Conforme al artículo 51(2), se presume que un modelo de IA de uso general tiene capacidades de gran impacto (y, por tanto, riesgo sistémico) cuando el cómputo acumulado utilizado para entrenarlo supera las 10²⁵ operaciones de coma flotante (FLOP). Cruzarlo presume al modelo dentro de la categoría de riesgo sistémico, activa una notificación a la Comisión conforme al artículo 52 y añade las obligaciones del artículo 55 al proveedor del modelo. La presunción puede rebatirse a través del procedimiento del artículo 52.

¿El umbral de 10²⁵ FLOP aplica a mi empresa si solo uso o hago ajuste fino de un modelo?

Casi con seguridad, no. El umbral es la escala de las mayores ejecuciones de entrenamiento fronterizas: miles de aceleradores durante semanas. Usar un modelo, construir sobre una API o hacer ajuste fino de un modelo de tamaño medio consume cómputo muchos órdenes de magnitud por debajo de 10²⁵ FLOP. Tus obligaciones vienen de tu papel como proveedor o responsable del despliegue de un sistema de IA, clasificado por su uso conforme al artículo 6, no del cómputo de entrenamiento.

¿El umbral de FLOP es lo mismo que ser de alto riesgo?

No. La presunción de 10²⁵ FLOP concierne a los modelos GPAI de riesgo sistémico conforme al capítulo V (artículos 51-55). La clasificación de alto riesgo concierne a los sistemas de IA conforme al artículo 6 y al anexo III. Son regímenes separados, con sujetos, plazos y conjuntos de obligaciones distintos. Una cifra de cómputo no tiene incidencia en si un sistema de selección de personal o de puntuación crediticia es de alto riesgo: eso depende del uso.

¿Qué cuenta para el cómputo de entrenamiento acumulado?

El cómputo total utilizado para entrenar el modelo, acumulado a lo largo de las etapas de entrenamiento. El preentrenamiento es normalmente el grueso; un entrenamiento continuado grande o un reentrenamiento repetido se suman a él; el ajuste fino corriente suele ser demasiado pequeño para mover a un modelo a través de la línea por sí solo. La cifra se estima a partir del tamaño del modelo, el tamaño del conjunto de datos y los pasos de entrenamiento, en vez de contarse operación por operación, y la estimación y su método pertenecen a la documentación técnica.

¿Puede la Comisión cambiar el umbral de 10²⁵ FLOP?

Sí. El artículo 51(3) permite a la Comisión adoptar actos delegados que modifiquen los umbrales y completen los parámetros a la luz de la evolución tecnológica, por ejemplo, a medida que algoritmos y hardware se vuelven más eficientes. Así que 10²⁵ FLOP es la cifra actual, no una permanente. Los proveedores cercanos a la línea deberían seguir las modificaciones en vez de dar por fijo el umbral.

¿Qué ocurre si un modelo cruza las 10²⁵ FLOP?

El proveedor debe notificarlo a la Comisión conforme al artículo 52, sin demora y, en cualquier caso, en un plazo de dos semanas desde que se cruce el umbral o se sepa que se cruzará (en una ejecución planificada, normalmente antes de alcanzarlo). Se presume entonces que el modelo tiene riesgo sistémico, y el proveedor asume las obligaciones del artículo 55 (evaluación del modelo, pruebas de adversación o red-teaming, notificación de incidentes graves a la Oficina de IA y ciberseguridad), por encima de los deberes de GPAI básicos del artículo 53. El proveedor puede intentar rebatir la presunción a través del artículo 52.

Guías relacionadas

• Riesgo sistémico: definición y obligaciones: la categoría dentro de la cual el umbral de FLOP presume a un modelo
• Artículo 51: clasificación de riesgo sistémico: el mecanismo completo de presunción, designación y decisión de la Comisión
• Modelo de IA de uso general: la única categoría a la que aplica el umbral de FLOP
• Grupo de expertos científicos independientes: el órgano que puede señalar modelos capaces por debajo del umbral
• Cumplimiento de GPAI: el programa práctico del capítulo V
• Proveedor frente a responsable del despliegue: la distinción de papeles que de verdad rige a la mayoría de las empresas