AI System Acceptable Use Policy Template fourteen sections for the AI tool catalogue, prompt content rules, output validation, AI agents, AI coding assistants, AI in workforce decisions, and enforcement
A free, copy-ready AI system acceptable use policy template. Fourteen structured sections covering policy charter and AI governance authority, scope and definitions and AI system classification, AI posture statement, approved AI tool catalogue with per-tool data class rules, prompt content rules and forbidden input categories, output validation with human-in-the-loop and the no-blind-trust principle, training data and fine-tuning and retention boundaries, AI agents and autonomous tool-use rules, AI-assisted code generation and developer workflow rules, AI in workforce decisions and hiring and performance, AI procurement and third-party-vendor AI and customer-side AI features, AI-related security findings and incident reporting, monitoring of AI tool use and privacy boundary and lawful basis, and enforcement and sanctions and exceptions and document control. Aligned with ISO/IEC 42001 Clause 5.2 and Annex A.2 and A.3 and A.5 and A.6, NIST AI RMF GOVERN and MANAGE functions, EU AI Act Article 4 and 6 and 14 and 26 and 50, NIST CSF 2.0 GV.PO and GV.RR and PR.AT, NIST SP 800-37 Steps 1 and 2, NIST SP 800-53 PL-4 and AT-2 and AC-20 and CM-7 and SI-12, ISO 27001 Annex A 5.10 and A 5.34 and A 8.10 and A 8.12, SOC 2 CC1.4 and CC2.2 and CC6.1, OWASP LLM Top 10, OWASP AISVS, GDPR Article 22 and 32 and 35, US state AI hiring laws (NYC Local Law 144, Illinois AI Video Interview Act, California, Maryland, Connecticut evolving rules).
Carry the AI AUP evidence chain on one workspace rather than across folders
SecPortal pairs the signed AI AUP to the workspace document record so the quarterly catalogue review, the annual policy reaffirmation, the ten amendment triggers, the framework mapping, and the security findings that touch AI-relevant misuse all live on one workspace with named-actor activity log. Free plan available.
No credit card required. Free plan available forever.
Fourteen sections that turn the AI tool landscape into observable user behaviour
An AI system acceptable use policy (AI AUP) is the topic-specific rule book that governs how the workforce interacts with generative AI tools, machine-learning systems, AI agents, and AI features embedded inside SaaS products. It sits one level below the wider acceptable use policy template and one level above the named approved AI tool catalogue. Most existing AUPs predate workforce adoption of generative AI tools; the AI section needs faster amendment cadence, finer-grained data class rules per tool, and a defensible audit chain that ISO/IEC 42001, NIST AI RMF, EU AI Act, OWASP LLM Top 10, and OWASP AISVS all read against.
The fourteen sections below cover the durable shape of an AI use policy from organisational posture through approved tool catalogue, prompt content rules, output validation, training data, AI agents, AI-assisted code generation, AI in workforce decisions, AI procurement, AI incident reporting, monitoring with privacy boundary, and the enforcement chain. Pair the AI AUP with the data classification policy template for the data class taxonomy the per-tool rules read against, the secrets management policy template for the credential rules the AI tool prompt content rules cross-reference, the data protection impact assessment template for the DPIA required by AI tools that process personal data, and the SBOM policy template for the AI-assisted code IP and licence discipline. Copy the section that fits your stage and paste the rest as the AI programme matures.
Copy the full AI AUP template (all fourteen sections) as one block.
1. Policy charter and AI governance authority
Open the AI system AUP with the firm intent and the named AI governance authority. The reviewer reading the first paragraph should know who publishes the rule, which AI use cases it covers, which workforce populations it binds, who signed it, and when it went into effect. ISO/IEC 42001 Clause 5.2 expects a documented AI policy with named authority. NIST AI RMF GOVERN function expects a published AI policy hierarchy. EU AI Act Article 4 expects AI literacy provisions for the workforce. The AI system AUP sits below the general acceptable use policy and above the named approved AI tool catalogue.
Policy title: AI System Acceptable Use Policy
Policy identifier: {{POLICY_IDENTIFIER}}
Policy version: {{POLICY_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Last review date: {{LAST_REVIEW_DATE}}
Next scheduled review date: {{NEXT_REVIEW_DATE}}
Document classification (per the data classification policy): {{DOCUMENT_CLASSIFICATION}}
Retention period (per the audit evidence retention policy): {{RETENTION_PERIOD}}
Policy purpose paragraph (one paragraph, plain language, business-specific):
{{ORGANISATION_LEGAL_NAME}} publishes this AI System Acceptable Use Policy to {{PLAIN_LANGUAGE_PURPOSE_PARAGRAPH}}. The policy is the workforce-facing rule book that turns the organisation's posture on generative AI, machine learning, and AI agents into observable user behaviour. Every authorised user who passes data to an AI tool on behalf of the organisation, or who consumes the output of an AI tool inside an organisational workflow, is bound by this policy as a condition of access.
Policy objectives (the rule the audit reads against):
- Define the boundary of permitted and prohibited AI tool use by the workforce.
- Protect customer-entrusted data, regulated data, source code, security findings, credentials, and intellectual property from leakage to AI tools that have not been approved for the data class.
- Reduce the human-factor surface that contributes to AI-related security incidents (prompt injection, secret leakage to AI tools, indirect prompt injection through RAG pipelines, excessive agency through autonomous agents, model extraction, output blind trust).
- Provide a defensible contractual basis for the organisation to challenge misuse, suspend access, or retire approved tools when the AI risk picture changes.
- Evidence compliance with the framework controls and regulatory expectations that name AI use, AI policy, or AI workforce behaviour as required controls.
Policy hierarchy:
- Parent policies referenced by this policy:
- Acceptable Use Policy (the workforce-wide acceptable use rule the AI section of this document extends).
- Information Security Policy / Information Security Management System (the organisation-wide security expectation).
- AI and Machine-Learning Management Policy (where the organisation has separated the AI management system from the security management system under ISO/IEC 42001).
- Sibling policies and the boundary against each:
- Data Classification Policy (the AI policy reads data classes from the classification policy; the classification policy does not name AI tools).
- Secrets Management Policy (credentials are forbidden from AI prompts under this policy; the secrets policy carries the credential lifecycle).
- Cryptographic Key Management Policy (key handling rules apply to AI workloads through this policy).
- Vulnerability Management Policy (AI-related findings flow through the wider VM lifecycle).
- Vulnerability Disclosure Policy (security researchers who report AI tool issues use the named channel).
- Bring-Your-Own-Device Policy (personal device rules apply to AI tools on personal devices).
- Privacy and Personal Data Handling Policy (personal data rules apply to AI tools that process personal data).
- Records Management and Retention Policy (AI tool conversation logs are records).
- Procurement Policy (AI tools are procured through the named gate before they enter the approved catalogue).
- Approved AI Tool Catalogue (the workforce-facing list this policy reads against): {{APPROVED_AI_TOOL_CATALOGUE_REFERENCE}}.
Frameworks the policy evidences (map your scope into Section 14):
- ISO/IEC 42001:2023 Clause 5.2 (AI policy), Annex A.2 (policies related to AI), Annex A.3 (internal organisation), Annex A.5 (resources for AI systems), Annex A.6 (AI system life cycle).
- NIST AI RMF 1.0 GOVERN function (GOVERN 1, GOVERN 2, GOVERN 3, GOVERN 4), MANAGE function (MANAGE 1, MANAGE 2, MANAGE 3, MANAGE 4).
- EU AI Act Article 4 (AI literacy), Article 6 and Annex III (high-risk AI system classification rules where the organisation deploys high-risk systems), Article 14 (human oversight), Article 26 (deployer obligations), Article 50 (transparency obligations).
- US state AI hiring laws (NYC Local Law 144 on automated employment decision tools, Illinois Artificial Intelligence Video Interview Act, California, Maryland, and Connecticut evolving rules where applicable).
- NIST CSF 2.0 GV.PO (policy and procedures), GV.RR (roles, responsibilities, and authorities), PR.AT (awareness and training).
- NIST SP 800-37 Risk Management Framework Step 1 and Step 2 (assessment authorisation boundary).
- NIST SP 800-53 Rev. 5 PL-4 (rules of behavior), AT-2 (literacy training and awareness), AT-3 (role-based training), AC-20 (use of external systems), CM-7 (least functionality), SI-12 (information management and retention).
- ISO/IEC 27001:2022 Annex A 5.10 (acceptable use of information and other associated assets), A 5.34 (privacy and protection of PII), A 8.10 (information deletion), A 8.12 (data leakage prevention).
- SOC 2 Trust Services Criteria CC1.4, CC2.2, CC6.1, CC6.6.
- OWASP LLM Top 10 (the operating mapping for the prompt content rules, the output validation rules, the AI agent rules).
- OWASP AISVS (the verification baseline the AI workloads are evaluated against).
- GDPR Article 22 (automated individual decision-making, including profiling), Article 32 (security of processing), Article 35 (data protection impact assessments).
- Internal policy: {{INTERNAL_POLICY_REFERENCES}}
Policy custodian (the role that maintains the document between sign-offs):
- Role: {{CUSTODIAN_ROLE}} (typically AI Governance Owner, Chief AI Officer, or Head of Data Science where these exist; otherwise the CISO carries the custodian role).
- Named person at time of publication: {{CUSTODIAN_NAME}}.
Joint owners and approving signatories:
- AI Governance Owner or Head of Data Science (AI-specific technical content owner): {{AI_OWNER_NAME_AND_DATE}}.
- Chief Information Security Officer (security content owner): {{CISO_NAME_AND_DATE}}.
- Chief People Officer or HR Director (workforce-conduct content owner): {{HR_OWNER_NAME_AND_DATE}}.
- Data Protection Officer where applicable (privacy and EU AI Act dimensions): {{DPO_NAME_AND_DATE}}.
- General Counsel or Chief Legal Officer (employment-law and regulatory enforceability owner): {{LEGAL_OWNER_NAME_AND_DATE}}.
- Executive sponsor named in the AI charter or security charter (overall accountable signatory): {{EXECUTIVE_SPONSOR_NAME_AND_DATE}}.
Consultation parties (where applicable):
- AI governance committee or AI ethics committee: {{AI_GOVERNANCE_COMMITTEE_NAME_AND_CONSULTATION_DATE}}.
- Works council or staff representative body (EU operations): {{WORKS_COUNCIL_NAME_AND_CONSULTATION_DATE}}.
- Compliance Officer (regulated sectors): {{COMPLIANCE_OFFICER_NAME_AND_CONSULTATION_DATE}}.
- Union representative (where union recognition applies): {{UNION_REPRESENTATIVE_NAME_AND_CONSULTATION_DATE}}.
Version history:
- v1.0 {{V1_EFFECTIVE_DATE}}: Initial AI system AUP issued under sponsor {{V1_SPONSOR_NAME}}. Trigger: programme founding.
- v{{VN_VERSION}} {{VN_EFFECTIVE_DATE}}: {{VN_CHANGE_SUMMARY}}. Trigger: {{VN_TRIGGER}}.
2. Scope, definitions, and AI system classification
Scope is the most contested part of the AI system AUP because AI is a moving target. Name who the policy applies to, which AI systems it covers, which use cases it governs, and which jurisdictions the rules operate inside. Pair the definitions to the EU AI Act categorisation (general-purpose AI model, high-risk AI system, prohibited AI practice) and to the OWASP LLM Top 10 lifecycle categories so the AI section reads cleanly against both frameworks.
In-scope user populations (every individual in these populations is bound by this policy as a condition of access):
- Full-time and part-time permanent employees.
- Fixed-term and seasonal employees.
- Interns, placement students, and apprentices.
- Contractors and contingent workers engaged through any contracting vehicle.
- Agency workers, temporary workers, and seconded staff from group companies.
- Board members and non-executive directors with information system access.
- Advisors, consultants, and external auditors with named accounts.
- Vendor staff, partner staff, and service provider personnel with named accounts on organisational systems.
- Anyone else who receives a named user account, a guest credential, or any other access credential that may interact with an AI tool on behalf of the organisation.
In-scope AI systems (the rules cover every interaction with these systems):
- Generative AI chat assistants (consumer and enterprise editions of ChatGPT, Claude, Gemini, Copilot, Llama-based assistants, Mistral-based assistants, and any other tool of comparable shape).
- AI coding assistants (GitHub Copilot, Cursor, Codeium, Tabnine, Aider, JetBrains AI Assistant, and any other tool of comparable shape).
- AI features embedded inside SaaS products the workforce uses (CRM AI assistants, helpdesk AI assistants, document AI features, presentation AI features, design AI features, code review AI features, scheduling AI features).
- AI agents and autonomous tool-use runtimes that take actions on the workforce member's behalf (browser-using agents, code-writing agents, RPA agents augmented by LLMs, customer-service agents, sales-outbound agents, marketing-content agents).
- Retrieval-augmented generation (RAG) workloads that ingest organisational documents and serve generated answers back to the workforce.
- Custom fine-tuned models the organisation has built on top of vendor base models.
- AI services the organisation operates inside its own product that customers consume (in scope for the workforce that operates the service; the customer-facing transparency obligations are named in Section 11).
- Embedded AI in development tooling (LLM-augmented IDEs, AI-assisted debugging, AI-assisted test generation, AI-assisted code review).
- AI tools that operate on voice, video, image, or biometric data (voice transcription tools, video summarisation tools, image generation tools, identity verification tools, sentiment analysis tools).
Out-of-scope or modified-scope items:
- Personal use of personal AI accounts on personal devices outside any work context: out of scope.
- Search engines with AI-augmented summaries (the underlying use is search, not AI generation): in scope only where the user copies a search-AI summary into an organisational deliverable.
- Spell-check, grammar-check, and predictive-text features built into operating systems: out of scope unless the feature transmits content to a cloud service.
- AI features that are turned off by default and that the workforce has not enabled: out of scope.
Jurisdictional applicability:
- Primary jurisdiction (the law of the contract): {{PRIMARY_JURISDICTION}}.
- Operating jurisdictions where the workforce is located: {{LIST_OF_OPERATING_JURISDICTIONS}}.
- AI-specific jurisdictions with named rules the policy operates against: {{LIST_OF_AI_REGULATED_JURISDICTIONS_INCLUDING_EU_AND_NY_AND_IL_AND_CA_AND_MD_AND_CT}}.
- Where multiple jurisdictions apply to a single user, the strictest applicable rule is the binding rule for that user.
AI system classification (the named classes the policy distinguishes):
- General-purpose AI tool (the prompt-and-respond chat tool with broad use cases): the baseline rules in Sections 4, 5, 6, and 8 apply.
- AI coding assistant (the tool that writes code on the developer's behalf): the baseline rules plus the code-generation rules in Section 9 apply.
- AI agent or autonomous tool-use runtime (the system that takes stateful actions without prompt-by-prompt confirmation): the baseline rules plus the agent rules in Section 8 apply.
- High-risk AI system as classified under EU AI Act Annex III (employment decisions, credit decisions, education access, law enforcement, biometric categorisation, critical infrastructure management): the baseline rules plus the high-risk rules in Section 10 apply with the named human oversight obligations.
- Prohibited AI practice as named under EU AI Act Article 5 (social scoring, real-time biometric categorisation in public spaces for law enforcement except under named exceptions, exploitation of vulnerabilities, manipulation through subliminal techniques): not used by the workforce on any data, for any use case, under any condition.
- AI system the organisation provides to customers as part of its own product: the baseline plus the customer-side rules in Section 11 apply with the named transparency and consent obligations.
User population modifiers (named user populations bound by additional rules):
- AI tool operators (workforce members who configure, deploy, or operate AI tools for other workforce members): bound by the additional rules in the AI Operator addendum.
- Developers using AI coding assistants: bound by the additional rules in Section 9 and the secure code review process.
- Workforce members making AI-assisted workforce decisions (hiring, performance, disciplinary, termination): bound by the additional rules in Section 10.
- Workforce members building customer-facing AI features: bound by the additional rules in Section 11 and the named transparency obligations.
3. AI posture statement and organisational position
The posture section names the explicit organisational position on generative AI. Pick one of four postures, name the reason, and operationalise the rest of the policy against the choice. Workforce members and auditors read the posture first and use it as the lens for every other section.
Organisation posture on generative AI (choose one and name the reason):
- Posture choice: {{AI_POSTURE_ONE_OF_PERMITTED_BROADLY_OR_PERMITTED_WITH_RESTRICTIONS_OR_PERMITTED_LOW_RISK_ONLY_OR_FORBIDDEN}}.
- Posture rationale: {{ONE_PARAGRAPH_RATIONALE_FOR_THE_POSTURE_INCLUDING_BUSINESS_DRIVERS_RISK_DRIVERS_AND_REGULATORY_DRIVERS}}.
Posture A (permitted broadly): the organisation has reviewed the AI tool landscape, holds enterprise contracts with the named approved tools, runs the named training programme, and permits broad use of approved tools across the workforce with the named data class rules. The rest of the policy operationalises the broad permission with rules per data class, per tool, and per use case.
Posture B (permitted with restrictions): the organisation permits AI tool use for named populations (developers, content creators, business analysts), with named tools, with named data classes, with named approval gates for other populations. The rest of the policy names the restrictions and the exception path for restricted populations.
Posture C (permitted for low-risk classes only): the organisation permits AI tool use only with Public-class data and only with named tools that have been reviewed for low-risk use. The rest of the policy names the low-risk boundary and the named exception path for any use that crosses the boundary.
Posture D (forbidden): the organisation does not permit any AI tool use by the workforce on any organisational data or for any organisational purpose. The rest of the policy names the forbidden boundary, the named exception path for time-limited use cases, and the workforce-facing reporting channel for shadow AI use.
Standing exceptions to the posture (named populations or use cases that operate under a different rule):
- Named research populations under a documented research exception: {{RESEARCH_EXCEPTION_DETAILS}}.
- Named board-level or strategy populations under a documented exception: {{STRATEGY_EXCEPTION_DETAILS}}.
- Named regulated populations under a stricter rule than the baseline: {{REGULATED_POPULATION_DETAILS}}.
Standing prohibitions regardless of posture:
- AI tools that fall under EU AI Act Article 5 prohibited AI practices are not used on any data, for any use case, under any condition.
- Personal AI accounts on personal AI tools are not used to process any organisational data class above Public.
- AI tools that train on user prompts by default are not used with any data class above Public unless the organisation has contracted for a no-training commitment in writing.
- AI tools that do not provide an audit log capability are not used with data classes above Internal.
- AI tools that do not provide single sign-on or named authentication integration are not used for any work that affects multiple workforce members.
Communications cadence on the posture:
- The posture is communicated to the workforce at onboarding through the AI section of the security awareness training.
- The posture is reaffirmed at the annual security awareness training cycle.
- Posture changes (a move from Posture B to Posture A on the workforce-wide cadence, or a temporary tightening to Posture C during an active AI incident) are communicated through the named workforce channel within {{POSTURE_CHANGE_COMMUNICATION_WINDOW_DAYS}} days.
4. Approved AI tool catalogue and per-tool data class rules
The approved tool catalogue is the workforce-facing list of AI tools the organisation has reviewed, contracted with, and integrated with the security baseline. Each tool entry needs to be specific enough that a workforce member can read the entry and know what data they may pass to the tool and what the named owner is for questions.
Catalogue structure (the named fields per tool):
- Tool identifier: vendor name, product name, product edition (enterprise vs consumer), and contract identifier.
- Named procurement owner: the role and named person who owns the relationship with the vendor.
- Authentication path: single sign-on integration name, the named identity provider, the named entitlement group, and the conditional access policy that gates access.
- Data classes permitted: the Public, Internal, Confidential, or Restricted classes the workforce may pass to the tool with named conditions per class.
- Data classes forbidden: the classes the workforce may not pass to the tool under any condition.
- Training commitment: contractual statement on whether the vendor trains on user prompts (no-training, opt-out-training, train-by-default-with-no-opt-out).
- Data residency commitment: contractual statement on where prompt and response data is processed and stored.
- Data retention by vendor: contractual statement on how long the vendor retains prompt and response data.
- Subprocessor list: the vendor's named subprocessors and their data residency.
- Confidentiality commitment: contractual statement on confidentiality of prompt data.
- Audit log capability: whether the tool provides workspace-level audit logs of who accessed the tool, what prompts were submitted, and what outputs were generated.
- Output watermarking or provenance capability: whether the tool provides any provenance signal on AI-generated outputs.
- Named owner for questions: the role and named person workforce members contact with a question about the tool.
- Annual review date: the date the named owner reviews the tool entry for accuracy and continued fit.
- Approval date and approver: the date the tool entered the catalogue and the named person who approved it.
Default catalogue rules:
- Tools used to process Restricted or Regulated data classes must carry a contractual commitment to the regulatory regime that governs the class (GDPR for personal data, PCI DSS for payment card data, HIPAA Business Associate Agreement for protected health information, named sector-specific commitments for regulated financial data).
- Tools used to process Confidential data must carry a no-training contractual commitment, a data residency commitment matching the data class's required residency, and a contractual confidentiality commitment.
- Tools used to process Internal data must carry at minimum a no-training contractual commitment.
- Tools used to process Public data only may use the consumer or free tier of the tool with the named consumer-tier conditions.
Default approved tool list shape (template for an organisation to fill in):
- General-purpose chat assistant for Internal-and-below classes: {{GENERAL_CHAT_TOOL_NAME_AND_EDITION_AND_AUTH_PATH_AND_PERMITTED_CLASSES_AND_TRAINING_COMMITMENT_AND_OWNER}}.
- General-purpose chat assistant for Confidential classes: {{CONFIDENTIAL_CHAT_TOOL_NAME_AND_EDITION_AND_AUTH_PATH_AND_PERMITTED_CLASSES_AND_TRAINING_COMMITMENT_AND_RESIDENCY_AND_OWNER}}.
- AI coding assistant for the development organisation: {{CODE_ASSISTANT_TOOL_NAME_AND_EDITION_AND_AUTH_PATH_AND_PERMITTED_CLASSES_AND_TRAINING_COMMITMENT_AND_OWNER}}.
- AI features embedded in named SaaS products the workforce uses: {{LIST_OF_EMBEDDED_AI_FEATURES_WITH_TOOL_NAME_AND_PARENT_SAAS_AND_PERMITTED_CLASSES}}.
- AI agent or autonomous tool-use runtime where the organisation has approved an agent runtime: {{AGENT_RUNTIME_NAME_AND_PERMITTED_ACTIONS_AND_OWNER}}.
- AI features in voice, video, image, or biometric workloads: {{LIST_OF_AV_TOOLS_WITH_NAME_AND_PERMITTED_CLASSES}}.
Catalogue review cadence:
- The catalogue is reviewed quarterly by the AI governance owner.
- Tool entries are reviewed on the named annual review date for accuracy and continued fit.
- Tool entries are reviewed out-of-cycle on the named amendment triggers in Section 13.
- Workforce members who notice an inaccuracy in the catalogue (a vendor edition change, a contract change, a residency change, a feature change) report the inaccuracy through the named owner.
Forbidden tools (the named tools and tool categories that may not be used on any organisational data class above Public):
- Consumer-tier or free-tier editions of named generative AI tools where the organisation has procured the enterprise edition with a no-training commitment: workforce members use the procured enterprise edition.
- Personal AI accounts logged in through personal identity: forbidden across all data classes above Public.
- AI tools that train on user prompts by default with no opt-out: forbidden for all data classes above Public.
- AI tools that have not been procured through the named gate in Section 11.
- AI tools that violate EU AI Act Article 5 prohibited practices regardless of data class.
Catalogue distribution:
- The catalogue is distributed through the named workforce channel ({{CATALOGUE_DISTRIBUTION_CHANNEL}}) so the workforce can find the current list in the named place.
- Catalogue updates are notified through the named change channel within {{CATALOGUE_CHANGE_NOTIFICATION_WINDOW_DAYS}} days.
5. Prompt content rules and forbidden input categories
The prompt rules section names what may and may not be passed to AI tools through every input channel: the prompt window, the context window, the file upload, the browser extension page-scrape, the screen-capture share, and the voice transcript. Be specific enough that the workforce can apply the rule in real time rather than infer it from principle.
Forbidden inputs (the categories that may not be passed to any AI tool that has not been specifically approved for the category):
- Credentials of any kind: passwords, API keys, OAuth tokens, personal access tokens, TLS keys, SSH keys, MFA seeds, certificate private keys, database connection strings with credentials, environment variable dumps that contain credentials.
- Customer personal data: customer names, contact details, identity numbers, addresses, financial identifiers, health identifiers, employment details, and other directly identifying or directly identifiable data.
- Regulated data classes: personal data under GDPR or equivalent, payment card data under PCI DSS, protected health information under HIPAA, regulated financial data, classified information, export-controlled technical data.
- Source code from production repositories with sensitive business logic: pricing engines, security control implementations, fraud detection logic, proprietary algorithms.
- Security findings, scanner output, vulnerability details with reproduction steps, and exploit code.
- Internal-classification documents (board materials, M&A discussions, draft regulatory filings, draft customer contract terms, salary and compensation data, hiring decisions, performance review content, disciplinary records).
- Medical and health data and minors' personal data under each jurisdiction's rules.
- Customer support transcripts that contain customer-identifying content.
- Customer call recordings, customer email content with customer-identifying content, customer chat transcripts.
Permitted inputs (the categories that may be passed to broadly approved tools):
- Public data: information that has been approved for public release through the named publication-approval workflow.
- Internal-class data that has been reviewed for absence of sensitive content (no credentials, no personal data, no regulated data, no security findings, no compensation data).
Conditional inputs (the categories that may be passed only to specifically approved tools with contractual proof):
- Confidential business data: permitted only with tools that carry a no-training commitment, a named data residency commitment, and a contractual confidentiality commitment.
- Internal-class source code: permitted only with tools that carry a no-training commitment and a contractual confidentiality commitment, and only with the named code assistants.
- Customer support transcripts with named-customer permission: permitted only with the named approved tools and only after the customer has agreed to the AI-assisted handling under the named customer agreement.
Indirect input rules (the channels users may not realise are inputs):
- Browser extensions that read page content: extensions that read pages are restricted to the approved catalogue and may not pass page content to AI tools that have not been approved for the data class of the page.
- Screen-share tools that pass screenshots: screen-share tools that integrate with AI features do not pass screenshots of pages that contain forbidden input categories.
- Voice transcription tools that capture meeting audio: voice transcription is allowed for internal meetings under the named meeting-recording protocol; meetings that discuss forbidden input categories are not transcribed with AI tools.
- AI features embedded in note-taking apps that train on notes: note-taking AI is restricted to the approved catalogue with the named no-training commitment.
- AI features embedded in code review tools that read the diff: code review AI is restricted to the approved catalogue with the named no-training commitment for source code.
Indirect prompt injection rules (where third-party content reaches the LLM through documents, web pages, or files):
- When the workforce member feeds documents, web pages, or files to an AI tool, the content of those inputs becomes part of the prompt to the model.
- Documents or web pages from external sources may contain hostile content designed to override the model's behaviour, exfiltrate other prompts, or trigger unintended tool calls.
- The workforce member treats AI tool outputs that follow document or web ingestion with extra care, especially where the tool has been granted any tool-use capability.
- The named indirect prompt injection failure mode is described on the indirect prompt injection vulnerability page.
- Suspected indirect prompt injection is reported through the AI incident channel in Section 12.
Output rules (how AI tool outputs are treated):
- Outputs are not treated as authoritative; the workforce member is the named decision-maker.
- AI-generated code is reviewed by a human before commit per the rules in Section 9.
- AI-generated communications are reviewed before send.
- AI-assisted research is verified for accuracy and cited as AI-assisted in the deliverable.
- AI-generated decisions on workforce-affecting matters are reviewed by a named human per Section 10.
- Outputs that contain confidential information passed to the tool earlier in the conversation are treated as the same data class.
Hard prohibitions on prompt content regardless of tool approval:
- The workforce member does not pass content to an AI tool that would constitute a prohibited act under the workforce-wide AUP (harassment, discrimination, content that is unlawful in the operating jurisdiction).
- The workforce member does not use an AI tool to evade workplace rules (writing performance reviews of a colleague the workforce member should not be reviewing, generating disciplinary documentation that misrepresents events, generating content that constitutes harassment of another worker).
- The workforce member does not use an AI tool to fabricate evidence, fabricate identity, or fabricate communications attributed to another person.
6. Output validation, human-in-the-loop, and the no-blind-trust principle
AI tool outputs fail in recognisable patterns: hallucination, citation invention, bias amplification, training-data echo, and confident wrongness. The output validation rules name the durable workforce-facing discipline that prevents the failures from reaching production deliverables, customer communications, or workforce decisions. This is the section the OWASP LLM Top 10 Improper Output Handling category reads against.
No-blind-trust principle (the durable workforce expectation):
- AI tool outputs are not treated as authoritative without review.
- The workforce member who consumes the output is the named decision-maker; the AI tool is the named assistant.
- Outputs that influence external communications, customer deliverables, regulatory filings, financial records, security decisions, or workforce decisions are reviewed before use.
Output validation discipline (the named steps for each output category):
- Generated text for external use (customer email, marketing content, public statements): reviewed for accuracy, tone, brand alignment, factual correctness, and named-customer-context alignment before send.
- Generated code: reviewed against the rules in Section 9.
- Generated research output: verified against named primary sources, with citations checked for existence and accuracy (named hallucination check), and with the research cited as AI-assisted in the deliverable.
- Generated workforce decisions or workforce-affecting recommendations: reviewed against the rules in Section 10.
- Generated financial records or regulatory filings: reviewed by a named human qualified to sign off on the record category.
- Generated security analysis or security finding content: reviewed against the underlying scanner output and the named secure code review process.
Citation and hallucination check:
- Outputs that cite sources, statistics, regulations, court cases, technical references, or any other verifiable claim are checked for hallucination before the citation enters a deliverable.
- The check looks for: source existence (the cited source actually exists), source accuracy (the cited source actually says what the AI tool reported), and source recency (the cited source is current rather than outdated).
- Outputs that fail the citation check are not used; the workforce member either reformulates the prompt or uses an alternative research path.
Bias and fairness check (the named check for outputs that affect named populations):
- Outputs that affect named populations (hiring decisions, performance decisions, customer segmentation, content moderation decisions) are reviewed for bias against the named protected categories under each operating jurisdiction.
- Outputs that show a pattern of bias against any named protected category are flagged through the named bias-audit channel.
- Workforce members do not deploy AI tools into workforce-affecting workflows without the named bias audit cadence in Section 10.
Confidential information echo:
- AI tool outputs sometimes echo confidential information passed to the tool earlier in the same conversation; the workforce member treats outputs that contain echoed confidential information as the same data class as the input.
- AI tool outputs sometimes echo confidential information passed to the tool by other users (where the tool trains on user prompts); the workforce member who notices this pattern reports the pattern through the AI incident channel in Section 12.
Drift and regression check:
- AI tool outputs change as the underlying model is updated by the vendor; the workforce member does not assume that a workflow that worked against an earlier model version still works against the current version.
- Material model behaviour changes are an out-of-cycle amendment trigger under Section 13.
Brand and reputational check:
- Outputs that will be attributed to the organisation are reviewed against the brand and tone guidelines.
- Outputs that risk bringing the organisation into disrepute are not used.
Plagiarism and licence check:
- Outputs that may reproduce copyrighted training data are reviewed for licence risk; the workforce member does not present AI-generated work as original work where the work is required to be original (intellectual property creation, examinations, regulatory filings, certain customer deliverables).
OWASP LLM Top 10 mapping:
- LLM05 Improper Output Handling: the output validation discipline above is the workforce-facing response.
- LLM09 Misinformation: the citation and hallucination check is the workforce-facing response.
- LLM01 Prompt Injection: the workforce-facing response is to treat outputs that follow document or web ingestion with extra care, per Section 5.
7. Training data, model fine-tuning, and retention boundaries
The training data section governs how organisational data is or is not used to train, fine-tune, or otherwise persist inside AI models. Cover the workforce-side rules (what the workforce may submit as training data) and the operator-side rules (what the AI operator population may do with training data). Pair to the Data Classification Policy and the Privacy and Personal Data Handling Policy.
Workforce-side training data rules:
- The workforce member does not consent to AI tool training on organisational data by leaving the default training opt-in setting in place when an enterprise tool offers an opt-out.
- The workforce member uses the named enterprise edition with a no-training commitment for any data class above Public.
- The workforce member does not upload labelled or unlabelled datasets to AI tools for fine-tuning purposes without the named operator-side approval in this section.
Operator-side training data rules (the population that builds or fine-tunes models):
- Custom fine-tuning of vendor models on organisational data follows the named operator process: data class review, training data minimisation, named training data owner, named fine-tuning record, named evaluation evidence, named retention period for the training dataset.
- Personal data may not be used to fine-tune a model unless the data subject has consented to the use, the lawful basis is documented, and the named DPIA has been completed.
- Customer data may not be used to fine-tune a model that other customers will benefit from unless the named contractual arrangement permits the cross-customer use.
- Security findings, scanner output, and reproduction steps may not be used to fine-tune a model.
- Source code may be used to fine-tune a model only with the named code-licence review and the named no-leakage commitment in the model evaluation step.
Retention boundaries:
- Prompt history retention at the vendor side: per the vendor contract, with the named retention period in the tool catalogue and the named data subject access path.
- Prompt history retention at the organisational side: per the records retention policy, with the named retention period for the conversation log.
- Fine-tuning dataset retention: per the named operator process, with the named retention period named in the operator addendum.
- Generated output retention: per the records retention policy for the deliverable category the output landed in.
Training data hygiene rules (where the workforce member contributes data that may end up in fine-tuning):
- Workforce members do not include credentials, personal data, regulated data, or security findings in any input that may flow to a training dataset.
- Workforce members consent to the use of feedback signals (thumbs up, thumbs down, edit-after-output) only where the feedback signal is sent to a tool that has been approved for the data class.
Model evaluation evidence (the AI operator population maintains this evidence):
- Model evaluation against named OWASP AISVS verification objectives.
- Model evaluation against named NIST AI RMF MAP and MEASURE outputs.
- Model evaluation against named bias and fairness measures for the operating jurisdictions.
- Model evaluation against named safety evaluations (red-team output, adversarial input library, jailbreak resistance, prompt injection resistance).
- Model evaluation against named privacy attack measures (membership inference, model inversion, training data extraction).
Workforce-facing reporting rules on training data:
- Workforce members who notice that an AI tool appears to have been trained on confidential organisational content report through the AI incident channel in Section 12.
- Workforce members who notice that an AI tool appears to have been trained on customer content or personal data report through the privacy channel and the AI incident channel.
- Workforce members who notice that an AI tool appears to leak training data through a named extraction technique report through the AI incident channel and the security incident channel.
8. AI agents and autonomous tool-use rules
AI agents that take actions on behalf of the workforce member raise novel acceptable-use questions that prompt-only AI tools do not. Cover the approved runtime gate, the human-in-the-loop boundary for stateful or irreversible actions, the excessive-agency principle, the audit log requirement, and the incident response inclusion. Pair to OWASP LLM06 Excessive Agency.
Approved agent runtimes only:
- Autonomous AI agents may only run inside approved runtimes named in the AI tool catalogue.
- Each approved runtime names: operator role, permitted actions, denied actions, named identity for the agent on the workspace, named credential lifecycle for the agent, named audit log path.
- Personal-account autonomous agents (personal AutoGPT-style runtimes, personal LangChain-based agents that the workforce member built on their own time) are not used for any organisational data class above Public.
Human-in-the-loop for stateful or irreversible actions:
- Agents that take stateful or irreversible actions are gated on explicit human confirmation per action class.
- Action classes that require explicit confirmation: send external communications (email, message, SMS, voice call), modify production systems, write to customer-visible records, transfer funds, dispatch invoices, sign documents, file regulatory filings, deploy infrastructure, modify infrastructure access, modify security controls, change user accounts, change user entitlements.
- Action classes that may be performed without per-action confirmation but within a named scope: read-only browsing of internal documents, draft generation that the workforce member reviews before send, internal search of the workspace knowledge base.
Excessive agency boundary (the OWASP LLM06 named pattern):
- Agents are not granted broader access than the workforce member they act for.
- Agents are not granted permanent credentials; agents use named credential lifecycle with named rotation and named scope.
- Agents are not granted production access where the workforce member would not be.
- Agent permissions are scoped to the minimum set the agent needs to complete the named task class.
Agent identity and credential discipline:
- Each agent has a named identity on the workspace distinct from the workforce member operating the agent.
- Agent credentials are stored in the named secrets management system with the named rotation cadence.
- Agent credentials are not embedded in agent prompts or context windows where any third-party content can read them.
- Agent identity events (sign-in, action, error, escalation) are recorded against the agent identity rather than against the operating workforce member, with the workforce member as the named responsible party in the audit log.
Audit log requirement:
- Every agent action is logged with named operator, named agent identity, action class, target, payload summary, outcome, and timestamp.
- The audit log retention follows the records retention policy and is reproducible on demand for incident review and regulator request.
- Agent audit logs are reviewed on the named cadence by the AI governance owner.
Excessive agency quarterly review:
- The AI governance owner reviews the agent permission set quarterly and on every new action class addition.
- The review checks for permission accretion (agents that have gained authority over time), credential staleness, scope drift, and named-task adherence.
- Findings from the review are recorded against the security finding record per the findings management workflow.
Incident response inclusion:
- Agent actions are in scope for the incident response programme.
- The named agent identity is treated as a named user identity in the incident response runbook.
- Incidents involving agents (an agent that took an unauthorised action, an agent that was prompt-injected into an unintended action, an agent that exfiltrated data) are escalated under the named runbook.
Customer-affecting agent rules:
- Agents that interact with customers (customer-service agents, sales-outbound agents, marketing agents) follow the named customer-side transparency obligations in Section 11.
- Customer-affecting agents are identified as agents in the customer interaction (under EU AI Act Article 50 and the named transparency rules of the operating jurisdictions).
Agent runtime decommission:
- Agent runtimes that are no longer in active use are decommissioned through the named procedure: credential rotation, identity disablement, scope removal, audit log retention through the named retention period.
- Agent runtimes that fail the quarterly review are decommissioned or remediated through the named procedure.
9. AI-assisted code generation and developer workflow rules
AI-assisted code generation is a high-volume, high-risk workforce behaviour that needs explicit rules rather than implicit norms. Cover the approved-tools-only rule, the human-review-before-commit rule, the extra-care rule for security primitives, the secret-leakage rule, the AI-assisted citation rule, and the licence and IP discipline. Pair to the Secrets Management Policy, the SBOM Policy, the secure code review process.
Rule 1 (approved tools only):
- AI code assistants are restricted to the approved catalogue with named contractual no-training commitments.
- Personal Copilot accounts, personal Cursor accounts, personal Codeium accounts, personal Tabnine accounts, personal Aider runs, and personal AI chat assistants used for code work are forbidden for any code beyond Public class.
- The approved code assistant is integrated with single sign-on, with the named entitlement group, and with the named conditional access policy.
Rule 2 (human review before commit):
- Every AI-generated commit is reviewed by a human before merge.
- The review verifies: correctness, security primitives correctness, licence compliance, secrets review, dependency review, test coverage, and adherence to the codebase conventions.
- The review record references the AI-assisted origin of the commit.
Rule 3 (security-relevant primitives extra care):
- AI-generated authentication code, encryption code, access control code, cryptographic primitives, input validation, output encoding, session management, password handling, MFA handling, token handling, and authorisation checks get extra review.
- Extra review includes: comparison to the named secure coding standard, review against the named cryptographic baseline, named pairing against the secure code review checklist.
- AI tools have known failure modes around security primitives; the workforce member does not assume the AI tool got the security primitive right.
Rule 4 (no secret leakage to AI):
- Credentials, API keys, OAuth tokens, personal access tokens, SSH keys, TLS keys, MFA seeds, certificate private keys, database connection strings with credentials, environment variable dumps that contain credentials, and customer data are not included in AI prompts or context windows.
- Secrets that have been included in an AI prompt by mistake are rotated through the named secrets management workflow within {{SECRET_ROTATION_AFTER_AI_LEAK_WINDOW_HOURS}} hours.
- The AI incident channel is notified per Section 12.
Rule 5 (AI-assisted citation):
- AI-generated code is identified as AI-assisted in the pull request description for audit trail.
- The named reviewer chain reads against the audit log for AI-assisted commits.
- AI-assisted commits are tagged in the commit metadata where the development workflow supports it.
Rule 6 (licence and IP discipline):
- AI-generated code that mirrors copyrighted training data is treated as a licence finding under the SBOM policy.
- AI-generated code that appears to leak proprietary or third-party content is remediated under the secret scanning remediation workflow.
- AI-generated code that mirrors competitor or third-party code is reviewed for licence and IP risk before merge.
Code review workflow integration:
- The named code review tool integrates with the AI assistant audit log so the reviewer can see whether the diff was AI-assisted.
- Reviewers are trained on the named AI-assisted review pattern so they apply the extra care rule consistently.
- Repositories that handle Restricted or Regulated data classes are flagged in the AI assistant configuration so the assistant does not pass content from those repositories to the vendor by default.
Developer-side workforce rules:
- Developers do not deploy AI tools that have not been approved into their development workflow.
- Developers do not connect AI tools to repositories that have not been authorised for the data class.
- Developers do not connect AI tools to production identity, production credentials, or production data.
Test generation discipline:
- AI-generated tests are reviewed for test value (the test must verify behaviour that matters, not behaviour that the AI invented).
- AI-generated tests are not used to mask coverage gaps; coverage is measured by the named coverage tool.
- AI-generated test data is reviewed for realism, named-customer-context absence, and named regulated-data absence.
Code search and code retrieval discipline:
- AI-assisted code search across multiple repositories follows the same data class rules as the underlying repositories.
- AI-assisted code retrieval from open-source corpora is reviewed for licence and named-IP risk.
- Cross-repository code search through AI tools is logged for audit per the activity-log requirement.
10. AI in workforce decisions, hiring, and performance
AI tools that participate in workforce decisions raise regulatory exposure that prompt-style AI tools do not. Cover the no-autonomous-decisions rule, named-jurisdiction compliance, bias audit cadence, workforce notice, data minimisation, and the named tool authorisation gate. Pair to ISO/IEC 42001, NIST AI RMF, EU AI Act Annex III, and the AI hiring laws of the operating jurisdictions.
Rule 1 (no autonomous workforce decisions):
- Hiring decisions, performance decisions, disciplinary decisions, and termination decisions are not made by AI tools without explicit named human review and a documented decision-maker.
- The named human review is not a rubber-stamp review; the named decision-maker is the named accountable party and reads the underlying evidence rather than reading the AI summary alone.
Rule 2 (named-jurisdiction compliance):
- The rules in the AI hiring laws of the operating jurisdictions are followed:
- EU AI Act Article 6 and Annex III treat AI used in employment as high-risk; the EU AI Act Article 14 human oversight provisions apply.
- NYC Local Law 144 on automated employment decision tools expects bias audits with public summary.
- Illinois Artificial Intelligence Video Interview Act expects notice and explicit consent for AI-analysed video interviews.
- California, Maryland, and Connecticut have evolving rules; the named jurisdictional update is monitored under Section 13 amendment triggers.
- Tools used in workforce decisions are reviewed against the EU AI Act conformity assessment requirements where the deployer responsibilities apply.
Rule 3 (bias audit cadence):
- AI tools used in workforce-affecting decisions are reviewed against the named bias audit cadence.
- Bias audits cover the protected categories named in the operating jurisdiction (sex, race, age, disability, religion, sexual orientation, gender identity, and any other named protected category).
- Bias audit outcomes are documented and available for regulator inspection and customer security review.
Rule 4 (named workforce notice):
- Workforce members and candidates are notified when AI tools participate in a decision that affects them.
- Notice is named (which tool, what data the tool processes, what role the tool plays in the decision, what role the human decision-maker plays).
- Notice carries the named appeal channel (the named human who reviews the decision on appeal, the named timeline for appeal, the named outcome record).
Rule 5 (named data minimisation):
- AI tools used in workforce decisions process only the data necessary for the named decision with the named retention.
- AI tools do not process data beyond the named decision scope (a tool used for hiring decisions does not process unrelated personal data; a tool used for performance review does not process medical data).
Rule 6 (named tool authorisation):
- AI tools used in workforce decisions are authorised through a named exception path.
- The named CHRO, the named CISO, the named DPO where applicable, and the named General Counsel all sign off on the tool before deployment.
- The named DPIA is completed for any AI tool used in workforce decisions that process personal data under GDPR or equivalent.
- The named conformity assessment is completed for any high-risk AI system under EU AI Act Article 6 where applicable.
Rule 7 (workforce member appeal rights):
- Workforce members and candidates may request human review of any decision that the AI tool participated in.
- The human review is conducted by a named human who is qualified to review the underlying evidence.
- The outcome of the human review is documented and provided to the workforce member or candidate within the named timeline.
Prohibitions on AI in workforce contexts:
- AI tools are not used to monitor workforce member productivity through covert means (no covert webcam analysis, no covert mouse-movement analysis used as performance evidence, no covert keystroke analysis used as performance evidence).
- AI tools are not used to predict union membership, political affiliation, religious belief, or other protected categories.
- AI tools are not used to make automated decisions about discipline based on sentiment analysis of communications without the named human review.
- AI tools are not used to score workforce members against each other for ranking or stack-ranking purposes without the named named-human review.
Annual workforce decision AI review:
- The AI governance owner publishes an annual review of AI use in workforce decisions, including the bias audit outcomes, the appeal volume, and the named amendment triggers.
- The review is shared with the workforce in summary form so the workforce can hold the AI use accountable.
11. AI procurement, third-party-vendor AI, and customer-side AI features
The AI procurement section names the gate that controls how new AI tools enter the approved catalogue and how the organisation handles AI features inside third-party SaaS products. Cover the six-check procurement gate, the third-party AI feature rules, and the customer-side AI feature rules. Pair to the named procurement process, the data classification policy, and the framework anchors.
AI procurement gate (the six-check approval before a tool enters the approved catalogue):
- Check 1 (data class fit): the proposed tool names the data classes the workforce would pass through it, the contractual no-training commitment, the data residency commitment, the contractual confidentiality commitment, and the subprocessor list.
- Check 2 (security baseline): the proposed tool meets the security baseline (SSO integration where supported, audit log capability, access control granularity, support contract level, named incident response commitment).
- Check 3 (regulatory fit): the proposed tool fits the regulatory regime the data class operates under (GDPR for personal data, PCI DSS for payment data, HIPAA Business Associate Agreement for protected health information, sector-specific regimes).
- Check 4 (model risk fit): the proposed tool names the underlying model family, the model provenance, the training data position, the safety evaluation evidence, and the named contact for model questions.
- Check 5 (jurisdictional fit): the proposed tool fits the EU AI Act classification for the use case, the AI hiring laws of the operating jurisdictions where applicable, the AI transparency requirements of the operating jurisdictions where applicable.
- Check 6 (named owner and review cadence): the proposed tool names the named owner, the named annual review date, the named amendment trigger if a new use case is added.
Third-party vendor AI features (AI features embedded in SaaS products the workforce uses):
- AI features inside existing SaaS contracts are reviewed through the named amendment trigger when the vendor turns the feature on.
- Workforce members notify the AI governance owner when a SaaS vendor turns on an AI feature the workforce had not been using.
- The AI feature is reviewed for data class fit, training commitment, residency, and audit log capability per the procurement gate.
- The catalogue entry for the parent SaaS product is updated to reflect the AI feature.
Customer-side AI features (AI features the organisation builds into its own product that customers use):
- Customer-facing AI features carry the named transparency obligations under EU AI Act Article 50 (deployer must inform users where they interact with an AI system).
- Customer-facing AI features carry the named consent obligations under the operating jurisdictions.
- Customer-facing AI features carry the named audit log obligations against the named customer agreement.
- Customer-facing AI features are reviewed for the data class fit, the named training commitment to customers, the named human oversight provisions, and the named opt-out path for customers who do not want the AI feature applied.
- Customer-facing AI features that classify, score, or rank customers are reviewed for bias against the protected categories named in the operating jurisdictions.
Vendor due diligence on AI tools (the named questions at procurement):
- What is the underlying model and the model provenance?
- Where does prompt and response data process and what is the data residency commitment?
- Does the tool train on customer prompts and is the no-training commitment contractual?
- What is the retention period for prompt and response data on the vendor side?
- What is the audit log capability and what is the audit log retention?
- What is the incident response commitment when the vendor experiences an AI-relevant security or safety incident?
- What are the named subprocessors and where are they?
- What is the named contact for security and privacy escalation?
- What is the named contact for model behaviour questions?
- What is the renewal cadence and the named amendment trigger when the underlying model or the contractual position changes?
AI tool deprecation and exit:
- Tools that are decommissioned from the catalogue follow the named exit procedure: data return or destruction, prompt history retrieval per the data subject access path, named identity disablement, named credential rotation, audit log retention through the named retention period.
- Workforce members are notified of decommissioned tools through the named change channel.
Forbidden vendor relationships:
- AI tool vendors that have a known training-data-leakage pattern that the organisation cannot remediate through contract are not added to the catalogue.
- AI tool vendors that are subject to sanctions or trade restrictions in the operating jurisdictions are not added to the catalogue.
- AI tool vendors that do not provide a named contact for security and privacy escalation are not added to the catalogue.
12. AI-related security findings and incident reporting
The AI incident reporting section names the workforce-facing entry point for AI-relevant security events. Cover the named event categories, the named reporting channels, the named timeline, and the named non-retaliation commitment. Pair to the incident response plan and the security findings management workflow.
Reportable AI event categories:
- Suspected prompt injection of an AI tool the workforce member is using (the tool appears to follow instructions from external content rather than the workforce member).
- Suspected indirect prompt injection through document, web, or file ingestion (the tool processed a document and the output suggests the document overrode the workforce member's instructions).
- Suspected secret leakage to an AI tool (the workforce member realises a credential, an API key, or other secret was included in a prompt).
- Suspected confidential information leakage to an AI tool (the workforce member realises confidential data was included in a prompt to a tool that has not been approved for the data class).
- Suspected training data leakage from an AI tool (the workforce member notices the tool output contains content that appears to come from confidential organisational documents or from another customer).
- Suspected model extraction attempt (the workforce member or an external party appears to be systematically querying the organisation's customer-facing AI feature to extract the underlying model).
- Suspected hallucination that reached a deliverable (the workforce member notices an AI-generated deliverable contains fabricated citations, fabricated quotes, or fabricated facts that the named review missed).
- Suspected bias output in a workforce-affecting context (the workforce member notices an AI tool output appears to be biased against a protected category).
- Suspected unauthorised agent action (an agent took an action that was not authorised under Section 8).
- Suspected catalogue inaccuracy (the workforce member notices a tool entry in the catalogue is inaccurate).
- Suspected shadow AI use (the workforce member notices another workforce member is using an unapproved AI tool with organisational data).
- Suspected violation of this policy by any person (including the workforce member themselves).
Reporting channels:
- AI security incident: {{AI_INCIDENT_REPORTING_CHANNEL}} (typically a named email address, a named ticket queue, or the security incident channel with the named AI sub-category).
- AI privacy concern: {{AI_PRIVACY_REPORT_CHANNEL}} (typically the Data Protection Officer or the named privacy team).
- AI safety concern (bias output, unintended harm to a named population): {{AI_SAFETY_REPORT_CHANNEL}} (typically the AI governance owner or the AI ethics committee).
- AI tool catalogue inaccuracy: {{AI_CATALOGUE_OWNER_CHANNEL}} (the named catalogue owner).
- AI vendor incident: {{AI_VENDOR_INCIDENT_CHANNEL}} (the named vendor management team).
- Out-of-hours emergency: {{OUT_OF_HOURS_EMERGENCY_CHANNEL}}.
Reporting timeline:
- Suspected secret leakage to an AI tool is reported immediately, within {{SECRET_LEAK_TO_AI_REPORTING_WINDOW_MINUTES}} minutes of discovery, so the credential can be rotated before the prompt history is retrieved by an attacker.
- Suspected confidential information leakage to an AI tool is reported as soon as practicable, and in any case within {{CONFIDENTIAL_LEAK_TO_AI_REPORTING_WINDOW_HOURS}} hours of discovery.
- Suspected prompt injection that resulted in an unauthorised action is reported immediately under the incident response runbook.
- Suspected training data leakage that affects personal data is reported as a personal data incident within the regulatory notification timeline (which can be as tight as 72 hours under GDPR).
- Suspected bias output is reported as soon as practicable so the AI governance owner can review the pattern.
What happens after a report:
- The named team acknowledges the report through the named channel.
- The report is triaged per the incident response procedure with the AI-specific sub-procedure.
- The reporter may be asked for additional information including the prompt content, the output content, the named tool, the named time, and the named workspace identity; the reporter cooperates with the request within the protections of the policy.
- The reporter is updated on the outcome of the report where appropriate.
Non-retaliation commitment:
- Reporting a suspected AI incident, an AI privacy concern, an AI safety concern, or an AI-related policy violation in good faith is encouraged.
- The organisation does not retaliate against any workforce member who reports in good faith, including reports that turn out to be unfounded after investigation.
- Retaliation against a reporter is itself a disciplinary matter and a prohibited act under the workforce-wide acceptable use policy.
Reporting your own mistake:
- If you have made a mistake (passed a credential to an AI tool, passed confidential data to a tool that was not approved, deployed an agent action that was not authorised, missed a hallucination check), report it through the named channel as soon as you realise.
- Self-reporting an honest mistake is treated as a routine response event, not as a disciplinary event.
- Concealing a mistake is treated as a separate and additional violation under the disciplinary procedure.
Customer-side AI incident reporting:
- Customer-affecting AI incidents (a customer-facing AI feature that produced biased output, a customer-facing AI feature that exfiltrated training data, a customer-facing AI feature that took an unauthorised action) are escalated to the named customer incident workflow with the named customer notification timeline.
Regulator-side AI incident reporting:
- Where the incident triggers a regulatory notification requirement (EU AI Act Article 73 for high-risk systems, GDPR Article 33 for personal data breaches, sector-specific cybersecurity notification rules), the General Counsel and the DPO are engaged on the named regulator notification path.
13. Monitoring of AI tool use, privacy boundary, and lawful basis
The monitoring section is the part of the AI system AUP most often challenged by workforce representatives and most often read by the regulator. Balance the organisation's legitimate operational need to monitor AI tool use against the user's privacy expectations and the local jurisdictional rules.
Monitoring scope (what is monitored on AI tool use):
- AI tool access events (sign-in events, conditional access decisions, named tool, named workspace identity).
- AI tool usage telemetry (number of prompts, named tool, named workspace identity).
- AI tool prompt and response content where the tool provides workspace-level audit logs and the audit log is enabled.
- AI tool flagged events (output flagged as policy violation, output flagged for review, jailbreak attempt flagged).
- AI agent action audit logs per Section 8.
- AI-assisted code commit metadata per Section 9.
- AI tool credential events (sign-in, sign-out, credential rotation, credential failure).
Monitoring purposes:
- Information security: detect and respond to AI-relevant security incidents (prompt injection, secret leakage, training data extraction, model extraction).
- AI governance: detect catalogue violations (workforce using tools that have not been approved for the data class), shadow AI use, and unauthorised agent action.
- Operational continuity: capacity and licence management of approved AI tools.
- Legal compliance: respond to legal process, regulator request, lawful access request, named records retention.
- Audit and assurance: produce the audit evidence required by ISO/IEC 42001, NIST AI RMF, EU AI Act, and the named operating frameworks.
Lawful basis:
- Employment contract or contractor agreement: monitoring is named in the contract as a condition of access.
- Legitimate interest: monitoring necessary for the security and operation of the organisation, balanced against the user's rights and freedoms, with the named privacy boundary below.
- Legal obligation: monitoring required by law (records retention regimes, regulator-imposed obligations, sectoral cybersecurity requirements, AI regulatory reporting).
- Consent: in jurisdictions where consent is the lawful basis for specific monitoring categories, consent is captured separately from the AUP acknowledgement.
Privacy boundary (what the organisation does not monitor in the AI context):
- Personal AI accounts on personal AI tools on personal time on personal devices.
- AI tool prompts and responses for use cases that fall within the personal use allowance of the workforce-wide AUP and that do not touch organisational data.
- Trade union and works council communications that pass through AI tools where the workforce member has been transparent about the union or works council nature.
- Whistleblowing communications to internal whistleblowing channels or to designated external channels, even where AI tools are used.
- Workforce member identity attributes that are not relevant to the workplace and that pass through AI tools (sexual orientation, religious belief, political activity, health status), except where the workforce member has opted into a programme that processes the attribute.
Access to monitoring data:
- Named security analysts and security engineers with named work-area assignment.
- Named AI governance owner and AI operations staff for AI governance and operational telemetry.
- Named IT operations staff for AI tool licence and capacity telemetry.
- Named HR staff for monitoring data relevant to an active disciplinary investigation under the named procedure.
- Named legal staff for monitoring data relevant to legal process or legal hold.
- Named privacy staff for monitoring data relevant to a privacy review.
- Access is granted on a need-to-know basis, recorded on the access log, and reviewed periodically.
Retention of monitoring data:
- AI security telemetry: {{AI_SECURITY_TELEMETRY_RETENTION}}.
- AI usage telemetry: {{AI_USAGE_TELEMETRY_RETENTION}}.
- AI prompt and response audit log content where retained at vendor: per the catalogue entry for the tool.
- AI prompt and response audit log content where retained at organisation: {{AI_PROMPT_RESPONSE_AUDIT_LOG_RETENTION}}.
- AI agent action audit logs: {{AI_AGENT_AUDIT_LOG_RETENTION}}.
- AI-assisted code commit metadata: per the records retention policy for source code.
- Beyond the retention windows, monitoring data is disposed under the data disposal procedure or anonymised where the retention serves a continuing operational or regulatory purpose.
User rights:
- Right to know what is monitored (this section discharges that right at the policy level; specific queries are routed to {{AI_MONITORING_QUERY_CHANNEL}}).
- Right to access personal data about you that is processed for monitoring purposes, subject to the lawful exceptions in your jurisdiction (data subject access request through {{DATA_SUBJECT_REQUEST_CHANNEL}}).
- Right to challenge a monitoring-derived decision through the named appeal channel.
- Right to escalate a privacy concern to the Data Protection Officer or to the data protection authority of your jurisdiction.
Jurisdictional variation:
- Where jurisdictional law applies stricter rules (German co-determination, French CNIL guidance, UK Investigatory Powers Act expectations, EU GDPR, US state-level wiretapping rules), the stricter rule applies for users in that jurisdiction.
14. Enforcement, sanctions, exceptions, and document control
The closing section converts the AI AUP into an enforceable rule. Name the enforcement authority, the proportionate sanctions per category of violation, the exception process for users who need a documented departure from a clause, and the document control header that holds the policy together.
Enforcement authority:
- The CISO or Head of Security carries the technical enforcement authority on AI security matters (access revocation on security grounds, conditional access tightening, AI tool blocking on security grounds).
- The AI Governance Owner or Head of Data Science carries the AI-specific enforcement authority on catalogue, posture, and use case matters.
- The HR Director or Chief People Officer carries the workforce enforcement authority (disciplinary action, training requirement, contract action, termination).
- The DPO carries the personal data enforcement authority where the AI violation has a privacy dimension.
- The General Counsel carries the legal enforcement authority (litigation, regulatory notification, criminal referral).
- The Executive Sponsor named in the AI charter or security charter carries the ultimate enforcement authority on policy-wide matters.
Sanctions framework:
- Minor violation (one-off, low-impact, no malicious intent, no recurring pattern; for example, a single use of an unapproved AI tool with Internal-class non-sensitive data): verbal coaching by line manager, training refresher, named record in the user file.
- Moderate violation (impactful, repeated minor pattern, or moderate carelessness; for example, repeated use of unapproved AI tools, a one-off pass of confidential data to a broadly approved tool that did not have the no-training commitment for the data class): written warning under the disciplinary procedure, named training requirement, named account-restriction period.
- Serious violation (significant impact, deliberate boundary-crossing, or recurring moderate pattern; for example, deliberate pass of customer data to a personal AI account, deliberate use of a forbidden tool, deliberate bypass of the catalogue): final written warning under the disciplinary procedure, named account-suspension period, named role reassignment where applicable, named cost recovery where applicable.
- Gross misconduct (deliberate harm, criminal conduct, deliberate concealment, repeated serious pattern; for example, deliberate exfiltration of customer data through AI tools, deliberate fabrication of evidence using AI tools, deliberate manipulation of workforce decisions through AI tools): termination of employment or contract under the disciplinary procedure, civil action where appropriate, criminal referral where appropriate, regulator notification where appropriate.
Investigation discipline:
- Every sanction is preceded by a named investigation under the disciplinary procedure with the named AI-specific investigation sub-procedure.
- The investigation is conducted by a named investigator who is not the line manager of the user under investigation where avoidable.
- The investigation collects evidence under the named evidence-collection rules, including evidence from monitoring data per Section 13.
- The user under investigation has the opportunity to respond to the evidence before a decision is made.
- The decision is made by a named decision-maker who is independent of the investigator.
- The user under investigation has the named appeal channel.
Exception process:
- A user who needs a documented departure from a clause of this policy raises an exception request through {{AI_EXCEPTION_REQUEST_CHANNEL}}.
- The exception request names the clause, the reason for the departure, the proposed alternative control, and the proposed expiry date.
- AI exceptions are approved by the AI Governance Owner and the CISO; high-impact exceptions are escalated to the executive sponsor.
- Exceptions are recorded on the security exception register with named owner, named expiry, and named review cadence.
- Exceptions expire on the named date; renewal requires a fresh review.
Out-of-cycle amendment triggers (the ten named triggers that force an out-of-cycle amendment between annual reviews):
- Trigger 1 (new approved tool added or removed from the catalogue).
- Trigger 2 (new data class rule for an existing tool).
- Trigger 3 (new regulatory expectation in any operating jurisdiction).
- Trigger 4 (new agent runtime or new agent action class).
- Trigger 5 (named AI incident that reveals an unaddressed AUP gap).
- Trigger 6 (new jurisdiction entered through expansion or acquisition).
- Trigger 7 (material model behaviour change at a vendor).
- Trigger 8 (new threat pattern: mass prompt injection, model extraction, training data poisoning, AI-assisted social engineering).
- Trigger 9 (new AI feature in an existing SaaS product the workforce uses).
- Trigger 10 (audit or regulator finding that names the AI AUP as a contributing cause).
Quarterly review cadence:
- The AI governance owner reviews the approved tool catalogue and the data class rules quarterly.
- The quarterly review record is captured on the activity log.
Document control footer:
- Effective date: {{EFFECTIVE_DATE}}.
- Version: {{POLICY_VERSION}}.
- Last review date: {{LAST_REVIEW_DATE}}.
- Next scheduled review date: {{NEXT_REVIEW_DATE}}.
- Owner roles: AI Governance Owner ({{AI_OWNER_NAME}}), CISO ({{CISO_NAME}}), HR Director ({{HR_OWNER_NAME}}), DPO where applicable ({{DPO_NAME}}), General Counsel ({{LEGAL_OWNER_NAME}}).
- Executive sponsor: {{EXECUTIVE_SPONSOR_NAME}}.
- Approved by (sponsor signature and date): {{SPONSOR_SIGNATURE_AND_DATE}}.
- Approved by (AI governance owner signature and date): {{AI_OWNER_SIGNATURE_AND_DATE}}.
- Approved by (CISO signature and date): {{CISO_SIGNATURE_AND_DATE}}.
- Approved by (HR signature and date): {{HR_SIGNATURE_AND_DATE}}.
- Approved by (legal signature and date): {{LEGAL_SIGNATURE_AND_DATE}}.
- Custodian: {{CUSTODIAN_ROLE_AND_NAME}}.
- Document identifier and storage location: {{DOCUMENT_IDENTIFIER_AND_STORAGE_LOCATION}}.
- Acknowledgement record location: {{ACKNOWLEDGEMENT_RECORD_LOCATION}}.
- Retention: per the audit evidence retention policy.
Closing statement:
- This AI System Acceptable Use Policy is the workforce-facing rule book at {{ORGANISATION_LEGAL_NAME}} for how the workforce interacts with generative AI tools, machine-learning systems, AI agents, and AI features inside SaaS products.
- Authorised access to organisational systems is conditioned on the workforce member's acknowledgement of this policy and the workforce-wide acceptable use policy.
- The AI section is reviewed quarterly for catalogue and data class rules; the policy structure is reviewed annually; out-of-cycle amendments follow the ten named triggers.
- Policies, standards, addendums, and operating procedures derive their workforce-facing rules from this policy; where any subordinate document conflicts with this policy, this policy prevails until the subordinate is realigned.
Seven failure modes the AI AUP has to design against
An AI AUP fails the audit read, the workforce read, and the regulator read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the AI AUP so the customisation does not weaken the discipline that makes the policy enforceable.
The AI rules live as a paragraph inside the general AUP
When the AI rules sit as a single paragraph inside the wider acceptable use policy, the rules cannot be amended on the faster cadence the AI tool landscape requires, the approved tool catalogue cannot be operationalised against the rules, and the audit read against ISO/IEC 42001 and NIST AI RMF lacks a named AI policy. The fix is a standalone AI System AUP that sits below the wider AUP and operates on a quarterly catalogue review and a ten-trigger amendment cadence.
The approved tool catalogue is implicit rather than named
When the catalogue is implicit, workforce members assume any tool with an enterprise sticker is approved for any data class, and shadow AI use grows because the approved alternative is not named. The fix is the explicit catalogue with named procurement owner, data classes permitted per tool, training commitment, residency, audit log capability, and review cadence so the workforce reads what is approved for what.
The prompt content rules are written as principles rather than categories
A prompt content section that says "do not share confidential information" leaves the workforce to invent the categorisation in real time. The fix is the named forbidden inputs, named permitted inputs, named conditional inputs, named indirect input rules, and named output rules so the workforce member can apply the rule in real time without judgement-by-judgement litigation.
The AI agent rules are missing
When the AI section addresses only prompt-and-respond chat tools but not AI agents that take stateful actions, the workforce member who runs an autonomous agent operates without an audit trail, without a human-in-the-loop boundary, and without the excessive-agency principle. The fix is the named agent rules in Section 8 with approved runtimes only, human-in-the-loop for stateful actions, the excessive-agency boundary, the audit log requirement, and the quarterly permission review.
The workforce decision AI rules are silent
When the AI section does not name the rules for AI in hiring, performance, and disciplinary decisions, AI tools enter the workforce decision workflow without bias audit, without named notice, without workforce member appeal rights, and without conformity assessment under EU AI Act high-risk classification. The fix is the explicit Section 10 with no-autonomous-decisions, named-jurisdiction compliance, bias audit cadence, named workforce notice, named data minimisation, and named tool authorisation gate.
AI procurement is left to individual workforce members
When the AI section does not name a procurement gate, individual workforce members sign up for tools, accept clickwrap terms, and bring tools inside the workforce-data perimeter without the contractual no-training commitment, the data residency commitment, or the audit log capability. The fix is the six-check procurement gate in Section 11 so every new tool clears data class fit, security baseline, regulatory fit, model risk fit, jurisdictional fit, and named owner before it enters the catalogue.
The amendment cadence matches the wider AUP cycle rather than the AI tool cycle
When the AI section refreshes only once a year alongside the wider AUP, the catalogue lags the live tool landscape and the workforce ends up applying stale rules to new tools, new agent action classes, new model behaviour changes, and new regulatory expectations. The fix is the quarterly catalogue review plus the ten named out-of-cycle amendment triggers so the policy keeps up with the tool landscape and the regulatory landscape.
Ten questions the AI AUP has to answer
A defensible AI AUP answers each of these ten questions explicitly. Capture the answers in the sections above rather than relying on individual line managers, AI operators, or security analysts to recall them when a real situation arises. The ten questions are the operational floor of an AI AUP; richer programmes answer more, but the ten below are the durable minimum the workforce, the disciplinary procedure, and the audit read against.
1.Who in your organisation is authorised to sign this policy on behalf of AI governance, security, HR, privacy, legal, and the executive sponsor.
2.Which AI posture (permitted broadly, permitted with restrictions, permitted for low-risk classes only, forbidden) reflects the organisation's actual position and the named business and risk and regulatory drivers behind it.
3.Which AI tools are on the approved catalogue with which data classes, what training commitment, what residency commitment, and what audit log capability per tool.
4.Which data classes are forbidden from AI tools regardless of approval (credentials, customer personal data, regulated data, source code with sensitive business logic, security findings, internal-classification documents, medical and health data).
5.How is the human-in-the-loop boundary named for AI agents that take stateful or irreversible actions (send external communications, modify production systems, write to customer-visible records, transfer funds, file regulatory filings, deploy infrastructure).
6.How are AI-assisted code commits identified as AI-assisted in the pull request audit trail, and what is the extra-care discipline for AI-generated authentication, encryption, access control, cryptographic, input validation, and session management code.
7.How are AI tools used in workforce decisions (hiring, performance, disciplinary, termination) authorised through the named tool authorisation gate with the named DPIA, the named bias audit cadence, the named workforce notice, and the named appeal channel.
8.How is the AI procurement gate run for new AI tools with data class fit, security baseline, regulatory fit, model risk fit, jurisdictional fit, and named owner.
9.How does a workforce member report a suspected AI incident (prompt injection, secret leakage to an AI tool, indirect prompt injection through a RAG pipeline, training data leakage, model extraction, hallucination that reached a deliverable, bias output, unauthorised agent action, shadow AI use, catalogue inaccuracy).
10.How does an exception to a clause of this policy get recorded, approved, expired, and reviewed against the wider security exception register with named owner and named expiry.
How the AI AUP pairs with SecPortal
The template above is copy-ready as a standalone artefact. SecPortal is not an HRIS, a learning management system, an AI tool catalogue, or a policy distribution platform; it does not replace the HR-owned acknowledgement chain, the AI procurement system, or the AI vendor management workflow. What SecPortal does is carry the security-side evidence chain that connects the AI AUP to the rest of the security operating record. The AI AUP itself can be held as a versioned document through document management with named custodian, named version history, and the named owner roles (AI governance owner, CISO, HR director, DPO, general counsel, executive sponsor) recorded on the document control header.
The sign-off chain on each version is captured on the activity log with named actor, timestamp, and 30, 90, or 365-day retention by plan, so the audit reads the quarterly catalogue review, the annual policy review, the out-of-cycle amendment, and the reacknowledgement trigger directly from the workspace record rather than as a separate assertion. Access to the policy and its sensitive sections is gated by team management role-based access control with the four roles (owner, admin, member, viewer) shaping who can read and amend the document, and protected by multi-factor authentication for the sign-off events on the workspace itself.
The chartered outcomes that reference the AI AUP read against the compliance tracking feature where ISO/IEC 42001 Clause 5.2 and Annex A.2 and A.3 and A.5 and A.6, NIST AI RMF GOVERN and MANAGE functions, EU AI Act Article 4 and 6 and 14 and 26 and 50, NIST CSF 2.0 GV.PO and GV.RR and PR.AT, NIST SP 800-37 Steps 1 and 2, NIST SP 800-53 PL-4 and AT-2 and AC-20 and CM-7 and SI-12, ISO/IEC 27001 Annex A 5.10 and A 5.34 and A 8.10 and A 8.12, SOC 2 CC1.4 and CC2.2 and CC6.1, OWASP LLM Top 10, OWASP AISVS, and GDPR Article 22 and 32 and 35 mapping reads against the live findings record with CSV export.
Exception-routed departures from the AI AUP are recorded against finding overrides (where the override expresses the operating-side risk acceptance) and against the wider vulnerability acceptance and exception management workflow for the named expiry, named owner, and named renewal review. The AI report generation workflow drafts the workforce-facing summary of the AI AUP, the executive summary, and the framework-mapping section from the underlying workspace record so the AI governance owner edits rather than writes from a blank page. The notifications and alerts feature dispatches the quarterly catalogue review trigger, the annual policy review trigger, and the ten named amendment triggers to the AI governance owner and the named co-owners with the same audit trail.
For the framework anchors that the AI AUP evidences, see the framework pages for ISO/IEC 42001, NIST AI RMF, OWASP LLM Top 10, OWASP AISVS, ISO 27001, SOC 2, NIST CSF 2.0, NIST SP 800-37, NIST SP 800-53, and GDPR. SecPortal does not replace the HRIS that holds the per-user acknowledgement chain, the AI tool catalogue that the procurement team maintains, the learning management system that delivers the AI literacy training, or the policy management platform that distributes the policy to the workforce. The HR-owned and AI-governance-owned chain sits in those systems while SecPortal carries the security-side evidence chain that connects the AI AUP to the live security operating record.
Buyer and operator pairing
The AI system acceptable use policy is the workforce-facing rule book that CISOs and security leaders, GRC and compliance teams, internal security teams, AppSec teams, product security teams, security architects, security program managers, and security engineering teams publish jointly with AI governance, HR, privacy, and legal when a board, an audit committee, a regulator, a customer security review, an insurance underwriter, or a procurement process asks for evidence that the workforce contract names what AI tools are permitted, what data classes may pass to which tools, what is monitored, and what happens when the rules are broken. External advisors (virtual CISOs, compliance consultants, AI and ML security consultancies) use the same template to give client programmes a defensible AI use rule that meets ISO/IEC 42001, NIST AI RMF, and EU AI Act expectations rather than a placeholder paragraph drafted on the eve of an AI governance audit, a customer security review, or a regulator engagement on AI system deployment.