Ownership review
Identify source ownership, third-party rights, contractual restrictions and restricted data classes.
Trust architecture
Rights-cleared by design.
Every environment begins with ownership, permitted use, privacy and access boundaries. Those controls remain connected to the derived tasks, trajectories and verifiers throughout the lifecycle.
Our principle
Privacy transformation cannot cure unclear ownership. Security controls cannot cure overbroad permitted use.
Sofitra treats rights, lineage, transformation and technical access as one connected system, not separate legal and engineering workstreams.
Rights lifecycle
A controlled path from source to environment.
Each stage has a documented purpose, owner, input, output and release gate.
Permitted use
Define purpose, duration, geography, exclusivity, buyers, models and onward delivery.
Classification
Map personal, regulated, customer-owned and excluded data.
Transformation
Remove, replace, aggregate or synthesise identifying data while preserving workflow logic.
Validation
Human and automated review for leakage, integrity, utility and scope compliance.
Controlled delivery
Release only approved derivative assets through buyer-specific access and terms.
Audit and retire
Track lineage, versions, access, retention, deletion and end-of-term obligations.
Control model
Data owner, derived environment and buyer stay distinct.
The environment is designed to expose the approved workflow and task, not unrestricted access to the source archive.
Partner data
The authorised source remains segregated and governed by the partner agreement.
- Source-specific permissions
- Named systems and date ranges
- Explicit exclusions
- Retention and return rules
Environment assets
Tasks, state and artifacts are transformed, versioned and traceable to permitted sources.
- Privacy-safe data universe
- Approved derivative scope
- Lineage and transformation records
- Release-gate review
Buyer runtime
Buyers receive only the approved environment surface, subject to their access terms.
- Buyer-specific isolation
- Role and tool restrictions
- Logging and monitoring
- Expiry and revocation controls
Core safeguards
Designed for both sides of the marketplace.
Data partners need control over their assets. AI labs need evidence that the environments they receive are usable, traceable and appropriately governed.
Rights and provenance
Documented source ownership, contractual basis, permitted use, exclusions, transformation authority and delivery scope.
Privacy transformation
Entity replacement, field suppression, aggregation, controlled synthesis and leakage review according to the asset.
Access segregation
Role-based access, least privilege, environment separation, secure transfer and buyer-specific controls.
Lineage and auditability
Source-to-task traceability, version history, transformation records, approval gates and access logs.
Procurement readiness
Evidence for legal, security and research review.
A private diligence pack can be configured to the engagement and the actual controls in place. Certification claims are made only once they are formally achieved and approved.
Data and environment cards
Source classes, intended uses, transformations, limitations and version information.
Architecture and data flow
Processing boundaries, storage, runtime components, access paths and deletion flow.
Rights documentation
Permitted-use summary, exclusivity, onward delivery, publicity and retention conditions.
Control evidence
Privacy review, release-gate checks, lineage samples, access logs and incident procedures.
Frequently asked
Security and rights questions.
The answers below describe the standard operating model. Final terms and control commitments are defined in each executed agreement.
Not by default. The standard design is to provide an approved derivative environment containing the data and tools needed for the task. Any raw-data access would require a separate, explicit permitted-use basis and access model.
Yes. Exclusions can be defined by source system, customer, geography, date range, field, document type, workflow or other identifiable boundary before ingestion and transformation.
The objective is to remove or replace identifying data while preserving relationships, distributions, dependencies, exceptional cases and task difficulty. The technique therefore varies by data class rather than relying on one universal anonymisation step.
Yes. Commercial and technical controls can reflect buyer-specific, domain-specific, model-specific, time-limited or exclusive arrangements, subject to the final agreement and delivery architecture.
Derived artifacts receive lineage metadata linking the task family and environment version to the approved source set and transformation history. The buyer need not see source identity for Sofitra to preserve that internal traceability.
Diligence pack
Review the controls behind the environment.
Request a security, rights and data-flow briefing tailored to a lab engagement or data partnership.