Responsible AI Architecture

Most AI policies describe principles. PrismCDM describes architecture. Four guardrails are built into the platform, enforced structurally, and inspectable on request through the Compliance Review.

• Source Fidelity. Every value carries a classification of its origin. Values without an origin cannot be displayed.
• Provenance. Every value records the sources, the platform components, and the version stack that produced it. Outputs are inspectable from the value back to the source that justifies it.
• Structural Validation. AI cannot write directly to execution. Every output passes through schema validation, evidence validation, confidence validation, and provenance validation before becoming visible.
• Human Governance. Only operators can accept, reject, override, or defer. AI proposes; operators decide. The architecture refuses to let AI act on regulated decisions.

AI is embedded throughout the platform, not just in protocol parsing. Each capability is bound to the same four guardrails above and feeds a specific operational surface.

Every AI output in PrismCDM travels the same lifecycle from the source protocol through the audit trail. Each step is architectural; no step can be bypassed.

PrismCDM prevents unsupported outputs through architectural controls. Before an AI output becomes visible to an operator, all of the following conditions must be satisfied.

• Evidence exists for the asserted value
• Evidence is classified by origin
• Schema validates the value
• Confidence threshold met
• Provenance attached and inspectable
• Integrity anchor generated

Where any condition is not satisfied, the platform surfaces Not Supported or Not Specified in Protocol rather than fabricating a value. No exceptions.

Different output classes carry different trust levels and different review obligations. The class is a structural property of the output, not a label applied at presentation time.

Every AI output in PrismCDM is designed to answer the same questions on request.

• Why was this output generated?
• What evidence supports it?
• Which platform component generated it?
• Which assessment framework was in force at generation?
• Can the supporting evidence be inspected directly?
• Can the output be reproduced from the same inputs?
• Has this output changed since it was first generated, and if so, when and why?

The answers are produced by the platform itself, not by the operator who reviews the output. Explainability is an architectural property, not a manual workflow.

The platform architecture refuses to let AI act autonomously on regulated decisions. The following are never AI-driven actions.

• Approve protocol amendments
• Approve Case Report Forms
• Sign 21 CFR Part 11 records
• Lock databases
• Close queries
• Approve submissions
• Replace Medical Monitor decisions
• Replace Biostatistics review
• Replace Regulatory review

Each of these is reserved for the human role accountable for the decision under applicable regulation and the customer's validated processes. AI may surface evidence, propose drafts, and suggest actions; AI may not take the decision.

PrismCDM is designed so that, given the same validated inputs, assessment framework, evidence snapshot, and platform configuration, analytical outputs are reproducible within the constraints of the configured inference pipeline.

Historical outputs remain permanently inspectable and are not silently replaced when AI models evolve. Changes to models, assessment frameworks, or evidence snapshots produce new outputs with new provenance, while the prior outputs continue to be inspectable in their original context.

Customer protocols, study documents, trial data, and tenant information are not used to train foundation models or shared machine-learning models that operate across customers. AI features operate within the customer's tenant boundary.

Where third-party AI providers are used, requests are transmitted only for the purpose of providing the requested functionality and are governed by contractual and technical safeguards. The list of providers is maintained at /trust/subprocessors; the detailed list is shared during the Compliance Review.

• Human review. Customers review AI outputs before relying on them for regulated activities. The platform supports this review; it does not replace it.
• Operational governance. Customers configure who can accept, defer, or decline AI-generated suggestions inside the execution workspace, with the decisions captured as auditable events.
• Regulatory determinations. Determining regulatory fitness for purpose, validating regulated workflows, and complying with applicable laws and regulations remain the responsibility of the customer.

Concerns about AI outputs, model behavior, or this Policy can be directed to /contact with reason “Compliance Review” or “Technical question”.

• Security:the architectural posture.
• Privacy:AI and customer data commitments.
• Subprocessors:third-party AI providers within the trust boundary.
• Data Processing Agreement:the legal framework.
• Architecture and Assurance Roadmap:independent validation milestones.