Your AI workflow handles the happy path in a demo. The production decision gets harder when it can see customer records, misread an exception, grant access, send a message, move money, or change code. At that point, a better prompt is not a sufficient safety plan.

You need a control plane around the model: one that decides which data may enter, which actions may leave, what evidence must support a decision, and when the system must stop. The goal is not to make the model trustworthy. It is to make an untrustworthy component safe enough for a narrowly defined job.

Define the harm before choosing the guardrail

Start with one live workflow, not a company-wide principle such as use AI responsibly. A useful guardrail is tied to a specific failure and an enforceable response.

For that workflow, write a one-page guardrail contract with these fields:

1. Outcome: What job is the system completing? Be precise enough that success can be observed, such as classifying an access request or drafting a refund recommendation.
2. Authorized actor: Who may start the workflow, and on whose behalf does it act? A support representative, a customer, and a background service should not inherit the same permissions.
3. Permitted inputs: Name the allowed data classes, systems, document types, and jurisdictions. Do not rely on employees to make a new privacy decision for every file.
4. Permitted outputs: Separate reading, drafting, recommending, approving, and executing. These are different authority levels even when they appear in one user interface.
5. Source of truth: Identify the system that settles each factual question. A model can extract an account ID, but the account system must confirm that the ID exists and belongs to the right customer.
6. Failure consequences: List what can happen if the result is wrong, disclosed, delayed, duplicated, or applied to the wrong subject.
7. Stop conditions: Define the missing evidence, conflicting data, policy exception, low confidence, or system failure that forces escalation.
8. Recovery: State how an action is cancelled, reversed, or contained, who owns that response, and what happens if reversal is impossible.
9. Decision receipt: Define the evidence retained after each run: policy version, validation results, approver, action identifier, and outcome.

Assess data sensitivity and action risk separately. A read-only summary of a restricted document has high privacy risk but low action authority. An automated permission change may use little sensitive text but carry a large security impact. One blended risk score can hide both problems.

A practical starting classification is:

• Low sensitivity: Public or explicitly approved material that may use an approved hosted model.
• Confidential: Internal or customer material that requires an approved private route, least-privilege retrieval, retention controls, and output handling rules.
• Restricted: Material that stays in a controlled environment or outside the AI workflow entirely unless the accountable data owner has approved a specific architecture.

Give the same treatment to actions:

• Suggest: Produce a draft or recommendation without changing another system.
• Prepare: Build an exact proposed transaction, message, diff, or permission change for review.
• Execute within bounds: Perform a reversible action only when deterministic policy checks pass.
• Escalate: Stop when the action is irreversible, unusually consequential, ambiguous, or outside the declared scope.

Key takeaways

• Put hard limits in code, permissions, and policy services rather than relying on the model to remember them.
• Route and minimize sensitive data before it reaches the model.
• Tie autonomy to consequence, reversibility, and verifiability, not to a general confidence score.
• Validate structure, factual meaning, policy compliance, and authorization as separate gates.
• Retain decision receipts without turning observability logs into a second store of sensitive data.

Build guardrails as gates around the model

The safest production design treats the model as one stage in a pipeline. It does not let the model classify the risk, create the action, approve the action, and declare the result successful in the same step.

1. Classify the request. Determine the user, purpose, data class, jurisdiction, requested tools, and action risk before assembling the prompt. Use authoritative metadata and policy rules where they exist. If classification is missing or contradictory, stop.
2. Minimize the input. Retrieve only the fields and passages needed for the declared task. Replace identifiers where the task does not require identity, and keep the re-identification mapping outside the model context. A sanitized document is not a universal permission slip because what must be removed depends on the question being asked.
3. Isolate untrusted content. Treat emails, uploaded documents, web pages, tickets, and retrieved notes as data, even when they contain text that looks like an instruction. Do not allow content inside a customer file to expand the tool list, alter the policy, or request secrets.
4. Constrain generation. Ask for a narrow intermediate result rather than an open-ended answer. Define allowed values, required evidence, and explicit abstention states. Do not expose tools or credentials that the current step does not need.
5. Validate structure. Use a machine-enforced contract for outputs that feed software. A JSON Schema can turn the expected output shape into an explicit contract: required fields, types, enumerated decisions, numeric bounds, and rejected extra properties. A malformed or incomplete result should fail closed instead of being repaired silently downstream.
6. Validate meaning. Schema validation proves that a field has the right form, not that it is true. Check account identifiers, policy versions, currencies, totals, dates, permissions, cited passages, and current state against authoritative systems. For document-grounded decisions, require the model to return the evidence location so another component or person can inspect it.
7. Authorize outside the model. Send the proposed action to a deterministic policy layer. That layer checks the actor, subject, limits, approvals, separation of duties, and current system state. The model may propose an exception; it must not grant itself one.
8. Execute defensively. Use previews, exact diffs, idempotency keys, transaction boundaries, bounded retries, and reversible operations where the underlying system supports them. A retry must not create a second refund, duplicate message, or repeated permission change.
9. Inspect the output. Apply disclosure, policy, and content checks before a response reaches a person or another system. If the system transforms sensitive input into a summary, treat the summary according to what it reveals, not merely according to its shorter length.
10. Record the result. Store the policy decision, validation outcomes, model and harness versions, approval, action receipt, and final status. Avoid copying full prompts and retrieved records into general-purpose logs unless their access, retention, and deletion controls match the original data.

These gates should return explicit states such as allow, deny, request approval, request more evidence, or escalate. Free-form warnings are difficult to test and easy for downstream code to ignore.

The failure behavior matters as much as the success behavior. Decide what happens when the policy service is unavailable, the validator times out, the model returns an unknown action, or the source-of-truth system changes between proposal and execution. For a consequential action, timeout should normally mean no action, not implied approval.

Set autonomy by consequence and verifiability

Human-in-the-loop is not a complete control. You still need to decide which human, what they see, exactly what they approve, and what the system does when they do nothing.

Workflow condition	Default authority	Required controls
Low consequence, reversible, and objectively verifiable	Bounded execution can be appropriate	Deterministic pre-checks, narrow permissions, idempotency, post-check, and rollback
Low consequence but dependent on judgment	Draft or recommend	Evidence display, sampling, feedback capture, and an escalation path
High consequence but objectively verifiable	Prepare the action; require authorization	Named approver, exact transaction preview, policy checks, separation of duties, and a durable receipt
High consequence, difficult to verify, or irreversible	No autonomous execution	Human decision, specialist review where required, and a safe manual path

Do not let a single model confidence score override this matrix. A fluent answer can be confidently wrong, and confidence does not measure financial, legal, privacy, security, or customer impact. Use confidence as one signal for routing only after consequence-based limits are already in place.

A good approval packet contains:

• The exact action, recipient, resource, amount, permission, message, or code diff being approved.
• The relevant before-and-after state.
• The policy rule and version that apply.
• The evidence used, with links or locations in the authoritative system.
• Any missing, conflicting, or model-inferred information.
• The expected side effects and whether the action can be reversed.
• A clear approve, reject, or return-for-more-evidence choice.

Approval should bind to that exact payload. If the account, amount, recipient, code diff, or underlying data changes, invalidate the approval and run the checks again. Do not ask a reviewer to approve an intent and then allow the agent to construct a different transaction afterward.

Match the reviewer to the decision. A customer can verify that a repaired interface meets the need, but customer confirmation is not production-deployment authority. That distinction became visible when an agent found a charting bug, wrote a test, shipped a fix, and still produced a customer-facing design error. Technical checks, product-intent validation, and release authorization answer different questions.

Design the review experience for disagreement, not ceremonial approval. Show the diff and evidence first. Hide irrelevant model prose. Make rejection easy, capture a reason, and route the case to a named owner. If reviewers routinely approve without inspection, either the action should be safely automated with stronger machine checks or the approval step needs redesign.

Make the approved data route usable under deadline

A policy that says do not upload sensitive files identifies a risk but does not complete the work. If leaders demand AI productivity while the approved route is unclear or impractical, employees end up inventing a privacy process file by file. That is a predictable form of shadow AI, not merely an awareness failure. The practical test is to put the approved path on a clock against the consumer-tool path and remove unnecessary friction from the responsible route.

Build a router that makes the decision before content reaches a model:

• Hosted approved route: Public or approved low-sensitivity material goes to a managed model endpoint with authenticated access and declared retention behavior.
• Private enterprise route: Confidential material goes only to an environment whose identity, tenant isolation, logging, retention, training-use terms, regional handling, subprocessors, and deletion behavior have been reviewed for that data class.
• Local or isolated route: Restricted material may be processed where the data already resides, with external egress disabled and locally controlled storage, if security, privacy, legal, and data owners approve the full workflow.
• No-model route: Prohibited data, unsupported jurisdictions, missing consent, unavailable controls, or an unapproved purpose stays outside the AI system. The workflow must offer a manual alternative rather than pressuring the employee to bypass policy.

Routing is purpose-specific. A contract may be approved for clause extraction in an isolated environment but not for training, open-ended conversation, or reuse in another department. Store the purpose and data classification with the job so later steps cannot quietly broaden them.

Redaction is useful when the removed fields are unnecessary, but it is not the same as permission. Names, addresses, prices, rare attributes, free-text narratives, and combinations of otherwise ordinary fields can each reveal identity or business-sensitive facts. Review the transformed input against the exact task, protect any token-to-identity mapping, and apply controls to the output as well.

Bringing a model to the data can remove one exposure path. A downloaded model can process an authorized file on the same machine without sending the text to a model provider, and an offline test can reveal which tasks fit that setup. But a local laptop does not become compliant merely because the network is disconnected. Device access, disk encryption, malware protection, model provenance, local logs, backups, output handling, deletion, physical security, and user authorization still matter.

Do not hide this routing logic inside a prompt. Put it in the product experience. Show the detected data class, selected environment, blocked fields, retention treatment, and available alternative before the user submits the job. Give employees a fast escalation path when the classification is wrong or the approved route cannot perform the task.

Test the whole control system, then operate it

Model accuracy is only one release dimension. A production evaluation must test whether the workflow refuses the wrong data, denies unauthorized tools, preserves approvals, survives retries, records evidence, and stops safely when dependencies fail.

Create a versioned test suite with at least these families:

• Expected work: Representative cases with expert-approved outputs, evidence, actions, and escalation decisions.
• Policy boundaries: Requests just inside and just outside each permission, amount, role, jurisdiction, data class, and action limit.
• Missing and conflicting evidence: Absent identifiers, stale policy records, contradictory documents, ambiguous subjects, and unavailable source systems.
• Sensitive-data leakage: Synthetic secrets and identifiers placed in input, retrieved context, tool responses, output, error messages, and logs to confirm where they appear.
• Instruction attacks: Untrusted documents or messages that ask the model to ignore policy, reveal data, call an unapproved tool, or conceal an action.
• Tool failure: Timeouts, partial writes, stale reads, permission denial, malformed responses, duplicate retries, and state changes between approval and execution.
• Recovery: Rollback, cancellation, quarantine, notification, and manual completion after a failed or partially completed run.
• Version regression: The same suite rerun for every material change to the model, prompt, retrieval logic, policy, schema, tool, permission, or workflow code.

Set release thresholds before running the evaluation. Separate task-quality metrics from non-negotiable policy gates. A team may tolerate some drafts being sent for revision; it should not average an unauthorized disclosure or action into an overall quality score.

Keep prompts compact enough to inspect. Adding another instruction after every failure feels safe, but it creates hidden interactions and makes enforcement difficult to audit. In one limited local test, roughly 5,000 extra words of instructions improved analysis while delivery failed in two of three runs. That is not a universal failure rate. It is a useful warning that accumulated instructions are not equivalent to controls. Move stable constraints into schemas, policy code, permissions, validators, and tests.

Separate production from verification. The same generation step should not be the only judge of its own work. Use deterministic checks wherever possible, human review for consequential judgment, and an independently scoped quality step for evidence and outcome checks. A workflow can remain useful despite unreliable individual outputs when it can catch fabricated work, force a redo, verify the correction, and retain the record.

For each run, capture a privacy-conscious decision receipt containing:

• Request and trace identifiers.
• Authenticated actor and delegated authority.
• Declared purpose and data classification.
• Model, prompt, retrieval, schema, tool, and policy versions.
• Retrieved record identifiers or evidence locations without duplicating sensitive content unnecessarily.
• Validation results and policy decision.
• Approval identity, scope, and timestamp when required.
• Execution identifier, resulting state, and rollback status.
• Escalation, override, incident, and user-feedback outcomes.

A workable operating cadence is to inspect critical failures and unauthorized attempts as they occur, review clustered failure causes weekly during a pilot, and audit permissions, retained data, override patterns, stale policies, evaluation coverage, and harness changes on a scheduled basis. Adjust the cadence to the workflow’s volume and consequence, but assign each review to a named owner.

Give operators a kill switch that disables actions without destroying the evidence needed for investigation. Test that switch before launch. Also maintain a safe degraded mode: read-only access, draft-only output, a manual queue, or a complete stop, depending on the harm the workflow can cause.

Choose one sensitive workflow this week and complete the guardrail contract before adding another model capability. If you cannot name the blocked actions, authoritative checks, exact approval unit, timeout behavior, recovery path, and decision receipt, the workflow is not ready for more autonomy. That gap is the next product requirement.

References

• JSON Schema — How JSON Schema makes LLM output reliable
• Nate Jones’s Substack — Executive Briefing: Gumroad Let a Customer Approve Its Code. Here’s Where Your Agent Should Stop
• Nate Jones’s Substack — Your company blocked ChatGPT for sensitive files. Grab the guide to strip the name, the address, and the price, and the block stops mattering.
• Nate Jones’s Substack — Executive Briefing: How Microsoft, Bayer, and Discovery Use AI on the Data You Can’t Upload
• Nate Jones’s Substack — I gave Fable 5 five thousand extra words of instructions. It thought better and failed delivery two runs out of three.
• Nate Jones’s Substack — Stop waiting for AI you can trust. Borrow the 500-year-old trick that made untrustworthy agents useful anyway.

---