Security and privacy architecture: preparing for IRB review | DATASPHERES AI - Dataspheres AI

Supports Module 1 objectives; aligned to CLO 1. This lesson documents the platform's security and privacy controls at the level of detail an IRB applicati...

Supports Module 1 objectives; aligned to CLO 1. This lesson documents the platform's security and privacy controls at the level of detail an IRB application or a methods reviewer requires, and identifies the responsibilities that remain with the researcher. Claims here describe technical mechanisms, not certifications. 1. Access control Role-based membership. Four roles (Owner, Admin, Moderator, Participant) are stored per member per datasphere and enforced server-side on every API route. There is no client-side-only gating of research data. Per-document authorization. Access to a recording, transcript, or analysis requires either uploader identity or qualifying membership in the document's datasphere, checked on each request. Private by default. New dataspheres and their contents are non-public. Public visibility is an explicit, per-artifact setting; a private artifact's public URL returns not-found, including to logged-in non-members. 2. Authentication Interactive sessions use signed tokens. Programmatic access uses API keys that are stored hashed, scoped to specific capabilities, revocable, and expiring. A key acts with exactly its owner's permissions, never more. 3. Storage and transport Research files are stored in private object storage (AWS S3, us-east-1); direct object URLs are not publicly readable, and access flows through the authenticated API. Data in transit is TLS-encrypted. Data at rest is covered by S3 server-side encryption. Application infrastructure is hosted in the United States (Render, Virginia; AWS us-east-1). State data locality in your protocol if your participants are outside the U.S. 4. Third-party AI processing — the data-flow disclosure This is the section reviewers probe. Disclose it plainly in your protocol: Transcription, translation, and analysis send content to external AI providers for processing: speech-to-text vendors for audio and large-language-model providers for text and low-resource-language audio. Processing occurs under the vendors' commercial API terms, which as of this writing exclude the use of API-submitted data for model training. Verify the current terms of each vendor named in your protocol at submission time. No AI processing is automatic upon upload of audio and video: transcription and analysis are researcher-initiated actions, so a protocol can specify exactly which materials are processed and when. 5. Advanced controls: AI endpoint overrides and private hosting Model and endpoint overrides. AI processing is not fixed to a single vendor. Administrators can configure which model serves each task class (transcription, analysis, translation), and members can select models per message. Institutions can supply their own provider API keys, in which case AI processing runs under the institution's own vendor agreement and data-processing terms rather than the platform defaults. Self-hosted inference. The model-routing layer supports locally hosted models, allowing configurations in which analysis text never leaves institution-controlled infrastructure. Private and secure hosting. For protocols requiring complete data isolation - dedicated instances, restricted processor lists, or contractual data-processing agreements - contact Dataspheres AI support to arrange a configuration reviewed against your requirements. For an IRB conversation, this changes the shape of the answer: if a review board's concern is a specific third-party processor, the processor can be replaced, brought under an institutional agreement, or removed from the data path. 6. Audit and attribution AI operations are logged, metered, and attributable to the member account that initiated them. Analytical artifacts carry provenance: coded segments store the applying account, timestamp, exact quote, character offsets, memo, and confidence value. The chain from recording to published figure is inspectable in both directions. 7. Publication controls Publication is deliberate and artifact-specific. A study can keep every recording, transcript, and coded segment private while publishing only an aggregate report, presentation, or course. 8. Researcher responsibilities and limitations IRB approval is per-protocol. The platform has been used in IRB-approved research protocols; that does not transfer approval to your study. Your IRB reviews your design, consent instruments, and data management plan. De-identification is your task. Transcripts reproduce what participants said, including names. Pseudonymization and redaction decisions belong to the research team and should be stated in the protocol. Consent language should cover AI processing. If recordings will be machine-transcribed or machine-translated, say so in the consent form. Certifications. The platform does not claim HIPAA, FedRAMP, or similar certifications. Studies subject to those regimes require a compliance review before use. Retention and deletion. Owners can delete documents and artifacts; define your retention schedule in the protocol and e