Seguimiento posterior a la comercialización: guía práctica para equipos SaaS

El seguimiento posterior a la comercialización consiste en comprobar cómo se comporta un sistema de IA tras su lanzamiento y utilizar los resultados para mantener su seguridad y conformidad. Para los equipos SaaS, el punto de partida práctico es un responsable identificado, un plan documentado, información fiable del uso real y un recorrido desde cada hallazgo significativo hasta una decisión. Un panel solo aporta pruebas útiles cuando alguien lo revisa y actúa en consecuencia.

Esta guía se centra en los sistemas de IA de alto riesgo del Reglamento de IA de la UE. Las recomendaciones operativas también pueden ayudar con otras funciones de IA, pero eso no somete todos los productos SaaS al artículo 72. Las listas, los intervalos de revisión y los ejemplos siguientes son recomendaciones de implementación, no una plantilla reglamentaria obligatoria.

Determine el alcance y el calendario vigente

El artículo 72 exige a los proveedores de sistemas de IA de alto riesgo establecer y documentar un seguimiento posterior a la comercialización proporcionado. Abarca la recogida y el análisis sistemáticos de datos de funcionamiento pertinentes durante toda la vida del sistema, incluidas las interacciones relevantes con otros sistemas de IA. Su finalidad es evaluar el cumplimiento continuo de los requisitos de alto riesgo. Reglamento de IA, artículo 72.

Empiece por la finalidad prevista, la clasificación de riesgo y el papel de su empresa. Ofrecer una aplicación bajo su nombre, utilizar un sistema adquirido y suministrar un modelo de propósito general son situaciones diferentes. Pida al responsable jurídico que confirme el papel y las disposiciones aplicables, incluido el régimen transitorio de los sistemas existentes, antes de presentar un programa de seguimiento como obligación legal.

A 13 de septiembre de 2026, la Comisión sitúa el inicio de aplicación de las reglas de alto riesgo del anexo III en el 2 de diciembre de 2027 y el de la IA de alto riesgo integrada en productos del anexo I en el 2 de agosto de 2028. Estos hitos actualizados siguen a la entrada en vigor del Ómnibus de IA el 27 de julio de 2026. No aplazan globalmente todas las obligaciones de IA. Actualización de la Comisión.

La modificación del artículo 72, apartado 3, exige un plan de seguimiento y fija el 2 de septiembre de 2027 como plazo para las orientaciones de la Comisión, incluida una plantilla. No presente como vigente el plazo original de febrero de 2026 para un acto de ejecución. Reglamento (UE) 2026/1744, artículo 1, punto 30.

Conserve junto al plan una nota de aplicabilidad fechada. Registre versión del sistema, justificación, fechas relevantes, revisor y próximo desencadenante de reevaluación. Revísela cuando cambien la finalidad, el mercado o las responsabilidades sobre el producto. Un alcance claro evita que el equipo herede una promesa infundada de plena conformidad de todas las funciones.

Conecte el seguimiento del proveedor con la información del cliente

El proveedor puede ver la telemetría del servicio mientras los clientes observan las consecuencias de resultados individuales. Diseñe un canal que conecte ambas perspectivas. Pida a los equipos de atención al cliente contexto suficiente para distinguir defectos del producto, entradas inadecuadas, problemas de configuración y usos ajenos a la finalidad documentada.

Los responsables del despliegue tienen una obligación propia de supervisión operativa conforme al artículo 26, apartado 5, incluida la comunicación pertinente a proveedores y la escalada de determinados riesgos e incidentes graves. El plan del proveedor no sustituye esa responsabilidad. Reglamento de IA, artículo 26.

Acuerde quién recibe reclamaciones, cómo identifica el cliente la versión afectada y quién puede solicitar información adicional. Incluya una vía para problemas urgentes fuera de las revisiones habituales de cuenta. Si el cliente aloja el sistema y usted no puede consultar datos de producción, documente esa limitación y acuerde pruebas alternativas: resultados agregados, reproducciones controladas o evaluaciones dirigidas por el cliente.

Para el contexto organizativo, consulte las guías en inglés sobre expectativas de gobernanza de IA para proveedores SaaS y asignación de responsabilidades de cumplimiento.

Construya un plan que pueda ejecutarse

Empiece con un plan breve para un sistema bien delimitado. Enlace los registros existentes de ingeniería, soporte, seguridad y riesgos en lugar de duplicar pruebas. Estos campos son un punto de partida práctico:

• Límites del sistema: finalidad prevista, usuarios afectados, configuraciones admitidas, versiones y componentes de IA conectados.
• Responsabilidad: responsable del plan, revisor técnico, contacto jurídico para escaladas y suplente.
• Señales: evaluaciones, reclamaciones, correcciones humanas, fallos del servicio, avisos del proveedor y lagunas de visibilidad conocidas.
• Métodos: muestreo, referencia comparativa, frecuencia de revisión y limitaciones de cada medición.
• Decisiones: umbrales para investigar, restringir, revertir versiones, comunicar a clientes y escalar a dirección.
• Pruebas: ubicación de hallazgos, aprobaciones, medidas correctoras y verificaciones posteriores.
• Desencadenantes de cambio: nuevos modelos, instrucciones, fuentes de datos, integraciones, poblaciones de clientes y finalidades.

Asigne un destinatario a cada señal. Un buzón compartido sin revisor responsable puede acumular informes mientras todos creen que otro los atiende. En empresas pequeñas una persona puede desempeñar varios papeles, pero el plan debe distinguir quién investiga, quién acepta el riesgo residual y quién autoriza continuar operando.

Pruebe el plan con una reclamación reciente. ¿Puede el revisor identificar la versión, localizar la referencia, contactar con el ingeniero adecuado y documentar una decisión sin buscar mensajes privados? Si no, corrija el traspaso de responsabilidades antes de añadir métricas.

Elija señales que puedan cambiar una decisión

Parta de los modos de fallo de la evaluación de riesgos. Para cada uno, determine qué pruebas observables indicarían que un control pierde eficacia. La disponibilidad y el tiempo de respuesta pueden importar, pero no demuestran que los resultados sigan siendo adecuados para la finalidad prevista.

Son candidatos útiles las respuestas incorrectas en muestras revisadas, la falta de escalada de casos inciertos, cambios inesperados en correcciones humanas, reclamaciones sobre exclusión recurrente y fallos tras actualizaciones de servicios previos. Cuando resulte significativo y lícito, compare contextos operativos relevantes. Una muestra ausente o muy pequeña es una limitación, no prueba de rendimiento equivalente.

Registre cómo se calcula cada métrica y qué población cubre. El porcentaje semanal de errores puede bajar por una mejora del producto, por la desaparición de casos difíciles de la muestra o por un fallo de recogida. Acompañe los cambios numéricos de información sobre tráfico, configuración y cobertura de medición.

Justifique documentalmente los umbrales de alerta. Una regla ilustrativa podría abrir una investigación cuando una versión falla repetidamente en un escenario crítico de evaluación. Es una regla interna de decisión, no un umbral numérico legal. Asigne la revisión de falsas alarmas y fallos no detectados para mejorar también el seguimiento.

Evite recopilar por defecto conversaciones completas de clientes. Trabaje con privacidad y seguridad para elegir la información mínima necesaria, restricciones de acceso y plazos de conservación adecuados a cada tipo de prueba. Cuando sea posible, use un identificador de caso y material complementario restringido, en lugar de duplicar contenido sensible en tickets y paneles.

Defina ritmos de revisión y desencadenantes

Separe alertas inmediatas, análisis rutinario y revisión periódica de dirección. Por ejemplo, un equipo podría evaluar señales urgentes al recibirlas, revisar tendencias semanalmente y reevaluar el plan mensualmente durante un despliegue inicial. Son intervalos sugeridos: justifique la frecuencia según riesgos y velocidad de cambio.

Cada lanzamiento debe identificar qué supuestos podrían haber cambiado. Nuevas fuentes de recuperación, enrutamiento de modelos, permisos, idiomas y grupos de clientes pueden alterar el comportamiento sin cambiar la interfaz. Registre una referencia antes del cambio, defina el periodo de observación y decida qué pruebas justificarían pausar el despliegue.

Incluya las actualizaciones del proveedor. Determine quién recibe avisos, cómo se identifican versiones y qué ocurre si un servicio previo cambia sin una versión fijada. Si la observabilidad es limitada, documente controles compensatorios e incertidumbre restante, sin insinuar cobertura completa.

Consulte también el artículo en inglés sobre cómo cambia la IA el seguimiento y la información de cumplimiento. Resuma el resultado de cada revisión: qué cambió, qué pruebas se examinaron, qué decisión siguió y quién asume la siguiente acción.

Convierta los hallazgos en medidas correctoras

Todo hallazgo significativo necesita un expediente. Registre el momento de detección, versión y configuración afectadas, pruebas disponibles, impacto potencial, contención inicial, responsable de decisión y plazo de seguimiento. Clasifique explícitamente la incertidumbre: una preocupación plausible puede exigir actuar antes de conocer la causa raíz.

Una secuencia práctica es evaluar la señal, proteger a los usuarios afectados, preservar pruebas necesarias, investigar, seleccionar la corrección y verificarla. Las opciones incluyen modificar instrucciones, restringir una configuración, revertir una versión, mejorar la revisión humana o suspender una función. Elija según el fallo real y las obligaciones aplicables.

No cierre automáticamente el caso cuando ingeniería despliegue un parche. Repita el escenario fallido, compruebe usos representativos y registre si el cambio introdujo problemas nuevos. Actualice evaluación de riesgos, instrucciones, controles de seguimiento y documentación de versiones cuando el hallazgo cambie sus supuestos.

Para problemas aceptados temporalmente, especifique alcance, aprobador, vencimiento, controles compensatorios y desencadenante de reapertura. Una excepción indefinida dificulta distinguir una decisión deliberada de una tarea olvidada. El siguiente revisor debe entender por qué continuó la operación y qué modificaría esa decisión.

Mantenga una vía separada para incidentes graves

Los posibles incidentes graves requieren evaluación jurídica y de respuesta a incidentes inmediata. No deben esperar a la próxima revisión de tendencias. El artículo 73 establece obligaciones de notificación y plazos diferenciados: un límite general de 15 días, límites inferiores para determinados casos y requisitos de notificación inmediata según las circunstancias. No permite esperar sistemáticamente 15 días. Reglamento de IA, artículo 73.

El revisor responsable debe determinar si se cumple la definición legal, qué disposiciones de notificación se aplican, a quién avisar y cuándo comenzó el plazo. Evalúe también obligaciones paralelas de otros regímenes aplicables y contratos con clientes. Mantenga esas decisiones separadas para no considerar erróneamente que una comunicación satisface todos los deberes.

Ensaye un escenario urgente antes del lanzamiento. Confirme que el equipo encuentra contactos, preserva pruebas, restringe el uso y prepara un relato inicial con hechos aún incompletos. Registre quién puede decidir bajo presión temporal si falta el responsable habitual.

Ejemplo: aplicación de contratación tras actualizar el modelo

Imagine un proveedor SaaS cuya aplicación de clasificación de candidatos se ha evaluado como de alto riesgo. Tras actualizar un modelo previo, las reclamaciones sugieren clasificaciones inconsistentes de candidatos con trayectorias poco convencionales. La disponibilidad agregada sigue siendo normal.

El responsable abre un caso, identifica versiones y clientes afectados y pide a ingeniería reproducir el problema con ejemplos controlados. El equipo comprueba si el conjunto de evaluación cubría esas trayectorias y si el comportamiento cambió frente a la referencia aprobada. Los revisores jurídicos y de producto evalúan el impacto potencial y las posibles implicaciones de notificación.

Según los resultados, el proveedor podría detener el despliegue, restaurar la versión anterior, restringir funciones afectadas o introducir revisión humana adicional. Las comunicaciones explican el alcance y las medidas provisionales sin atribuir una causa aún no establecida.

El caso se cierra únicamente cuando la verificación respalda la corrección elegida y el revisor registra el resultado. El equipo amplía la cobertura de evaluación y los desencadenantes cuando esté justificado. Este ejemplo ilustra un proceso; no convierte toda inconsistencia de clasificación en incidente grave legalmente notificable.

Errores frecuentes

Considerar la disponibilidad como todo el programa. La salud operativa indica si un servicio funciona. Añada controles relacionados con calidad de resultados, supervisión y riesgos de su finalidad real.

Esperar solo reclamaciones. Los clientes silenciosos quizá no tengan canal o no reconozcan el fallo. Combine información recibida con evaluaciones planificadas y consultas específicas.

Supervisar una versión obsoleta. Vincule hallazgos con cambios de modelo, aplicación, configuración y fuentes. Un informe del trimestre pasado puede decir poco de la versión actual.

Conservar pruebas sin decisiones. Los gráficos no explican por qué se continuó, restringió o detuvo la operación. Preserve razonamiento y verificación posterior.

Prometer visibilidad completa. Identifique datos de clientes ausentes, elementos internos inaccesibles del proveedor y límites de muestreo. Explique cómo afectan a la confianza y a las decisiones.

Preguntas habituales

¿Cuál es el propósito práctico del seguimiento posterior a la comercialización?

Detectar cuándo el uso real cuestiona supuestos anteriores al lanzamiento y convertir esas pruebas en acciones revisadas. El resultado operativo es una decisión defendible y un seguimiento verificado, respaldados por hallazgos trazables.

¿Toda empresa SaaS necesita un plan del artículo 72?

No lo suponga. Confirme clasificación de alto riesgo, condición de proveedor, alcance y calendario. Otros sistemas pueden beneficiarse de seguimiento proporcionado; los responsables del despliegue deben evaluar por separado sus responsabilidades.

¿Qué debemos documentar primero?

Empiece con límites de un sistema, responsable, fallos principales, señales disponibles y vía urgente de escalada. Procese un hallazgo real antes de extender el método a toda la cartera.

¿Qué pruebas debe producir una revisión?

Conserve versión del plan, pruebas examinadas, límites de cobertura, decisión, responsable de acción y resultado de verificación. Un revisor debe seguir el recorrido de señal a cierre sin reconstruir la memoria del equipo.

Fuentes

El análisis jurídico utiliza el Reglamento de IA consolidado, la modificación Ómnibus de IA y las referencias de la Comisión enlazadas junto a las afirmaciones. Situación jurídica comprobada el 13 de septiembre de 2026. Los ejemplos operativos y ritmos sugeridos son recomendaciones editoriales.

Imagen: Team Meeting, de woodleywonderworks, CC BY 2.0, vía Wikimedia Commons; redimensionada a 1280 × 482 píxeles.