¿Qué es el seguimiento poscomercialización y la notificación de incidentes en IA?
Regulación de la IA: conceptos, instituciones y normas
El seguimiento poscomercialización y la notificación de incidentes en IA es el proceso continuo de supervisar un sistema de IA tras su despliegue, recopilar evidencias sobre su funcionamiento en uso real, identificar fallos dañinos o usos indebidos, y escalar los casos graves a los reguladores, clientes u otras partes responsables cuando se alcanzan los umbrales legales o contractuales establecidos. En la práctica, convierte la gobernanza de la IA de un ejercicio de lanzamiento en un ciclo de control continuo de registro, revisión, acción correctiva y, cuando procede, notificación formal.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
El seguimiento poscomercialización comienza cuando un sistema de IA está en producción, no cuando supera las pruebas. Consiste en la recopilación organizada de evidencias del uso real: registros, comentarios de operadores, reclamaciones de usuarios, comportamientos inesperados, señales de uso indebido, fallos causados por actualizaciones y problemas derivados de la interacción con otros sistemas.
La notificación de incidentes es la capa de escalada que se añade a lo anterior. La mayoría de los problemas se gestionan dentro de los procesos habituales de calidad, seguridad o riesgo. Un subconjunto más reducido supera un umbral definido, como daños graves a la salud, interrupción de infraestructuras críticas, vulneraciones graves de derechos o cualquier otro desencadenante establecido por la normativa sectorial o el contrato. En ese momento, la organización puede estar obligada a notificar a un regulador, un proveedor, un cliente u otra parte responsable dentro de los plazos establecidos.
Por tanto, este tema no es simplemente "seguimiento" ni simplemente "respuesta a incidentes". Es el puente entre la supervisión en tiempo real y la rendición de cuentas formal.
Por qué es importante
Los sistemas de IA suelen comportarse de forma diferente en producción a como lo hacían en las pruebas. Los usuarios reales improvisan, los datos cambian, las interfaces se modifican, los componentes de terceros se actualizan y algunos sistemas siguen adaptándose tras su lanzamiento. Los reguladores y los organismos de normalización prestan atención al seguimiento poscomercialización porque las verificaciones previas al lanzamiento no pueden predecir plenamente esas condiciones reales.
Para las organizaciones, aquí es donde la gobernanza adquiere credibilidad. Un régimen de seguimiento poscomercialización maduro permite detectar daños antes, conservar evidencias, decidir si parchear, revertir o suspender el uso, y demostrar a clientes, auditores y autoridades que se puede gestionar la IA desplegada, no solo aprobarla en el momento del lanzamiento. Sin él, los fallos graves se descubren tarde, las explicaciones son débiles y los plazos de notificación se incumplen con facilidad.
Cómo funciona
El ciclo de control básico
El seguimiento poscomercialización debe ser activo y sistemático, no improvisado. En el modelo legal más exigente vigente, el proveedor de un sistema de IA de alto riesgo debe contar con un sistema y un plan de seguimiento documentados, proporcionales a la tecnología y al nivel de riesgo. En términos prácticos, esto implica recopilar y revisar registros, reclamaciones del campo, comentarios de los desplegadores, informes de uso indebido, avisos de proveedores y señales de que el sistema se comporta de forma diferente en producción.
Un buen seguimiento también va más allá de los incidentes plenamente formados. La OECD distingue entre un incidente, en el que el desarrollo, uso o mal funcionamiento de la IA ha causado daño, y un peligro, en el que podría causarlo de forma plausible. Esta distinción es útil porque las obligaciones legales más estrictas suelen vincularse a los incidentes, pero una gobernanza responsable debe actuar antes, ante peligros, cuasi accidentes y defectos recurrentes de bajo nivel.
Cuándo un problema se convierte en un incidente notificable
No todo error es un incidente de IA notificable. La mayoría de las organizaciones necesitan una escala de gravedad que diferencie los defectos rutinarios, las señales de riesgo elevado, los peligros o cuasi accidentes, y los incidentes graves notificables. El umbral exacto depende del régimen aplicable. El umbral legal intersectorial más claro hasta la fecha proviene del EU AI Act, que considera incidentes graves los eventos o fallos que provoquen la muerte o daños graves a la salud, una interrupción grave e irreversible de infraestructuras críticas, el incumplimiento de obligaciones del Derecho de la Unión destinadas a proteger los derechos fundamentales, o daños graves a la propiedad o al medio ambiente.
Una lección práctica útil del modelo europeo es que la notificación no espera a tener certeza absoluta. El proveedor notifica una vez que ha establecido un vínculo causal, o la probabilidad razonable de que exista, entre el sistema y el incidente grave. Cuando la rapidez es determinante, el informe inicial puede ser incompleto y completarse posteriormente con uno más detallado. En otras palabras, la regla operativa habitual es "escalar y preservar evidencias primero, completar el análisis después".
Responsabilidades a lo largo de la cadena de valor de la IA
Las obligaciones de seguimiento poscomercialización raramente recaen en un solo equipo o una sola empresa. En el modelo europeo, el proveedor es el titular del sistema formal de seguimiento poscomercialización para los sistemas de IA de alto riesgo. El desplegador también tiene obligaciones durante el uso: debe supervisar el funcionamiento conforme a las instrucciones del proveedor, informarle cuando proceda y suspender el uso si tiene motivos para creer que el sistema presenta un riesgo. Si el desplegador identifica un incidente grave, debe informar de inmediato al proveedor y, a continuación, al importador o distribuidor y a la autoridad competente. Los desplegadores también deben conservar los registros bajo su control durante un período definido.
La cadena de valor es relevante porque los incidentes suelen implicar modelos alojados externamente, datos de terceros, herramientas integradas o integradores intermedios. El EU AI Act exige acuerdos escritos entre los proveedores de sistemas de IA de alto riesgo y los terceros que suministran herramientas, servicios, componentes o procesos, de modo que el proveedor disponga de la información y el acceso técnico necesarios para el cumplimiento normativo. El perfil de IA generativa de NIST traslada esta misma idea al plano operativo, recomendando cláusulas sobre incidentes en los contratos con proveedores, incluidas la asignación de responsabilidades, los tiempos de respuesta y la notificación de incidentes graves derivados de datos y sistemas de terceros.
Las evidencias que debe generar un sistema de seguimiento
El seguimiento importa porque genera evidencias, no solo conciencia. Las evidencias útiles suelen incluir un plan de seguimiento, registros de producción, historial de versiones, registros de cambios, comentarios de usuarios y operadores, tickets de incidencias, decisiones de gravedad, evaluaciones de riesgo, comunicaciones con contrapartes, acciones correctivas, registros de reversión y revisiones posteriores a los incidentes. Este material es lo que permite a un responsable de gobernanza explicar qué ocurrió, por qué la organización respondió como lo hizo y si se activaron obligaciones legales.
Aquí es también donde el seguimiento poscomercialización se conecta con la garantía, la auditoría y la gestión de riesgos. El AI RMF de NIST sitúa el seguimiento posterior al despliegue, la respuesta a incidentes, la recuperación y la comunicación dentro de la función MANAGE. Su perfil de IA generativa va más lejos al recomendar el seguimiento de errores y cuasi accidentes, la revisión posterior a los incidentes, las vías de escalada a organismos legales y regulatorios cuando proceda, y el seguimiento continuo de sistemas de IA generativa de terceros en producción. Si una organización no puede reconstruir el evento y el rastro de decisiones asociado, su régimen de seguimiento aún no es maduro.
Cómo utilizan el concepto las normas y los marcos voluntarios
Las normas y los instrumentos intergubernamentales tratan el seguimiento poscomercialización como una obligación de gobernanza continua. NIST lo enmarca como seguimiento y mejora regulares de los sistemas de IA desplegados. El Código de Conducta del Proceso de Hiroshima establece que las organizaciones que desarrollan IA avanzada deben supervisar vulnerabilidades, incidentes, riesgos emergentes y usos indebidos tras el despliegue, facilitar la divulgación responsable por parte de usuarios y terceros, documentar los incidentes notificados y compartir información relevante con las autoridades públicas y la ciudadanía cuando proceda.
El Hiroshima AI Reporting Framework convierte esa lógica voluntaria en un proceso de información pública estandarizado. Está abierto a organizaciones de toda la cadena de valor de la IA, los informes son publicados por OECD.AI y la primera ronda produjo 25 informes públicos. Esto no equivale a la notificación obligatoria de incidentes a un regulador. Su valor reside en la comparabilidad, la rendición de cuentas pública y el aprendizaje transfronterizo. El marco común de notificación de incidentes de IA de la OECD cumple una función diferente pero complementaria, al ofrecer una taxonomía interoperable que las jurisdicciones pueden utilizar tanto para regímenes de notificación obligatoria como voluntaria.
Dónde es más sólida hoy la legislación vinculante
Actualmente, la arquitectura legal de aplicación general más sólida específica para la IA se encuentra en el EU AI Act. Para los sistemas de IA de alto riesgo, los proveedores deben establecer y documentar un sistema de seguimiento poscomercialización proporcional a los riesgos, basado en un plan de seguimiento que forme parte de la documentación técnica. El sistema debe recopilar, documentar y analizar de forma activa y sistemática los datos relevantes del campo a lo largo de toda la vida útil del sistema, incluida, cuando proceda, su interacción con otros sistemas de IA.
La misma norma otorga verdadero peso a la notificación de incidentes. Los proveedores de sistemas de IA de alto riesgo comercializados en el mercado de la Unión deben notificar los incidentes graves a la autoridad de vigilancia del mercado del Estado miembro donde se produjo el incidente. El plazo base es de no más de 15 días desde que se tiene conocimiento, pero el calendario se acorta a 2 días en caso de infracciones generalizadas o de interrupción grave e irreversible de infraestructuras críticas, y a 10 días en caso de fallecimiento. Tras la notificación, el proveedor debe investigar sin demora, realizar una evaluación de riesgos y adoptar medidas correctivas. La autoridad debe adoptar las medidas oportunas en un plazo de siete días desde la recepción de la notificación.
El marco europeo también muestra cómo el seguimiento poscomercialización interactúa con la normativa sectorial. Permite cierta integración con los sistemas de seguimiento existentes en la legislación sobre productos y con los mecanismos de gobernanza interna en los servicios financieros. Para los modelos de IA de uso general con riesgo sistémico, ya se aplica una obligación de notificación relacionada pero diferenciada: los proveedores deben registrar, documentar y notificar sin demora indebida información relevante sobre incidentes graves y posibles medidas correctivas a la Oficina de IA y, cuando proceda, a las autoridades nacionales.
Un límite temporal importante es el siguiente. A junio de 2026, la mayoría de las normas sobre sistemas de IA de alto riesgo están previstas para aplicarse a partir del 2 de agosto de 2026, mientras que las obligaciones para los proveedores de IA de uso general ya se aplican desde el 2 de agosto de 2025. La Comisión Europea propuso ajustar el calendario de las normas sobre alto riesgo porque las normas técnicas clave y las medidas de apoyo se han retrasado, y en mayo de 2026 se alcanzó un acuerdo político provisional para aplazar varias de estas fechas en el marco del Digital Omnibus, por lo que la fecha de aplicación debe confirmarse con la posición actual. El diseño institucional es claro, pero algunos plazos de implementación siguen siendo provisionales.
Ejemplos
Ejemplo actual en la UE: se espera que el proveedor de un sistema de IA de alto riesgo ejecute un plan de seguimiento poscomercialización documentado que recopile evidencias del campo a lo largo de toda la vida útil del sistema. Si se identifica un incidente grave, el desplegador informa al proveedor y a la autoridad competente; el proveedor puede presentar un informe inicial incompleto si la rapidez es crítica y, a continuación, debe investigar, evaluar el riesgo y adoptar medidas correctivas. Este es el flujo de trabajo legal central que la UE está construyendo para la IA de alto riesgo desplegada.
Ejemplo actual en el sector del transporte: en Estados Unidos, la Standing General Order de la NHTSA exige a determinados fabricantes y operadores que notifiquen ciertos accidentes que involucren sistemas de conducción automatizada o sistemas avanzados de asistencia al conductor de nivel 2. El objetivo es una notificación oportuna y transparente desde el campo para que la agencia pueda investigar las preocupaciones de seguridad en el mundo real y, si es necesario, emprender acciones por defectos. Es un ejemplo sectorial de seguimiento poscomercialización traducido en notificación obligatoria de incidentes.
Ejemplo voluntario global actual: el Hiroshima AI Reporting Framework permite a las organizaciones de toda la cadena de valor de la IA presentar informes públicos sobre cómo gestionan los riesgos y gobiernan la IA avanzada. OECD.AI publica esos informes, acepta envíos de forma continua y señala que la primera ronda generó 25 informes. No se trata de un desencadenante de incidentes de derecho positivo, pero muestra cómo la información pública puede generar evidencias compartidas y escrutinio entre pares antes de los mandatos legales o junto a ellos.
Malentendidos frecuentes
"Una vez superadas las pruebas previas al lanzamiento, el seguimiento poscomercialización es opcional." No lo es. El seguimiento existe porque el uso en el mundo real genera riesgos que las pruebas por sí solas no pueden capturar.
"Cualquier error es un incidente de IA notificable." No lo es. La mayoría de los defectos se gestionan dentro de los procesos habituales de calidad, seguridad o riesgo. La notificación externa suele reservarse para eventos graves que superan un umbral legal o contractual.
"Solo el desarrollador del modelo tiene obligaciones." No siempre. Los desplegadores, operadores, distribuidores, importadores y proveedores externos pueden tener responsabilidades de seguimiento, registro, escalada o intercambio de información.
"La notificación de incidentes solo comienza cuando la causalidad está plenamente probada." No necesariamente. Algunos regímenes exigen la notificación una vez establecido un vínculo causal, o la probabilidad razonable de que exista.
"Un informe de transparencia equivale a un informe de incidente." No es así. Los informes de transparencia describen en términos generales las prácticas de gobernanza, las capacidades, las limitaciones o las salvaguardias. Los informes de incidentes son escaladas específicas de un evento vinculadas a un fallo concreto o a un riesgo grave.
Riesgos y límites
El seguimiento poscomercialización no sustituye a la evaluación de riesgos, la garantía, el red-teaming, las pruebas de seguridad ni un plan de respuesta a incidentes. Es la capa operativa en tiempo real que alimenta esos mecanismos tras el despliegue. Una organización puede tener buenos controles previos al despliegue y aun así fallar en el seguimiento en producción, y lo contrario también es cierto.
Tampoco es un ejercicio orientado exclusivamente al regulador. La mayor parte del trabajo ocurre antes de que se envíe cualquier notificación formal: detectar el problema, preservar evidencias, evaluar la gravedad, mitigar el daño, determinar si se ha alcanzado un umbral legal o contractual y solo entonces presentar o actualizar las notificaciones. Si los equipos se centran únicamente en lo que debe notificarse externamente, suelen pasar por alto peligros, cuasi accidentes y fallos menores recurrentes que apuntan a un problema de gobernanza más amplio.
Las obligaciones legales siguen siendo desiguales entre jurisdicciones y sectores. Fuera del régimen de IA intersectorial de la UE y de campos especializados como el transporte, muchos modelos de notificación siguen siendo sectoriales o voluntarios. Incluso cuando la notificación es obligatoria, un informe no prueba por sí solo que la IA haya causado el daño. Los sistemas de notificación pueden ser incompletos o generar ruido, y el intercambio de información debe respetar los límites de privacidad, confidencialidad y propiedad intelectual. A junio de 2026, algunos plazos de implementación de alto riesgo en la UE siguen sujetos a posibles ajustes legislativos.
Qué hacer a continuación
Comience por identificar su rol en cada despliegue: proveedor, desplegador, integrador, distribuidor, comprador o proveedor de modelos con riesgo sistémico. Ese mapa de roles debe determinar quién supervisa el sistema, quién decide la gravedad, quién tiene autoridad para suspender o revertir el uso, y quién notifica a los reguladores o contrapartes.
A continuación, plasme el modelo operativo por escrito. Necesita una taxonomía de incidentes que diferencie defectos rutinarios, peligros, cuasi accidentes e incidentes graves notificables; normas de registro y conservación de evidencias; responsables de escalada designados; una matriz de notificación que cubra autoridades y contrapartes; y cláusulas contractuales que exijan a los proveedores notificación oportuna, acceso técnico y soporte.
Por último, ensaye el proceso. Un ejercicio de simulación que comience con una reclamación de usuario, una señal de deriva o una vulnerabilidad de un tercero y concluya con un borrador de notificación al regulador suele ser la forma más rápida de detectar registros ausentes, responsables no asignados y derechos contractuales inexistentes. Revise todo el régimen tras actualizaciones importantes del modelo, cambios en el despliegue o cambios de proveedor.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿El seguimiento poscomercialización solo es relevante para la IA generativa?
No. Cualquier IA desplegada puede generar problemas de seguridad, derechos, ciberseguridad o fiabilidad en el uso real. La IA generativa añade problemas recurrentes como la confabulación, el uso indebido y la dependencia de modelos de terceros, pero la lógica de gobernanza es más amplia.
¿Cuál es la diferencia entre un peligro y un incidente?
Un peligro es una situación que podría causar daño de forma plausible. Un incidente es aquel en el que el desarrollo, uso o mal funcionamiento de la IA ya ha causado, directa o indirectamente, el daño cubierto. Los equipos maduros hacen seguimiento de ambos.
¿Es necesario notificar a una autoridad cada error del modelo?
No. La mayoría de los errores se gestionan dentro de los procesos habituales de calidad o seguridad. La notificación externa suele reservarse para eventos graves que superan un umbral legal o contractual.
¿Quién notifica cuando el proveedor y el desplegador son organizaciones distintas?
Depende del régimen aplicable. En virtud del EU AI Act, el proveedor suele tener la obligación formal de notificar a la autoridad en el caso de sistemas de alto riesgo, mientras que el desplegador debe supervisar el uso y alertar de inmediato al proveedor y a la autoridad si identifica un incidente o riesgo grave.
¿Qué evidencias debemos conservar?
Como mínimo, conserve los planes de seguimiento, los registros bajo su control, los historiales de versiones y cambios, los comentarios de usuarios y operadores, las decisiones de clasificación de incidentes, las acciones correctivas y las comunicaciones con contrapartes o autoridades.
¿Pueden los marcos de notificación voluntaria sustituir a las obligaciones legales vinculantes?
No. Marcos como el Hiroshima AI Reporting Framework pueden mejorar la comparabilidad y la confianza, pero complementan las obligaciones legales de notificación en lugar de sustituirlas.
¿Por qué está vinculado esto a los contratos?
Porque los incidentes suelen implicar a proveedores, modelos alojados externamente, proveedores de datos e integradores. Sin cláusulas de notificación, derechos de acceso y responsabilidades acordadas, una organización puede no ser capaz de investigar con la rapidez suficiente ni cumplir los plazos de notificación.
¿Ya están vigentes los plazos de notificación de alto riesgo de la UE?
La obligación de notificación específica para los proveedores de modelos de IA de uso general con riesgo sistémico ya se aplica. La mayoría de las obligaciones relativas a sistemas de IA de alto riesgo están previstas para el 2 de agosto de 2026 según el texto publicado, pero en mayo de 2026 se alcanzó un acuerdo político provisional para aplazar varias de estas fechas en el marco del Digital Omnibus, por lo que esa fecha no debe considerarse definitiva.
Fuentes
Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (European Union). Core legal definitions of "serious incident", provider post-market monitoring duties, deployer monitoring and logging duties, GPAI systemic-risk reporting duty, deadlines, investigations, and enforcement flow under the EU AI Act.
Navigating the AI Act (European Commission). Current Commission explanation of who must monitor and report under the AI Act, applicability dates, governance structure, and the note that a proposal to adjust high-risk timing is under consideration.
Artificial Intelligence Risk Management Framework (AI RMF 1.0) (National Institute of Standards and Technology). The standards-based governance logic for post-deployment monitoring, incident response, recovery, communication and documentation in the MANAGE function.
Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (National Institute of Standards and Technology). Detailed operational practices for generative AI, including incident monitoring, after-action review, near-miss tracking, legal and regulatory escalation, third-party monitoring, and vendor contract considerations.
Hiroshima Process International Code of Conduct for Organizations Developing Advanced AI Systems (Ministry of Foreign Affairs of Japan). Voluntary commitments to monitor vulnerabilities, incidents, emerging risks and misuse after deployment, document incidents, support responsible disclosure, publish transparency reports, and share relevant information with authorities.
Hiroshima AI Reporting Framework (Organisation for Economic Co-operation and Development). The practical structure of the Hiroshima reporting process, its public and rolling submission model, its scope across the AI value chain, and the fact that the first round produced 25 reports.
Towards a Common Reporting Framework for AI Incidents (Organisation for Economic Co-operation and Development). Interoperable definitions of AI incidents and hazards, and the OECD view that a common framework can support both mandatory and voluntary incident reporting across jurisdictions.
Standing General Order on Crash Reporting (U.S. Department of Transportation, National Highway Traffic Safety Administration). A current sector-specific example of mandatory post-market incident reporting for automated driving systems and Level 2 advanced driver assistance systems.