3. Trazabilidad y auditoría: quién cambió qué

Descripción

Al terminar esta lección vas a poder distinguir un rastro de auditoría de un log operativo —se parecen mucho y sirven para cosas distintas—, vas a saber qué campos exige un registro que sirva para responderle a un humano, y vas a diseñar las dos auditorías que necesita Terra Market: la de negocio (qué le hizo el sistema al pedido 4471) y la de plataforma (quién tocó el workflow, la credencial o el interruptor de activación). Vas a conocer qué te da n8n de fábrica para lo segundo, qué cobra y qué no: el Log Streaming es Enterprise, la lista de eventos que emite, y cuál es la alternativa cuando no tienes esa edición. Y vas a decidir el punto que casi nadie decide a tiempo: cuánto tiempo se guarda cada cosa.

Esto importa porque el reclamo del pedido 4471 no se queda en soporte. Cuando un caso escala —el cliente insiste, aparece una devolución de cargo, alguien de dirección pregunta— la conversación cambia de tono. Ya no basta con "creo que el ERP estaba caído": hace falta un registro que aguante que lo cuestionen, con fecha, con actor y con evidencia de que nadie lo tocó después. Y la otra mitad, la que se descubre tarde: un porcentaje muy alto de los incidentes de producción no los causa una API caída, los causa una persona que cambió algo. Sin rastro de quién cambió qué y cuándo, esa causa es invisible.

Conexión con el módulo: la lección 2 te dio el run_log, el registro que escribes para ti. Esta lección construye el registro que escribes para otros —soporte, dirección, el área legal, un cliente— y explica por qué no puede ser el mismo. Es la última pieza de la mitad "memoria" del módulo: con la lección 2 sabes qué pasó, con esta puedes demostrarlo y además sabes quién intervino. A partir de la lección 4 dejamos el caso individual y pasamos a la tendencia. Y hay un hilo que se cierra aquí: la lección 1 mencionó que las ejecuciones anotadas nunca se podan; ahora vas a ver qué papel juega eso en una investigación real.

Dos cuadernos, dos dueños

Vamos a empezar por la distinción, porque todo lo demás se deriva de ella.

Piensa en un taller mecánico. Hay dos cuadernos y ninguno reemplaza al otro.

El primero es el cuaderno del mecánico: apuntes sueltos mientras trabaja. "Probé la bujía 3, chispa débil. Cambié filtro. Ruido sigue con motor frío." Le sirve a él, es desordenado, está lleno de intentos fallidos, y a la semana lo tira. Nadie más lo lee y a nadie le importa.

El segundo es la orden de servicio: fecha, cliente, vehículo, kilometraje, qué pieza se cambió, quién autorizó el gasto, quién hizo el trabajo, firma. Es formal, se guarda años, y existe justamente para el día en que alguien pregunte. Si el motor falla en seis meses y el cliente reclama, esa hoja es la que se pone sobre la mesa.

Tu run_log es el cuaderno del mecánico. Tu audit_log es la orden de servicio.

Con eso en la mano, las diferencias dejan de ser abstractas:

La fila que más gente pasa por alto es la de "se modifica". Un rastro de auditoría es append-only: solo se agregan renglones, nunca se editan ni se borran los que ya están. La razón no es técnica, es de confianza. Un registro que alguien puede editar no demuestra nada, porque siempre cabe la pregunta "¿y quién me dice que no lo cambiaste?". La inmutabilidad es lo que convierte un renglón en evidencia.

Piénsalo como la diferencia entre una libreta con hojas sueltas y un libro cosido con las páginas numeradas. Se puede escribir en los dos. Solo uno sirve cuando alguien duda.

Las cinco preguntas que responde una auditoría

Un renglón de auditoría, para servir, tiene que responder cinco preguntas. Si le falta una, no sirve del todo.

1. ¿Quién? El actor. Una persona con nombre, o un sistema con nombre. Nunca "el sistema" a secas: si fue un proceso automático, di cuál. alicia@terramarket.com o workflow:order-sync, pero algo identificable.

2. ¿Qué hizo? La acción, con un nombre estable y del mismo estilo que los eventos de la lección 2: workflow.deactivated, credential.updated, order.pushed_to_erp.

3. ¿Cuándo? El sello de tiempo en UTC, con la misma disciplina de la lección 2.

4. ¿Sobre qué? El objeto afectado, identificado sin ambigüedad: order:4471, workflow:shipment-notify, credential:erp-api. Un tipo y un identificador.

5. ¿Con qué resultado, y desde qué estado? Qué cambió. Para una acción administrativa, el antes y el después (active: true → false). Para una acción de negocio, el desenlace (accepted, rejected, dropped) y su motivo.

Un renglón completo de Terra Market se ve así:

{
  "ts": "2026-07-14T16:22:09.771Z",
  "actor": "carlos@terramarket.com",
  "actor_type": "user",
  "action": "workflow.deactivated",
  "target_type": "workflow",
  "target_id": "shipment-notify",
  "before": { "active": true },
  "after":  { "active": false },
  "source": "n8n-ui",
  "note": null
}

Léelo en voz alta y suena a frase completa: el 14 de julio a las 16:22 UTC, Carlos desactivó el workflow shipment-notify, que estaba activo, desde la interfaz de n8n. Eso es lo que quieres poder decir seis meses después sin depender de la memoria de nadie.

Fíjate en actor_type. Separar user de system importa más de lo que parece: cuando busques la causa de un incidente, la primera pregunta útil es "¿esto lo hizo una persona o pasó solo?", y esa columna la contesta con un filtro en vez de con una interpretación.

Las dos auditorías de Terra Market

Aquí es donde mucha gente se enreda, porque la palabra "auditoría" se usa para dos cosas distintas que se registran de formas distintas.

Auditoría de negocio: qué le hizo el sistema a un registro. Es el hilo del pedido 4471 en su versión formal. No cada paso interno —eso es el run_log—, sino los hechos con consecuencia para el cliente: se recibió el pedido, se aceptó, se rechazó por tal motivo, se despachó, se notificó, se reembolsó. Es lo que soporte necesita para contestar, y lo que se pone sobre la mesa si hay una disputa.

Auditoría de plataforma: quién tocó el sistema. Quién editó un workflow, quién lo activó o lo desactivó, quién creó o modificó una credencial, quién entró a ver datos de una ejecución, quién invitó a un usuario nuevo. No habla de pedidos: habla de la instancia y de las personas que la operan.

Las dos hacen falta y responden preguntas distintas:

Y aquí está el punto clave para ti como operador: la de negocio la construyes tú; la de plataforma te la da n8n, con condiciones. Vamos con las dos.

La auditoría de negocio: la tabla audit_log

Esta la escribes tú, con el mismo patrón de la lección 2 —el nodo Code arma, otro nodo transporta— pero con criterios distintos sobre qué entra.

El criterio es más estricto que el del run_log. Ahí registrabas decisiones, fronteras y resultados; aquí registras solo lo que le importa a alguien de fuera del equipo técnico. Un reintento contra el ERP es un evento operativo interesantísimo y no tiene nada que hacer en la auditoría de negocio. Que el pedido se haya descartado definitivamente, sí.

La regla práctica:

Va a la auditoría de negocio todo hecho que, si te lo preguntaran dentro de un año, tendrías que poder demostrar.

Para Terra Market son estos, y no más:

Siete acciones. Compara con los seis o siete eventos por ejecución del run_log y verás la diferencia de escala: la auditoría de negocio es deliberadamente escasa.

El esquema, en inglés como todo el código:

CREATE TABLE audit_log (
  id           BIGSERIAL PRIMARY KEY,
  ts           TIMESTAMPTZ NOT NULL,
  actor        TEXT        NOT NULL,   -- persona o 'workflow:order-sync'
  actor_type   TEXT        NOT NULL,   -- 'user' | 'system'
  action       TEXT        NOT NULL,   -- nombre estable, igual que en run_log
  target_type  TEXT        NOT NULL,   -- 'order' | 'shipment' | 'customer'
  target_id    TEXT        NOT NULL,   -- '4471'
  outcome      TEXT,                   -- 'accepted' | 'rejected' | 'dropped'
  reason       TEXT,                   -- por qué, en un valor corto y estable
  before       JSONB,                  -- estado previo, si aplica
  after        JSONB,                  -- estado posterior, si aplica
  source       TEXT,                   -- 'n8n' | 'store-webhook' | 'admin-ui'
  execution_id TEXT                    -- puente hacia run_log y hacia n8n
);

CREATE INDEX idx_audit_target ON audit_log (target_type, target_id, ts);
CREATE INDEX idx_audit_actor  ON audit_log (actor, ts DESC);
CREATE INDEX idx_audit_action ON audit_log (action, ts DESC);

Dos detalles del esquema que importan.

execution_id como puente. Es lo que conecta el renglón formal con el detalle operativo. Soporte lee la auditoría y contesta; si hace falta profundizar, ese campo lleva al run_log y —mientras exista— a la ejecución en n8n. Sin el puente tienes dos registros que hablan del mismo hecho y no se conocen.

No hay columna de "edición". A propósito. Si un registro salió mal, no se corrige: se agrega un renglón nuevo que dice qué se corrigió y quién lo hizo. Es incómodo la primera vez y es la única forma de que la tabla siga siendo evidencia.

Ejemplo trabajado: registrar el hecho del pedido 4471

Vamos a escribir el renglón de auditoría del momento en que order-sync se rinde con el pedido, tras agotar los tres intentos.

Paso 1 — El nodo Code que arma el hecho. Va después del nodo que decide que ya no hay más reintentos.

// Nodo: Code — "build audit fact: order dropped"
// Modo: Run Once for All Items
// Entrada: los pedidos que agotaron todos los intentos contra el ERP
// Salida: un item por hecho de auditoría, listo para insertar

const facts = [];

for (const item of $input.all()) {
  const data = item.json;

  facts.push({
    json: {
      ts: new Date().toISOString(),

      // El actor. Como no hay persona detrás, es el propio workflow,
      // nombrado. Nunca 'el sistema' a secas: eso no identifica nada.
      actor: `workflow:${$workflow.name}`,
      actor_type: 'system',

      // Nombre estable del hecho. Se elige una vez y no se cambia.
      action: 'order.dropped',

      target_type: 'order',
      target_id: String(data.order_id),

      // El desenlace y su porqué, en valores cortos y agrupables.
      outcome: 'dropped',
      reason: 'erp_unreachable',

      // El antes y el después del estado del pedido dentro de n8n.
      before: { status: 'pending_erp' },
      after: { status: 'dropped' },

      source: 'n8n',

      // El puente hacia el detalle operativo: run_log y la ejecución.
      execution_id: $execution.id,
    },
  });
}

return facts;

Paso 2 — El nodo que lo escribe. Igual que en la lección 2: un nodo Postgres en modo Insert contra audit_log. El Code arma, el nodo transporta. Y la misma advertencia: este nodo no va en la ruta crítica; que la auditoría no se pueda escribir no puede tumbar el procesamiento del pedido.

Qué esperar. Después de correrlo, esta consulta devuelve la historia formal completa del pedido:

SELECT ts, actor, action, outcome, reason
FROM audit_log
WHERE target_type = 'order' AND target_id = '4471'
ORDER BY ts;

2026-07-14 10:02:11+00  store-webhook            order.received   received   —
2026-07-14 10:04:02+00  workflow:order-sync      order.dropped    dropped    erp_unreachable

Dos renglones. Eso es todo lo que soporte necesita para contestarle al cliente: el pedido entró a las 10:02 y a las 10:04 nuestro sistema no pudo registrarlo en el ERP porque el ERP no respondía; nunca se procesó. Comparado con los once renglones del run_log, esta versión es más corta, más aburrida y mucho más útil para hablar con una persona que no es del equipo técnico.

Y fíjate en lo que la brevedad permite: si mañana la pregunta es "¿cuántos pedidos perdimos por el ERP este trimestre?", la respuesta sale de una consulta sobre una tabla pequeña, sin filtrar ruido.

SELECT date_trunc('day', ts) AS day, count(*) AS dropped
FROM audit_log
WHERE action = 'order.dropped' AND reason = 'erp_unreachable'
  AND ts >= now() - interval '90 days'
GROUP BY day ORDER BY day;

Qué esperar de esa consulta. Una fila por día con pedidos perdidos. Si aparecen tres días con números altos y el resto en cero, tienes tres incidentes puntuales. Si todos los días tienen un goteo de dos o tres, tienes un problema crónico que nadie había visto porque cada caso individual parecía aislado. Esa diferencia —incidente contra goteo— es imposible de percibir sin la tabla, y cambia por completo qué hay que arreglar.

La auditoría de plataforma: qué te da n8n

Ahora la otra mitad: quién tocó el sistema. Aquí no construyes tú, sino que usas —y verificas— lo que la plataforma ofrece. Y hay que ser preciso con lo que cuesta y lo que no.

Log Streaming: potente, y es Enterprise

n8n tiene una función llamada Log Streaming que emite eventos de la instancia hacia un sistema externo. Según la documentación oficial, está disponible en todos los planes Enterprise. Conviene decirlo sin rodeos: si operas Community, esta función no la tienes.

Vale la pena entender qué hace, porque marca el estándar contra el que vas a comparar tu alternativa. Se configura en Settings > Log Streaming, agregando un destino, y admite tres tipos de destino: un servidor syslog, un webhook genérico y un cliente de Sentry.

Las categorías de eventos que puede emitir, según la documentación:

La tercera fila es la que nos ocupa: es exactamente la auditoría de plataforma, resuelta de fábrica. Y la documentación menciona un detalle de diseño que vale la pena notar, porque es lo que lo hace confiable: n8n persiste cada evento en un archivo local antes de reenviarlo al destino, de modo que el archivo sobrevive a un reinicio y los eventos que no se entregaron se pueden volver a emitir. Un sistema de auditoría que pierde eventos cuando el destino está caído no es un sistema de auditoría.

Si tu empresa tiene Enterprise, esta es la respuesta y no hay que inventar nada: configuras el destino, eliges las categorías, y tienes el rastro. Verifica en tu panel qué categorías concretas ofrece tu versión, porque la lista crece entre releases.

Qué haces si no tienes Enterprise

Aquí viene la parte honesta, porque es la situación de la mayoría de las instancias self-hosted.

Sin Log Streaming, n8n no te va a entregar un rastro de auditoría de plataforma listo para usar. No hay una variable de entorno que lo encienda ni un endpoint que lo exponga. Lo digo claro para que no pierdas la tarde buscándolo.

Lo que sí tienes son tres piezas parciales que, combinadas, cubren buena parte del terreno:

1. Historial de workflows (workflow history). n8n guarda versiones anteriores de cada workflow y permite verlas y restaurarlas. La cobertura depende del plan: según la documentación, todos los usuarios tienen las versiones de las últimas 24 horas; Cloud Pro llega a cinco días; y el historial completo es de Enterprise (Cloud y self-hosted). Las versiones con nombre —que además quedan protegidas de la poda automática de versiones— son de Pro/Enterprise Cloud y Enterprise self-hosted. Verifica el alcance en tu panel, porque es de las cosas que cambian.

Con 24 horas tienes muy poco margen: si alguien rompe un workflow el viernes y el problema aparece el lunes, la versión anterior ya no está.

2. Git como fuente de verdad de los cambios. Esta es la respuesta seria al problema, y es aditiva: si tus workflows están versionados en un repositorio, cada cambio tiene autor, fecha, mensaje y diferencia exacta —que es más de lo que da cualquier historial interno—. El cómo se monta eso es el módulo 8 de esta guía, así que no lo desarrollo aquí; lo que sí quiero que veas es que el control de versiones no es solo una comodidad de desarrollo: es tu auditoría de cambios de workflow. Si estás en Community y te preocupa saber quién cambió qué, esta es la pieza que más rinde por lo que cuesta.

3. Tu propia bitácora de operación. Para lo que ni Git ni el historial cubren —quién activó o desactivó un workflow, quién rotó una credencial, quién corrió algo a mano en producción— queda un registro escrito por el equipo. Suena artesanal y lo es. Pero un renglón en una tabla audit_log con actor_type: 'user' escrito a mano, o una convención de que todo cambio operativo se anota, es infinitamente mejor que nada. Y tiene una ventaja: te obliga a que alguien se haga responsable.

Una cuarta pieza que conviene mencionar aunque no la vayas a usar: existe una función Enterprise de redacción de datos de ejecución, que oculta los datos de entrada y salida de las ejecuciones dejando visible solo la metadata —nombres de nodo, estado, tiempos— con un indicador de que el dato fue redactado. Sirve cuando hay datos personales en las ejecuciones y no todo el equipo debe verlos. Es Enterprise y requiere versiones recientes de n8n; verifica los requisitos exactos en la documentación de tu versión si te interesa. La menciono porque la alternativa en Community es exactamente la disciplina de la lección 2: no metas datos personales en donde no quieres que se vean.

Cuánto tiempo se guarda cada cosa

Esta es la decisión que casi nadie toma a tiempo y que después es carísima de corregir. Guardar de más y guardar de menos son los dos errores, y tienen costos distintos.

Empecemos por lo que ya sabes: el historial de ejecuciones de n8n no es una decisión de retención, es un efecto secundario. Con EXECUTIONS_DATA_PRUNE en true por defecto, EXECUTIONS_DATA_MAX_AGE en 336 horas y EXECUTIONS_DATA_PRUNE_MAX_COUNT en 10000, Terra Market tiene dos días y medio de historial porque su volumen hace que mande el conteo. Nadie eligió ese número; salió de una división.

La retención de tus propias tablas sí la eliges tú, y conviene escribirla como una política explícita:

Fíjate en el patrón: cuanto más grueso el grano, más tiempo se guarda. Los eventos finos son muchos y envejecen rápido; los hechos y los agregados son pocos y envejecen bien. Es la misma lógica del archivo de una empresa: los borradores se tiran, los contratos se guardan.

Tres advertencias sobre esto.

Primera: la retención del audit_log no la decides tú solo. Cuánto tiempo hay que conservar registros de transacciones depende de la normativa de tu país y de tu industria, y no es una conversación de ingeniería. Ten esa conversación con quien lleve el tema legal antes de diseñar el esquema. Es de esas cosas que si preguntas después, la respuesta puede ser "necesitábamos siete años" cuando llevas seis meses borrando a los noventa días.

Segunda: borrar también hay que programarlo. Una política de retención que no se ejecuta no es una política, es una intención. Un workflow programado —semanal, con un Schedule Trigger— que borra de run_log lo anterior a noventa días es cinco minutos de trabajo y evita que la tabla crezca sin freno.

Tercera, y es la que más se descuida: los datos personales tienen su propia regla. El plazo de un dato personal no lo fija tu comodidad, lo fija el propósito para el que se recogió. Si en tu audit_log hay correos de clientes, ese campo puede necesitar un plazo distinto —y más corto— que el resto del renglón. La forma limpia de evitarse el problema entero es la de la lección 2: guardar el identificador y no la persona.

La salida de emergencia: anotar la ejecución

Cierro con una pieza pequeña y muy útil en el momento exacto en que la necesitas.

Cuando estás investigando un caso y la ejecución todavía existe, tienes un reloj en contra: en Terra Market, dos días y medio. La documentación confirma que las ejecuciones anotadas —con una etiqueta o una calificación— nunca se podan. Anotar la ejecución que estás investigando la congela.

Sirve muchísimo para lo que es: preservar una evidencia concreta mientras trabajas, o guardar el caso de referencia de un incidente para poder volver a él dentro de tres meses. También hay una operación de anotación disponible desde la API de n8n, por si quisieras marcar ejecuciones de forma programada.

Lo que no es: una estrategia de observabilidad. Exige que alguien sepa de antemano cuál ejecución va a importar, y el problema del pedido 4471 es justamente que nadie lo sabía. Trátala como el clip que le pones a un expediente antes de que se lo lleven al archivo: útil, manual, y no sustituye tener el expediente copiado en otro lado.

Errores comunes

Usar el run_log como auditoría (conceptual). Qué pasa: como la tabla de logs ya tiene todo, se decide que sirve también para responderle al cliente y a dirección. Y funciona hasta el día en que alguien pregunta algo serio y descubres tres problemas a la vez: la mitad de los renglones son ruido técnico que nadie de fuera entiende, la retención de noventa días no alcanza para el caso de hace ocho meses, y como la tabla se limpia y se ajusta a mano cuando estorba, nadie puede afirmar que no se tocó. Por qué pasa: los dos registros se parecen muchísimo y duplicar tablas se siente redundante. Cómo detectarlo: pregúntate si le pasarías tu run_log tal cual a alguien de dirección. Si la respuesta es "no, primero tendría que filtrarlo y explicarlo", no es una auditoría. Cómo corregirlo: mantén los dos, con criterios distintos de qué entra, de retención y de inmutabilidad. La auditoría es tan pequeña que el costo de tenerla aparte es mínimo.

Registrar "el sistema" como actor (práctico). Qué pasa: los renglones automáticos llevan actor: "system" y los manuales actor: "admin". Cuando llega el incidente y filtras por actor, no puedes distinguir cuál de los 18 workflows hizo qué, ni cuál de las seis personas con acceso administrativo intervino. Por qué pasa: en el momento de escribirlo parece suficiente, porque tú sabes de qué workflow se trata. Cómo detectarlo: mira los valores distintos de tu columna actor; si hay menos de cinco y uno de ellos concentra casi todo, están agregados de más. Cómo corregirlo: nombra siempre —workflow:order-sync, alicia@terramarket.com— y separa actor_type en su propia columna. Un actor genérico convierte la primera pregunta de cualquier investigación, "¿quién?", en un callejón sin salida.

Editar el rastro de auditoría para corregir un error (conceptual). Qué pasa: se detecta que un renglón quedó con el motivo equivocado y alguien lo corrige con un UPDATE. Parece un arreglo inocente y destruye la propiedad que hacía útil a la tabla: a partir de ahí, cualquiera puede preguntar qué más se editó, y no hay forma de contestar. Por qué pasa: corregir un dato malo es un reflejo sano en cualquier otra tabla. Cómo detectarlo: si tu tabla de auditoría tiene una columna updated_at, o si el rol de la aplicación tiene permiso de UPDATE y DELETE sobre ella, la puerta está abierta. Cómo corregirlo: haz la tabla append-only también a nivel de permisos —el rol que usa n8n solo debería poder insertar— y corrige agregando un renglón nuevo que documente la corrección y quién la hizo. Un histórico con un error visible y su corrección al lado es más creíble que uno impecable que alguien pudo haber maquillado.

Descubrir la retención cuando ya es tarde (práctico). Qué pasa: se despliega todo sin decidir plazos. Seis meses después hay dos sorpresas simultáneas: la tabla run_log pesa cien gigabytes y hace lentas las consultas, y el caso legal que alguien necesitaba de hace ocho meses no está porque un script de limpieza ad-hoc lo borró. Por qué pasa: la retención no bloquea el despliegue, así que se posterga, y es una de esas decisiones que solo se sienten el día que fallan. Cómo detectarlo: si no puedes decir en una frase cuánto tiempo vive cada uno de tus registros, no tienes política. Cómo corregirlo: escribe la tabla de retención —cuatro renglones, como la de esta lección—, confirma el plazo del audit_log con quien lleve el tema legal, y programa el borrado con un workflow. Cinco minutos ahora contra un problema que no tiene arreglo retroactivo.

Ejercicios

Ejercicio 1 — Reparte los hechos. Para cada uno de estos siete registros, di si va al run_log, al audit_log, a los dos, o a ninguno, y por qué:

(a) El nodo del ERP dio timeout en el intento 1 de 3. (b) El pedido 4471 se descartó definitivamente por erp_unreachable. (c) Se normalizaron los nombres de campo del pedido. (d) Carlos desactivó el workflow shipment-notify el viernes a las 16:22. (e) Se le envió al cliente el correo con el número de guía. (f) La consulta al ERP devolvió 37 pedidos listos para despachar. (g) Se rotó la credencial erp-api.

Ejercicio 2 — Completa el renglón incompleto. Este renglón de auditoría de Terra Market no sirve. Di qué le falta según las cinco preguntas y reescríbelo completo:

{
  "ts": "2026-07-14",
  "action": "cambio",
  "note": "se actualizó la configuración"
}

{
  "ts": "2026-07-14T16:22:09.771Z",
  "actor": "carlos@terramarket.com",
  "actor_type": "user",
  "action": "workflow.deactivated",
  "target_type": "workflow",
  "target_id": "shipment-notify",
  "before": { "active": true },
  "after":  { "active": false },
  "source": "n8n-ui",
  "note": "pruebas del nuevo transportista"
}

Ejercicio 3 — Diseña la política de retención. Terra Market te pide por escrito cuánto tiempo se guarda cada registro y quién lo borra. Escribe la política para: (1) las ejecuciones de n8n, (2) el run_log, (3) el audit_log, y (4) las métricas agregadas. Para cada una di el plazo, la justificación, y cómo se ejecuta el borrado. Marca explícitamente qué decisión no te corresponde a ti.

Resumen y siguiente paso

En esta lección separaste dos registros que se parecen y no son lo mismo: el log operativo —el cuaderno del mecánico, que escribes para depurar y puedes borrar en un mes— y el rastro de auditoría —la orden de servicio, que escribes para responderle a alguien, que es append-only y que se guarda años—. Aprendiste las cinco preguntas que todo renglón de auditoría debe responder: quién, qué, cuándo, sobre qué y con qué resultado. Distinguiste las dos auditorías que necesita Terra Market: la de negocio, que construyes tú con la tabla audit_log y siete acciones bien elegidas, y la de plataforma, que responde quién tocó el sistema. Sobre esa segunda viste con precisión qué da n8n: el Log Streaming es Enterprise —con destinos syslog, webhook o Sentry, categorías de eventos que incluyen los de auditoría, y persistencia local antes de reenviar—, y la alternativa cuando no lo tienes es la combinación de historial de workflows (24 horas para todos, completo en Enterprise), Git como auditoría de cambios (módulo 8) y una bitácora de operación escrita por el equipo. Y decidiste la retención, con el patrón de que a mayor grano, mayor plazo, y con la parte que no te toca decidir a ti: el plazo del audit_log se acuerda con quien lleve el tema legal.

Antes de avanzar deberías poder: explicar en una frase por qué un rastro de auditoría no se edita; escribir las cinco preguntas y un renglón que las responda; y decir qué hace n8n de fábrica para la auditoría de plataforma y bajo qué edición.

Con las lecciones 2 y 3 tienes memoria: puedes responder qué pasó con un caso y demostrarlo. Pero fíjate en el límite de esa memoria. Los dos registros son excelentes para un pedido y ciegos para el conjunto. Si el ERP empezó a fallar el doble desde el martes, ningún renglón te lo va a decir: cada uno describe su propio caso, y el patrón solo aparece cuando los sumas. La lección 4 da ese salto: las métricas de ejecución. Volumen, tasa de éxito y duración, calculadas sobre los mismos eventos que ya estás registrando. Y con una advertencia que vale la lección entera: el promedio miente. Una tarea que normalmente tarda dos segundos y de vez en cuando noventa tiene un promedio tranquilizador y un problema real, y lo único que lo revela es el percentil.

Recursos

• Stream logs to external systems — n8n Docs — la página oficial de Log Streaming: disponible en todos los planes Enterprise, sus tres tipos de destino y las categorías de eventos que emite, incluidos los de auditoría. Verifica en tu panel qué categorías trae tu versión.
• View change history — n8n Docs — el historial de versiones de un workflow y su alcance por plan (24 horas para todos, cinco días en Cloud Pro, completo en Enterprise). Confírmalo en tu instancia.
• Manage execution data — n8n Docs — la poda de ejecuciones y la confirmación de que las ejecuciones anotadas nunca se podan, que es la salida de emergencia de esta lección.
• Redact execution data — n8n Docs — la función Enterprise que oculta los datos de entrada y salida de las ejecuciones dejando visible la metadata. Verifica los requisitos de versión.
• n8n node — n8n Docs — el nodo que habla con la API de n8n, con operaciones sobre ejecuciones, workflows y credenciales. Útil para automatizar tareas de auditoría, incluida la anotación de ejecuciones.