El AI Act no crea una categoría jurídica única llamada «agente de IA». Las obligaciones dependen del papel de la organización —proveedor, responsable del despliegue, importador o distribuidor—, de la finalidad prevista y del riesgo del sistema en el que se integra el agente. La arquitectura agéntica sí aumenta la exigencia práctica: más autonomía, herramientas, memoria y capacidad de actuar requieren mejor inventario, límites, registros, supervisión y seguridad.
La primera obligación es clasificar el caso de uso
Llamar «agente» a una aplicación no determina su régimen. Hay que analizar qué hace realmente: si recomienda, decide, ejecuta acciones, interactúa con personas o controla un proceso. También importa dónde se utiliza. Un agente que resume documentación interna no se evalúa igual que uno que filtra candidaturas, prioriza pacientes o interviene en un servicio esencial.
La clasificación debe responder, por orden, a estas preguntas:
- ¿Encaja la solución en la definición de sistema de IA del Reglamento?
- ¿Existe una práctica prohibida aplicable al uso concreto?
- ¿El sistema es de alto riesgo por su producto o por uno de los ámbitos del anexo III?
- ¿Se aplican obligaciones de transparencia del artículo 50?
- ¿La organización es proveedor o responsable del despliegue, o ha cambiado de rol al modificar el sistema?
- ¿Interviene un modelo de propósito general y qué obligaciones corresponden a su proveedor?
- ¿Qué otras normas siguen aplicando: RGPD, consumo, empleo, secreto profesional, ciberseguridad o regulación sectorial?
El resultado se registra por sistema y versión. «Usamos IA» no es un inventario suficiente.
Roles: quién debe hacer qué
Una empresa que compra un agente suele ser responsable del despliegue, pero puede convertirse en proveedor si comercializa la solución bajo su nombre, realiza una modificación sustancial o cambia su finalidad prevista en circunstancias contempladas por el Reglamento. La asignación contractual no puede contradecir la realidad operativa.
| Rol | Control habitual | Evidencias principales |
|---|---|---|
| Proveedor | Diseña o pone el sistema en el mercado | Gestión de riesgos, datos, documentación, registros, conformidad y vigilancia |
| Responsable del despliegue | Usa el sistema bajo su autoridad | Uso conforme a instrucciones, supervisión, monitorización, registros e impacto |
| Importador | Introduce un sistema de terceros países | Verificaciones y documentación exigible |
| Distribuidor | Lo hace disponible en la cadena | Comprobaciones y cooperación |
En una arquitectura con modelo, plataforma, integrador, herramientas y cliente final puede haber varios actores. Debe crearse un mapa que indique quién controla finalidad, datos, prompts, permisos, actualizaciones, incidentes y retirada.
Calendario y prudencia regulatoria
El Reglamento (UE) 2024/1689 entró en vigor en 2024 y aplica de forma escalonada. Las prohibiciones y la alfabetización en IA comenzaron a aplicarse el 2 de febrero de 2025; las reglas sobre modelos de propósito general, entre otras, desde el 2 de agosto de 2025; y una parte sustancial del marco tiene como referencia el 2 de agosto de 2026, con otras previsiones posteriores.
El calendario debe verificarse contra el texto vigente y cualquier modificación oficialmente publicada. No se debe basar el proyecto en anuncios, propuestas legislativas o resúmenes comerciales. Aunque una fecha cambie, inventario, alfabetización, seguridad, trazabilidad y gobierno siguen siendo controles necesarios.
Obligaciones técnicas de los sistemas de alto riesgo
Cuando un agente forma parte de un sistema de alto riesgo, el proveedor debe articular requisitos como gestión continua de riesgos, gobierno de datos, documentación técnica, registros, información al responsable del despliegue, supervisión humana, exactitud, solidez y ciberseguridad.
Gestión de riesgos durante el ciclo de vida
El expediente debe identificar riesgos conocidos y previsibles, incluidos usos razonablemente previsibles. En agentes, esto incluye desviación del objetivo, uso indebido de herramientas, acciones encadenadas, credenciales excesivas, instrucciones incrustadas en documentos, memoria contaminada y dependencia de terceros.
Para cada riesgo se documentan escenario, personas o bienes afectados, severidad, probabilidad, medidas, prueba y riesgo residual. La evaluación se actualiza cuando cambian modelo, herramienta, permiso, datos, finalidad o entorno.
Datos y conocimiento
Si se utilizan datos para entrenamiento, validación o prueba, deben aplicarse prácticas de gobierno y calidad adecuadas. En RAG, también hay que gobernar documentos, índices y permisos aunque el modelo no se reentrene.
El inventario debe registrar procedencia, licitud, representatividad, calidad, actualización y limitaciones. Los fragmentos recuperados necesitan trazabilidad hasta la fuente. El agente no debe elevar una salida propia a «memoria válida» sin control.
Documentación y registros
La documentación debe permitir comprender finalidad, arquitectura, dependencias, prestaciones, límites y controles. Los registros tienen que reconstruir decisiones y acciones sin almacenar indiscriminadamente datos personales.
Una traza útil incluye:
- Identificador y versión del sistema.
- Modelo, prompt y política aplicados.
- Datos o fuentes recuperados.
- Herramientas y argumentos.
- Resultado y acción ejecutada.
- Aprobación o intervención humana.
- Errores, reintentos, coste y latencia.
Supervisión humana
La supervisión no puede reducirse a un botón. La persona debe entender capacidades y límites, detectar anomalías, interpretar la salida, evitar dependencia automática y poder ignorar, detener o revertir.
Las acciones de alto impacto deben mostrar fuentes, incertidumbre, datos afectados y consecuencias. Si la carga de alertas hace inviable revisar, el diseño no proporciona supervisión efectiva.
Exactitud, solidez y ciberseguridad
Los umbrales se definen por caso de uso. Deben probarse entradas normales, límites, ataques, caída de herramientas, cambios de versión y condiciones adversas. Para acciones críticas se establecen clases de error con tolerancia cero.
La ciberseguridad incluye inyección directa e indirecta, envenenamiento de memoria, abuso de identidad, herramientas maliciosas, extracción de datos y ejecución inesperada. Los controles deterministas deben situarse fuera del modelo.
Obligaciones del responsable del despliegue
El artículo 26 exige, para sistemas de alto riesgo, utilizar el sistema conforme a instrucciones, asignar supervisión a personas competentes, controlar los datos de entrada cuando estén bajo su control y monitorizar el funcionamiento. Si se detecta un riesgo o incidente grave, deben activarse las comunicaciones y medidas previstas, incluida la suspensión cuando corresponda.
El responsable del despliegue necesita un expediente operativo:
- Finalidad autorizada y usos prohibidos.
- Responsables y personas supervisoras.
- Formación y competencia.
- Instrucciones internas.
- Datos y fuentes permitidos.
- Monitorización, alertas e incidentes.
- Conservación de registros.
- Evaluación de impacto cuando proceda.
- Revisión de proveedores y cambios.
El cumplimiento del proveedor no legitima cualquier uso del cliente. Cambiar la población, la decisión o la autonomía puede alterar riesgos y obligaciones.
Transparencia y contacto con personas
Cuando una persona interactúa con un sistema de IA, el artículo 50 establece obligaciones de información en los supuestos aplicables, salvo que resulte evidente por las circunstancias. También existen reglas para contenidos sintéticos o manipulados en determinados casos.
En un agente de atención, la información debe aparecer al inicio y explicar cómo acceder a una persona. No basta con ocultarla en la política de privacidad. Si el agente realiza una acción con consecuencias, deben comunicarse su papel, límites y vía de revisión.
Alfabetización en IA
El artículo 4 exige adoptar medidas para asegurar un nivel suficiente de alfabetización en IA de personal y otras personas que operan sistemas por cuenta de la organización, considerando conocimientos, experiencia, contexto y personas afectadas.
Un programa útil se diseña por rol:
| Rol | Competencia mínima |
|---|---|
| Dirección | Riesgo, responsabilidades y decisiones de aceptación |
| Producto/proceso | Finalidad, límites, impacto y supervisión |
| Desarrollo | Evaluación, seguridad, datos y trazas |
| Usuarios | Uso previsto, verificación y escalado |
| Privacidad/compliance | Clasificación, derechos y evidencias |
| Soporte | Incidentes, retirada y comunicación |
La evidencia incluye temario, asistencia, evaluación y aplicación práctica; no solo un vídeo general.
Arquitectura de control para agentes
- Identidad propia: nunca una cuenta administradora compartida.
- Permiso mínimo: por herramienta, dato, acción, volumen y tiempo.
- Política determinista: valida cada acción fuera del modelo.
- Aprobación por impacto: previa para decisiones difíciles de revertir.
- Idempotencia: un reintento no duplica operaciones.
- Aislamiento: código y adjuntos en entornos restringidos.
- Procedencia: fuentes y memoria con propietario y fecha.
- Límites: pasos, coste, tiempo y alcance.
- Trazas: reconstrucción completa con minimización de datos.
- Parada: mecanismo independiente para suspender acciones.
Plan de adecuación en 60 días
Días 1–15
- Inventariar agentes, modelos, herramientas y responsables.
- Clasificar rol, riesgo y calendario.
- Detener usos prohibidos o sin propietario.
- Mapear datos, acciones y personas afectadas.
Días 16–30
- Crear expediente por sistema.
- Revisar contratos, instrucciones y documentación del proveedor.
- Definir supervisión, usos prohibidos y métricas.
- Ejecutar análisis RGPD y de derechos fundamentales cuando proceda.
Días 31–45
- Implantar identidad, permisos, políticas, trazas y parada.
- Construir pruebas funcionales y adversariales.
- Formar a cada rol.
- Ensayar incidentes y suspensión.
Días 46–60
- Operar en sombra o piloto limitado.
- Corregir fallos y calcular riesgo residual.
- Aprobar el uso y registrar condiciones.
- Programar vigilancia y reevaluación.
Checklist previo a producción
- Rol y clasificación documentados.
- Finalidad y usos prohibidos aprobados.
- Obligaciones por fecha verificadas oficialmente.
- Datos, herramientas y proveedores inventariados.
- Gestión de riesgos y pruebas actualizadas.
- Supervisión humana efectiva.
- Identidad, permisos mínimos y parada implantados.
- Registros reconstruyen decisiones y acciones.
- Transparencia y escalado a persona configurados.
- Alfabetización acreditada por rol.
- RGPD, FRIA y normativa sectorial coordinados.
Preguntas frecuentes
¿Todo agente es de alto riesgo?
No. Depende de finalidad y ámbito. La autonomía no lo convierte automáticamente en alto riesgo, pero sí puede elevar el riesgo técnico y organizativo.
¿Comprar un agente transfiere toda la responsabilidad al proveedor?
No. Quien lo despliega debe controlar finalidad, datos, supervisión, monitorización e impacto. Puede además convertirse en proveedor si modifica sustancialmente el sistema o su finalidad en los supuestos del Reglamento.
¿Un chatbot tiene que identificarse como IA?
En los supuestos del artículo 50, las personas deben ser informadas de que interactúan con IA, salvo que sea evidente, y de forma clara y oportuna.
¿El AI Act sustituye al RGPD?
No. Son marcos complementarios. Un sistema puede cumplir requisitos del AI Act y seguir infringiendo protección de datos si carece de base, minimización o transparencia.
¿Los logs deben guardarlo todo?
No. Deben permitir trazabilidad aplicando minimización, seguridad y plazos. Los prompts pueden contener datos personales o secretos.
Summum IA puede acompañar la clasificación técnica, arquitectura y evaluación de agentes, así como el diseño de agentes de IA y el LLMOps asociado. La interpretación jurídica y el calendario deben validarse antes de publicación y despliegue.