Start with operational questions
A log records individual events. A trace joins the steps of one run, such as retrieving a document, calling a model and preparing a CRM update. Neither needs to become a permanent copy of everything the model saw. For a UK business handling enquiries, the useful starting point is a small set of questions: did the work arrive, where did it stop, and does a person need to intervene?
Define the difference between a technical success and a business outcome. A model returning text does not prove that the reply was approved, delivered or accepted by the receiving system. Give those stages separate names so an operator can distinguish a prepared draft from a completed action.
Agree a small event record
For each workflow, agree a list of permitted fields. The following is a suggested starting point to adapt with the team operating the process. Keep free-text descriptions out of these fields wherever a defined category will do.
Use an opaque run reference to connect the records. Keep any mapping back to a customer in the business application, behind its normal permissions. A reference still needs protection when it can be linked to a person; changing the label does not make the underlying information harmless.
- Run reference, workflow name, release version and event time.
- Stage and outcome: received, validation failed, awaiting review, action confirmed or recovery required.
- Model identifier and prompt-template version, rather than the populated prompt.
- Duration, retry count and reported token usage, with missing measurements marked as unknown.
- Controlled failure category and the destination system's operation reference, where appropriate.
Illustrative example: a delayed customer reply
Imagine a service business using AI to prepare replies to maintenance enquiries. Staff approve each draft before it is sent. This is an illustrative design, not a Fewzen customer story or a measured result.
A customer asks why no reply arrived. The operator finds the run reference in the enquiry record. Its events show that drafting finished, approval was recorded and the email service rejected the send request because access had expired. The enquiry text, customer's address and draft body are unnecessary for diagnosing that failure.
The operator can restore the connection and use the workflow's recovery process after checking whether delivery occurred. For a complaint about the wording instead, an authorised reviewer opens the original enquiry and approved draft in the business system. The routine monitoring dashboard does not need to expose both to everyone with technical support access.
Remove content before it reaches the monitoring service
OWASP's logging guidance identifies credentials, payment details and sensitive personal information as data that should generally be excluded or protected. Apply that caution to model inputs, outputs, retrieved passages and tool arguments. An exception message can also contain part of a request. Check error handling as well as the successful path.
LangSmith documents controls to hide inputs and outputs before sending traces to its backend, including LANGSMITH_HIDE_INPUTS and LANGSMITH_HIDE_OUTPUTS for its Python and TypeScript SDKs. These are product-specific controls, checked on 4 November 2026. They do not establish what a separate application logger, gateway or another tracing client captures.
Inspect the records actually exported by your configuration. Also check trace names, tags, URLs and attachments: hiding the main message is insufficient if a customer's email address remains in a label. Prefer synthetic examples for routine development so a debugging session does not start with live customer correspondence.
Treat redaction as a control with limits
OpenTelemetry recommends collecting only information needed for observability and reviewing what instrumentation emits. Its Collector can remove or transform attributes, including using an allowlist through the redaction processor. That can add protection, but it is not a reason to capture unrestricted content in the application first.
Decide where filtering happens along the whole route. A downstream filter cannot undo a copy already written to a local file or sent to another service. Pattern matching may miss an unfamiliar identifier or confidential prose. OpenTelemetry also warns that hashing predictable identifiers may offer inadequate anonymity.
If content is essential to investigate a particular incident, define the scope, authorised reviewers, destination and expiry before enabling capture. Keep it separate from general dashboards. Reproduce the issue with sanitised inputs where possible; if sanitising removes the behaviour, document that limitation rather than claiming the issue is resolved.
Keep monitoring useful when detail is reduced
Less content means some investigations will need a second step. Accept that trade-off explicitly and give support staff a route to the right reviewer. Do not compensate by granting everyone access to the original records.
Choose alerts that correspond to work someone can act on: enquiries stuck awaiting review, repeated authentication failures or actions with no confirmed outcome. Assign an owner and recovery instruction. Track accepted results alongside latency and usage so a fast stream of unusable drafts does not look like a healthy service.
Agree how long each category of record is useful and who can export it. Include copied incident attachments in that discussion. Operational history and temporary diagnostic material may need different handling; a single indefinite retention setting is a poor substitute for a decision.
Review one workflow before expanding capture
Take one existing workflow and run a controlled enquiry containing invented, recognisable markers in its message, attachment name and tool result. Trigger both success and failure, then look for those markers in every monitoring destination. Verify that the permitted event fields still explain what happened.
Repeat the check after changing instrumentation or adding a connector. Keep a short record of what is captured, what is excluded and who owns the configuration. The useful next step is an agreed logging boundary for one process, followed by evidence that it works.