AI Governance Policy

Document control

[Company Name]

Status Draft for approval | Version 1.1 | Prepared 6 October 2026

Document identifier AIG POL 001

Owner [AI Governance Lead] | Approving authority [Board or delegated executive authority]

Approval date [To be completed] | Effective date [To be completed] | Next review [Within 12 months of effective date]

Complete the approval fields and Company tailoring register before adoption.

AI Adoption and Governance Implementation Guideline

P01 Purpose authority and scope

The Company permits AI where it improves a defined business outcome and where the resulting risks can be controlled. This policy establishes mandatory requirements for selecting, procuring, developing, using, monitoring, and retiring AI. Every approved use must have an accountable owner, a defined purpose, suitable evidence, and controls proportionate to its potential harm.

This policy applies to employees, directors, contractors, temporary workers, and third parties acting for the Company, across all business units and locations. It covers purchased and internally developed AI, generative AI, predictive models, recommendation systems, embedded software features, coding assistants, retrieval systems, and agents that use tools or take actions. Trials, free accounts, browser extensions, personal devices used for work, and AI supplied through partners are included.

The policy takes effect only after approval by the designated approving authority. Mandatory language uses “must”; “should” identifies a recommended practice requiring a documented reason when not followed. The companion AI Adoption and Governance Implementation Guideline defines the operating process and evidence templates. It may specify stricter safeguards but may not weaken this policy. Applicable law, contractual commitments, and stricter Company policies take precedence.

The AI Governance Lead must coordinate this policy with information security, privacy, records management, procurement, software delivery, business continuity, employee conduct, and enterprise risk requirements. Legal must resolve conflicts involving legal obligations. Unresolved conflicts must be escalated before the activity proceeds.

P02 Governance principles and risk appetite

The Company must use AI for a legitimate, documented purpose. AI use must respect affected people, protect information, provide appropriate transparency, and maintain responsibility for decisions and outcomes. Controls must address the whole workflow, including data, models, prompts, users, integrations, and downstream actions.

The Company has no appetite for unlawful use, intentional discrimination, deception, unauthorized disclosure, circumvention of security controls, or use of intellectual property without sufficient rights. Business value does not justify these activities. Proposed uses with severe, irreversible, or uncontrolled harm must not proceed until the risk has been removed or reduced within approved limits.

AI may support material decisions only when the decision process is lawful, tested, traceable, and subject to effective oversight. A human reviewer must have the time, information, competence, and authority to challenge or reject an AI recommendation. A nominal approval click does not establish effective oversight.

Use case owners must consider safety, fairness, accessibility, reliability, security, privacy, explainability, commercial dependence, workforce effects, and environmental or resource impacts where material. Tradeoffs must be recorded with the affected stakeholders, supporting evidence, and authorized risk acceptance. Legal or contractual prohibitions cannot be accepted as business risk.

P03 Accountability and decision rights

The approving authority must approve the policy and enterprise AI risk appetite. The executive sponsor must secure resources and resolve cross-functional issues. The AI Governance Committee must oversee the portfolio, approve high-risk uses, review material incidents, and challenge overdue remediation. The AI Governance Lead must maintain the inventory, workflow, control library, and reporting.

Each use case must have a business owner accountable for purpose, business outcomes, users, and residual risk, and a technical owner accountable for implementation, operation, monitoring, and recovery. Data owners must authorize access and permitted purposes. Security, Privacy, Legal, Compliance, Procurement, and HR must assess matters within their authority. Independent validation must challenge high-risk designs and evidence. Internal Audit must provide independent assurance and must not serve as the operational approver.

The Company may combine roles where scale requires it, but it must document the arrangement and preserve independent challenge for high-risk uses. The developer, vendor, or business owner must not independently validate and approve their own high-risk system. Conflicts of interest must be disclosed and alternate reviewers appointed.

Security and designated operational owners may restrict access or suspend an AI system immediately when necessary to contain harm. They must promptly notify the business owner and AI Governance Lead. Restoration requires recorded authorization under P13 and must not depend solely on the person responsible for the failure.

P04 Inventory approved tools and intake

All business AI uses must be registered before a prototype, proof of concept, pilot, procurement commitment, integration, or production launch. The inventory must distinguish the tool or model from the use case and record ownership, purpose, users, data categories, suppliers, jurisdictions, system versions, risk tier, approvals, dependencies, monitoring, and retirement status.

The AI Governance Lead must maintain an approved tools catalog stating approved account types, features, data classes, permitted activities, restrictions, and renewal dates. Tool approval is limited to the reviewed configuration and purposes. It does not approve every use, plug-in, model, connector, or data category offered by that supplier.

Routine individual use within a documented, approved low-risk activity may rely on the catalog entry and workforce acknowledgment without a separate record for each employee prompt. A new business workflow, new data class, customer exposure, integration, automated action, or material decision requires use case intake. Users must ask the AI Governance Lead when the boundary is unclear.

Technology and Procurement must identify embedded AI during acquisition and renewal. Feature owners must review vendor activations and material updates before enabling them. Unregistered existing uses must enter the discovery and remediation process; harmful or prohibited activity must be suspended immediately. Legacy status does not grant an exemption.

P05 Risk classification and approval

Risk tiers are internal governance categories, separate from any legal classification. Screening must consider foreseeable harm before controls, affected populations, data sensitivity, external exposure, reversibility, autonomy, scale, and dependency on the system. The highest applicable trigger determines the tier; a low average score must not conceal a severe risk.

High-risk treatment also applies where a failure could materially disrupt critical operations or cause substantial financial loss. Legal must separately assess sector rules and jurisdiction-specific categories. Where the Company cannot establish the risk, the use must be treated as high-risk until resolved.

Mitigation may reduce residual risk but must not automatically remove high-risk governance requirements. Reclassification requires a documented change in purpose or exposure, evidence, and approval by the authority that approved the previous tier. Each approval must state scope, conditions, accountable owners, expiry or review date, and residual risks. Silence or elapsed review time is not approval.

P06 Prohibited and restricted activities

The following activities are prohibited: using AI unlawfully; enabling intentional discrimination, harassment, fraud, or impersonation; misrepresenting AI output as verified evidence; bypassing Company security or approval controls; placing secrets or restricted information into unauthorized services; and using confidential information or intellectual property without sufficient rights. AI must not fabricate records, audit evidence, citations, customer commitments, or regulatory submissions.

Employees must not upload another employer's confidential documents, proprietary policies, source code, internal models, or other protected material without documented authorization and rights. Renaming, paraphrasing, or asking AI to rewrite protected material does not establish permission to use it. The same requirement applies to partner, customer, and third-party content.

High-risk activities require specific approval rather than reliance on general tool approval. These include employment screening or evaluation; eligibility, credit, insurance, health, or legal recommendations; biometric or workplace monitoring; regulated communications; material financial analysis; safety-critical control; and agents able to transact, alter access, publish, or modify production records. Some of these activities may be unlawful in a particular jurisdiction and must then be rejected.

The Company prohibits solely AI-determined adverse decisions affecting employment, access to essential services, or comparable individual rights under this baseline policy. Any change to that prohibition requires a formal policy amendment, a documented lawful process, and approval by the policy approving authority; it cannot be granted through an exception. Use of AI to provide professional advice must include appropriately qualified responsibility and required disclosures.

P07 Data protection and information handling

Data owners and Privacy must approve AI processing according to Company classification, permitted purpose, legal basis where required, notices, consent where applicable, contractual restrictions, residency, and transfer requirements. Approval must cover training, fine-tuning, retrieval, inference, evaluation, logs, embeddings, caches, backups, and supplier access. Public availability does not by itself establish permission to process or train on data.

Only the minimum information necessary may be provided. Users must remove unnecessary identifiers and confidential details. Pseudonymized data remains subject to applicable personal data controls. Sensitive data must be restricted to explicitly approved environments; credentials, private keys, authentication tokens, and production secrets must never be submitted as AI input.

Supplier terms and configuration must define whether prompts, files, outputs, and feedback are retained, accessed by people, shared, or used for supplier training. Company confidential or personal data must not be used to train supplier models without separate documented authorization from the data owner, Privacy, Legal, and relevant approval authority. An interface label alone is insufficient evidence of protection.

Retrieval and search systems must enforce source permissions at retrieval time and when presenting results. Indexing must not broaden access. Derived datasets and embeddings must receive an appropriate classification. Records must have defined retention and deletion rules, with legal holds preserved. Teams must maintain the complete transaction journal required by P23 while separating minimized searchable metadata from protected actual evidence under approved retention and access rules.

P08 Suppliers procurement and intellectual property

Procurement must complete AI due diligence before purchase, renewal, integration, or activation. Review must cover supplier identity, financial and operational resilience, model dependencies, data use, subprocessors, hosting, security, evaluation evidence, accessibility, limitations, change notices, incident cooperation, service availability, and exit arrangements. High-risk approval must not rely solely on marketing claims or a general security certificate.

Contracts must address authorized use, confidentiality, data processing and transfers, supplier training restrictions, ownership or licenses for inputs and outputs, rights to use training and retrieval material, incident notification, audit evidence, material changes, subcontracting, retention, deletion, termination, and continuity. Legal must assess indemnities, liability limits, warranties, and the practical allocation of risk. Missing safeguards require remediation or explicit lawful risk acceptance by the authorized owner.

Teams must confirm adequate rights for datasets, model weights, software, prompts, documentation, and generated outputs intended for use. Open-source license obligations must be assessed before distribution or commercial deployment. AI-generated code must pass normal security, quality, provenance, and license checks. Outputs must not be assumed accurate, exclusive, noninfringing, or protected by copyright merely because a tool generated them.

Material supplier or model changes must trigger reassessment. If a supplier cannot provide sufficient information for the intended use, the Company must limit the purpose, add independent evidence and controls, or decline deployment. The business owner must maintain a feasible exit route and dependency register.

P09 Development architecture and security

AI systems must follow secure development and change management requirements. Teams must record model and component versions, data lineage, intended use, limitations, prompts and configuration where material, evaluations, and dependencies. Training or fine-tuning must use approved datasets and environments, with access controls and reproducible evidence appropriate to the system.

Security controls must include least privilege, approved identity and authentication, encryption, secret management, environment separation, vulnerability management, dependency review, abuse prevention, and protected logs. Threat assessment must address prompt injection, data poisoning, malicious files, model or data extraction, unsafe output handling, and abuse of connected tools, as applicable.

Untrusted content, including retrieved text, email, web pages, and tool results, must not grant authority or override policy. Authorization must be enforced by the application and receiving service. Prompt instructions and model refusal behavior are supporting safeguards, not substitutes for access control. Code and commands produced by AI must be reviewed or executed in an appropriately restricted environment.

Technical owners must provide safe fallback behavior, rate and resource limits, traceability, and a tested way to disable the system or revoke its access. Changes to models, prompts, retrieval sources, integrations, and guardrails must be versioned and tested against the approved baseline before release. Supplier-managed updates must be detected and assessed under a documented process.

P10 Evaluation fairness and human oversight

Every use must have documented acceptance criteria tied to its purpose and tier. Evaluation must use representative scenarios, foreseeable misuse, challenging cases, and realistic operating conditions. Teams must assess performance, factual accuracy, harmful content, security, privacy, accessibility, and reliability where relevant. Material decisions require task-specific validation and evidence of effective human oversight.

Where outputs affect people, teams must assess relevant disparities and harms, consult appropriate stakeholders, and test across relevant groups or conditions where lawful and feasible. Sensitive attributes must not be collected or inferred for testing without Privacy and Legal review. Lack of suitable data must be recorded as a limitation; it must not be interpreted as evidence of fairness.

Generative outputs must be checked against authoritative information for material facts, calculations, citations, or recommendations. Retrieval may improve grounding but does not guarantee correctness. Reviewers must understand uncertainty and automation bias, have access to the evidence necessary to challenge outputs, and record overrides or escalations for material cases.

High-risk systems must receive independent validation before production and after material changes. Validators must review test design, results, subgroup limitations, operating boundaries, failure modes, and oversight. Severe safety, privacy, security, or rights-related failures must be resolved before release. Other residual risks require specific acceptance, a mitigation owner, due date, and operating limits. A pilot is not permission to expose people to uncontrolled harm.

P11 Agentic AI and automated actions

Agents must have a documented action boundary that identifies permitted tools, accounts, destinations, data, transaction types, monetary limits, execution time, and maximum scope. Access must use dedicated identities with narrowly scoped permissions. Agents must not grant themselves new rights, approve their own exceptions, or expand their task scope.

Material or difficult-to-reverse actions must require an authorized human to approve the specific action with its target, content, amount, and consequences. This includes payments, contractual commitments, consequential access changes, production deletion, and publication of regulated or sensitive communications. Approved low-consequence, reversible actions may run automatically only within a tested, documented scope. High-risk uses remain subject to P05.

Teams must constrain network destinations, validate tool inputs and outputs, prevent replay or duplicate execution, enforce budgets and transaction limits outside the model, and protect credentials. Agents must stop when authorization is ambiguous, a required approval is absent, or a defined threshold is exceeded. External messages and retrieved content must be treated as untrusted input.

The technical owner must maintain action traces sufficient to reconstruct who authorized an action, which system version executed it, what tool was called, and the outcome, while minimizing sensitive payloads. Rollback or compensating procedures, isolation, and credential revocation must be tested. Failed or partially completed actions must be reconciled before retrying.

P12 Transparency workforce use and adoption

Users must follow the approved tools catalog, complete required training before access, review outputs according to risk, and remain responsible for work they submit. Employees must not use personal AI accounts for Company work unless expressly approved. Meeting transcription or recording requires review of participant notice, consent where required, confidentiality, retention, and applicable law.

People interacting with AI must receive appropriate notice when required by law or needed to avoid misleading them. Customer-facing systems must provide clear scope and limitations, a means to reach a person, and a process to challenge material outcomes. Synthetic media must not impersonate people or mislead audiences; required disclosure, labeling, and provenance controls must be applied.

Business owners must maintain evidence for external AI performance and capability claims. Customer, contractual, legal, financial, and regulatory statements must receive the same accountable review as other Company statements. Company standards for accessibility and reasonable accommodation apply to AI-enabled experiences.

Adoption must include role-specific training, support, user feedback, and assessment of workflow and workforce effects. HR and business owners must consult employees or representatives where required. AI proficiency must not become an unsupported basis for employment decisions. Users must have a confidential reporting channel for unsafe use and be able to raise concerns in good faith without retaliation.

P13 Operations monitoring and incident response

Production use requires approved operating documentation, support ownership, monitoring thresholds, review schedules, fallback procedures, and an incident route. Technical owners must monitor failures, unauthorized actions, leakage indicators, drift, supplier changes, availability, cost, and business outcomes as relevant. Business owners must review complaints, overrides, and harmful outcomes.

Users must report suspected exposure, harmful output, unauthorized action, discrimination, misuse, or control failure immediately through [Incident reporting channel]. They must preserve available evidence and avoid spreading sensitive content. The Company must integrate AI incidents with security, privacy, operational, legal, and HR response processes rather than maintain conflicting escalation routes.

For critical events involving credible severe harm, material data exposure, or uncontrolled consequential actions, the response lead must initiate immediate containment and notify Security, Privacy, Legal, the business owner, and the AI Governance Lead within one hour of awareness. High-severity events must be escalated within four hours; other events must be recorded within one business day. These are proposed internal requirements and do not replace shorter legal or contractual notification duties.

The response lead must assess impact, stop or restrict the system where needed, preserve evidence with controlled access, identify affected parties, and coordinate remediation. Legal and Privacy must determine external notification obligations and deadlines. Restart requires root-cause assessment, successful corrective tests, business owner and relevant specialist approval, and Committee approval for high-risk use. Retrospectives must update controls and the risk register.

P14 Changes continuity records and retirement

Material changes require reassessment and approval before release. Triggers include new purpose, population, data category, jurisdiction, supplier, model family or material version, automation level, tool permissions, integration, operating scale, or degraded performance. The AI Governance Lead must determine the required review path; uncertainty must be escalated.

Business and technical owners must assess dependency on AI and maintain a manual, alternative, or safe-stop process appropriate to the business impact. Recovery objectives must align with business continuity requirements. High-risk systems and critical dependencies must undergo at least annual fallback and disablement exercises, and additional exercises after material changes.

The Company must retain approvals, assessments, evaluations, version history, incident records, supplier evidence, training records, and relevant decision trails according to an approved records schedule. The schedule must specify an owner, purpose, retention period, storage location, access controls, deletion method, and legal hold handling. Teams must implement P23 complete recording and protected evidence requirements under a defined lawful retention schedule rather than choose unlimited retention.

Retirement requires notifying users, removing integrations and access, revoking credentials, canceling services, addressing downstream dependencies, archiving necessary evidence, and deleting data where permitted and required. Deletion scope must include supplier copies, indexes, embeddings, caches, and backups according to approved schedules. The owner must record completion, unresolved retention obligations, and the replacement or fallback service.

P15 Exceptions assurance and enforcement

Exceptions must be requested before the affected activity and include the specific requirement, rationale, affected use cases, duration, risk, compensating controls, remediation plan, owner, and approvals. The AI Governance Committee and relevant control owner must approve high-risk exceptions. Lower-tier exceptions require the AI Governance Lead and relevant control owner, with business owner risk acceptance.

No exception may authorize an unlawful activity, a P06 prohibition, use without sufficient rights, or breach of an unwaived contractual duty. Exceptions must expire within 90 days under this proposed baseline. Renewals require fresh evidence and approval. Expired exceptions must block the affected activity unless the original requirement has been met. Emergency containment actions may proceed immediately but must be documented and reviewed within one business day.

The AI Governance Lead must review high-risk use cases at least every six months, moderate-risk use cases annually, and low-risk catalog patterns annually. All tiers require immediate review after material change or incident. The Committee must receive quarterly reporting on inventory coverage, risk acceptance, incidents, exceptions, validation findings, training, and business value. Internal Audit must include AI in its risk-based audit plan.

Noncompliance may result in access restrictions, remediation, supplier action, or disciplinary measures under Company procedures and applicable law. Good-faith reporting must be protected. The policy owner must review the policy annually and after material legal, operational, or technology changes, with amendments approved by the designated authority.

P16 Adoption decisions and definitions

Before approval, the Company must name the policy authority, executive sponsor, AI Governance Lead, Committee members, specialist reviewers, independent validation function, incident channel, and records owner. It must adopt or adjust the proposed tier boundaries, review intervals, incident targets, and exception duration; confirm jurisdictions and sector requirements; and align the data taxonomy and records schedule with existing policies. Approval must identify the effective date and transition plan.

P17 Requirements for small medium and large companies

Apply the common policy to every Company. Adjust the delivery model to organizational complexity and capability while preserving control outcomes. Size, ownership, and regulatory status are separate dimensions; the applicable sections are cumulative. A small regulated company must satisfy the regulated-company requirements. A large private company must satisfy the large-company and private-company requirements.

The approving authority must record the Company's operating model using AI volume, consequences, business units, locations, data sensitivity, and available assurance capacity. The descriptions below are operational profiles, not statutory definitions or employee-count thresholds. High-risk activity requires high-risk governance regardless of company size.

Small companies

A small company with a limited portfolio may appoint a founder, executive, or existing functional leader as sponsor and designate a part-time AI Governance Lead. A small designated review group may fulfill the Committee role if its charter, membership, decisions, and specialist access are documented. It must preserve P03 independence for high-risk review and cannot allow one person to build, validate, and approve their own high-risk use.

The Company may use a controlled register and shared evidence repository rather than a dedicated governance platform. It must maintain approved accounts, data boundaries, intake, training, incidents, and a stop mechanism. Where internal expertise is insufficient, it must obtain qualified independent advice or limit use to activities it can oversee. Lack of resources is a reason to constrain high-risk adoption, not to remove required review.

Medium companies

A medium company with several functions or integrations must establish a cross-functional review group, identify business and technical owners, and allocate explicit capacity for governance and specialist review. It must maintain a central catalog and register, use common assessment and approval templates, and connect AI review to procurement, privacy, security, and software change processes.

Business units may deliver within approved patterns and delegated limits. The AI Governance Lead must review exceptions, drift in local practices, supplier dependencies, and the aggregate portfolio. High-risk validation must be separate from the delivery team or supported by qualified external reviewers.

Large companies

A large company with multiple entities, locations, or a substantial AI portfolio must maintain enterprise policy ownership, business-unit accountability, and defined local regulatory responsibilities. Central governance must set control outcomes, approve reusable patterns, maintain consolidated visibility, and oversee aggregate exposure. Local teams must implement controls and record approvals within their delegated authority.

The Company must assign resources for independent validation, monitoring, model and agent lifecycle management, supplier concentration, and risk-based assurance. It must reconcile local inventories, manage cross-border dependencies, and govern acquisitions, subsidiaries, and shared platforms. Automated evidence collection may support the process but must not replace accountable decisions.

P18 Requirements for public and private companies

Public companies

For a publicly traded company, the board or its designated committee must receive periodic reporting on material AI exposure, strategic dependence, major incidents, and realized value. Legal, Finance, Investor Relations, and the disclosure control function must assess when AI affects external reporting, financial statements, investor communications, or market-sensitive information under the applicable listing and securities regime.

Material nonpublic information must be limited to explicitly approved environments and access. AI used in financial reporting or disclosure preparation must have traceable sources, controlled versions, accountable review, and applicable internal-control evidence. AI must not independently publish market disclosures or authorize changes to financial reporting records. Claims about AI capability and financial impact must be substantiated and reviewed before release.

Legal determines legally required disclosures, notification timing, and market-abuse controls. This policy does not impose a single disclosure timetable across exchanges or jurisdictions. Material issues must reach the appropriate decision makers early enough for them to meet actual obligations.

Private companies

For a privately held company, the owner, board, managing partners, or authorized executive body must establish approval authority and oversight proportionate to risk. Material uses and incidents must reach those responsible for the business. A founder's operational involvement does not eliminate independent high-risk validation or specialist clearance.

The Company must assess investor, lender, customer, insurer, and shareholder commitments involving AI, confidentiality, assurance, or reporting. Portfolio companies must clarify their own accountability and any parent-company standards. Sharing information with owners or affiliates must follow data rights and access restrictions rather than assume unrestricted access.

Private-company status does not reduce obligations to employees, customers, counterparties, or regulators. The Company must retain sufficient evidence for due diligence, financing, acquisition, insurance, and customer assurance where relevant, using the approved records schedule.

P19 Requirements for regulated and unregulated companies

Regulated companies

A company operating under sector-specific supervision must involve its Compliance and relevant professional or safety functions from intake. Legal and Compliance must determine whether AI changes regulated activities, model-risk obligations, product or service approvals, outsourcing, recordkeeping, customer protection, professional accountability, operational resilience, or required regulator engagement.

Relevant requirements must be recorded for the particular use, entity, jurisdiction, and Company role. The business owner must satisfy applicable validation, auditability, documentation, human review, monitoring, and retention obligations before deployment. A general AI assessment must not replace a required sector-specific assessment or approval. Existing sector risk governance should incorporate AI, with clear coordination and no duplicated or conflicting decisions.

Where a supplier limits access to evidence needed for a lawful regulated use, the Company must obtain adequate assurance, narrow the use, or stop. The approving authority cannot accept noncompliance as residual business risk. Regulator communications must be coordinated by authorized functions.

Unregulated companies

“Unregulated” in this policy means the absence of an identified sector-specific supervisory regime; it does not mean an absence of law or accountability. Legal must still assess privacy, employment, discrimination, consumer protection, IP, contracts, safety, and any AI-specific requirements applicable to the activity and location.

An unregulated company must follow the common inventory, approval, data, security, evaluation, oversight, incident, and training requirements. High-risk uses must receive high-risk treatment even if no sector regulator requires it. The Company should proportionately obtain independent assurance and review customer and supply-chain obligations that may require additional controls.

Combining the requirements

Record the applicable size model, ownership model, regulatory overlay, and any additional contractual or legal constraints in the tailoring register. Where requirements differ, apply the stricter applicable control outcome and resolve legal conflicts through Legal. Changing ownership, entering a new sector, acquiring a business, or expanding geography must trigger a governance review.

P20 Classification of inputs outputs and derived information

Data classification is a mandatory routing control throughout the AI lifecycle. The data owner must classify source records, datasets, prompts, attachments, retrieved context, features, embeddings, fine-tuned artifacts where relevant, outputs, decision records, telemetry, and retained evidence. A tool's approved status does not authorize every information class. Each use must state its permitted input classes, expected output classes, authorized recipients, storage locations, retention, and business purpose before execution.

Use the Company's established taxonomy, mapped to the following reference classes. Personal information, sensitive personal information, regulated records, licensed content, privileged material, and third-party restrictions are additional flags rather than interchangeable confidentiality labels. A publicly accessible record may still carry privacy, license, or purpose restrictions.

Unclassified information must be quarantined and treated as D3 pending classification; this treatment does not grant permission to use it. The data owner must document the classification rationale and rights. Privacy determines applicable personal-data obligations, and Legal determines privilege, licensing, sector, and contractual conditions. Their determinations must be linked to the use case record.

The effective handling class is the most restrictive class among source information actually accessible to the workflow, assembled input and context, expected or detected output, and linked evidence. Account for data the system can retrieve or disclose, not only what the user types. The internal approval tier is then the strictest applicable data, decision, autonomy, exposure, and legal requirement. Public data does not make an employment or safety decision low-risk.

Outputs inherit source and context restrictions by default. Outputs may require a higher class when combination, inference, personal identification, or a business decision creates new sensitivity. Redaction, summarization, embeddings, synthetic generation, or aggregation must not automatically downgrade information. A documented declassification decision requires data-owner authorization, Privacy or Legal review when relevant, transformation and disclosure tests, and a specific release scope. Output approval must identify the intended recipient and permitted onward use.

Classification and permissions must be rechecked when the purpose, population, dataset, retrieval index, model, feature, integration, output recipient, or transaction authority changes. Classification must propagate to derivative assets and evidence. Label propagation supports the decision; enforcement must occur in applications, storage, retrieval, access, and outbound channels. Input and output screening must be tested for the information types, modalities, languages, and attack scenarios in scope.

Figure P20A Data classification and release decision

flowchart TD
  A[Identify sources and permitted purpose] --> B{Rights and classification established}
  B -->|No| Q[Quarantine and resolve]
  B -->|Yes| C[Classify input context and expected output]
  C --> D[Apply privacy legal and action risk flags]
  D --> E[Choose strictest handling and approval route]
  E --> F[Use approved stage environment]
  F --> G[Inspect output and inherited restrictions]
  G --> H{Recipient and release authorized}
  H -->|No| X[Block release and record reason]
  H -->|Yes| Y[Release and record evidence]

Figure P20B Information sensitivity across an AI workflow

The illustration shows public drafting, confidential contract processing, and sensitive inference. Outputs and evidence retain the relevant restrictions, and inferred information can require a higher class.

P21 Permissions from prototype through production

Each initiative must progress through a recorded lifecycle state: intake, prototype, proof of concept, pilot, production, material change, and retirement. The owner must obtain explicit authorization for each stage, information class, participant group, environment, model configuration, and action boundary. Approval for an earlier stage must not carry forward automatically. A successful demonstration or a small test population does not reduce data obligations.

A prototype tests an idea or interaction, normally with invented, synthetic, or appropriately authorized D0 or D1 information and without live decisions or write access to production. A proof of concept tests technical feasibility against predefined criteria, using a bounded approved dataset and a segregated nonproduction environment. A pilot validates an actual workflow with approved participants and, if authorized, live information, meaningful human review, monitoring, and incident support. Production permits the specifically approved operating scope after readiness and acceptance requirements are met.

Live D2 or D3 information in a prototype or proof of concept requires a documented necessity assessment, data-owner authorization, privacy and legal screening, the appropriate P05 approval route, and data controls equivalent to the sensitivity of the information. The preferred alternative is a validated minimized or synthetic dataset. Real-data use may proceed only after its environment and evidence protections are ready. Prototype and proof-of-concept stages must not issue live consequential decisions or execute consequential production actions.

The data owner approves the dataset and transformations; the business owner approves the purpose and outcomes; the technical owner attests to environment and operational controls. Specialist clearances and independent high-risk challenge remain required under P03 and P05. Every stage decision must record the responsible person, authority, evidence version, rationale, conditions, decision time, expiry or next review, and rejected alternatives where material.

Figure P21A Authorized lifecycle progression

flowchart TD
  I[Intake and classification] --> P[Prototype authorization]
  P --> C[Proof of concept authorization]
  C --> T[Pilot authorization]
  T --> R[Production approval]
  R --> O[Operate and monitor]
  O --> M{Material change or control failure}
  M -->|Yes| S[Restrict suspend and reassess]
  S --> I
  M -->|No| O
  O --> X[Retire revoke archive and delete]

P22 Data stewardship lineage and accountable decisions

Every dataset and derivative asset must have an accountable data owner and an operational steward. The owner authorizes purpose, access, onward use, and retention. The steward maintains classification, quality checks, provenance, refresh, correction, and deletion. The business and technical owners remain accountable for decisions and system operation. Delegation must identify the delegate, authority, duration, and supervision; it must not remove accountability.

Maintain a data passport describing source, acquisition method, rights, purpose, subjects and jurisdictions, collection or consent conditions where applicable, classification and flags, transformations, quality limitations, access, retention, and approved AI uses. Record versions and relationship identifiers connecting source records to transformations, datasets, features, retrieval chunks, model or configuration versions, actual outputs, decisions, and downstream actions. For training, retain the approved data manifest, splits, transformation code, hyperparameters, artifacts, and relevant environment details.

Lineage must cover manual editing, annotation, external data purchases, preprocessing, masking, embedding, retrieval, export, human corrections, and supplier handoffs. Record the responsible actor and timestamp for each activity. Automated lineage gaps must have an explicit manual record and verification; a catalog entry alone does not establish complete runtime lineage. W3C PROV distinguishes entities, activities, and agents and provides a useful vocabulary for these relationships. W3C PROV Overview.

Source corrections, withdrawn authorization, or required erasure must trigger impact analysis across derived datasets, indexes, caches, features, models, and records. Privacy, Legal, and the technical owner must determine required measures; deleting a source file alone is not sufficient. Where removal from a trained model is required, assess retraining, validated unlearning where feasible, or withdrawal of the affected model rather than promise an unsupported deletion capability.

Every material classification, access, stage, validation, release, exception, incident, restart, and retirement decision must enter the decision register. Record what was decided, by whom, under which authority and policy version, using which evidence, with what conditions and residual risk. Store dissent or unresolved specialist findings and their disposition. Model-generated explanations must not substitute for documented accountable decisions.

Figure P22A Lineage links information to responsibility

flowchart TD
  S[Source and rights record] --> T[Versioned transformation]
  T --> D[Approved dataset snapshot]
  D --> C[Features or retrieved context]
  C --> M[Model and configuration version]
  M --> O[Actual output record]
  O --> J[Human or rule based decision]
  J --> A[Authorized downstream action]
  W[Owners actors and time records] -.-> T
  W -.-> J
  W -.-> A

P23 Complete transaction evidence and reproducibility

Every AI transaction in every stage must have an auditable record. A transaction includes an inference request, a retrieval operation used to assemble context, an agent tool operation, an approval or override, a downstream action, and any retry, refusal, failure, or cancellation. Link constituent events to a common workflow and transaction identifier. The technical owner must ensure coverage of UI, API, batch, embedded, and agent pathways; operational traces sampled for performance are not a complete audit journal.

Use a durable transaction journal and a separately protected evidence store. Record an intent before sending a request or permitting an action, the actual outcome when known, and any unresolved or ambiguous outcome. Where durable recording is unavailable, new work must stop or remain queued without execution. Reconcile partial failures using provider request IDs, recipient records, and idempotency keys where supported. Never label an ambiguous action successful, failed, or safe to retry without supporting evidence. Never promise exactly-once behavior across services without validated receiving-system guarantees.

Retain actual prompts, permitted context, responses, and material action payloads in the controlled evidence store, or retain authorized references to immutable versions sufficient to reconstruct them. The record must distinguish actual historical content from later regenerated content. Protect identifiers, hashes, and pointers when they themselves expose sensitive or linkable information. Where appropriate, use keyed integrity values rather than exposing guessable hashes of sensitive identifiers. Never retain credentials or require undisclosed model chain-of-thought; record observable inputs, outputs, applicable rules, source evidence, human judgments, and authorized actions.

Data owners, Privacy, Legal, and Records must approve the content, purpose, access, retention period, legal hold, and deletion rules for each evidence class. Complete recording does not mean unlimited retention or broad visibility of raw payloads. Where law or an unwaived contract prevents evidence necessary for a material or regulated use, restrict or reject that use. After lawful deletion, retain only permitted metadata and clearly mark any resulting loss of replay capability. Immutable storage settings must not conflict with required deletion; approve the retention design before applying an irreversible lock.

Each use must declare its assurance level. Historical reconstruction means recovering the actual transaction, evidence, controls, and accountable decision during the approved retention period. Controlled replay means rerunning retained inputs and configuration in an isolated environment, with variation recorded and actions disabled. Validated deterministic reproduction means demonstrating a defined identical result for a controlled workload and environment. It must not be claimed for a generative service merely because a seed or temperature is fixed. Microsoft documents that determinism is not guaranteed even with identical seed and system fingerprint. Microsoft reproducible output documentation.

Historical reconstruction is mandatory. Controlled replay must be available where required for the use's validation, impact, or legal obligations and must record supplier and artifact limitations. Deterministic reproduction is conditional on demonstrated technical capability and an appropriate acceptance test. If an obligation requires it and the system cannot deliver it, do not deploy that use. Explainability must reflect real evidence and the decision process; a plausible explanation written afterwards is not proof of causation.

Figure P23A Audit evidence with separated access

flowchart TD
  W[Every workflow event] --> J[Durable unsampled journal]
  W --> V[Encrypted classified evidence store]
  J --> L[Integrity links and retention rules]
  V --> L
  A[Authorized investigator] --> C[Access and purpose check]
  C --> J
  C --> V
  L --> H[Historical reconstruction]
  L --> R[Isolated replay when supported]
  R --> N[No live tools payments or publication]

P24 Infrastructure and application control requirements

Each stage must document the infrastructure, application classes, service owners, regions, suppliers, product editions, configurations, integrations, and evidence needed to meet its controls. The reference architecture must cover identity, network boundaries, authorized data stores, catalog and lineage, classification and loss prevention, model access, retrieval, evaluation, release controls, transaction evidence, security monitoring, and incident response. G30 provides a dated provider shortlist; brands are not mandatory policy choices.

Prototype, proof-of-concept, pilot, and production environments must be separated by appropriate accounts or projects, identities, permissions, datasets, secrets, network rules, and release authority. Production data must not be copied into a lower-control environment merely because it is labeled a test. D2 and D3 environments must enforce approved network destinations and private connectivity where required by the security assessment, restricted administrative access, encryption with approved key management, training-use restrictions, and controlled support access.

Policy checks must operate before data leaves an approved boundary and before outputs or tool actions are released. A provider content filter cannot replace identity, purpose, retrieval permissions, transaction authorization, or evidence retention. A tracing tool cannot substitute for a complete durable audit journal. The architecture must identify which control is native, configured, custom, or provided by another system and show evidence that it works end to end.

Supplier and infrastructure approval must verify supported APIs, modalities, regions, audit exports, data use, deletion, version control, dependency notice, restoration, and portability. Feature availability and safeguards must be checked for the exact deployed service rather than inferred from a general product description. Changes that weaken coverage must block the affected release or operation pending reassessment.

P25 Assurance of data routing and transaction controls

Before each stage is authorized, test classification propagation, unauthorized information submission, cross-user retrieval, output sensitivity, unauthorized recipients, prompt injection, prohibited tool access, evidence integrity, and the journal's behavior during failure. Tests must cover refusals, streaming and batch requests where used, retries, interrupted actions, cancellations, and supplier updates. High-risk use requires independent challenge of the evidence and operating boundaries.

The technical owner must reconcile executed requests and actions against recorded intents and outcomes. The baseline target is complete event coverage; sampling must not be used to claim full auditability. Unexplained missing transactions, failed integrity checks, and unresolved consequential actions are control failures requiring investigation and restriction of affected activity. Report coverage gaps separately from quality evaluation samples.

Demonstrate historical reconstruction for selected transactions from each relevant stage and information class, including a failure and a human override. Test controlled replay without live side effects where required. Record the tested retention window, reconstruction time, unresolved dependencies, and supplier limits. The business owner and relevant specialists must approve the evidence design; Internal Audit independently assesses compliance rather than operating the control.

These controls extend P07 through P15 and apply alongside P17 through P19. A small company may use fewer products and qualified external support; it must still demonstrate the required data boundaries and transaction records. The Company must approve the classification mapping, retention design, accountable owners, and any permitted implementation transition before adopting this version.

Reference framework and sources

The following public references inform the framework. The policy requirements, internal tiers, approval routes, and numerical targets are Company baseline proposals; they are not quotations from these sources or claims of certification or legal compliance. Legal must maintain current applicability and effective dates for each operating jurisdiction.

NIST AI Risk Management Framework 1.0 provides voluntary risk management functions described as Govern, Map, Measure, and Manage. Policy accountability, use case assessment, evaluation, and lifecycle oversight follow these broad functions.

NIST Generative Artificial Intelligence Profile identifies risks specific to generative AI. The policy addresses erroneous content, information handling, misuse, human reliance, and supply-chain concerns through original control requirements.

ISO IEC 42001 public overview describes an AI management system standard. This document adopts a management-cycle approach; no clause-by-clause conformance or certification claim is made, and the copyrighted standard is not reproduced.

European Commission AI Act overview is a reference for EU scope, regulatory categories, and phased application. Legal must verify the binding text, amendments, obligations, and effective dates for the Company's specific role and uses.

CISA and UK NCSC secure AI development guidance supports lifecycle security assessment. Joint secure deployment guidance is particularly relevant to systems the Company deploys and operates itself.

ICO governance and accountability toolkit supports privacy review and documented accountability. EEOC artificial intelligence and ADA resources support specialist review of employment-related AI and accessibility.

Gartner AI governance guidance supports attention to discovery and controls during operation. McKinsey AI trust research informs accountability and agent oversight. BCG responsible AI guidance informs risk-based review and lifecycle evaluation. Bain adoption guidance informs employee readiness and sponsored rollout. These public management perspectives supplement the standards and regulator references; they do not establish mandatory legal requirements.

Sources reviewed on 6 October 2026. These references support the framework and do not constitute a complete register of applicable law.

Additional data security provenance and evidence references

NIST SP 800 218A addresses secure development practices for generative AI and foundation models. NIST SP 800 53 Revision 5 provides a security and privacy control catalog, including audit-related control families. Their requirements require use-specific selection and tailoring; this policy is not a claim of full conformance.

W3C PROV Overview supports the entities activities and agents vocabulary for provenance. OpenTelemetry GenAI conventions support interoperable telemetry; the Company must still implement complete business decision and transaction evidence.

Microsoft reproducible output documentation explains why fixed seeds and fingerprints do not guarantee deterministic output. AWS invocation logging describes supported capture configuration and limitations. Google Bucket Lock describes immutable retention behavior. These implementation examples support the evidence and retention design; they do not make a particular vendor mandatory.