Security and ownership are part of what we deliver, not a paragraph in the contract. This page lists the controls every workflow ships with, what they mean in practice, and where the law applies and specialist review is needed.
Ownership and access
Your accounts, your credentials, your data
The point of these controls is that you can see everything, change anything and stop it all without asking us.
Client-owned accounts
Automation platform, model provider and hosting accounts are opened in your name and billed to you wherever practical. We are an invited user, not the owner, and we can be removed in a minute.
Least privilege
Each connection gets its own credential with the narrowest scope that works: read-only where reading is enough, one mailbox rather than the tenant, one CRM pipeline rather than all of them.
Development and production separated
We build and test against sample data or a sandbox with separate credentials. Production credentials are issued at launch and never used for experiments.
Secrets in a vault
API keys and tokens live in the platform’s credential store or a password manager you control. They are never pasted into workflow notes, prompts, documentation or source control.
Data minimisation and retention
A step receives only the fields it needs. Personal data is masked or omitted before it reaches a model where the task allows. Logs and intermediate data have a retention period agreed with you, not “forever”.
Subprocessor inventory
Every third party that touches data in a workflow is listed with its purpose, region and contract reference, so your own records and privacy notice can be updated accurately. See our data processing information.
Human oversight and operations
Controls that run every day, not just at launch
Approval thresholds
AI steps report a confidence level. Below the threshold, or for any action on a defined sensitive list (payments, refunds, contract terms, anything about a person), the workflow stops and asks a named approver.
Run logs and alerts
Every run, every AI input and output, every error is logged where you can read it. Failures and unusual volumes alert a person you name, not a dashboard nobody opens.
Cost caps
Model and platform spend is capped per workflow and per month, with an alert before the cap and a hard stop at it. A loop or a spike cannot produce a surprise bill.
Fallback and kill switch
If a vendor or model fails, work is queued or routed to the manual path, never dropped. One documented switch pauses the workflow entirely, and your team knows where it is.
Export and backups
Workflow definitions, prompts and configuration are exported at every release and stored in a repository or folder you own. Restoring the previous version is a documented step, not a rescue.
Model-update regression tests
Each AI step has a small test set of real-shaped examples with expected results. When a provider updates or retires a model, we run the set before the change reaches production.
Incident and rollback plan
A one-page plan says who is told, how the workflow is paused, how affected records are found and corrected, and how the previous version is restored. Rehearsed once before launch.
Written handover
A runbook, an ownership map (who owns which account, credential and decision), the subprocessor list and a recorded walkthrough. Enough for your team or another provider to run it without us.
Encryption in transit and at rest is used wherever the platform supports it, which today is every platform we recommend. Ongoing monitoring, regression testing and incident support after the included support window are covered by the care plans.
Regulation
Where the law applies, and what we do about it
We design privacy, access controls, human oversight and documentation into each workflow, then identify where specialist legal or security review is required.
We do not claim that a workflow is “GDPR compliant” or “EU AI Act compliant”. Whether and how a rule applies depends on your role, the data, the system and the use case, and that is a judgement your legal adviser makes, with our documentation in hand. What we can promise is that the documentation exists and that we flag the cases that need a specialist.
EU AI Act
Most provisions have applied since 2 August 2026, with some high-risk obligations on separate timelines. Uses touching employment, credit, access to essential services (housing, utilities, insurance) and biometrics need particular care and may fall into the high-risk category. We do not build autonomous decisions in those areas; where a workflow only prepares such a decision for a person, we document the role, the oversight and the record-keeping, and we tell you when a classification review by a lawyer is needed.
GDPR and data processing
For EU and EEA clients we work under a data processing agreement, keep the subprocessor inventory current, prefer EU-hosted or contractually bounded model options, and record the purpose, legal basis and retention for each data flow so your records of processing can be updated. Our data processing information and privacy policy describe our own handling of your data.
United Kingdom
UK clients are covered by UK data protection law and the ICO’s guidance on AI and data protection, as amended by the Data (Use and Access) Act, not by the EU rules above. We follow the ICO’s expectations on lawfulness, transparency, accuracy and automated decision-making, and we do not copy EU wording into UK contracts. Where the ICO would expect a data protection impact assessment, we say so and supply the technical description for it.
United States
For occasional US-facing work we use the NIST AI Risk Management Framework’s voluntary Govern, Map, Measure and Manage structure to organise the risk review, avoid unsubstantiated performance claims, and refer state-level and sector rules to your counsel. The US is not a market we actively sell into; see about us.
Security and governance questions
Which AI model providers do you use, and where is the data processed?
You choose, with our recommendation. Options include EU-region endpoints from the major providers, EU-hosted platforms, and self-hosted open-weight models for sensitive or high-volume work. The provider, region and contract terms go into your subprocessor inventory, and we confirm the provider’s data-use terms in writing before the first production call.
Do you sign a data processing agreement?
Yes. Where we process personal data on your behalf during discovery, build or care, we sign a DPA, and we can work under yours if you prefer. Our standard terms are described under data processing information. In production, the workflows run in your accounts, so most processing is between you and your own providers.
Can you work inside our security policies and tooling?
Usually. Single sign-on, conditional access, your password manager, your repository and your ticketing system are all fine. If a policy rules out a platform, we choose another. If a policy cannot be met at all, we tell you before you pay for a build rather than after.
What happens if a workflow makes a mistake?
Sensitive actions require approval, so most mistakes are caught as a draft. For the rest, the run log shows exactly which records were touched, the incident plan says how to correct them, and the previous version can be restored. Post-launch care includes incident support; without a care plan we help on a time basis.
Are you certified, for example ISO 27001 or SOC 2?
No, and we will not imply otherwise. We are a small implementation partner working in your environment. The platforms and model providers we recommend publish their own certifications, which we reference in the subprocessor list. If your procurement requires a certified provider for the service itself, we say so early and can help you scope the work with one.