Enterprise AI shouldn't require giving every agent everything your organization knows.
DM is designed around data minimization, purpose limitation, scoped access, human approval, and customer-defined deployment boundaries. Only the permitted knowledge that applies to the task should be activated.
Privacy is an architectural constraint, not a footer claim.
DM's architecture is designed around the GDPR principle of data protection by design and by default: minimize what is processed, keep purpose and scope explicit, restrict access, and make data boundaries visible. We do not claim GDPR certification or an audited compliance status — this is an architectural commitment, and formal compliance claims are made only where legal and technical documentation support them.
Evidence you choose
DM operates on evidence users intentionally add, or sources explicitly configured for the workflow — a document, transcript, ticket, or connector you turn on. There is no background crawl of your whole workspace.
The smallest useful subset
A task should receive what is current, relevant, in-scope, and authorized — not the whole knowledge store. Out-of-scope or unauthorized knowledge stays out. This is a context-quality advantage and a privacy advantage at once.
Agents propose. Humans decide.
Agents may propose candidate knowledge from evidence or their own work. A human reviews, edits, rejects, or approves. Nothing is autonomously promoted to authoritative organizational knowledge, and every change stays traceable to its provenance.
Scoped and permission-aware
Every record carries the scope it applies to. Retrieval is permission-aware, and nothing crosses a tenant or workspace boundary it wasn't approved for.
Data boundaries and deployment.
One maturity model, used everywhere on this site: what runs today, what we provision with you during onboarding, and what is still planned.
Available now
Running in DM today.
- Managed DM AuzzurA operates the DM application and its data stores for you. Managed deployments can be provisioned in an EU cloud region. All plans
- Control and Knowledge kept apart Account and workspace control data and your Knowledge — Decisions, Rules, Skills and their evidence — live in physically separate databases. All plans
- Workspace-bound Knowledge Store Each workspace resolves to its own Knowledge Store binding. A missing or broken binding fails closed — it never falls back to another workspace’s store. All plans
Provisioned during onboarding
Built and tested. Set up with AuzzurA for your workspace — not self-service.
- Dedicated Knowledge Store Your workspace Knowledge on its own database instance, provisioned and migrated with AuzzurA. Business · Enterprise
- Customer-controlled Knowledge Store (BYODB) Your Knowledge on a supported database you control, connected to DM and migrated with AuzzurA during onboarding. Enterprise
Planned
Architecture direction. Not available yet.
- Bring Your Own Key (BYOK) Customer-managed encryption keys for your Knowledge.
- Bring Your Own Model (BYOM) Your own model provider or approved model endpoint for AI-assisted steps.
- Customer-operated DM Running the full DM application inside your own environment, and self-service store provisioning.
- Retrieval is permission-aware: an agent or user only reaches what their scope authorizes.
- Provisioning a dedicated or customer-controlled Knowledge Store, and migrating existing Knowledge into it, is done with AuzzurA during onboarding — there is no self-service store setup yet.
Evidence & onboarding.
- The evidence boundary — what can be used, and what stays out — is agreed with you before any evidence is shared.
- Residency, retention, access, and deletion requirements are agreed in writing as part of your customer agreement.
- Confidential, customer, or sensitive data should not be submitted through the public website forms — every deployment has its own designated evidence channel.
What is sent to models?
What can reach an LLM
Only the permitted, in-scope subset of governed knowledge resolved for the specific task — not the full knowledge store — is sent to the configured model to draft a candidate or generate a response.
Model training
We do not publish a blanket model-training guarantee here. Provider configuration, logging, and retention behavior are documented and agreed as part of your deployment. Bring Your Own Model — using your own provider contract to govern training and retention directly — is planned, not available yet.