AI Policy, Standards and Procedures: What Belongs Where
Too many organisations confuse policy, standards and procedures and end up with documents that try to be all three. A policy is a high-level commitment. A standard is a specific requirement. A procedure is a step-by-step workflow. Each serves a different purpose and lives in a different place in your governance framework.
A policy is typically one to three pages and states what your organisation will do at a high level. Example: “We are committed to ensuring that AI systems do not breach laws or regulations, are tested for fairness before deployment in high-risk decisions, and have documented human oversight.” This tells your board, employees and regulators what you are committed to. It does not prescribe exactly how you will achieve these things; that is what standards and procedures do.
Standards are the detailed requirements that turn policies into measurable commitments. They specify what must happen. Example: “All AI systems that make decisions affecting protected groups must have demographic parity testing completed and results must be reviewed by compliance before deployment. Demographic parity is measured as the difference in approval rates between groups and must be within 5 percentage points, or system deployment is postponed until the gap is resolved or a documented exception is approved by the Chief Risk Officer.”
That standard is testable. Compliance can sample deployed systems and verify that demographic parity testing happened, that results are documented and that approval was recorded. Standards typically live in a governance framework document or policy suite, not in day-to-day procedures.
Procedures are the step-by-step workflows that tell people how to follow the standard. Example: “When a model owner completes development and is ready to deploy a high-risk system, they log into the AI governance platform, upload the model card and bias test report, select ‘ready for deployment’ and the system notifies the compliance team. The compliance team has five working days to review results and either approve deployment or raise concerns. Concerns must specify which standard the model does not meet and what the model owner must fix. If the model owner disagrees with the concern, they escalate to the Chief Risk Officer for resolution.”
A procedure like this tells the model owner exactly what to do and when, and tells compliance exactly what to expect. Procedures change frequently as you optimise workflows. Standards change less often because they represent commitments. Policies change rarely because they represent your organisation’s position.
The EU AI Act does not specify how you must document policies and standards; it simply specifies obligations. Article 4 requires AI literacy for personnel operating AI systems. Your policy commits to providing it. Your standard specifies minimum training hours and competencies required. Your procedure details who delivers training, how completion is recorded and how you verify people have been trained.
Do not put everything in a policy. A common mistake is writing a 50-page policy document with standards, procedures, exceptions and role definitions mixed together. Three months later, compliance needs to update a procedure and discovers that updating the procedure requires an approval process for policy change. Your documents become unmaintainable.
Instead, create a pyramid: a two-page core policy (commitments), a 10-15 page standards framework (what must happen), and detailed procedures stored separately (how to do it). Changes to procedures do not require policy approval. Changes to standards require risk review. Changes to policy require board approval. This structure lets you move fast where speed matters and maintain governance where it matters.
Document roles clearly. If the policy says “systems are approved by the Chief Risk Officer”, but systems are actually approved by a compliance team, your policy is false and regulators will notice the mismatch. Use your governance framework to state clearly who is accountable for each decision and who is informed.
Policies are often written for regulators and boards. Procedures are written for the people doing the work. Write procedures in a tone that matches your audience. If procedures are painful to read, people will not follow them and will invent their own workarounds.
Version control your documents and date them. When a regulator asks whether your AI governance policy was in place when a system was deployed, you need to know what version of the policy existed on that date. Maintain a version history.