Skip to content
AnglinAI Docs

AI Development Policy and Procedures

Version: 1.0
Status: Draft for adoption; effective when approved by the policy owner
Owner: Designated engineering or security lead
Review cadence: Quarterly and after a material AI-related incident or tool change

Purpose and scope

This policy governs employees and contractors using AI to design, write, test, review, or operate software, including AI features delivered to customers. A named human owner remains accountable for each AI-assisted change and each production AI feature.

Policy

  1. Approved tools and data. Use only tools approved by the policy owner for the intended data. Do not submit secrets, credentials, personal data, or confidential customer information to an AI tool unless its use for that data has been explicitly approved. Record approved tools and any data restrictions in an internal register.
  2. Human review and release. Treat AI-generated work like any other code change: review it, run applicable tests and checks, and obtain the normal approval before merging. AI tools may not independently deploy to production.
  3. Security and rights. Review AI output for security defects, exposed data, incorrect behavior, and licensing concerns. Apply the existing dependency, secret, and security checks. Do not accept unverified claims from AI output as evidence.
  4. Traceability. For material AI assistance, identify its use in the pull request, describe the change, and record tests and reviewer approval. Document significant design decisions and approved exceptions.
  5. Production AI features. Before release, assign an owner and document the feature’s purpose, data flow, expected behavior, foreseeable failures, evaluation results, monitoring, and a way to disable or roll back the feature. Re-evaluate material model, prompt, or provider changes.
  6. Incidents and exceptions. Report suspected AI-related data exposure, unsafe output, or security defects through the existing incident process. The policy owner must document exceptions, their rationale, compensating controls, and expiry date.

Operating procedure

  1. Before using a tool: Check the approved-tool register and its data restrictions. Request owner approval if the tool or data use is not listed.
  2. For each material AI-assisted change: Review the output, run applicable tests and security checks, and record AI assistance and validation in the pull request. A human reviewer approves the change under the normal workflow.
  3. Before releasing a production AI feature: Complete and retain the ownership, data-flow, evaluation, monitoring, and rollback record. Obtain the normal release approval.
  4. When a problem is found: Stop or disable the affected use when appropriate, report it through the incident process, preserve relevant evidence, and track remediation to closure.
  5. Quarterly: The policy owner reviews the approved-tool register, a sample of AI-assisted changes, open exceptions, incidents, and whether this policy needs revision.

Adoption checklist

Complete these items before describing the policy as implemented:

  • Designate and record the policy owner and approval date.
  • Publish an approved-tool register with permitted data types and restrictions.
  • Add an AI-assistance and validation field to the pull-request template.
  • Brief developers and reviewers on this policy and the incident-reporting path.
  • Identify existing production AI features and record their owners, data flows, evaluation, monitoring, and rollback methods.
  • Check a sample of pull requests and resolve any gaps.

Until adoption is complete, describe this document externally as a draft policy being implemented. Once the checklist is complete, it may be provided as the current AI development policy and procedures.

  • nist-ai-rmf-alignment.md — maps the controls in this policy to the NIST AI Risk Management Framework (GOVERN, MAP, MEASURE, MANAGE); this policy is the cited evidence for the GOVERN function.
  • ../runbooks/ai-kill-switch.md — operational procedure for disabling an AI feature or provider, satisfying the rollback requirement in Policy §5.
  • ../../Policies/incident-risk-register.md — the incident and risk context referenced by Policy §6 (“Incidents and exceptions”).