Permitted sources
Define the records and access needed for this task.
Owner and permissions
Agreed processing
Name providers, destinations and what each step retains.
Storage and retention
Review and action
Test who can review, authorise and stop the workflow.
Approval and recovery
Agree where data is stored and processed
A deployment decision covers more than the application server. Source records, uploaded files, search indexes, model requests, logs and backups may each have a different destination. We assess the proposed data flow against your requirements and document the selected services and responsibilities. A cloud, private network or on-site requirement needs a feasibility review; this page is not a guarantee that every configuration is available.
| Area | Required decision |
|---|---|
| Application and storage | Where the workflow runs, who owns the accounts and which regions are used. |
| Models and external services | Which providers process each input and under which account settings and terms. |
| Indexes and logs | What is copied or retained, who can access it and when it is removed. |
| Support and recovery | Who may troubleshoot, how access is granted and how the workflow can be stopped. |
What leaves your environment
Review each outbound path, including model calls, integrations, file processing, monitoring and notifications. A model request may include the prompt and retrieved business context. A notification may expose part of an output. Keeping an application inside a private network does not by itself keep all processing there.
Keep unnecessary data out of the workflow
Start with the smallest set of records needed for the task. A reporting pilot may need totals and operational identifiers rather than full customer profiles. An invoice reminder may need an account contact and payment status but no unrelated mailbox history. Redaction and filtering need checks of their own, including what appears in error messages and logs.
Confirm provider retention and training settings
Data handling depends on the selected service, account configuration and agreement. Before use, confirm whether prompts and outputs are retained, whether they may be used for model training, which exceptions apply and how deletion works. Do not assume a consumer account and a business API have identical terms. Requirements that a provider cannot meet should change the design or stop that use.
Access follows the permissions you grant
Use credentials scoped to the sources and actions the workflow needs. Access to a source and access to an output are separate questions: a service account may read material that not every reviewer should see. Client, department and property boundaries must therefore be checked in retrieval, storage and the interface, rather than relying on a prompt to keep them apart.
Agree how credentials are stored and rotated, who can grant access and what happens when permission is revoked. Tests should cover an unauthorised user, a removed permission and an attempt to retrieve another client's material. Source documents and messages are task data; embedded instructions must not grant the workflow new authority.
Define and test approval controls
Begin with a draft-only workflow where that is sufficient. For a workflow that sends messages or changes records, define the exact action, allowed recipients or destinations, authorised approver and any limits. The application should enforce those checks. A statement in a prompt that asks the model to seek permission is not an access control.
- Show the proposed action and the output version the reviewer is approving.
- Recheck permission and relevant record state before execution.
- Handle rejection, expiry, retries and duplicate requests without unintended actions.
- Record the result and provide a clear way to pause the workflow.
The action-risk guide offers an example policy to adapt to your organisation. The controls required for a particular workflow are agreed and verified in that implementation.
Agree the run record and monitoring
Decide which records support troubleshooting and review: source references, output versions, approvals, attempted actions, failures and available usage information. Those records may themselves contain sensitive data, so access and retention matter. We scope the reporting needed for the project; a universal live audit console is not assumed.
Evidence and procurement requirements
Use the vendor questions checklist to identify required evidence before implementation. This page makes no certification claim. If a certification, regional restriction or particular security control is a condition of the project, raise it early so that support and evidence can be confirmed in writing.
Genaima AI Ltd is registered in England and Wales, company number 17138081. The privacy policy describes this website's handling of personal information; project-specific data processing and operational responsibilities need their own agreement.
Common questions on security and control
Can we begin without sending business data to a model?
Yes, the initial discussion can use a description of the task or a redacted example. Decide what data is necessary and which processing arrangement is acceptable before an implementation uses it.
Can everything stay inside our network?
That requirement needs a review of application hosting, models, integrations, logging and support access. We confirm feasibility before proposing a design that depends on it.
Who can inspect a workflow's outputs?
The roles agreed for the implementation. Access should be tested for both permitted and denied users, including records belonging to different clients or departments.
Launch your autopilotInclude any data-location, access or procurement requirements in your enquiry.