Cómo se resuelve el AI Act aplicado a producto en una pyme, paso a paso

·

«Ya tenemos IA en el producto, ¿ahora qué hacemos con el AI Act?»: esa fue la pregunta que se hizo el equipo de producto de una pyme de software de gestión de incidencias y atención al cliente. Se trata de un SaaS B2B, y la función ya estaba en beta con varios clientes cuando alguien cayó en la cuenta de que llevaban meses hablando del AI Act como algo que le pasaba a la empresa, a sus propios sistemas internos, y no como algo que pudiera aplicarse directamente a lo que estaban vendiendo. Este artículo recorre, paso a paso, cómo se resolvió ese caso: el inventario, la clasificación, lo que estuvo a punto de pasar desapercibido, la documentación que hicieron aunque no era obligatoria y la decisión final.

Es un caso construido a partir de situaciones habituales: los datos y detalles son ilustrativos y están simplificados, y el objetivo es mostrar el proceso, no documentar un cliente concreto. Ese proceso (inventariar por componente, clasificar por función y no por etiqueta comercial, poner la transparencia en el punto de interacción, diseñar la supervisión humana para el modo de fallo real) es el mismo que se aplicaría a cualquier otra pyme que venda un producto con una función de IA dentro. Si se busca primero el marco general de preguntas y respuestas, conviene leer antes nuestras preguntas frecuentes sobre el AI Act aplicado a producto; aquí se ve ese mismo marco funcionando sobre un caso concreto.

El AI Act no pregunta si el producto «lleva IA» en la ficha comercial. Pregunta qué hace cada función, sobre quién actúa y con cuánta autonomía se ejecuta —y la respuesta puede ser distinta para dos funciones del mismo producto, o incluso para dos modos de uso de la misma función.

Por qué vender el producto cambia la pregunta

Cuando una empresa usa IA para automatizar un proceso interno, su papel casi siempre es el de responsable del despliegue de un sistema ajeno. Cuando esa misma empresa integra IA dentro de lo que vende a sus clientes, la pregunta cambia: puede convertirse en proveedora del sistema de IA que ha construido, aunque el modelo que hay debajo sea de un tercero al que solo llama por API. Ese matiz —desarrollado con más detalle en nuestras preguntas frecuentes sobre el AI Act aplicado a producto— fue el primer punto de fricción en este caso: nadie había decidido explícitamente que la empresa pasaba a tener obligaciones de proveedor. Simplemente ocurrió, sin que nadie lo formalizara, en el momento en que la función salió de las pruebas internas y empezó a usarse con clientes reales.

El punto de partida: una función que ya estaba en producción

El producto es un software de gestión de tickets e incidencias que otras empresas usan para atender a sus propios clientes finales. Meses atrás, el equipo de producto —cuatro personas, dentro de una plantilla de poco más de veinte— había añadido una función que lee cada ticket entrante, lo clasifica por categoría y urgencia, y redacta una propuesta de respuesta que el agente humano puede enviar tal cual, editar o descartar. En los planes de mayor volumen existía, además, la opción de activar el envío automático de esa respuesta para los tickets marcados como de urgencia baja, sin que nadie la revisara antes de salir.

La función llevaba semanas funcionando bien, con buena aceptación entre los primeros clientes que la habían probado. El problema no era técnico: era que nadie en la empresa había hecho todavía el ejercicio de preguntarse qué obligaciones nacían de haber puesto esa función, tal y como estaba configurada, delante de usuarios finales que no eran empleados propios ni habían firmado nada con la empresa que la vendía.

El inventario: más piezas de las que parecía

El primer paso no fue clasificar nada, sino inventariar. Al desglosar la función aparecieron en realidad dos componentes distintos que hasta entonces se venían tratando como uno solo: un modelo de clasificación que decidía la categoría y la urgencia del ticket, y un modelo generativo de terceros al que se le enviaba el contenido para redactar la propuesta de respuesta. Cada uno tenía su propio comportamiento, su origen de datos y su nivel de autonomía según el plan contratado por cada cliente. Tratarlos como una sola «función de IA» habría escondido que uno de los dos —el que podía terminar en un envío automático sin revisión— tenía implicaciones que el otro no tenía. Inventariar por componente técnico, no por función comercial, es justo el primer paso que seguimos en nuestro servicio de gobernanza técnica de IA y AI Act, y en este caso se confirmó por qué importa: sin ese desglose, la clasificación posterior habría quedado incompleta.

La clasificación: recorrer el anexo III función por función

Con el inventario hecho, tocaba responder, para cada componente por separado, las mismas preguntas que cualquier producto con IA tiene que responder: si encaja en la definición de sistema de IA del Reglamento (UE) 2024/1689, si el uso concreto está entre las prácticas prohibidas, si el ámbito de aplicación aparece entre los supuestos de alto riesgo del anexo III, y si le corresponden obligaciones de transparencia del artículo 50 aunque no sea de alto riesgo.

Clasificar tickets de atención al cliente por urgencia y categoría, y redactar una propuesta de respuesta, no encaja en ninguno de los ámbitos que el anexo III enumera como de alto riesgo: no hay selección de personas para un empleo, evaluación crediticia, acceso a un servicio esencial ni ninguno de los demás supuestos que la norma tasa de forma cerrada. La conclusión, para las dos piezas del inventario, fue que el producto no era de alto riesgo conforme al artículo 6 y al anexo III. Ese dato importa también por el calendario: aunque el producto hubiera resultado de alto riesgo, las obligaciones del capítulo III, secciones 1 a 3, para los sistemas de alto riesgo del artículo 6.2 y el anexo III no son exigibles hasta el 2 de diciembre de 2027, tras el aplazamiento que introdujo el Reglamento (UE) 2026/1744; el aviso de interacción del artículo 50.1, en cambio, sí es exigible desde el 2 de agosto de 2026, que es justo el terreno donde se jugó este caso (el marcado del artículo 50.2 tiene un plazo distinto, que se explica más abajo). Pero la clasificación no cerró el trabajo, lo abrió: quedaba por resolver el bloque de transparencia y supervisión, que es donde de verdad estaba el riesgo operativo del caso.

Lo que estuvo a punto de pasar desapercibido

El punto que casi se quedó sin resolver fue el envío automático. En el modo asistido —una persona revisa la propuesta antes de enviarla— el usuario final recibía una respuesta redactada con ayuda de IA pero enviada por una persona; el contexto dejaba razonablemente claro que hablaba con el servicio de atención al cliente de la empresa. En el modo de envío automático para tickets de baja urgencia, eso cambiaba: la respuesta llegaba sin que nadie la hubiera leído antes, generada íntegramente por el modelo. Ahí sí eran de aplicación, sin ambigüedad, las obligaciones de transparencia del artículo 50: la persona que recibe esa respuesta tiene que poder saber que ha sido generada por un sistema de IA, sin tener que deducirlo ni buscarlo en la política de privacidad.

El segundo punto que apareció fue de supervisión, no de transparencia: si nadie revisaba esas respuestas automáticas, ¿quién se enteraba de que el modelo empezaba a fallar en un tipo concreto de ticket? El equipo revisó los registros de las semanas anteriores y confirmó lo que sospechaba: el envío automático se había activado en varios clientes sin que existiera un mecanismo rápido para desactivarlo si algo iba mal, ni ninguna métrica que avisara de una caída de calidad antes de que un cliente final se quejara directamente.

La documentación que hicieron aunque no era obligatoria

Como el producto no resultó de alto riesgo, el expediente técnico completo del artículo 11 y el anexo IV no era, en este caso, una obligación legal. Aun así, el equipo decidió documentar el componente igual que si lo fuera, en una versión reducida: qué modelo se usaba, qué datos del ticket se le enviaban y cuáles se excluían deliberadamente, qué pruebas se habían hecho sobre los tipos de ticket más frecuentes, cuáles eran las limitaciones conocidas y cómo estaba diseñada la supervisión humana. La razón no fue puramente normativa: varios clientes de plan grande habían empezado a pedir precisamente esa información dentro de su propio proceso de compra, como parte de la debida diligencia sobre proveedores que usan IA. Tener ese documento listo, en lugar de improvisarlo cliente a cliente, resultó tan útil comercialmente como legalmente. Desarrollamos el contenido completo de ese expediente en nuestra guía de documentación técnica del AI Act (anexo IV) y model cards.

Transparencia en el punto de interacción, no en la letra pequeña

El aviso se rediseñó para aparecer donde ocurre la interacción, no solo en el aviso legal del pie de página: las respuestas enviadas sin revisión humana llevan ahora una etiqueta visible que indica que han sido generadas por IA, y el propio widget de tickets muestra, la primera vez que un usuario final interactúa con el sistema, un aviso breve de que puede recibir una respuesta asistida por IA según el tipo de ticket. En el modo asistido, donde una persona revisa y firma cada respuesta, no se activó ese aviso adicional: el criterio que siguieron fue el mismo que exige el artículo 50, informar cuando no resulte evidente por el contexto, y no añadir un aviso genérico a todo de forma indiscriminada. Este es exactamente el reparto de casos que desarrollamos en nuestra guía técnica del artículo 50.

El artículo 50 tiene dos capas que conviene no confundir. El apartado 50.1 exige informar de que se interactúa con un sistema de IA, salvo que resulte evidente para una persona razonablemente informada, atenta y perspicaz según el contexto; ese fue el criterio que llevó a no repetir el aviso visible en el modo asistido, donde una persona revisa y firma cada respuesta. El apartado 50.2 es una obligación distinta, y no depende de si hay revisión humana: el proveedor tiene que asegurar que el contenido sintético que genera el sistema (texto, en este caso) quede marcado en un formato legible por máquina y detectable como generado artificialmente, salvo que el sistema cumpla una función de apoyo a la edición estándar o no altere sustancialmente los datos de entrada. Como el modelo redacta la propuesta de respuesta desde cero, esa excepción no se cumple ni siquiera en el modo asistido. El artículo 111, apartado 4, del Reglamento —añadido por el Reglamento (UE) 2026/1744— da a los sistemas generativos ya introducidos en el mercado antes del 2 de agosto de 2026, como era el caso de esta función, plazo hasta el 2 de diciembre de 2026 para cumplir ese marcado; aun así, el equipo decidió implementarlo ya, sin esperar al final del plazo, y añadió un marcado técnico en los metadatos de la respuesta, aparte del aviso visible que solo se activa en el envío automático.

Supervisión humana con un diseño concreto, no un botón decorativo

Para el envío automático, el rediseño incluyó tres piezas. Primero, un límite explícito de qué categorías de ticket pueden enviarse sin revisión, excluyendo, entre otras, cualquier categoría de ticket marcado como urgente o con lenguaje que sugiera una insatisfacción fuerte del cliente. Segundo, un registro por cada respuesta enviada —modelo y versión usados, categoría asignada, si hubo revisión humana o no— que permite reconstruir qué pasó ante cualquier reclamación posterior. Tercero, un interruptor real que cualquier responsable de cuenta puede activar para desactivar el envío automático de un cliente concreto sin tocar código ni esperar a un despliegue. Ese registro sigue la misma lógica de trazabilidad que trabajamos en nuestro servicio de gobernanza técnica de IA y AI Act: no se trata de guardar todo indiscriminadamente, sino de guardar lo necesario para reconstruir una decisión cuando alguien lo pida, con criterio de minimización sobre los datos del ticket que puedan ser sensibles.

La decisión final y lo que queda abierto

El producto se mantuvo, en conjunto, fuera del régimen de alto riesgo: la clasificación por función y ámbito, y no por la etiqueta comercial de «tiene IA», sostuvo esa conclusión. Pero la clasificación no se dio por cerrada de forma definitiva. El equipo dejó anotado, como parte del propio proceso de revisión de producto, que cualquier función nueva que tocara ámbitos como la evaluación de personas trabajadoras, el acceso a un servicio esencial o cualquier otro supuesto del anexo III obligaría a repetir el ejercicio desde cero para esa función concreta, sin asumir que el resto del producto «ya estaba aprobado» de forma permanente. Es la misma lógica de fondo que reforzamos en nuestra guía sobre los requisitos técnicos para sistemas de alto riesgo: la clasificación acompaña a cada función del producto, no a la empresa en general de una vez para siempre.

Qué se puede extrapolar a otro producto con IA

Checklist para replicar este caso

Preguntas frecuentes

¿Cambia algo si el modelo que usamos dentro del producto es de un proveedor externo, no propio?

No elimina las obligaciones sobre el producto. El proveedor del modelo responde de lo que le corresponde sobre ese modelo; la empresa que lo integra dentro de un producto propio y lo comercializa sigue teniendo que resolver por su cuenta la clasificación, la transparencia y la supervisión del sistema completo que ha construido alrededor.

Si el producto no resulta de alto riesgo, ¿hace falta documentar algo?

No por obligación legal del anexo IV, que se aplica a sistemas de alto riesgo. Pero, como muestra este caso, documentar de forma ligera el modelo, los datos que recibe y cómo está diseñada la supervisión suele resolver peticiones de compliance de clientes grandes antes de que las pidan, y deja el trabajo ya hecho si el producto evoluciona hacia un ámbito de mayor riesgo.

¿Cuánto tarda un proceso como este?

En un caso como el descrito, el inventario, la clasificación y el rediseño de transparencia y supervisión pueden resolverse en pocas semanas cuando el producto ya existe y solo hay que revisarlo, no construirlo desde cero. Un producto sin ningún registro previo ni criterio de clasificación documentado necesita más tiempo de partida.

Summum IA puede acompañar este mismo proceso sobre un producto real —inventario, clasificación, documentación y diseño de transparencia y supervisión— con el mismo criterio que este caso: clasificar por lo que hace cada función, no por la etiqueta comercial del producto. Puede plantearse directamente desde gobernanza técnica de IA y AI Act, o revisando antes cómo encaja una función conversacional en chatbot de atención al cliente con IA o en agentes de IA para back office. La interpretación jurídica del caso concreto debe validarse siempre con asesoría legal antes de tomar decisiones de producto.

Fuentes consultadas