Preguntas frecuentes sobre el AI Act aplicado a producto

·

«¿Tenemos que hacer algo con el AI Act si nuestro producto ya está en producción?» es una de las preguntas que más nos llegan de equipos técnicos y de producto cuando el Reglamento europeo de IA deja de ser una diapositiva de comité y empieza a chocar con decisiones concretas: qué modelo usar, qué registrar, qué decirle al usuario, quién firma la documentación técnica. Este artículo reúne las dudas que más se repiten cuando alguien intenta aplicar el AI Act a un producto real (no a una presentación) y enlaza con las guías técnicas donde desarrollamos cada bloque con más profundidad. No sustituye un análisis jurídico del caso concreto: es el mapa para saber qué preguntar y a quién.

El AI Act no evalúa la etiqueta «IA» de un producto, evalúa lo que ese producto hace, sobre quién y con cuánta autonomía. Esa es la pregunta que hay que responder antes que cualquier otra de esta lista, y la que condiciona todas las respuestas siguientes.

Clasificación y alcance: ¿me afecta el AI Act?

¿Cómo sé si mi producto de IA es de alto riesgo?

No depende de si el producto «usa IA», sino de qué hace realmente y en qué ámbito se aplica. Hay que responder, en orden, varias preguntas: si la solución encaja en la definición de sistema de IA del Reglamento, si el uso concreto está entre las prácticas prohibidas, si el producto o el ámbito en el que se despliega (selección de personal, acceso a servicios esenciales, evaluación crediticia, entre otros supuestos del anexo III) lo convierte en alto riesgo, y si le corresponden obligaciones de transparencia del artículo 50 aunque no lo sea. Un producto que resume documentación interna no se evalúa igual que uno que prioriza candidaturas o decide sobre el acceso a un servicio. El resultado de esta clasificación se documenta por producto y por versión: «tenemos un módulo de IA» no es un inventario suficiente. Desarrollamos este proceso paso a paso en nuestra guía de clasificación por el anexo III.

¿Y si mi producto de IA no es de alto riesgo? ¿Tengo cero obligaciones?

No necesariamente. Que un producto no sea de alto riesgo no lo deja fuera del Reglamento. Si hay interacción directa con personas, generación de contenido o ciertos usos de reconocimiento de emociones o categorización biométrica, pueden aplicar las obligaciones de transparencia del artículo 50. Además, el artículo 4, en su redacción vigente tras el Reglamento (UE) 2026/1744, obliga a adoptar medidas para apoyar y promover la alfabetización en IA de quien opera el sistema, con independencia del nivel de riesgo, sin exigir que se garantice un nivel específico de formación en cada persona. Y si el producto se apoya en un modelo de propósito general de terceros, existen obligaciones propias que recaen sobre el proveedor de ese modelo, no sobre ti, pero que conviene conocer para exigir la información correspondiente en el contrato.

¿Desde cuándo tengo que cumplir el AI Act?

El Reglamento (UE) 2024/1689 entró en vigor en 2024 y se aplica de forma escalonada, y el Reglamento (UE) 2026/1744, «Ómnibus digital sobre IA», en vigor desde el 27 de julio de 2026, movió parte de ese calendario. Las prohibiciones originales y la alfabetización en IA se aplican desde el 2 de febrero de 2025 (las prohibiciones que añadió el Ómnibus, sobre contenido íntimo no consentido y material de abuso sexual infantil generados por IA, son exigibles desde el 2 de diciembre de 2026); las reglas sobre modelos de propósito general, desde el 2 de agosto de 2025; las obligaciones de transparencia del artículo 50 (informar de que un contenido se ha generado con IA), desde el 2 de agosto de 2026 (los sistemas generativos ya introducidos en el mercado antes de esa fecha disponen hasta el 2 de diciembre de 2026 para cumplir el marcado del artículo 50.2); y las obligaciones de alto riesgo, que son la parte más exigente del marco, se aplazaron al 2 de diciembre de 2027 para los sistemas del anexo III y al 2 de agosto de 2028 para los del anexo I. Estas fechas deben verificarse siempre contra el texto vigente y cualquier modificación oficialmente publicada antes de tomar una decisión de producto basada en ellas: no conviene construir un roadmap sobre un resumen comercial o un anuncio de prensa. Aunque una fecha cambie, inventariar los sistemas de IA del producto, formar a quien los opera y tener trazabilidad mínima siguen siendo trabajo necesario en cualquier calendario.

Roles: proveedor, responsable del despliegue… ¿quién soy yo?

Solo integro un modelo de terceros en mi producto: ¿soy proveedor?

Llamar a la API de un modelo de terceros (de OpenAI, Anthropic, Google o un modelo abierto que despliegas tú mismo) no te convierte automáticamente en proveedor de ese modelo. En la mayoría de los casos, tu empresa actúa como responsable del despliegue del sistema que construyes alrededor: decides la finalidad, los datos que le pasas, cómo se supervisa el resultado y cómo se monitoriza en producción. Esa posición conlleva obligaciones propias, no es un papel pasivo, pero es distinta de la del proveedor del modelo subyacente. Si tu producto incorpora un agente que ejecuta acciones además de responder, conviene revisar también qué exige el Reglamento a nivel de agentes de IA para back office, donde la autonomía añade requisitos prácticos de supervisión.

¿Puedo convertirme en proveedor sin darme cuenta?

Sí, y es uno de los puntos que más se pasa por alto en producto. La asignación de roles no es solo contractual: depende de lo que haces realmente con el sistema. El artículo 25 del Reglamento contempla tres supuestos que desplazan las obligaciones de proveedor hacia tu empresa: poner tu marca en un sistema de alto riesgo ya introducido en el mercado, modificarlo sustancialmente, o cambiar la finalidad prevista de un sistema (incluido uno de propósito general) hasta convertirlo en alto riesgo. Cualquiera de los tres puede darse aunque nadie lo haya decidido explícitamente en una reunión de producto: reentrenar un modelo hasta cambiar su finalidad, retirar salvaguardas que traía el proveedor original o comercializar un sistema de terceros bajo tu propia marca son ejemplos habituales. Conviene revisar este punto cada vez que el equipo de datos hace un ajuste importante al modelo base.

¿Qué diferencia hay entre las obligaciones del proveedor del modelo y las de mi producto?

El proveedor de un modelo de propósito general responde de obligaciones propias sobre ese modelo (documentación técnica, información a quien lo integra, entre otras). Tu producto tiene obligaciones distintas e independientes de esas: controlar la finalidad real de uso, gobernar los datos que entran y salen, mantener supervisión humana efectiva, monitorizar el comportamiento en producción y, cuando corresponda por el nivel de riesgo, conservar registros. Que el modelo cumpla sus obligaciones no exime a tu producto de las suyas, ni al revés: son capas complementarias, no intercambiables.

Documentación técnica y evidencias del producto

¿Qué tengo que documentar si mi producto es de alto riesgo?

El artículo 11 y el anexo IV del Reglamento exigen un expediente técnico que permita a un tercero entender cómo funciona el sistema y verificar su cumplimiento: finalidad prevista, arquitectura y componentes, dependencias de terceros, datos utilizados, sistema de gestión de riesgos, métricas de rendimiento, límites conocidos y medidas de supervisión humana y ciberseguridad. No es un documento que se redacta una vez y se archiva: se actualiza cuando cambia el modelo, los datos de entrada, la finalidad o el entorno de despliegue. Entramos en el desglose completo de cada apartado en nuestra guía de documentación técnica del anexo IV.

¿Me sirve un model card como documentación técnica?

Cubre una parte, no el expediente completo. Un model card bien hecho describe con solidez el modelo en sí (datos de entrenamiento, métricas de evaluación, limitaciones conocidas, casos de uso previstos y desaconsejados), y ese contenido encaja de forma natural en varios apartados del anexo IV. Pero el expediente técnico de un producto pide también información que ningún proveedor de modelo puede darte: cómo lo has integrado en tu arquitectura, qué supervisión humana aplicas en tu flujo concreto, qué pruebas has hecho sobre tu caso de uso real y qué controles operan alrededor del modelo dentro de tu sistema. El model card es un buen punto de partida, no un sustituto del trabajo de documentar el producto completo.

¿Qué logs tengo que guardar en producción?

Los necesarios para reconstruir decisiones y acciones, no todo lo que el sistema genera de forma indiscriminada. Una traza útil identifica el identificador y la versión del sistema, el modelo y el prompt o política aplicados, los datos o fuentes recuperados, el resultado producido y si hubo aprobación o intervención humana en el camino. Al diseñar el logging hay que aplicar minimización: los prompts pueden contener datos personales o información confidencial que no conviene retener sin criterio ni plazo de conservación definido, ni almacenarlos en el mismo sitio que las métricas de rendimiento sin control de acceso.

Transparencia y supervisión humana en el producto

¿Tengo que avisar a los usuarios de que hablan con una IA?

En los supuestos que cubre el artículo 50, sí: las personas deben ser informadas de que interactúan con un sistema de IA, de forma clara y en el momento oportuno, salvo que resulte evidente por las circunstancias. No basta con mencionarlo únicamente en la política de privacidad o en un aviso legal que nadie lee antes de usar el producto; el aviso debe estar donde ocurre la interacción. Si además el producto genera o modifica contenido de forma sintética, existen reglas adicionales de marcado del artículo 50.2, con un plazo hasta el 2 de diciembre de 2026 para los sistemas generativos ya introducidos en el mercado antes del 2 de agosto de 2026. Cubrimos la implementación práctica (dónde colocar el aviso, cómo formularlo, qué casos concretos aplican) en nuestra guía del artículo 50.

¿Qué supervisión humana necesita mi producto?

No se resuelve con un botón decorativo de «revisar». La persona que supervisa debe poder entender las capacidades y los límites reales del sistema, detectar resultados anómalos, interpretar la salida en su contexto y tener capacidad efectiva de ignorar, corregir o detener la acción antes de que produzca efectos. Cuanto mayor sea el impacto de la decisión (una denegación de acceso, una priorización que afecta a personas, una acción irreversible), más contexto debe mostrarse en el momento de decidir: fuentes utilizadas, nivel de incertidumbre, datos afectados y consecuencias previsibles. Si el volumen de alertas hace inviable revisarlas todas con atención real, el diseño no está proporcionando supervisión efectiva, aunque exista sobre el papel. En nuestra guía sobre los requisitos técnicos de los artículos 8 a 15 desarrollamos qué se espera en la práctica para sistemas de alto riesgo.

¿El AI Act sustituye al RGPD para mi producto?

No, son marcos complementarios y hay que cumplir ambos. Un producto puede satisfacer los requisitos técnicos del AI Act (documentación, supervisión, trazabilidad) y seguir infringiendo protección de datos si carece de base legal para el tratamiento, no aplica minimización de datos o no informa adecuadamente a las personas cuyos datos personales procesa. Si tu producto usa IA sobre datos de clientes, empleados o usuarios finales, el análisis de ambos marcos debe hacerse en paralelo desde el diseño, no como una revisión legal posterior.

Puesta en marcha y cumplimiento práctico

¿Qué pasa si no cumplo? ¿Hay sanciones?

El Reglamento prevé un régimen sancionador cuyo importe depende del tipo de infracción cometida y de las circunstancias de la empresa, por lo que no existe una cifra única aplicable a cualquier caso ni tiene sentido citar un número suelto fuera de contexto. Si necesitas una estimación aproximada para tu situación concreta, en Summum Consultoría mantenemos una calculadora de sanciones del AI Act que ayuda a orientar el orden de magnitud; cualquier cifra que obtengas ahí debe validarse después con asesoría legal antes de tomarla como referencia definitiva.

¿Cuánto tarda o cuesta adecuar un producto que ya está en producción?

Depende de tres factores que varían mucho de una empresa a otra: si el producto resulta de alto riesgo o no, cuántos sistemas de IA distintos intervienen en él, y cuánta documentación y trazabilidad existe ya de partida. Un producto sin logs, sin aviso al usuario y sin supervisión humana formalizada requiere bastante más trabajo que uno que solo necesita completar el expediente técnico y ordenar lo que ya hace bien. Cualquier cifra genérica de coste o plazo publicada sin conocer el caso concreto es, en el mejor de los casos, orientativa.

¿Por dónde empiezo si mi producto ya está en producción?

Por inventariar: qué sistemas de IA tiene el producto, sobre qué datos operan, qué deciden o recomiendan y quién es responsable de cada uno. Con ese inventario se hace la clasificación de riesgo y se cierran primero los huecos más urgentes (aviso al usuario si falta, registros mínimos, capacidad real de intervención humana ante una decisión de impacto). Después se construye el expediente técnico completo y la gobernanza continuada: revisión de cambios, formación por rol y vigilancia posterior al despliegue. Encajar todo esto dentro de un sistema de gestión, en lugar de mantenerlo como una lista de tareas sueltas, es justo lo que aporta un marco como ISO/IEC 42001.

Summum IA puede acompañar la clasificación técnica, la documentación y la evaluación de tu producto frente al AI Act, desde el inventario inicial hasta el expediente y la supervisión en producción. La interpretación jurídica del caso concreto y el calendario de obligaciones deben validarse siempre con tu asesoría legal antes de tomar decisiones de producto.

Fuentes consultadas