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 retransmite el encargo y la respuesta sin persistir su contenido: las columnas de contenido están eliminadas del esquema. Sí trata los datos de cuenta y el registro mínimo de sesiones descritos en la política. Los documentos originales permanecen en el Nodo, aunque los fragmentos necesarios puedan formar parte de la respuesta o enviarse al proveedor si eliges un modelo API.
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: con Ollama no añades un proveedor de inferencia externo.
- 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 dos ejes separados: rol técnico sobre el Nodo y grants Lectura/Trabajo sobre Espacios concretos. Ningún admin o supervisor recibe documentos por su rol. Ejecutar comandos va aparte y apagado, porque quien lo tiene alcanza esa máquina con los permisos del sistema.
¿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 y sin cuota por tarea: el cómputo lo pone tu equipo, así que no hay contador de tareas.