Seguridad en IA: qué es un sandbox y por qué tu pyme necesita uno

Tienes un modelo de IA corriendo en tu servidor. Le das acceso a tu base de datos de clientes. Le das acceso a tu sistema de facturación. Le das acceso a tu correo electrónico. Y luego te preguntas: "¿Y si hace algo que no debería?"

Buena pregunta. La respuesta se llama sandbox.

Qué es un sandbox

Un sandbox es un entorno aislado donde un programa puede ejecutarse sin afectar el resto del sistema. Es como una habitación acolchada: lo que pasa dentro, se queda dentro.

Si el modelo intenta acceder a un archivo que no debería, el sandbox lo bloquea. Si intenta conectarse a internet, el sandbox lo corta. Si intenta ejecutar un comando del sistema operativo, el sandbox lo ignora. El modelo puede pensar lo que quiera, pero solo puede hacer lo que tú le permitas.

No es un concepto nuevo. Los navegadores web usan sandboxes desde hace décadas. Los móviles ejecutan cada app en su propio sandbox. Los bancos de arena literales existen para que los niños jueguen sin salirse del parque. El principio es el mismo: delimitar el espacio de acción.

Por qué tu pyme lo necesita

Si usas ChatGPT o Claude en el navegador, ya estás usando un sandbox. Es el proveedor quien decide qué puede y no puede hacer el modelo. No puedes ejecutar código arbitrario desde la interfaz web. No puedes acceder al sistema de archivos del servidor. Eso es seguridad por diseño — pero es su sandbox, no el tuyo.

El problema aparece cuando despliegas IA en tu propia infraestructura. Ahí no hay nadie que te proteja por defecto. Tú decides qué permisos tiene el modelo. Y si le das permisos de más, las consecuencias son tuyas.

Ejemplos concretos:

• Un agente que gestiona devoluciones. Le das acceso a la pasarela de pagos para procesar reembolsos. ¿Qué evita que procese un reembolso de 50.000€ a una cuenta arbitraria? Solo las instrucciones que le diste. Si esas instrucciones tienen un hueco, el hueco se explota.
• Un asistente que lee correos. Le das acceso al email para clasificar solicitudes. ¿Qué evita que envíe correos en nombre de tu empresa? Solo una capa de permisos que quizás no configuraste.
• Un modelo que consulta tu ERP. Le das acceso de lectura a la base de datos. ¿Y si un prompt ingenioso logra que ejecute una consulta DELETE? Las bases de datos no distinguen entre un usuario y un modelo si ambos tienen las mismas credenciales.

Cómo funciona en la práctica

Un sandbox para IA no es solo "limitar permisos". Tiene capas:

1. Aislamiento de red

El modelo no necesita internet. Si está corriendo localmente, sus respuestas se generan a partir de los datos que ya tiene. Corta el acceso a la red y eliminas la posibilidad de exfiltración de datos o de que el modelo descargue algo que no debería.

2. Sistema de archivos de solo lectura

El modelo lee documentos, no los modifica. Monta el directorio de datos como solo lectura. Si el modelo necesita escribir resultados, escribe en un directorio separado que no afecta a los datos de origen.

3. Permisos mínimos

El agente que clasifica correos no necesita acceso a facturación. El que procesa facturas no necesita acceso a RRHH. Cada agente, los permisos estrictamente necesarios. Ni uno más. Esto se llama principio de mínimo privilegio y es seguridad 101.

4. Logs y auditoría

Todo lo que hace el modelo se registra. Cada consulta, cada acción, cada acceso a datos. No solo para detectar problemas después del hecho, sino para poder auditar que el sistema se comporta como debería.

5. Capa de validación

Antes de que cualquier acción del modelo se ejecute realmente (enviar un correo, procesar un pago, modificar un registro), pasa por una capa de validación que comprueba que la acción está dentro de los parámetros permitidos. El modelo propone, la validación dispone.

El mito del "si es local, ya es seguro"

Correr IA localmente es más seguro que enviar tus datos a un proveedor cloud. Eso es verdad. Pero no es lo mismo que seguro.

Local significa que tus datos no salen de tu red. Pero un modelo local con permisos excesivos es como tener una puerta blindada en la entrada y dejar las ventanas abiertas. El modelo no va a enviar tus datos a OpenAI, pero sí puede hacer cosas dentro de tu sistema que no querías que hiciera.

La combinación ganadora es IA local + sandbox. Datos en tu servidor, permisos bajo control, acciones auditadas.

La analogía que lo aclara

Imagina que contratas a alguien para clasificar documentos en tu oficina. Opción A: le das las llaves de todo el edificio, el código de la caja fuerte y la contraseña del sistema informático. Opción B: le das acceso solo a la sala de documentos, un escritorio, y una regla: "clasifica estos papeles, pero no toques nada más".

Ambas opciones funcionan. La opción A es más rápida porque no tienes que configurar permisos. La opción B es más segura porque si esa persona comete un error —o si alguien la engaña para que haga algo que no debería— el daño está contenido.

Un sandbox es la opción B. Para tu IA.

Qué hacer ahora

1. Audita los permisos. Si ya tienes IA corriendo, revisa qué acceso tiene. Te puede sorprender.
2. Implementa mínimo privilegio. Cada agente, solo los permisos que necesita. Nada más.
3. Aísla la red. Si el modelo no necesita internet, no se lo des.
4. Añade logs. Si no puedes ver lo que hace, no puedes mejorar lo que hace.
5. Crea una capa de validación. Antes de cualquier acción irreversible, un humano o una regla confirme.

No necesitas hacerlo todo a la vez. Empieza por auditar permisos. Es lo que más impacto tiene con menos esfuerzo.

En Neurosint diseñamos despliegues de IA con seguridad por defecto. Sandboxes, permisos mínimos, auditoría integrada. Si vas a meter IA en tu empresa, que sea segura desde el primer día. Hablemos.