DevAI Suite — White Paper de Seguridad

Versión 1.1 — Octubre 2026 Clasificación: Pública · seguro para compartir con clientes potenciales, clientes y auditores.

Resumen ejecutivo

DevAI Suite es la primera plataforma Manufacturing-as-a-Service (MaaS) — un entorno unificado de gestión de programas APQP, excelencia de proveedores e inteligencia de planta para fabricantes de automoción y aeroespacial. La plataforma maneja datos regulados de manufactura (envíos PPAP, libros FMEA, cualificación de proveedores, telemetría de planta) para clientes que operan bajo IATF 16949 y AS9100 / AS9145.

Este white paper documenta cómo se diseña y opera DevAI Suite para proteger esos datos. Está estructurado conforme al NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) y mapea cada función a controles, tecnologías y prácticas operativas concretas. Cuando hay certificaciones pendientes lo decimos honestamente con un calendario defendible en lugar de exagerar.

La audiencia prevista son los equipos de revisión de seguridad empresarial, las funciones de gestión de riesgo de proveedores y los responsables de compras durante la due diligence previa a la firma del contrato.

1. Govern — Programa de seguridad y rendición de cuentas

1.1 Propiedad de la seguridad

Un responsable de seguridad designado reporta al fundador/CEO y posee:

• Redacción y revisión de políticas de seguridad (cadencia anual; ad-hoc tras incidentes).
• Revisiones de riesgo de proveedores y decisiones de incorporación de subencargados.
• Coordinación de respuesta a incidentes.
• Gestión del programa de auditoría y certificación.
• Respuestas a cuestionarios de seguridad de clientes.

El rol platform-admin está vinculado a una cuenta de usuario específica vía la flag is_platform_admin (que reemplaza la verificación obsoleta por comparación de email); el privilegio deriva de la fila de base de datos, no del email. En producción el rol queda cubierto por MFA a través del requisito de MFA de la propia organización de DevAI; es un ajuste de organización, no una regla fijada en el código para el rol.

1.2 Políticas en vigor

Las políticas se mantienen bajo control de versiones y son revisadas por el responsable de seguridad antes de cada ciclo de release. Los extractos elegibles para clientes están disponibles bajo NDA.

1.3 Seguridad del personal

• Verificaciones de antecedentes para personal que maneja datos regulados de cliente.
• Acuerdos de confidencialidad firmados al inicio del contrato.
• La incorporación incluye formación en concienciación sobre seguridad; refresco anual.
• El aprovisionamiento de acceso sigue el principio de menor privilegio; revisión trimestral de accesos.
• La baja se automatiza cuando es posible (de-aprovisionamiento SSO, rotación de secretos, revocación de repositorios).

1.4 Hoja de ruta de cumplimiento y certificación

Para los nombres de las firmas de auditoría, las narrativas de control y los paquetes de evidencia pre-auditoría, contactar con admin@devaisuite.com.

2. Identify — Gestión de activos y riesgo

2.1 Inventario de activos

La superficie de activos de la plataforma está acotada e inventariada:

• Apps de aplicación: devai-api (backend FastAPI) y devai-web (frontend Next.js) en Fly.io (Frankfurt FRA); la consola de administración (admin.devaisuite.com) y el sitio de marketing (devaisuite.com) en Cloudflare.
• Almacenes de datos: Neon Postgres (Frankfurt, aws-eu-central-1) para todos los datos relacionales incluidos los logs de auditoría; buckets de Cloudflare R2 en jurisdicción UE: devai-templates-eu (biblioteca global de plantillas, más archivos adjuntos en el chat de IA y documentos de proceso heredados), devai-tenant-docs-eu (documentos y modelos por org), devai-db-backups-eu (copias nocturnas de la base de datos) y devai-object-backups-eu (copias nocturnas fechadas de los dos buckets de documentos).
• Caché / colas: Redis alojado en Upstash (Estados Unidos) para los contadores de rate limit, valores en caché de corta duración y la difusión de mensajes en tiempo real entre las máquinas de la API; Inngest (orquestación de jobs en background, Estados Unidos).
• Proveedores externos: ver §7 Gestión de proveedores y subencargados.

La lista pública de subencargados, con la finalidad, los datos implicados y la región de tratamiento de cada proveedor, está en /subprocessor-list.html; §7.2 recoge la misma lista.

2.2 Clasificación de datos

2.3 Gestión de riesgos

Los riesgos materiales se llevan en un registro interno revisado trimestralmente. Principales elementos a 2.º trim. 2026:

• Postgres en una sola región — punto único de fallo para la capa de base de datos; mitigado por el historial Point-in-Time de 24 horas de Neon, un volcado nocturno en un segundo proveedor (30 diarios / 12 mensuales) y una restauración documentada. La multi-región está en la hoja de ruta cuando la escala de cliente lo justifique.
• Dependencia de proveedor LLM — el AI Coordinator depende de la API de modelos de un tercero: Together AI es el proveedor por defecto. Si Together falla, los turnos que no necesitan llamar a herramientas pasan al modelo propio de DevAI servido en RunPod, allí donde sus credenciales estén configuradas; por defecto, los turnos con llamadas a herramientas no tienen proveedor de respaldo. Anthropic y OpenAI son solo de emergencia (break-glass): no son alcanzables salvo que un operador active el ajuste de emergencia, desactivado por defecto, o seleccione uno de ellos como proveedor de modelos.
• Bloqueo de dimensión de embeddings — el esquema de pgvector está fijado en 1024 dimensiones (Cloudflare Workers AI @cf/baai/bge-m3); un cambio de proveedor o de dimensión requiere un re-embed coordinado del corpus, documentado en el runbook de cambio de embeddings.

2.4 Modelo de amenazas

La plataforma se modela frente a:

• Atacantes externos — credential stuffing, account takeover, injection, SSRF, compromiso de la cadena de suministro.
• Tenants maliciosos o comprometidos — intentos de acceso a datos cross-tenant vía enumeración de API, RAG poisoning, prompt injection LLM.
• Amenaza interna — ingenieros sobre-privilegiados, personal que ha dejado la empresa.
• Compromiso de tercero — brecha de subencargado que afecte a nuestros datos.

Las mitigaciones se describen en las secciones correspondientes a continuación.

3. Protect — Controles

3.1 Multi-tenancy y aislamiento de datos

Los datos de cada cliente residen en una única base de datos PostgreSQL compartida, aislados mediante PostgreSQL Row-Level Security. Cada tabla con datos de cliente tiene una política RLS atada al contexto del tenant de la solicitud. La capa de aplicación define el tenant en cada sesión de base de datos a través del middleware de autenticación de la solicitud:

ALTER TABLE deliverables ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON deliverables
  USING (org_id = current_setting('app.current_org_id', true)::int);

Una solicitud que filtre el contexto del tenant (incluso por un bug interno de aplicación) no puede leer ni escribir filas pertenecientes a otro tenant — la base de datos lo rechaza. Las consultas SELECT cross-tenant devuelven cero filas por diseño.

RLS no está simplemente habilitado — está FORZADO (ALTER TABLE … FORCE ROW LEVEL SECURITY), y el rol de base de datos de la aplicación es explícitamente NOBYPASSRLS. Esto significa que ninguna ruta de código que se ejecute con credenciales de la aplicación puede eludir el aislamiento de tenant: incluso las operaciones privilegiadas de mantenimiento están sujetas a él. Se cumple en la práctica, no solo en la configuración — nuestras propias copias de seguridad automatizadas no pueden ejecutarse con credenciales de la aplicación: pg_dump se niega a exportar tablas con RLS forzado para un rol que no puede eludir RLS (verificado en CI el 2026-07-23), por lo que los backups se ejecutan bajo un rol propietario gestionado por el proveedor, controlado por separado, que nunca sirve tráfico de la aplicación.

Fallo cerrado por construcción. Cuando el contexto de tenant falta o se vincula mal, el fallo observable es la denegación (resultados vacíos, HTTP 403), nunca la exposición entre tenants. Los incidentes de producción de esta clase se han manifestado exclusivamente como funcionalidad no disponible para el tenant legítimo — la respuesta por defecto de la base de datos ante un tenant no vinculado es cero filas.

El helper app.db.tenant.set_tenant_context es el único punto por el que se aplica el contexto de tenant; se ejecuta en cada solicitud que resuelva un usuario, antes de que se ejecute cualquier lógica de negocio. Un job de CI (rls-postgres-pr) ejercita la postura RLS contra PostgreSQL real en cada pull request.

3.2 Almacenamiento de documentos por tenant

Los documentos para RAG viven en Cloudflare R2 con claves de objeto prefijadas por org_id. Las lecturas están limitadas por el mismo contexto de tenant, con una verificación en servidor antes de la emisión de cualquier presigned-URL.

Los embeddings (1024 dim, Cloudflare Workers AI @cf/baai/bge-m3) se almacenan en tablas pgvector que llevan una columna org_id bajo la misma política RLS que los documentos fuente.

3.3 Cifrado

En tránsito. TLS 1.2+ en todos los endpoints accesibles al cliente. Solo cipher suites fuertes (AES-GCM, ChaCha20-Poly1305). HSTS aplicado con max-age=31536000; includeSubDomains. La directiva preload se omite intencionadamente hasta que cada subdominio cumpla los criterios de elegibilidad. X-Frame-Options está en DENY y X-Content-Type-Options en nosniff en cada respuesta.

En reposo. Los datos de Postgres se cifran en reposo en la capa de almacenamiento de Neon. Cloudflare R2 cifra en reposo por defecto (AES-256). Las credenciales sensibles de integración almacenadas en integration_connectors.credentials_json se cifran mediante envelope con una clave Fernet por despliegue (DEVAI_CREDENTIALS_ENCRYPTION_KEY); la clave se rota en una cadencia documentada y nunca sale del store de secretos.

Gestión de claves. Las claves de aplicación (firma JWT, Fernet, secrets OAuth, API keys de terceros) se almacenan en Fly Secrets, se exponen al proceso en arranque y nunca se persisten en disco. Los procedimientos de rotación están documentados por proveedor en docs/runbooks/disaster-recovery.md §3.

3.4 Autenticación y control de acceso

Opciones de identidad:

• Email/contraseña — las contraseñas se hashean con PBKDF2-HMAC-SHA256 (passlib CryptContext), con sal aleatoria por contraseña y estiramiento de clave iterado; los hashes bcrypt de cuentas heredadas/migradas siguen siendo verificables. No se aplica historial de contraseñas; longitud mínima 12 caracteres con requisitos de complejidad (configurable por org).
• Google SSO vía OAuth 2.0.
• Microsoft Entra ID SSO vía OAuth 2.0 / OIDC, por defecto al tenant organizations (cuentas de trabajo/escuela) — las cuentas MSA personales se bloquean mediante el gate is_business_domain.
• Los usuarios solo-SSO tienen contraseña NULL y la ruta de login con contraseña los rechaza en lugar de ofrecer un fallback inseguro.

Autenticación multifactor. Basada en TOTP con códigos de respaldo de un solo uso, según la política de cada organización. La propia organización de DevAI la exige, y así queda cubierto el rol platform-admin en producción. La verificación MFA se ejecuta en la dependencia de auth en cada solicitud protegida; los usuarios con MFA habilitado pero no verificado solo pueden alcanzar los endpoints /auth/mfa/verify y /auth/mfa/status hasta que verifiquen.

Autorización basada en roles. Cada ruta protegida llama ensure_permission(db, user, resource_type, action, org_id) que verifica el grant rol-permiso del usuario contra la acción solicitada. Las decisiones se registran en una tabla de auditoría policy_decisions append-only.

Tokens de sesión. JWTs con una vida de 8 horas por defecto, renovables hasta una duración absoluta de sesión de 30 días. El token se guarda en una cookie HttpOnly; Secure; SameSite=Strict que los scripts de la página no pueden leer; no se guarda en localStorage. Cerrar sesión la termina en el servidor. Un cambio o restablecimiento de contraseña, la desactivación de MFA o el cambio del email de la cuenta terminan las demás sesiones de esa cuenta, y el usuario puede cerrar sesión en todos sus dispositivos a la vez.

CAPTCHA. Cloudflare Turnstile protege registro, login, restablecimiento de contraseña, alta MFA y la ruta de provisioning del sandbox público de demo. El helper verify_turnstile_token registra el campo error-codes de Cloudflare en caso de fallo para diagnóstico.

Rate limiting. Un middleware con backend Redis aplica límites por endpoint y por IP — endpoints de inicio de sesión, registro, contraseña y MFA limitados a 10 solicitudes/minuto, AI Coordinator feedback a 30/minuto, defecto en 100/minuto. Cuando Redis no está disponible, las rutas de inicio de sesión siguen limitadas por un contador que mantiene cada proceso de la API, a la mitad del presupuesto habitual; el resto de rutas falla abierto (disponibilidad por encima de límites rígidos), y cada una de esas solicitudes se contabiliza y la caída se registra como error.

3.5 Seguridad de aplicación

• Alineación con OWASP ASVS Level 2 como base.
• Validación de entrada vía esquemas Pydantic en cada límite de API; estrictez de tipos en tiempo de compilación con mypy.
• Acceso a datos solo vía ORM (SQLAlchemy); ningún SQL concatenado por strings.
• Las respuestas HTTP llevan headers de seguridad estrictos (HSTS, X-Frame-Options=DENY, X-Content-Type-Options=nosniff, Referrer-Policy=strict-origin-when-cross-origin). La aplicación web publica además una Content-Security-Policy: default-src 'self', frame-ancestors 'none', listas explícitas de los hosts desde los que puede cargar imágenes y a los que puede conectarse, y sin unsafe-eval (se permite la compilación de WebAssembly, para el visor CAD). Los scripts y estilos inline siguen permitidos. Un test de CI impide que la política se relaje.
• Defensa contra SSRF: las salidas HTTP de la aplicación están limitadas a una allowlist conocida de hostnames de proveedores; no se permiten salidas arbitrarias desde rutas de código atadas a solicitudes.
• Codificación de salida: React (web app) y Jinja2 (admin) auto-escapan; el uso explícito de dangerouslySetInnerHTML se revisa en CI con grep.

3.6 Protecciones específicas de LLM

La plataforma envía trabajo de IA a Together AI (inferencia por defecto, comprensión de imágenes y transcripción de voz), al proveedor de embeddings (Cloudflare Workers AI, §7.2) para los embeddings de documentos y, cuando la búsqueda web está configurada, a Tavily (las consultas de búsqueda que escribe el asistente). RunPod sirve el modelo propio de DevAI: con sus credenciales configuradas es el respaldo ante caídas para los turnos que no necesitan llamar a herramientas, y solo pasa a ser la primera opción para las skills de dominio cuando se activa el enrutado al modelo propio, desactivado por defecto. Anthropic y OpenAI son solo de emergencia (break-glass), inalcanzables salvo que un operador active el ajuste de emergencia (desactivado por defecto) o seleccione uno de ellos como proveedor de modelos. Riesgos específicos:

• Inyección de prompt desde documentos cargados. El texto que no procede de la plataforma ni del mensaje que el propio usuario ha escrito — pasajes de documentos recuperados, archivos adjuntos, respuestas anteriores del asistente reproducidas desde el historial y texto aportado por proveedores — llega al modelo dentro de un bloque delimitado de datos no confiables. Antes de envolverlo se enmascaran las formulaciones habituales de inyección y se neutralizan los delimitadores imitados, de modo que un documento no puede cerrar su propio bloque; el system prompt indica al modelo que trate esos bloques como datos, nunca como instrucciones. Esto reduce el riesgo, no lo elimina, y por eso las propuestas de tool-calling se exponen para revisión del usuario antes de ejecutarse (ciclo de vida AIProposal).
• Datos que salen de la plataforma. Los datos de cliente salen de la plataforma para algo más que la inferencia de modelos, y §7.2 nombra a cada destinatario: los prompts, los fragmentos recuperados, las imágenes y el audio van a Together AI; los fragmentos de documentos y las consultas de búsqueda, al proveedor de embeddings (Cloudflare Workers AI); las consultas de búsqueda web, a Tavily; los eventos de jobs, a Inngest; los informes de error, a Sentry; los eventos de uso, a PostHog; un archivo de Office que el usuario previsualiza, al visor de Microsoft; y el volcado nocturno de la base de datos y el simulacro mensual de restauración se ejecutan en runners alojados por GitHub. El fine-tuning por organización (§10.4) envía los pares de corrección de una organización a Together AI y el adaptador resultante a Hugging Face; solo se ejecuta para una organización cuyo administrador ha activado el consentimiento de datos de entrenamiento.
• Agotamiento de coste. Cuotas por org y por usuario (configurables; defecto conservador). El sandbox público de demo aplica una cuota de 10 mensajes del AI Coordinator por sesión.
• Fine-tuning privado por tenant. Los adaptadores LoRA por tenant se entrenan únicamente con las correcciones de la propia org a las propuestas de IA, y solo con su consentimiento de datos de entrenamiento (§10.4). El job diario programado de entrenamiento está retenido; hoy un fine-tune solo arranca cuando lo inicia un administrador de la plataforma. Los adaptadores nunca cruzan tenants; el router de inferencia selecciona el adaptador correcto por org_id antes de llamar al servidor de modelo.

3.7 Gestión de secretos

Ningún secreto se commitea jamás al control de versiones; los hooks pre-commit y CI escanean por commits accidentales.

4. Detect — Monitorización y auditoría

4.1 Logging de aplicación

Se emiten logs estructurados en JSON por cada solicitud y evento relevante para seguridad. El saneado de PII se aplica en el filtro de logging (app.core.logging_filters.PIIScrubFilter) antes de que los logs salgan de la aplicación; emails, direcciones IP y otros identificadores se redactan en entornos no-debug.

4.2 Trazabilidad de auditoría

Una tabla dedicada org_security_audits append-only registra eventos relevantes para seguridad acotados por org:

• Autenticación: login, logout, alta MFA, resultado de challenge MFA, restablecimiento de contraseña, vinculación/desvinculación SSO.
• Autorización: grants de rol, revocaciones de rol, denegaciones de permiso.
• Acceso a datos: envíos PPAP, ediciones FMEA, aceptar/rechazar propuestas IA, lectura/escritura de credenciales de integración, toggle del sandbox.
• Ciclo de vida de la org: creación, solicitud de eliminación, cancelación de eliminación, conversión desde demo.

Los administradores cliente pueden solicitar exportación del histórico de auditoría de su org vía el flujo DSR. Retención: 7 años para artefactos regulados, 1 año para eventos generales, configurable por cliente en el DPA.

4.3 Seguimiento de errores

Sentry captura excepciones de aplicación con la integración FastAPI (transacciones etiquetadas por endpoint), la integración SQLAlchemy (detección de queries lentas) y el filtro de saneado PII aplicado en la capa de logging. La tasa de profiling está al 1% de transacciones trazadas para equilibrar coste y señal.

4.4 Monitorización de infraestructura

El chequeo automático de Fly consulta la probe de liveness (/livez). La probe de readiness (/readyz) pinguea la base de datos (dependencia dura) y Redis (suave, fail-open); se usa para verificar despliegues y para el triaje de incidentes, y cada despliegue además prueba la conectividad con la base de datos al ejecutar las migraciones del esquema antes de reemplazar ninguna máquina. Un monitor externo en Cloudflare, fuera de nuestra propia infraestructura, comprueba cada minuto la aplicación web, la API y el sitio web, y dos veces por hora la probe de readiness, y publica el resultado en la página de estado pública, https://status.devaisuite.com (en inglés y español, con un feed legible por máquinas); una caída que detecta abre allí un incidente automáticamente.

4.5 Detección de anomalías

El middleware de rate-limit emite headers estándar X-RateLimit-{Limit,Remaining,Reset} y registra anomalías (picos súbitos de una sola IP) para revisión. La integración con un SIEM está en la hoja de ruta una vez SOC 2 Type II esté firmado.

5. Respond — Respuesta a incidentes

5.1 Clasificación de incidentes

5.2 Checklist de los primeros 30 minutos

Una checklist lista para pegar para el operador vive en docs/runbooks/disaster-recovery.md §0:

1. Confirmar el impacto vía /readyz.
2. Probar el estado de máquinas Fly y los logs recientes.
3. Categorizar la clase de fallo (DB / Redis / bug de app / infra Fly).
4. Publicar actualización en página de estado antes de arreglar — fija expectativas del cliente.
5. Mitigar según la sección correspondiente del runbook.
6. Comunicar directamente a los tenants afectados.

5.3 Notificación al cliente

Cuando lo exige la ley para violaciones de datos personales bajo el Artículo 33 del RGPD, la notificación al cliente se realiza dentro de las 72 horas desde la confirmación. La notificación incluye la naturaleza de la brecha, las categorías y número aproximado de interesados, las consecuencias probables y las medidas adoptadas o propuestas para abordarla.

5.4 Revisión post-incidente

Se redacta un post-mortem sin culpa en 5 días laborables para cada incidente P0 y P1, capturando línea temporal, causa raíz, factores contribuyentes y seguimientos concretos. Los post-mortems se archivan internamente y se comparten con clientes afectados bajo NDA.

5.5 Divulgación de vulnerabilidades

Publicamos un security.txt en /.well-known/security.txt con el contacto de reporte, admin@devaisuite.com. Acusamos recibo de un reporte en 48 horas y acordamos con quien lo envía una fecha de publicación, normalmente cuando la corrección está desplegada y como máximo 90 días después del reporte. Los investigadores que sigan nuestras reglas de prueba de buena fe no están sujetos a acción legal bajo nuestro lenguaje de safe-harbor.

6. Recover — Recuperación ante desastres y continuidad

6.1 Postura de backups

La base de datos primaria corre en Neon, que conserva un historial continuo de escrituras: se puede restaurar cualquier momento de las últimas 24 horas y la copia restaurada está disponible en segundos (ensayado en staging el 9 de julio de 2026). De forma independiente, cada noche se escribe un volcado lógico de la base de datos de producción en Cloudflare R2 en jurisdicción UE — una segunda copia en un segundo proveedor — con retención de 30 días diarios y 12 meses mensuales. El volcado se genera en un runner alojado por GitHub, que mantiene una copia de la base de datos mientras dura el job. R2 cifra en reposo el volcado almacenado; el cifrado en el propio runner antes de la subida está construido y se activa en cuanto se cree su clave. El RTO objetivo para una restauración full-stack es 30 minutos; el RPO es prácticamente cero dentro de la ventana de 24 horas, y de hasta 24 horas si se restaura desde el volcado nocturno.

6.2 Procedimiento de restauración

Documentado en detalle en docs/runbooks/disaster-recovery.md §1. Resumen:

1. Detener la API para prevenir escrituras split-brain.
2. Identificar el momento anterior a la ventana de corrupción.
3. Restaurarlo como una nueva rama de Neon (NO sobrescribir in-place — preserva el original para análisis forense). Si Neon no está disponible, restaurar el último volcado nocturno en una instancia PostgreSQL nueva.
4. Validar contra baselines de métricas de negocio.
5. Reapuntar DATABASE_URL al cluster restaurado.
6. Devolver la API a online.
7. Smoke-test vía /readyz y los endpoints de salud por proveedor.

6.3 Recuperación de R2 (object storage)

Cloudflare R2 es de región única y no versiona objetos. La biblioteca global de plantillas puede regenerarse desde el código fuente vía publish_global_library. Los documentos de cliente, los modelos entrenados y los adjuntos del chat se copian cada noche a las 03:00 UTC, en el lado del servidor, a una instantánea fechada en un bucket separado en jurisdicción UE (devai-object-backups-eu), con retención de 30 días diarios y 12 meses mensuales. Un archivo subido después de la última copia depende de la durabilidad propia de R2 hasta la siguiente. La restauración desde una instantánea está documentada y todavía no se ha ejercitado.

6.4 Cadencia de simulacros DR

Qué se prueba, con qué frecuencia y qué se ha hecho hasta ahora:

Hasta que el simulacro mensual haya dejado su primer registro, el RTO de 30 minutos es un objetivo, no una medición. Un simulacro fallido se trata como un incidente en ciernes y se corrige en la misma semana.

6.5 Continuidad de negocio

Las funciones críticas de negocio (facturación, soporte al cliente, rotación on-call) están documentadas en playbooks separados de la plataforma misma, de modo que la indisponibilidad de la plataforma no bloquee los esfuerzos de recuperación del cliente.

7. Gestión de proveedores y subencargados

7.1 Incorporación

Cada nuevo subencargado se revisa por:

• Residencia de datos (dónde almacenan nuestros datos de cliente).
• Postura contractual: DPA, SCCs (para procesadores no EEE que manejen datos personales UE), términos de responsabilidad.
• Postura de seguridad: certificaciones publicadas (SOC 2, ISO 27001), páginas públicas de seguridad, historial de brechas.
• Dependencia operativa: criticidad para el servicio, facilidad de cambio.

La decisión se registra en el registro de proveedores; la revisión de renovación es anual.

7.2 Lista actual de subencargados

Los proveedores que reciben datos de cliente en el servicio cloud, y la condición que activa a cada uno cuando no está siempre activo.

Servicios de datos públicos. Los servicios siguientes responden a preguntas sobre el mundo exterior. No reciben registros de cliente, pero una consulta puede revelar dónde están las plantas, los proveedores o los envíos de un cliente.

Los conectores que un cliente configura hacia sus propios sistemas (ERP, MES, PLM, SharePoint, Google Drive, webhooks y otros) envían los datos adonde el cliente indica, con credenciales que aporta el cliente. Son encargados del cliente, no subencargados de DevAI, y no figuran aquí.

La misma lista está publicada en /subprocessor-list.html, con los datos que puede recibir cada proveedor y la fecha de su última actualización. La columna de cumplimiento recoge lo que cada proveedor publica sobre sí mismo; recopilar y revisar los informes forma parte de la revisión anual de proveedores de DevAI. La notificación al cliente de cambios de subencargado sigue la cadencia del DPA del cliente (típicamente 30 días de antelación para cambios materiales).

7.3 Revisión de cambios de subencargado

Los clientes son notificados de cambios de subencargado según la cadencia del DPA y pueden objetar dentro de la ventana contractual. Cuando la objeción del cliente no puede reconciliarse con el nuevo subencargado, el contrato permite la rescisión según el DPA.

8. Ciclo de vida seguro de desarrollo

8.1 Control de fuente y revisión

• Repositorio canónico único en GitHub.
• Branch protection en main: revisiones PR obligatorias, status checks obligatorios, force-push deshabilitado.
• Hooks pre-commit: lint, type check, escaneo de secretos.
• CI en cada PR: suite completa de tests (actualmente ~3.000 tests en niveles smoke y full).

8.2 Pruebas

8.3 Gestión de dependencias

• GitHub Dependabot habilitado; PRs semanales para advisories de seguridad.
• Revisión manual de cada actualización de dependencia; los parches relevantes para seguridad se aplican en 7 días para advisories de severidad alta, 30 días para media.
• Sin frameworks mayores obsoletos: Python 3.11 (canónico CI), Node 20+, FastAPI / Pydantic / SQLAlchemy actuales.

8.4 Disciplina de migraciones

Los cambios de esquema de base de datos fluyen mediante migraciones Alembic, revisadas e idempotentes. Producción ejecuta alembic upgrade head como pre-flight del comando de release. Los rollbacks están probados; las migraciones destructivas llevan un gate --confirm.

8.5 Análisis estático

• El type checking es la herramienta principal de análisis estático (mypy + tsc strict).
• flake8 para estilo Python.
• ESLint para TypeScript.
• Semgrep se ejecuta en CI en cada pull request y en main: un hallazgo que introduce un pull request hace fallar el check, y los hallazgos que ya existían se reportan para su triaje.

8.6 Validación de configuración en arranque

validate_production_config(settings) se ejecuta en el lifespan startup de FastAPI. La aplicación rechaza el boot cuando:

• Falta un secreto requerido en producción.
• Está activo STRIPE_LIVE=true pero la clave Stripe no es sk_live_ (mismatch de modo live).
• Otros invariantes requeridos para evitar estados inseguros.

Esto detecta la deriva de configuración antes de que pueda servir una sola solicitud.

9. Manejo de datos

9.1 Ciclo de vida de los datos

9.2 Residencia de datos

La capa de aplicación corre en la región Frankfurt (FRA) de Fly y la base de datos primaria en la región Frankfurt de Neon (aws-eu-central-1). Los buckets de Cloudflare R2 están en jurisdicción UE. La caché Redis (Upstash), el proveedor de modelos por defecto (Together AI), la orquestación de jobs (Inngest), la monitorización de errores (Sentry) y el correo transaccional (Resend) están en Estados Unidos. Los embeddings de documentos se ejecutan en Cloudflare Workers AI, que no ofrece elección de región, por lo que ese tratamiento no está fijado a la UE. La región de cada proveedor figura en §7.2.

Para clientes con requisitos estrictos de residencia, hay despliegue on-premise / región dedicada disponible en planes Enterprise.

9.3 Derechos del interesado (RGPD / CCPA / CPRA)

El flujo DSR soporta:

• Derecho de acceso — exportación completa de los datos del cliente bajo solicitud.
• Derecho de eliminación — en 30 días, con confirmación al solicitante.
• Derecho de rectificación — gestionado vía la UI por administradores de org.
• Derecho de portabilidad — exportación JSON alineada con el mismo contrato de exportación que el acceso.
• Derecho de objeción / restricción — gestionado según la tabla de fines de tratamiento del DPA.

Las solicitudes se registran y trazan a través del log de auditoría.

9.4 Transferencia transfronteriza

Cuando los datos personales de interesados UE son procesados por subencargados con sede en EE.UU. (proveedores LLM, Stripe, etc.), la transferencia se rige por:

• Cláusulas Contractuales Tipo (SCCs) incluidas en el DPA.
• Medidas suplementarias cuando sea necesario (cifrado en tránsito, sin logging de texto plano en el proveedor).

La evaluación completa de impacto de transferencia es interna pero está disponible para clientes Enterprise bajo NDA.

10. Consideraciones específicas de IA

10.1 Qué se envía a los proveedores LLM

Las llamadas de inferencia envían:

• El prompt del usuario (system prompt + mensaje del usuario).
• El contexto RAG recuperado (documentos de la propia organización, limitados a los que el usuario puede ver).
• Los resultados de las herramientas que el asistente ha llamado durante la conversación.
• Imágenes y audio grabado, cuando el usuario los aporta (comprensión de imágenes y transcripción de voz).
• Puntero al adaptador por tenant (solo router de inferencia Fase 3 — nunca un adaptador de otro tenant).

Hay dos flujos más que no son inferencia: los fragmentos de documentos y las consultas de búsqueda van al proveedor de embeddings (Cloudflare Workers AI) y, cuando la búsqueda web está configurada, la consulta que escribe el modelo va a Tavily. Esa consulta puede llevar contexto de la conversación.

Lo que NO se envía:

• Datos de otros clientes.
• Secretos de aplicación, API keys, credenciales del sistema.
• Tokens de autenticación del cliente.

10.2 Manejo de datos del proveedor

Dos ajustes por organización gobiernan los datos de IA, y son independientes. La indexación de conocimiento está activada por defecto: decide si el asistente se apoya en los documentos indexados de la propia organización. Es un ajuste de producto, no un consentimiento de entrenamiento. El consentimiento de datos de entrenamiento (training_data_opt_in) está desactivado por defecto y lo activa el administrador de la organización, quedando registrado quién lo activó y cuándo. Decide si las correcciones de esa organización a las propuestas de IA se capturan como pares de entrenamiento, y un fine-tune solo se ejecuta mientras está activado (§10.4). Una organización sin registro de consentimiento se trata como si no hubiera consentido.

10.3 Revisión de propuestas de IA

El AI Coordinator de la plataforma nunca ejecuta acciones destructivas en silencio. Cualquier cambio generado por LLM en datos del cliente fluye por el ciclo de vida AIProposal:

1. La IA genera una propuesta (fila FMEA, tile de dashboard, clasificación de documento).
2. La propuesta se almacena con status=draft y se expone al usuario.
3. El usuario revisa y acepta explícitamente; el rechazo también se registra con texto de corrección opcional para tenant-learning.
4. Solo en aceptación la plataforma commitea el cambio a los datos del cliente.

Esto previene la corrupción silenciosa de datos por una respuesta LLM alucinada y crea un audit trail para cada cambio impulsado por IA.

10.4 Aislamiento de tenant-learning

Se pueden entrenar adaptadores LoRA por tenant sobre las correcciones de la org a las propuestas IA. El job diario programado de entrenamiento está retenido; hoy un fine-tune solo arranca cuando lo inicia un administrador de la plataforma. Propiedades críticas de consentimiento y aislamiento:

• Las correcciones solo se capturan como pares de entrenamiento mientras el consentimiento de datos de entrenamiento de la org está activado (§10.2).
• Un fine-tune solo arranca si ese consentimiento está activado en el momento en que empieza el job; una org sin registro de consentimiento se trata como si no hubiera consentido. Las orgs demo (is_demo=True) y las organizaciones dentro de una ventana sandbox (sandbox_unlimited_until en el futuro) se omiten.
• Los datos de entrenamiento de cada adaptador se obtienen exclusivamente de las filas tenant_learning_events de una org, acotadas por RLS.
• Los pares de entrenamiento se suben a Together AI (EE.UU.) para el job y se eliminan del almacén de archivos de Together cuando el job termina.
• Los adaptadores entrenados se etiquetan con org_id y se almacenan en repositorios privados de la organización propia de DevAI en Hugging Face (EE.UU.), uno por org, skill y versión (<skill>-org-<id>-v<n>).
• El router de inferencia selecciona el adaptador activo para el org_id de la solicitud antes de despachar a RunPod / Together; la selección de adaptador cross-tenant es imposible por diseño (probado en la suite Phase 3c wiring).
• Un adaptador nunca se activa automáticamente: lo activa un operador, normalmente solo después de que haya superado al modelo base en una evaluación con datos reservados; existe una anulación explícita del operador para reactivar un adaptador ya conocido.

11. Responsabilidades del cliente (modelo compartido)

La seguridad es compartida. El cliente es responsable de:

• Gestión de usuarios: añadir, eliminar y revisar usuarios autorizados de su org. Deshabilitar prontamente a usuarios que han dejado la empresa.
• Higiene de credenciales: contraseñas fuertes; MFA donde la política de la org lo permita; no compartir credenciales.
• Configuración: habilitar dominios de email permitidos, exigencia de MFA y los ajustes de residencia de datos apropiados a la postura de cumplimiento del cliente.
• Clasificación de datos: evaluar qué datos elige cargar a la plataforma. La plataforma es adecuada para datos típicos de APQP/manufactura; clientes con clasificaciones más estrictas (controlados por exportación, clasificados, etc.) deben consultar antes de cargar.
• Validación de salidas: las salidas generadas por IA deben revisarse antes de basarse en ellas para decisiones reguladas (envíos PPAP, entregables al cliente, etc.). Los indicadores de confianza del AI Coordinator son un punto de partida, no un sustituto de la revisión por SME.
• Credenciales de integración: rotar las credenciales propias para sistemas conectados (Salesforce, SAP, ERP, MES) según la política interna.

Una copia de esta lista de responsabilidades del cliente está en el Master Service Agreement y el DPA.

12. Contactos

La clave pública PGP para correspondencia de seguridad está disponible bajo solicitud.

13. Control documental

Este white paper se revisa al menos anualmente y en cada cambio material en la postura de seguridad de la plataforma. La fuente autorizada es docs/security/WHITEPAPER_ES.md en el repositorio fuente de la plataforma.

Una versión en inglés se mantiene en paralelo en docs/security/WHITEPAPER_EN.md y se renderiza en /security-whitepaper.html.

© 2026 DevAI Suite. Este documento puede redistribuirse sin cambios para el propósito de revisión de seguridad de proveedor. Los extractos deben mantener la atribución.