Política de Soporte de Anjana Data

1. PROPÓSITO, ALCANCE Y RELACIÓN CON EL MSA/PEDIDO

1.1 Propósito. Esta Política de Soporte (la “Política”) define, de forma operativa y contractualmente coherente, los servicios de soporte prestados por Anjana Data al Cliente para (i) la Anjana Data Platform (software) en sus Versiones Soportadas, (ii) Incidentes de disponibilidad/accesibilidad de los Servicios SaaS (si contratados) y (iii) Consultas (how-to/dudas) dentro del perímetro definido.

1.2 Incorporación por referencia. Esta Política podrá incorporarse por referencia al MSA (según se define en la Sección 2) y/o al Pedido. En caso de conflicto entre (i) el MSA y/o el Pedido y (ii) esta Política, prevalecerán el MSA y/o el Pedido en lo que resulte aplicable.

1.3 Separación de dominios. Esta Política diferencia y regula separadamente los siguientes dominios, que no se confunden entre sí:

• (A) Soporte técnico de producto (software) sobre Versiones Soportadas;

• (B) Soporte a Incidentes SaaS (solo indisponibilidad/inaccesibilidad del servicio SaaS contratado);

• (C) Atención de Consultas (how-to/dudas) dentro de perímetro, excluyendo Servicios Profesionales.

2. DEFINICIONES

A los efectos de esta Política, se entenderá por:

2.1 “Anjana Data”: la entidad del grupo Anjana Data indicada en el MSA/Pedido.

2.2 “Cliente”: la entidad contratante indicada en el MSA/Pedido.

2.3 “MSA” (Master Services Agreement / Acuerdo Marco de Servicios): el acuerdo marco de servicios suscrito entre Anjana Data y el Cliente que regula, entre otros, las condiciones generales aplicables a la prestación de los servicios y/o licencias objeto del Pedido, incluyendo, en su caso, limitaciones de responsabilidad, exclusiones, confidencialidad y demás términos generales.

2.4 “Pedido”: el documento de orden de compra/Order Form o anexo comercial suscrito entre las Partes que identifica, entre otros, el alcance contratado, la zona horaria aplicable, el tipo de despliegue (on-premise/privado/SaaS), y cualesquiera condiciones específicas.

2.5 “Documentación”: documentación técnica/funcional publicada por Anjana Data (incluyendo, en su caso, portal/documentación online) aplicable a la Anjana Data Platform y/o Servicios SaaS.

2.6 “Servicios SaaS”: el servicio SaaS de Anjana Data contratado por el Cliente en el Pedido, cuya obligación de soporte a incidencias, bajo este dominio, se limita a la disponibilidad/accesibilidad del servicio.

2.7 “Soporte”: la asistencia prestada por Anjana Data conforme a esta Política, incluyendo (según dominio) análisis, diagnóstico, recomendaciones, mitigaciones (“workarounds”), actualizaciones, correcciones de errores (“bug fixes”) y parches de seguridad; todo ello sujeto a exclusiones y requisitos.

2.8 “Incidencia”: para el Dominio 2 (SaaS), un evento de indisponibilidad o inaccesibilidad del Servicio SaaS contratado. Para el Dominio 1 (producto), un error o comportamiento anómalo del software en una Versión Soportada que afecte su funcionamiento conforme a Documentación.

2.9 “Severidad”: nivel asignado al ticket conforme a los criterios de esta Política.

2.10 “TOR” (Time of Response / Tiempo Objetivo de Respuesta): tiempo objetivo máximo para el primer acuse de recibo y respuesta inicial por parte de Anjana Data desde el registro del ticket en el Portal, dentro de horarios aplicables. El TOR no constituye compromiso de resolución ni de entrega de correcciones.

2.11 “TTR” (Time To Restore / Tiempo Objetivo de Restauración): para Dominio 2 (SaaS), objetivo de restauración del servicio a un estado accesible/disponible. El TTR es un objetivo operativo, no una garantía absoluta, y está sujeto a exclusiones, dependencias y causas fuera de control razonable.

2.12 “Partner Integrador”: tercero autorizado por el Cliente (y aceptado por Anjana Data cuando aplique) para implementar/operar/integrar la Anjana Data Platform y actuar como interlocutor técnico.

2.13 “Versión”, “Parche”, “GA”, “Latest Release”, “Ventana de Soporte”, “EOS”, “EOL”, “Versión Soportada”: definidos en la Sección 9.

3. PRINCIPIOS GENERALES DEL SOPORTE

3.1 Obligación de medios. Anjana Data prestará Soporte con diligencia razonable y conforme a esta Política. Salvo por el TTR objetivo del Dominio 2, esta Política no establece compromisos de resolución ni plazos de entrega de correcciones.

3.2 Respuesta vs. workaround vs. corrección.

• (i) Respuesta: comunicación inicial y orientación de diagnóstico;

• (ii) Workaround: mitigación razonable para reducir impacto, cuando sea viable;

• (iii) Corrección: entrega de un fix mediante (a) nueva Versión, (b) kit de instalación actualizado y/o (c) Parche, según la Sección 9.

3.3 Condición de versionado. El Soporte pleno se presta sobre Versiones Soportadas. Si el Cliente opera una versión en EOS/EOL (End Of Support/End Of Life, ver Sección 9.2) o fuera de Ventana de Soporte, Anjana Data podrá exigir actualización como condición previa para continuar el Soporte con alcance completo.

3.4 Separación de Servicios Profesionales. Actividades de diseño/arquitectura, implementación, configuración avanzada, validación funcional, optimización, migraciones, desarrollo a medida, formación o gestión de cambio se consideran Servicios Profesionales y quedan excluidas del Dominio 3 salvo pacto expreso en el Pedido.

4. CANALES, REGISTRO DE TICKETS Y REQUISITOS DE INFORMACIÓN

4.1 Canal único (Portal). El Cliente registrará tickets exclusivamente mediante el Portal de Soporte:
https://support.portal.anjanadata.com/servicedesk/customer/portals

4.2 Tipos de ticket obligatorios. El Cliente seleccionará el tipo correspondiente:

• “Soporte técnico” (Dominio 1)

• “Incidente” (Dominio 2 – SaaS disponibilidad/accesibilidad)

• “Consulta” (Dominio 3)

4.3 Requisitos mínimos de información. El Cliente (o Partner Integrador) aportará información razonablemente necesaria, incluyendo, cuando aplique:

• descripción del impacto y alcance (usuarios/entornos afectados);

• hora de inicio y estado actual;

• pasos para reproducir (si aplica);

• evidencias y logs relevantes, mensajes de error, IDs de correlación;

• versión exacta, componentes/plugins, configuración relevante;

• cambios recientes (configuración, deploys, upgrades, red, IAM, certificados, etc.);

• en SaaS: entorno, URLs afectadas, trazas de conectividad.

4.4 Cooperación y acceso. Cuando sea necesario para diagnóstico, el Cliente facilitará acceso remoto razonable, permisos, ventanas de intervención y/o disponibilidad de personal técnico. La falta de cooperación o de información suficiente podrá (i) impedir reproducción, (ii) retrasar el diagnóstico, y (iii) afectar la capacidad de Anjana Data para proponer workaround o corrección.

4.5 Guía de uso del canal de soporte. La información operativa relativa al uso del Portal de Soporte (incluyendo, entre otros, creación y seguimiento de tickets, tipologías, campos requeridos, buenas prácticas de aportación de evidencias y comunicaciones) está disponible en la wiki pública de Anjana Data en:
https://wiki.anjanadata.com/es/portal-de-soporte/current

Nota: En caso de discrepancia entre dicha wiki y el MSA/Pedido o esta Política, prevalecerán el MSA/Pedido y esta Política.

5. CLASIFICACIÓN DE SEVERIDAD, RECLASIFICACIÓN Y SLAS (TOR/TTR)

5.1 Asignación inicial. El Cliente propondrá Severidad al abrir el ticket.

5.2 Derecho de reclasificación. Anjana Data podrá reclasificar la Severidad en cualquier momento, justificándolo en el ticket, en función del impacto real, reproducibilidad, alcance y existencia de workaround.

5.3 Cómputo. Los TOR se computan desde el registro del ticket en el Portal, durante el horario aplicable del dominio. El tiempo podrá quedar en pausa razonable (“waiting on Customer”) cuando la siguiente acción dependa de información, acceso o confirmación del Cliente.

5.4 Tabla de Severidades y SLAs (por tipo de soporte)

Nota contractual (TOR/TTR/RPO/RTO). (i) El TOR (Time of Response / Tiempo Objetivo de Respuesta) es el tiempo objetivo máximo para el primer acuse de recibo y respuesta inicial por parte de Anjana Data; los TOR no constituyen compromisos de resolución ni de entrega de correcciones. (ii) El TTR (Time To Restore / Tiempo Objetivo de Restauración) es un objetivo de restauración del servicio para Incidentes SaaS y no una garantía absoluta, estando sujeto a exclusiones y dependencias de terceros. (iii) Para el Dominio 2, el RPO (Recovery Point Objective / Objetivo de Punto de Recuperación) – 24 horas es el objetivo máximo de antigüedad de los datos restaurados respecto del momento del incidente (pérdida máxima de datos de hasta 24 horas), y el RTO (Recovery Time Objective / Objetivo de Tiempo de Recuperación) – 24 horas es el objetivo máximo para restaurar la plataforma a pleno funcionamiento cuando proceda una restauración; el RTO se computa desde la solicitud de restauración registrada por el Cliente a través del Portal (o canal contractualmente aceptado). (iv) TTR, RPO y RTO son objetivos operativos y no garantías absolutas; están sujetos a exclusiones, dependencias y requisitos de cooperación del Cliente. (v) RPO/RTO no sustituyen ni modifican el TOR ni el TTR, y aplican exclusivamente en escenarios en los que sea necesaria una restauración de datos/plataforma.

6. DOMINIO 1: SOPORTE TÉCNICO DE PRODUCTO (ANJANA DATA PLATFORM – VERSIONES SOPORTADAS)

6.1 Objeto. Soporte técnico sobre Versiones Soportadas de la Anjana Data Platform, incluyendo:

• actualizaciones de mantenimiento/mejoras de plataforma o kits de instalación;

• correcciones de bugs y parches de seguridad;

• asistencia técnica y diagnóstico conforme a TORs.

6.2 Horario. Laboral 9:00–18:00 en la zona horaria de la dirección del Cliente indicada en el Pedido, excluyendo fines de semana y festivos.

6.3 SLA. Exclusivamente TOR conforme a la tabla de la Sección 5.4. No se establecen SLAs de resolución.

6.4 Entregables posibles. Según el caso, Anjana Data podrá proporcionar:

• guía de diagnóstico y recomendaciones;

• workaround razonable;

• identificación de causa raíz (cuando sea viable);

• entrega de corrección según política de la Sección 9 (Latest Release/Parche/Versión futura).

6.5 Exclusiones mínimas (producto). Anjana Data no estará obligada a prestar Soporte en la medida en que el ticket derive de:

• uso o configuración no autorizada o incompatible con el Contrato o la Documentación;

• problemas generales de internet, fuerza mayor o factores fuera de control razonable;

• infraestructura del Cliente (equipos, software, red, IAM, certificados, etc.);

• sistemas o componentes de terceros, o actos u omisiones de terceros.

Efecto de exclusión. En caso de que Anjana Data determine razonablemente, tras comprobaciones mínimas, que el evento está comprendido en una exclusión, Anjana Data podrá limitar o cesar las actividades de Soporte relativas a la remediación de la causa excluida (incluyendo corrección, rollback, reconfiguración o reconstrucción), y comunicará dicha determinación y su justificación a través del ticket. Salvo lo previsto para Servicios SaaS en relación con operaciones que únicamente pueda ejecutar Anjana Data (incluidas, en su caso, intervenciones sobre persistencias) conforme a la Sección 11, la remediación será responsabilidad del Cliente o su Partner Integrador. Cualquier asistencia que exceda recomendaciones de alto nivel y requiera ejecución por Anjana Data se prestará, cuando proceda, como Servicios Profesionales o bajo el servicio específico aplicable, formalizado por escrito.

7. DOMINIO 2: SOPORTE A INCIDENTES SAAS (SOLO DISPONIBILIDAD/ACCESIBILIDAD)

7.1 Objeto limitado. Este dominio se limita exclusivamente a indisponibilidad o inaccesibilidad del Servicio SaaS contratado. No cubre: errores funcionales del software, configuraciones, integraciones, rendimiento por cargas del Cliente, ni incidencias atribuibles a dependencias externas del Cliente.

7.2 Horario. 24x7.

7.3 SLAs.

• TOR: 2 horas.

• TTR objetivo (Time To Restore): 8 horas.

7.4 Naturaleza del TTR. El TTR es un objetivo operativo sujeto a:

• necesidad de verificación del alcance del Incidente;

• dependencias de terceros (por ejemplo, proveedores cloud, DNS, proveedores de identidad del Cliente);

• cooperación y pruebas de restauración por el Cliente cuando sea requerido;

• exclusiones de la Sección 11.

7.5 Exclusiones (SaaS). Además de las exclusiones generales, se excluyen indisponibilidades causadas por:

• interrupciones de conectividad del Cliente o su ISP;

• configuración/operación del Cliente en contradicción con Documentación (incl. integraciones, políticas IAM);

• actos u omisiones de terceros ajenos a Anjana Data, incluidos proveedores del Cliente.

Efecto de exclusión. En caso de que Anjana Data determine razonablemente, tras comprobaciones mínimas, que el evento está comprendido en una exclusión, Anjana Data podrá limitar o cesar las actividades de Soporte relativas a la remediación de la causa excluida (incluyendo corrección, rollback, reconfiguración o reconstrucción), y comunicará dicha determinación y su justificación a través del ticket. Salvo lo previsto para Servicios SaaS en relación con operaciones que únicamente pueda ejecutar Anjana Data (incluidas, en su caso, intervenciones sobre persistencias) conforme a la Sección 11, la remediación será responsabilidad del Cliente o su Partner Integrador. Cualquier asistencia que exceda recomendaciones de alto nivel y requiera ejecución por Anjana Data se prestará, cuando proceda, como Servicios Profesionales o bajo el servicio específico aplicable, formalizado por escrito. Lo anterior se entiende sin perjuicio de los objetivos TOR/TTR/RPO/RTO aplicables al Dominio 2.

8. DOMINIO 3: ATENCIÓN DE CONSULTAS (HOW-TO / DUDAS)

8.1 Objeto. Atención de consultas dentro del perímetro:

• dudas funcionales (uso previsto conforme Documentación);

• configuración funcional;

• configuración técnica de plataforma o plugins en forma de orientación puntual;

• instalación en forma de orientación puntual.

8.2 Horario. Laboral 9:00–18:00 en la zona horaria de la dirección del Cliente indicada en el Pedido, excluyendo fines de semana y festivos.

8.3 SLA. TOR 24 horas. No se establecen SLAs de resolución.

8.4 Exclusiones (Consultas). Quedan fuera del perímetro y se consideran Servicios Profesionales:

• diseño/arquitectura e implementación end-to-end;

• configuración avanzada o a medida, optimizaciones complejas;

• validación funcional, QA del Cliente, pruebas de aceptación;

• asesoramiento operativo, gobierno organizativo, procesos y capacitación/formación.

9. VERSIONADO, LIFECYCLE Y POLÍTICA DE CORRECCIONES DE ERRORES (BUG FIXING)

9.1 Nomenclatura de versiones y definiciones

9.1.1 “Versión” o “Feature Release”. Formato YY.N (p. ej., 25.1, 25.2), donde:

• YY: dos últimos dígitos del año de publicación;

• N: ordinal de la versión publicada dentro de ese año (1, 2, 3…).

9.1.2 “Parche” o “Patch Release”. Formato “YY.N Parche P” (p. ej., 25.2 Parche 1), donde P es el ordinal del parche.

9.1.3 “GA (General Availability)”. Fecha a partir de la cual una Versión se considera liberada para uso general.

9.1.4 “Latest Release” (Versión más reciente). La última Versión YY.N publicada por Anjana Data y, si existe, su último Parche vigente.

9.1.5 “Ventana de Soporte”. Periodo de soporte estándar de 12 meses desde la fecha GA de una Versión. No obstante, en el supuesto excepcional de que, transcurridos dichos 12 meses, no exista una Versión posterior en estado GA/Disponible (esto es, la Versión siga siendo la Latest Release), dicha Versión continuará considerándose Supported hasta la fecha GA de la siguiente Versión que Anjana Data publique; a partir de esa fecha, comenzará a computarse el estado EOS de la Versión anterior conforme a la Sección 9.2.

9.1.6 “Versión dentro de Ventana de Soporte” y “Versión Soportada”.
Una Versión está “dentro de Ventana de Soporte” cuando no ha alcanzado EOS. Una “Versión Soportada” es una Versión dentro de Ventana de Soporte y operada conforme a Documentación y requisitos técnicos aplicables.
Aclaración expresa: “Versión dentro de Ventana de Soporte” no equivale necesariamente a ser “elegible para recibir parches” (ver 9.3 y 9.4).

9.2 Política de lifecycle de versiones (estados y ventana)

9.2.1 Ventana estándar. Cada Versión YY.N está soportada durante 12 meses desde su fecha GA, salvo el supuesto excepcional previsto en la definición de Ventana de Soporte (Sección 9.1.5), en cuyo caso la Versión permanecerá Supported hasta la GA de una Versión posterior.

9.2.2 Estados.

1. GA / Disponible: la versión queda liberada y entra en Ventana de Soporte.

2. Supported: durante la Ventana de Soporte, Anjana Data proporciona asistencia conforme a esta Política (incl. diagnóstico compatible y TOR), sujeto a exclusiones.

3. EOS (End of Support): Al finalizar los 12 meses desde GA o, si fuera posterior, en la fecha GA de una Versión posterior cuando aplique la extensión excepcional de la Sección 9.1.5. Desde EOS, Anjana Data podrá limitar o rechazar soporte para esa versión y exigir actualización a una versión en estado Supported.

4. EOL (End of Life) (si aplica): estado posterior donde Anjana Data no mantiene compatibilidad operativa/telemetría ni asistencia.

9.2.3 Publicación de fechas. Las fechas GA/EOS (y EOL si aplica) se publicarán en Documentación y/o Portal de Soporte y podrán actualizarse con preaviso razonable.

9.2.4 Ventana recomendada de actualización (recomendación). Se recomienda que el Cliente mantenga su despliegue en la Latest Release o, como máximo, en la Versión inmediatamente anterior publicada, a fin de reducir riesgo, facilitar soporte y maximizar recepción de mejoras y correcciones.

9.3 Principios generales de corrección de errores

9.3.1 Mitigaciones. Anjana Data podrá proporcionar workarounds a su discreción razonable cuando exista una mitigación viable.

9.3.2 Decisión de mecanismo. La decisión de corregir mediante Parche, incorporarlo a una Versión futura, o priorizarlo en roadmap corresponde a Anjana Data, de forma razonable, considerando impacto, riesgo y esfuerzo, sin perjuicio de la reclasificación de severidad (Sección 5.2).

9.3.3 Dependencias. La corrección puede depender de reproducibilidad, acceso a evidencias/logs, entorno del Cliente, dependencias de terceros y cumplimiento de requisitos de cooperación.

9.4 Política de entrega de correcciones (por severidad) — Regla “Latest Release”

9.4.1 Regla general (Sev 1/2/3). Las correcciones se entregan en la Latest Release y/o su último Parche vigente. Para beneficiarse de la corrección, el Cliente deberá actualizar a dicha Latest Release (o su parche vigente).

9.4.2 Errores de Severidad 1.

• Gestión prioritaria conforme a TOR, incluyendo diagnóstico y, cuando proceda, workaround.

• Entrega del fix: mediante Parche de la Latest Release o mediante una Latest Release posterior si fuese necesario.

• Entrega condicionada a la Latest Release: Anjana Data no está obligada a emitir un Parche para la versión específica del Cliente si dicha versión no es la Latest Release, incluso si se encuentra dentro de la Ventana de Soporte de 12 meses. Para beneficiarse de la corrección, el Cliente deberá actualizar a la Latest Release (y, en su caso, a su último Parche vigente), salvo acuerdo expreso por escrito en el Pedido.

9.4.3 Errores de Severidad 2.

• Normalmente se incorporan en una Versión futura planificada y/o en Parche de la Latest Release si el riesgo lo justifica, a discreción razonable de Anjana Data.

9.4.4 Errores de Severidad 3.

• Gestión por priorización en roadmap. La inclusión en roadmap no implica compromiso de fecha salvo pacto expreso en el Pedido.

9.5 Restricciones y consistencia contractual

9.5.1 Prohibición de ambigüedad. No se establecen compromisos del tipo “tan pronto como sea posible”. La entrega se rige por Latest Release/Parche/Versión futura/roadmap conforme a 9.4.

9.5.2 Cláusula expresa. “Los tiempos de respuesta (TOR) no constituyen compromisos de resolución ni de entrega de correcciones.”

9.5.3 Condición por EOS/EOL. Si el Cliente opera una versión en EOS/EOL o fuera de Ventana, Anjana Data podrá exigir actualización como condición de soporte pleno.

9.5.4 Responsabilidad de upgrades/actualizaciones y modalidades de mantenimiento de plataforma.
Salvo que el Pedido establezca expresamente lo contrario, la planificación, ejecución y validación de los upgrades/actualizaciones de la Anjana Data Platform en los entornos del Cliente serán responsabilidad del Cliente o de su Partner Integrador. No obstante, cuando el Cliente tenga contratado en el Pedido un servicio de Mantenimiento de Plataforma, la participación de Anjana Data en las actualizaciones se prestará conforme a la modalidad contratada:

a) Mantenimiento de Plataforma – Básico. Anjana Data proporcionará soporte remoto durante la actualización ejecutada por el Cliente o su Partner Integrador, consistente en orientación técnica razonable, verificación de prerequisitos y asistencia de troubleshooting durante ventanas acordadas; la ejecución material de la actualización y las acciones en los sistemas del Cliente permanecen a cargo del Cliente o su Partner Integrador.

b) Mantenimiento de Plataforma – Premium. Anjana Data realizará la ejecución de la actualización de los entornos del Cliente según el alcance, condiciones y ventanas definidos en el Pedido, incluyendo las tareas operativas necesarias para aplicar la Versión/Parche correspondiente; el Cliente deberá proporcionar accesos, permisos, colaboración y validaciones de negocio razonablemente necesarias.

c) Clientes sin Mantenimiento de Plataforma contratado. Para Clientes cuyos contratos/Pedidos anteriores no incluyan Mantenimiento de Plataforma, Anjana Data podrá, a su discreción razonable, prestar asistencia limitada de carácter best-effort y no recurrente, sin que ello constituya obligación de Anjana Data de ejecutar actualizaciones. En todo caso, desde 2025, el Mantenimiento de Plataforma es un requisito contractual para la prestación ordinaria de asistencia relacionada con upgrades/actualizaciones, debiendo contratarse en modalidad Básico o Premium según corresponda.

d) Exceso de alcance. Cualquier asistencia o actividad relacionada con upgrades/actualizaciones que (i) exceda lo previsto en la modalidad contratada, o (ii) requiera diseño, implementación, migraciones complejas, optimización, configuración avanzada o coordinación extendida, se considerará Servicios Profesionales y requerirá contratación adicional o acuerdo expreso por escrito en el Pedido.

Aclaración: Esta cláusula no altera la política de entrega de correcciones (Sección 9.4), incluyendo la regla de Latest Release, ni convierte los TOR en compromisos de resolución o entrega.

9.6 Exclusiones específicas para correcciones de errores

Además de las exclusiones generales:

• personalizaciones no estándar, integraciones no soportadas o modificaciones de código por terceros;

• incompatibilidades por dependencias/infraestructura fuera de las indicadas en Documentación;

• uso de funcionalidades preview/beta (si aplica): soporte en modalidad best-effort salvo pacto expreso en Pedido.

10. ESCALADO, COMUNICACIONES Y GESTIÓN DE ESTADO

10.1 Estados del ticket. Anjana Data comunicará el estado del ticket a través del Portal de Soporte. Sin perjuicio de ajustes menores operativos, Anjana Data podrá utilizar los siguientes estados estándar:

a) “L1”: primera revisión orientada a validación de comportamiento, verificación de configuración, recopilación inicial de evidencias y determinación preliminar de alcance/severidad.

b) “L2”: revisión avanzada, incluyendo análisis de logs, datos, conectividades, trazas y validación técnica detallada; podrá incluir solicitud de información adicional al Cliente.

c) “L3”: escalado a equipos de producto y/o DevOps, según corresponda (incluyendo análisis relativo al producto y/o a kits de instalación), para diagnóstico adicional, evaluación de workaround y/o determinación del mecanismo de corrección conforme a la Sección 9.

d) “Waiting for customer’s response”: el avance del ticket queda condicionado a verificaciones, pruebas, confirmaciones, acceso o información adicional por parte del Cliente o Partner Integrador.

e) “Waiting for business alignment”: el avance del ticket queda condicionado a coordinaciones o decisiones con el Cliente (por ejemplo, ventanas de cambio, aceptación de workaround, priorización de corrección, o confirmación de acciones necesarias para habilitar la entrega de la corrección conforme a la política de versionado).

Nota operativa/contractual: Los estados anteriores describen la fase de gestión del ticket y no implican, por sí mismos, compromiso de resolución ni de entrega de correcciones; los TOR y, en su caso, el TTR objetivo para Incidentes SaaS, se rigen exclusivamente por la Sección 5.

10.2 Escalado interno. Anjana Data podrá escalar internamente a equipos de producto, seguridad, IT o DevOps cuando proceda. El escalado interno no modifica los SLAs salvo pacto expreso.

10.3 Notificaciones. La notificación de avances y entregas de corrección se realizará por el ticket del Portal y/o por los canales contractualmente aceptados en el Pedido.

11. EXCLUSIONES, LIMITACIONES Y DEPENDENCIAS DE TERCEROS

11.1 Exclusiones generales. Anjana Data no tendrá obligación de prestar Soporte en la medida en que el evento derive de:

• uso no autorizado o contrario al Contrato/Documentación;

• fuerza mayor, problemas generales de internet u otros factores fuera de control razonable;

• infraestructura del Cliente (equipos, software, red, seguridad, IAM, certificados, etc.);

• sistemas de terceros o actos/omisiones de terceros.

• despliegues, instalaciones o actualizaciones ejecutadas de forma contraria al funcionamiento del instalador oficial, kits de instalación o procedimientos de instalación/upgrade publicados por Anjana Data en la Documentación, incluyendo (sin limitación) modificaciones no autorizadas del instalador, automatizaciones/scripts no soportados que alteren los pasos prescritos, o desviaciones materiales de prerequisitos y configuraciones requeridas; en tales casos, Anjana Data podrá denegar o limitar el Soporte hasta que el Cliente regularice el despliegue conforme a los procedimientos oficiales o, cuando corresponda, mediante Servicios Profesionales.

11.2 Limitación por dependencias. Cuando el diagnóstico o restauración dependa de terceros (incluidos proveedores cloud, servicios de identidad, integraciones del Cliente), los objetivos (incl. TTR) se interpretarán de acuerdo con la capacidad razonable de coordinación y con la información disponible.

11.3 Verificación mínima previa y efectos de una exclusión.
Antes de aplicar una exclusión de soporte establecida en esta Política, Anjana Data realizará comprobaciones razonables de primer nivel para determinar si, de forma fundada, la causa probable del evento o del impacto reportado se encuentra comprendida en una o varias exclusiones (por ejemplo, infraestructura del Cliente, sistemas de terceros, despliegue contrario al instalador oficial, o uso/configuración contraria a Documentación/Contrato).
Una vez determinada razonablemente la aplicabilidad de una exclusión, Anjana Data podrá: (i) limitar o cesar las actividades de Soporte relacionadas con corrección, rollback, remediación o cambios necesarios para resolver la causa excluida; y (ii) comunicar al Cliente, a través del ticket, la exclusión aplicada y la justificación operativa.
Las acciones de remediación, corrección de configuración, rollback, reconstrucción del entorno, cambios en infraestructura o en sistemas de terceros serán responsabilidad del Cliente o su Partner Integrador.

11.4 Intervenciones de remediación y operaciones sobre persistencias. Cuando la remediación requiera acciones operativas (incluyendo corrección, rollback, reconfiguración, reconstrucción de entornos o cambios en infraestructura), dichas acciones serán responsabilidad del Cliente o su Partner Integrador, salvo en el caso de Servicios SaaS, en los que determinadas operaciones (incluyendo intervenciones sobre bases de datos, almacenamiento o cualesquiera persistencias gestionadas por Anjana Data) solo podrán ser ejecutadas por Anjana Data.
En tales supuestos, (i) Anjana Data evaluará si la remediación puede realizarse mediante procedimientos estándar (p. ej., actualización a Latest Release, restauración conforme a RPO/RTO, o mecanismos automatizados soportados), y (ii) si, de forma excepcional, fuese necesaria una intervención manual sobre persistencias, dicha intervención: (a) no forma parte del Soporte estándar; (b) se realizará únicamente bajo un servicio específico y/o Servicios Profesionales formalizados por escrito (incluyendo alcance, prerrequisitos, aprobaciones y ventana de ejecución); y (c) quedará sujeta a criterios de elegibilidad y salvaguardas técnicas razonables definidas por Anjana Data para minimizar el riesgo de corrupción de datos.
Queda expresamente excluido del Soporte cualquier incidente, degradación o corrupción de datos derivada de intervenciones manuales sobre persistencias realizadas por el Cliente, el Partner Integrador o terceros sin autorización previa y por escrito de Anjana Data o fuera de los procedimientos soportados; en tales casos, Anjana Data podrá suspender o limitar el Soporte del entorno afectado hasta su regularización.

12. REQUISITOS DEL CLIENTE Y DEL PARTNER INTEGRADOR

12.1 Puntos de contacto. El Cliente designará puntos de contacto técnicos y operativos con capacidad de:

• aportar evidencias y aprobar acciones de mitigación;

• coordinar pruebas y validación de restauración;

• ejecutar upgrades cuando aplique.

12.2 Entornos y reproducibilidad. El Cliente mantendrá entornos y configuraciones de forma que permitan reproducibilidad razonable, conforme a Documentación.

12.3 Seguridad y acceso. Cuando se requiera acceso, el Cliente lo facilitará de forma segura y conforme a sus políticas, incluyendo ventanas y permisos mínimos necesarios.

13. RESERVA DE DERECHOS Y CAMBIOS DE LA POLÍTICA

13.1 Actualizaciones de la Política. Anjana Data podrá modificar esta Política con preaviso razonable, mediante publicación en el Portal de Soporte y/o notificación al contacto contractual designado.

13.2 Aplicabilidad temporal. Salvo que el MSA/Pedido disponga lo contrario, la versión actualizada aplicará a tickets registrados a partir de su fecha de efectividad indicada.

ANEXO A: EJEMPLOS DE CLASIFICACIÓN DE SEVERIDAD (3–6 EJEMPLOS)

A.1 Producto – Sev 1 (crítico masivo). Tras un upgrade soportado, la plataforma no arranca en producción para múltiples usuarios y no existe workaround razonable (p. ej., fallo sistémico del servicio principal).

A.2 Producto – Sev 2 (degradación grave). Módulo de búsqueda funciona pero con latencia extrema que afecta a múltiples usuarios; existe workaround parcial (p. ej., eliminar ponderaciones en búsquedas) con pérdida relevante de funcionalidad.

A.3 Producto – Sev 3 (no crítico). Error visual en UI o comportamiento menor con impacto limitado; existe workaround sencillo (p. ej., reintentar, cambiar validación).

A.4 SaaS – Incidente. El tenant del Cliente no es accesible (timeouts/HTTP 5xx) desde múltiples ubicaciones y se confirma indisponibilidad del servicio SaaS contratado.

A.5 Consulta. Pregunta sobre cómo configurar una regla de gobernanza descrita en Documentación, o cómo habilitar un conector estándar conforme a guía.