Where does our client data live, and who can see it?

    By default, every engagement runs inside your tenancy — your cloud account (AWS, Azure, or GCP), your VPC, your CRM, and your carrier connections. We never pool client PII across customers, and access is scoped to a named engineering team under signed BAAs and NDAs. If you require an on-prem or sovereign deployment, that is a first-class option, not a custom upcharge.

    What does 'inside your tenancy' actually mean?

    It means the system is deployed into infrastructure you already own and already audit. Your cloud account, your VPC, your identity provider, your CRM, and your carrier connections. Mindfulware does not operate a multi-tenant platform that your data is loaded into, so there is no Mindfulware-side database holding your client records, and no shared vector store where one firm's book sits next to another's.

    The practical consequence is that your existing controls keep applying. Network policy, key management, logging, retention, and egress rules are the ones your security team already wrote. Nothing has to be re-argued because a vendor needed data moved somewhere else to make their product work.

    Who at Mindfulware can reach the environment?

    Access is scoped to a named engineering team, under signed BAAs and NDAs, and it is granted through your identity provider rather than through a vendor back door. Role-based access with SSO and MFA is a standard control on every engagement, alongside field-level encryption at rest, TLS 1.2 and above in transit, and tokenization of identifiers before they reach any model.

    Everything that team does is logged. Every AI-assisted output is recorded with prompt, response, model version, and reviewer action, so your compliance team can reconstruct any interaction without asking us for an export. Audit logging is not an add-on tier here; it is how the systems are built, because the reference clients are regulated and would not accept anything else.

    How is restricted data handled?

    NPI, PHI, and HNW client data are treated as restricted by default rather than by exception. For health-adjacent workflows — long-term care, disability, and life underwriting — we operate under HIPAA BAAs and minimum-necessary data principles, which means the system is given the narrowest field set that makes the workflow work, not a full table because a full table was easier to pipe.

    Your data is also never used to train shared or third-party foundation models. When we fine-tune, we fine-tune private models inside your environment, on your data, for your use only. When we use hosted LLMs, we use providers and endpoints that contractually disable training on inputs, and we route through a gateway that enforces it.

    What does this architecture rule out?

    Naming what we do not build is more useful than describing what we do. We do not build a Mindfulware-hosted middle tier that your client data passes through. We do not pool records across customers to improve a shared model. We do not ship a system whose outputs cannot be reconstructed after the fact. And we do not treat an on-prem or sovereign requirement as an exotic request that carries a surcharge — for some clients it is the only acceptable deployment, and it is supported as a first-class option.

    During onboarding we can provide architecture diagrams, data-flow maps, pen-test summaries, and sub-processor lists, which is usually the fastest way for a security reviewer to confirm all of the above rather than take it on assertion.

    Have a specific question?

    Book a 30-minute consultation with the founder, or send a note.