Saltar al contenido
Tinu AI
Continue→

Seguridad

Última revisión: 1 de octubre de 2026

En resumen

  • Las solicitudes de los miembros llegan al contenido del espacio de trabajo de cada organización a través de la seguridad a nivel de fila de la propia base de datos, que limita cada solicitud a la organización y la persona que la aplicación le asigna.
  • El contenido del espacio de trabajo lo procesan dos proveedores de IA, OpenAI y Google, a través de sus API. Cada organización tiene un límite mensual de gasto en IA, y no entrenamos modelos de IA con el contenido de los clientes.
  • Tinu nunca se conecta a sistemas de control. Los datos operativos solo le llegan como archivos que exporta una persona, o desde sistemas de negocio que un operador de Tinu conecta junto con el administrador de tu sistema.
  • Preparación para SOC 2 en curso. Todavía no tenemos un informe SOC 2 que compartir.
  • Reporta un problema de seguridad a security@tinuai.com.

Esta página describe cómo funciona el producto hoy. Nuestros compromisos contractuales están en el Acuerdo de Tratamiento de Datos.

Contenido

  1. 01Alojamiento y ubicación de los datos
  2. 02Aislamiento entre clientes
  3. 03Cifrado
  4. 04Inicio de sesión y control de acceso
  5. 05Procesamiento con IA y proveedores de modelos
  6. 06Retención y eliminación de datos
  7. 07Registro de auditoría
  8. 08Copias de seguridad y recuperación
  9. 09Cambios en el software
  10. 10Sistemas de control (OT y SCADA)
  11. 11Subencargados del tratamiento
  12. 12Estado de cumplimiento normativo
  13. 13Cómo reportar un problema de seguridad

01Alojamiento y ubicación de los datos

Tinu es un servicio en la nube. La aplicación está alojada en Vercel. Los datos de los clientes se guardan en una base de datos PostgreSQL gestionada por Neon en la región us-east-2 de AWS (Ohio, Estados Unidos). Los trabajos en segundo plano se ejecutan con Inngest, y Upstash Redis se encarga de la limitación de solicitudes y la revocación de sesiones.

Tinu es multiinquilino: los clientes comparten la misma aplicación y la misma base de datos, separados como se describe en la sección 02. Hoy no ofrecemos implementaciones dedicadas ni locales (on-premises).

02Aislamiento entre clientes

Las tablas que contienen el contenido del espacio de trabajo de una organización, como entradas, decisiones, memorias y registros de miembros, tienen políticas de seguridad a nivel de fila de PostgreSQL, basadas en la organización y en la persona que hace la solicitud. Las solicitudes de los miembros que iniciaron sesión se ejecutan con un rol de base de datos aparte, que no es dueño de las tablas y no puede saltarse esas políticas. La aplicación decide la organización y la persona de cada solicitud y las establece dentro de la misma transacción que la consulta; después, la base de datos hace cumplir esa elección. En las tablas de contenido, como entradas y decisiones, una consulta sin organización establecida solo coincide con las filas propias de quien la hace.

Algunas rutas se ejecutan como dueño de la base de datos, lo que omite estas políticas, y en su lugar limitan sus consultas en el código de la aplicación: el inicio de sesión, los enlaces para compartir de solo lectura, las herramientas internas de administración de Tinu y algunos trabajos de procesamiento en segundo plano. Algunas tablas no tienen seguridad a nivel de fila: los enlaces para compartir, a los que el rol que atiende a los miembros no puede acceder en absoluto; el registro de auditoría, al que solo puede agregar registros; y tablas internas como los eventos de analítica del producto y las solicitudes de registro.

Dos comprobaciones automáticas protegen esto en cada cambio de código:

  • una prueba que hace fallar la compilación si se agrega una tabla nueva con una columna de organización sin seguridad a nivel de fila, salvo que esté en una lista corta de excepciones con un motivo por escrito; y
  • una prueba con una base de datos PostgreSQL real que demuestra que una organización no puede leer ni escribir las filas de otra, y que el rol de la aplicación no puede saltarse las políticas.

Dentro de una organización, los miembros pueden marcar una entrada como privada. Los gerentes y administradores no tienen ninguna excepción que les permita leer las entradas privadas de otro miembro.

03Cifrado

En tránsito

Cada respuesta indica a los navegadores que usen solo HTTPS, con un encabezado Strict-Transport-Security (dos años, incluidos los subdominios). La aplicación de producción se niega a iniciarse si alguna de sus cadenas de conexión a la base de datos permite explícitamente una conexión sin cifrar.

Datos almacenados

  • Los tokens de acceso, las claves de API y las contraseñas de los sistemas que conectas a Tinu los cifra la aplicación con AES-256-GCM antes de guardarlos. Se almacenan en columnas de la base de datos que el rol que atiende las solicitudes de los clientes no puede leer. La clave de cifrado se guarda fuera de la base de datos y se puede rotar.
  • Las contraseñas de las cuentas de Tinu se guardan como hashes bcrypt, nunca en forma legible.
  • Las claves de API de Tinu y los tokens de los enlaces para compartir se guardan solo como hashes SHA-256, así que una copia de la base de datos no los contiene.

04Inicio de sesión y control de acceso

  • Las personas inician sesión con una cuenta de Google o con una dirección de correo y una contraseña. Los intentos de inicio de sesión con contraseña tienen un límite de frecuencia por dirección IP y por dirección de correo.
  • Tinu no tiene hoy un segundo factor de inicio de sesión integrado.
  • Una sesión termina después de 24 horas sin actividad. Es un tiempo de espera por inactividad, no una duración fija: cada visita la renueva por otras 24 horas, y hoy no hay una duración máxima de sesión. Cambiar o restablecer una contraseña, cerrar sesión o desactivar una cuenta termina de inmediato todas las sesiones de esa cuenta.
  • Una cuenta desactivada no puede iniciar sesión, y sus claves de API dejan de funcionar.
  • Cada miembro de una organización tiene un rol: administrador, gerente o miembro. Los administradores gestionan los miembros y la configuración de la organización.

Acceso del personal de Tinu

Una lista corta de cuentas del personal de Tinu puede abrir una sesión de soporte en una organización a la vez. Una sesión de soporte dura como máximo una hora. Le permite al miembro del personal administrar esa organización sin convertirse en miembro de ella. Su inicio, su fin y cada cambio hecho durante la sesión quedan escritos en el registro de auditoría con el nombre del propio miembro del personal. Estas cuentas del personal deben iniciar sesión con Google: en producción se les rechaza el inicio de sesión con contraseña.

05Procesamiento con IA y proveedores de modelos

Tinu envía el contenido del espacio de trabajo a dos proveedores de IA a través de sus API: OpenAI y Google (Gemini). Escriben resúmenes, extraen decisiones, personas y temas, generan los embeddings que impulsan la búsqueda y responden preguntas en el chat. Ningún otro proveedor de IA recibe contenido de los clientes.

  • El chat y el procesamiento en segundo plano se ejecutan primero en OpenAI, y pasan a Google si la llamada a OpenAI falla. Los embeddings de búsqueda, las respuestas en Slack y algunas respuestas rápidas dentro de la aplicación se ejecutan en Google.
  • Cada organización tiene un límite mensual de gasto en IA. Las llamadas a modelos hechas para una organización se comprueban primero contra ese límite, aunque algunas solicitudes dentro de la aplicación todavía no se cuentan en él. Cuando se alcanza el límite, las funciones que cubre se detienen para esa organización hasta el siguiente mes calendario o hasta que se aumente el límite.
  • Por cada llamada a un modelo registramos el proveedor, el modelo, el propósito, la cantidad de tokens y los tiempos, vinculados a la organización. Ese registro no contiene el texto del prompt.
  • Tinu no entrena modelos de IA con el contenido de los clientes.

La sección 05 de la Política de Privacidad trata en detalle los proveedores de IA y el entrenamiento de modelos.

06Retención y eliminación de datos

Eliminación de los datos de un miembro que se fue. Cuando alguien ya dejó una organización, un administrador o su gerente más reciente puede presentar una solicitud para eliminar sus datos en ella, y otro administrador la aprueba. En una organización con un solo administrador, ese administrador puede aprobar su propia solicitud, y la aprobación queda registrada. Una vez aprobada, los datos se ocultan de inmediato y se pueden restaurar durante 30 días. Pasados esos 30 días, se pueden eliminar de forma permanente o desidentificar: se quita la autoría del miembro, su nombre y sus direcciones de correo se reemplazan en el conocimiento que conserva la organización, y ese conocimiento se mantiene. El reemplazo es automático: el nombre se sustituye por la marca [Deleted] allí donde se puede identificar. Algunas formas pueden permanecer en ese texto, por ejemplo un apodo, un nombre mal escrito, un nombre escrito en minúsculas o un nombre escrito dentro de una frase en chino, japonés o tailandés.

Cuando un miembro se va y su organización conserva su conocimiento de forma desidentificada, sus entradas privadas nunca se muestran a nadie como entradas, pero las respuestas y los resúmenes de Tinu pueden basarse en lo que contenían. Los miembros pueden revisar y eliminar sus entradas privadas en cualquier momento antes de irse.

Una solicitud de eliminación solo afecta los datos de ese miembro en esa única organización. Si pertenece a otras organizaciones, esas no se tocan.

Exportación. Cualquier miembro puede exportar sus propias entradas, en JSON o CSV, en cualquier momento.

Fin del contrato. La devolución y la eliminación de tus datos cuando termina un acuerdo se tratan en la sección 13 del Acuerdo de Tratamiento de Datos. Los periodos de retención de cada tipo de datos están en la sección 07 de la Política de Privacidad.

07Registro de auditoría

  • Los cambios en los datos del espacio de trabajo se escriben automáticamente en un registro de auditoría, en la capa de acceso a datos y no a mano en cada función. Cada registro guarda la persona que actúa, la organización, un ID de solicitud, la dirección IP, el agente de usuario y el registro antes y después del cambio.
  • Abrir los registros de otra persona también queda registrado: una entrada, una decisión, los registros de una persona en la página del equipo, el texto completo de sus entradas, una respuesta en el chat o en Slack que se basó en sus entradas o decisiones, o una app de IA conectada a Tinu que leyó sus entradas o decisiones. Cada registro indica quién leyó, de quién eran los registros, dónde y cuándo, solo mediante ID, nunca el contenido. Leer tus propios registros no queda registrado, y tampoco las listas ni los resultados de búsqueda, que pueden mostrar el título y el resumen de IA de la entrada de otra persona; abrir esa entrada sí queda registrado. Si falla la escritura de un registro, la lectura se realiza de todos modos. Los administradores de tu organización pueden revisar este registro, y cada autor puede ver quién abrió su entrada.
  • Los hashes de contraseñas, los hashes de claves y tokens, y el texto original de las entradas quedan fuera de los registros de auditoría.
  • El rol de base de datos que atiende las solicitudes de los clientes puede agregar registros de auditoría, pero no puede leerlos, modificarlos ni eliminarlos.
  • Los registros de auditoría se conservan durante al menos un año.

08Copias de seguridad y recuperación

La base de datos usa la restauración a un momento dado de Neon. Un trabajo programado la prueba cada mes: restaura una copia de la base de datos de producción tal como estaba unos cinco minutos antes, comprueba que las tablas esperadas existen y se pueden consultar, y luego elimina la copia.

09Cambios en el software

En cada pull request se ejecutan comprobaciones automáticas: linting y comprobación de tipos, el conjunto completo de pruebas, una compilación de producción, una comprobación del orden de las migraciones de la base de datos y un escaneo de secretos con TruffleHog. Otras dos se ejecutan en cada pull request que cambia código, y solo se omiten cuando un pull request no cambia nada más que pruebas o documentación: la prueba de seguridad a nivel de fila con una base de datos PostgreSQL real y las pruebas de navegador de extremo a extremo. En nuestra cola de fusión se ejecutan todas estas comprobaciones, sin omitir ninguna. Dependabot abre pull requests semanales para mantener actualizadas las dependencias.

10Sistemas de control (OT y SCADA)

Tinu nunca se conecta a tecnología operativa. No tiene ningún conector para SCADA, EMS, DCS, PLC ni historiadores de datos, y no instala ningún agente, sensor ni software en redes operativas o de control.

Dos herramientas opcionales se ejecutan en las computadoras de los propios empleados: una herramienta de línea de comandos que indexa archivos de esa computadora y los envía a Tinu, que está desactivada salvo que se active para tu organización, y un complemento de Excel. Ninguna de las dos se conecta a sistemas de control.

La información de los sistemas operativos llega a Tinu solo de dos maneras:

  • una persona exporta un archivo y lo sube, por ejemplo un diario de alarmas de SCADA guardado como CSV; o
  • un operador de Tinu conecta un sistema de negocio como Maximo o SAP, junto con el administrador de tu sistema, usando una credencial que emite tu administrador. Tinu lee ese sistema a través de su API. Estos conectores solo leen. Nunca escriben de vuelta.

Tinu no está diseñado para guardar BES Cyber System Information ni otra información que proteja tu programa CIP, y tus usuarios no deben enviarla.

11Subencargados del tratamiento

Todos los terceros que procesan datos de clientes por encargo nuestro, para qué sirve cada uno y qué datos le llegan, aparecen con un historial de cambios fechado en nuestra página de subencargados. Enviamos un correo a los administradores de la organización al menos 30 días antes de que un nuevo subencargado empiece a procesar tus datos.

12Estado de cumplimiento normativo

Preparación para SOC 2 en curso. Todavía no tenemos un informe SOC 2 que compartir.

Nuestro Acuerdo de Tratamiento de Datos establece nuestras medidas de seguridad, cómo te notificamos una violación de datos personales y cómo se devuelven o eliminan tus datos cuando termina un acuerdo.

13Cómo reportar un problema de seguridad

Escribe a security@tinuai.com con lo que encontraste y cómo reproducirlo. No emprenderemos acciones legales por investigaciones de buena fe que respeten la privacidad de los usuarios y no degraden el servicio.

Si tenemos conocimiento de una violación de datos personales que afecte a tus datos, lo notificamos por correo a los administradores de tu organización sin demora indebida, según lo establecido en la sección 09 del Acuerdo de Tratamiento de Datos.

Tinu Inc
Ann Arbor, Michigan, United States
Seguridad: security@tinuai.com
Privacidad: privacy@tinuai.com

Consulta también nuestra Política de Privacidad, el Acuerdo de Tratamiento de Datos, los Subencargados y los Términos del Servicio, o vuelve a la página de inicio de Tinu AI.