Política de Seguridad de la Información
TaskFlow AI opera sobre información sensible de sus clientes: documentos internos, comunicaciones comerciales y credenciales delegadas de acceso a sistemas de terceros. Los agentes de la plataforma no se limitan a leer datos, sino que ejecutan acciones sobre herramientas reales en nombre del cliente.
Este documento describe los controles de seguridad implementados para proteger esa información, el modelo de responsabilidad compartida entre TaskFlow AI y sus clientes, y los procedimientos aplicables ante incidentes. Está dirigido a los responsables de tecnología y seguridad de las organizaciones clientes, y a todo integrante del equipo con acceso a los sistemas descriptos.
1. Objetivo y alcance
El objetivo de esta política es preservar la confidencialidad, integridad y disponibilidad de la información gestionada por la plataforma, garantizando el aislamiento efectivo entre organizaciones y el uso controlado de las credenciales delegadas.
La política alcanza a la totalidad de los componentes del servicio y al equipo que los desarrolla y opera:
- Aplicación web y servicios de backend, incluidos los procesos de ejecución asincrónica.
- Agentes de inteligencia artificial y su interacción con proveedores de modelos de lenguaje.
- Bases de datos, almacenamiento de archivos, colas de trabajo e índice semántico.
- Integraciones con servicios de terceros mediante autorización delegada.
- Repositorios de código, pipelines de integración continua y entornos de despliegue.
- Todo integrante del equipo con acceso a cualquiera de los activos anteriores.
Quedan fuera de alcance la seguridad interna de los proveedores de infraestructura y de modelos de lenguaje, regida por sus propios marcos de cumplimiento, y la seguridad de los dispositivos y redes desde los cuales los usuarios acceden al servicio.
2. Principios
Las decisiones de diseño e implementación de la plataforma se rigen por los siguientes principios:
| Principio | Aplicación en TaskFlow AI |
|---|---|
| Mínimo privilegio | Cada componente, agente e integrante del equipo accede únicamente a los recursos necesarios para su función. Los agentes reciben contexto filtrado, no la totalidad del workspace. |
| Defensa en profundidad | El aislamiento entre organizaciones se sostiene en más de una capa: validación en la aplicación y políticas de acceso a nivel del motor de base de datos. |
| Seguro por defecto | Toda ruta y todo recurso se consideran privados salvo declaración explícita en contrario. Las integraciones permanecen deshabilitadas hasta que el cliente las autoriza. |
| Trazabilidad | Toda ejecución de agente y toda acción sobre sistemas externos queda registrada y es atribuible a una organización, un usuario y una tarea. |
| Intervención humana en acciones de impacto | Las operaciones con efecto irreversible sobre sistemas externos requieren confirmación explícita del usuario antes de ejecutarse. |
3. Autenticación y control de acceso
3.1 Autenticación de usuarios
Cada sesión válida emite un token firmado con vencimiento acotado, que incluye el identificador de la organización como atributo. El backend valida la firma y la vigencia del token en cada solicitud recibida. Toda ruta se considera protegida salvo las expresamente declaradas como públicas.
Las contraseñas se almacenan exclusivamente en forma de hash y nunca en texto plano. El cierre de sesión invalida el estado local y revoca el acceso a las rutas protegidas. La recuperación de contraseña opera mediante enlaces de un solo uso con vencimiento.
3.2 Aislamiento entre organizaciones
El aislamiento multi-tenant se implementa mediante políticas de seguridad a nivel de fila en la base de datos relacional. El filtrado se evalúa en el motor de base de datos utilizando el identificador de organización contenido en el token de sesión, de modo que no depende del código de aplicación y no puede omitirse por un error de implementación.
El mismo criterio se extiende al resto de los componentes de persistencia: los archivos se organizan por organización en el almacenamiento de objetos, el índice semántico se particiona por organización y los trabajos encolados incluyen el identificador correspondiente en su contexto de ejecución.
Toda incidencia en la que un dato resulte accesible desde una organización distinta a la propietaria se clasifica como defecto crítico y bloquea la promoción del cambio a producción.
3.3 Acceso del equipo
El acceso a entornos productivos se restringe a los integrantes que lo requieren por su función y se otorga de forma nominal. Los entornos de desarrollo, prueba y producción utilizan credenciales independientes. Los accesos se revisan periódicamente y se revocan de forma inmediata ante la desvinculación de un integrante.
4. Credenciales de integración y secretos
4.1 Autorización delegada
Las integraciones con servicios externos operan mediante autorización delegada bajo el estándar OAuth 2.0. Cada organización conecta sus propias cuentas y otorga de forma explícita el conjunto de permisos solicitado, aplicando el criterio de mínimo privilegio: se solicitan únicamente los alcances necesarios para las operaciones que los agentes deben realizar.
Los tokens de acceso y de refresco se almacenan cifrados en la base de datos mediante cifrado simétrico a nivel de aplicación. Antes de cada ejecución, el backend recupera el token vigente de la organización, lo renueva si corresponde y lo inyecta en el contexto acotado de esa ejecución.
Los tokens no se exponen al frontend, no se registran en logs ni se transmiten a los proveedores de modelos de lenguaje. El cliente puede revocar una autorización en cualquier momento, lo que invalida de forma inmediata la capacidad de los agentes de operar sobre ese servicio.
4.2 Secretos de la plataforma
Las claves de API, cadenas de conexión y claves de cifrado se gestionan como variables de entorno en cada plataforma de despliegue y como secretos cifrados en el proveedor de integración continua. Su incorporación al repositorio de código está expresamente prohibida, aun de forma transitoria.
Un secreto expuesto de forma accidental se rota de inmediato y sin excepción, con independencia de que el repositorio sea privado.
5. Cifrado
La totalidad de las comunicaciones entre el usuario, la plataforma y los servicios de terceros se realiza sobre canales cifrados mediante TLS. No se admiten conexiones en texto plano en ningún entorno.
En reposo, las bases de datos y el almacenamiento de objetos aplican el cifrado provisto por sus respectivos proveedores. Las credenciales de integración incorporan una capa adicional de cifrado a nivel de aplicación, de modo que el acceso directo a la base de datos resulta insuficiente para utilizarlas.
6. Clasificación, retención y eliminación de datos
La información gestionada por la plataforma se clasifica en los siguientes niveles, que determinan los controles aplicables:
| Nivel | Ejemplos | Controles |
|---|---|---|
| Crítica | Credenciales de integración, claves de cifrado, secretos de infraestructura | Cifrado a nivel de aplicación, acceso restringido, prohibición de registro en logs y de exposición al frontend |
| Confidencial | Contenido del workspace, documentos, comunicaciones procesadas, datos de clientes de la organización | Aislamiento por organización, cifrado en tránsito y en reposo, acceso limitado al titular |
| Interna | Métricas de consumo, trazas de ejecución, historial de tareas | Acceso autenticado, segmentación por organización, retención acotada |
| Pública | Documentación del producto, catálogo de agentes, planes disponibles | Sin restricciones de acceso |
La información se conserva mientras la organización mantenga su cuenta activa. Producida la baja, se revocan las autorizaciones vigentes y el contenido asociado se elimina dentro de los plazos previstos en los Términos y Condiciones de Uso, salvo obligación legal de conservación.
Las trazas de ejecución y los registros técnicos se conservan por un período acotado con fines de diagnóstico y auditoría. No incluyen credenciales ni el contenido íntegro de los documentos procesados.
7. Seguridad en el ciclo de desarrollo
Los controles de seguridad están integrados al flujo de trabajo, de modo que no dependen de la iniciativa individual:
- Ningún cambio se incorpora a las ramas principales sin revisión de al menos un integrante distinto del autor.
- El pipeline de integración continua ejecuta análisis estático, verificación de tipos y la batería de pruebas automatizadas. Un fallo bloquea la incorporación del cambio.
- Las ramas principales están protegidas: no se admite la escritura directa ni la reescritura del historial.
- El plan de pruebas contempla una categoría específica de defectos de aislamiento y seguridad, orientada a verificar que los datos de una organización no resulten accesibles desde otra.
- Las dependencias de terceros se mantienen actualizadas y se revisan ante la publicación de vulnerabilidades conocidas.
- Los datos utilizados en entornos de prueba son ficticios. No se emplea información real de clientes fuera del entorno productivo.
8. Seguridad de los agentes de inteligencia artificial
La incorporación de modelos de lenguaje introduce riesgos que no se resuelven con los controles tradicionales de una aplicación web. Se adoptan los siguientes recaudos:
| Riesgo | Control aplicado |
|---|---|
| Inyección de instrucciones a través del contenido procesado | El contenido externo se trata como dato y no como instrucción. Las capacidades de cada agente se limitan al conjunto acotado de herramientas habilitadas para su dominio. |
| Filtración de contexto entre organizaciones | Cada agente recibe exclusivamente el contexto recuperado del índice de su propia organización, filtrado previamente por el proceso que lo invoca. |
| Acciones no deseadas sobre sistemas externos | Las operaciones de impacto irreversible requieren aprobación explícita del usuario. El alcance de los permisos delegados se mantiene en el mínimo necesario. |
| Resultados incorrectos o alucinaciones | Los resultados se registran y son trazables. Las ejecuciones se monitorean mediante una plataforma de observabilidad y los casos detectados se documentan como defectos de una categoría propia. |
| Consumo descontrolado de recursos | Control de cuota por organización mediante ventanas temporales y capacidad compartida, con operaciones atómicas que garantizan consistencia ante concurrencia. |
El contenido del cliente no se utiliza para entrenar modelos de lenguaje propios ni de terceros. Los proveedores de modelos se seleccionan considerando sus compromisos contractuales en materia de retención y uso de datos.
9. Proveedores y subprocesadores
La prestación del servicio se apoya en proveedores de infraestructura y de modelos de lenguaje que pueden procesar contenido del cliente. Las categorías de proveedores utilizadas son:
| Categoría | Función | Datos involucrados |
|---|---|---|
| Infraestructura de base de datos y autenticación | Persistencia relacional, índice semántico, identidad de usuarios | Contenido del workspace, metadatos de tareas, credenciales cifradas |
| Almacenamiento de objetos | Archivos del workspace y salidas de los agentes | Documentos cargados y generados |
| Hosting de aplicación y procesos de ejecución | Ejecución del frontend, del backend y de los procesos asincrónicos | Datos en tránsito y en procesamiento |
| Proveedores de modelos de lenguaje | Razonamiento de los agentes | Fragmentos de contexto e instrucciones necesarios para resolver cada tarea |
| Observabilidad | Trazas de ejecución de agentes y diagnóstico | Metadatos de ejecución, sin credenciales |
El listado actualizado de proveedores concretos se encuentra disponible a solicitud del cliente. La incorporación de un nuevo proveedor con acceso a contenido del cliente se comunica con antelación razonable.
10. Registro, monitoreo y trazabilidad
Toda ejecución de agente queda asociada a una organización, un usuario y una tarea identificable. La plataforma registra el estado de las tareas, el consumo de recursos y el resultado de cada subtarea delegada, información que se expone al cliente a través de su tablero de control.
A nivel técnico se conservan trazas de ejecución con fines de diagnóstico, limitadas a la información necesaria para reconstruir el comportamiento del sistema ante un incidente y depuradas de credenciales.
Los eventos relevantes desde la perspectiva de seguridad —intentos de autenticación fallidos, rechazos por política de acceso, agotamiento de cuota y errores de integración— se registran para su revisión.
11. Respuesta a incidentes
Se considera incidente de seguridad todo evento que comprometa o pueda comprometer la confidencialidad, integridad o disponibilidad de la información gestionada por la plataforma. El procedimiento de respuesta comprende las siguientes etapas:
| Etapa | Acciones |
|---|---|
| Detección y reporte | Todo integrante que detecte un posible incidente lo comunica de inmediato al responsable de seguridad, sin intentar resolverlo de forma aislada. |
| Contención | Se limita el alcance: revocación de credenciales comprometidas, suspensión del componente afectado o restricción temporal del acceso. |
| Análisis | Se determina el origen, el alcance y los datos potencialmente afectados a partir de los registros y trazas disponibles. |
| Remediación | Se corrige la causa raíz, se rotan los secretos involucrados y se verifica la corrección mediante pruebas específicas. |
| Notificación | Se informa a los clientes afectados cuando el incidente involucre datos de su titularidad, dentro de un plazo razonable desde su confirmación. |
| Cierre y aprendizaje | El incidente se documenta, se incorpora al registro de riesgos y las acciones de mejora se llevan al ciclo de trabajo siguiente. |
12. Modelo de responsabilidad compartida
La seguridad del servicio es un resultado conjunto. La distribución de responsabilidades es la siguiente:
| Ámbito | TaskFlow AI | Cliente |
|---|---|---|
| Infraestructura y plataforma | Configuración segura, actualizaciones, cifrado, aislamiento entre organizaciones | — |
| Cuentas y credenciales de acceso | Mecanismos de autenticación y recuperación | Custodia de credenciales, altas y bajas de usuarios, notificación ante compromiso |
| Integraciones de terceros | Almacenamiento cifrado y uso acotado de los tokens | Otorgamiento y revocación de autorizaciones, definición del alcance concedido |
| Contenido cargado | Almacenamiento, aislamiento y eliminación conforme a esta política | Licitud del contenido y adecuación de los datos que decide incorporar |
| Acciones de los agentes | Trazabilidad y solicitud de aprobación en acciones de impacto | Validación de los resultados antes de su uso u envío a terceros |
13. Reporte de vulnerabilidades
Se agradece el reporte responsable de vulnerabilidades por parte de clientes e investigadores. Los reportes pueden dirigirse a los canales de contacto indicados al final de este documento, incluyendo la descripción del hallazgo y los pasos necesarios para reproducirlo.
Se solicita no divulgar públicamente el hallazgo hasta que la corrección esté disponible, no acceder a datos de terceros ni degradar la disponibilidad del servicio durante la investigación. Los reportes recibidos se acusan y se tratan conforme al procedimiento de la sección 11.
14. Vigencia y revisión
Esta política se revisa ante la incorporación de nuevas integraciones o agentes, ante cambios relevantes en la arquitectura, ante la ocurrencia de un incidente de seguridad y, en todo caso, al menos una vez al año.
Toda modificación se refleja en la versión y fecha indicadas al inicio del documento.