Activity logs & audit trails

Cada entrada del log debe responder cuatro preguntas sin ambiguedad: quien realizo la acción (el actor autenticado, no solo una IP), que hizo exactamente (verbo legible más categoría), sobre que recurso actuo (objeto con nombre, no ID crudo) y cuando ocurrio (timestamp ISO 8601 con zona horaria explicita). Omitir cualquiera de los cuatro convierte el log en evidencia parcial, inútil para una auditoria legal o para reconstruir un incidente. Cuando el actor es el sistema y no un humano, diferencialo con una etiqueta tipo [Sistema] para que nadie confunda una acción automática con una manual.

La descripción de cada evento debe ser una oración en prosa que cualquier stakeholder no técnico pueda leer sin un diccionario de códigos. El patrón recomendado es sujeto + verbo en pasado + objeto + contexto: "Carlos Perez invito a sofia@empresa.com como Miembro". Resuelve los nombres propios al renderizar, o guarda un snapshot del nombre en el momento del evento, para que un rename futuro no rompa la lectura historica. Usa verbos específicos: "elimino", no "actualizo"; "exporto", no "acciono".

El detalle de una entrada de edición debe expandirse para mostrar el antes y el después campo por campo, con resaltado de lo que cambio. Pero los logs se exportan y son accesibles a multiples roles: nunca registres contrasenas, tokens, números de tarjeta ni claves de cifrado. Si el campo modificado es sensible, el evento se registra pero el valor se muestra como [redactado]. Así el auditor confirma que la contrasena cambio sin que el log se convierta en un vector de filtración.

Un log sin filtros es inútil a escala. Los filtros mínimos son actor (quien), tipo de acción (que), recurso (sobre que) y rango de fechas. Cada filtro activo debe mostrarse como chip eliminable para que el usuario entienda el estado actual de la vista de un vistazo. Además, ofrece enlaces directos desde el recurso al log ya prefiltrado ("Ver actividad de este usuario"), para que el auditor no tenga que reconstruir el filtro a mano. Un buscador de texto libre que solo hace match en la descripción no sustituye a los filtros tipados.

Compliance, legal y seguridad necesitan llevar los logs fuera del sistema para reportes o reguladores. El export debe respetar los filtros activos (no descargar el log completo cuando el usuario filtro por fecha y actor), ofrecer al menos CSV y JSON, y etiquetar cada campo con nombre claro: actor_name, action_type, timestamp_utc, nunca f1 o col_4. Incluye metadata de cadena de custodia en el archivo: quien lo genero, cuando y con que filtros. El botón debe declarar el alcance: "Exportar (247 registros)".

Un log que un administrador puede modificar o borrar no es evidencia confiable. La implementación debe ser append-only a nivel de base de datos (sin UPDATE ni DELETE en la tabla de audit), con verificación de integridad por hash chaining para detectar cualquier alteración. En la UI, ningun control de edición o papelera debe ser visible en el log, ni siquiera para superadmins: lo único que aparece al hacer hover es "Ver detalle". Comunica la garantía con un badge visible: "Inmutable · Hash verificado".

El contexto de origen, dirección IP, pais aproximado y dispositivo o user-agent, convierte una entrada en evidencia accionable: permite detectar un acceso desde una geografia inusual o un dispositivo nuevo. Los eventos de seguridad (login fallido repetido, cambio de contrasena, MFA deshabilitado, sesión sospechosa) deben destacarse visualmente del ruido operativo con un acento de color y un icono, no perderse en una lista uniforme. Para logs fríos enmascara la IP a /24 para cumplir GDPR sin perder la señal de geolocalización.

Un feed de actividad en vivo debe envolver su contenedor en role="log", que implica aria-live="polite" y aria-atomic="false": el lector de pantalla anuncia cada nueva entrada sin interrumpir la narración en curso. Dale un aria-label descriptivo y, para tablas paginadas, confirma los resultados de filtro con una region aria-live ("Mostrando 50 resultados"). Cada timestamp debe usar <time datetime="2026-06-14T10:32:00-06:00">: el texto visible puede ser relativo ("hace 3 horas") mientras el atributo conserva la fecha absoluta con zona horaria para la tecnologia de asistencia.