#AI Governance & Model Risk Policy

POL-GL-132 | Version 1.0.0 | Last Modified On 31 July 2026 | Tier: Public

The boundary, first, because it is the whole policy. Pensieve uses machine learning for non-clinical functions only. It does not diagnose, triage, score clinical risk, calculate patient-specific doses, or recommend treatment. The regulatory boundary is DIS-GL-028; the feature-level disclosure is DIS-GL-027. Nothing in this policy may be read as softening that boundary.

---

#Applicability

Applies identically in all four deployment models: the boundary is a property of the software, not of where it runs. In DM-4, any model runs on the hospital's own hardware and no inference data leaves the hospital's premises unless the hospital configures an external model provider under Section 4.

---

#1. Purpose

To govern every use of machine learning and generative AI, in the Platform, in Edsol Edtech Pvt. Ltd.'s own operations, and in how Pensieve Labs builds software, so that the clinical safety boundary holds, hospital data does not leak into a third party's model, and a hospital always knows what a model did and can turn it off.

#2. Scope

Three distinct uses, governed separately:

---

#3. Models in Pensieve

3.1 The clinical boundary.

3.1.1 No model in Pensieve diagnoses, triages, scores clinical risk, calculates a patient-specific dose, or recommends treatment. A feature request that would do any of these is refused at design, not mitigated.

3.1.2 Permitted uses are administrative and operational: for example coding assistance for billing codes with human confirmation, document classification, text extraction, scheduling optimisation, demand forecasting, duplicate-record detection and search ranking.

3.1.3 Every model output that affects a record is advisory and requires a human action to take effect. A model does not write to a clinical record autonomously.

3.1.4 A proposed feature is assessed against DIS-GL-028 before build. R_FOUNDER approves; the assessment is recorded. Where the assessment is uncertain, the answer is no.

3.2 Transparency and control.

3.2.1 Every model-driven feature is named in DIS-GL-027 with: what it does, what data it uses, what the human review step is, and how the hospital turns it off.

3.2.2 Every model-driven feature can be disabled by the hospital, per feature, without losing unrelated functionality.

3.2.3 Where a user sees a model-generated suggestion, it is labelled as such in the interface. A suggestion presented as a fact is a defect.

3.2.4 Model inference that affects a record is logged with the model version, the inputs' identifiers and the output, so a decision can be reconstructed (POL-GL-113 Section 3.1.1).

3.3 Data.

3.3.1 Hospital data is not used to train models offered to other hospitals. This is absolute and is contractual in DPA-GL-001.

3.3.2 A model trained on one hospital's data, at that hospital's written instruction, is that hospital's and is deployed only in its own tenant.

3.3.3 Where inference is performed by an external model provider, that provider is a sub-processor, is assessed under POL-GL-120, is published in DIS-GL-009, is contractually prohibited from retaining or training on submitted content, and hospitals are notified before it begins processing (POL-GL-135 Section 4.2).

3.3.4 Where a hospital declines an external model provider, the feature is disabled for that hospital rather than the data being sent anyway.

3.4 Model risk.

3.4.1 Every model in production is recorded in a model inventory with: purpose, version, training or provider basis, input data classes, output use, human review step, owner, evaluation results, and date of last evaluation.

3.4.2 Models are evaluated before release and at least semi-annually thereafter for accuracy and for material performance differences across the populations they touch. Results are recorded, and a material degradation removes the feature from service until corrected.

3.4.3 Model risks are recorded in REG-GL-202 with an accepting role (POL-GL-117).

3.4.4 A model incident (a materially wrong output that reached a user, an unexpected data flow, a provider incident) is a security incident under POL-GL-112 and, where it affects a record, is notified to the hospital.

---

#4. External AI services used by Edsol Edtech Pvt. Ltd.

4.1 No hospital data (patient, clinical, financial, operational or identifying) is entered into any external AI service. This is one of the four absolute prohibitions in POL-GL-102 Section 3.

4.2 External AI services used for Edsol Edtech Pvt. Ltd.'s own work (drafting, summarising internal material, research) are permitted only from the approved list maintained by R_SEC, and only with CONFIDENTIAL-or-lower Edsol Edtech Pvt. Ltd. information, never with a hospital's confidential commercial terms.

4.3 An approved service must be configured not to retain or train on submitted content, and the configuration is verified at approval and at each semi-annual review.

4.4 A service that processes any customer personal data is a sub-processor and follows Section 3.3.3 without exception.

---

#5. AI coding assistants

5.1 AI coding assistants are permitted only from the approved list, configured not to retain or train on submitted content.

5.2 Hospital data is never submitted to a coding assistant (POL-GL-102 Section 4.4).

5.3 Accountability for merged code is the author's. "The assistant wrote it" is not a defence at code review or in a post-incident review (POL-GL-118 Section 3.8.3).

5.4 Assistant-generated code passes the same review, static analysis, dependency scanning and secret scanning as any other code. Suggested dependencies are checked for existence and provenance before use.

5.5 The approved list is reviewed semi-annually by R_SEC and R_ENG.

---

#6. What Edsol Edtech Pvt. Ltd. will not claim

6.1 Pensieve Labs does not describe Pensieve as clinical decision support, as AI-driven diagnosis, or as anything that would place it inside a medical device definition (DIS-GL-028). This applies to marketing copy, demonstrations, conference talks and tender responses equally (POL-GL-100 Section 4.8).

6.2 Pensieve Labs does not claim model accuracy figures without stating the evaluation dataset, the date and the method.

6.3 Pensieve Labs does not hold, and does not claim, any AI-specific certification or conformity assessment.

---

#7. Roles and responsibilities

---

#8. Exceptions

Per POL-GL-000 Section 5. No exception is available to Section 3.1.1 (the clinical boundary), Section 3.3.1 (no cross-hospital training) or Section 4.1 (no hospital data in external AI services). These three are refusals, not risk decisions.

---

#9. Compliance and enforcement

Evidence is the model inventory and its evaluation records, DIS-GL-027 currency, the approved-tool lists with verification records, sub-processor entries in DIS-GL-009, and per-hospital feature enablement settings. R_FOUNDER reports at each management review: models in production, evaluations overdue, features disabled by hospitals, model incidents, and any proposed feature refused under Section 3.1.4. Submitting hospital data to an AI service is gross misconduct under POL-GL-102 Section 7.

---

#10. Related documents

POL-GL-100, POL-GL-102 Acceptable Use (internal), POL-GL-110 Data Protection & Privacy, POL-GL-112 Incident Response, POL-GL-117 Risk Management, POL-GL-118 Secure SDLC, POL-GL-120 Vendor & Third-Party Risk, POL-GL-135 Sub-Processor Management, DIS-GL-027 AI/ML Feature Disclosure, DIS-GL-028 Clinical Safety Boundary Statement, ADD-GL-005 Use Case Restrictions, DPA-GL-001 Data Processing Agreement, DIS-GL-009 Subprocessor Register

---

#11. Review cadence

Semi-annual. Out of cycle on: a new model-driven feature; a change of model provider; a model incident; a change in AI regulation in any market Pensieve Labs serves.

---

#12. Change history