B2Shift · Published 3 August 2026 · Updated 14 August 2026
Most AI safety incidents in business are not model failures. They are access failures: a system that could reach more data than the task required, acting without a checkpoint, leaving no record of what it did. The controls that prevent that are ordinary engineering practice, applied deliberately.
Start with data minimisation and a documented purpose
GDPR-aware automation begins before any code: write down what the workflow is for, what personal data it genuinely needs, and how long that data must be kept. Then make the system match. Only the fields and systems the workflow actually requires should be reachable — not the whole CRM because it was easier to grant.
This is also the cheapest control to implement and the most expensive to retrofit. Widening access later is a config change; narrowing it after a system has been running for a year means discovering what quietly came to depend on it.
Put gates on the actions that cannot be undone
Not every step needs approval, and treating them all the same trains people to click through. Split actions by reversibility. Reading, classifying, drafting and routing can usually run unattended. Sending money, publishing prices, replying to complaints, deleting records and anything that reaches a customer under your name deserves a human gate, or at minimum a delay window in which a person can intervene.
Role-based access belongs in the same conversation. The automation should act with its own identity and its own permissions, not by borrowing an administrator's credentials — which is both a security problem and an audit problem, because afterwards nobody can tell the human and the machine apart in the logs.
Make every decision reconstructable
Every action should leave an audit record: what triggered it, what context was used, what the system decided, what confidence it had, whether a human approved, and what changed as a result. This sounds like compliance overhead until the first time a customer disputes something, at which point it is the only thing standing between you and a guess.
Confidence handling belongs here too. A workflow should have an explicit path for low-confidence cases — to a named person or a queue, not silently to a best guess. The failure mode you want is 'this went to a human', not 'this went out wrong and nobody noticed for three weeks'.
Know where the model runs and what it retains
Ask three questions of any provider: where is the data processed, is it retained, and is it used for training. The answers differ substantially between consumer products and business tiers of the same vendor, and between hosted and private deployments. For regulated data, deployment choice — EU regions, private hosting, or self-hosted open models — is a compliance decision, not a preference.
The European Data Protection Board's opinion on AI models is the reference worth reading before committing to an architecture; it covers when model outputs and training data engage data protection obligations at all.
What technical controls cannot do
Everything above reduces risk. None of it establishes a lawful basis for processing, drafts your privacy notice, decides whether a data protection impact assessment is required, or settles your responsibilities as controller or processor. Those depend on your specific use case and the parties involved, and they need a legal review rather than an engineering one. Good controls make that review straightforward; they do not replace it.
Discuss your workflow