Responsible AI Policy

Effective Date: August 30, 2026

How Quaspar designs, deploys, and governs AI in the Workforce platform

1. Purpose

This policy describes the principles and controls Quaspar applies to the AI systems it builds and offers. It is written for customers, regulators, and our own team. It supports our obligations under HIPAA, the FTC Act, Illinois law, the Colorado Artificial Intelligence Act, and similar rules as they take effect, and it is reviewed at least annually.

2. What our AI does and does not do

Quaspar workers carry out administrative, research, and analytical tasks configured by customers: retrieving records, drafting forms and correspondence, summarizing literature, running analyses on data the customer authorizes, and calling tools within permitted scopes. Workers do not make clinical decisions, do not make eligibility or coverage determinations, do not make employment, credit, housing, insurance, or education decisions about individuals, and are not intended for any use that would make them a high-risk AI system under Colorado law or a medical device under FDA rules. Customers agree not to use the Service for those purposes without meaningful human review.

3. Principles

Human accountability. A qualified person reviews outputs before they affect patient care, research findings, regulatory filings, or money. The platform is built so a reviewer can see what a worker did and why.
Permissions enforced by code, not by the model. What a worker may do is defined in a structured spec and enforced by a deterministic policy engine. The model cannot grant itself access.
Least privilege and budgets. Connectors and tools are scoped narrowly. Per-organization daily AI spend caps and a separate research cap limit runaway behavior.
Transparency. Customers can see which model powered a build, what tools were called, what data was retrieved, and what it cost. Marketing does not overstate capabilities.
Privacy by design. PHI is redacted before it enters learning memory. Customer data is never used to train general models. Providers without a BAA cannot receive PHI.
Safe learning. Per-worker neural networks run in shadow mode until they beat a baseline on held-out data; only then do they influence behavior. Learning can be paused, reset, or deleted by the customer.
Fairness. We test workers against synthetic and evaluation datasets for inconsistent behavior across patient or subject groups, and we do not use protected characteristics as inputs unless clinically or scientifically required and configured by the customer.

4. Lifecycle controls

Stage	Control
Design	Worker archetypes reviewed for intended use, risk class, and required approvals before entering the catalog
Build	Compiler charter constrains what a worker can be; tool names validated; free-text requests interpreted within the same policy engine
Evaluation	Evaluation datasets with LLM-as-judge and rule-based regression gating; releases blocked on regression
Release	Shadow and canary rollouts; OpenTelemetry tracing; rollback path
Operation	Audit logging; exception intelligence surfaces anomalies to admins; budget caps; rate limits; fail-open availability design for non-safety paths
Feedback	Customer feedback and correction signals feed evaluation, not general model training
Retirement	Deprecated archetypes and models removed with notice; learning data deleted on request

5. Model providers

We route to third-party models selected by the customer. Each provider is onboarded only after reviewing its usage policies, data retention, training commitments, and BAA availability. Providers are listed in the Sub-processor List with their PHI eligibility. We do not send PHI to providers that have not signed a BAA.

6. Incident handling

AI-related incidents (harmful output, permission bypass, unexpected autonomous action, budget overrun, data leakage) are handled under the Incident Response Plan. Customers are notified as required by the BAA and DPA. Post-incident reviews feed back into evaluation datasets and policy engine rules.

7. Customer responsibilities

Customers own their worker configurations, approval gates, budgets, and the decision to rely on outputs. Customers deploying workers in regulated contexts must complete their own risk assessment and, where required, notify affected individuals that AI is involved.

8. Governance

The CEO is accountable for this policy. It is reviewed annually and whenever a material new capability (new data type, new autonomy level, new provider) is added. Questions: support@quaspar.com.