Skip to content
Pre-publication draft. This Trust Center is prepared for peer review before public launch.
Policies, Standards & Procedures
AI Governance

AI Governance

Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30

Bioscope Foundry runs an AI-enabled back office for member physician practices. This policy establishes the framework for the responsible development, deployment, and use of AI systems at Foundry: the Atlas orchestrator, the tiered Forge Agents (including the Tier-4 Moltworkers that cannot hold PHI), the Beacon Layer redaction surface, and third-party AI tools used by the workforce. AI assistance augments human judgment; it does not replace it. PHI used by AI components lives only within Foundry’s FHIR service; PHI is never sent to third-party AI tools.

1. Purpose & scope

This policy establishes the framework for the responsible and ethical development, deployment, and use of artificial intelligence (AI) systems at Bioscope Foundry. As an AI-enabled MSO supporting independent physician practices, Foundry deploys agentic systems to operate over administrative and clinically-adjacent workflows on a member practice’s behalf, under that practice’s Business Associate Agreement. The policy:

  • Ensures compliance with all applicable laws, regulations, and ethical standards, including HIPAA, the HITECH Act, and the frameworks tracked in the framework crosswalk;
  • Promotes the responsible, transparent, and accountable use of AI technologies in healthcare-adjacent applications;
  • Mitigates the risks associated with AI: bias, privacy violations, security vulnerabilities, hallucination, prompt-injection, and the unique risks of multi-tier agentic systems;
  • Sustains trust in Foundry’s use of AI when operating over PHI on a member practice’s behalf;
  • Defines roles, responsibilities, and processes for AI governance across the organization;
  • Holds Foundry to a conservative posture: AI augments human judgment; it does not replace clinical or administrative decision-makers.

This policy applies to:

  • All workforce members, contractors, partners, and stakeholders involved in the development, implementation, management, or use of AI systems at Foundry;
  • All AI systems deployed in Foundry production environments, principally the Atlas orchestrator (Tier-0 control plane), Forge Agents at Tiers 1–3 that may access PHI under appropriate scope, and the Tier-4 Moltworkers that are sandboxed and cannot hold PHI;
  • The Beacon Layer redaction surface that separates raw PHI from physician-facing insights;
  • HIPAA-eligible AI services consumed under executed BAAs (for example, model endpoints offered by approved cloud providers);
  • Third-party AI tools used by the workforce for non-PHI business purposes;
  • AI models and systems under development or evaluation for potential deployment.

2. Background

Foundry operates the foundry-master-agent multi-agent system, in which the Foundry Orchestrator (canonical agent_id = atlas-orchestrator, commonly referred to as “Atlas”; legacy alias orchestrator per ADR 005) coordinates Forge Agents across five tiers to support a member practice’s operations. Tier-1 executive assistants (Goose and Maverick) help workforce members; Tier-2 Foundry operations and specialist agents handle the back office; Tier-3 clinic-scoped clinical agents operate within a single practice’s BAA; and Tier-4 sandboxed Moltworkers run untrusted or experimental tasks on dedicated sandboxed_public hosts that cannot reach PHI by construction. The Beacon Layer redaction surface converts clinic-scoped data into sanitized physician-facing insights, never exposing raw PHI or peer-practice :private memory.

Foundry uses two model providers under BAA, mapped to distinct agent tiers:

  • The Atlas orchestrator core and Tier-3 clinic-scoped clinical agents run on the Anthropic Claude API. PHI may flow to these endpoints under the Anthropic BAA, subject to the Tier-3 isolation invariants.
  • The Maverick Tier-1 executive assistant runs on the OpenAI API (currently gpt-5.5) via the OpenClaw agent-gateway runtime. PHI scope for OpenAI is governed by Foundry policy and routing: by default, Maverick does not receive PHI; any change requires Security Officer sign-off and an executed BAA addendum with OpenAI.

Where Foundry consumes hosted model inference for PHI-eligible workloads, that consumption occurs only via HIPAA-eligible services covered by a BAA with the provider. Foundry does not send PHI to consumer AI products or to model endpoints not covered by a BAA. The current set of approved AI subprocessors is maintained on the Subprocessors page.

This policy acknowledges both the value and the inherent risks of AI in a healthcare-adjacent operating environment and establishes the governance framework that ensures AI is used responsibly, ethically, and in compliance with healthcare regulations and the BAA with each member practice.

3. Definitions

  1. Artificial Intelligence (AI): the development of computer systems able to perform tasks that normally require human intelligence, including natural language processing, decision support, summarization, prediction, and tool-using agents. Includes generative AI, machine learning, deep learning, and large language models (LLMs).
  2. AI System: a specific implementation of AI technology, including software, infrastructure, data, and supporting processes. At Foundry, AI Systems include the Atlas orchestrator and the Forge Agents.
  3. AI Model: a learned representation of data used by an AI System to make predictions, classifications, or decisions. Includes hosted LLMs accessed via API and any fine-tuned or auxiliary models Foundry operates.
  4. Atlas: the Tier-0 master orchestrator and control plane for the Foundry agent operating model. Canonical agent identifier atlas-orchestrator.
  5. Forge Agent: any agent coordinated by Atlas at Tiers 1–4 (executive assistants, operations, specialist, clinical, and sandboxed worker agents).
  6. Moltworker: a Tier-4 worker that runs on a sandboxed_public host. Cannot hold PHI, cannot read clinic-scoped or :private memory, and cannot reach the PHI cloud.
  7. Beacon Layer: the redaction surface that sanitizes physician-facing outputs. The Beacon Layer never exposes raw PHI or peer-practice :private memory across the boundary.
  8. Vector Engine: the deterministic, scored routing and placement planner inside Atlas. Despite its name, it is not vector search.
  9. Production AI System: any AI System deployed in a Foundry production environment that processes data on behalf of a member practice. Production AI Systems that process PHI must operate on HIPAA-eligible infrastructure under executed BAAs.
  10. Third-Party AI Tool: external AI services (such as ChatGPT, Claude.ai, Microsoft Copilot, Cursor, or similar) used by workforce members for general business purposes. Third-Party AI Tools must never process PHI or confidential business information not approved for that tool.
  11. Data Privacy: the protection of personal information, including PHI, from unauthorized access and misuse.
  12. Data Security: the appropriate handling of data to ensure its confidentiality, integrity, and availability and to comply with applicable laws and the HIPAA Security Rule.
  13. Bias: systematic and unfair discrimination or prejudice in AI outputs due to flawed or unrepresentative data, algorithms, or development processes. In healthcare-adjacent AI this includes potential disparities in model performance across demographic groups.
  14. Transparency: the extent to which the inner workings of an AI System are understandable and explainable to relevant stakeholders, including practice staff, clinicians, and Foundry’s own workforce.
  15. Accountability: the ability to assign responsibility for the outcomes and actions of an AI System.
  16. HIPAA: the Health Insurance Portability and Accountability Act of 1996, as amended.
  17. PHI / ePHI: Protected Health Information; ePHI is PHI in electronic form. Foundry handles PHI as a business associate.
  18. Clinical Decision Support (CDS): AI systems that assist licensed healthcare providers in making clinical decisions. Foundry’s posture is conservative on CDS; the Foundry platform is not marketed as a CDS device and any CDS-adjacent feature requires explicit assessment against FDA guidance and the AI Governance Committee.

4. Policy statements

4.1 Compliance with laws and regulations (A)

All AI systems developed, deployed, or used at Foundry must comply with all applicable laws, regulations, and ethical standards, including but not limited to:

  • HIPAA Privacy Rule (45 CFR Part 160 and Part 164, Subparts A and E);
  • HIPAA Security Rule (45 CFR Part 164, Subpart C);
  • HITECH Act;
  • FDA regulations applicable to clinical decision support software, where engaged;
  • State-specific healthcare data-protection and AI laws;
  • Applicable AI safety and ethics guidelines, including the AI-management frameworks tracked in the framework crosswalk and Executive Order 14110.

4.2 Data privacy and security (B)

AI systems handling PHI must adhere to the strictest data-privacy and -security standards:

  1. Access controls. Role-based access controls (RBAC) and least privilege are enforced for any AI surface that touches PHI. All reads and writes of PHI by AI components are logged and auditable with the same controls described in the Access Control and System Audits & Monitoring policies.
  2. Encryption. Strong encryption protects PHI at rest (AES-256) and in transit (TLS 1.2+). All API calls to AI model endpoints handling PHI are made over TLS 1.2+ to HIPAA-eligible endpoints covered by a BAA.
  3. Security assessments. Foundry conducts regular security assessments, vulnerability scanning, and periodic penetration testing of AI systems processing PHI as part of the Vulnerability Management program.
  4. Incident response. Incident-response procedures cover incidents involving AI systems and are regularly tested. Breaches involving PHI are handled per the Breach Notification policy and the BAA.
  5. Data minimization. AI systems process only the minimum necessary PHI required for their intended purpose. Tier-4 Moltworkers cannot hold PHI under any circumstance.
  6. Purpose limitation. Use of PHI in AI systems is restricted to the specified, explicit, and legitimate purposes set out in the member practice’s BAA.
  7. Secure development. AI systems follow the Secure SDLC practices, including threat modeling, secure coding, code review, and security testing.
  8. Prompt-injection & tool-use safety. Agents that consume content from untrusted sources isolate that content from instructions and from PHI. The agent tier model is the primary structural control: untrusted content is handled at Tier 4 or behind explicit sanitization before being passed to a PHI-eligible tier.

4.3 Production AI systems handling PHI (C)

  1. HIPAA-eligible infrastructure. All production AI systems handling PHI operate on HIPAA-eligible infrastructure (Foundry’s FHIR service for the PHI substrate; HIPAA-eligible model endpoints for inference) with executed BAAs.
  2. Operational validation. AI components used in clinically-adjacent workflows undergo validation appropriate to the use case, accuracy, calibration, robustness on edge cases, and behavior under failure, before deployment to production.
  3. Human oversight. AI outputs that affect a member practice’s clinical or operational decisions are subject to review by qualified humans, either the practice’s clinicians or Foundry workforce members in the appropriate role. AI augments judgment; it does not replace it.
  4. Sensitive-category handling. Categories of PHI requiring heightened protection (for example, behavioral health, substance-use, HIV/AIDS, reproductive health, genetic information) are handled with additional controls. Such data is not used to train Foundry models without explicit, lawful authorization, and access is more tightly scoped than baseline PHI access.
  5. Model performance monitoring. Continuous monitoring of the behavior of deployed AI components, success rates, refusal patterns, drift, and fairness signals where applicable, with thresholds for intervention.
  6. Regulatory awareness. Foundry tracks FDA guidance on clinical decision-support software and adjusts the product posture if any feature begins to resemble a regulated device. The current posture is conservative: Foundry does not market the platform as a CDS device.

4.4 Third-party AI tools (D)

The use of external, non-Foundry AI tools is permitted only under the following conditions.

Prohibited uses. Third-Party AI Tools may never be used to process:

  • Protected Health Information (PHI) or electronic Protected Health Information (ePHI), including patient names, dates of service, clinical content, identifiers, or any patient-identifying detail;
  • Practice-confidential information whose disclosure could harm a member practice or its patients;
  • Confidential Foundry business information or trade secrets;
  • Security credentials, API keys, signing keys, or access tokens;
  • Data subject to contractual confidentiality obligations to a third party.

Permitted uses. Third-Party AI Tools may be used for:

  • General research and information gathering on public topics;
  • Drafting non-sensitive internal communications and templates;
  • Marketing and content review where no patient or practice information is involved;
  • Code assistance for non-PHI, non-production code, subject to Secure SDLC review before merging.

Vendor assessment. All Third-Party AI Tools used at organizational scale must undergo vendor risk assessment per the Vendor & Third-Party Risk policy before being approved for workforce use.

Training and awareness. Workforce members receive training on the appropriate use of Third-Party AI Tools and the data-exposure risks associated with them, as part of onboarding and the annual refresh.

4.5 Ethical considerations (E)

AI systems must be developed and used ethically, considering potential impacts on fairness, equity, and well-being:

  1. Bias mitigation. AI systems are designed, deployed, and monitored to minimize bias and discrimination. Where Foundry can measure performance across population subgroups, it does; where it cannot, it accepts a conservative deployment posture and discloses the limitation.
  2. Transparency and explainability. AI outputs used in workforce or practice workflows include sufficient information for the human reviewer to understand the basis for the output to the extent technically feasible.
  3. Human autonomy. AI systems are designed to respect and support human judgment. Clinical AI, where introduced, augments, not replaces, the professional judgment of licensed healthcare providers.
  4. Beneficence and non-maleficence. AI systems are designed to maximize benefit and minimize harm to patients, workforce members, and member practices.
  5. Privacy respect. AI development and deployment respect patient privacy rights as defined by the covered entity (the practice) and exercised through the practice.

4.6 Risk management (F)

  1. Pre-deployment risk assessment. A risk assessment is conducted before deploying any AI system that processes PHI or can influence clinically-adjacent decisions. The assessment covers data privacy and security risks, clinical safety risks where applicable, bias and fairness risks, regulatory compliance risks, technical performance risks, and operational risks.
  2. Risk mitigation. Identified risks are addressed through appropriate mitigations before deployment. Residual risks are documented and accepted by named stakeholders per the Risk Management policy.
  3. Ongoing risk monitoring. Continuous monitoring of deployed AI systems detects new or emerging risks: security vulnerabilities, model behavior degradation, bias or fairness issues, and regulatory changes that may require system updates.

4.7 Transparency and explainability (G)

  1. Model documentation. Each production AI System is documented: its architecture and algorithms, training data sources and characteristics (for fine-tuned components), performance metrics and validation results, known limitations and biases, intended use cases, and contraindications.
  2. Decision transparency. For agent actions that affect practice workflows, the audit trail records the agent identity, the inputs considered, the policy decisions made, and the outputs produced, sufficient for a human reviewer to reconstruct the agent’s behavior.
  3. Auditability. Comprehensive audit trails of AI system decisions, data access, and configuration changes are maintained to support compliance reviews and investigations, per the System Audits & Monitoring policy.

4.8 Human oversight and control (H)

  1. Clinical oversight. Human oversight by licensed healthcare providers is required for any AI output that would inform a clinical decision. Foundry’s posture is to keep clinical AI in an advisory role.
  2. Escalation procedures. Clear escalation paths exist for situations requiring human intervention: low-confidence outputs, detection of potential safety issues, unusual or unexpected results, system errors, prompt-injection signals.
  3. Override capability. Human reviewers can override AI recommendations based on their judgment and case-specific factors. Override actions are logged.
  4. Feedback mechanism. Workforce members and the practices we support can give feedback on AI behavior. Feedback is reviewed and integrated into improvements.

4.9 Training and awareness (I)

  1. Role-based training. Workforce members involved in AI development, deployment, or use receive role-appropriate training:
    • Engineering & data: AI ethics, secure development practices, bias detection and mitigation, HIPAA compliance, prompt-injection awareness, the agent tier model and Beacon Layer redaction;
    • Practice-facing workforce: appropriate use of AI tooling, capabilities and limitations, when to escalate;
    • Operations and IT: AI system monitoring, incident response, security operations;
    • All workforce members: appropriate use of Third-Party AI Tools, the PHI boundary, data-protection requirements.
  2. Continuous education. Training is updated to reflect evolving AI technology, regulatory requirements, and Foundry policy.
  3. Competency assessment. Periodic assessment of AI-related competencies is performed for workforce members in critical roles.

4.10 AI system documentation (J)

Every production AI system that processes PHI maintains:

  1. System architecture documentation: design, components, data flows, integration points;
  2. Data management documentation: sources, processing methods, quality controls, retention;
  3. Model details: algorithms, models, methodologies, validation;
  4. Performance metrics: ongoing documentation including accuracy, calibration, fairness signals, and clinical-utility measures where applicable;
  5. Security controls: access management, encryption, audit mechanisms;
  6. Change management: version control and change history for all AI system components.

4.11 Monitoring and auditing (K)

  1. Continuous monitoring. Performance metrics, behavior signals, security events and anomalies, data quality, and availability;
  2. Regular audits. Compliance with HIPAA Security and Privacy Rules, adherence to this policy, bias and fairness assessments, security vulnerability assessments, and validation of any clinically-adjacent outputs;
  3. Audit documentation. Findings and remediation actions are documented and tracked to closure;
  4. Third-party audits. Foundry supports external audits by regulators, certification bodies, and member practices as required.

4.12 Continuous improvement (L)

  1. This policy is reviewed at least annually and more frequently when AI technology, regulatory requirements, organizational structure, or incident learning requires it;
  2. AI systems are continuously improved based on monitoring, workforce and practice feedback, advances in the field, and observed fairness or bias issues;
  3. Foundry tracks the state of the art in agentic systems, evaluation methods, and safety research as part of normal engineering work.

5. Governance structure

5.1 AI Governance Committee

An AI Governance Committee (AIGC) oversees the implementation and adherence to this policy.

Composition ():

  • Security Officer: chair;
  • Privacy Officer;
  • The Engineering Lead;
  • The Clinical Advisor (consulted on clinically-adjacent features);
  • The Operations Lead.

Responsibilities:

  1. Review and approve AI system deployments to production;
  2. Establish guidelines and acceptable-use policies for AI technologies at Foundry;
  3. Monitor compliance with ethical, regulatory, and contractual standards;
  4. Oversee risk management and mitigation for AI systems;
  5. Evaluate the effectiveness of AI systems and this policy;
  6. Review and approve changes to this policy;
  7. Investigate and address AI-related incidents or ethics concerns;
  8. Monitor for potential bias, discrimination, or harm resulting from AI systems.

Cadence: the AIGC meets at least quarterly, with additional meetings as needed for urgent matters.

5.2 AI ethics responsibilities

An AI ethics function is assigned to a designated workforce member who is the point of contact for ethical concerns or violations. This responsibility may be held by the Security Officer or the Privacy Officer rather than by a separate AI Ethics Officer. The assignment is recorded in the AIGC charter in internal governance records.

The AI ethics function:

  1. Advises on ethical considerations during AI system design and deployment;
  2. Conducts ethics reviews of proposed AI systems and use cases;
  3. Investigates and addresses ethical issues or complaints related to AI systems;
  4. Facilitates training on ethical AI use and practice;
  5. Monitors AI systems for ethical compliance and potential harm;
  6. Participates in AIGC meetings;
  7. Stays informed on evolving AI ethics standards and best practices;
  8. Reports significant ethical concerns to senior leadership and the AIGC.

5.3 Senior leadership accountability

Final responsibility for Foundry’s adherence to AI governance principles and this policy rests with the CEO and senior leadership team. Senior leadership must:

  • Allocate appropriate resources for responsible AI development and governance;
  • Foster a culture of ethical AI development and use;
  • Support the AIGC and the AI ethics function;
  • Ensure accountability for AI-related incidents or policy violations;
  • Communicate AI governance priorities throughout the organization.

6. Development & deployment procedures

6.1 Assessment and approval

Before an AI system that processes PHI or that influences a workflow with patient-safety implications is deployed to production, it completes a multi-stage approval:

  1. Technical review. Architecture and design, code quality and security, performance and scalability, integration and testing.
  2. Security risk analysis. Threat modeling and risk assessment, security control validation, vulnerability and penetration testing results, HIPAA Security Rule compliance verification.
  3. Ethical review. Bias and fairness assessment, transparency and explainability evaluation, human oversight and control mechanisms, privacy impact assessment.
  4. Legal and compliance review. HIPAA compliance verification, BAA validation (with the member practice and with subprocessors), FDA regulatory review where applicable, data-use and consent verification.
  5. Clinically-adjacent validation (for features that produce outputs intended for clinical or operational decision-making). Validation on representative cases, evaluation by workforce members in the relevant role, comparison to existing operational standards.
  6. Final approval. AIGC review and approval; sign-off by the Security Officer and the engineering lead; documentation of the approval decision and any conditions.

6.2 Documentation requirements

Comprehensive documentation is created and maintained for AI systems:

  1. System design. Architecture diagrams, data-flow diagrams, integration points, infrastructure and deployment configuration.
  2. Model documentation. Algorithm description and rationale, training data characteristics (for fine-tuned components), training methodology and hyperparameters, validation approach and results, performance across relevant populations, known limitations and contraindications.
  3. Security documentation. Threat model, implemented controls, access-control policies, encryption and key management, audit logging configuration.
  4. Operational documentation. Deployment procedures, monitoring and alerting, incident-response procedures, maintenance, BCDR.
  5. Compliance documentation. HIPAA compliance assessment, privacy impact assessment, BAAs, regulatory filings (if applicable).

Documentation is maintained under version control and updated as systems change.

6.3 Change management

All changes to production AI systems follow the Configuration & Change Management process:

  1. Changes are documented, tested, and approved before implementation;
  2. Security and compliance impacts are assessed for each change;
  3. Changes to AI models that alter behavior require re-validation and AIGC approval;
  4. Changes are tracked in the production-change tracker and applied through GitHub-Actions-driven workflows where applicable;
  5. Rollback procedures are documented and tested.

7. Monitoring & evaluation

7.1 Continuous monitoring

AI systems handling PHI are continuously monitored for:

  1. Performance metrics. Accuracy and other relevant metrics, inference latency, system response time, availability and uptime, error rates and exception handling;
  2. Fairness signals. Performance differences across population subgroups where measurable, representation in processed data, potential bias sources;
  3. Security events. Access attempts and authorization failures, data-access patterns and anomalies, security-control effectiveness, suspected incidents;
  4. Data quality. Completeness and accuracy of inputs, distribution drift, missing or invalid data patterns, integrity verification;
  5. Operational outcomes. Workforce acceptance and use rates, integration with practice workflows, observed effects on practice operations, feedback and reported issues.

7.2 Regular audits and reviews

  1. Quarterly reviews. Monitoring data, incidents and issues, compliance with this policy, opportunities for improvement;
  2. Annual comprehensive audits. HIPAA compliance, security assessment and penetration testing, bias and fairness assessment, validation review for any clinically-adjacent outputs, refresh of all AI system documentation;
  3. Incident-triggered reviews. Investigation of security incidents involving AI systems, analysis of failures or unexpected errors, review of bias or fairness concerns, assessment of any safety events.

7.3 Feedback mechanisms

  1. Practice feedback. Member practices have an accessible channel to report concerns, provide feedback, or request clarification about AI behavior in their operations.
  2. Internal reporting. Workforce members can report AI-related concerns through direct contact with the AI ethics function, the Security Officer, the Privacy Officer, anonymous whistleblower channels, the Linear ticketing system, and dedicated a dedicated AI-governance channel.
  3. Patient concerns. When patients raise concerns about AI in their care, those concerns are routed through their physician practice (the covered entity). Foundry supports the practice in addressing such concerns but does not engage patients directly except where the practice directs us to.
  4. Feedback integration. Feedback is systematically reviewed and integrated into AI system and policy improvements.

8. Enforcement & accountability

8.1 Policy violations

Violations of this policy are taken seriously and addressed promptly:

  1. Investigation. Reported or suspected violations are investigated by the AI ethics function in coordination with the Security Officer, the Privacy Officer, and (where applicable) HR.
  2. Workforce action. Violations may result in actions up to and including mandatory retraining, suspension of AI system access privileges, formal written warning, performance plan, or termination of employment or engagement, in line with the HR & Personnel Security sanction framework.
  3. System action. AI systems found to be in violation of this policy may be immediately disabled, taken offline, required to undergo remediation, required to undergo re-approval, or permanently decommissioned.
  4. Legal consequences. Violations that result in regulatory non-compliance, breaches, or harm may result in regulatory enforcement, civil or criminal liability, contractual penalties, and reputational harm. Foundry will cooperate fully with regulators and member practices in such cases.

8.2 Reporting requirements

  1. Internal reporting. Workforce members and stakeholders report suspected policy violations, AI system malfunctions or unexpected behavior, potential bias or fairness concerns, security incidents involving AI systems, and patient-safety concerns related to AI systems.
  2. External reporting. Foundry reports to external parties as required:
    • Breach of unsecured PHI: notification to affected member practices per the BAA and per the Breach Notification policy; the practice notifies HHS and individuals as the covered entity;
    • FDA adverse-event reports if and where applicable;
    • State data-breach notifications as required;
    • Subprocessor and member-practice notifications per contractual obligation.
  3. Reporting channels.

9. Policy approval & maintenance

9.1 Approval authority

This policy is approved by:

  • Chief Executive Officer (CEO);
  • Security Officer;
  • Privacy Officer;
  • Engineering lead;
  • AI Governance Committee.

9.2 Review and revision

  1. Scheduled reviews. This policy is reviewed at least annually by the AIGC.
  2. Triggered reviews. Reviews are also conducted when significant changes to AI technology occur, new regulations or guidance affecting AI use are issued, significant incidents or policy violations occur, organizational changes affect AI governance, or industry best practices evolve.
  3. Revision process. Proposed revisions are drafted by the AIGC, circulated for review and comment, approved by the AIGC and senior leadership, communicated to all workforce members, and reflected in updated training.
  4. Version control. Each version is maintained with version number and date, summary of changes, approvals, and effective date.

10. Applicable regulations & standards

This policy is designed to comply with and align to the following:

  • Health Insurance Portability and Accountability Act (HIPAA);
  • Health Information Technology for Economic and Clinical Health (HITECH) Act;
  • FDA regulations for clinical decision support software (21 CFR Part 820, where applicable);
  • Executive Order 14110 on Safe, Secure, and Trustworthy AI;
  • Foundry’s secure-development standards for LLM-enabled applications.

HIPAA Security Rule, Privacy Rule, and Breach Notification Rule govern this policy. Mapping to other frameworks (CCPA, ISO/IEC 27001, ISO/IEC 42001, SOC 2) is maintained in the framework crosswalk.

11. Related policies

Security Architecture & Operating ModelAccess Control