Seguridad y subencargados

1. Modelo de responsabilidad compartida

La seguridad de Ressearch AI combina controles de plataforma, proveedores cloud y decisiones del usuario. La plataforma protege la infraestructura, sesiones, almacenamiento, procesamiento, logs y límites técnicos razonables. El usuario protege qué datos carga, qué integraciones conecta, qué permisos concede y dónde publica sus resultados.

Las funciones de exportación, enlaces compartibles, repositorios externos, tokens, credenciales y herramientas científicas de terceros requieren atención especial porque pueden mover información fuera del perímetro principal de Ressearch AI.

2. Subencargados y proveedores críticos

La lista puede evolucionar a medida que el producto cambia. Los agrupamos por la sensibilidad de los datos que reciben. Algunos actúan como encargados/subencargados y otros como responsables independientes para sus propios fines (Culqi, GitHub, Zotero).

• Contenido completo del usuario — Supabase: autenticación, base de datos, storage, control de sesión, políticas de acceso (RLS), pgvector e indexación contextual. Es el núcleo de almacenamiento.
• Contenido completo del usuario — Google Cloud — Gemini Enterprise Agent Platform (anteriormente Vertex AI): proveedor único de inferencia generativa, embeddings (text-embedding-004) y procesamiento multimodal. Cuando se habilita la familia Claude, se sirve vía Vertex AI Model Garden, por lo que Google es el único destinatario de inferencia; no hay envío directo a Anthropic ni a Google AI Studio.
• Contenido completo del usuario — E2B: ejecución aislada de código Python/R inline, notebooks y artefactos. Los datasets y el código del usuario se copian al contenedor para ejecutarse.
• Contenido completo del usuario — Modal: trabajos largos, cargas pesadas, perfiles especializados y GPU. Puede crear volúmenes de checkpoint por sesión que conservan datos entre ejecuciones.
• Datos acotados — Culqi: pagos, tokenización de tarjetas, suscripciones, cargos y recargas (responsable independiente para el procesamiento de pagos; PCI DSS).
• Datos acotados — GitHub y Zotero: integraciones que el usuario habilita; reciben lo necesario para repositorios o referencias y se rigen por sus propias políticas.
• Datos acotados — Resend: envío de correos transaccionales (p. ej. invitaciones de equipo); recibe direcciones de correo.
• Datos acotados — Inngest: orquestación de trabajos en cola, reapers y conciliación; recibe identificadores de proyecto/job y payloads de orquestación.
• Solo términos de consulta — APIs científicas externas (PubMed/NCBI, Crossref, OpenAlex, Semantic Scholar, Europe PMC, DOAJ, arXiv, ClinicalTrials, Unpaywall, SciELO ArticleMeta, PubChem, GBIF, RCSB PDB, AlphaFold, UniProt, Ensembl, ChEMBL): reciben términos de búsqueda, DOIs o identificadores, nunca tus datasets o documentos.
• Infraestructura y analítica — Railway (hosting), Cloudflare (CDN/seguridad de borde), Google Analytics (solo rutas públicas de marketing, sujeto a consentimiento de cookies) y monitoreo de disponibilidad que solo consulta endpoints de salud. La observabilidad interna del producto se almacena en Supabase, sin SDK de terceros.

3. Controles técnicos principales

• Autenticación mediante Supabase y proveedores OAuth habilitados por el producto.
• Separación lógica de datos por usuario, cuenta, proyecto y organización, de acuerdo con las políticas de acceso del backend.
• Ejecución de código en entornos de sandbox diseñados para aislar análisis de la infraestructura principal.
• Firmado o control de acceso para descargas y artefactos cuando la funcionalidad lo requiere.
• Validaciones de archivo, cuotas, límites de crédito, restricciones de plan y controles antifraude.
• Observabilidad de navegador y backend para detectar errores, abuso, fallas de rendimiento y anomalías operativas.

4. Datos enviados al proveedor de IA

Cuando una función de IA se activa, Ressearch AI puede enviar al proveedor de modelos —Google Cloud — Gemini Enterprise Agent Platform (anteriormente Vertex AI)— el prompt, la selección del usuario, archivos adjuntos, fragmentos de papers, resultados previos, memoria del proyecto, instrucciones del sistema, metadatos de herramienta y contexto suficiente para completar la tarea.

El producto está diseñado para enviar contexto útil, no historiales completos sin necesidad. Aun así, ciertas tareas complejas pueden requerir fragmentos amplios de documentos, tablas, datasets o resultados para producir una respuesta coherente. Bajo los términos empresariales de Google Cloud aplicables a Vertex AI / Gemini Enterprise, el contenido no se utiliza para entrenar los modelos fundacionales de Google ni se comparte con otros clientes, y el cliente controla la región de residencia de los datos en reposo.

5. Datos que requieren evaluación previa

• Datos de salud identificables, datos biométricos, datos genéticos atribuibles a personas, información de menores o expedientes clínicos.
• Datos cubiertos por contratos de confidencialidad, secretos empresariales, información prepublicación o resultados patentables.
• Bases de datos personales masivas, credenciales de terceros, material regulado o información sujeta a normas sectoriales estrictas.
• Contenido que una revista, universidad, comité ético, financiador o empleador prohíba procesar en herramientas externas de IA.

6. Repositorios, enlaces y artefactos públicos

Algunas salidas pueden exportarse a GitHub, descargarse como paquetes reproducibles o compartirse mediante URL directa. Si el usuario elige un repositorio público, comparte un enlace o incorpora información sensible en una figura pública, la exposición puede ser irreversible o quedar fuera del control de Ressearch AI.

Antes de publicar, el usuario debe revisar datasets, notebooks, imágenes, tablas, variables, nombres de archivo, metadatos, comentarios, commits y licencias incluidas en el paquete exportado.

7. Contraseñas, tokens y credenciales

El usuario no debe pegar llaves API, contraseñas, tokens de producción, credenciales institucionales o secretos de terceros en prompts, notebooks o datasets, salvo que la función lo requiera y exista autorización válida. Cuando una integración almacena tokens técnicos, estos se tratan para operar la conexión elegida por el usuario.

8. Disponibilidad y resiliencia

Ressearch AI depende de proveedores externos de nube, IA, pagos, sandboxes, autenticación y red. Puede haber degradaciones por mantenimiento, límites de proveedor, cambios de modelo, fallas regionales, consumo excesivo, actualizaciones o incidentes de terceros.

La plataforma puede suspender tareas, bloquear exports, pausar sandboxes o limitar funciones cuando sea necesario para proteger seguridad, costos, disponibilidad, cumplimiento o integridad del servicio.

9. Vulnerabilidades y reportes

Los reportes de vulnerabilidades, exposición accidental, abuso de cuenta o sospechas de acceso indebido deben enviarse a [email protected]. Incluye descripción, pasos de reproducción, impacto, URLs, capturas y cualquier indicador técnico disponible. No realices pruebas destructivas, exfiltración de datos, persistencia, ingeniería social o acceso a información de terceros.

10. Certificaciones y estado de madurez

Ressearch AI está en evolución activa. Nuestros subencargados principales sí mantienen certificaciones (por ejemplo, Google Cloud: ISO 27001/27017/27018/27701, SOC 2/3 y BAA HIPAA; Supabase: SOC 2 Tipo II y HIPAA bajo add-on; E2B y Modal: SOC 2 Tipo II), pero la certificación de un proveedor no equivale a la certificación de Ressearch AI como producto.

El estado real y honesto de nuestras propias certificaciones (ISO 27001, ISO 42001, ISO 27701, SOC 2) y de la disponibilidad de un BAA enterprise se publica en el Centro de Confianza. Si una certificación, auditoría, BAA, DPA enterprise o despliegue regional específico no aparece expresamente confirmado allí o en un contrato, no debe asumirse como disponible. No mostramos sellos que aún no hayamos obtenido.

Las instituciones con requisitos formales de procurement, residencia de datos, DPA firmado, revisión de subencargados, SSO, auditoría o controles sectoriales deben coordinar una evaluación previa antes de cargar datos regulados.