Evolución y continuidad de Business Central

Actualizar Business Central sin frenar el negocio ni arrastrar problemas

SaaS, on-premise, nuevas versiones, extensiones, integraciones, NAV y migración a la nube: cada escenario necesita una ruta distinta.

Actualizar Business Central no debería empezar descargando una versión ni reservando una ventana técnica. Debe empezar identificando qué necesita el negocio, qué riesgos existen, qué dependencias pueden romperse y si la empresa debe actualizar, migrar, reimplantar o rediseñar parte de su solución.

Evaluación inicial de versión, extensiones, personalizaciones, integraciones, infraestructura y continuidad operativa.

Business Central online
Preparar cada release

On-premise
Actualizar plataforma y aplicación

NAV y versiones antiguas
Definir pasos intermedios

Decisión empresarial
Actualizar, migrar o reimplantar

Respuesta directa

Actualizar Business Central no es una única operación

La misma búsqueda puede esconder situaciones completamente distintas. Una empresa en Business Central online puede necesitar preparar una nueva release y validar extensiones. Otra puede trabajar con Business Central on-premise y llevar varias versiones de retraso. Otra puede venir de NAV, mantener código C/AL y necesitar pasos intermedios antes de llegar a la versión actual o a SaaS.

También existe un cuarto caso: el sistema está técnicamente actualizado, pero los procesos, informes, integraciones y personalizaciones se han quedado atrás. En ese escenario, instalar la última versión no resuelve el problema. Solo actualiza la base tecnológica de una solución que sigue sin responder al negocio.

La ruta correcta depende de versión de origen, modelo de despliegue, extensiones, datos, arquitectura, criticidad operativa, soporte disponible y objetivo futuro. Empezar por el diagnóstico evita convertir una actualización en una cadena de incidencias.

Actualizar

Mantener el modelo actual, llevar plataforma y aplicación a una versión posterior y adaptar extensiones e integraciones.

Migrar

Cambiar de versión, arquitectura o modelo de despliegue, trasladando datos y reconstruyendo las capacidades necesarias.

Reimplantar

Rediseñar configuración, procesos y datos cuando conservar la estructura anterior cuesta más que construir un modelo limpio.

Seis escenarios distintos

Antes de hablar de calendario, identifica qué significa “actualizar” en tu empresa

La decisión cambia por completo según el punto de partida. Mezclar escenarios genera presupuestos poco comparables, expectativas incorrectas y proyectos que empiezan sin saber qué se está intentando conseguir.

Escenario 1

Business Central online ante una nueva release

La plataforma se mantiene dentro del servicio, pero la empresa debe probar extensiones, integraciones, procesos críticos y nuevas funcionalidades antes de la ventana de producción.

Objetivo: convertir cada actualización en una rutina controlada, no en una sorpresa semestral.

Escenario 2

Business Central on-premise con una versión reciente

La empresa necesita aplicar actualizaciones acumulativas o avanzar a una nueva versión manteniendo infraestructura, extensiones y modelo operativo.

Objetivo: actualizar sin romper compatibilidades y sin dejar el entorno fuera de la política de soporte.

Escenario 3

Business Central on-premise con varias versiones de retraso

La ruta puede exigir pasos intermedios, conversión de extensiones, revisión de SQL, plataforma, aplicaciones y componentes asociados.

Objetivo: definir una secuencia soportada y comparar su coste con una migración a SaaS.

Escenario 4

Dynamics NAV o Navision

Las versiones antiguas pueden necesitar un salto previo a Business Central on-premise antes de migrar online. Además, las personalizaciones C/AL deben transformarse o replantearse.

Objetivo: no confundir actualización técnica con modernización del ERP.

Escenario 5

Paso de on-premise a Business Central SaaS

No basta con mover datos. Hay que validar extensiones, identidades, integraciones, aplicaciones, histórico, seguridad y operación futura.

Objetivo: reducir deuda técnica y preparar el ERP para Microsoft 365, Power Platform, Copilot e IA.

Escenario 6

Sistema actualizado, procesos agotados

La versión es reciente, pero persisten Excel, tareas manuales, informes lentos, integraciones frágiles y personalizaciones que dificultan cada cambio.

Objetivo: combinar actualización con una hoja de ruta funcional y de automatización.

Business Central online

En SaaS, Microsoft actualiza el servicio. La empresa debe asegurar que el negocio está preparado.

Business Central online cuenta con dos grandes ciclos de actualización al año, iniciados en abril y octubre, además de actualizaciones menores en otros meses. El servicio no está pensado para permanecer indefinidamente en una versión antigua. La ventaja es que la empresa evita grandes proyectos técnicos de plataforma; la exigencia es mantener extensiones, integraciones y procesos preparados para evolucionar.

El centro de administración permite gestionar ventanas y fechas, recibir notificaciones y trabajar con entornos sandbox. Microsoft recomienda probar las aplicaciones y procesos en un entorno que ejecute la nueva versión antes de desplegarla en producción. Esto convierte la actualización en un proceso de validación continua.

La organización que espera a la última semana para comprobar extensiones, informes o integraciones está usando mal el modelo SaaS. La actualización debe tener propietarios, calendario, criterios de prueba y evidencias de aceptación.

Actualizar sin improvisar

El objetivo no es impedir que cambie la versión. Es conseguir que cada cambio llegue probado, documentado y con una respuesta clara ante cualquier incidencia.

Entorno de prueba

Crear o actualizar una sandbox con la nueva versión y datos suficientemente representativos para validar los procesos críticos.

Extensiones

Comprobar compatibilidad, dependencias, permisos, cambios de API, disponibilidad de nuevas versiones y soporte del fabricante.

Integraciones

Probar intercambios de datos, colas, APIs, conectores, automatizaciones, interfaces bancarias y sistemas externos.

Procesos críticos

Validar cierres, facturación, compras, cobros, pagos, inventario, fabricación, proyectos y obligaciones legales.

Usuarios y cambio

Comunicar novedades relevantes, preparar instrucciones y evitar que los usuarios descubran cambios durante una operación crítica.

Plan de respuesta

Definir responsables, evidencias, incidencias bloqueantes, alternativas operativas y comunicación durante el despliegue.

Pruebas que aportan valor

Abrir pantallas no es probar una actualización

La prueba debe reproducir operaciones completas y excepciones reales. Una extensión puede instalarse correctamente y fallar cuando interviene una dimensión, un lote, una devolución, una divisa, una aprobación o una integración. Los casos deben diseñarse alrededor del riesgo empresarial.

Finanzas

Registro, impuestos, dimensiones, bancos, conciliación, pagos, cobros, diferimientos, activos, consolidación y cierre.

Ventas y compras

Pedidos, precios, descuentos, aprobaciones, reservas, entregas, devoluciones, facturas, abonos y documentos electrónicos.

Inventario y logística

Recepciones, ubicaciones, lotes, series, transferencias, picking, inventarios, valoración y conexión con almacenes externos.

Fabricación y proyectos

Listas, rutas, consumos, producción, capacidad, costes, partes, recursos, planificación, avances y facturación.

Integraciones

CRM, comercio electrónico, nómina, bancos, EDI, SGA, MES, portales, Power Platform, Power BI y aplicaciones sectoriales.

Excepciones

Errores de datos, documentos bloqueados, permisos, reintentos, anulaciones, caídas de servicios y operaciones fuera del flujo ideal.

Business Central on-premise

En local, actualizar significa intervenir sobre más capas y asumir más responsabilidad

Microsoft mantiene Business Central on-premise bajo sus políticas de ciclo de vida, pero el soporte exige conservar el software dentro de las condiciones aplicables. La empresa controla el calendario y la instalación, aunque también debe coordinar plataforma, aplicación, base de datos, extensiones, infraestructura, seguridad y pruebas.

Capa Qué debe revisarse Riesgo si se ignora
Ruta de versiones Compatibilidad entre origen y destino, actualizaciones intermedias, versión de aplicación y versión de plataforma. Elegir un salto no soportado o descubrir tarde que hacen falta varias etapas.
Base de datos y SQL Versiones compatibles, rendimiento, copias, espacio, conversión y recuperación. Paradas prolongadas, errores de conversión, degradación o imposibilidad de volver atrás.
Infraestructura Servidores, sistema operativo, almacenamiento, redes, certificados, servicios y capacidad. Actualizar el ERP sobre una base tecnológica que ya está cerca de quedar obsoleta.
Extensiones y código Compatibilidad, compilación, eventos, APIs, permisos, dependencias y versión de cada aplicación. Bloqueo del proyecto, pérdida de funcionalidad o creación de una nueva capa de deuda.
Integraciones Servicios, interfaces, endpoints, autenticación, formatos, colas, ficheros y tareas programadas. Un ERP disponible que no puede recibir pedidos, emitir pagos o alimentar sistemas externos.
Datos Calidad, volumen, campos personalizados, tablas heredadas, histórico y tiempos de conversión. Ventanas de parada irreales, errores de negocio y arranque con información inconsistente.
Operación Plan de despliegue, aceptación, responsables, soporte, comunicación, contingencia y vuelta atrás. Improvisación durante el arranque y decisiones críticas tomadas bajo presión.

Una actualización acumulativa no es lo mismo que un salto de versión

Aplicar correcciones dentro de una versión puede ser una intervención acotada. Saltar entre versiones mayores puede afectar a plataforma, código, extensiones, base de datos, compatibilidad y modelo funcional. El alcance debe definirse con precisión antes de comprometer plazo y presupuesto.

Decisión de arquitectura

Actualizar la versión actual, migrar a SaaS o reimplantar: tres caminos con costes distintos

La actualización conserva buena parte del modelo existente. Suele encajar cuando procesos, datos, personalizaciones e integraciones están razonablemente controlados y la organización necesita avanzar de versión sin rediseñar la solución.

La migración a SaaS añade una decisión de arquitectura. Puede reducir infraestructura y facilitar futuras actualizaciones, integración e innovación, pero obliga a revisar extensiones, conectividad, identidades, aplicaciones y dependencia de componentes locales.

La reimplantación tiene sentido cuando el ERP se ha convertido en una acumulación de código, datos, procesos y excepciones difíciles de sostener. Es más exigente desde el punto de vista organizativo, pero puede ser más rentable que reconstruir cada personalización antigua.

Actualizar

Encaja cuando: la solución funciona, la deuda está controlada, la ruta es soportada y el objetivo principal es mantener soporte, seguridad y acceso a mejoras.

Migrar a SaaS

Encaja cuando: la empresa quiere reducir infraestructura, actualizar de forma continua y conectar el ERP con el ecosistema Microsoft.

Reimplantar

Encaja cuando: conservar el diseño anterior exige más esfuerzo que configurar un modelo limpio y la organización está preparada para revisar procesos y datos.

Cuándo una actualización deja de ser la opción prudente

Varias versiones de retraso y múltiples pasos intermedios.
Código heredado sin documentación ni propietario claro.
Procesos paralelos sostenidos por Excel, Access o tareas manuales.
Datos duplicados, inconsistentes o imposibles de gobernar.
Infraestructura que también necesita una renovación relevante.
Necesidad de automatización, analítica e IA que el modelo actual dificulta.

No copies el problema

Una versión nueva no arregla automáticamente procesos viejos

Actualizar puede ser una oportunidad para retirar personalizaciones, mejorar datos, ordenar permisos, simplificar integraciones y eliminar tareas manuales. También puede convertirse en una mudanza costosa si el proyecto se limita a reproducir cada decisión histórica.

La pregunta correcta no es “¿podemos llevarlo?”. Es “¿merece la pena llevarlo y qué debería sustituirlo?”.

Evaluar mi actualización

Dependencias críticas

El mayor riesgo no suele estar en Business Central. Está en todo lo que se ha construido alrededor.

Un ERP puede actualizarse correctamente y dejar de operar como sistema empresarial porque una extensión, interfaz, fichero, servicio o automatización ya no responde como antes. Por eso el inventario de dependencias debe realizarse antes de estimar el proyecto.

01

Extensiones propias

Revisar código, eventos, APIs, tablas, permisos, dependencias, pruebas existentes, documentación y capacidad del equipo para mantenerlas.

02

Aplicaciones de terceros

Confirmar versiones disponibles, roadmap, licencias, compatibilidad con el destino, soporte del fabricante y posibles cambios funcionales.

03

Integraciones

Identificar endpoints, autenticación, formatos, propietarios, frecuencia, volumen, errores, reintentos y respuesta ante indisponibilidad.

04

Informes y analítica

Comprobar informes personalizados, Excel conectados, Power BI, consultas, vistas, réplicas, data warehouses y procesos de cierre.

05

Automatizaciones

Revisar tareas programadas, flujos de Power Automate, colas, servicios, robots, procesos nocturnos y dependencias de cuentas técnicas.

06

Conocimiento

Saber quién entiende cada componente, qué documentación existe y qué ocurriría si la persona o proveedor clave no estuviera disponible.

Coste y alcance

Qué determina el coste de actualizar Business Central

No existe una tarifa universal porque la actualización puede ir desde validar una nueva release online hasta transformar una solución on-premise con varias versiones de retraso, código heredado e integraciones críticas.

La estimación debe separar diagnóstico, preparación técnica, adaptación de extensiones, migración de datos, pruebas, formación, despliegue y soporte posterior. También debe dejar claro qué asume el cliente, qué depende de terceros y qué riesgos pueden modificar el alcance.

Una oferta económica sin inventario de personalizaciones e integraciones no es una estimación precisa. Es una hipótesis comercial que probablemente cambiará cuando aparezca la complejidad real.

Factores principales
Versión de origen y versión de destino
Número de pasos intermedios
Volumen y calidad de datos
Extensiones y personalizaciones
Integraciones y sistemas externos
Infraestructura y arquitectura
Sociedades, países y localizaciones
Procesos críticos y esfuerzo de prueba
Disponibilidad de usuarios clave
Ventana de parada y soporte al arranque

Riesgo de alcance

Dependencias no documentadas, desarrollos sin propietario, integraciones ocultas y requisitos que aparecen durante las pruebas.

Riesgo de calendario

Usuarios clave no disponibles, ventanas irreales, retrasos de terceros o falta de tiempo para repetir pruebas completas.

Riesgo operativo

Procesos críticos que no se validan, contingencias inexistentes o arranque sin capacidad suficiente de soporte.

Riesgo de futuro

Invertir en una actualización que mantiene la empresa atrapada en la misma arquitectura y obliga a repetir el proyecto poco después.

Ruta recomendada

Cómo actualizar Business Central con control

La secuencia debe proteger la operación y, al mismo tiempo, impedir que el proyecto se limite a conservar deuda técnica. Cada fase debe producir decisiones, evidencias y responsables claros.

01

Diagnóstico

Versión, despliegue, infraestructura, extensiones, datos, integraciones, procesos, soporte, incidencias y objetivos del negocio.

02

Elección de ruta

Comparar actualización, migración a SaaS y reimplantación según coste, riesgo, tiempo y arquitectura futura.

03

Inventario de dependencias

Clasificar aplicaciones, código, interfaces, informes, tareas, cuentas técnicas y responsables.

04

Preparación

Adaptar extensiones, actualizar aplicaciones, limpiar datos, preparar infraestructura, crear entornos y definir casos de prueba.

05

Pruebas integrales

Validar procesos completos, excepciones, seguridad, rendimiento, informes e integraciones con usuarios responsables.

06

Ensayo y transición

Medir tiempos, documentar pasos, preparar contingencia, formar usuarios y confirmar criterios de aceptación.

07

Despliegue

Ejecutar la actualización con responsables, seguimiento, comunicación, soporte reforzado y control de incidencias.

08

Estabilización y evolución

Cerrar incidencias, documentar, medir resultados y activar la hoja de ruta funcional, de automatización, datos e IA.

Señales de alerta

Cuándo no conviene aplazar más la actualización

No toda versión antigua exige una intervención inmediata, pero algunas señales indican que la empresa está acumulando un riesgo que ya afecta a continuidad, coste o capacidad de evolución.

El problema más serio no es estar una versión por detrás. Es no saber cuánto costaría actualizar, depender de un entorno sin soporte suficiente y descubrir la complejidad cuando aparece una necesidad urgente.

La versión o sus componentes están fuera de soporte o cerca de estarlo.
Cada cambio requiere tocar código que pocas personas entienden.
Las integraciones fallan con frecuencia y no existe monitorización suficiente.
La infraestructura necesita renovación y el ERP condiciona toda la decisión.
El partner actual responde incidencias, pero no presenta una hoja de ruta.
La empresa no puede integrar nuevas herramientas sin construir soluciones frágiles.
Los usuarios mantienen procesos críticos fuera del ERP porque el sistema no evoluciona.

Cuando el problema es el servicio

Actualizar también puede ser el momento de cambiar de partner

Algunas empresas no están bloqueadas por Business Central, sino por una relación de servicio que se ha vuelto reactiva. Falta documentación, las mejoras se eternizan, las incidencias no se convierten en aprendizaje y nadie plantea cómo preparar la siguiente versión.

Un cambio de partner no debe comenzar tocando el sistema. Debe comenzar revisando accesos, contratos, licencias, documentación, desarrollos, integraciones, incidencias, entornos y conocimiento. La actualización puede ser una oportunidad para ordenar esa transición, pero no conviene mezclar ambos movimientos sin un plan de continuidad.

Visibilidad

Saber qué existe, quién lo controla, qué documentación falta y qué riesgos están abiertos.

Continuidad

Asegurar soporte durante el traspaso, la actualización, las pruebas y la estabilización.

Evolución

Pasar de resolver incidencias a gestionar versiones, mejoras, automatización y adopción.

Errores frecuentes

Ocho formas de convertir una actualización en un problema

Empezar sin inventario

Las dependencias aparecen durante el proyecto y transforman una estimación controlada en una negociación permanente.

Probar solo el estándar

Los procesos básicos funcionan, pero fallan extensiones, informes, interfaces o excepciones que sostienen la operación real.

No reservar usuarios clave

La validación se retrasa o la realiza alguien que no puede confirmar si el resultado es correcto para el negocio.

Migrar todo el histórico

Aumenta tiempo, complejidad y coste sin demostrar que toda la información deba seguir dentro del ERP operativo.

Conservar cada personalización

Se paga por reconstruir limitaciones antiguas en lugar de aprovechar estándar, extensiones modernas o Power Platform.

No ensayar la parada

La ventana se calcula por intuición y el negocio descubre demasiado tarde cuánto dura la conversión real.

Olvidar la adopción

Los usuarios reciben una versión nueva, pero no entienden cambios, mejoras ni nuevos procedimientos.

No definir el siguiente paso

La empresa invierte en actualizar y vuelve inmediatamente al mantenimiento reactivo sin una hoja de ruta de evolución.

Rutas relacionadas

Conecta la actualización con la decisión empresarial completa

La versión es solo una pieza. El modelo de despliegue, la migración desde NAV, el coste del proyecto, el soporte y la estrategia de automatización determinan el valor real de la actualización.

Página principal
Dynamics 365 Business Central

Capacidades, implantación, migración, comparativas, integraciones y evolución del ERP Microsoft.

Explorar Business Central

Modelo de despliegue
Business Central SaaS vs On-Premise

Coste total, seguridad, control, actualizaciones, integraciones, Copilot e IA.

Comparar modelos

Migración
Cuánto cuesta migrar de NAV a Business Central

Escenarios de inversión según personalización, datos, integraciones, usuarios y ambición.

Ver escenarios

Evolución
Power Platform conectada al ERP

Aplicaciones, flujos, datos y automatización alrededor de Business Central con gobierno.

Ver automatización

Inteligencia artificial
ERP + IA con Microsoft

Cómo preparar ERP, datos, procesos e integraciones para Copilot y agentes inteligentes.

Explorar ERP + IA

Capacidad de servicio
Ayesa como partner Microsoft

Designaciones, especializaciones, certificaciones y capacidad para proyectos Microsoft empresariales.

Conocer Ayesa

Preguntas frecuentes

Dudas habituales al actualizar Business Central

¿Cada cuánto se actualiza Business Central online?

Microsoft organiza dos grandes ciclos de actualización al año, iniciados en abril y octubre, y publica actualizaciones menores en otros meses. Los administradores pueden gestionar fechas y ventanas dentro de los periodos disponibles y preparar entornos sandbox para validar la nueva versión.

¿Se puede evitar una actualización de Business Central SaaS?

El servicio online está diseñado para mantenerse actualizado. Es posible gestionar la programación dentro de las opciones disponibles, pero no conservar indefinidamente una versión antigua. La estrategia correcta es probar con antelación y mantener extensiones e integraciones preparadas.

¿Qué hay que probar antes de actualizar?

Procesos críticos completos, extensiones, integraciones, informes, permisos, automatizaciones y excepciones. No basta con acceder al sistema o crear un documento sencillo. Las pruebas deben cubrir cierres, facturación, pagos, inventario, fabricación, proyectos y operaciones específicas de la empresa.

¿Cómo sé qué versión de Business Central tengo?

La información de versión puede consultarse desde el entorno y, en Business Central online, desde el centro de administración. Para definir una ruta correcta también conviene identificar versión de aplicación, plataforma, extensiones instaladas y modelo de despliegue.

¿Puedo actualizar directamente desde cualquier versión on-premise?

No siempre. Microsoft publica rutas de actualización y matrices de compatibilidad. Según la versión de origen, puede ser necesario pasar por versiones intermedias. La ruta debe confirmarse antes de estimar alcance, calendario y ventana de parada.

¿Se puede actualizar desde NAV a Business Central online?

Sí, pero las versiones antiguas de NAV no migran directamente a la nube. Microsoft indica que deben actualizarse primero a una versión compatible de Business Central on-premise. Además, las personalizaciones C/AL deben convertirse en extensiones AL o replantearse mediante una reimplantación.

¿Actualizar y migrar a SaaS es lo mismo?

No. Actualizar puede significar avanzar de versión manteniendo el modelo on-premise. Migrar a SaaS implica cambiar el modelo de despliegue y revisar identidades, extensiones, integraciones, datos, aplicaciones y operación dentro del servicio online.

¿Qué ocurre con las personalizaciones?

Deben inventariarse y clasificarse. Algunas se adaptan, otras se sustituyen con estándar o aplicaciones, otras pueden resolverse con Power Platform y otras deberían retirarse. Mantenerlas todas sin análisis suele aumentar coste y deuda técnica.

¿Cuánto dura una actualización de Business Central?

Depende de la versión, el modelo de despliegue, los pasos intermedios, el volumen de datos, las extensiones, las integraciones y la disponibilidad de usuarios para probar. Una release SaaS puede requerir una preparación recurrente; un salto de varias versiones on-premise puede convertirse en un proyecto de varios meses.

¿Cuánto cuesta actualizar Business Central?

El coste depende de la ruta, personalizaciones, datos, infraestructura, integraciones y pruebas. Para estimarlo hay que realizar un diagnóstico. Dar una cifra cerrada sin revisar estas variables suele generar desviaciones posteriores.

¿Cuándo conviene reimplantar en lugar de actualizar?

Cuando la solución acumula demasiadas personalizaciones, procesos obsoletos, datos inconsistentes, integraciones frágiles y conocimiento no documentado. La reimplantación permite construir un modelo más limpio, aunque exige mayor participación del negocio y gestión del cambio.

¿Puede Ayesa hacerse cargo si el partner actual no responde?

Sí. El primer paso debe ser revisar accesos, documentación, licencias, desarrollos, integraciones, incidencias, entornos y responsabilidades. Después se puede plantear una transición ordenada, la actualización y una hoja de ruta de evolución sin comprometer la continuidad.

Documentación oficial consultada

Criterios contrastados con Microsoft Learn

La página se apoya en la documentación oficial sobre ciclos de actualización, gestión desde el centro de administración, política de soporte on-premise, rutas de actualización y migración desde NAV o Business Central local.

Siguiente paso

Revisa tu versión antes de que la actualización se convierta en una urgencia

Podemos analizar tu entorno y definir si conviene actualizar, migrar a Business Central SaaS, reimplantar o combinar la intervención técnica con una hoja de ruta funcional.

Versión actual y modelo de despliegue
Usuarios, sociedades y procesos críticos
Personalizaciones, extensiones e integraciones
Infraestructura, soporte y documentación
Fecha objetivo y principal preocupación

Cuéntanos tu situación

Solicita una revisión inicial

    He leído y acepto la Política de Privacidad de Ayesa.

    Información respecto al tratamiento de los datos solicitados, de acuerdo con el RGPD 2016/679 y la LOPDGDD 3/2018: el responsable es Ayesa; la finalidad es la recogida y tratamiento de los datos personales que solicitamos para atender tu consulta, enviarte nuestras publicaciones, newsletters, promociones de productos y/o servicios, y recursos exclusivos; la legitimación se establece mediante el consentimiento expreso; no se cederán datos a terceros, salvo obligación legal; en cualquier momento puedes ejercer tus derechos de acceso, rectificación, supresión, portabilidad, limitación u oposición al tratamiento de tus datos, así como retirar el consentimiento prestado o formular reclamaciones ante la Autoridad de Control, enviando la solicitud por correo electrónico a: lopd@ayesa.com; puedes consultar la información adicional y detallada sobre Privacidad y Protección de Datos de Carácter Personal en la Política de Privacidad de Ayesa.