El reglamento europeo sobre la inteligencia artificial ya no es un tema para colocar en una vigilancia lejana. Desde el 2 de agosto de 2026, la aplicación del texto alcanza una etapa importante: las autoridades europeas y nacionales entran en una fase de implementación y control, mientras que varias obligaciones de transparencia se vuelven aplicables.
Para una empresa, la mala respuesta consiste en lanzar una producción masiva de políticas genéricas. El enfoque correcto comienza con cuatro preguntas: ¿qué sistemas de IA se utilizan realmente, con qué fines, por qué personas y con qué rol jurídico en la cadena de valor?
El calendario, las directrices y las interpretaciones pueden evolucionar. Este artículo proporciona un método operativo y no constituye un consejo legal.
Lo que cambia concretamente en agosto de 2026
La Ley de IA organiza las obligaciones según los usos, los riesgos y el papel de cada actor. Una misma tecnología puede estar sujeta a requisitos muy diferentes según si resume documentos internos, selecciona candidatos, maneja un equipo o genera un video difundido al público.
Las reglas se aplicaron de manera progresiva. Las obligaciones dirigidas a ciertos modelos de IA de uso general comenzaron a producir sus efectos en 2025. A partir del 2 de agosto de 2026, la gobernanza y la aplicación se refuerzan, y las obligaciones de transparencia del artículo 50 se aplican, en particular, a ciertas interacciones y a ciertos contenidos generados o manipulados por IA.
Esto no significa que cada uso de la IA se convierta en un sistema de alto riesgo. Gran parte de los usos permanece en una categoría de riesgo limitado o mínimo. En cambio, la empresa debe ser capaz de explicar por qué eligió una calificación y qué medidas aplica.
Comenzar con un inventario real
El registro no debe limitarse a los proyectos validados por la DSI. Debe cubrir:
- las funciones de IA integradas en programas existentes;
- los asistentes comprados directamente por una dirección de negocio;
- las API utilizadas por los equipos de desarrollo;
- los modelos de pesos abiertos autoalojados ;
- las automatizaciones sin código ;
- los POC aún conectados a datos reales;
- las herramientas gratuitas utilizadas sin contrato;
- los sistemas desarrollados para los clientes.
Para cada entrada, registrar la finalidad, el propietario, los usuarios, la población concernida, los datos, el modelo o proveedor, las decisiones influenciadas, las herramientas conectadas, los lugares de alojamiento y el estado de despliegue.
Un inventario incompleto es a menudo el primer riesgo: la organización no puede ni clasificar, ni informar, ni supervisar lo que no conoce.
Identificar su papel en la cadena de valor
El reglamento distingue varios roles, en particular proveedor y desplegador. Según el contexto, pueden añadirse otras posiciones de la cadena de distribución o del producto. Una empresa que compra un asistente para sus empleados será a menudo desplegador. Aquella que integra un modelo en un servicio vendido bajo su nombre puede asumir responsabilidades adicionales. Una personalización profunda o un cambio de finalidad también puede modificar el análisis.
Es necesario documentar, sistema por sistema:
- quién diseñó el sistema;
- que elige el propósito;
- quien lo pone en el mercado o en servicio;
- bajo qué nombre se presenta;
- quién controla los datos, prompts, herramientas y umbrales;
- que recibe los incidentes y solicitudes de las personas;
- que puede suspender el servicio.
Este análisis debe compararse con los contratos. Un proveedor comercial puede describir una funcionalidad, pero no necesariamente conoce el uso exacto que su cliente hace de ella en el negocio.
Clasificar por uso, no por nombre del proveedor
La clasificación no debe basarse en la marca del modelo o en la etiqueta «copiloto». Depende del objetivo y del contexto. Las grandes familias de preguntas son las siguientes.
¿Está prohibido o es muy sensible su uso?
Algunos usos están prohibidos o fuertemente regulados. Cualquier proyecto relacionado con la biometría, la manipulación, la explotación de vulnerabilidades, la calificación de personas o la vigilancia debe ser examinado de inmediato con un consejo competente.
¿El sistema interviene en un área potencialmente de alto riesgo?
El reclutamiento, la educación, el acceso a servicios esenciales, las infraestructuras críticas, la justicia, la seguridad o ciertos productos regulados requieren un análisis profundo. Asistir a un humano no siempre es suficiente para eliminar el riesgo si la recomendación realmente influye en la decisión.
¿Se aplica una obligación de transparencia?
Es necesario, entre otras cosas, verificar si una persona interactúa directamente con un sistema de IA, si un contenido sintético debe ser marcado de manera legible por máquina, o si un deepfake o ciertos textos sobre una cuestión de interés público deben ser señalados.
¿Se proporciona un modelo de uso general o sólo se consume?
Las responsabilidades del proveedor del modelo y del integrador no son idénticas. La empresa debe obtener la documentación disponible y definir lo que debe completar para su propio sistema.
Hoja de ruta de la Ley de IA en 90 días, desde el inventario hasta las pruebas, contratos, exámenes y controles permanentes.
Tratar las obligaciones de transparencia como un recorrido del usuario
Una mención oculta en unas condiciones generales no constituye una experiencia de transparencia satisfactoria. La información debe colocarse en el momento pertinente, ser comprendida por el público y coherente con el uso.
Para un asistente conversacional, especificar claramente que se trata de un sistema automatizado, sus límites, la manera de contactar con un humano y la forma en que se procesan los datos. Para un contenido generado o manipulado, distinguir el marcado técnico destinado a la detección de la mención visible destinada al público.
No todas las producciones asistidas por IA requieren la misma etiqueta. Se deben verificar las excepciones y condiciones previstas por el texto. Sin embargo, la organización debe mantener una política editorial: nivel de revisión humana, responsabilidad asumida, conservación de las fuentes y trazabilidad de las transformaciones importantes.
Constituir pruebas en lugar de una documentación decorativa
Un expediente creíble relaciona cada requisito con una prueba en vivo:
- ficha del sistema y versiones;
- finalidad y límites aprobados;
- análisis de riesgos e impactos;
- origen y gobernanza de los datos;
- protocolo de evaluación;
- resultados, umbrales e incidentes;
- aviso al usuario;
- mecanismos de supervisión humana;
- registros y política de conservación;
- seguridad, acceso y continuidad;
- contratos y responsabilidades ;
- historial de cambios.
La documentación debe reflejar el sistema desplegado. Una evaluación realizada sobre una versión antigua o un conjunto de datos sin relación con la producción no protege a la empresa.
Organizar la supervisión humana
La presencia de un botón « validar » no es suficiente. El controlador humano debe disponer del tiempo, las competencias, la información y la autoridad necesarias para impugnar la salida.
Definir:
- las decisiones que el sistema solo puede preparar;
- aquellas que requieren una validación;
- los criterios de rechazo;
- el nivel de explicación proporcionado;
- el procedimiento de recurso ;
- las condiciones de detención;
- las pruebas de dependencia excesiva de la automatización.
Cuanto mayor sea el impacto en las personas, más concreta y probada debe ser la supervisión.
Revisar los contratos y la cadena de subcontratación
Las cláusulas deben permitir obtener la información necesaria: versiones, localización, subcontratistas, seguridad, incidentes, derechos sobre los contenidos, uso de los datos, conservación, reversibilidad y notificación de cambios importantes.
Verificar también la capacidad para:
- exportar los datos y configuraciones;
- desactivar una función;
- imponer una región de alojamiento;
- dominar el entrenamiento en los datos;
- auditar o recibir informes;
- obtener ayuda durante un incidente;
- cambiar de modelo sin reconstruir el producto.
Un contrato estándar de herramienta de oficina puede ser insuficiente para un proceso crítico.
Construir un programa proporcionado
No todas las entradas del registro requieren el mismo esfuerzo. Priorizar según el impacto en los derechos, el número de personas, la autonomía, la sensibilidad de los datos, la madurez del proveedor y la ausencia de recursos.
Una gobernanza eficaz distingue:
- los usos prohibidos o a suspender;
- los sistemas a calificar inmediatamente;
- los usos con transparencia reforzada;
- las herramientas internas a enmarcar;
- las experimentaciones sin datos reales;
- los sistemas de bajo riesgo a vigilar simplemente.
La conformidad se convierte entonces en una cartera de riesgos, no en un cuestionario idéntico para todos.
Una hoja de ruta en 90 días
Días 0 a 30: visibilidad y medidas inmediatas
- nombrar un patrocinador y un responsable operativo;
- lanzar el inventario;
- detectar los usos sensibles o no autorizados ;
- suspender los flujos manifiestamente peligrosos;
- identificar las obligaciones de transparencia inmediatas;
- centralizar contratos y avisos;
- definir un canal de notificación.
Días 31 a 60: calificación y pruebas
- analizar los roles;
- clasificar los casos prioritarios;
- cartografiar datos y subcontratistas ;
- completar los análisis de RGPD y seguridad ;
- definir las evaluaciones y umbrales;
- corregir los recorridos de información;
- formalizar la supervisión humana.
Días 61 a 90: industrialización
- adoptar una política de IA;
- establecer el registro permanente;
- integrar los controles en el ciclo del proyecto;
- formar a los equipos según su rol;
- negociar las cláusulas faltantes;
- organizar la supervisión y las revisiones;
- preparar la gestión de incidentes y la reversibilidad.
Los errores a evitar
Esperar una lista perfecta
El inventario debe comenzar incluso si está incompleto. Las entradas « proveedor desconocido » o « datos por confirmar » permiten gestionar la incertidumbre.
Confundir conformidad del proveedor con conformidad del uso
Una certificación o una declaración del proveedor no cubre automáticamente el propósito, los datos y el proceso implementado por el cliente.
Clasificar todo como de alto riesgo
Esta estrategia sobrecarga la gobernanza y termina banalizando los riesgos reales. La proporcionalidad debe ser argumentada.
Tratar el tema únicamente desde el punto de vista jurídico
Las pruebas se encuentran en el producto: código, configuración, datos, pruebas, registros, interfaces y procedimientos. Abogados, DPO, seguridad, negocio y técnica deben trabajar juntos.
Transformar la obligación en disciplina produce
La Ley de IA impone un mejor conocimiento de los sistemas, pero esta disciplina también aporta beneficios operativos: menos herramientas invisibles, responsabilidades claras, pruebas reproducibles, incidentes mejor gestionados y una arquitectura más reversible.
Partitech puede intervenir en el inventario técnico, los mapeos de flujo, las evaluaciones, la trazabilidad, los controles humanos y la integración de los requisitos en el ciclo de entrega. La calificación jurídica final sigue realizándose con los asesores competentes de la empresa. El objetivo es vincular el reglamento a un sistema real, medible y mantenible.
Hablemos de su proyecto
Estructurar un diagnóstico del AI Act y una hoja de ruta de cumplimiento con Partitech y sus asesorías legales. Contacte a Partitech.