AI Act y agentes de IA: obligaciones según tu papel
De la finalidad prevista a la cadena de valor: cómo delimitar el sistema, clasificar el riesgo y asignar responsabilidades antes de elegir controles.
Sin revisión jurídica declarada. Las referencias describen el régimen de los sistemas de alto riesgo cuando corresponda. Las propuestas de ingeniería son interpretación técnica, no certificaciones del producto.
1. El perímetro precede al control
Un agente no es una categoría jurídica autónoma. Su arquitectura puede combinar modelo, memoria, herramientas y un ejecutor capaz de modificar el entorno. La primera decisión técnica consiste en delimitar qué sistema se pone en servicio, con qué finalidad y bajo la autoridad de quién. Comprar una API no resuelve esa delimitación.
Como método de ingeniería, prepara un inventario que conecte cada finalidad con entradas, salidas, permisos y personas afectadas. Conserva la versión del modelo, las herramientas habilitadas y la configuración de autorización. Este inventario es una propuesta de trabajo; no es una clasificación emitida por una autoridad.
2. Proveedor y responsable del despliegue
El proveedor desarrolla, o encarga desarrollar, un sistema y lo comercializa o pone en servicio bajo su nombre. El responsable del despliegue lo utiliza bajo su autoridad, salvo el uso personal no profesional. Una organización puede desempeñar papeles distintos para sistemas distintos.
Reetiquetar un sistema de alto riesgo, modificarlo sustancialmente o cambiar una finalidad de modo que pase a ser de alto riesgo puede trasladar responsabilidades de proveedor conforme al artículo 25. Por eso un cambio de integración necesita revisión de responsabilidades además de una revisión de código.
3. Autonomía no equivale a alto riesgo
La clasificación depende de la finalidad y de los supuestos del artículo 6 y sus anexos. Un asistente para redactar notas y un sistema utilizado para seleccionar candidatos no comparten necesariamente el mismo régimen. Las condiciones y excepciones del anexo III requieren evaluación específica.
No ser de alto riesgo tampoco elimina todas las obligaciones: pueden ser aplicables reglas de transparencia del artículo 50, además de otras normas sectoriales o de protección de datos. El análisis debe registrar la justificación de cada obligación incluida o descartada.
4. De la clasificación al expediente operativo
Para sistemas de alto riesgo, el artículo 9 sitúa la gestión del riesgo en un proceso continuo. El artículo 26 establece deberes de uso y supervisión para responsables del despliegue. Una ficha de producto no sustituye esa actividad organizativa.
Propuesta técnica: asigna un propietario al inventario, otro a las autorizaciones y otro a la revisión de incidentes. Vincula cada prueba a una versión concreta del sistema y registra el alcance de lo observado. Un ensayo aislado no demuestra la conformidad de todas las integraciones futuras.
5. Dónde encaja BABYLON
BABYLON documenta controles de autorización y registros de ejecución; CORTEX se orienta a memoria y NEMESIS a verificación. La sección de pruebas y límites publica el estado observado del snapshot y sus divergencias. Ese estado puede ser parcial o estar desactualizado.
La integración debe demostrar que las acciones relevantes atraviesan el control y que el registro conserva contexto suficiente. Instalar un componente no certifica una finalidad, no reemplaza una evaluación de conformidad y no transfiere por sí solo responsabilidades legales.