SERA 1 Privacy Policy
Effective date: January 3, 2026
Version: 1
This document defines how SERA 1 collects, processes, stores, secures, retains, and disposes of personal and conversational data. It is intended to describe the data lifecycle and the controls that SERA 1 applies or enables. This is a technical and contractual template and does not constitute legal advice. Parties should obtain independent legal review before relying on this document.
1. Purpose and scope
This policy applies to personal data and derived artifacts that SERA 1 receives, generates, or stores when deployed in enterprise environments. The policy covers data collection, ingestion, transformation, storage, access, retention, deletion, security, audit, and transfer. This policy does not prescribe operational investigative practices or instruct operators on product usage.
2. Roles and responsibility for data
1. Provider responsibilities:
The provider is responsible for the design, delivery, and secure maintenance of the SERA 1 software, for documenting technical characteristics relevant to data handling, and for implementing the technical controls described in this policy when those controls are included in the licensed software. The provider will not access client raw conversational data unless explicit, written agreement permits it and a Data Processing Agreement is in force.
2. Client responsibilities:
The client is the data controller for personal data ingested into SERA 1. The client is responsible for establishing and documenting the lawful basis for processing, for obtaining any required consents or legal authorizations, and for complying with applicable data subject rights. The client must use the technical controls provided by SERA 1 to meet legal obligations.
3. Subprocessors and third parties:
Any provider use of subprocessors for maintenance, updates, or support that involves client data requires prior written client authorization and a contract that imposes equivalent data protection obligations.
3. Data types and sources
1. Ingested content:
SERA 1 processes conversational text and related metadata that the client explicitly ingests. No external data collection occurs by default.
2. Derived data:
SERA 1 produces derived artifacts such as risk scores, context maps, behavioral indicators, and training labels. These derived artifacts are treated as data for the purposes of this policy.
3. Hard negatives:
Datasets labeled as hard negatives are lawful adult-to-adult materials used to evaluate or calibrate the model. Provenance, consent, and documentation for these datasets must be retained by the client.
4. Collection and minimization
1. Minimal necessary principle:
SERA 1 supports configuration to ingest only the data fields necessary for the stated, documented purpose. Default configurations favor minimized ingestion and storage.
2. Provenance and documentation:
For every dataset ingested for model evaluation or training, provenance metadata shall be recorded, including source, date of collection, lawful basis, and consent status where applicable.
5. Storage and encryption
1. Local storage model:
SERA 1 is designed to keep raw conversational data and derived artifacts on client-controlled infrastructure when deployed in on-premise or closed-network configurations. Any transfer to provider infrastructure requires explicit written agreement.
2. Encryption at rest:
All persisted data shall be encrypted at rest using industry-standard symmetric encryption. The client shall manage encryption keys unless a separate key management agreement assigns responsibility to the provider under explicit contractual terms.
3. Encryption in transit:
All network communications for administrative access, updates, and optional telemetry shall use strong transport encryption. Mutual authentication for administrative channels is required.
4. Key management and access to decrypted data:
Access to decrypted data is restricted to authorized processes and users. Key rotation, secure backup of keys, and documented procedures for emergency key recovery are required.
6. Retention, archival, and deletion
1. Retention policy framework:
SERA 1 provides configurable retention settings for raw data, derived artifacts, and audit logs. Default retention settings are conservative and require documented justification for any extended retention.
2. Default retention windows:
Unless a different lawful requirement applies and has been documented, audit logs shall be retained for at least six months and investigative context files for a period justified by law and documented in the record of processing activities.
3. Archival and pseudonymization:
For long-term retention, the system supports secure archival and irreversible pseudonymization of personal identifiers upon client instruction and where compliant with legal obligations.
4. Deletion and legal holds:
The system supports logical and physical deletion workflows. Legal holds must be documented and limited to the scope required by competent legal authorities. Deletion requests from data subjects must be executable by the client using provided tooling, subject to lawful exceptions and documented legal holds.
7. Access control and authentication
1. Principle of least privilege:
Role based access controls are enforced. Each human user or system process receives the minimal privileges required to perform their documented duties.
2. Strong authentication:
Administrative and moderator interfaces require multi-factor authentication and session controls that expire after inactivity.
3. Privileged operations:
Sensitive operations such as export, deletion, and configuration changes require separate authorization steps and are logged immutably.
8. Auditability and logging
1. Immutable audit logs:
The system generates tamper-evident audit logs for data ingestion, data access, human reviews, threshold or configuration changes, and export operations. Logs include actor identity, timestamp, action, and rationale when applicable.
2. Log retention and access:
Audit logs are retained for the configured retention period and are accessible only to authorized audit personnel and independence reviewers under controlled conditions.
9. Security measures and integrity
1. Secure development lifecycle:
Provider development follows secure development practices, includes code review and security testing, and avoids embedding hard-coded secrets in distributed artifacts.
2. Anti-tampering:
The software includes integrity verification mechanisms for code and configuration. These mechanisms protect against unauthorized modification without masking system behavior or evading lawful transparency.
3. Host and network security:
The client is responsible for host hardening, network segmentation, intrusion detection, and physical security. The provider documents recommended security baselines and hardening checks.
10. Model transparency, explainability, and anti-evasion
1. Explainability artifacts:
The provider supplies non-sensitive explanations of output factors and performance metrics so decisions using derived artifacts can be interpreted, audited, and contested. The provider will not publish operational trigger lists or configuration values that would materially increase risk of evasion.
2. Anti-evasion trade-off:
Security measures that limit disclosure of operational details are balanced with obligations for regulatory transparency and auditability. Any decision to withhold information for security reasons shall be documented and legally reviewed.
11. Data subject rights and support tooling
1. Support for rights:
The system provides tools to locate subject data, produce exports in standard formats, and effect rectification or deletion as directed by the client acting as controller. These tools are operational; legal determination required for whether a request is valid rests with the client.
2. Documentation for client responses:
The provider supplies API and administrative documentation to support timely client responses to data subject requests.
12. Telemetry, support, and provider access
1. Telemetry by default:
The software does not transmit raw conversational content to provider systems unless the client opts in explicitly. Telemetry, if enabled, is limited to diagnostic metadata and crash reports and excludes raw user data.
2. Support access:
Any remote support access that could expose client data requires explicit prior written consent, a scoped access window, and audit logging. Such access is governed by a Data Processing Agreement.
13. Subprocessors and third-party components
1. Third-party components:
The provider will maintain an inventory of third-party components and libraries used in SERA 1 and will disclose high-risk dependencies on request. Security updates for third-party components shall be applied as part of routine maintenance.
2. Subprocessor engagement:
Use of subprocessors that handle client data requires client approval, documented contracts with equivalent protections, and a public subprocessor list.
14. Breach notification and incident response
1. Provider incident obligations:
If a provider-controlled system experiences an incident with the potential to affect client data, the provider will notify the client promptly and provide forensic data necessary for client assessment.
2. Client obligations:
The client, as data controller, is responsible for regulatory breach notifications and for documenting the breach assessment and remedial actions. The provider will cooperate and provide logs and evidence subject to any lawful restrictions.
15. Cross-border transfers and export controls
1. Transfers:
Any transfer of personal data outside the jurisdiction where it was collected requires documented transfer mechanisms compliant with applicable law. Cross-border transfers for backups or support require prior client authorization.
2. Export controls and lawful requests:
The provider and the client will document procedures for responding to lawful requests for access to systems or data while protecting data subject rights and complying with applicable legal processes.
16. Data used for model improvement
1. Local improvement only:
By default, model improvement training using client data occurs only on client infrastructure with client authorization. Any use of client data for centralized model improvement requires separate, explicit contractual consent and lawful basis.
2. Federated learning and aggregate telemetry:
If federated learning or aggregate model telemetry is implemented in the future, mechanisms will ensure that no raw personal data leaves client infrastructure and that updates are differentially private and non-identifying.
17. Records and assessments
1. Record of processing activities:
The system generates and exports records to support client maintenance of a record of processing activities.
2. Impact assessments:
The provider supplies technical input for Data Protection Impact Assessments and for equivalent fundamental-rights impact assessments. The client remains responsible for conducting and filing such assessments where required.
18. Limitations and liability
1. No guarantee of legal compliance:
Technical controls cannot ensure legal compliance in all jurisdictions or under all factual circumstances. Compliance determinations and lawful authorizations are the responsibility of the client.
2. Provider warranties:
The provider warrants that the software implements the data handling mechanisms described in this policy, is delivered free from intentionally malicious code, and will maintain security measures in line with reasonable industry practices. Contractual terms will set limitations and allocation of liability.
19. Amendments and governance
This policy will be updated as laws, standards, and technical capability evolve. Material changes to data handling practices will be documented and communicated to clients. The provider and client will coordinate to ensure that contractual terms reflect any material changes.