Agentes de IA que modifican registros: quién responde bajo el AI Act

El caso: una solicitud, una herramienta y un registro modificado

Imaginemos que una persona pide actualizar la dirección de un cliente. Un agente interpreta la solicitud, consulta un sistema empresarial, comprueba algunos datos y envía una instrucción que modifica el registro. La pregunta jurídica no se resuelve llamándolo «agente» ni observando que actúa sin una confirmación en cada paso. Primero hay que fijar qué sistema se ha puesto en servicio, con qué finalidad y por qué entidad.

El Reglamento (UE) 2024/1689, conocido como AI Act, no crea una categoría regulatoria separada para los agentes. La Comisión señala que un agente suele incluir al menos un modelo de IA de propósito general y puede constituir un sistema de IA. Eso no significa que cada agente, como conjunto técnico o producto comercial, tenga necesariamente una clasificación única: pueden intervenir varios sistemas, componentes y organizaciones con funciones distintas.

Para analizar el ejemplo, hay que describir el flujo concreto: quién ofrece el sistema, quién lo configura, qué herramientas conecta, quién autoriza las instrucciones y qué decisión produce el cambio. También importa si el agente solo prepara una propuesta o si ejecuta la modificación, y si la finalidad es una tarea administrativa ordinaria o una actividad incluida en un ámbito regulado por el Reglamento. La acción externa es un dato relevante para el análisis operativo, pero no basta por sí sola para concluir que el sistema es de alto riesgo.

La explicación que sigue es un mapa general del AI Act, no una determinación jurídica para una implantación concreta. El reparto de papeles depende de hechos verificables y de la relación entre los participantes, no solo de cómo se denomine internamente al producto.

Sistema, modelo, agente y roles: conceptos distintos

El Reglamento define «sistema de IA» atendiendo a características como su funcionamiento con distintos niveles de autonomía, su capacidad de inferencia y la generación de resultados —por ejemplo, predicciones, contenidos, recomendaciones o decisiones— que pueden influir en entornos físicos o virtuales. La Comisión ha publicado directrices para ayudar a interpretar esa definición. El análisis debe centrarse en la solución concreta y sus capacidades, no en una etiqueta de mercado como «agente», «copiloto» o «automatización inteligente».

Un modelo de IA y un sistema de IA no son sinónimos. Un modelo puede ser un componente del sistema; el sistema incluye la forma en que el modelo se integra, se pone a disposición y se utiliza. A su vez, «agente» suele describir una arquitectura o modo de funcionamiento que puede combinar un modelo, instrucciones, herramientas, memoria y mecanismos de ejecución. Esa descripción técnica no sustituye las definiciones del Reglamento.

El «proveedor» es, en términos generales, quien desarrolla un sistema de IA o un modelo de IA de propósito general, o hace que se desarrolle, y lo introduce en el mercado o lo pone en servicio bajo su nombre o marca, en las condiciones previstas por el Reglamento. El «responsable del despliegue» es quien utiliza el sistema bajo su autoridad, salvo el uso personal no profesional. La función depende de lo que la entidad hace y de cómo ofrece o utiliza el producto; puede diferir entre componentes de una misma solución.

«Integrador» no es, por sí solo, una categoría general de operador equivalente a proveedor o responsable del despliegue en el AI Act. Una empresa que conecta herramientas puede limitarse a integrar un sistema, o sus actuaciones podrían situarla en otro papel según los hechos. El artículo 25 contempla supuestos en que un distribuidor, importador, responsable del despliegue u otro tercero pasa a ser considerado proveedor de un sistema de alto riesgo, por ejemplo si lo comercializa bajo su nombre, lo modifica sustancialmente o cambia su finalidad prevista de modo que se convierta en alto riesgo. No toda configuración o integración produce automáticamente ese efecto.

En el caso del registro, el proveedor podría ser quien ofrece el sistema agéntico bajo su marca; la empresa cliente podría ser responsable del despliegue si lo utiliza bajo su autoridad; y una firma tecnológica podría prestar servicios de integración. Pero esos rótulos son hipótesis de trabajo, no conclusiones: contratos, presentación al mercado, control sobre el diseño y cambios efectuados pueden alterar el encaje.

La finalidad, no la autonomía aislada, guía la clasificación

El AI Act no clasifica como de alto riesgo todo sistema que tenga autonomía, acceda a una herramienta o produzca un efecto externo. La clasificación depende de los criterios y ámbitos definidos en el Reglamento, en particular de si el sistema es un componente de seguridad de un producto cubierto por la legislación enumerada o si pertenece a uno de los casos de uso del anexo III, teniendo en cuenta las condiciones y excepciones aplicables.

En el ejemplo, modificar una ficha de cliente no permite por sí solo afirmar que el sistema sea de alto riesgo. Habría que identificar el propósito previsto del sistema y el sector y proceso en que opera. El análisis podría cambiar si el sistema se emplea, por ejemplo, para una función incluida expresamente en un ámbito del anexo III, o si forma parte de un producto regulado en los términos del Reglamento. No basta con que una empresa use datos personales, que exista automatización o que una acción sea importante desde el punto de vista comercial.

La finalidad prevista se determina a partir de lo que el proveedor pretende que el sistema haga, tal como se refleja en instrucciones, documentación técnica y material de comercialización, además del contexto de uso que resulte pertinente. También debe distinguirse ese propósito de un uso real que se aparte de lo previsto. Si el responsable del despliegue modifica el sistema o cambia su finalidad, puede ser necesario reevaluar tanto la clasificación como quién asume obligaciones de proveedor.

La Comisión indica que los agentes suelen contener al menos un modelo de propósito general y pueden constituir un sistema de IA. La consecuencia práctica es examinar por separado las reglas aplicables al modelo y las del sistema integrado, sin inferir que la presencia de un modelo de propósito general determine por sí misma la clasificación del sistema completo.

La autonomía sí es relevante para describir el funcionamiento y valorar los controles adecuados. Por ejemplo, no es equivalente que el sistema sugiera una modificación que una persona ejecuta, que la aplique tras una aprobación específica o que la realice automáticamente. Esa diferencia puede cambiar la evaluación operativa, pero no sustituye los criterios jurídicos de clasificación del AI Act.

Responsabilidades: separar obligaciones del sistema y uso empresarial

El Reglamento distribuye obligaciones según el papel desempeñado y la categoría del sistema. Por eso no es correcto atribuir todas las obligaciones al desarrollador del modelo, ni trasladarlas sin más a la empresa cliente. Un flujo puede implicar obligaciones para más de una entidad, pero solo después de determinar qué sistema se analiza, qué reglas le son aplicables y quién cumple cada definición.

Para sistemas de alto riesgo, el artículo 16 establece obligaciones del proveedor, entre ellas asegurar la conformidad con los requisitos aplicables, disponer de un sistema de gestión de calidad, conservar documentación y cumplir las obligaciones de evaluación de conformidad, registro y otras exigencias indicadas en el artículo. Esta referencia no convierte cualquier agente en sistema de alto riesgo ni supone que la empresa que lo integra sea siempre su proveedor.

El artículo 26 regula obligaciones de los responsables del despliegue de sistemas de alto riesgo. Entre otros aspectos, exige utilizar el sistema de acuerdo con las instrucciones de uso, asignar supervisión humana a personas con competencia y autoridad adecuadas, y vigilar su funcionamiento en las condiciones previstas. El alcance concreto depende de que se trate efectivamente de un sistema de alto riesgo y de las disposiciones aplicables. No debe extrapolarse como obligación general del AI Act para toda acción automatizada.

El artículo 25 puede alterar el reparto cuando una entidad cambia el papel que desempeña respecto de un sistema de alto riesgo: por ejemplo, si lo pone en el mercado bajo su propio nombre o marca, realiza una modificación sustancial o cambia su finalidad prevista de forma que pase a ser de alto riesgo. La evaluación requiere examinar qué modificación se hizo y cómo afecta al sistema; conectar una API o cambiar una plantilla no equivale necesariamente a esos supuestos.

El artículo 4 dispone que proveedores y responsables del despliegue adopten medidas para garantizar, en la mayor medida posible, un nivel suficiente de alfabetización en materia de IA para su personal y otras personas que operen o utilicen sistemas en su nombre, teniendo en cuenta conocimientos, experiencia, formación, contexto de uso y personas afectadas. La obligación no reemplaza el análisis de roles ni convierte las recomendaciones de diseño de esta pieza en mandatos legales.

También pueden resultar pertinentes otras normas europeas o nacionales, según el dato tratado, la decisión automatizada, el sector y las consecuencias. Este análisis se limita a ubicar cuestiones dentro del AI Act y no determina obligaciones derivadas de otros marcos.

Permisos, confirmación y registros: controles prudenciales

Aunque el AI Act no convierte automáticamente en obligación general cada control técnico imaginable, un agente con capacidad de escribir en sistemas empresariales merece límites operativos proporcionados. Restringir las herramientas disponibles, el alcance de los datos y las operaciones permitidas reduce el impacto potencial de errores, instrucciones mal interpretadas o fallos de integración. Estas son recomendaciones de diseño y seguridad, no afirmaciones de que cada una sea exigida por el AI Act en todo despliegue.

Una práctica útil es conceder permisos mínimos: permitir al agente consultar solo los campos necesarios y separar lectura de escritura. Si una actualización puede causar un perjuicio significativo o es difícil de revertir, puede requerirse aprobación humana antes de ejecutarla. Para cambios rutinarios, el diseño podría permitir ejecución automática dentro de límites estrechos, con validaciones previas y un mecanismo de reversión. La decisión depende del impacto y del contexto, no de una fórmula única.

Los registros operativos pueden ayudar a reconstruir qué solicitud originó una acción, qué datos o herramientas se usaron, qué instrucción se envió, qué resultado devolvió el sistema y si intervino una persona. Conviene fijar acceso, retención y protección de esos registros conforme a las normas aplicables. Registrar una acción no demuestra por sí solo que el despliegue sea conforme, ni sustituye documentación o registros legalmente exigidos cuando correspondan.

El escalado humano es una medida de diseño apropiada cuando el sistema detecta datos incompletos, una instrucción ambigua, una operación fuera del patrón autorizado o un fallo de herramienta. Debe definirse quién recibe el caso, qué información obtiene y si puede detener o corregir la operación. En sistemas de alto riesgo, el artículo 26 contiene requisitos específicos de supervisión humana para responsables del despliegue; en otros casos, la recomendación prudencial no debe presentarse como una obligación equivalente del AI Act.

Estas medidas sirven para gobernar acciones externas, pero no resuelven la clasificación jurídica. Una implementación técnicamente controlada puede seguir requiriendo análisis de finalidad y roles; y una clasificación de alto riesgo no queda satisfecha por el mero hecho de limitar permisos.

Fechas de aplicación y límites temporales

El calendario debe leerse desde el Reglamento oficial y distinguir la entrada en vigor de la aplicación efectiva de cada obligación. El Reglamento (UE) 2024/1689 entró en vigor el 1 de agosto de 2024. Su regla general establece que será aplicable desde el 2 de agosto de 2026, pero el propio artículo 113 fija fechas anteriores para partes concretas y una fecha posterior para determinados sistemas de alto riesgo integrados en productos regulados.

Desde el 2 de febrero de 2025 se aplican el capítulo I y el capítulo II, según el artículo 113. Esto incluye, entre otras disposiciones, las definiciones del capítulo I, la alfabetización en IA del artículo 4 y las prácticas prohibidas del artículo 5. La fecha no significa que el régimen completo de sistemas de alto riesgo se aplique desde entonces.

Desde el 2 de agosto de 2025 se aplican, entre otras, las disposiciones del capítulo V sobre modelos de IA de propósito general, así como las normas institucionales y las reglas sancionadoras señaladas en el artículo 113. Para proveedores de modelos de propósito general introducidos en el mercado antes del 2 de agosto de 2025, el artículo 111 establece una disposición transitoria: deben cumplir las obligaciones aplicables a más tardar el 2 de agosto de 2027.

La aplicación general comienza el 2 de agosto de 2026. Para los sistemas de alto riesgo contemplados en el artículo 6, apartado 1, que sean componentes de seguridad de productos o sean productos sujetos a la legislación de armonización enumerada en el anexo I, la fecha indicada por el artículo 113 es el 2 de agosto de 2027. El artículo 111 también contiene reglas transitorias para sistemas de alto riesgo ya introducidos en el mercado o puestos en servicio antes del 2 de agosto de 2026; su alcance depende de si se producen cambios significativos en el diseño y de otras condiciones del texto.

Por tanto, no basta con citar una fecha general en una planificación empresarial. Hay que asociar cada obligación a su artículo, categoría y disposición transitoria, y verificar si el sistema o modelo ya estaba en el mercado o en servicio en la fecha relevante. Este resumen refleja el texto del Reglamento (UE) 2024/1689 disponible en las fuentes aportadas; una modificación legislativa posterior, si la hubiera, exige volver a comprobar la versión oficial antes de tomar decisiones.

Checklist de verificación antes de desplegar

Empieza delimitando el objeto: ¿se analiza un modelo, un sistema que lo integra o un flujo de varios sistemas? Dibuja la cadena desde la solicitud hasta la modificación del registro y señala qué componente genera cada resultado. Identifica si existe una acción externa y qué entidad controla su ejecución.

Después, fija roles con pruebas concretas: marca bajo la que se ofrece el sistema, contratos, documentación, quién encarga o realiza cambios, quién decide la finalidad y quién lo utiliza bajo su autoridad. Comprueba especialmente si una modificación puede ser sustancial o si se ha cambiado la finalidad prevista de una forma que afecte a la categoría del sistema.

Evalúa la clasificación sin atajos: identifica la finalidad prevista, consulta los criterios del artículo 6 y los ámbitos pertinentes de los anexos, y revisa excepciones o condiciones. Si la información no permite resolverlo, registra la cuestión como abierta y solicita revisión jurídica o regulatoria antes de afirmar que el sistema es o no es de alto riesgo.

Por último, separa lo exigido legalmente de las medidas prudenciales: determina qué disposiciones se aplican al papel de cada entidad y al sistema concreto; anota fechas y transiciones; y define permisos, aprobaciones, registros y escalados como controles operativos con responsables y criterios verificables. El resultado debe poder revisarse cuando cambien el modelo, las herramientas, la finalidad, el sector o la forma de uso.

Este checklist organiza la verificación inicial, pero no sustituye el asesoramiento jurídico para un producto o despliegue específico. Tampoco es una guía completa de gestión de riesgos, conformidad de proveedores, evaluación de impacto o documentación de decisiones. Su objetivo es evitar que la autonomía del agente se use como sustituto de un análisis basado en el texto legal y en hechos acreditables.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.