AI governance and security

The Epic on Azure platform operates in a healthcare enterprise context where the consequences of security lapses, data mishandling, or unverified automation can affect patient safety, regulatory standing, and organizational trust. AI development tools introduce powerful capabilities alongside new categories of risk. This page establishes the governance framework that allows the team to use AI tools confidently while maintaining the security posture and compliance obligations that healthcare infrastructure demands.

---

Acceptable use principles

AI tools are force multipliers for the platform team. These principles define the boundaries of responsible use:

1. AI tools are productivity aids, not decision-makers for critical systems. No AI-generated output should be deployed to production infrastructure without human review and approval. AI assists; humans decide.
2. Always review AI-generated code before committing. Treat AI output the same way you would treat code from an untrusted contributor: review it line by line, understand what it does, and verify it meets the project's standards.
3. AI-generated documentation should be verified for accuracy. AI tools can draft documentation quickly, but they may hallucinate details, invent configuration options, or misrepresent system behavior. Verify all claims against the actual codebase.
4. Use AI tools to augment, not replace, human judgment. AI excels at boilerplate generation, pattern recognition, and exploring solution spaces. It does not understand the business context, operational history, or risk tolerance that informs engineering decisions on this platform.

---

Data sensitivity guidelines

The single most important governance rule is controlling what information enters AI tool prompts and conversations. Once data is sent to an AI service, you cannot retrieve or delete it from the provider's systems with certainty.

What you must never share with AI tools

Use placeholders instead

When you need AI assistance with code that involves sensitive values, substitute placeholders:

# Instead of real credentials
export AZURE_CLIENT_ID="<client-id>"
export AZURE_CLIENT_SECRET="<client-secret>"
export AZURE_TENANT_ID="<tenant-id>"
export DB_PASSWORD="<database-password>"
export API_KEY="<your-api-key>"

# Instead of real infrastructure details
azure_subscription_id: "<subscription-id>"
key_vault_name: "<key-vault-name>"
storage_account_key: "<storage-account-key>"

If you realize you have accidentally included sensitive data in an AI prompt, see the Incident response section below.

---

Approved AI tools

The following tools are sanctioned for use by the platform team. Using unapproved AI tools for work on Epic on Azure repositories is not permitted without prior approval from the security team.

Plugin management

All Claude Code plugins are sourced from the otc-awesome-llm repository. Only plugins from this repository are approved. Do not install third-party Claude Code plugins without security team review.

Organizational AI usage policy

The tools listed above operate within the broader organizational AI usage policy. If your use case falls outside standard development workflows (for example, processing large datasets through AI tools or integrating AI into customer-facing systems), consult the compliance team before proceeding.

UHG / Optum policy alignment

This page is downstream of organization-level policy work — it documents how platform engineers should use AI tools day-to-day, not the policies themselves. The authoritative sources are:

• AAP (AI Acceptable Use Policy) — sets the boundaries for what AI tools may be used on UHG/Optum systems and data. AI usage outside the development workflows above is subject to AAP review.
• RAI (Responsible AI) review process — governs models or agents that affect business decisions, customer-facing systems, or clinical content. Engage RAI before integrating AI into anything beyond developer-tooling use cases.
• AI Digital Workers Enterprise Policy / UAIS registration — any autonomous AI agent operated by the team that performs actions on systems (issue triage, PR creation, automated remediation) must be registered as a Digital Worker in UAIS with the required attributes (owner, scope, audit trail). Operation Agent Swarm tracks the engineering controls behind this policy.
• Optum AI Tiger Team — owns the post-Agile AI-DLC strategy this site documents and convenes the cross-portfolio Tiger Den pilots that exercise it. This page is not a substitute for Tiger Team guidance; surface novel use cases there.

When in doubt: route through the AI Tiger Team or your CISO contact rather than improvising policy from this page.

---

Code review requirements

AI-generated code is subject to the same review standards as human-written code, with additional scrutiny in certain areas.

Standard review process

• All AI-generated code must go through the standard pull request review process. There are no shortcuts for "AI wrote it."
• AI-generated tests should be validated against actual system behavior. AI tools may generate tests that pass syntactically but do not exercise real conditions.
• AI-suggested architectural changes (new modules, service boundaries, data flow modifications) require team discussion before implementation.

AI-DLC approval gates

When using the AI-DLC methodology, the built-in phase gates serve as structured review checkpoints:

• Inception phase produces requirements and design documents that must be reviewed before construction begins.
• Construction phase generates code unit by unit, with review opportunities between each unit.
• Quality gates enforce that tests pass and documentation exists before work is considered complete.

These gates do not replace PR review. They supplement it by catching issues earlier in the development process.

Areas requiring extra scrutiny

Pay particular attention when reviewing AI-generated code in these areas:

• Infrastructure as Code (Terraform, Ansible) -- misconfigurations can affect production environments
• Security-related logic -- authentication, authorization, encryption, secret handling
• Database operations -- migrations, queries against production data stores
• Network configurations -- firewall rules, NSG changes, private endpoint setup

---

Audit and traceability

Maintaining a clear record of AI involvement in development work supports both internal accountability and external compliance requirements.

Automatic audit trails

The AI-DLC plugin automatically creates audit trails in aidlc-docs/audit.md within each project. These records capture:

• Which AI-DLC phases were executed
• Requirements gathered during inception
• Design decisions made during construction
• Timestamps and completion status for each phase

Commit message practices

When AI tools provide significant assistance (beyond trivial suggestions), note this in your commit messages:

feat(ansible): add ODB backup validation playbook

Implements pre-backup and post-backup validation tasks for the ODB role.
Backup integrity checks run automatically after each scheduled backup.

AI-assisted: Claude Code used for initial task scaffolding and Jinja2
template generation. All tasks reviewed and tested against staging.

This is not about disclaiming responsibility. You own every line you commit. The notation provides context for future reviewers and auditors.

Pull request descriptions

PR descriptions should indicate which AI tools were used and how:

## AI tool usage

- Claude Code CLI: Generated initial molecule test scaffolding
- AI-DLC: Used inception phase for requirements gathering (see aidlc-docs/)
- GitHub Copilot: Inline suggestions for YAML formatting

---

Compliance considerations

The Epic on Azure platform operates under multiple compliance frameworks that have implications for AI tool usage.

HIPAA implications

HIPAA's Security Rule applies to any system that stores, processes, or transmits PHI. AI tools are not covered entities, but sharing PHI with them could constitute an unauthorized disclosure:

• Technical safeguard (access control): AI tools should never have access to production systems containing PHI.
• Administrative safeguard (workforce training): Team members must understand what constitutes PHI and the prohibition on sharing it with AI tools.
• Physical safeguard (device security): AI tool sessions on developer workstations should be conducted on managed devices with full-disk encryption.

SOC 2 data handling

SOC 2 Type II audits evaluate the effectiveness of controls over time. AI tool usage intersects with several trust service criteria:

• Confidentiality: Sensitive data must not leave the organization's control boundary via AI tool prompts.
• Processing integrity: AI-generated infrastructure code must be validated to ensure it produces the intended results.
• Availability: AI tool outages should not block critical operational procedures. Maintain the ability to perform all tasks without AI assistance.

Organizational AI usage policies

Enterprise-level AI usage policies may impose additional requirements beyond what is documented here. These policies are maintained by the legal and compliance teams and may be updated independently of this document.

/// warning | Not legal advice This document provides practical guidance for the platform team. It is not a substitute for legal counsel. For binding interpretations of HIPAA requirements, SOC 2 obligations, or organizational AI policies, consult the legal and compliance team directly. ///

---

Incident response

If sensitive data was shared with an AI tool

If you realize that credentials, PHI, PII, or other sensitive data was included in an AI tool prompt or conversation:

1. Stop immediately. Do not continue the conversation or provide additional context that could compound the exposure.
2. Rotate affected credentials. If API keys, passwords, tokens, or certificates were exposed, rotate them immediately through the standard credential rotation process. Do not wait for confirmation that the data was compromised.
3. Document the incident. Record what was shared, which AI tool received it, the approximate timestamp, and the scope of potentially affected systems.
4. Report to the security team. File a security incident report through the standard incident management process. Classify based on the data type:
   • PHI exposure: P0 (Critical)
   • Credential exposure: P1 (High)
   • PII exposure: P1 (High)
   • Internal configuration details: P2 (Medium)
5. Preserve evidence. If possible, capture the AI tool session history or conversation log before it is cleared.

Reporting AI-related security concerns

For non-emergency concerns about AI tool security (potential policy violations, suspicious tool behavior, questions about data handling):

• Contact the security team through the standard security support channels
• Reference the specific AI tool and the nature of the concern
• Include relevant context (tool version, plugin name, configuration details)

Escalation path

---

Best practices

Project-level guardrails with CLAUDE.md

Use CLAUDE.md files in each repository to encode project-specific AI tool guardrails:

# CLAUDE.md

## Security constraints

- Never generate code that accesses production databases directly
- All Azure resource creation must go through Terraform modules
- Credential references must use Key Vault, never environment variables
- Do not modify files in the `secrets/` directory

## Review requirements

- Ansible playbook changes require molecule test coverage
- Terraform changes require `terraform plan` output in PR

These files are read by Claude Code at the start of every session, providing consistent guardrails across team members.

Permission mode configuration

Claude Code supports permission modes that control how much autonomy the tool has:

• Use restrictive permission modes for security-sensitive repositories
• Configure appropriate tool approval requirements for your risk tolerance
• Review and adjust permission settings as your comfort level with the tools evolves

Version control for AI configurations

Keep all AI tool configurations under version control:

• Plugin configurations in settings.json
• Hook definitions for pre-commit and post-commit validation
• CLAUDE.md files with project-specific instructions
• AI-DLC templates and workflow customizations

This ensures that AI tool behavior is auditable, reproducible, and consistent across the team.

Critical thinking about AI output

• Question AI-generated solutions that seem overly complex or use unfamiliar patterns
• Verify that AI-suggested dependencies are real, maintained, and do not introduce supply chain risk
• Be skeptical of AI-generated security configurations; cross-reference with official documentation
• Remember that AI tools optimize for plausibility, not correctness

---

Related resources

• Claude Code Setup -- Secure installation and initial configuration
• AI-DLC Methodology -- Built-in governance features of the structured development lifecycle
• AI Tools Decision Matrix -- Choosing the right tool for the task
• Security Development Guidelines -- Broader platform security standards
• Security and Compliance Hub -- Organizational security posture and compliance documentation