We do not use submitted API content to train or improve detection models.
We do not use submitted API content to train or improve detection models. Our processing and retention controls are designed to enforce this commitment. The data-handling policy describes retained metadata, subprocessors, and available assurance evidence.
How the commitment is enforced
The commitment is carried by operating controls, not by an opt-out flag. Each control has an internal owner and evidence that security can produce on request (permissions, logging configuration, data-flow diagrams, and retention tests).
Request path (API)
- Handles incoming detection requests
- Runs pinned, immutable analysis configurations
- Submitted text is processed in memory and not persisted
- Access to offline development systems is restricted by permissions and reviewed
Model development (offline)
- Runs on separate infrastructure under separate permissions
- Uses documented, licensed corpora only
- Development datasets are reviewed for source and lineage before inclusion
- Submitted API content is not an input to model development
What enters the request path from offline work is a versioned, immutable configuration — released through published updates, not through usage.
WHY THIS IS DIFFERENT
A commitment with controls, not an opt-out
At some API providers, "we don't train on your data" is a contractual or configuration-level setting that can vary by product tier, can change, or may not cover consumer-facing surfaces. What a given provider actually does depends on that provider's terms and controls.
At Sentiqra there is no opt-out to configure and no tier where the answer changes: submitted API content is excluded from model development for every request, on every plan. Processing controls - in-memory handling, separated permissions, and the retention schedule - are designed to enforce this, and the data-handling policy describes the evidence available.
We describe this as a commitment backed by controls rather than a mathematical impossibility: no public API response can prove internal storage behavior. What we can offer is the policy, the control design, and assurance evidence - including reproducible outputs and signed receipts that make analysis behavior auditable.
What we do train on
Our models are trained exclusively on:
Curated proprietary datasets
Produced in-house by our taxonomy and linguistics team. Every entry is reviewed, labeled, and documented.
Explicitly licensed corpora
Commercial language datasets with clear licensing terms. No scraped web content. No opaque third-party arrangements.
Controlled synthetic data
Produced under documented internal processes during training-data preparation only. No generative model is used to produce classifications. All synthetic data is reviewed before inclusion.
Public domain reference texts
Used for language coverage and quality. No user-generated content from any platform.
Every training corpus is documented with source, license, and processing lineage. This documentation is available to Enterprise customers and may support AI Act Article 10 data governance documentation.
The development datasets above are distinct from any inherited pretrained-component lineage: where a third-party pretrained component is used as a starting point, its upstream training lineage is governed by that component's license and documented separately. Submitted API content is not part of either.
COMPLIANCE IMPLICATIONS
What no-training means for your obligations
EU AI Act
Article 10 requires data governance documentation. Since no customer data enters the training pipeline, our published training corpus documentation may help reduce the scope of what you need to document - your own obligations depend on your deployment.
GDPR
Excluding submitted content from model development reduces the surface for training-data-related claims. Rights around automated decision-making (e.g. GDPR Article 22) are unaffected by this commitment - they depend on your decision process and deployment, not on whether we train on inputs.
Confidentiality
Submitted content is excluded from model development under the commitment above, and the analysis configuration changes only through published versioned releases - not through usage. Submitted content is not persisted after the response completes (bounded idempotency replay copies excepted - see the data-handling policy).
IP contamination
Because submitted content is not added to development datasets, using the API does not contribute your content - or third-party content it may contain - to model development.