Checklist de AI Act aplicado a producto para pymes

«¿Nuestro producto ya cumple el AI Act o no?» es la pregunta que se hacen cada vez más equipos de producto que han añadido una función de IA —un asistente, un clasificador, un motor de recomendación— a un software que venden a otras empresas. Ya contamos cómo se resolvió un caso concreto paso a paso y respondimos las preguntas más habituales sobre el AI Act aplicado a producto; este checklist da un paso más operativo: una lista de comprobación, fase a fase, para que un equipo de producto sin especialistas legales a tiempo completo pueda revisar por su cuenta si una función de IA dentro de su propio producto está resuelta, y en qué punto exacto no lo está.

Cómo usar este checklist

Está organizado en siete fases —de la fase 0, decidir si la empresa actúa como proveedora del sistema, al mantenimiento una vez el producto está en producción— más un bloque final con señales de alerta que conviene revisar aunque el resto del checklist parezca resuelto. No hace falta completarlo entero de una sentada: lo práctico es repasar la fase que corresponda cada vez que se añade o se modifica una función de IA en el producto, y dejar constancia por escrito de qué puntos están resueltos y cuáles no. Varios puntos sin marcar no significa que el producto esté mal planteado; significa que hay trabajo concreto pendiente antes de escalar esa función a más clientes.

Fase 0 — ¿La empresa actúa como proveedora del sistema de IA?

• Función de IA integrada en lo que se vende. El producto que vendéis a clientes incluye alguna función que decide, clasifica, genera contenido o recomienda algo por su cuenta, más allá del uso interno de herramientas de IA dentro de la propia empresa.
• Proveedor frente a responsable del despliegue. El equipo sabe distinguir el papel de proveedor del sistema de IA —quien lo integra y lo pone en el mercado bajo su propio producto— del papel de responsable del despliegue, que es el que tiene una empresa que solo usa una herramienta de IA de terceros para su propio trabajo interno.
• El modelo es de un tercero, pero el sistema es vuestro. Si el modelo que hay detrás de la función es de un proveedor externo al que se llama por API, está identificado que las obligaciones sobre el sistema completo que habéis construido alrededor —no sobre el modelo en sí— recaen sobre vuestra empresa, no solo sobre el proveedor del modelo.
• Momento del cambio de estatus fechado. Está fechado el momento —fin de la beta cerrada, lanzamiento general, activación por defecto en un plan— en que la función pasa o pasó de prueba interna a producto comercializado con clientes reales, porque es ese momento el que hace nacer las obligaciones de proveedor.

Fase 1 — Inventariar cada función de IA por componente

• Desglose por componente técnico. Cada función de IA del producto está desglosada como componente individual —qué modelo la resuelve, qué datos recibe, con qué nivel de autonomía actúa— y no descrita de forma genérica como «el producto tiene IA».
• Lista escrita y viva. Existe una lista escrita y actualizada, no solo en la memoria del equipo de producto, de qué funciones usan IA, desde cuándo están activas y en qué planes o configuraciones comerciales.
• Autonomía revisada por función. Está comprobado, función por función, si actúa de forma totalmente autónoma —sin que una persona revise el resultado antes de que llegue al usuario final— en alguna configuración o plan comercial concreto.
• Autonomía distinta según el plan. Se ha revisado si el mismo producto ofrece distinto nivel de autonomía según el cliente o el plan contratado —por ejemplo, una función que solo sugiere en el plan básico y que actúa sola en el plan avanzado—, porque eso puede cambiar la clasificación de esa función en concreto.

Fase 2 — Clasificar por el anexo III y las prácticas prohibidas

• Cotejo explícito con el anexo III. Para cada función del inventario se ha comprobado, de forma explícita y por escrito, si su ámbito de uso coincide con alguno de los supuestos de alto riesgo tasados en el anexo III (empleo y gestión de personal, evaluación crediticia, acceso a servicios esenciales, educación, biometría, aplicación de la ley, entre otros).
• Prácticas prohibidas descartadas por escrito. Se ha descartado, también por escrito, que alguna función incurra en alguna de las prácticas prohibidas del artículo 5 —manipulación subliminal, explotación de vulnerabilidades, puntuación social, entre otras—, en lugar de darlo por supuesto sin revisarlo.
• El aplazamiento no es una exención. Si alguna función sí encaja en el anexo III, está claro que el aplazamiento de los plazos hasta el 2 de diciembre de 2027 (sistemas del anexo III) o el 2 de agosto de 2028 (sistemas del anexo I) no es una razón para posponer el diseño: da tiempo de margen, no una excepción a la obligación.
• Clasificación repetida con cada función nueva. La clasificación se repite cuando se lanza una función nueva o se amplía el alcance de una existente, en lugar de asumir que, porque el producto ya se revisó una vez, cualquier función añadida después queda cubierta por esa revisión anterior.

Fase 3 — Transparencia del artículo 50

• Aviso en el punto de interacción. En cada función donde el usuario final interactúa directamente con el sistema —un chat, una respuesta automática, una recomendación— existe un aviso en el propio punto de esa interacción, no solo en el aviso legal o en la política de privacidad del sitio.
• Marcado técnico del contenido sintético. El contenido que el sistema genera de forma autónoma —texto, imagen, audio o vídeo— lleva, además del aviso visible, un marcado técnico legible por máquina, que es la obligación distinta que impone el artículo 50.2.
• Calendario del periodo transitorio correcto. Si el sistema generativo ya estaba comercializado antes del 2 de agosto de 2026, está identificado que el Reglamento (UE) 2026/1744 introduce un periodo transitorio de cuatro meses —hasta el 2 de diciembre de 2026— solo para ese marcado técnico del artículo 50.2, y que el aviso de interacción del artículo 50.1 es exigible desde el 2 de agosto de 2026 sin ningún periodo de gracia.
• Criterio de «evidente» aplicado con cuidado. El equipo sabe distinguir cuándo el aviso de interacción puede omitirse porque resulta evidente para una persona razonablemente informada, atenta y perspicaz, de cuándo hace falta explicitarlo porque el contexto no lo deja claro por sí solo.

El reparto exacto entre cuándo el aviso de interacción puede omitirse y cuándo no, con ejemplos aplicados, se desarrolla con más detalle en nuestra guía técnica del artículo 50.

Fase 4 — Supervisión humana y trazabilidad

• Límite explícito de autonomía. Cada función con autonomía alta tiene un límite explícito y documentado de qué tipo de casos puede resolver sin que una persona la revise antes.
• Registro que permite reconstruir una decisión. Existe un registro que permite reconstruir, ante una reclamación concreta de un cliente final, qué modelo y qué versión decidieron, sobre qué caso y si hubo revisión humana.
• Interruptor real, no solo teórico. Hay un mecanismo real para desactivar la autonomía de una función concreta para un cliente concreto en minutos, no solo sobre el papel ni dependiendo de un nuevo despliegue de código.
• Revisión periódica de fallos. Alguien revisa con regularidad los casos donde el sistema falla o se corrige, y no solo cuando un cliente final se queja de forma directa.

Fase 5 — Documentar, aunque no sea obligatorio

• Expediente técnico si aplica alto riesgo. Si alguna función del producto resulta de alto riesgo, está identificado quién construye el expediente técnico del artículo 11 y el anexo IV, y con qué plazo.
• Ficha ligera aunque no sea obligatoria. Si ninguna función es de alto riesgo, existe igualmente una ficha ligera por función —modelo usado, datos que recibe, pruebas realizadas, limitaciones conocidas— en lugar de no documentar nada porque «no es obligatorio».
• Anticiparse a la compra de cuentas grandes. Está previsto que clientes de cuentas grandes probablemente pidan esta documentación como parte de su propio proceso de compra o de auditoría a proveedores, antes de que la pidan de forma explícita.
• Alfabetización en IA revisada. Está revisado si aplica alguna obligación de fomentar la alfabetización en IA, conforme al artículo 4 del Reglamento, para el personal que opera o supervisa el sistema.

Fase 6 — Ya en producción: mantenimiento continuo

• Clasificación revisada cuando cambia el alcance. La clasificación de cada función se revisa cuando cambia su alcance —por ejemplo, se activa el modo autónomo para un tipo de caso que antes requería revisión humana—, no solo quedó fijada en el lanzamiento.
• Canal específico de aviso de fallos. Existe un canal específico para que un cliente o un usuario final reporte un fallo del sistema de IA, distinto del canal general de soporte del producto.
• Calidad revisada por segmento. La calidad del sistema se revisa por segmento —tipo de caso, tipo de cliente, volumen— y no solo con una media general que puede esconder un problema concentrado en un grupo concreto.
• Gobernanza presupuestada como coste recurrente. El mantenimiento de esta gobernanza —revisar registros, actualizar la documentación, repetir la clasificación cuando cambia algo— está presupuestado como coste recurrente del producto, no como un gasto puntual del lanzamiento.

Siete señales de que una función necesita revisión urgente

Estas señales no son una lista exhaustiva, pero en la experiencia de acompañar este tipo de revisiones son las que con más frecuencia indican que una función necesita atención antes de seguir creciendo:

1. Existe algún plan comercial con envío o decisión automática sin revisión humana, y nadie ha revisado la clasificación del anexo III para ese modo concreto.
2. El aviso de que se interactúa con IA solo aparece en el aviso legal o en la política de privacidad, no en el punto donde ocurre la conversación o la respuesta.
3. El equipo de producto no sabría decir, si se le preguntara hoy, si la empresa actúa como proveedora o como responsable del despliegue para la función que acaba de lanzar.
4. Ninguna persona concreta tiene asignada la responsabilidad de repetir la clasificación cuando se añade una función nueva o se amplía una existente.
5. Un cliente de cuenta grande ha pedido documentación de compliance sobre alguna función de IA y el equipo ha tenido que improvisarla desde cero, sin ninguna base previa.
6. El contenido generado de forma automática no lleva marcado técnico y el sistema ya estaba comercializado antes del 2 de agosto de 2026, sin ningún plan para cumplir antes del 2 de diciembre de 2026.
7. Nadie del equipo puede decir, sin mirar el código, si una función concreta se puede desactivar para un cliente en minutos si algo empieza a fallar.

Si dos o más de estas señales aparecen en un producto que ya está en el mercado, lo razonable no es dejar de vender ni desactivar la función de golpe: es volver a las fases 1 y 2 de este checklist y resolver la clasificación con datos reales antes de seguir ampliando esa función a más clientes o más casos de uso.

Este checklist recoge, en forma de lista reutilizable, el mismo criterio que aplicamos en el caso resuelto paso a paso de AI Act aplicado a producto en una pyme: inventariar por componente técnico, clasificar por función y no por etiqueta comercial, poner la transparencia en el punto de interacción y diseñar la supervisión para el modo de fallo real del producto. Si antes de recorrerlo hace falta resolver dudas de fondo —qué es un sistema de IA a efectos del Reglamento, cuándo una pyme pasa a ser proveedora, qué ocurre si el modelo es de un tercero—, esas respuestas están reunidas en nuestras preguntas frecuentes sobre el AI Act aplicado a producto.

Preguntas frecuentes

¿Este checklist sustituye una asesoría legal sobre el AI Act aplicado a mi producto?

No. Es un marco operativo para no llegar tarde a las preguntas correctas: inventariar, clasificar y diseñar la transparencia y la supervisión de cada función de IA. La calificación legal definitiva de un caso concreto, sobre todo si hay dudas de si una función entra en el anexo III, debe validarla un asesor legal especializado en la materia.

¿En qué se diferencia de vuestro caso resuelto de AI Act aplicado a producto?

Ese artículo narra, paso a paso, cómo se resolvió un caso construido a partir de situaciones habituales, con las dudas y los detalles concretos que fueron apareciendo. Este checklist da por hecho ese proceso y lo convierte en una lista de comprobación reutilizable para revisar cualquier producto propio, se parezca o no al caso concreto que contamos allí.

¿Hay que repetir todo el checklist cada vez que lanzamos una función nueva?

No todo, pero sí las fases de clasificación y de transparencia para la función nueva en concreto. El inventario se actualiza añadiendo la función; las fases de documentación y mantenimiento normalmente se revisan de forma periódica para todo el producto, no una por una cada vez que cambia algo.

Nuestro producto ya está en el mercado y no hicimos nada de esto antes de lanzarlo, ¿por dónde empezamos?

Por la transparencia del artículo 50, porque es la obligación que ya es exigible desde el 2 de agosto de 2026 sin ningún periodo transitorio para el aviso de interacción del artículo 50.1. Con eso resuelto, se sigue por el inventario y la clasificación del resto de funciones, que conviene tener hechos aunque el calendario de las obligaciones de alto riesgo se haya aplazado.

El aplazamiento de los plazos a 2027 y 2028, ¿significa que podemos dejar la clasificación para más adelante?

No conviene leerlo así. El aplazamiento afecta a cuándo son exigibles las obligaciones si una función resulta de alto riesgo, no a si conviene saberlo. Diseñar la supervisión humana, el registro de decisiones y la documentación técnica lleva tiempo; empezar la clasificación ahora, cuando el producto todavía se puede ajustar con relativa facilidad, sale más barato que rehacerlo bajo presión cerca del plazo.

Summum IA acompaña este mismo proceso —inventario, clasificación, transparencia y supervisión— sobre productos reales, con el criterio de clasificar por lo que hace cada función y no por la etiqueta comercial del producto, desde gobernanza técnica de IA y AI Act. La interpretación jurídica de un caso concreto debe validarse siempre con asesoría legal antes de tomar decisiones de producto.

Fuentes consultadas

• Reglamento (UE) 2024/1689 (AI Act) — EUR-Lex
• Art. 6 — Clasificación de sistemas de alto riesgo
• Anexo III — Sistemas de IA de alto riesgo
• Art. 11 — Documentación técnica
• Anexo IV — Documentación técnica
• Art. 12 — Registro de actividad (logs)
• Art. 14 — Supervisión humana
• Art. 50 — Transparencia
• Reglamento (UE) 2026/1744 — Ómnibus digital sobre IA — EUR-Lex
• Reglamento (UE) 2026/1744 — Ómnibus digital sobre IA (DOUE, espejo BOE)