Stork Delivery
What needs to be logged when AI takes an action
An AI action log should explain what was requested, authorized, attempted, and confirmed without collecting unnecessary sensitive information.
The problem: a conversation transcript cannot explain an executed business action
An AI-enabled workflow changes a customer record. Later, someone asks why the change happened and whether it was approved.
A transcript containing a confident explanation is not enough to answer those questions. The application needs a record of the observable events that led to the change.
Design that record around the business action.
A practical approach
Identify the request and the actor
Record which authenticated user or authorized process initiated the work, the relevant business record, and an identifier that connects the steps of the operation.
Keep the user's request or an appropriate representation of it according to the application's data-handling requirements. Avoid copying sensitive content into broad operational logs simply because it is convenient.
The record should make it possible to distinguish separate attempts and recognize retries of the same intended action.
Separate proposal, approval, and execution
Capture the proposed change, the authorization decision, any required human approval, the tool operation attempted, and the confirmed outcome.
These are different events. A model proposing a refund does not mean a person approved it. An approval does not mean the payment provider accepted it. A timeout may leave the result uncertain rather than failed.
Keep the downstream reference when one is returned so the business can reconcile the action later.
Preserve enough context to investigate
Record the relevant application or workflow version and the model identifier used, where appropriate. Keep references to the source records that supported the action, subject to their access and retention rules.
Do not rely on a model's private reasoning as the evidence. Focus on inputs, permissions, explicit approvals, tool calls, and results that the surrounding software can observe.
An investigation should be able to distinguish a bad source record, an incorrect proposal, a missing approval, and a failed integration.
Protect the record itself
Restrict who can read and alter action history. Define retention with the people responsible for the information and the business process. Consider whether selected records need stronger tamper resistance for their intended use.
Test that failures are recorded too. A logging process that only captures the successful path leaves the most important questions unanswered.
Useful AI governance gives the business a way to understand and control what the application does. A well-designed action history supports that responsibility without pretending that storing every prompt and response automatically creates a complete audit trail.
The result: an action history that supports an investigation
Choose one safe test action and follow its request identifier through proposal, permission check, approval, execution, and confirmed result. Repeat with a denied request and an uncertain downstream response. An authorized reviewer should be able to reconstruct what happened without access to model-private reasoning or unnecessary sensitive data. Fix missing links before allowing the workflow to make consequential changes.