AI Act: gobernar cada uso real

Una empresa autoriza un asistente para redactar respuestas comerciales. Semanas después descubre que selección lo usa para resumir candidaturas y que soporte copia datos de clientes en otra versión. La licencia es la misma; finalidad, personas afectadas y riesgo no lo son. El Reglamento europeo de IA ya aplica en gran parte desde el 2 de agosto de 2026, con fechas posteriores para las obligaciones de sistemas de alto riesgo. Por eso una política genérica o una lista de proveedores no bastan. La primera compra útil es un inventario pagado de casos reales: quién desarrolla o usa cada sistema, qué decisión apoya, con qué datos, qué regla le corresponde y qué prueba falta. Esta lectura acota ese encargo para una entidad y una unidad de negocio. No clasifica jurídicamente toda la cartera, no certifica conformidad y no confunde el proyecto legislativo español con una ley vigente.

Entró en aplicación el cuerpo general del AI Act que no tenía una fecha especial. Ya regían definiciones, prácticas prohibidas, gobernanza y obligaciones sobre modelos de propósito general. Las obligaciones específicas de alto riesgo conservan ahora plazos posteriores fijados por el Reglamento 2026/1744.

Los sistemas de alto riesgo del anexo III, como determinados usos en empleo, educación o acceso a servicios esenciales, pasan al 2 de diciembre de 2027. Los vinculados a productos del anexo I pasan al 2 de agosto de 2028. El cambio no autoriza a esperar sin inventario: una práctica prohibida, una obligación de transparencia o una medida de alfabetización puede afectar antes. Cada ficha registra la norma aplicable y su fecha, no un único semáforo para toda la empresa.

Un caso de uso une una finalidad, usuarios, personas afectadas, datos, salida y decisión. El inventario incluye desarrollo propio, API, función integrada en software, prueba piloto y uso autorizado por empleados. Una marca de modelo o una factura de proveedor no describen esa unidad.

La misma herramienta puede ayudar a traducir una nota, ordenar reclamaciones o puntuar candidatos. Cada finalidad cambia el análisis. La ficha mínima identifica propietario interno, población afectada, dato de entrada, resultado, intervención humana, proveedor, integración, versión y forma de detener el uso. Un caso descubierto sin responsable queda abierto; no se atribuye por intuición al departamento que compró la licencia.

El proveedor desarrolla un sistema o modelo de IA, o lo manda desarrollar, y lo comercializa o pone en servicio bajo su nombre. El responsable del despliegue lo utiliza bajo su autoridad. La misma organización puede ocupar roles diferentes según el caso concreto.

Comprar una API suele situar a la empresa como responsable del despliegue, pero personalizar profundamente, cambiar la finalidad prevista o poner el sistema bajo marca propia puede alterar responsabilidades. Importador, distribuidor y fabricante de producto también tienen reglas propias. El diagnóstico documenta contrato, control técnico, nombre comercial y cambio realizado. Cuando el rol no puede cerrarse con esos hechos, se marca para revisión jurídica.

La clasificación inicial debe permitir detener una práctica prohibida, continuar un uso con controles, cumplir una obligación de transparencia o abrir un análisis de alto riesgo. No sustituye una opinión jurídica ni una evaluación de conformidad; organiza la siguiente decisión y la prueba necesaria.

El cribado pregunta qué conducta ejecuta el sistema, si coincide con una categoría prohibida, qué personas afecta y si entra en un producto o finalidad de alto riesgo. Después revisa transparencia, alfabetización y obligaciones del rol. «No parece de alto riesgo» no significa «sin obligaciones». Tampoco basta que el proveedor declare cumplimiento: la entidad debe entender su propio uso y conservar la información que sostiene la decisión.

Un asistente no queda exento por ser común o de bajo impacto. La entidad conserva finalidad, usuarios, datos permitidos, proveedor, versión, instrucciones, supervisión y canal de incidente. Si interactúa con personas o genera contenido cubierto por el artículo 50, añade la transparencia correspondiente.

Desde el 2 de agosto de 2026, determinadas interacciones y contenidos generados o manipulados por IA están sujetos a información o marcado. Los proveedores de sistemas generativos comercializados antes de esa fecha tienen hasta el 2 de diciembre de 2026 para cumplir el marcado técnico del artículo 50. No toda salida necesita la misma etiqueta: el equipo comprueba quién provee, quién despliega, tipo de contenido, finalidad y excepción aplicable antes de diseñar el aviso.

La revisión enlaza modelo, datos, identidades, integraciones, registros y respuesta a incidentes. Para sistemas de alto riesgo, el reglamento exige precisión, solidez y ciberseguridad. Para otros usos, estas pruebas permiten gobernar accesos, filtraciones, manipulación de entradas, dependencia del proveedor y recuperación.

Seguridad no puede evaluar un modelo aislado del proceso. Debe saber qué dato sale, quién puede cambiar instrucciones, qué registro existe, cómo se detecta una respuesta manipulada y qué alternativa mantiene la tarea. Una prueba útil simula un fallo concreto y observa detección, intervención humana, bloqueo y recuperación. El resultado es una acción con responsable, no una afirmación amplia de que la IA es segura.

La entrada es una revisión pagada de una entidad, una unidad y hasta cinco casos de IA. Entrega inventario, roles de trabajo, cribado de riesgo, calendario aplicable, matriz de pruebas y acciones priorizadas. No incluye certificación, clasificación jurídica definitiva ni implantación completa.

El cliente aporta accesos a propietarios, contratos, políticas, arquitectura y muestras permitidas. El equipo entrevista negocio, tecnología, seguridad, datos, compras y jurídico; contrasta cada caso con evidencia disponible. Las salidas son autorizar con condiciones, corregir, suspender o escalar. El precio, el plazo real y el margen solo se fijan tras delimitar los casos y comprobar la capacidad del socio. La recurrencia solo se ofrece si versiones, finalidades, proveedores o incidentes generan revisiones observables.

AESIA es una agencia estatal creada para supervisar sistemas de IA dentro de las competencias que tenga atribuidas. No será la única autoridad en todos los casos. El proyecto español de gobernanza reparte funciones y sanciones, pero al 6 de agosto de 2026 sigue en tramitación parlamentaria.

El Real Decreto 729/2023 aprueba el estatuto de AESIA y prevé supervisión y sanción conforme a la normativa europea en las materias asumidas. El proyecto de Ley Orgánica para el buen uso y la gobernanza de la IA fue presentado en mayo de 2026 y permanece en fase de enmiendas. Por tanto, sus repartos y procedimientos no se venden como derecho vigente. La autoridad competente se confirma según sistema, sector y materia.

La demanda aparece cuando una empresa compra una plataforma, lanza una función, recibe una petición de cliente, cambia de proveedor, detecta un uso no autorizado o prepara información al público. El mensaje ofrece convertir esa señal en inventario y decisiones, no evitar una sanción garantizada.

El pagador suele ser dirección de tecnología, seguridad, cumplimiento, producto o datos con capacidad para reunir áreas y frenar un caso. La oportunidad se califica por entidad, unidad, número de usos, acceso a contratos, propietario interno y decisión pendiente. La lectura sobre ENS ayuda cuando el comprador debe unir IA y seguridad demostrable. La página de IT y ciberseguridad sitúa el resto del recorrido.

La base combina el AI Act original, su reforma de julio de 2026, recursos de AESIA y el estado parlamentario español. Ninguna lectura general determina por sí sola el rol o riesgo de un caso. Cada encargo confirma finalidad, hechos, versión normativa y autoridad competente.

• Unión Europea, Reglamento 2024/1689 de Inteligencia Artificial.
• Unión Europea, Reglamento 2026/1744, Digital Omnibus sobre IA.
• AESIA, aproximación general al Reglamento europeo de IA.
• AESIA, preguntas y respuestas sobre alfabetización del artículo 4.
• AESIA, recursos sobre transparencia del artículo 50.
• AESIA, guías prácticas de aplicación del reglamento.
• BOE, Real Decreto 729/2023, Estatuto de AESIA.
• Congreso de los Diputados, expediente 121/000096 del proyecto de ley orgánica.