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.