Política de seguridad de la información

Control iso27001:A.5.1 en el registro de cumplimiento; también respalda la cláusula 5 (liderazgo), iso27001:A.6.7 (trabajo a distancia) y iso27001:A.8.24 (criptografía).

Aprobada por el propietario el 2-10-2026. Al mismo tiempo, el propietario aceptó los riesgos residuales que el registro de riesgos trata como «aceptados», entre ellos que una sola persona sea propietaria y administradora, y la ausencia de una prueba de penetración externa.

Esta es la política que exige ISO 27001 A.5.1: un único documento que establece qué quiere lograr Stilops en materia de seguridad de la información, quién decide sobre qué y qué reglas se aplican. Es deliberadamente breve y describe lo que realmente ocurre. Una política que es mejor que la práctica no es una política, sino un deseo.

1. Objeto y ámbito de aplicación

Stilops suministra agentes de IA que realizan trabajo en nombre de una organización. Los clientes nos confían para ello los datos de su empresa y, en ocasiones, datos personales de _sus_ relaciones. El núcleo del producto no es solo que el trabajo se realice, sino que después pueda reconstruirse _qué_ ha ocurrido y quién lo ha aprobado.

Esta política se aplica a toda la plataforma: el portal de clientes, el entorno de administración, el sitio público, la ejecución de las tareas de los agentes y la infraestructura sobre la que funciona. Se aplica a todas las personas que trabajan en ella —en la actualidad, el propietario— y a los agentes que trabajan por sí mismos en el código base.

2. Objetivos

1. Confidencialidad. Los datos de una organización no son accesibles para otra organización, y los secretos de los sistemas vinculados se almacenan cifrados y no se muestran a un agente. Cuando un agente necesita técnicamente un secreto, lo recibe únicamente durante la duración de esa tarea; las excepciones figuran en «Criptografía y gestión de claves» y en el §5.
2. Integridad y trazabilidad. Lo que un agente propuso, quién lo aprobó y cuál fue el resultado queda registrado y no se modifica posteriormente.
3. Disponibilidad. El servicio funciona, y una avería es recuperable sin pérdida del rastro de auditoría.
4. Autoridad humana. Ningún efecto sin una persona que lo haya aprobado.

El cuarto no es en Stilops una medida de seguridad, sino el punto de partida del producto. Los otros tres existen para hacer creíble ese cuarto.

3. Quién decide qué

Que el propietario sea la única persona de esta tabla es un hecho y no una deficiencia que ocultar, pero sí es el mayor riesgo individual del registro de riesgos, y figura allí como tal.

4. Reglas aplicables

Acceso. El acceso es nominativo y por rol. Las contraseñas se almacenan como hash robusto con sal. La verificación en dos pasos está disponible para todos los usuarios y es obligatoria como paso adicional en las operaciones con consecuencias, entre ellas la confirmación pública de una declaración de cumplimiento. Existe un límite de velocidad en el inicio de sesión y en los formularios.

Puesto de trabajo y trabajo a distancia. Stilops no tiene oficina; toda la administración se realiza a distancia, desde el puesto de trabajo del propietario. A tal efecto se aplican estas reglas: el disco del dispositivo está cifrado y la pantalla se bloquea automáticamente tras un breve periodo de inactividad; el sistema operativo y el navegador reciben las actualizaciones de seguridad en cuanto se publican; las cuentas con los proveedores de código, alojamiento, DNS y pago están protegidas con verificación en dos pasos; el acceso a los servidores se realiza únicamente mediante claves SSH, no mediante contraseñas; los datos de producción no se copian al puesto de trabajo, salvo una copia temporal para una recuperación o una investigación que se elimina después. En caso de pérdida o robo del dispositivo, en un plazo de 24 horas se cierran las sesiones y se renuevan las claves que había en él, y se evalúa si se trata de una violación de la seguridad de los datos personales conforme al Procedimiento de incidentes y violaciones de datos.

Secretos. Los secretos de los sistemas vinculados y de la infraestructura se almacenan cifrados (AES-256-GCM) con una clave por entorno, y solo se descifran en el momento en que una tarea los necesita. Nunca figuran en la instrucción dirigida al modelo de lenguaje. La inclusión accidental de un secreto en un commit solo se evita en parte: una comprobación de la barrera de calidad busca en el código secretos con un prefijo fijo (como claves de GitHub, Anthropic y Stripe y claves privadas), y los mismos patrones se aplican a lo que los agentes presentan como modificación. Un secreto sin prefijo reconocible, como un token de Hetzner o una contraseña, no es detectado por ese control. Un usuario que introduce un secreto en un mensaje de chat tiene ese mensaje interceptado antes de que el modelo lo vea.

Ejecución de tareas de agentes. Una tarea de agente se ejecuta aislada bajo una cuenta propia y limitada de un grupo fijo. Si hay más tareas simultáneas que el tamaño del grupo, una tarea se ejecuta provisionalmente bajo la cuenta compartida de agentes, en la que otra tarea simultánea puede leer su configuración descifrada. Esto se está corrigiendo. Un agente de un cliente nunca obtiene acceso a datos de otra organización, no tiene buzón de correo y no envía correo electrónico.

Modificaciones del software. Toda modificación pasa por una barrera automatizada establecida: estilo, comprobación de tipos, el conjunto completo de pruebas, una comprobación de secretos incluidos en commits y una comprobación de vulnerabilidades conocidas en las dependencias. Una modificación de una barrera o de una facultad debe, además, romperse deliberadamente para demostrar que la prueba correspondiente se pone en rojo — una barrera que no se ha roto no protege nada hasta que se demuestre lo contrario.

Modificaciones y cumplimiento. Toda modificación se evalúa también, antes de su integración, en cuanto a lo que significa para el cumplimiento: ¿afecta a algo que prometen un documento de cumplimiento, los controles o las condiciones? El software determina qué asuntos afecta una modificación; un agente de evaluación independiente, de solo lectura, valora entonces si la modificación puede aprobarse tal cual, si un documento de cumplimiento debe cambiar con ella (lo que Stilops actualiza por sí misma en la misma modificación, tras lo cual el propietario aprueba el nuevo texto), si debe decidir el propietario, o si la modificación se rechaza. Una modificación de las condiciones, de la declaración de privacidad, del acuerdo de encargo del tratamiento o de la lista de subencargados, un riesgo que deba aceptarse y una medida que se debilite, corresponden siempre al propietario; también una evaluación que no llegue a un dictamen. Además, cada trimestre Stilops contrasta todos los documentos de cumplimiento con el código y convierte cada discrepancia en un hallazgo.

Registro. Las operaciones de los administradores y de los usuarios de la organización se registran en modo solo adición (append-only). Una operación registrada no se modifica ni se elimina.

Criptografía y gestión de claves. El tráfico discurre por TLS. Los datos en reposo que constituyen un secreto están cifrados con AES-256-GCM, con dos excepciones conocidas: el token de lectura de corta duración de la vinculación con Search Console (válido como máximo una hora) se almacena deliberadamente sin cifrar, y la clave de la API de Anthropic para las ejecuciones de clientes se encuentra, durante una de esas ejecuciones, hasta dos minutos, como archivo en el disco. La clave se encuentra por entorno fuera del código fuente y de la base de datos y solo es legible por el propio servicio, en máquinas en las que los agentes se ejecutan bajo una cuenta aparte (un ajuste independiente para esa cuenta). Donde esa separación no está configurada, como en el entorno local de desarrollo y de producción, los agentes se ejecutan como el mismo usuario que el servicio y pueden leer tanto la clave como los valores cifrados.

Lo que un agente puede leer, incluso donde la separación sí está configurada: la clave de la API de Anthropic durante una ejecución de cliente; el token ordinario de Cloudflare; mientras el túnel local para secretos de vinculaciones no esté activado, el archivo de configuración descifrado de una tarea; y, con el grupo lleno, también el archivo de configuración de otra tarea simultánea, con los secretos de vinculación de un cliente. Donde ese túnel está activado, esos secretos no acaban en un archivo legible. También la base de datos con los datos de todas las organizaciones es legible para la cuenta de agentes, porque los servidores que los agentes utilizan la necesitan. Un agente de un cliente no llega a ella: entonces no dispone de shell, un control fijo previo a cada operación limita su lectura a su propio directorio de trabajo y a sus anexos, y las herramientas que recibe filtran por su organización. Esa separación reside en la aplicación, no en el sistema operativo: si ese control desaparece, la cuenta no detiene nada. Se trata de riesgos residuales, y el primero figura en el registro de riesgos (R13).

Las claves de acceso externas se renuevan en la medida en que el proveedor lo permita. El token de Cloudflare lo renueva Stilops por sí misma. Para Hetzner, GitHub, Anthropic, Stripe y MXroute, Stilops genera un recordatorio como hallazgo y el propietario renueva la clave por sí mismo. Para las demás vinculaciones (S3, OneDrive, VirusTotal, LinkedIn, PageSpeed, Bing, la cuenta de servicio de Google y las contraseñas de SMTP e IMAP) no hay ningún recordatorio configurado; allí solo rige la rotación manual de claves de la planificación operativa. Para Hetzner se añade una vigilancia que notifica toda operación en el registro de acciones de Hetzner que no proceda de la propia Stilops; para los demás proveedores esa vigilancia no existe.

Un cambio de clave tras una fuga (presunta) invalida las confirmaciones públicas de cumplimiento existentes: estas deben darse de nuevo, porque quien tuviera la clave antigua puede haberlas falsificado. En un cambio ordinario, Stilops vuelve a firmar con la nueva clave cada confirmación que era válida con la clave antigua. Las sesiones y los enlaces de invitación y de restablecimiento caducan con cada cambio.

Incidentes. Qué es un incidente, cómo se recibe y dentro de qué plazo se notifica qué y a quién figura en el Procedimiento de incidentes y violaciones de datos. La decisión de notificar es humana.

Proveedores. Toda parte que trata datos personales figura con su nombre, finalidad, país y el estado del acuerdo de encargo del tratamiento en la Lista de subencargados, también cuando ese acuerdo falta.

5. Lo que esta política debe reconocer con honestidad

• No existe separación de funciones. Una persona aprueba la política, autoriza y administra. La compensación es que el rastro de auditoría es completo y append-only, y que las operaciones más graves exigen un paso de verificación adicional. Eso es una compensación, no una solución.
• La recuperación se prueba, pero todavía no por completo. El descifrado y la comprobación de las copias de seguridad se han probado; se ha establecido un ejercicio de recuperación completo cada trimestre y la primera ejecución sigue pendiente. Los detalles figuran en el plan de continuidad, que los clientes pueden consultar en el portal.
• Los secretos no son ilegibles para todos los agentes. Véase «Criptografía y gestión de claves»: la clave de la API de Anthropic durante una ejecución de cliente, el token ordinario de Cloudflare y, en máquinas sin cuenta de agentes separada, también la propia clave. Sellar esas vías es una ponderación pendiente.
• La separación entre organizaciones en la base de datos es una separación en la aplicación. La base de datos con los datos de todas las organizaciones es legible para la cuenta de agentes, porque los servidores que los agentes utilizan la necesitan. Que un agente de un cliente no llegue a ella lo garantiza un control fijo en la aplicación, no el sistema operativo: si ese control desaparece, la cuenta no detiene nada.
• No existe una prueba de penetración externa.

Estos puntos figuran como punto abierto en el registro de cumplimiento. Figuran aquí porque una política de seguridad que solo menciona los puntos fuertes induce a error al lector sobre aquello con lo que puede contar.

6. Cumplimiento y revisión

El registro de cumplimiento en stilops.com/nalevingsregister es la medición continua de esta política: por norma y por control, cuál es el estado, con pruebas. Las desviaciones entran como hallazgo y se encaminan a quien sea competente.

Esta política se revisa cuando la organización crezca hasta más de una persona, cuando se incorpore una nueva categoría de datos o un nuevo proveedor, tras un incidente con impacto y, como máximo, anualmente.