Software para gestoría agraria: gestionar muchas explotaciones desde un panel

Una gestoría o asesoría agraria que lleva veinte o treinta explotaciones necesita algo que el software de uso individual no da: un panel multicliente con aislamiento legal estricto entre titulares, donde la técnica que abre el cuaderno del agricultor A no puede ver ni rozar los datos del agricultor B, y donde cada anotación que introduce en nombre del titular queda firmada con su identidad, no confundida con la del propio cliente.

Eso no es un detalle de interfaz. Es la base legal del modelo de negocio del despacho: sin aislamiento real y sin trazabilidad de autoría, la gestoría asume responsabilidades que jurídicamente no son suyas y expone datos protegidos de unos clientes a las vistas de otros.

Este artículo explica cómo debe funcionar un software de gestoría agraria multicliente, qué garantías técnicas y legales son exigibles desde el primer día, y cómo Campodato las implementa en la práctica.

Nota: este artículo se centra en la operativa y el modelo de negocio del despacho que gestiona carteras de explotaciones. Si buscas el detalle de los Anexos VIII, IX y X del RD 1054/2022 como mecanismo de autorización titular-asesor, lee Autorizar al asesor a gestionar el cuaderno CUE: Anexos VIII, IX y X. Si buscas el flujo completo de Verifactu+fiscal+cuaderno por trimestre, consulta la Guía para gestorías: Verifactu, SIEX y fiscal multicliente.

---

El modelo de negocio del despacho agrario: qué lo hace diferente

Una gestoría o asesoría agraria no es un software de un solo agricultor escalado. El modelo es otro: el despacho es una organización distinta que actúa como encargada de tratamiento sobre los datos de varias organizaciones cliente. Esa diferencia de roles es la que determina todo lo demás: el tipo de acceso, el nivel de aislamiento que se exige, la trazabilidad que se necesita y los documentos que hay que firmar.

El sector agrario tiene tres características que complican la gestión multicliente respecto a otros sectores:

Primera. Las obligaciones del titular son múltiples y paralelas: cuaderno de explotación (RD 1054/2022), registro de tratamientos fitosanitarios (RD 1311/2012, con fecha de obligatoriedad electrónica el 1 de enero de 2027 conforme al RD 1039/2025), libro SILICIE si hay bodega, registro de fertilización (RD 1051/2022, obligatorio desde el 1 de enero de 2026 para explotaciones no exceptuadas), registro de jornada (art. 34.9 del ET y RD-ley 8/2019) y obligaciones fiscales. Cada marco tiene su propio ciclo, su propia Administración responsable y sus propios plazos. La gestoría que promete "llevar la explotación" tiene que llevar todos esos hilos a la vez.

Segunda. Los datos del cuaderno tienen valor jurídico directo: una anotación de tratamiento fitosanitario puede ser determinante en un control de condicionalidad PAC (RD 1049/2022) o en una inspección del Servicio de Sanidad Vegetal. Un dato incorrecto o ausente no es solo un descuido administrativo; puede derivar en una reducción de ayudas o en una sanción. La gestoría que lo gestiona asume, en la práctica, responsabilidad sobre esa calidad.

Tercera. El titular es siempre el responsable legal del cuaderno, independientemente de quién lo haya rellenado. Esto lo establece el art. 10 del RD 1054/2022 sin margen de interpretación. La gestoría actúa bajo un mandato otorgado por el titular; si anota algo incorrecto, el titular responde ante la Administración y puede repercutir el daño sobre la asesoría por la vía contractual. Sin trazabilidad de quién introdujo qué dato y cuándo, esa cadena de responsabilidad es imposible de demostrar.

---

El problema central: muchos clientes, un solo equipo

El reto operativo de un despacho con veinte o treinta explotaciones no es de capacidad bruta sino de visibilidad y priorización. La técnica que llega el lunes por la mañana no puede permitirse recorrer uno a uno los cuadernos de cada cliente para saber si hay algo urgente. Necesita una respuesta en segundos a una sola pregunta: ¿qué cliente necesita atención hoy?

Ese problema se multiplica cuando el equipo del despacho tiene varios técnicos, cada uno con una cartera distinta. Sin una herramienta que centralice el estado de todos los clientes y lo presente con una jerarquía de urgencia clara, el riesgo de que algo se caiga por las grietas es alto. Y en el ámbito agrario, lo que se cae por las grietas tiene fecha de caducidad: un plazo de anotación del cuaderno vence al mes de la operación (regla general del RD 1054/2022); un tratamiento fitosanitario no registrado antes del plazo cuenta como incumplimiento.

El segundo problema es el de la contaminación de datos. Cuando el mismo usuario de software accede a varios clientes desde una sola sesión, existe riesgo de que datos de un cliente aparezcan accidentalmente en el contexto de otro: un recinto SIGPAC precargado del cliente anterior, un número de factura que se hereda de la serie incorrecta, un producto fitosanitario en el autocomplete que corresponde a otra explotación. Ese riesgo no es teórico; ocurre cuando el software no implementa un aislamiento estricto entre los contextos de los distintos clientes.

El tercer problema, de naturaleza más jurídica, es el del acceso no legitimado. Cuando la gestoría tiene acceso a los datos de treinta titulares en un mismo sistema, ¿cómo se garantiza que el acceso a cada uno está respaldado por un mandato explícito del titular y que, si ese mandato se retira, el acceso desaparece de forma inmediata? En la mayoría de los sistemas generalistas, esto se gestiona manualmente y sin auditoría. Eso no es suficiente.

---

Aislamiento por tenant: qué significa en la práctica

El término «tenant» designa a cada organización con datos propios dentro del sistema. En un software multicliente bien diseñado, cada explotación o titular es un tenant, y el software garantiza que ninguna consulta a la base de datos puede devolver filas de un tenant distinto al que tiene activa la sesión.

La forma técnica correcta de garantizarlo es Row-Level Security (RLS) de PostgreSQL: una política que se aplica en la capa de base de datos, no en la capa de aplicación. La diferencia es crítica:

• Un filtro en la capa de aplicación (WHERE organization_id = X) puede fallar si un desarrollador olvida añadirlo, si hay un bug en el código o si se usa una ruta de consulta alternativa. La base de datos no lo sabe y devuelve lo que se le pide.
• Una política RLS activa en la base de datos convierte ese filtro en un invariante: si no hay un contexto de tenant válido en la sesión, el resultado de cualquier SELECT es cero filas. No es un error, no es un mensaje de acceso denegado; simplemente no hay datos. El sistema es fail-closed: sin contexto, sin datos.

Campodato implementa RLS sobre PostgreSQL como invariante de diseño desde las primeras olas de desarrollo. Cada conexión a la base de datos viaja con el identificador del tenant activo como variable de sesión (SET LOCAL app.current_org = 'org_xxxx'), y las políticas RLS verifican que el identificador corresponde al tenant autorizado antes de devolver ninguna fila.

Cuando la gestoría abre un cliente en Campodato, el sistema ejecuta un drill-down controlado: cambia el contexto de tenant al del cliente, pero solo si existe un mandato vigente que lo legitima. Sin mandato activo, el botón de entrar aparece en la interfaz pero la operación devuelve un error explícito («El mandato no está activo; el cliente debe reactivarlo»). El técnico del despacho ve que ese cliente está en la cartera pero no puede acceder a sus datos.

El aislamiento tiene una consecuencia que puede parecer obvia pero que muchos software ignoran: la gestoría no puede ver en un solo listado las facturas de todos sus clientes, ni los tratamientos de todas las fincas, ni los datos de los trabajadores de todos los titulares. El panel de cartera muestra semáforos e indicadores agregados (sin datos personales), pero para ver el detalle de un cliente concreto hay que entrar en ese cliente, lo que activa el cambio de contexto auditado y verificado.

Esto no es una limitación operativa. Es el modelo correcto, tanto desde el punto de vista de protección de datos (cada titular sabe que sus datos no son accesibles a otros titulares del despacho) como desde el punto de vista de responsabilidad (el log de accesos registra exactamente cuándo y con qué mandato el técnico entró en cada cliente).

---

Mandatos append-only: el consentimiento que el titular controla

El mandato de gestoría es el mecanismo por el que el titular autoriza a una asesoría concreta a acceder a sus datos en el sistema. En Campodato, el mandato se modela como un ledger de eventos append-only: cada acción sobre la delegación (alta, renovación, suspensión, revocación) crea un nuevo evento sellado en la base de datos; ninguno se modifica ni se borra.

Esto tiene tres consecuencias prácticas:

El titular es el único que puede crear o retirar un mandato. La asesoría no puede otorgarse acceso a sí misma ni puede modificar el alcance de lo que se le ha delegado. El mandato lo crea el titular en su propio contexto de tenant, especificando qué ámbitos delega y a qué nivel:

Un mandato que solo concede cuaderno: leer no permite a la gestoría anotar ni remitir tratamientos, aunque el técnico lo intente. El sistema lo deniega en la capa de autorización antes de llegar a la base de datos.

El historial del mandato es la prueba de cumplimiento RGPD. El ledger registra con sello de tiempo cada evento: cuándo el titular otorgó el consentimiento, quién de la asesoría recibió el acceso, con qué evidencia se documentó el consentimiento (campo evidencia en el evento, que puede ser un identificador de documento, una IP o una referencia al DPA firmado), y cuándo se suspendió o revocó. Ese historial no se puede alterar.

La suspensión del mandato bloquea el acceso en tiempo real. En el momento en que el titular sella un evento de suspensión o revocación, el acceso de la gestoría desaparece. No hay que esperar a ningún ciclo de sincronización ni a que el técnico cierre sesión. El siguiente intento de drill-down sobre ese cliente devuelve el error de mandato no activo. Los datos del cliente siguen en el sistema pero la asesoría no puede verlos.

La diferencia con el modelo habitual de «usuario con permiso de acceso a varios expedientes» es fundamental: aquí el consentimiento pertenece al titular, no al administrador del despacho. Eso no solo es buena práctica; es el modelo que exige el art. 6 del RGPD para el tratamiento de datos con base en el consentimiento, y el que contemplan los Anexos VIII y IX del Documento Técnico SIEX del FEGA para la delegación sobre el cuaderno electrónico de explotación.

---

Trazabilidad de autoría por anotación

Cuando la gestoría anota un tratamiento fitosanitario o una fertilización en el cuaderno de un titular, esa anotación lleva dos identidades: la del titular de la explotación (responsable legal del cuaderno) y la del técnico del despacho que introdujo el dato (ejecutor de la acción).

Esa doble identidad no es redundante. Sirve para tres cosas distintas:

Para el control de calidad interno del despacho. Si hay una anotación errónea, el responsable del despacho puede ver quién la introdujo y cuándo, y corregirla con un nuevo registro trazado. La corrección es siempre una nueva anotación; el dato original no se modifica ni se borra. El cuaderno es append-only, igual que el libro SILICIE de bodegas y que la cadena de huellas Verifactu: la integridad de los datos históricos es un principio compartido por todos los registros con efectos legales.

Para la relación contractual con el titular. Si el agricultor discute una anotación («yo no autoricé ese tratamiento» o «esa fertilización no se hizo en esa fecha»), el despacho puede demostrar que el técnico X introdujo el dato en la fecha Y bajo el mandato Z, y que el titular tenía en ese momento mandato activo con permiso de escritura sobre el cuaderno. Eso es evidencia contractual, no solo un dato interno del sistema.

Para las inspecciones de la Administración. El Servicio de Control de la comunidad autónoma o el órgano que realiza el seguimiento de los ecorregímenes PAC puede verificar qué datos están en el cuaderno y cómo llegaron ahí. La presencia de un identificador de entidad habilitada (el despacho con su Anexo VIII) junto al identificador del titular satisface la trazabilidad que exige el Documento Técnico SIEX.

En Campodato, la trazabilidad de autoría funciona así: cada anotación del cuaderno lleva el userId del técnico que la creó y el organizationId del tenant del cliente (el titular). El log de accesos de gestoría, que es append-only e independiente del cuaderno, registra además el momento del drill-down y el mandato vigente en ese momento. La combinación de los dos registros permite reconstruir, a posteriori, la cadena completa: quién tenía acceso, cuándo entró, qué anotó y con qué autorización.

---

DPA art. 28 RGPD y RAT: las obligaciones del despacho como encargado

Una gestoría agraria que accede a los datos personales de los titulares de explotaciones en nombre de estos —datos del cuaderno, datos de trabajadores para el registro de jornada, datos fiscales, datos de clientes en las facturas Verifactu— es, en términos del RGPD, un encargado del tratamiento (art. 4.8 RGPD). El titular es el responsable del tratamiento.

Esa distinción genera dos obligaciones concretas para el despacho:

1. El DPA (Data Processing Agreement o contrato de encargo del tratamiento, art. 28 RGPD). Es el contrato entre el responsable (el titular) y el encargado (la gestoría) que define qué datos se tratan, con qué finalidad, durante cuánto tiempo, con qué medidas de seguridad y bajo qué instrucciones del responsable. El art. 28.3 RGPD exige que conste por escrito (puede ser formato electrónico) y que incluya, entre otros, la duración, la naturaleza del tratamiento, las categorías de datos y los derechos del responsable, incluido el de auditoría.

Sin DPA firmado, la gestoría no puede tratar datos personales de sus clientes agrarios de forma conforme al RGPD. Esto no es una obligación que afecte solo a grandes corporaciones: cualquier despacho, por pequeño que sea, que acceda a datos de personas físicas (los propios titulares, sus trabajadores, sus clientes) en nombre de otro, necesita el DPA.

La Agencia Española de Protección de Datos (AEPD) ha desarrollado guías específicas sobre el contrato de encargo del tratamiento disponibles en aepd.es. Para gestorías agrarias, los puntos más delicados son los datos de trabajadores (datos especialmente sensibles si incluyen categorías protegidas, aunque los datos de jornada en general no lo son) y los datos de salud si la explotación tiene obligaciones de vigilancia médica preventiva.

2. El RAT (Registro de Actividades de Tratamiento, art. 30 RGPD). El encargado del tratamiento está obligado a mantener un RAT propio que describa cada actividad de tratamiento que realiza en nombre de sus responsables. Para la gestoría agraria, una actividad de tratamiento puede ser «gestión del cuaderno electrónico de explotación de titulares agrarios»; otra, «preparación de declaraciones tributarias de agricultores»; otra, «gestión de contratos de trabajo de temporeros».

El RAT del encargado no requiere inscripción en ningún registro externo. Pero debe estar disponible para la AEPD si lo solicita, y debe mantenerse actualizado. Una gestoría que empiece a llevar un cliente nuevo debe actualizar el RAT para incluir ese nuevo responsable.

Campodato no genera automáticamente el DPA ni el RAT —esos son documentos que el despacho elabora y firma con cada titular, con asesoramiento legal propio si es necesario—, pero la estructura de mandatos y el log de accesos auditado facilitan dos cosas: (a) demostrar que el acceso está legitimado por un consentimiento documentado del titular, y (b) exportar el historial de accesos para anexarlo al RAT como evidencia de las actividades reales de tratamiento realizadas.

---

El panel de cartera: cómo priorizar sin abrir cada expediente

El panel de cartera de Campodato está diseñado para responder en menos de tres segundos a la pregunta de qué cliente necesita atención. La tabla muestra una fila por cliente con tres semáforos independientes y un semáforo global que es el peor de los tres:

Semáforo Verifactu: verde si no hay incidencias AEAT en la ventana reciente; ámbar si hay un registro con estado «AceptadoConErrores»; rojo si hay dos o más incidencias o un registro con estado «Incorrecto». Un estado «AceptadoConErrores» de la AEAT significa que el registro de facturación fue aceptado pero con discrepancias en la huella recalculada; debe resolverse antes de que se convierta en un problema tributario.

Semáforo SIEX (cuaderno): verde si no hay operaciones pendientes de declarar; aviso a partir de una operación en cola; urgente a partir de diez operaciones sin remitir. La regla general del RD 1054/2022 establece un plazo de un mes desde la operación para la anotación; cuando hay operaciones en cola y ese plazo se aproxima, el semáforo refleja la urgencia.

Semáforo de plazos: verde si no hay plazos pendientes; aviso si hay alguno en los próximos quince días; urgente si hay alguno en los próximos tres días; crítico si hay algún plazo ya vencido sin cumplir.

El semáforo global de la fila es el peor de los tres. La tabla se ordena de mayor a menor urgencia, y dentro del mismo nivel, alfabéticamente. El técnico ve arriba lo que arde.

Encima de la tabla, cuatro KPIs de cabecera:

Si los cuatro son cero o bajos al empezar el día, la jornada empieza tranquila. Si hay clientes en riesgo, el orden del trabajo está determinado.

Cuando un cliente tiene el mandato suspendido o revocado, aparece en la tabla con semáforos en «desconocido» y sin posibilidad de drill-down. La gestoría sabe que ese cliente está en la cartera pero no tiene acceso a sus datos. Eso también es información útil: si el cliente suspendió el mandato y no lo ha reactivado, hay que llamarle.

---

Tabla comparativa: qué debe incluir un software de gestoría agraria

---

Cómo funciona en Campodato

Campodato tiene el módulo de gestoría multicliente como parte del núcleo del producto, desarrollado en la Ola 9 del proyecto y verificado en tests de integración real contra PostgreSQL con RLS activo.

El flujo completo desde que una gestoría incorpora un cliente nuevo hasta que lo tiene operativo tiene estos pasos:

1. Alta del cliente en la cartera del despacho. La gestoría crea en su panel una referencia al cliente (nombre, NIF, CCAA de la explotación). El cliente aparece en la tabla con estado de mandato «pendiente» y semáforos en «desconocido».

2. El titular crea el mandato en su tenant. El titular de la explotación entra en su panel de Campodato, localiza la solicitud de la gestoría y sella el evento de alta del mandato, especificando los ámbitos que delega. Ese evento queda registrado en el ledger append-only con el identificador del usuario del titular, la fecha y hora, y la evidencia del consentimiento.

3. El sistema recalcula el acceso vigente. Al sellar el evento de alta, el motor recalcula el estado del acceso: el mandato pasa a «activo» y los permisos delegados quedan materializados en la tabla de accesos vigentes. El cliente aparece en la cartera de la gestoría con semáforo activo.

4. La gestoría hace el drill-down. Al pulsar sobre el cliente, el sistema verifica el mandato vigente, registra el acceso en el log auditado (quién, cuándo, qué mandato) y cambia el contexto de tenant al del cliente. A partir de ahí, todas las pantallas muestran solo los datos de ese cliente.

5. Cada anotación lleva la firma del técnico. Cuando el técnico introduce una anotación en el cuaderno del titular, el registro lleva su userId como autor de la acción y el organizationId del titular como propietario del dato. Si más adelante el titular o la Administración revisan el cuaderno, pueden ver que esa anotación la introdujo el técnico X del despacho Y en la fecha Z.

6. La revocación es inmediata. Si el titular revoca el mandato, el siguiente intento de drill-down devuelve un error: «El mandato está revocado; el cliente debe reactivarlo». Los datos del titular siguen en el sistema, pero la gestoría no puede acceder a ellos. El log registra el intento denegado.

El módulo de gestoría de Campodato no incluye generación automática del DPA ni del RAT. Esos documentos los elabora el despacho con su propio asesoramiento legal. Lo que Campodato proporciona es la infraestructura de trazabilidad que permite al despacho demostrar que el acceso siempre estuvo legitimado: el ledger de mandatos y el log de accesos son la evidencia documental de ese cumplimiento.

---

Preguntas frecuentes

¿Puede la gestoría crear el mandato en nombre del cliente?

No. El mandato lo crea el propio titular en su contexto de tenant. La gestoría no puede otorgarse acceso a sí misma. Esto es coherente con el principio de consentimiento del RGPD y con la estructura de los Anexos VIII y IX del Documento Técnico SIEX del FEGA, que exigen que la autorización para actuar ante el cuaderno electrónico la firme el propio titular. En la práctica, la gestoría envía al titular un enlace de invitación; el titular accede a su panel y sella el mandato.

¿Qué pasa si el IUWS de una comunidad autónoma está caído cuando hay que remitir el cuaderno?

La indisponibilidad del servicio de la Administración no genera incumplimiento del titular. Campodato registra el intento de envío con sello de tiempo y reencola la remisión. El plazo legal de anotación es de un mes desde la operación (regla general del RD 1054/2022); si la indisponibilidad supera ese plazo, es recomendable documentar el intento ante la CCAA. Cada comunidad autónoma tiene su propio adaptador IUWS en Campodato con fail-closed: sin conexión, el envío no sale; con conexión, la operación se reintenta desde la cola.

¿La gestoría puede ver los datos de todos sus clientes en una sola pantalla?

El panel de cartera muestra semáforos e indicadores agregados de todos los clientes, pero sin exponer datos de una explotación concreta. Para ver el detalle —las facturas de un cliente, sus anotaciones de cuaderno, sus trabajadores fichados— hay que entrar en ese cliente mediante el drill-down, que activa el cambio de contexto y el log auditado. Es un diseño intencionado: el RLS de PostgreSQL garantiza que ningún dato de un cliente sea visible en el contexto de otro.

¿Es obligatorio el DPA con cada cliente agrario que llevo?

Sí, si la gestoría accede a datos personales del titular o de sus trabajadores en nombre del titular. El art. 28 RGPD obliga a documentar el encargo del tratamiento por escrito. La Agencia Española de Protección de Datos dispone de modelos orientativos en aepd.es. El incumplimiento puede derivar en sanciones del Título IX LOPDGDD y, en caso de inspección de la AEPD, en la obligación de justificar la base legal del acceso.

¿El software certifica que la gestoría está habilitada como entidad ante las CCAA?

No. El trámite de habilitación como entidad representante ante cada comunidad autónoma (que permite a la gestoría actuar ante el CUE autonómico con el Anexo VIII del titular) es una gestión administrativa que el despacho debe realizar ante cada CCAA donde opere. El procedimiento varía por comunidad autónoma. Campodato no sustituye ese trámite; es el canal técnico por el que la entidad habilitada conecta con el IUWS una vez que ha completado su habilitación autonómica.

¿Cómo se actualiza el RAT del despacho cuando incorporo un cliente nuevo?

El RAT del encargado del tratamiento (art. 30.2 RGPD) debe actualizarse cada vez que se incorpora una nueva actividad de tratamiento o un nuevo responsable para quien se actúa. En la práctica, incorporar un cliente agrario nuevo implica añadir al RAT la descripción de las actividades de tratamiento que se realizarán en su nombre (gestión del cuaderno, preparación de modelos AEAT, registro de jornada, etc.) y los datos del responsable (el titular). El log de accesos de Campodato puede exportarse para documentar las actividades reales de tratamiento realizadas en cada período.

---

Conclusión y siguiente paso

El canal de la gestoría agraria es el más eficiente para llevar el cumplimiento digital al campo. Una sola técnica puede acompañar a veinte o treinta titulares en la transición al cuaderno electrónico obligatorio, al registro de fitosanitarios en soporte digital (obligatorio desde el 1 de enero de 2027) y a las demás exigencias de la normativa agraria y fiscal.

Pero ese acompañamiento solo es sostenible, jurídicamente correcto y escalable si la herramienta garantiza tres cosas desde el primer cliente hasta el último: aislamiento real entre tenants (RLS en base de datos, no filtros de aplicación), mandatos controlados por el titular con ledger append-only, y trazabilidad de autoría por cada anotación que el técnico introduzca en nombre del titular.

El despacho que elige una herramienta sin esas garantías no solo asume un riesgo técnico; asume un riesgo legal. El RGPD exige documentar el encargo del tratamiento (DPA) y las actividades de tratamiento (RAT); la normativa agraria exige que cada dato del cuaderno pueda atribuirse a su autor; y el titular, cuando le llega una inspección, necesita demostrar que quien le llevaba el cuaderno tenía autorización para ello y que la usó correctamente.

Si quieres ver cómo funciona el panel de cartera de Campodato con tu propia cartera de clientes, el módulo de gestoría está disponible desde el plan Despacho. El primer cliente se incorpora en menos de diez minutos; la habilitación ante las CCAA donde operes la gestionamos de forma conjunta.

Ver cómo funciona el panel multicliente de Campodato

---

Fuentes oficiales

• RD 1054/2022, de 27 de diciembre (SIEX, REA, CUE; Anexo II contenido mínimo; art. 10 autorización). BOE-A-2022-23054
• RD 34/2025, de 21 de enero (voluntariedad CUE completo hasta 2028). BOE-A-2025-998
• RD 1039/2025, de 19 de noviembre (registro electrónico de fitosanitarios obligatorio desde 01-01-2027, modificando el art. 16 del RD 1311/2012).
• RD 1311/2012, de 14 de septiembre (uso sostenible de productos fitosanitarios). BOE-A-2012-11605
• RD 1051/2022, de 27 de diciembre (nutrición sostenible en los suelos agrarios; fertilización obligatoria desde 01-01-2026). BOE-A-2022-23052
• RD 1049/2022, de 27 de diciembre (condicionalidad PAC). BOE-A-2022-23049
• Reglamento (UE) 2016/679 (RGPD), arts. 4.8, 6, 28, 30. EUR-Lex
• Documento Técnico SIEX del FEGA (Resolución 25 de mayo de 2023, Anexos VIII, IX y X). Disponible en fega.gob.es/es/siex/documentacion-tecnica-agricola-siex.
• Guía AEPD sobre contratos de encargo del tratamiento (art. 28 RGPD). Disponible en aepd.es.
• RD-ley 8/2019, de 8 de marzo (registro de jornada, art. 34.9 ET). BOE-A-2019-3481

---

Última revisión normativa: junio de 2026. La normativa agraria y de protección de datos está sujeta a modificaciones; verifica siempre con la fuente oficial antes de tomar decisiones.

Autor: Equipo Campodato (Summum Marketing)