Ingeniería · Evidencia
La cadena de evidencia
Cinco disposiciones en tres capítulos, leídas como una sola tubería. Escrito para el equipo que ejecuta el sistema en su propia infraestructura y controla los registros, porque es el equipo al que el Reglamento se dirige una y otra vez y para el que casi nadie escribe.
El incidente que no puedes reconstruir
Un cliente discute una decisión que tu sistema tomó hace cuatro meses. Aún tienes el modelo, el código y un panel. Lo que puede que no tengas es el registro de esa decisión: qué versión del modelo, sobre qué entrada, con qué salida y quién la vio. Ese hueco es el que esta cadena existe para cerrar, y cada disposición de abajo es una pieza de él.
Cinco disposiciones, una sola tubería
Leídos por separado, los artículos 12, 19, 26, apartado 6, 72 y 73 son cinco obligaciones en tres capítulos distintos. Leídos desde la silla de quien opera, son una sola tubería con un único resultado: poder responder, meses después, por qué un sistema produjo un resultado concreto en una fecha concreta, y poder demostrarlo. Todo lo que sigue va en ese orden.
| Paso | Qué pide la disposición | Dónde |
|---|---|---|
| Registrar | El sistema permite técnicamente el registro automático de acontecimientos durante su ciclo de vida | Art. 12 |
| Conservar | El proveedor conserva los registros que controla, al menos seis meses; el responsable del despliegue conserva los que controla, con el mismo mínimo | Art. 19, art. 26(6) |
| Documentar | La documentación técnica existe antes de introducir el sistema en el mercado y queda a disposición de las autoridades durante diez años | Art. 11, anexo IV, art. 18 |
| Vigilar | Un sistema de vigilancia poscomercialización documentado, basado en un plan que forma parte de la documentación técnica | Art. 72 |
| Notificar | Los incidentes graves llegan a la autoridad de vigilancia del mercado dentro de los plazos que fija el artículo | Art. 73 |
Registrar: qué pide el artículo 12 a un sistema
El artículo 12 no te dice que guardes registros. Dice que un sistema de alto riesgo permitirá técnicamente el registro automático de acontecimientos durante su ciclo de vida, y que esa capacidad permitirá registrar los acontecimientos pertinentes para tres fines concretos: detectar situaciones en las que el sistema presente un riesgo en el sentido del artículo 79, apartado 1, o dé lugar a una modificación sustancial, facilitar la vigilancia poscomercialización del artículo 72 y vigilar el funcionamiento conforme al artículo 26, apartado 5. Para los sistemas de identificación biométrica remota, el artículo 12, apartado 3, añade un mínimo: el período de cada uso, la base de datos de referencia consultada, los datos de entrada que produjeron una correspondencia y la identidad de quienes verificaron el resultado.
Una forma de cumplirlo
- Un acontecimiento de inferencia por decisión, con un identificador de correlación que sobreviva a cada salto entre servicios.
- Versiones de modelo y de prompt, referencias de entrada y salida, registradas como campos y no reconstruidas desde un panel.
- Trazas de OpenTelemetry para el camino de la petición, y el registro de aplicación para la decisión: la traza explica la latencia, el acontecimiento explica el resultado.
- Registros de auditoría de Kubernetes para saber quién cambió el sistema, que es una pregunta distinta de qué hizo el sistema.
Práctica de ingeniería, no una exigencia legal. La columna de la izquierda es la ley.
Conviene saber Las palabras "a prueba de manipulaciones" no aparecen en el artículo 12. La integridad es una buena respuesta de ingeniería a un riesgo real, no una exigencia legal.
Conservar: quién custodia los registros, y cuánto tiempo
Dos disposiciones, un mismo mínimo, dos custodios. El artículo 19 obliga al proveedor a conservar los registros del artículo 12, apartado 1, que sus sistemas generan automáticamente, en la medida en que estén bajo su control, durante un período adecuado a la finalidad prevista y de al menos seis meses. El artículo 26, apartado 6, dice lo mismo al responsable del despliegue, para los registros bajo su control. Si ejecutas el sistema en tu propia infraestructura, los registros están bajo tu control y la frase habla de ti. El mínimo es un suelo, y otras normas de la Unión o nacionales, en particular las de protección de datos, pueden mover la respuesta en cualquier dirección.
Una forma de cumplirlo
- Decide la custodia antes que la retención: qué registros son tuyos porque nunca salen de tu clúster y cuáles guarda el proveedor.
- Almacenamiento de objetos con una política de retención que supere el mínimo de seis meses, y una razón explícita allí donde guardes menos.
- Una vía de borrado que sobreviva a una solicitud de supresión sin destruir la evidencia que estás obligado a conservar, acordada con quien lleve protección de datos.
- Un simulacro de restauración: una política de retención que nadie ha leído nunca de vuelta es una afirmación, no una prueba.
Práctica de ingeniería, no una exigencia legal. La columna de la izquierda es la ley.
Conviene saber El artículo 18 es otro reloj para otro objeto: la documentación técnica queda a disposición de las autoridades nacionales competentes durante diez años, y eso es documentación, no registros.
Documentar: el expediente que debe existir antes de lanzar
El artículo 11 exige que la documentación técnica de un sistema de alto riesgo se redacte antes de introducirlo en el mercado o ponerlo en servicio, y se mantenga actualizada. Debe demostrar el cumplimiento de los requisitos de la sección 2 del capítulo III y contener, como mínimo, los elementos del anexo IV. Las pymes, incluidas las empresas emergentes, y las pequeñas empresas de mediana capitalización pueden facilitar esos elementos de forma simplificada. El artículo 18 mantiene después ese expediente, la documentación del sistema de gestión de la calidad, las decisiones de los organismos notificados y la declaración UE de conformidad a disposición de las autoridades nacionales competentes durante diez años.
Una forma de cumplirlo
- Genera lo que puedas desde el repositorio: las fichas de modelo, los resultados de evaluación y el linaje de datos envejecen mal cuando se mantienen a mano.
- Versiona la documentación junto al sistema, para que "la documentación tal como estaba en esa versión" sea un checkout y no una excavación.
- Guarda el plan de vigilancia poscomercialización en el mismo expediente, porque el artículo 72, apartado 3, lo incluye en la documentación del anexo IV.
Práctica de ingeniería, no una exigencia legal. La columna de la izquierda es la ley.
Vigilar: la vigilancia poscomercialización es un sistema, no un panel
El artículo 72 obliga al proveedor a establecer y documentar un sistema de vigilancia poscomercialización, proporcionado a la tecnología y a los riesgos, que recopile, documente y analice de manera activa y sistemática datos sobre el rendimiento de sus sistemas de alto riesgo durante todo su ciclo de vida, incluidos los datos que faciliten los responsables del despliegue. El texto dice para qué: para evaluar el cumplimiento continuo de los requisitos de la sección 2 del capítulo III. El sistema se apoya en un plan, y ese plan forma parte de la documentación técnica del anexo IV.
Una forma de cumplirlo
- Encauza deliberadamente la señal del responsable del despliegue: el artículo 26, apartado 5, envía información de este al proveedor, y alguien tiene que ser dueño de ese buzón.
- Vigila la deriva respecto de los requisitos, no solo la disponibilidad: precisión, solidez y el comportamiento que predijo el expediente de riesgos.
- Conserva el análisis, no solo la alerta. El artículo pide datos recopilados, documentados y analizados.
Práctica de ingeniería, no una exigencia legal. La columna de la izquierda es la ley.
Notificar: los relojes que empiezan cuando te enteras
El artículo 73 obliga al proveedor a notificar cualquier incidente grave a las autoridades de vigilancia del mercado del Estado miembro donde se produjo. El reloj empieza cuando el proveedor, o en su caso el responsable del despliegue, tiene conocimiento de él, y el artículo fija tres plazos distintos. Se permite expresamente un informe inicial incompleto seguido de uno completo cuando sea necesario para notificar a tiempo, y tras la notificación el proveedor investiga, evalúa el riesgo y adopta medidas correctoras.
| Situación | Plazo | Dónde |
|---|---|---|
| Un incidente grave, en general | Inmediatamente tras establecer el vínculo causal o su probabilidad razonable, y a más tardar 15 días después de tener conocimiento | Art. 73(2) |
| Una infracción generalizada, o un incidente del artículo 3, apartado 49, letra b) | Inmediatamente, y a más tardar 2 días | Art. 73(3) |
| El fallecimiento de una persona | Inmediatamente tras establecer o sospechar la relación causal, y a más tardar 10 días | Art. 73(4) |
Una forma de cumplirlo
- Ensaya la reconstrucción antes de necesitarla: el informe del incidente se escribe con los registros que produjeron los dos primeros pasos.
- Mete el reloj en el runbook de guardia. Quince días son generosos hasta que la primera semana se va en decidir quién es dueño de la decisión.
- Acuerda por escrito con tus proveedores con qué rapidez te avisan: tu reloj empieza cuando tienes conocimiento, y su silencio no lo detiene.
Práctica de ingeniería, no una exigencia legal. La columna de la izquierda es la ley.
Conviene saber Las orientaciones de la Comisión sobre el artículo 73 siguen en borrador. Donde este sitio se apoya en ellas, la cita lleva la marca de borrador.
Lo que esta página no decide
- Si estas obligaciones se aplican a tu sistema. Esa es una pregunta de clasificación, y se responde antes de esta página, no en ella.
- Cómo debes construirlo. La columna de práctica es una forma de cumplir la disposición, salida de plataformas que operamos. No es la única y no es Derecho.
- Nada que se parezca a asesoramiento jurídico. Los ingenieros de AstroKube mantienen esta referencia frente a fuentes primarias; somos ingenieros, no juristas.