Informe de seguridad
Gobernado por código, no por prompts.
Lo primero que pregunta un CISO: cómo se controlan, aíslan, registran y limitan los empleados de IA.
Esta página se imprime como el informe de seguridad.
Certificación
Polis aún no tiene ninguna certificación de seguridad (como ISO 27001 o SOC 2).
Este informe describe los controles del producto para que usted pueda evaluarlos directamente.
01 El modelo de control
Una pasarela para cada acción externa, y límites que ningún ajuste puede cambiar.
-
Una pasarela
Cada acción externa pasa por una pasarela: política, aprobación, credencial, registro.
-
Políticas y aprobaciones
Políticas por proyecto y por acción. Cuando una política exige aprobación, decide una persona designada y la decisión queda registrada.
-
Nunca, por código
Impuesto en el código, y ningún ajuste lo cambia: un empleado de IA nunca hace merge en la rama principal, nunca despliega y nunca cambia la configuración propia de Polis.
-
Pausar todo el trabajo de IA
Un interruptor pausa todo el trabajo de IA para todos, y un aviso lo indica.
02 Aislamiento y secretos
Sin credenciales de integración en el sandbox, y secretos cifrados en reposo.
-
Sandbox aislado
El código y las pruebas se ejecutan en un sandbox aislado (gVisor en servidores). No contiene credenciales de integración ni claves de proveedor, solo un token de corta duración para sus propias llamadas al modelo. El tráfico saliente solo va a una lista de permitidos.
-
Credenciales de corta duración
Tokens de corta duración emitidos por llamada, limitados a un repositorio en GitHub. Jira y Slack usan la credencial almacenada de la conexión, que nunca se expone a la IA.
-
Cifrado de sobre
Los secretos se protegen con cifrado de sobre bajo una clave de cifrado de claves, con una comprobación de que la restauración funciona de verdad.
03 Identidad y acceso
Cuentas con nombre, roles y autenticación reforzada, para personas y empleados de IA.
-
Empleados de IA con nombre
Los empleados de IA tienen sus propias cuentas con nombre, roles, límites y registro de auditoría.
-
Roles y autenticación de dos factores
Siete roles, autenticación de dos factores (TOTP) para cada usuario y autenticación reforzada para acciones sensibles.
-
Autonomía por proyecto
La autonomía se fija por proyecto: L0 · Advisory, L1 · Supervised, L2 · Autonomous. Ningún empleado de IA trabaja por encima del nivel de su proyecto, cada empleado puede limitarse a un nivel inferior y se pueden exigir aprobaciones para acciones concretas en toda la organización.
04 Auditoría y fiabilidad
Un registro de solo adición, y un servicio que sigue funcionando.
-
Auditoría de solo adición
Cada decisión, aprobación, llamada a herramienta y llamada al modelo se registra en un registro de auditoría de solo adición.
-
Conmutación por error
Si el servicio coordinador falla, otro toma el relevo en 20 segundos.
05 Límites y presupuestos
Cada llamada al modelo con su coste, y el gasto limitado.
-
Límite de coste por tarea
Un límite de coste por tarea, por proyecto.
-
Presupuesto en dinero
Un presupuesto global en dinero con reservas. Cada llamada al modelo se valora y se registra, sin almacenar el contenido de prompts ni de respuestas.
-
Límites por empleado
Un límite de coste por empleado de IA y un límite de tareas por día.
06Gobernanza y reglas de seguridad
Reglas impuestas en el código, a cargo de personas designadas.
Algunos límites no los cambia ningún ajuste. Dentro de ellos, su equipo fija la política, por proyecto y por acción.
Nunca, por código
Un empleado de IA nunca hace merge en la rama principal, nunca despliega y nunca cambia la configuración propia de Polis.
Impuesto en el código, y ningún ajuste lo cambia.
Nivel 1 · Reglas de seguridad
Cinco reglas de seguridad, activadas por defecto.
Solo su Owner puede desactivar una, con autenticación reforzada y un motivo. Mientras esté desactivada se muestra un aviso en todas las páginas, el cambio queda auditado y un informe de conformidad muestra el estado.
- 01 Nunca conceder derechos de administrador.
- 02 Nunca cambiar las cuentas propias de Polis ni los permisos de ningún empleado de IA.
- 03 Nunca eliminar al último administrador.
- 04 Nunca crear, leer ni rotar claves, tokens o contraseñas.
- 05 Nunca debilitar las protecciones de las que depende Polis.
Nivel 2 · Reglas de acceso, y la prueba
Reglas de acceso por empleado de IA, y la prueba de que las reglas de seguridad se cumplen.
-
Reglas de acceso de nivel 2
Reglas de acceso por empleado de IA.
-
Demuéstrelo
Polis intenta cada infracción de seguridad y muestra que se rechaza.
Después del piloto
Funciones de gobernanza que planificamos a continuación.
-
Funciones de gobernanza
Grupos, llaves de acceso, gestión de aprobaciones y exportación de la auditoría con encadenamiento de hashes.
07Protección de datos
Dónde se tratan sus datos y qué conserva Polis.
- En su entorno (opción A)
- Sus datos se quedan en su entorno.
- En una instancia dedicada (opción B)
- Una instancia por cliente, nunca compartida, en la UE.
- Llamadas al modelo
- Van a su propio proveedor, con su contrato, y solo para las clases de datos que usted permita.
- Qué almacena Polis sobre el uso de modelos
- Ningún contenido de prompts ni de respuestas: los registros de uso solo contienen recuentos, códigos y costes.
- Conocimiento de la empresa
- Usted puede exportarlo o eliminarlo, y quitar una fuente elimina su copia almacenada. La conservación la decide usted. La búsqueda se ejecuta en un modelo local, así que ningún texto de documentos sale de su instalación.
- Contrato de encargo del tratamiento
- Para la instancia dedicada que operamos, firmamos con usted un contrato de encargo del tratamiento, disponible a petición.
- Subencargados para la instancia dedicada
- Hetzner Online GmbH (servidores, UE). Los proveedores de modelos trabajan con su propio contrato con ellos, no con el nuestro.
08Retos, con franqueza
Los riesgos que conocemos y cómo los mantenemos bajos.
Preferimos decírselo antes de que usted lo descubra.
-
Los empleados de IA cometen errores
Nosotros: solo pull requests en borrador, las pruebas se ejecutan en el sandbox y sus revisores hacen el merge.
Usted: el tiempo de revisión, que medimos en el piloto.
-
Entradas manipuladas
Nosotros: la pasarela limita cada acción, un empleado de IA nunca puede cambiar la configuración de Polis y el sandbox no contiene credenciales de integración ni claves de proveedor, solo un token de corta duración para sus propias llamadas al modelo.
Usted: las acciones permitidas aún pueden usarse de forma indebida, así que mantenga los alcances acotados.
-
Fatiga de aprobaciones
Nosotros: aprobaciones solo donde su política lo exige, sobre planes y no sobre cada pulsación, todas registradas.
Usted: aprobadores designados y rotativos.
-
Los datos llegan a un proveedor de modelos
Nosotros: solo salen las clases de datos que usted permite, con su propio contrato.
Usted: elegir las clases de datos y el proveedor.
-
Un nuevo almacén de datos
Nosotros: la experiencia se almacenará en su instalación de Polis, donde podrá consultarla y eliminarla, y cada lección necesitará la aprobación de una persona.
Usted: se le aplica su gobernanza de datos.
-
Un producto en fase inicial
Nosotros: el piloto es acotado y reversible.
Usted: empiece en modo supervisado, en uno o dos proyectos.
Reservar una demo
Véalo en su propio flujo de trabajo.
Una llamada de 30 minutos: unos 15 minutos de producto en directo, incluido el interruptor que lo pausa todo, y después sus preguntas. Si lo desea, invite a su CISO.
Qué mostramos
- Roles que no pueden excederse, con autenticación reforzada para acciones sensibles
- Un proveedor de modelos vinculado a una clase de datos
- Aprobaciones de una persona designada, en Slack o en el panel
El interruptor que lo pausa todo
Un interruptor pausa todo el trabajo de IA para todos, y un aviso lo indica.