What is Write-Back Governance
Write-back governance is the rule that an AI may not change a live business system until a named person has seen the exact change and signed it — and if they have not, nothing happens.
Write-back means the AI is allowed to change a live business system — a CRM field, an ERP journal, a customer message — not just draft a suggestion.
Write-back governance is the control that decides whether that is allowed, exactly what will change, who must sign, and how you can prove it later. Its defining property is fail-closed: if approval is missing, the write does not occur.
A prompt that says “please ask first” is etiquette. It is not a control.
In June 2023, a New York federal judge sanctioned two lawyers who filed a brief citing cases ChatGPT had invented — the Mata v. Avianca episode. Fiction had been written into a court record. The same failure mode is waiting in CRM and ERP: fluent output that becomes an operational fact.
Air Canada’s chatbot invented a bereavement fare and the company was held to the commitment — CBC, decision Moffatt v. Air Canada. A customer-facing message is a write to the relationship even when no CRM API fired.
Words you’ll hear
- Live system / system of record. Salesforce, NetSuite, Workday — the official place the number or record lives. At work, this is where other teams will inherit the new value.
- Payload / quote. The exact change, shown before it runs: fields, values, line items — not “update CRM.” At work, Amount and a next-step note are not the same quote.
- Named signer. The identity that authorised the payload. Shared inboxes and “whoever is online” destroy this.
- Maker-checker. An older control: one person proposes, another authorises. Write-back governance is that instinct for AI, when the proposer is a model.
- Connector. A secure link from the AI product to a live system. Read-only is a control. A production write login is a different risk class.
- Fail-closed. Missing approval means nothing happens. Fail-open means the change goes through unless someone happens to stop it.
- Least privilege. The connected identity should not be able to edit every object “because setup was easier.” Application-level quotes do not shrink a superuser token.
- Rollback. Sometimes possible for a field; often impossible for a sent message. Rollback is not a substitute for a gate.
The NIST Cybersecurity Framework is useful vocabulary here — identify, protect, detect, respond, recover — but it does not, by itself, quote a Salesforce payload. AI governance is the broader programme. Write-back governance is the write subset.
Why you should care
Most enterprise software already has write controls: CRM validation, ERP posting periods, maker-checker in banking. Generative AI added a new writer that does not respect those cultures unless the runtime is bound to them.
It affects you if AI can:
- change revenue, pipeline, or customer records
- post journals
- send a customer a message that asserts a term or a price
- bulk-update hundreds of rows
Industry maturity, in plain steps:
- Copy-paste. A human types model output into the live system. Unlogged as AI. See shadow AI.
- Tools plus manners. The model has an “update opportunity” button. Instructions say to confirm. Haste and bugs bypass.
- Admin toggles. “Allow writes” per user. No preview of the exact change.
- Quoted, named, fail-closed. The product shows the change, binds the signer’s identity, records the outcome.
Only (4) is write-back governance in the sense auditors mean.
Salesforce validation will stop some nonsense. It will not record that an AI proposed the change, which playbook was cited, or that finance rejected an earlier payload.
How to turn it on without starting in production
Start read-only. Prove retrieval and drafts. Count how often humans would have written — and how often the draft contains something you would not file.
Enable writes per job and per object type. A next-step note is not Amount. A journal is not Slack.
Always show the payload. Rejects are success: a stored rejection proves the gate. Never hide bulk in a single “approve 200 records” with no visible set.
Rollback is not a substitute. Some writes are messages you cannot unsend.
Do not give the agent a full production key “because the proof of value was read-only” and promise to add gates later. Later is when the first bad write ships.
What changes by role
Finance. Journals and material fields need the owner of the analogue posting, a field-level quote, and a chain that shows the wiki version cited. A champion who does not own the ledger will rubber-stamp. Spend caps stop looping proposers; they do not replace the signer. See What is AI token economics.
Legal. Customer messages, terms, and anything that could become a commitment. Air Canada is the caution. Legal should also treat copy-paste from a consumer model as a write that bypassed the programme. Mata v. Avianca is fluent fiction entering a record — the CRM analogue is a next-step that never happened, or a clause the company does not offer.
Operations. Object-class rollout, visible bulk, human wait as a workflow step. Ops should measure time-to-approved-write and reject rate, and should refuse tenant-wide write toggles.
Go-to-market. Friction versus incident. GTM should get fast quotes on low-radius fields first, not a weekend cleanup agent. Slack is not “safe chat”; it is still a write to a system people treat as official.
Security. Jailbreaks should not execute. Combine least-privilege identity and application-level quotes. The OWASP Top 10 for LLM applications is about requesting bad actions; the gate is about refusing to run them. MCP will happily pass a write; it will not implement fail-closed.
What people get wrong
Salesforce permissions as sufficient. Necessary. If the connected user can edit all objects, the agent inherits that blast radius even with quotes.
Prompt manners. “Please ask first” is not fail-closed.
Admin allow-writes. No payload, no named signer, no record of rejects.
Bulk one-click. A rubber stamp with radius.
Rollback as the control. You cannot unsend.
Fully autonomous production writes. Only for low-radius, reversible actions you would otherwise schedule, with logging.
Theatre HITL. A checkbox is not a quote. See What is human-in-the-loop AI.
Good looks like: connectors default to read-only; writes opt-in per job and object; field-level quotes; named identity; model cannot waive; rejects stored on the lifecycle graph; least-privilege tokens. Failure looks like a production key issued after a read-only demo.
This is a core job of an enterprise AI operating system: I/O control, not chat with an API on the side.
How this shows up in Nimbus
Connectors default to read-only. Write-back is opt-in. The UI quotes the intended change at the field or line level. Humans sign with their identity. The model cannot waive the gate. Missing approval is fail-closed: nothing happens.
The Lifecycle Graph stores the quote, the decision, the execution, and errors. Agent teams can draft. They cannot release.
See Governance and Integrations.
Questions people actually ask
Isn’t this just permissions on the Salesforce user?
Permissions are necessary. If the connected user can edit all objects, the agent inherits that blast radius even with quotes. Combine least-privilege identity and application-level quotes.
Can we write back to Slack but not CRM?
Yes. Different systems, different bars. Do not treat “chat” as inherently safe.
Does this slow revenue teams?
It slows unreviewed mutation and speeds reviewed mutation relative to email-and-hope. Measure time-to-approved-write, not time-to-first-answer.
Can a jailbreak bypass the gate?
It can trick the model into requesting a bad write. It should not be able to execute without a quote and a signer.
What about fully autonomous writes?
Only for low-radius, reversible actions you would otherwise schedule, with logging. If you would not let a scheduled job do it, do not let an agent do it unattended.
How is copy-paste different from a connector write?
The live system still changes. Copy-paste is usually unlogged as AI and often happens on shadow tools. It is write-back without governance.
Why start read-only?
Because you need a baseline of draft quality and a count of how often a human would have written. Turning on writes on day one teaches the organisation to skip the quote.
Is a next-step note the same as Amount?
No. Enable writes per object type. Low-radius, reversible fields can come first. Money and contractual language should not piggy-back on a note permission.
Do rejects matter?
Yes. A stored rejection proves the gate and teaches the playbook. A six-month zero reject rate is a finding.
Can MCP or a plugin be the write path?
They can be wiring. They are not the gate. See What is Model Context Protocol.
How does this relate to the EU AI Act?
Effective oversight, for higher-risk systems, includes the ability to interrupt. A fail-closed named signer is that instinct for operational writes. It is not, by itself, “Act compliant.” See EU AI Act.
What should auditors see?
The payload the signer saw, the identity, the timestamp, the playbook version cited, and whether the live system accepted or rejected the change — on a chain, not in a screenshot.
Related reading
What is shadow AI and What is an enterprise AI operating system.
Sources
Related guides
See what governed AI looks like on your stack.
Connect your tools, run a workstream, and keep every decision on your ledger - free for 7 days.