AI compliance is a system. Not a policy PDF.

Start with the real workflow, not the vendor slide deck.

• List every model, API, data source, prompt, output and human reviewer.
• Record what data enters the system, where it travels, where it is stored and who can access it.
• Name one accountable owner for the workflow and one person who can stop it.
• Document the purpose of each data flow and the business decision it supports.

People should not need a lawyer or an engineer to understand what is happening to their data.

• Describe the categories of personal data collected and the purpose for collecting each category.
• Explain how a person can withdraw consent, exercise applicable rights or raise a complaint.
• Keep the notice separate, readable and easy to find at the moment it matters.
• Review the notice whenever the model, purpose, vendor or data flow changes.

Automation should not become an excuse for making accountability invisible.

• Define which decisions require human review, approval or an appeal route.
• Set thresholds for low confidence, unusual inputs, safety concerns and model drift.
• Give reviewers enough context to challenge an output instead of approving it blindly.
• Tell affected users when AI is involved where that disclosure is appropriate to the use case.

A model that works in a presentation is not evidence that it works in production.

• Test accuracy, unsafe output, bias, prompt injection, data leakage and abuse cases relevant to your workflow.
• Keep a dated record of test sets, results, known limitations and the decision to launch.
• Monitor quality after release and define who reviews alerts and how quickly.
• Retest after a model, prompt, vendor, data source or workflow change.

Your risk does not disappear because another company hosts the model.

• Record what each provider receives, retains, uses for training and returns or deletes.
• Review access controls, security commitments, incident notification and subcontractors.
• Do not send customer or employee data to a new AI tool until the owner approves the use.
• Keep a fallback plan for provider outages, policy changes and unexpected model behaviour.

Good evidence is cheaper to create before the first incident.

• Maintain a model or workflow register with owner, purpose, version and risk notes.
• Keep approval records, evaluation results, change logs, incidents and corrective actions.
• Define retention and deletion checks for data, prompts, outputs and logs.
• Run a short tabletop exercise: a bad output, a data request, a vendor breach and a shutdown.