Purpose and consequence
What useful outcome is being pursued? Who could be affected by a wrong, delayed or inappropriate action? Which decisions must remain with a person?
Practical safeguards
Security and data in AI automation.
Security and privacy decisions begin with the purpose, data flow, permissions and consequences of one scoped workflow. The right controls are then agreed for that build, tested and documented for handover.
Last reviewed: 4 August 2026
The answer in brief
Reduce the data and authority before adding controls.
A safer automation starts with a narrow purpose. It should use only the data and permissions required for that purpose, expose its important actions and failures, and keep a person responsible for consequential decisions.
The discovery record should show where data comes from, which providers receive it, who can access it, what the workflow may change and how an owner can pause or recover it. Those answers determine the safeguards, testing and handover—not a generic claim about every AI build.
Discovery safeguards
Answer six questions before connecting systems.
Discovery is where a risky scope can still be reduced cheaply. The process owner and people responsible for relevant systems, privacy, security or compliance should be involved according to the actual data and consequences.
Data inventory
Which fields, files and messages enter the workflow? Do they contain personal, confidential, commercially sensitive or otherwise restricted information?
Authority and notice
Who owns each account and dataset? Is the proposed use consistent with why the data was collected, the notices given and any contractual restrictions?
Data flow
Which systems and providers receive data or outputs? Where can administrators, subprocessors or other third parties access it?
Access and ownership
Which service accounts will act, what minimum permissions do they need and who will control them during operation and after handover?
Failure and recovery
How will a duplicate, missing record, unavailable dependency, unsafe output or unauthorised action be detected, contained and resolved?
Record the data lifecycle in the project scope.
A field list is not enough. The scope needs to connect each piece of information to a purpose, recipient, action and owner. This makes unnecessary collection easier to remove and future changes easier to review.
| Stage | Record in scope | Challenge |
|---|---|---|
| Collect | Source, fields, purpose, authority and expected quality. | Can the outcome be achieved with less or non-sensitive data? |
| Process | Systems, providers, locations, transformations and access. | Does every recipient need the full record or raw content? |
| Act | Output destination, permitted action, reviewer and evidence. | What prevents an uncertain output becoming an unsafe action? |
| Retain | Purpose, period, deletion method, export and responsible owner. | Can payloads be removed while keeping useful operational evidence? |
Build and test
Match practical safeguards to the agreed boundary.
The chosen platform, accounts and risk profile determine the exact implementation. These are design areas to confirm and test, not a representation that every project uses the same technical stack.
Minimise access
Request only the fields, records and permissions the scoped action needs. Separate read, draft, approve and send capabilities where the platform and risk warrant it.
Keep secrets out of content
Use the agreed platform’s appropriate secret-management method. Credentials should not be embedded in source code, prompts, logs or ordinary workflow records.
Validate at boundaries
Check required fields, formats, destinations and permitted actions before information crosses into another system or causes a change.
Make retries safe
Use identifiers, status checks or other controls suited to the platform so delayed events and repeated runs do not silently create duplicate actions.
Limit AI influence
Constrain model context and output format, treat untrusted content as data rather than instructions and prevent an uncertain response from directly expanding its own permissions.
Route consequential work
Require a suitable person to review sensitive communication, exceptions and decisions with material effects. Give that reviewer the source evidence, not only the generated answer.
Record useful events
Capture enough run status, decisions and errors to investigate behaviour while avoiding unnecessary sensitive payloads in operational logs.
Plan the safe stop
Define how the workflow pauses, alerts an owner, resumes and, where relevant, reverses or corrects an action. An unrecoverable failure should not be hidden by automatic retries.
The AI automation guide for business adds a practical test matrix and measurement approach.
No universal configuration
Retention and architecture are project decisions.
We do not claim one fixed retention period, hosting model, processing region, model provider or system architecture for customer automations. Those choices depend on the purpose, customer systems, provider capabilities, applicable obligations and written project scope.
Before a build proceeds, the customer should confirm acceptable providers, locations, access, retention, deletion, backup, export and handover arrangements. If a requirement cannot be supported or verified, the scope should change or stop.
Questions every customer should confirm.
The customer knows its contracts, obligations, internal policies and risk owners. These questions should be answered by the right people before sensitive data or consequential actions enter scope.
- Can we describe the exact purpose for every data field used?
- Do we have authority to give the workflow and its providers this access?
- Are any sensitive, confidential or regulated records involved?
- Which provider terms, model-training settings and subprocessors apply?
- Where may data be processed, stored or remotely accessed?
- What deletion, export and account-closure options are available?
- Who can change the workflow, credentials, prompts and approval rules?
- Which outputs must a person verify before an action occurs?
- How will affected people receive notice or challenge an outcome where needed?
- What logs, alerts and incident contacts will support investigation?
- What retention period fits the purpose and applicable obligations?
- Who owns operation, vendor management and access reviews after handover?
The questions change with the workflow.
Invoice follow-up
Confirm the source of payment status, contact authority, dispute handling and approval needed before a reminder is sent.
Review this workflowLead follow-up
Confirm collection notices, communication preferences, routing permissions and where a draft becomes a commercial promise.
Review this workflowCustomer onboarding
Confirm which documents are necessary, who may receive them and which access or account changes require explicit approval.
Review this workflowWebsite data and customer-build data are different scopes.
Our privacy notice describes website, application and analytics data. Our website and offer terms explain the public offer and the need for a written project scope. A customer automation may involve different systems, providers, data and contractual responsibilities, which must be documented for that project rather than inferred from this page.
Official guidance is a reference point, not a badge.
We use official guidance to improve the questions asked during discovery. Linking to it does not mean The Free AI Guys or a customer workflow has been assessed, certified or found compliant by the issuing body.
Describe the process and the data together.
Review our AI automation service, then tell us what starts the task, which systems and records it touches, who owns the decisions and what a safe result looks like.
Apply TodayStart with one repetitive task.
Tell us what your team repeats, which tools are involved and what a good result looks like. We will assess whether it is a sensible first automation.
Apply Today