La Comisión aclara qué es un sistema de IA en el AI Act. Y no, no todo software con estadísticas entra en el saco

La primera batalla del AI Act no va de modelos fundacionales, ni de deepfakes, ni de sanciones millonarias. Va de una pregunta mucho más básica y bastante más incómoda: qué demonios cuenta exactamente como “sistema de IA”. La Comisión Europea ha publicado por fin sus directrices sobre la definición de sistema de IA para facilitar la aplicación de las primeras normas del reglamento. Puede sonar menor. No lo es. De esa definición depende quién entra en el perímetro regulatorio, quién puede seguir respirando como “software tradicional” y quién va a tener que empezar a documentar, gobernar y justificar decisiones con bastante más rigor.

El movimiento llega en un momento delicado. El AI Act, aprobado como Reglamento (UE) 2024/1689, empezó a desplegarse por fases tras su entrada en vigor el 1 de agosto de 2024. Sus obligaciones no aterrizan todas de golpe. Algunas de las primeras disposiciones ya son relevantes para el mercado, incluida la prohibición de ciertas prácticas y la necesidad de entender si un producto, servicio o componente cae o no bajo la definición legal del artículo 3(1). Dicho de otro modo: antes de discutir si una herramienta es de alto riesgo, si exige evaluación de conformidad o si activa deberes de transparencia, hay que resolver si estamos ante IA en el sentido del reglamento. Y ahí estaba el atasco.

La guía de la Comisión intenta resolver ese atasco con una mezcla de precisión jurídica y pedagogía técnica. También deja algo claro: Bruselas no quiere que las empresas usen la ambigüedad como escondite, pero tampoco quiere convertir cualquier hoja de cálculo con una regresión lineal en un expediente regulatorio andante. El equilibrio no es trivial. Si el concepto es demasiado amplio, el AI Act se vuelve impracticable. Si es demasiado estrecho, media industria intentará reetiquetar sus productos para salir por la puerta de atrás.

Por qué esta guía importa más de lo que parece

En regulación tecnológica, las definiciones suelen decidir más que los titulares políticos. La razón es simple: una vez que el regulador fija el perímetro, el resto del edificio normativo empieza a caer por su propio peso. En el AI Act, la cadena es bastante directa. Si un producto encaja como sistema de IA bajo el artículo 3(1), entonces puede quedar sujeto —según su uso, sector y riesgo— a obligaciones de gobernanza, gestión del riesgo, calidad de datos, documentación técnica, trazabilidad, supervisión humana, ciberseguridad, registro o transparencia. Si no encaja, esas capas no aplican por esta vía, aunque puedan seguir vivas otras normas: GDPR, derecho de consumo, responsabilidad de producto, normativa sectorial financiera o laboral.

Esto tiene una consecuencia operativa inmediata: la definición no es un ejercicio académico para abogados con tiempo libre. Es una decisión de clasificación que afecta a compras, contratos, inventarios tecnológicos, estrategia de producto, disclosure comercial y controles internos. En una entidad financiera, por ejemplo, la misma herramienta de scoring, vigilancia de fraude, onboarding digital o monitorización de comunicaciones puede activar no solo el AI Act, sino también exigencias cruzadas de DORA, GDPR y gobernanza de modelos. Si la clasificación inicial falla, todo lo demás nace torcido.

La propia estructura del reglamento explica la ansiedad del mercado. El AI Act distingue entre prácticas prohibidas, sistemas de alto riesgo, obligaciones de transparencia para ciertos usos y un régimen específico para modelos de IA de propósito general. Pero antes de entrar en cualquiera de esas categorías, hay una puerta de entrada: ser un “machine-based system” diseñado para operar con distintos niveles de autonomía y capaz de generar salidas como predicciones, contenidos, recomendaciones o decisiones que influyen en entornos físicos o virtuales. La frase, heredera del trabajo de la OCDE y pasada por el tamiz legislativo europeo, es lo bastante técnica como para generar debate y lo bastante abierta como para invitar al oportunismo.

Ese oportunismo ya se veía venir. En los últimos dos años, demasiados proveedores han vendido como “IA” herramientas que son poco más que automatización con marketing brillante. Y, al mismo tiempo, otros tantos han empezado a sugerir justo lo contrario: que su producto no es IA, sino analítica avanzada, reglas expertas, optimización matemática o software estadístico, a ver si cuela y así esquivan el nuevo régimen. La Comisión ha entrado precisamente en esa zona gris.

Qué dice la definición legal y dónde estaban las dudas reales

El punto de partida es el artículo 3(1) del AI Act. Ahí se define el sistema de IA como un sistema basado en máquinas, diseñado para operar con distintos niveles de autonomía, que puede mostrar capacidad de adaptación tras su despliegue y que, para objetivos explícitos o implícitos, infiere a partir de la entrada que recibe cómo generar salidas como predicciones, contenidos, recomendaciones o decisiones capaces de influir en entornos físicos o virtuales.

La definición parece compacta. En la práctica, cada fragmento abría una discusión distinta.

La primera duda era la palabra “infiere”. No se eligió por capricho. La inferencia intenta separar los sistemas que derivan resultados a partir de datos, modelos o lógica aprendida de aquellos que se limitan a ejecutar instrucciones completamente predefinidas por humanos. Esa frontera importa. Un sistema puramente determinista, basado en reglas fijas del tipo “si pasa A, entonces haz B”, no encaja del mismo modo que un modelo que estima probabilidades, clasifica patrones o genera contenido a partir de entrenamiento o razonamiento computacional.

La segunda duda era la autonomía. El reglamento habla de “distintos niveles” de autonomía, no de autonomía total. Es una elección deliberada para evitar la escapatoria fácil de decir: “mi sistema siempre tiene un humano que valida el resultado, así que no es IA”. No funciona así. Un sistema puede seguir siendo IA aunque su salida sea revisada por una persona. La supervisión humana es un control; no convierte mágicamente el sistema en software ordinario.

La tercera era la adaptabilidad tras el despliegue. Aquí el matiz es fino y la guía lo es todavía más. La capacidad de adaptación puede existir, pero no es un requisito absoluto en todos los casos. Es decir, un sistema no deja de ser IA solo porque no siga aprendiendo una vez puesto en producción. Esto es esencial para no excluir modelos estáticos entrenados antes del despliegue, que siguen siendo IA aunque no se autoajusten en tiempo real.

La cuarta duda estaba en la lista de salidas: predicciones, contenidos, recomendaciones o decisiones. La lista es amplia a propósito. Cubre desde un clasificador de fraude hasta un generador de texto, pasando por sistemas de recomendación, motores de priorización o herramientas de soporte a decisiones clínicas, financieras o laborales. Lo que une a todos no es el sector, sino la forma de producir una salida que influye en una realidad física o virtual.

La quinta era la más peliaguda: cómo distinguir IA de software convencional. Y aquí es donde las guías de la Comisión juegan su partido de verdad.

El mensaje central de Bruselas: la inferencia separa la IA del software clásico

Si hubiera que condensar las directrices en una sola idea, sería esta: no todo software que procesa datos o automatiza tareas es un sistema de IA bajo el AI Act. La Comisión pone el foco en la capacidad del sistema para inferir cómo producir una salida, y no en la mera ejecución de una lógica preprogramada. Dicho sin jerga: una calculadora sofisticada sigue siendo una calculadora; un modelo que aprende patrones o estima resultados con base en datos ya juega en otra liga.

Esta distinción tiene bastante más miga de la que parece. Pensemos en cuatro categorías habituales dentro de una organización:

Un sistema basado solo en reglas, donde cada condición y cada resultado han sido codificados ex ante por una persona, normalmente se situará fuera de la definición. Un modelo estadístico o de machine learning que detecta correlaciones y genera una clasificación o predicción, en cambio, probablemente entrará. Un motor de optimización puede quedar dentro o fuera según cómo opere: si simplemente resuelve un problema mediante parámetros fijos y sin inferencia en el sentido del reglamento, su encaje será más discutible; si usa técnicas que infieren patrones o decisiones a partir de datos complejos, el panorama cambia. Y un modelo generativo que produce texto, imagen, audio o código está claramente en territorio AI Act.

La Comisión, por tanto, no está diciendo que solo el machine learning sea IA ni que toda estadística avanzada quede automáticamente incluida. Está diciendo algo más jurídico que técnico: la etiqueta comercial no manda; manda la arquitectura funcional y la forma en que el sistema produce resultados. Esto es bastante sensato y bastante incómodo para departamentos de ventas, que preferirían seguir llamando “IA” a cualquier automatización porque suena moderno, o dejar de llamarlo IA cuando toca compliance.

Aquí aparece una ironía regulatoria deliciosa. Durante años, media industria se benefició del término “IA” para captar inversión, titulares y contratos. Ahora que el término trae obligaciones, algunas compañías están descubriendo una pasión súbita por expresiones como “advanced analytics”, “decision engine” o “rules-based workflow”. Bruselas ha visto la jugada.

Lo que las guías probablemente buscan evitar: ni sobrecaptura ni arbitraje semántico

Un regulador serio intenta evitar dos errores simétricos. El primero es la sobrecaptura: meter dentro del AI Act productos que no presentan los rasgos que justifican el régimen. El segundo es el arbitraje semántico: permitir que proveedores sustancialmente equivalentes se autoclasiquen fuera con un cambio de terminología comercial. Las directrices de la Comisión van justamente contra ambos problemas.

La sobrecaptura sería un desastre práctico. Si cualquier software con lógica compleja, optimización o análisis de datos se considerase IA, el alcance del AI Act se dispararía hasta volverse difícil de administrar y de hacer cumplir. Afectaría a procesos empresariales masivos sin una ganancia regulatoria clara. Además, erosionaría la credibilidad del propio reglamento, que acabaría pareciendo una red tirada al azar.

El arbitraje semántico sería igual de tóxico, aunque por la vía contraria. Si bastara con afirmar que una herramienta es “estadística” o “basada en reglas” para evitar la definición, la competencia quedaría distorsionada y las obligaciones se desplazarían hacia quien sea más honesto, no hacia quien genere más riesgo. Esa es la receta clásica para un mal mercado regulado.

Por eso las guías importan también para compras y due diligence. La pregunta ya no puede formularse solo como “el proveedor dice que esto es IA o no lo es”. Habrá que pedir una explicación más incómoda: cómo genera la salida, qué técnicas utiliza, si existe inferencia, si el comportamiento depende de entrenamiento, si hay adaptación postdespliegue, cómo se documenta la lógica y qué grado de autonomía operativa tiene. Si tu proceso de procurement no está pidiendo eso, vas tarde.

Las primeras implicaciones prácticas para proveedores: menos marketing, más documentación técnica

Para los proveedores de software, las directrices de la Comisión no son una nota interpretativa inocua. Son una advertencia elegante: preparad vuestro expediente técnico antes de seguir vendiendo promesas. No basta con una demo vistosa ni con una FAQ comercial. Si un cliente regulado pregunta por el encaje de tu producto bajo el AI Act, la respuesta tendrá que bajar al nivel de diseño del sistema.

Eso obliga a varias cosas.

La primera es construir una racionalización de clasificación. No basta con afirmar “es IA” o “no es IA”. Hay que explicar por qué, con referencia a los elementos del artículo 3(1): si es un sistema basado en máquinas, si opera con cierto grado de autonomía, cómo infiere resultados, qué salidas genera y si esas salidas influyen en un entorno físico o virtual. Si además el producto puede caer en alto riesgo, esa clasificación será solo el principio de una cadena mucho más exigente.

La segunda es revisar el material contractual y comercial. Hay un riesgo evidente de incoherencia entre marketing, contratos, documentación técnica y respuestas a clientes. He visto demasiados casos donde la web presume de “AI-powered decisioning” y el cuestionario de compliance responde que no hay IA para evitar preguntas incómodas. Eso ya no es torpeza; es exposición legal. Si un regulador o un cliente confronta ambas versiones, la explicación puede ponerse fea.

La tercera es cuidar la trazabilidad de componentes. Muchos productos empresariales combinan capas: reglas, modelos, automatización, integraciones externas y, cada vez más, APIs de terceros con capacidades generativas o de clasificación. El hecho de que el producto final se presente como una plataforma unificada no elimina la necesidad de identificar qué componente realiza la inferencia relevante. Este punto va a ser especialmente espinoso en cadenas de suministro tecnológicas complejas.

La cuarta es la gobernanza de cambios. Un producto que hoy opera con reglas puede incorporar mañana un modelo de clasificación. Un sistema que hoy usa un modelo estático puede pasar a aprendizaje continuo. La clasificación bajo el AI Act no es un tatuaje; puede cambiar con la arquitectura. Si no tienes un proceso de change management que capture ese salto, el problema no será solo técnico. Será de cumplimiento.

Lo que deberían hacer ya los compradores corporativos y las entidades reguladas

Si compras tecnología, esta guía te afecta casi tanto como si la vendes. Y si estás en banca, seguros, pagos, telecom, salud o sector público, probablemente te afecta más. La razón es sencilla: la carga regulatoria no desaparece porque el proveedor te haya entregado una frase bonita.

La primera tarea es levantar un inventario funcional de sistemas que puedan caer bajo la definición. No un inventario de herramientas “que el negocio llama IA”, sino de casos de uso donde un sistema genera predicciones, recomendaciones, clasificación, priorización, scoring, contenidos o decisiones con base en inferencia. Este matiz importa. Muchas organizaciones tienen decenas de herramientas relevantes que nadie ha etiquetado como IA en términos internos, desde motores antifraude hasta soluciones de HR tech o compliance surveillance.

La segunda es revisar los cuestionarios de terceros. Si el formulario de due diligence solo pregunta “¿usa IA? sí/no”, estás haciendo teatro administrativo. Hay que pedir detalle técnico suficiente para sostener una clasificación razonada. Y luego hay que guardar esa evidencia. Porque cuando llegue una auditoría interna, una revisión del supervisor o un incidente con consecuencias jurídicas, nadie querrá apoyarse en una captura de pantalla de marketing.

La tercera es conectar esta clasificación con tus mapas de riesgo y control. Un sistema que entra en AI Act puede activar no solo obligaciones específicas del reglamento, sino interacciones con GDPR —piensa en los artículos 5, 13, 22, 25 y 35 si hay perfiles, decisiones automatizadas o DPIA— y, en el caso financiero, con marcos de gobernanza tecnológica, riesgo de modelo, outsourcing y resiliencia operativa. Si además el sistema soporta una función crítica o importante, el diálogo con DORA se vuelve inevitable, sobre todo en la gestión de terceros ICT del capítulo V y los artículos 28 a 30.

La cuarta es preparar a los equipos que realmente van a sufrir el aterrizaje de la norma: compras, legal, compliance, arquitectura empresarial, seguridad, riesgo operacional y negocio. El AI Act no es una ley que pueda “gestionar” una sola función. Quien piense lo contrario acabará con un comité precioso y una implementación desastrosa.

El punto fino: qué queda probablemente fuera y por qué eso también importa

Una de las aportaciones más útiles de estas guías es que ayudan a decir no cuando toca. En Europa seguimos teniendo cierta tendencia a pensar que más alcance regulatorio equivale automáticamente a mejor regulación. No siempre. A veces, la claridad consiste precisamente en excluir con criterio.

Quedarán previsiblemente fuera muchos sistemas de automatización puramente determinista, herramientas que ejecutan reglas fijas o flujos lógicos completamente definidos por humanos sin capacidad de inferencia en el sentido que usa el AI Act. También podría quedar fuera cierto software de optimización o procesamiento donde no exista ese elemento de inferencia orientado a generar predicciones, recomendaciones, contenidos o decisiones de la forma descrita por el reglamento.

Esto no significa barra libre. Significa algo más práctico: no todo problema de software es un problema de AI Act. Una aplicación puede estar fuera del reglamento y seguir generando riesgos serios de discriminación, error, opacidad, seguridad o privacidad. En ese caso, entran otras herramientas jurídicas y de control. GDPR no desaparece. La legislación de consumo no desaparece. La responsabilidad contractual no desaparece. El deber de buena gobernanza, desde luego, tampoco.

Este matiz es valioso porque evita dos errores habituales en empresas: meter demasiado dentro del programa de cumplimiento de IA, colapsándolo con ruido; o dejar fuera sistemas que, aunque no sean IA, siguen mereciendo disciplina de control por su impacto. El AI Act no sustituye la gobernanza tecnológica general. La afina en un perímetro concreto.

Cómo se conecta esto con las primeras obligaciones del AI Act

Las directrices llegan para facilitar la aplicación de las primeras normas del reglamento, y ese detalle temporal no es menor. El AI Act se despliega por hitos. Tras su entrada en vigor el 1 de agosto de 2024, varias obligaciones empiezan a aplicarse en fases sucesivas. Entre las más observadas están las prácticas prohibidas del artículo 5, las reglas para modelos de IA de propósito general, y más adelante el régimen completo para sistemas de alto riesgo. Si una organización no sabe todavía qué parte de su parque tecnológico entra en la definición general, mucho menos sabrá si está expuesta a esas capas posteriores.

El artículo 5 merece una mención concreta porque es donde el debate se vuelve menos teórico. Ahí se prohíben determinadas prácticas consideradas inaceptables, incluidas algunas relacionadas con manipulación, explotación de vulnerabilidades, ciertas formas de scoring social y usos específicos de identificación biométrica remota, con matices y excepciones. Sin una clasificación inicial correcta, una organización puede ni siquiera identificar que está cerca de una zona vetada.

Y luego está el terreno del alto riesgo, articulado principalmente en los artículos 6 y siguientes y los anexos correspondientes. Los requisitos para estos sistemas —gestión de riesgos, gobernanza de datos, documentación, registro de logs, transparencia, supervisión humana, robustez y ciberseguridad— son demasiado pesados como para improvisarlos tarde. Quien espere a tener certeza absoluta en cada caso para empezar a ordenar inventarios y evidencias, probablemente llegará mal.

Para el sector financiero europeo, esto no es teoría regulatoria

La noticia no menciona bancos ni aseguradoras, pero el impacto para el sector financiero europeo es bastante directo. Y para España, también. La razón está en la densidad regulatoria acumulada: una entidad financiera no analiza la IA en un vacío; la analiza sobre una mesa ya ocupada por DORA, GDPR, requisitos de gobierno interno, outsourcing, riesgo de modelo, prevención del fraude, AML, conducta y, en algunos casos, directrices supervisoras nacionales o del BCE.

Pensemos en tres casos bastante corrientes.

Un sistema de detección de fraude que clasifica operaciones sospechosas mediante modelos entrenados sobre históricos probablemente encajará sin demasiado drama en la definición de sistema de IA. Ahí se cruza el AI Act con exigencias de explicabilidad operativa, calidad de datos y trazabilidad, pero también con DORA si el sistema depende de un tercero ICT relevante o de una cadena de proveedores cloud y API.

Una herramienta de concesión o priorización crediticia puede generar salidas con impacto material en consumidores y empresas. Aquí la conexión con GDPR es obvia si hay perfiles o decisiones automatizadas significativas, especialmente bajo el artículo 22. También lo es la sensibilidad reputacional. Si además el uso entra en categorías de alto riesgo del AI Act, la gobernanza exigida sube de nivel.

Un sistema de vigilancia de comunicaciones o conducta para detectar abuso de mercado, conflictos o incumplimientos internos puede quedar dentro de la definición si infiere patrones y genera alertas o recomendaciones. Y entonces aparecen preguntas incómodas sobre base jurídica, minimización, sesgo, retención, supervisión humana y documentación de los umbrales del modelo.

El quid para las entidades financieras españolas es este: la clasificación de “sistema de IA” debe integrarse en procesos ya existentes de riesgo tecnológico y de terceros, no montarse como un universo paralelo. Si se crea un programa de IA completamente desconectado del vendor risk management, del inventario de aplicaciones críticas y de la evaluación de impacto en privacidad, el resultado será duplicidad, fatiga de control y lagunas justo donde no deberían existir.

La guía también deja un mensaje para los abogados: menos fetichismo terminológico

Hay un vicio clásico en regulación tecnológica: discutir durante meses sobre conceptos sin bajar al sistema real. La publicación de estas directrices debería servir para rebajar ese fetichismo. La clasificación jurídica importa, sí, pero no se resuelve con un adjetivo. Se resuelve entendiendo cómo funciona la herramienta.

Eso obliga a los equipos legales y de compliance a hacer algo que a veces incomoda: hablar con ingeniería, producto y arquitectura. No para que les den un curso de machine learning, sino para obtener los hechos necesarios. ¿El modelo se entrena? ¿Con qué datos? ¿Se reentrena? ¿La salida depende de patrones inferidos o de una lógica exhaustivamente codificada? ¿Hay ranking, scoring, clasificación, generación? ¿Puede influir en personas, procesos o entornos físicos? ¿Qué documentación existe y quién la aprueba? Sin esas respuestas, la opinión legal será poco más que prosa elegante.

Y aquí la Comisión acierta al no convertir la guía en un tratado académico. La utilidad está precisamente en empujar a una evaluación funcional. Bruselas, cuando quiere, también sabe ser pragmática.

Lo que todavía no resuelve la Comisión del todo

Sería ingenuo vender estas directrices como el final del debate. No lo son. Aclaran mucho, pero no pueden eliminar todas las zonas grises. Persistirán dudas en al menos cuatro frentes.

El primero es el de los sistemas híbridos. Muchas herramientas combinan reglas, optimización, modelos estadísticos y componentes generativos de terceros. Determinar qué parte del sistema es relevante para la clasificación y qué obligaciones se activan en la cadena no siempre será sencillo.

El segundo es el de ciertas técnicas de optimización y analítica avanzada que no encajan limpiamente ni en el software clásico ni en la caricatura habitual de IA. Habrá casos donde la respuesta razonable sea “depende de la implementación concreta”. Poco sexy, sí. Bastante realista, también.

El tercero es el de la evolución del producto. Un sistema puede cruzar la línea con una actualización, una integración de API o un cambio en la lógica de inferencia. Eso exige revisiones periódicas de clasificación, no un análisis único archivado para siempre.

El cuarto es el de la coherencia entre Estados miembros, autoridades competentes y sectores regulados. Aunque el AI Act es un reglamento directamente aplicable, su supervisión práctica no será perfectamente uniforme desde el primer día. Habrá criterios, prioridades y grados de sofisticación distintos. Por eso estas guías son importantes, pero no serán la última palabra en cada caso fronterizo.

Qué deberían decidir ya los responsables de compliance, riesgo y producto

La tentación ahora será esperar a más guías, más estándares armonizados, más FAQs, más señales del mercado. Mala idea. Lo razonable no es precipitarse, pero tampoco quedarse mirando. Hay decisiones bastante claras que sí pueden tomarse ya.

Primero, establece un criterio interno de clasificación alineado con el artículo 3(1) y con las directrices de la Comisión. No un eslogan, sino un procedimiento con preguntas técnicas, responsables claros y evidencia documental.

Segundo, revisa tu inventario de casos de uso. No empieces por los proyectos más glamourosos; empieza por los que toman o influyen en decisiones con impacto real: fraude, crédito, admisión, RR. HH., vigilancia, soporte al cliente, seguridad, biometría, priorización de incidencias, triage operativo.

Tercero, exige a proveedores una posición técnica escrita sobre el encaje de sus herramientas. Si el proveedor no puede explicar cómo genera resultados, el problema no es solo regulatorio. Es de gobernanza básica.

Cuarto, conecta esta clasificación con privacidad, seguridad, terceros y gobierno de modelo. Si cada función abre su propio inventario y su propia taxonomía, el caos administrativo está garantizado.

Quinto, prepara a la alta dirección para una verdad poco glamurosa: la principal dificultad del AI Act no será entender los grandes principios, sino ordenar sistemas reales, contratos reales y responsabilidades reales. Lo demás cabe bien en presentaciones. Esto no.

La lectura política de fondo: Europa intenta regular sin llamar IA a una tostadora

Detrás de estas directrices hay también una señal política. La UE sabe que el AI Act será juzgado no solo por su ambición, sino por su capacidad para aplicarse sin caer en el absurdo. Si la definición de IA se volvía un agujero negro capaz de tragarse cualquier software con analítica, el reglamento empezaría su vida con un problema de legitimidad operativa. Si, por el contrario, permitía que productos claramente algorítmicos se escaquearan con juegos de palabras, empezaría con un problema de credibilidad.

La Comisión está intentando caminar por esa cuerda floja. A veces Bruselas cae en la liturgia regulatoria y redacta textos que parecen escritos para no enfadar a nadie y no aclarar nada. Esta vez el esfuerzo por aterrizar la definición merece ser tomado en serio. No porque resuelva cada caso, sino porque fija el principio que realmente importa: el AI Act se aplica por función y diseño, no por marketing ni por superstición terminológica.

Eso, para un mercado europeo donde sobran etiquetas infladas y faltan inventarios decentes, ya es bastante avance.

La conclusión incómoda

La guía sobre la definición de sistema de IA no trae el dramatismo de una multa ni el ruido de una prohibición llamativa. Trae algo más peligroso para quien no haya hecho los deberes: claridad suficiente como para que ya no sea tan fácil fingir que no sabes si tu sistema entra o no entra.

Si eres proveedor, toca demostrar con documentación lo que antes resolvías con una diapositiva. Si compras tecnología, toca preguntar mejor. Si diriges compliance, riesgo, seguridad o producto, toca conectar piezas que hasta ahora quizá vivían separadas. Y si en tu organización alguien sigue pensando que esto va solo de ChatGPT y cuatro pilotos simpáticos, conviene tener una conversación menos romántica y bastante más útil.

La definición de IA parecía la parte aburrida del AI Act. Resulta que era la puerta de entrada. Y Bruselas acaba de recordar que las puertas, en regulación, nunca son decoración.