AI Governance Policy

1. Purpose

This policy sets how the Organisation decides to build, buy, deploy and retire artificial intelligence (AI) systems, and how it keeps them lawful, safe, secure, fair, explainable and under human control. It applies the Organisation's privacy and security commitments to the particular risks of AI, such as bias, opacity, drift, misuse of data and unreliable output.

• AI is adopted for stated purposes that bring value without disproportionate risk.
• Individuals are told when AI affects them, and can ask for explanation and human review.
• AI systems are inventoried, assessed, tested, monitored and retired under defined owners.

2. Scope

The policy applies to all AI systems the Organisation develops, trains, fine-tunes, buys, subscribes to, embeds in products or uses internally, and to all personnel and suppliers involved in them.

• In scope: machine learning models, generative AI, large language models, analytics that profile or score people, automated decision tools, chatbots, recommendation, classification and content analysis systems, and AI features in third-party software.
• In scope: the data used to train, test, tune and operate AI systems, the prompts and outputs, and the infrastructure that hosts them.
• In scope: AI used by customers' end users through the Organisation's platforms, where the Organisation provides the AI.
• Out of scope: simple rule-based automation with no learning component and no effect on individuals, provided it is registered as such in the AI register.
• Use of public AI tools by employees for personal productivity is covered by the Employee AI Usage Policy; this policy covers governance of AI systems.

3. Terms and Definitions

4. Roles and Responsibilities

5. AI Governance Policy Statements

The Organisation commits to the statements below. Detailed controls for personal data are in the Data Protection and Privacy Policy and Data Governance Policy.

5.1 AI governance committee

5.2 Principles

• Purpose: every AI system has a documented purpose and benefit, and is not used beyond it without a new approval.
• Lawfulness and privacy: AI processing of personal data has a lawful ground, notice, minimisation and safeguards.
• Fairness: AI must not unjustly discriminate, and is tested for it before and during use.
• Transparency: individuals are told when they are dealing with AI or when AI contributes to a decision about them.
• Human oversight: significant decisions about individuals are not taken solely by AI unless the Committee has approved it and a route to human review exists.
• Safety and security: AI systems are resilient to misuse and attack and fail safely.
• Accountability: a named owner is accountable for each system and its outputs.

5.3 AI register and classification

• Every AI system must be entered in the AI register before use, with owner, purpose, model type, data, suppliers, users, location and risk class. Shadow AI found in the Organisation must be registered or stopped within [30 days].
• The risk class decides the approval path and the controls, as the table shows.

5.4 Compliance with data protection laws

• AI processing of personal data must meet the Data Protection and Privacy Policy and the Digital Personal Data Protection Act, 2023 and its Rules [confirm the current requirement], and applicable AI and data law in other jurisdictions where the Organisation operates.
• Legal must track new AI regulation and report changes to the Committee within [30 days] of publication.

5.5 Data protection roles in AI

5.6 Privacy by design and default

• An AI system that processes personal data must be designed with minimisation (only the features needed), pseudonymisation of training data, short retention of prompts and outputs, and the most protective defaults.
• Personal data must not be used to train or fine-tune a model unless the Privacy Lead has confirmed that the purpose is compatible with the original and that the lawful ground covers it.
• Deletion requests must be honoured in training sets and, where technically possible, models must be retrained or filtered. Where it is not possible, the Committee must record the limit and tell the individual.

5.7 Data protection impact assessment and AI impact assessment

• A combined AI impact assessment and DPIA is required before a medium or high-risk system is built or bought. It uses the form in Annexure B and records purpose, data sources, lawful ground, model type, accuracy goals, bias risks, security threats, oversight and exit plan.
• The assessment must be repeated [every 12 months] for high-risk systems, and on any change in purpose, data, model or supplier.

5.8 Accountability and transparency

• Each AI system must have documentation: model card (purpose, data, performance, limits), data lineage, test results, version history and change log.
• Users must be told when they interact with AI or receive AI-generated content, and that outputs may be wrong. Content that could mislead, such as synthetic media, must be labelled.
• Where AI contributes to a decision about an individual, the individual must be able to obtain a meaningful explanation and request human review within [15 days].

5.9 Security measures

• AI systems and their data must meet the Information Security Policy, plus: access control to models, weights and training data; secrets protection for API keys; logging of prompts and outputs (with personal data minimised); and segregation of customer data.
• Threats specific to AI must be tested before release and [every 12 months]: prompt injection, data leakage, model theft, data poisoning, adversarial inputs, over-permissive tool access and unsafe output handling.
• AI systems that can take actions, such as running code or sending messages, must work with least-privilege credentials, rate limits and confirmation for high-impact actions.
• Models, datasets and libraries from public sources must be scanned, pinned to versions and obtained from trusted sources.

5.10 Bias and fairness

• For each high and medium-risk system, the data scientist must define the groups and attributes relevant to fairness, such as gender, age, language, region, disability or caste where lawful and appropriate, and the measures used, such as error-rate gaps and selection-rate ratios.
• Training and test data must be reviewed for representativeness, label quality and proxies for protected attributes before use.
• The system must meet a fairness threshold agreed by the Committee [for example no group error-rate gap above 5 percentage points, or a documented justification] before launch, and be re-tested [quarterly] for high-risk systems.
• Where bias is found, the owner must record it, stop or limit the system if harm is possible, and correct it within [30 days] or request Committee review.
• People who might be affected must have a route to challenge outcomes, and complaints about bias must be analysed for patterns.

5.11 Third-party management

• AI suppliers must be assessed under the Supplier Relationship Management Policy plus: model provenance, training data sources and rights, security testing evidence, handling of the Organisation's data (including no training on it without written approval), sub-processors, location, change notification and incident notification within [24 hours].
• Contracts must give rights to audit, to obtain documentation, to be told of material model changes, and to exit with data returned or deleted.
• The owner must keep an exit plan for each high-risk third-party AI service and test a fallback [every 12 months].

5.12 Features for AI systems that analyse customer content

AI systems that analyse customer or end-user content, such as messages, documents, calls or transactions, carry added duties because the content is often personal and sensitive.

• Analyse only the content and fields needed for the stated purpose, and only for customers who have a contract allowing it.
• Keep the content for as short a time as the function needs [for example 30 days], with automated deletion, and do not use it to train shared models unless the customer has agreed in writing.
• Provide customer-level segregation, so that one customer's content cannot affect or be revealed to another.
• Allow the customer to configure, review and switch off AI features, and give them logs of what was processed.
• Flag and route for human review any output that blocks, filters or labels content, with a path to appeal.

5.13 User inquiry management

• Users and customers must have a published channel for questions, complaints and requests about AI. Acknowledge within [2 working days] and respond within [15 days].
• Questions that concern personal data are handled by the grievance contact under the Data Protection and Privacy Policy; others by the AI system owner.
• The Committee reviews the log of inquiries [quarterly] for patterns that suggest a defect or a bias.

5.14 Monitoring and maintenance

• Each system must have monitoring for accuracy, drift, fairness, error rates, abuse, cost and availability, with thresholds and alert owners.
• Models must be revalidated [every 6 months] for high-risk systems and [every 12 months] for others, and whenever the input data changes materially.
• Changes to models, prompts, data or settings follow the Change Management Policy and Procedure and are tested before release, with rollback ready.
• A system must be retired when it is no longer needed or cannot be kept within policy, with data deleted and users told.

5.15 Human oversight

• A human reviewer with the authority and training to override must be placed in the loop for high-risk decisions. The reviewer must have enough time, information and independence to make a real decision.
• Automation bias must be managed through training and sampling: the reviewer's override rate is monitored, and very low rates trigger review.

6. AI Risk Management

AI risks are managed within the Risk Management Policy using the four steps below. The AI register and impact assessments are the main inputs.

6.1 AI risk identification

• Risks must be identified at design, before launch, on change and at least [yearly], using workshops, threat modelling, incident data and complaints.
• Risk categories: wrong or unreliable output; bias and discrimination; privacy and data leakage; security and misuse; lack of explainability; over-reliance; intellectual property; legal and regulatory; reputational; supplier lock-in or failure; environmental and cost.

6.2 AI risk evaluation

Each risk is rated by likelihood and severity, using the Risk Management Policy scale. The table gives examples of how AI risks map to ratings.

6.3 AI risk mitigation

• Controls must be chosen to reduce high and medium risks to an acceptable level: data quality checks; bias mitigation; guardrails and filters; human review; output limits; confidence thresholds; fallbacks; access control; red-team testing; user disclosure.
• Residual risks above the appetite need written acceptance by the Committee. The Committee must refuse a use case it considers unacceptable.

6.4 AI risk monitoring and review

• Risks are reviewed [quarterly] for high-risk systems and [yearly] for others, and after any incident or material change.
• Key risk indicators include model error rates, override rates, complaint volumes, drift measures and security test findings, and are reported to the Committee.

7. AI Incidents

• An AI incident is any event in which an AI system causes or may cause harm, such as discriminatory output, leakage of data in output, unsafe action, major inaccuracy or successful attack on a model.
• AI incidents are reported and handled under the Information Security Incident Management Policy and, where personal data is involved, the breach rules in the Data Protection and Privacy Policy.
• The AI system owner can pause the system at once. The Committee Chair must be told within [4 hours] of a high-risk AI incident and the Committee must review it within [10 working days].
• Post-incident reviews must examine data, model, prompt, oversight and supplier causes, and feed back into testing and monitoring.

8. Training and Awareness

• Everyone who builds, buys, approves or oversees AI must complete AI governance training on joining and [every 12 months], covering this policy, privacy, bias, security and the AI register.
• Human reviewers of high-risk systems must complete role-specific training before they begin, including how to recognise automation bias and model failure.
• All personnel must receive guidance on the Employee AI Usage Policy, including what data must never be put into unapproved AI tools.
• Training completion is reported to the Committee [quarterly].

9. Compliance and Monitoring

• The Committee reviews the measures [quarterly]. Internal audit includes AI governance in the audit plan [every 12 months]. Unregistered AI found in audit is a finding.

10. Records and Evidence

Annexure A: AI register entry

Annexure B: AI impact assessment form

11. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

12. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

13. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Employee AI Usage Policy
• Data Protection and Privacy Policy
• Data Governance Policy
• Risk Management Policy
• Supplier Relationship Management Policy
• Information Security Incident Management Policy