Cuando alguien pregunta “¿quién cambió esto?”, “¿por qué se anuló esta solicitud?” o “¿en qué momento falló el proceso?”, un software online debería poder responder con evidencia comprensible. No alcanza con guardar una fecha de modificación: hace falta un registro de actividad diseñado para la operación.
Este registro no es una herramienta para vigilar cada clic. Es una forma de reconstruir acciones relevantes, resolver consultas, detectar fallas y sostener procesos que requieren revisión o aprobación. OWASP señala que los registros de aplicación aportan contexto que normalmente no existe en los logs de infraestructura, y que pueden servir tanto para monitoreo operativo como para auditoría e investigación. Consultá la guía de logging de OWASP.
Un buen historial no intenta registrar todo: registra lo necesario para que una persona pueda entender y actuar.
Empezá por las preguntas que el historial debe responder
Antes de definir tablas, pantallas o alertas, reuní las preguntas reales que hoy obligan a buscar mensajes, revisar planillas o consultar a varias personas. Cada pregunta repetida es una candidata a convertirse en un evento trazable.
- Qué ocurrió: se creó, editó, aprobó, rechazó, asignó, exportó, anuló o eliminó un dato.
- Sobre qué: pedido, cliente, documento, tarea, producto, turno, cuenta u otro objeto del proceso.
- Quién o qué lo hizo: una persona identificada, una integración o una tarea automática.
- Cuándo ocurrió: fecha, hora y zona horaria coherentes para toda la operación.
- Cuál fue el resultado: completado, rechazado, fallido, pendiente o enviado a revisión.
- Por qué importa: motivo informado, regla aplicada o referencia a la solicitud relacionada, cuando corresponda.
El NIST define la gestión de logs como un ciclo que abarca generación, transmisión, almacenamiento, acceso, análisis y disposición. En términos prácticos, esto recuerda que el valor no está solo en “guardar un evento”: también hay que poder encontrarlo, interpretarlo y conservarlo durante el tiempo que el proceso necesite.
Definí un catálogo breve de eventos relevantes
No todos los movimientos merecen el mismo nivel de detalle. Conviene comenzar con acciones que cambian el estado de un proceso, afectan datos importantes, implican autorización o pueden requerir explicación posterior.
Eventos que suelen justificar un registro
- Alta, edición, anulación y eliminación de registros importantes.
- Cambios de estado: borrador, enviado, aprobado, rechazado, cerrado o archivado.
- Asignaciones y reasignaciones entre personas o equipos.
- Aprobaciones, rechazos y excepciones a una regla.
- Importaciones, exportaciones y descargas de información sensible o masiva.
- Acciones realizadas por automatizaciones o integraciones externas.
- Intentos fallidos de acceso y cambios en configuraciones críticas.
Para cada tipo de evento, redactá una ficha simple: nombre del evento, condición que lo dispara, datos mínimos a guardar, responsables que pueden verlo y tiempo de conservación. Este catálogo evita que cada módulo del sistema registre eventos con nombres, criterios y formatos incompatibles.
Guardá contexto, no datos de más
Un evento de negocio puede modelarse con una estructura constante: actor + acción + objeto + momento + resultado + contexto. Por ejemplo: “María Pérez aprobó la solicitud #184 el 4 de septiembre de 2026 a las 10:32, desde el módulo Compras, con el motivo ‘presupuesto validado’”.
Si se modifica un dato relevante, puede ser útil guardar el valor anterior y el nuevo, pero no necesariamente el contenido completo. En una modificación de dirección, quizá alcance con indicar que el campo cambió; en una modificación de importe, en cambio, el antes y el después pueden ser indispensables. La decisión depende de la pregunta que el equipo necesitará responder después.
OWASP recomienda que los eventos incluyan información sobre cuándo, dónde, quién y qué ocurrió, y también advierte que no se deben registrar directamente contraseñas, tokens de acceso, claves, datos de pago ni información personal sensible salvo que exista una razón válida y controles apropiados. La misma guía detalla datos que conviene excluir, enmascarar o seudonimizar.
Diseñá una pantalla que ayude a investigar
Un registro técnicamente completo pero difícil de leer termina sin usarse. La vista de actividad debería presentar primero una frase clara y permitir abrir el detalle solo cuando haga falta.
Elementos útiles en la interfaz
- Una descripción legible: “Carlos reasignó el caso a Soporte nivel 2”, en lugar de un código interno.
- Fecha y hora consistentes: con una convención definida para usuarios de distintas ubicaciones.
- Enlace al objeto relacionado: para pasar del evento al pedido, documento o tarea sin copiar identificadores.
- Filtros concretos: por período, persona, acción, resultado y objeto.
- Detalle progresivo: la lista muestra lo esencial; el panel de detalle aporta motivo, valores relevantes o identificadores técnicos.
- Diferenciación visual de automatizaciones: una integración no debe parecer una acción humana.
También conviene separar el historial operativo que usan los equipos de trabajo de los logs técnicos o de seguridad. Pueden relacionarse mediante un identificador de operación, pero tienen públicos, volúmenes y necesidades de acceso diferentes.
Protegé la integridad y el acceso al historial
Un registro pierde valor si cualquiera puede borrarlo o modificarlo sin dejar rastro. Como mínimo, definí quién puede consultar eventos, quién puede exportarlos y quién administra la política de conservación. Las acciones sobre el propio historial —por ejemplo, una exportación o cambio de configuración— también deberían quedar registradas.
OWASP recomienda proteger los datos de registro frente a acceso no autorizado, modificación y eliminación, además de revisar los privilegios de lectura periódicamente. Esto no obliga a que todo historial sea inmutable en sentido absoluto, pero sí a que cualquier corrección excepcional sea controlada, explicable y trazable.
Probalo con casos reales antes de darlo por terminado
La prueba más útil no es mirar si la tabla recibe filas. Elegí incidentes y dudas frecuentes de la operación y verificá si una persona que no participó del hecho puede reconstruirlo con el historial.
- Una aprobación que se hizo por error.
- Un cambio de importe o de estado discutido por dos áreas.
- Una importación que creó registros duplicados.
- Una tarea automática que falló y volvió a ejecutarse.
- Una consulta sobre quién descargó o exportó determinada información.
Revisá además que el sistema no guarde secretos, que los filtros entreguen resultados correctos, que las fechas sean confiables y que la carga de registrar eventos no degrade el proceso principal. La verificación de la funcionalidad de logging, sus controles de acceso y sus fallas posibles forma parte de las recomendaciones de OWASP.
Conclusión: trazabilidad útil, no acumulación de eventos
Un registro de actividad bien diseñado convierte una discusión basada en recuerdos en una revisión basada en hechos. Empezá por tres o cuatro procesos que hoy generan más consultas, definí un catálogo acotado de eventos y probalo con situaciones reales antes de ampliar la cobertura.
Si tu operación necesita conectar estados, aprobaciones, usuarios, automatizaciones e historial en un mismo flujo, un software o sistema a medida permite diseñar esa trazabilidad alrededor de las reglas reales del negocio, en lugar de forzar el proceso a una herramienta genérica.
