Client-chasing AI data safety and controls

The control register at a glance

Treat this as the working register, not a badge. The final scope, evidence, owners, and limits are agreed in writing for the specific workflow.

Inspect the full control register Six control decisions, their operating checks, and the evidence a reviewer can request.

Control decisions and the evidence a reviewer can request
Control	Before launch	During operation	Evidence to request
Access scope	Name the accounts, folders, trackers, actions, and exclusions.	Review access when the workflow or connected systems change.	Permission schedule and named owners.
Approval	Set which actions require a person and who can approve them.	Keep every client-facing message in human approval mode throughout the live launch pilot.	Approval matrix, pilot review, and any later workflow-specific change decision.
Write actions	Set a separate approval, reconciliation, and failure rule for each filing or tracker write.	Check attempted and completed writes; route failures, duplicates, and unexpected outcomes to a person.	Write matrix, reconciliation method, failure cases, and available action records.
Action record	Define the events and fields intended to be recorded.	Review available records for exceptions, approvals, and outcomes.	Log specification, access rules, and retention period.
Human escalation	Describe hold conditions and name the receiving person or team.	Route sensitive, unclear, unusual, or out-of-scope work for review.	Escalation rules and contact roster.
Stop and recovery	Document the available pause, access-revocation, and recovery controls.	Contain where possible, investigate, retest, and return to approval mode.	Runbook, test results, and incident notes.

Control 01 · Scope

Permissions and access are a written schedule

The signed schedule says what the workflow may use, what it may do there, who administers access, and what remains outside scope.

In scope: Named mailboxes, folders, trackers, exports, document types, and actions agreed for the job.
Permission level: Read or write access is selected per task. The design prefers separate accounts and read-only access where the connected system and job allow; the chosen method is documented and tested before access.
Outside scope: Professional judgement, tax, accounting, legal or regulated advice, unagreed systems, and ambiguous or sensitive cases.
Named ownership: Your team identifies access administrators, approvers, escalation contacts, and people allowed to review operational records.

The proposed standard data path

A scoped Quiet Quarter workflow is designed around this shape. The engagement's data-processing documents must name the suppliers, processing locations, temporary storage and retention behind each applicable step for the tools selected for that workflow.

Selected content goes to the contracted providers named in the data-processing schedule to draft and classify. Processing locations, temporary storage and retention depend on the tools selected for that workflow; the relevant supplier terms and configuration assumptions are recorded before processing starts.

Inspect the data path and supplier checks Read, prepare, hold, approve, act and record — plus the provider terms to request.

ReadNamed mailboxes, folders and trackers in your systems, under the signed permission schedule.
PrepareSelected content goes to the contracted providers named in the data-processing schedule to draft and classify.
HoldEvery client-facing draft waits in the approval queue throughout the launch pilot.
ApproveA named person at the practice reviews, edits and approves.
ActApproved messages send from the practice's own mailbox; agreed tracker and filing writes follow their own write rules.
RecordThe agreed action-record specification identifies which proposed and completed events are captured, its known coverage gaps, and how exceptions route to a person.

Data location and processing

A workflow reads or writes only in the business systems named in the permission schedule, and may send selected content to contracted service providers to perform a task. Processing locations, temporary storage and retention depend on the tools selected for that workflow.

Because those tools differ per engagement, the named suppliers and the exact data path for your workflow are confirmed in the technical design and data-processing documents before access — including any operational records held outside your systems.

Supplier use of inputs and outputs

Ask for the current supplier terms that describe whether and how inputs and outputs may be retained or used, including any model-improvement settings or contractual restrictions.

The approved suppliers, relevant terms, and any configuration assumptions are recorded in the engagement pack before processing starts and reviewed when a supplier or service changes.

Control 02 · Approve

Every client-facing launch starts with human approval

There is no autonomous client-facing sending at launch. Every message remains held for a person throughout the live approval-mode pilot. Filing, tracker updates, and other writes each receive their own approval, reconciliation, and failure rule.

Inspect the four pre-launch decisions Map, test, pilot and record the permitted actions and owners.

Map List systems, data, actions, exclusions, and owners.
Test Use agreed samples and scenarios, including exceptions.
Pilot Run with human review and compare intended with actual outcomes.
Decide Record the permitted actions, approval rules, and launch owner.

A later wider permission cannot be the launch rule. Only after the live approval-mode pilot is reviewed may the practice consider a workflow-specific, tested, written change. That later decision should name the action, evidence, accountable owner, reconciliation method, and return-to-approval condition.

Control 03 · Record

Specify the available action record before relying on it

The action-record specification in the engagement pack identifies which events are captured, the fields available, who can see them, how long they are kept, and known gaps. It is never described as a complete history unless the scoped system can evidence that claim.

Inspect an illustrative action record Sample fields and events only — not live client data or proof of complete coverage.

Illustrative action record — sample fields and events, not live client data
Time	Proposed or completed action	Source / target	Approval or rule	Outcome
09:02	Draft reminder created	Agreed tracker → approval queue	Human approval required	Held for review
09:14	Draft edited and approved	Approval queue → named mailbox	Named approver	Send requested
11:37	Ambiguous reply detected	Named mailbox → exception queue	Escalation rule	No reply proposed

Records depend on the connected systems and integrations operating as designed. They are tested before launch, and known gaps are documented in the specification rather than assumed away.

Control 04 · Escalate

Exceptions have a named human destination

Escalation is a workflow state with an owner and a resume condition—not a vague promise that someone will notice.

Unclear requests, sensitive or unusual replies, professional judgement, and system or permission failures are held and routed to the named owner. The workflow does not generate or send professional advice.

Inspect the example escalation matrix Triggers, workflow responses, named human owners and resume conditions.

Example escalation matrix to tailor during workflow design
Trigger	Workflow response	Human owner	Resume condition
Unclear request or conflicting records	Hold the next client-facing action and route the context.	Named workflow owner	Owner records the chosen next step.
Sensitive, angry, or unusual reply	Stop the routine sequence and flag for review.	Named client-service contact	A person decides whether and how to respond.
Professional judgement requested	Do not generate or send professional advice.	Appropriately qualified member of your team	The matter is handled outside the admin workflow.
System or permission failure	Hold dependent actions and surface the failure.	Named technical contact	Access is checked and the affected path is retested.

Qualified boundary · engagement evidence required

No general security, encryption, training-use or retention assurance is approved. Actual suppliers, locations, access, retention, action-record coverage, incident contacts and terms are confirmed for the scoped workflow before access.

Control 05 · Contain

Pause, review, then return to approval mode

The available stop controls depend on the connected system. The runbook says who can use them and what they do—and do not—contain.

Before any restart, the affected path is retested and the workflow returns in approval mode. Any later widening requires a fresh decision.

Inspect the six-step containment method Trigger, contain, review, correct, retest and re-enter.

TriggerA person or agreed rule identifies a reason to stop.
ContainPause available jobs, revoke relevant access, or disable the integration where supported.
ReviewIdentify affected items using the evidence that is available.
CorrectChange permissions, instructions, data, or process as appropriate.
RetestRun agreed scenarios before reconnecting the workflow.
Re-enterResume in approval mode; any later widening requires a fresh decision.

Control 06 · Recover

Incident response includes the limits

Contain where possible, preserve available evidence, identify affected items, agree corrective action, make any required notifications, and retest before resuming.

Some actions are not reversible

A sent message cannot reliably be unsent. File recovery, version history, and transaction reversal depend on the connected system and its configuration.

Evidence can have gaps

Logs may be incomplete if an integration, supplier, or network fails. Incident review should state what is known, unknown, and inferred.

Approval is not professional validation

A human click does not by itself establish accounting, tax, legal, or factual accuracy. The approver needs the right context and authority.

Recovery is system-specific

Rollback depends on backups, versioning, permissions, supplier availability, and the side effects already produced in other systems.

Data responsibilities are agreed in writing

Before processing starts, the service agreement and data-processing documents identify the parties' roles, instructions, data categories, approved suppliers, retention and deletion arrangements, transfer details where relevant, and incident contacts.

The final arrangement depends on the workflow, suppliers, and your own responsibilities under UK data-protection law. Your organisation and its advisers review the documents and decide whether the arrangement meets its obligations.

Incident and continuity contact. Report a suspected incident, or reach us during one, at hey@machlilies.com. The engagement pack names the accountable incident owner, the escalation roster and the response expectations for your workflow, and that route works even while the workflow is paused.

Exit and deletion. The signed exit plan must state how access will be revoked, how the workflow will be shut down, and how data held on our side will be returned or deleted with written confirmation. It also states timing, any legal or technical exceptions, and what evidence can be provided. This page is an operational summary, not proof that an exit has already run, legal advice or a compliance determination.

The proposed engagement document pack

Mach Lilies commits to provide and agree this document set before access for a Quiet Quarter engagement. Forward the list to your IT, data-protection, security, or legal adviser and require the actual documents and test results; this page is not a substitute for them.

Open the adviser checklist Eight documents and the specific decisions each should evidence before launch.

Pre-launch evidence checklist
Ask to see	What it should make clear
Permission schedule	Systems, accounts, resources, actions, exclusions, administrators, and review dates.
Data-processing documents	Roles, instructions, suppliers, locations or transfers, retention, deletion, and incident contacts.
Current supplier terms	How inputs and outputs are handled, retained, and used, including relevant configuration settings.
Approval matrix	Which actions need review, who can approve them, and how permissions are changed.
Log specification and sample	Captured events and fields, access, retention, export, tests, and known gaps.
Escalation roster	Triggers, human owners, expected handling, and resume conditions.
Stop and recovery runbook	Available controls, owners, dependencies, tests, irreversible actions, and return-to-approval steps.
Exit plan	Access removal, service shutdown, data return or deletion, exceptions, and available evidence.

What this control model does—and does not—prove

It does: Provide the structure for inspectable decisions about scope, approval, evidence, escalation, containment, and recovery for a particular workflow, and the document pack that evidences them.
It does not: Certify a system, guarantee zero risk, determine legal compliance, or make every external action reversible.

Which parts of your workflow are ready for controlled automation?

Take the readiness scorecard for an indicative view of fit, the controls to inspect, and the work that should remain human-led.

Take the readiness scorecard

Bring the workflow. Bring your adviser.

We can walk through the proposed scope, approval rules, evidence, escalation route, and limits in plain English before you decide whether the fit is right.

Book an AI workflow assessment

Data safety and controls for a human-controlled AI agent.