Our position
AI is infrastructure that ships to real users, so it inherits the same duty of care as the rest of the stack. We treat safety, evaluation, transparency, and human oversight as engineering requirements, not marketing claims — measured, versioned, and reviewed the same way we review any other production system.
Client data is not training data
We do not use client data — prompts, completions, uploads, retrieval sources, evaluation traces, or telemetry — to train, fine-tune, or evaluate any foundation model, ours or a third party's, unless you have signed a specific written agreement authorising a named use. The default is off, and there is no path in our stack that flips it on silently.
Model choice and provenance
We select models on capability, cost, latency, and vendor safety posture — not on brand. For every deployed model we record its provider, version, licence, known limitations, and the evaluation suite it passed before going live. Model swaps are versioned and change-logged so a regression can be traced to the exact release.
Evaluation and guardrails
Every production endpoint has an evaluation suite covering task quality, factuality where the domain allows it, refusal behaviour on out-of-scope requests, and safety on the categories relevant to the deployment. Guardrails run inline: input classification, output filtering, and policy-aware routing. Failures roll back the release, they do not just alert.
Human oversight
Automated decisions with legal or similarly significant effect on a person — credit, housing, employment, insurance, benefits, medical triage — require a documented human review step and an appropriate legal basis. This mirrors the acceptable-use policy and is enforced in our engagement contracts, not just in our documentation.
Transparency to end users
Where an interaction is with an AI system on your product, users should be told. We help you meet that obligation in the product design and in the model cards we hand over; the wording and placement is a decision you own, but the default position we take into design reviews is disclose.
Bias, harm, and known limits
No frontier model is bias-free, and no evaluation suite is exhaustive. We publish the limitations we know about for each deployment — the populations it under-represents, the categories where refusal is stricter, the failure modes we have measured — so your team can add product-side mitigations rather than discovering them in the field.
Incident response
A safety incident is any output that causes real-world harm, plausibly could, or breaches the acceptable-use policy on our side. We roll back or gate the offending endpoint, notify affected customers on the same clock as any security incident, and publish a post-incident review to the engagement.
Reporting a concern
Email support@myndstack.io with the subject line "Responsible AI" and enough detail for us to reproduce or verify. Concerns from end users of a client's product should route through that client first; where they reach us directly we relay them to the client and, if the concern involves risk to a person, act on it immediately regardless of relay.
Questions about this page? Get in touch.