En muchas plataformas digitales, el tratamiento de datos personales suele abordarse como una cuestión principalmente documental. Se redacta una política de privacidad, se incorporan cláusulas en los términos y condiciones y, en algunos casos, se agrega un acuerdo de tratamiento de datos. Sin embargo, ese abordaje suele aparecer en una etapa posterior, cuando ya están definidas —de forma implícita o no— las decisiones relevantes sobre qué datos se utilizan, con qué finalidad y bajo qué lógica operativa. El punto crítico no está en el documento sino en esa definición previa, que muchas veces no se realiza de manera consciente.
Cuando la estructura del tratamiento no se analiza desde el diseño del servicio, es habitual que el contrato intente ordenar algo que en la práctica ya funciona con una lógica distinta. En ese contexto, las categorías jurídicas pasan a cumplir un rol declarativo más que descriptivo, y el encuadre de las partes como responsables o encargados no necesariamente refleja lo que efectivamente ocurre en la operación diaria.
En modelos como SaaS, marketplaces, aplicaciones de beneficios o soluciones fintech, la delimitación de roles no siempre resulta evidente. Una empresa puede presentarse como proveedor tecnológico y, al mismo tiempo, tomar decisiones relevantes sobre el uso de los datos, ya sea a través de funcionalidades propias, análisis internos o desarrollo de nuevas herramientas. A la inversa, un cliente puede asumir que ha delegado completamente el tratamiento en la plataforma, cuando en realidad sigue definiendo la finalidad principal en relación con sus usuarios, empleados o clientes.
La distinción entre responsable y encargado del tratamiento se construye, en este contexto, a partir de quién determina la finalidad y los medios esenciales del tratamiento y quién actúa siguiendo instrucciones. No se trata de una calificación abstracta ni de una etiqueta contractual, sino de una consecuencia directa de cómo está estructurado el servicio. Cuando esa estructura no se analiza con cierto nivel de detalle, la asignación de roles tiende a simplificarse y a replicar modelos estándar que no siempre encajan con la realidad.
En Argentina, esta distinción debe leerse a la luz de la Ley 25.326 de Protección de los Datos Personales y de su Decreto Reglamentario 1558/2001. La ley trabaja sobre la figura del “responsable o usuario del archivo, registro, base o banco de datos”, mientras que la reglamentación contempla los supuestos en los que un tercero presta servicios de tratamiento de datos por cuenta de ese responsable. Aunque la terminología local no siempre coincide exactamente con la utilizada por el RGPD o por los modelos internacionales de DPA, la lógica de fondo es similar en cuanto exige identificar quién decide sobre el tratamiento y quién actúa siguiendo instrucciones ajenas.
La simplificación en la asignación de roles suele pasar inadvertida mientras la operación funciona sin fricciones y no hay situaciones que obliguen a revisar cómo se están tratando los datos. Cuando surgen incidentes de seguridad, reclamos de usuarios o requerimientos regulatorios, esa falta de precisión empieza a hacerse visible y la discusión deja de centrarse en lo que dice el contrato para desplazarse hacia la operación real, es decir, hacia quién tomó decisiones sobre el tratamiento de los datos, cómo se utilizaron y con qué grado de autonomía actuó cada parte.
En entornos SaaS, por ejemplo, es frecuente considerar al cliente como responsable del tratamiento respecto de los datos que carga en la plataforma. Sin embargo, esa calificación puede volverse discutible cuando el proveedor utiliza esa información para finalidades propias, como la mejora del servicio, el desarrollo de funcionalidades o el uso de datos en sistemas de inteligencia artificial. En esos supuestos, la intervención del proveedor excede la mera ejecución de instrucciones y comienza a incidir en la lógica del tratamiento.
Los marketplaces presentan un escenario aún más complejo, en la medida en que la plataforma interactúa simultáneamente con distintos actores y gestiona múltiples flujos de datos. El tratamiento de la información necesaria para procesar una transacción no plantea los mismos interrogantes que el uso de esos datos para fines comerciales propios, segmentación o desarrollo del negocio. La posición de la plataforma puede variar según el tipo de dato y la finalidad específica, lo que exige un análisis más granular.
En plataformas de beneficios o servicios corporativos, la relación entre la empresa cliente, la plataforma y el usuario final suele generar configuraciones intermedias. La empresa puede mantener un rol claro como responsable en relación con los datos de sus empleados, pero la plataforma, al definir la estructura del servicio y participar en la experiencia del usuario, no siempre encaja de manera estricta en el rol de encargado. La forma en que se distribuyen las decisiones sobre los datos es lo que termina determinando el encuadre, más allá de cómo se presente la relación a nivel comercial.
Dentro de este escenario, el Data Processing Agreement (DPA) suele incorporarse como un mecanismo para ordenar la relación entre las partes. Su utilidad es evidente cuando existe una distinción clara entre quien define la finalidad del tratamiento y quien actúa por cuenta de un responsable. Sin embargo, su eficacia depende de que esa distinción esté correctamente identificada. Si la estructura subyacente es difusa o no responde a la realidad operativa, el DPA tiende a convertirse en un instrumento formal que no resuelve los puntos críticos.
Desde esa perspectiva, el DPA no es una figura extraña al derecho argentino, aunque no siempre se lo denomine de ese modo ni se lo instrumente como documento separado. El Decreto 1558/2001 contempla expresamente la prestación de servicios de tratamiento por terceros y exige que esa relación se encuentre regulada contractualmente, incluyendo pautas sobre instrucciones, confidencialidad y seguridad. En la práctica local, muchas veces esa regulación aparece incorporada dentro del contrato comercial principal, en un anexo o en cláusulas específicas, en lugar de presentarse como un documento autónomo al estilo europeo.
En el mercado local es frecuente la adopción de modelos contractuales basados en estándares internacionales, en particular aquellos derivados del RGPD. Esos modelos incorporan previsiones detalladas sobre instrucciones, subencargados, medidas de seguridad o transferencias, que pueden resultar útiles en determinados contextos. El problema aparece cuando se los utiliza sin un análisis previo de la operación concreta, lo que puede llevar a declarar roles o asumir obligaciones que no se corresponden con el funcionamiento real de la plataforma.
La comparación con otros marcos regulatorios ayuda a entender estas diferencias, así tanto el RGPD europeo como la Lei Geral de Proteção de Dados (LGPD) de Brasil formulan de manera más explícita la distinción entre quien determina la finalidad del tratamiento y quien actúa por cuenta de ese responsable. Esa claridad normativa explica por qué en esos sistemas es más habitual encontrar acuerdos de tratamiento de datos separados o anexos específicos. En Argentina, en cambio, la Ley 25.326 responde a una lógica anterior al desarrollo de plataformas digitales complejas, lo que hace que estas definiciones deban reconstruirse a partir de la operación concreta más que de categorías legislativas expresas.
En ese tipo de situaciones, el contrato puede transmitir la idea de que el esquema de cumplimiento está completo, aunque la asignación de responsabilidades siga siendo ambigua. Frente a un conflicto, esa ambigüedad no se resuelve por la vía formal, sino a partir del análisis de cómo se llevan adelante los tratamientos en la práctica, lo que puede dejar a las partes en una posición menos previsible de la que creían tener.
La definición de quién es responsable del tratamiento, por lo tanto, no debería abordarse como una cuestión accesoria ni como un punto a resolver al momento de redactar el contrato. Se trata de una decisión que forma parte de la arquitectura del servicio y que impacta directamente en la forma en que se diseñan las funcionalidades, se gestionan los datos y se estructuran las relaciones con clientes y usuarios.
Cuando esa definición se realiza de manera consistente con la operación real, los instrumentos contractuales cumplen su función de reflejar y ordenar esa estructura. En ausencia de ese análisis previo, el contrato y el DPA tienden a operar como soluciones aparentes, que pueden resultar insuficientes cuando se los confronta con situaciones concretas.
Por Andrés San Juan
Estudio Lexar
Protección de datos personales en Argentina
