Guías

¿Cómo demuestras después que el sistema estaba funcionando?

En resumen

Tarde o temprano alguien te pide que demuestres que algo estaba funcionando. La memoria no es una prueba y una captura de pantalla no es un registro. Lo que responde a esa pregunta es un historial guardado de forma continua, incidentes con horas reales y un informe periódico que no escribiste después de los hechos.

Toda conversación sobre monitorización va del futuro: nos enteraremos antes, nos lo dirán más rápido. Y un día la conversación se da la vuelta y alguien pregunta por el pasado. ¿Estaba funcionando el día once? ¿Cuánto tiempo estuvo caído? ¿Cómo lo sabes?

En ese momento la calidad de tu monitorización se mide de otra manera. No por lo rápido que avisó, sino por lo que guardó.

¿Por qué el recuerdo no vale como prueba?

Porque tres semanas después de una caída nadie la recuerda con exactitud. La duración encoge o crece según quién hable. La hora de inicio se convierte en “hacia la hora de comer”. Una captura de pantalla demuestra que una pantalla tenía cierto aspecto cuando alguien la hizo, que no es lo mismo que demostrar lo que pasó.

Lo que aguanta un escrutinio es un registro producido mientras las cosas estaban pasando, sin que nadie decidiera producirlo: comprobaciones que se ejecutaron según un calendario, un incidente abierto automáticamente al primer fallo y no cuando se dio cuenta una persona, una hora de cierre y las notas escritas durante la reparación. El valor de ese registro viene precisamente de que nadie eligió escribirlo.

¿Qué tiene que contener el registro?

  • Qué se vigilaba, con un nombre claro, para que quien lo lea sin ser técnico entienda de qué se trataba.
  • Cuándo dejó de contestar y cuándo volvió, con el incidente fechado desde la primera comprobación fallida y no desde el momento en que alguien miró.
  • Desde dónde se ejecutaron las comprobaciones, porque “inalcanzable desde fuera” y “roto” son dos afirmaciones distintas y normalmente solo una de las dos es cierta.
  • Qué se hizo entre medias: confirmado a tal hora, investigado, resuelto. Notas cortas, escritas entonces.
  • Qué estaba planificado, separado de lo que falló. Un mantenimiento anunciado no es una caída, y poder enseñar esa distinción es lo que corta una discusión sobre un número.
  • Un resumen periódico producido según un calendario —disponibilidad, tiempos de respuesta, los incidentes del mes, los mantenimientos, el estado de los certificados y del alojamiento— que llega por correo haya pasado algo interesante o no. Un informe escrito el día en que hace falta vale muy poco.

El ángulo suizo, dicho con cuidado

La Ordenanza de protección de datos (RS 235.11) es el único texto que hemos encontrado que habla directamente de esto. El artículo 3 apartado 2 letra e pide que se tomen medidas para que los fallos de funcionamiento se notifiquen. El apartado 3 letra c pide que las violaciones de la seguridad se identifiquen con rapidez. El artículo 4 apartado 5 pide que los registros se conserven al menos un año, por separado del sistema que describen.

Léelo por lo que dice. Te pide estar en condiciones de darte cuenta y de conservar la traza. No impone ningún producto, ni el nuestro ni el de nadie, y cualquier proveedor que te diga que su herramienta es “exigida por la ley” te está diciendo algo que no está en el texto. Lo que sí es cierto es más estrecho y sigue siendo útil: si tienes que demostrar que estabas vigilando, la traza tiene que existir antes de que llegue la pregunta.

El mismo principio aparece en otros sitios con otras palabras. Las orientaciones sobre videovigilancia en Europa esperan que las grabaciones se conserven solo poco tiempo —días, no meses, y cualquier plazo mayor justificado—, y en Suiza la expectativa habitual ronda las veinticuatro horas. Lo que significa que la prueba que te van a pedir muy a menudo no son las imágenes. Es el registro de si el sistema que debería haberlas capturado estaba funcionando.

Qué hacer esta semana

  1. Coge tu última caída real e intenta responder, solo con documentos: cuándo empezó, cuándo terminó, a quién se avisó. Si no puedes, ese es el hallazgo.
  2. Asegúrate de que los incidentes se abren desde la primera comprobación fallida, no desde el momento en que alguien se dio cuenta.
  3. Programa el informe periódico para que llegue lo pidas o no, y guarda los que van llegando.
  4. Declara tus mantenimientos por adelantado, para que el trabajo planificado no haya que discutirlo nunca después.
  5. Decide hasta cuándo necesitas poder mirar hacia atrás y comprueba que la conservación de tu plan llega de verdad tan lejos. Es la única decisión que no se puede arreglar a posteriori.

El día en que alguien te pida demostrarlo, no vas a poder empezar. Solo vas a poder abrir lo que ya tengas.

Lo que no podemos decirte

  • No podemos demostrar que un sistema estuviera haciendo su trabajo: podemos mostrar lo que vieron nuestras comprobaciones, desde dónde se ejecutaron y a qué hora, que es prueba de vigilancia, no un certificado de buen funcionamiento.
  • No podemos darte asesoramiento jurídico y nada de esto lo es: si tu documentación satisface una obligación es una pregunta para un abogado que haya leído tu situación.
  • No podemos enseñarte un detalle que ya no conservamos: el historial por comprobación se guarda durante un periodo que depende de tu plan, de dos semanas a dos años, mientras que los incidentes permanecen.
  • No podemos exportar los datos en bruto como hoja de cálculo: los informes llegan en PDF y por correo, y hoy no hay exportación a CSV ni a Excel.

Las preguntas que se hacen de verdad

¿Quién pide esto en la práctica?

Más gente de la que esperarías. Un cliente después de una caída discutida. Una aseguradora después de un siniestro. Una autoridad de control después de un incidente con datos personales. Un arrendador, un franquiciador, una matriz. Y, la mayoría de las veces, tu propia dirección, tres semanas después, preguntando cuánto duró de verdad: una pregunta que la memoria contesta mal y con mucha seguridad.

¿Hay alguna norma suiza que diga algo sobre esto?

La Ordenanza de protección de datos (RS 235.11) pide, en el artículo 3 apartado 2 letra e, que se tomen medidas para que los fallos de funcionamiento se notifiquen. Vale la pena leerlo con atención: exige estar en condiciones de darse cuenta, no exige ningún producto concreto. Poder demostrar que estabas vigilando ayuda a responder a esa expectativa; no es una certificación legal, y no lo vamos a describir así.

¿Qué cuenta como prueba y qué no?

Un registro producido de forma continua, mientras las cosas pasaban, cuenta. Un documento montado después de memoria no, y todos los presentes en la sala notan la diferencia. La forma útil es aburrida: esto es lo que se vigilaba, estas son las comprobaciones, aquí dejó de contestar, aquí volvió, esto es lo que hicimos entre medias.

¿Cuánto tiempo hay que conservarlo?

Más de lo que crees que vas a necesitar, porque la pregunta siempre llega tarde. La misma ordenanza pide que los registros se conserven al menos un año y por separado del sistema que describen. Nuestra conservación del detalle por comprobación va de dos semanas a dos años según el plan, y los incidentes se guardan sin ese límite, así que la profundidad de tus pruebas es una decisión que tomas al elegir el plan, no después.

¿Ayuda una página de estado?

Sí, por una razón que no tiene nada que ver con la tecnología: está fechada, es pública y se escribió en el momento. Una página que cuenta qué estaba pasando, en el idioma del visitante, es a la vez una forma de evitar veinte llamadas y un registro que nadie puede decir que se inventó después.

Actualizada el 18 de septiembre de 2026 · Angelo Barbosa