Seguridad y RGPD en la fiscalización en la nube: qué deben comprobar las empresas italianas

Trasladar la fiscalización de un Registratore Telematico (RT) situado junto a la caja a una API en la nube cambia dónde se procesan físicamente los datos de las transacciones y cómo debe evaluar una empresa su relación con quien opera esa infraestructura. Por sí solo, esto no cambia las dos obligaciones de cumplimiento independientes que existen en Italia. Las normas italianas sobre los corrispettivi telematici ya exigen que los datos lleguen íntegros y sin alteraciones a la Agenzia delle Entrate (AdE), la agencia tributaria italiana; el RGPD es una capa independiente, de ámbito comunitario, que regula cómo se almacenan, procesan y protegen los datos personales dentro de esas transacciones. Una empresa que pasa de hardware RT a un proveedor de fiscalización en la nube está comprobando ambas cosas a la vez, no sustituyendo una por la otra.

Puntos clave

• Las soluciones de fiscalización en la nube siguen necesitando la certificación y homologación de la AdE para la función fiscal en sí; el cumplimiento del RGPD es un requisito adicional independiente que se suma, no un sustituto. En agosto de 2026, ninguna solución de fiscalización en la nube había completado la homologación de la AdE; se esperan las primeras homologaciones a finales de 2026 o principios de 2027.
• Las funciones de fiscalización en Italia son distintas: el Produttore (fabricante) desarrolla el software, y el Erogatore (proveedor) lo opera para los comercios. La norma ISO 27001 es obligatoria para ambas funciones, pero las obligaciones del RGPD recaen específicamente sobre el Erogatore, la entidad que realmente procesa los datos.
• Las transmisiones de los corrispettivi telematici están diseñadas para minimizar los datos personales: el campo de pago solo registra el método de pago y el importe, no los datos completos de la tarjeta, y el código fiscal de un cliente, cuando se recoge, se guarda cifrado mediante hash en lugar de en claro. Las facturas y los identificadores de programas de fidelización no forman parte en absoluto del flujo de datos de fiscalización.
• El artículo 33 del RGPD exige notificar al Garante per la protezione dei dati personali (la autoridad italiana de protección de datos) en un plazo de 72 horas desde que se tiene conocimiento de una brecha de datos personales; quién asume realmente ese plazo depende de lo que establezca el contrato con el proveedor sobre los tiempos de notificación entre encargado y responsable.
• El almacenamiento de datos fiscales italianos fuera de la UE no es solo un escenario de transferencia que se pueda gestionar con cláusulas contractuales tipo: está prohibido de forma expresa y absoluta por la propia especificación técnica de la AdE.
• Las condiciones contractuales de un proveedor, no sus mensajes de marketing, determinan quién es responsable si un fallo de seguridad de los datos afecta a los registros fiscales de una empresa.

¿Qué datos procesa realmente la fiscalización en la nube?

Los sistemas de fiscalización en la nube procesan datos a nivel de transacción, y parte de esos datos constituye datos personales según el RGPD, por lo que el RGPD se aplica junto a las normas fiscales italianas, no al margen de ellas. Pero el alcance es más reducido de lo que sugeriría una comparación genérica con un "sistema de punto de venta", porque los corrispettivi telematici están diseñados para minimizar lo que se transmite:

• Los datos de pago se reducen a tipo e importe. La transmisión registra que una venta se pagó con tarjeta o en efectivo y por qué importe, no el número de tarjeta ni otras credenciales de pago.
• El código fiscal, cuando existe, se cifra mediante hash. Cuando se recoge el codice fiscale de un cliente, se almacena en forma de hash en lugar de en claro.
• Las facturas son un tipo de documento independiente. Una factura no forma parte de la transmisión de los corrispettivi telematici en sí, por lo que no debería figurar en una lista de lo que contiene el flujo de datos de fiscalización.
• Los identificadores de programas de fidelización no tienen reconocimiento oficial en el sistema. No son un campo reconocido en el modelo de datos de los corrispettivi telematici.

Nada de esto excluye al sistema del ámbito del RGPD. Un tipo de pago con su importe, o un código fiscal cifrado mediante hash, pueden seguir siendo datos personales si pueden vincularse a una persona: el hash reduce lo que queda expuesto, pero no convierte automáticamente el campo en anónimo según las propias definiciones del RGPD. Para una empresa que evalúa a un proveedor, la cuestión práctica es más concreta que "¿se aplica el RGPD de forma genérica a los datos de un TPV?": se trata de qué campos concretos transmite realmente el sistema, y de si las afirmaciones del proveedor sobre minimización de datos coinciden con lo que define la propia especificación de la AdE.

Funciones en la normativa italiana de fiscalización: Produttore, Erogatore y dónde se aplica el RGPD

La normativa italiana de fiscalización separa la entidad que desarrolla una solución de la que la opera para los comercios, y esa distinción importa tanto para la certificación como para el RGPD:

• El Produttore (fabricante) desarrolla el software —los módulos PEM y PEL— conforme a la especificación técnica de la AdE.
• El Erogatore (proveedor) distribuye la solución y la mantiene operativa para los comercios, y es la entidad legal y operativamente responsable ante la AdE y ante el comercio si algo falla.

La ISO 27001 es un requisito para ambas funciones. El RGPD, en cambio, no: las obligaciones del RGPD recaen sobre el Erogatore, porque es la parte que realmente opera el sistema y procesa los datos que circulan por él. La función de Produttore, por sí sola, no tiene relevancia a efectos del RGPD.

fiskaly ejerce ambas funciones para su propia solución de fiscalización en la nube. Cuando fiskaly, en cambio, suministra el software subyacente a un tercero que actúa como Erogatore, ese tercero necesita tanto una solución certificada y homologada como su propia acreditación ante la AdE como proveedor: la certificación del software por sí sola no sustituye la acreditación propia del Erogatore.

¿Qué confirma la ISO 27001 y qué deja fuera?

La ISO 27001 certifica que una organización mantiene un sistema de gestión de seguridad de la información (SGSI) documentado que cubre evaluación de riesgos, controles de acceso y respuesta ante incidentes. No confirma por sí misma el cumplimiento del RGPD, ni tampoco la certificación fiscal de la AdE: es una declaración sobre cómo gestiona una empresa la seguridad de la información, no sobre lo que debe hacer una solución certificada concreta.

fiskaly cuenta con certificación ISO 27001 en todo su grupo de empresas, incluida fiskaly Italia; el Trust Center de fiskaly documenta directamente el alcance. Se trata de una señal relevante para una empresa que evalúa a un proveedor, pero responde a una pregunta distinta de si una solución de fiscalización está certificada para cumplir una obligación de los corrispettivi telematici.

La certificación y la homologación de la función fiscal son un proceso de dos fases, y la propia AdE no "certifica" una solución. Primero, un organismo autorizado —el CNR di Pisa y el Politecnico di Milano son los dos actualmente activos— certifica que la solución cumple la especificación técnica. Después, la Commissione Misuratori Fiscali determina la homologación. Ambos pasos son necesarios antes de que una solución pueda salir al mercado. En agosto de 2026, ninguna solución de fiscalización basada en software había completado la homologación; fiskaly participa en la fase piloto de la AdE y SOGEI para la transmisión basada en API, con el apoyo del CNR di Pisa en la parte de certificación. No conviene tratar un camino de fiscalización en la nube como ya plenamente certificado en Italia: conviene comprobar en qué punto de ese proceso se encuentra realmente un proveedor concreto.

¿Qué controles de seguridad exige la especificación de la AdE?

La ISO 27001 describe cómo gestiona un proveedor la seguridad en términos generales; la especificación de la AdE describe lo que debe hacer la propia solución certificada, con independencia de la postura general de seguridad del proveedor. Algunos de los controles que prescribe la especificación:

• El PEL se comunica con el sistema de la AdE mediante TLS 1.2 con autenticación mutua X.509, utilizando un certificado emitido en el momento de la acreditación; el mismo requisito se aplica al software externo que llama a las API de la solución (§9.3 de la especificación técnica).
• Las claves privadas de firma deben residir en una zona segura que impida su extracción y duplicación (§9.2).
• Cada documento comercial y cada archivo de registro (journal) se firma con un certificado por dispositivo, y los registros llevan una cadena de hash que permite detectar secuencias alteradas.
• El Erogatore debe registrar todos los accesos a los datos almacenados (§9.7).

Son requisitos técnicos fijos que una solución certificada debe implementar, no "buenas prácticas de seguridad" opcionales que un proveedor pueda omitir; por eso son una cuestión independiente de la postura general del proveedor en materia de ISO 27001.

¿Qué ocurre si un proveedor de fiscalización en la nube sufre una brecha de datos?

El artículo 33 del RGPD exige que un responsable del tratamiento notifique al Garante per la protezione dei dati personali en un plazo de 72 horas desde que tiene conocimiento de una brecha de datos personales, y el artículo 34 exige notificar directamente a las personas afectadas cuando la brecha supone un riesgo elevado para sus derechos.

Para una empresa que utiliza un proveedor de fiscalización en la nube, la cuestión práctica es quién asume ese plazo de 72 horas. Si el proveedor actúa como encargado del tratamiento en virtud de un acuerdo conforme al artículo 28 del RGPD, el encargado debe notificar al responsable —la propia empresa— sin dilación indebida, de modo que la empresa pueda cumplir su propia obligación de 72 horas ante el Garante. Un contrato que no diga nada sobre los plazos de notificación de brechas deja a la empresa expuesta a incumplir ese plazo sin culpa directa suya.

¿Dónde se almacenan los datos de las transacciones, y por qué importa eso?

La especificación técnica de la AdE exige que la infraestructura de fiscalización en la nube se ubique dentro de la UE (§11.6). Esto no se plantea como una opción con una alternativa compatible con el RGPD: almacenar datos fiscales italianos fuera de la UE está expresamente prohibido por la propia especificación, independientemente de cualquier salvaguarda de transferencia que un proveedor pudiera establecer de otro modo.

Dado que los registros de transacciones procesados con fines fiscales suelen incluir datos personales junto con datos fiscales, el almacenamiento en la UE también mantiene a la empresa fuera de las normas independientes del RGPD sobre transferencias internacionales de datos, que de otro modo exigirían mecanismos como las cláusulas contractuales tipo para cualquier dato personal trasladado fuera de la UE. fiskaly almacena los datos fiscales en infraestructura ubicada en la UE, cubierta por su certificación ISO 27001, lo que resuelve por defecto tanto el requisito de residencia de la AdE como la cuestión de transferencia del RGPD, sin necesidad de una justificación independiente para cada cliente.

¿Qué condiciones contractuales importan al evaluar a un proveedor de fiscalización en la nube?

La especificación de la AdE, no el contrato, es la que decide qué ocurre con los datos fiscales de un comercio al finalizar la relación. El Erogatore debe dar acceso completo a todos los datos almacenados y exportarlos en un formato estándar "con independencia de la forma contractual que rija el uso de la solución" (§9.7), archivarlos conforme al Decreto Ministerial del 17 de junio de 2014 (§9.8) y, al término de la relación, entregar un File Archivio con los registros, los documentos comerciales y un índice metadati.xml (§10.1–10.3). Nada de eso es negociable en un contrato, porque es una obligación normativa del Erogatore.

Lo que el contrato sí cubre es lo que la especificación deja abierto: la velocidad y el coste de la exportación, y quién gestiona la migración; un acuerdo de tratamiento de datos conforme al artículo 28 del RGPD que identifique las actividades de tratamiento concretas, los plazos de conservación y los subencargados; y un plazo de notificación de brechas expresado en horas, no dejado en "sin dilación indebida".

Próximos pasos

Pasar de hardware RT a un proveedor de fiscalización en la nube significa evaluar una relación de tratamiento de datos en sus propios términos, junto con un camino de certificación y homologación fiscal que la mayoría de las soluciones del mercado italiano aún no han completado. fiskaly SIGN IT funciona sobre infraestructura certificada ISO 27001 con datos fiscales almacenados en infraestructura de la UE, y el Trust Center de fiskaly documenta los controles de seguridad concretos detrás de esa certificación. Para el propio proceso de certificación y homologación, la guía de fiskaly sobre los requisitos de certificación de la fiscalización en la nube en Italia explica con más detalle la separación entre Produttore y Erogatore y los pasos de certificación, y el panorama fiscal en Italia en 2026 recoge en qué punto se encuentra hoy el cambio más amplio de hardware a nube. Una vez recogidos los datos fiscales, fiskaly SAFE se encarga del archivo, listo para auditoría, de esos mismos datos.

Última actualización: septiembre de 2026. Este artículo es una orientación general, no asesoramiento legal. Confirme los requisitos vigentes ante la Agenzia delle Entrate, el Garante per la protezione dei dati personali y el propio RGPD antes de elegir un proveedor de fiscalización en la nube.