Responsable, encargado y subencargado cuando metes IA en el proceso
Cada proveedor que toca datos personales por cuenta tuya entra en la cadena del artículo 28 del RGPD: contrato de encargo, instrucciones documentadas, autorización de subencargados y la obligación de responder de ellos. Con la IA esa cadena se alarga rápido, porque el proveedor de la aplicación usa a su vez el modelo de un tercero que se apoya en la nube de un cuarto.
La cadena típica, y por qué es incómoda
Tú eres responsable del tratamiento. La herramienta de IA que contratas es encargada. El proveedor del modelo que usa por debajo es subencargado, y la infraestructura donde corre, otro. El artículo 28.2 exige tu autorización para los subencargados y el 28.4 impone al encargado las mismas obligaciones frente a ellos. En la práctica, aceptas una lista que puede cambiar con un preaviso.
Cada eslabón es, además, un sitio más donde tu expediente existe en algún momento. Una cadena bien contratada reparte responsabilidades; no reduce el número de copias.
Qué cambia si el contenido no llega al proveedor
Mycel ejecuta en tu Nodo. El servidor es un relevo sin estado y el contenido de tus tareas no tiene dónde guardarse: las columnas están eliminadas del esquema. Eso no significa que no tratemos ningún dato tuyo: los datos de tu cuenta y el registro mínimo de sesiones sí existen y están descritos en la política de privacidad. Lo que no entra en esa cadena es el material sensible con el que trabaja el agente.
Si conectas tu propia clave de API, aparece un eslabón nuevo y conviene verlo con claridad: ese proveedor de modelo recibe tus prompts, directamente desde tu Nodo. Es una relación tuya con él, con su política y sus condiciones, y nosotros no estamos en medio. En modo local, ese eslabón no existe.
Y dentro de tu casa, quién ve qué
El artículo 32 pide medidas apropiadas, y el artículo 5 de la LOPDGDD impone el deber de confidencialidad a quienes intervienen en el tratamiento. Dentro de un Nodo compartido eso se traduce en el reparto: cuatro roles y acceso a carpetas concretas por persona, con el permiso de ejecutar comandos apagado por defecto.
Lo decimos entero porque es lo útil: conceder shell a alguien equivale a darle acceso de lectura a esa máquina, y las credenciales de correo se guardan en el disco del Nodo, así que para correspondencia la regla es un Nodo por persona. Mycel no te hace cumplir; te da el mapa exacto de dónde llega cada permiso para que decidas tú. Esto no es asesoramiento jurídico.
Cómo funciona, paso a paso
- Dibujas la cadena actual: quién trata tus datos por cuenta tuya y quién por cuenta de ellos.
- Marcas qué eslabones desaparecen si el trabajo se ejecuta en una máquina tuya.
- Decides modelo local o clave de API sabiendo que la segunda opción añade un eslabón tuyo.
- Repartes roles y carpetas dentro del Nodo, y dejas el shell apagado salvo para quien deba tenerlo.
Qué necesitas
- Saber quiénes son hoy tus encargados: sin ese inventario no hay nada que simplificar.
- Una máquina bajo tu administración para alojar el Nodo.
- Tu contrato y tu registro de actividades del artículo 30. Eso lo mantienes tú.
Qué te llevas
- Menos eslabones en la cadena: el contenido de la tarea no sale de tu máquina.
- Un reparto de accesos por persona y por carpeta, revocable en el acto.
- Traza exportable en JSON con quién lanzó cada tarea, con el alcance ajustado a su rol.
Más preguntas
¿El proveedor de mi clave de API es subencargado?
Recibe tus prompts directamente desde tu Nodo, con tu clave y bajo su política. Cómo se califique esa relación en tu esquema es un análisis tuyo; lo que sí es un hecho es que nosotros no estamos en medio de ese envío y no vemos ni la clave ni el contenido.
¿Cómo limito lo que ve cada empleado?
Con roles (dueño, admin, operador, supervisor) y acceso a carpetas concretas. Un operador solo ve lo suyo; un supervisor lo ve todo y no ejecuta. Y el permiso de ejecutar comandos va aparte y apagado, porque quien lo tiene alcanza esa máquina entera.
¿Y las cuentas de correo del equipo?
Cada cuenta es de quien la conecta y un compañero no la abre, ni siquiera pidiéndoselo al agente. Pero las credenciales se cifran en el disco del Nodo, y el dueño de esa máquina puede leer los buzones conectados en ella. Por eso, para trabajar con correo, un Nodo por persona.
Pruébalo con tus propios documentos
Creas la cuenta, abres el Nodo y le encargas la primera tarea. Es gratis e ilimitado: el cómputo lo pone tu equipo, así que no hay nada que racionar.