SLA Y CONDICIONES DE SOPORTE
Última actualización: 7 de agosto de 2026
Versión: 1.0
1. Objeto
Las presentes condiciones regulan los servicios de soporte, atención de incidencias, mantenimiento operativo, monitorización, niveles de servicio y gestión técnica proporcionados por:
ACCION DIGITAL LOCAL S.L.
NIF: B75510008
Domicilio: Avinguda de les Glòries Catalanes, 62, Bloc B, Can Palet, 08223 Terrassa, Barcelona, España
Correo electrónico: info@acciondigital.es
en adelante, “ACCIÓN DIGITAL”.
2. Aplicación
Estas condiciones complementan:
Condiciones Generales;
Sistemas y Automatización;
Inteligencia Artificial;
Hosting/VPS;
Seguridad y Responsabilidad Compartida;
Backup y Recuperación;
DPA;
SOW / Order Form.
La Orden determinará:
plan contratado;
horario;
canales;
tiempos;
disponibilidad;
cobertura;
exclusiones específicas;
precio.
3. Regla fundamental
La contratación de un servicio tecnológico no implica automáticamente la contratación de un SLA.
Solo existirá un compromiso contractual específico de:
tiempo de respuesta;
disponibilidad;
cobertura 24/7;
intervención;
recuperación;
resolución;
cuando figure expresamente en la Orden o SOW.
4. Soporte sin SLA
Cuando un servicio incluya soporte pero no identifique expresamente un SLA, ACCIÓN DIGITAL prestará asistencia de forma razonable según:
disponibilidad del equipo;
gravedad;
orden de entrada;
impacto;
dependencias;
recursos disponibles.
En este supuesto no existe un plazo contractual garantizado de primera respuesta o resolución.
5. SLA contratado
Cuando la Orden indique expresamente:
“SLA CONTRATADO”
serán aplicables:
prioridades;
horarios;
tiempos de primera respuesta;
métricas;
exclusiones;
establecidos en este documento y en la Orden.
6. Horario estándar de soporte
Salvo que la Orden indique otro horario:
Lunes a viernes
09:00–18:00
Zona horaria: Europe/Madrid
excluyendo días no laborables aplicables al centro operativo de ACCIÓN DIGITAL.
7. Soporte 24/7
El soporte 24 horas al día, 7 días por semana:
NO está incluido por defecto.
Solo existirá cuando se identifique expresamente en la Orden.
8. Cobertura fuera de horario
Los tickets recibidos fuera del horario contratado se considerarán recibidos, a efectos de cómputo del SLA, al inicio de la siguiente ventana de soporte.
Excepción:
cuando exista cobertura 24/7 expresamente contratada para la prioridad correspondiente.
9. Canal oficial
El CLIENTE deberá utilizar los canales de soporte establecidos por ACCIÓN DIGITAL.
Podrán incluir:
sistema de tickets;
portal;
correo específico;
teléfono de emergencia;
canal técnico acordado.
10. Canales informales
Salvo acuerdo distinto, no se considerarán canales oficiales de soporte:
mensajes personales;
redes sociales;
WhatsApp personal;
mensajes enviados a miembros del equipo;
comentarios en documentos;
comunicaciones fuera del sistema acordado.
ACCIÓN DIGITAL podrá responderlos, pero ello no implica activación del SLA.
11. Ticket
Cada incidencia deberá registrarse, cuando sea razonablemente posible, mediante un ticket.
El ticket debería contener:
cliente;
servicio afectado;
descripción;
impacto;
usuarios afectados;
momento aproximado de inicio;
capturas o logs disponibles;
cambios recientes;
persona de contacto.
12. Un incidente por ticket
Cuando resulte razonable, cada incidencia independiente deberá gestionarse en un ticket separado.
Agrupar múltiples problemas no relacionados en un único ticket podrá dificultar su clasificación y seguimiento.
13. Incidente
Se considera Incidente una interrupción, degradación o comportamiento materialmente distinto del funcionamiento contratado de un Servicio.
14. Solicitud de servicio
No constituye necesariamente un Incidente una petición de:
configuración;
alta;
baja;
información;
consulta;
modificación ordinaria.
Estas solicitudes podrán gestionarse como Service Request.
15. Cambio
No constituye Incidente una petición destinada a:
añadir funcionalidades;
modificar workflows;
crear integraciones;
cambiar arquitectura;
desarrollar nuevas funciones;
modificar diseño.
Dichas solicitudes podrán gestionarse como Change Request.
16. Bug
Un bug podrá considerarse Incidente cuando produzca una desviación material respecto de lo contratado.
No toda preferencia, mejora o comportamiento no contemplado constituye un bug.
17. Problema
Un Problema es la causa subyacente conocida o potencial de uno o varios incidentes.
La resolución de un Incidente puede producirse antes de identificar definitivamente su causa raíz.
18. Restauración frente a resolución
Se diferencia entre:
RESTAURACIÓN
Recuperar una funcionalidad operativa suficiente.
RESOLUCIÓN DEFINITIVA
Eliminar o corregir la causa subyacente.
Una incidencia podrá considerarse mitigada aunque exista posteriormente trabajo de corrección permanente.
19. Primera respuesta
La Primera Respuesta es la primera intervención humana significativa de ACCIÓN DIGITAL destinada a:
reconocer;
clasificar;
analizar;
solicitar información;
iniciar la gestión.
20. Respuesta automática
Un mensaje automático de:
“Ticket recibido”
no contará por sí solo como Primera Respuesta humana.
21. Tiempo de respuesta
TIEMPO DE RESPUESTA ≠ TIEMPO DE RESOLUCIÓN.
Cumplir el tiempo de primera respuesta no significa que la incidencia deba estar resuelta dentro de dicho periodo.
22. Tiempo de resolución
Solo existirá un tiempo contractual de resolución garantizado cuando la Orden lo indique expresamente.
Salvo dicho pacto, ACCIÓN DIGITAL no garantiza un plazo fijo de resolución.
23. Dependencias de resolución
El tiempo de resolución puede depender de:
diagnóstico;
complejidad;
datos disponibles;
CLIENTE;
proveedor upstream;
API externa;
fabricante;
disponibilidad de repuestos;
restauración;
permisos;
terceros.
24. Clasificación de prioridades
Los incidentes podrán clasificarse como:
P1 — CRÍTICO
P2 — ALTO
P3 — MEDIO
P4 — BAJO / SOLICITUD
25. P1 — Crítico
Un incidente podrá clasificarse como P1 cuando exista un impacto crítico real en producción.
Ejemplos:
servicio principal completamente indisponible;
mayoría de usuarios incapaces de utilizar una función crítica;
pérdida activa o riesgo inmediato grave de datos;
compromiso de seguridad activo con impacto material;
automatización crítica ejecutando acciones perjudiciales;
fallo crítico sin workaround razonable.
26. Qué no es P1
No se considerará normalmente P1:
problema estético;
funcionalidad secundaria;
petición de mejora;
usuario individual bloqueado cuando existen alternativas;
duda;
cambio;
lentitud menor;
problema en DEV;
problema en TEST;
error sin impacto operativo crítico.
27. P2 — Alto
Podrá clasificarse P2 cuando:
una función importante está indisponible;
existe degradación severa;
un número relevante de usuarios está afectado;
existe impacto operacional considerable;
existe workaround limitado.
28. P3 — Medio
Podrá clasificarse P3 cuando:
existe un error no crítico;
el servicio principal continúa funcionando;
existe workaround;
el impacto es limitado;
afecta a una función secundaria.
29. P4 — Bajo
Podrá clasificarse P4:
consulta;
solicitud;
cambio menor;
mejora;
documentación;
asistencia no urgente;
incidencia cosmética.
30. Prioridad solicitada por el CLIENTE
El CLIENTE podrá proponer una prioridad.
La prioridad contractual definitiva se determinará según el impacto objetivo.
31. Reclasificación
ACCIÓN DIGITAL podrá reclasificar razonablemente un ticket cuando su prioridad declarada no corresponda con:
alcance;
impacto;
usuarios afectados;
criticidad.
Cuando sea relevante, se explicará el motivo.
32. Falsa clasificación P1
La utilización reiterada del nivel P1 para cuestiones manifiestamente no críticas podrá considerarse abuso del canal de emergencia.
ACCIÓN DIGITAL podrá:
reclasificar;
solicitar corrección del procedimiento;
limitar el canal de emergencia;
revisar las condiciones del servicio.
33. SLA Estándar AD
Este SLA solo será aplicable cuando la Orden indique expresamente “SLA ESTÁNDAR AD”.
Los objetivos de primera respuesta serán:
| PrioridadPrimera respuesta | |
|---|---|
| P1 — Crítico | 4 horas laborables |
| P2 — Alto | 8 horas laborables |
| P3 — Medio | 2 días laborables |
| P4 — Bajo | 3 días laborables |
34. Cómputo
Los tiempos se computarán únicamente dentro del horario cubierto por el plan.
Ejemplo:
Un P1 recibido el viernes a las 17:00 con soporte estándar dispone de una hora computable ese viernes y continúa computándose al abrir la siguiente ventana de soporte.
35. SLA personalizado
Un CLIENTE podrá contratar tiempos distintos.
Ejemplo:
| PrioridadRespuesta | |
|---|---|
| P1 | [DEFINIR] |
| P2 | [DEFINIR] |
| P3 | [DEFINIR] |
| P4 | [DEFINIR] |
El SOW prevalecerá sobre la tabla estándar.
36. SLA 24/7
Un plan 24/7 deberá definir expresamente:
prioridades cubiertas;
teléfono/canal;
tiempos;
personal de guardia;
precio.
No deberá presumirse que P2, P3 y P4 tienen cobertura 24/7 simplemente porque P1 la tenga.
37. Inicio del SLA
El cómputo comienza cuando:
1. el ticket llega al canal oficial;
2. se encuentra dentro de la ventana cubierta;
3. contiene información suficiente para identificar razonablemente el servicio afectado.
38. Información insuficiente
Cuando falte información esencial, ACCIÓN DIGITAL podrá solicitarla.
Los tiempos posteriores que dependan de esa información podrán quedar suspendidos hasta recibirla.
39. Pausa por CLIENTE
El cómputo de actuaciones que requieran cooperación quedará pausado mientras ACCIÓN DIGITAL espere:
respuesta;
acceso;
autorización;
prueba;
decisión;
credencial;
confirmación;
del CLIENTE.
40. Pausa por tercero
Cuando la resolución dependa exclusivamente de una actuación de un tercero no controlado por ACCIÓN DIGITAL, el tiempo de resolución —cuando exista— podrá quedar suspendido conforme al régimen establecido en la Orden.
El tiempo de primera respuesta ya cumplido no se altera.
41. Seguimiento
ACCIÓN DIGITAL podrá actualizar un incidente activo cuando:
exista un cambio relevante;
se identifique la causa;
se aplique una mitigación;
sea necesaria una actuación del CLIENTE.
No se garantiza una frecuencia concreta de actualizaciones salvo contratación específica.
42. P1 activo
Durante un P1, ACCIÓN DIGITAL priorizará razonablemente:
1. seguridad;
2. contención;
3. recuperación de servicio;
4. integridad de datos;
5. diagnóstico definitivo.
43. Workaround
Un workaround válido podrá utilizarse para restaurar temporalmente el servicio.
Después de recuperar la operación, la incidencia podrá:
reducir prioridad;
convertirse en Problem;
generar una corrección posterior.
44. Root Cause Analysis
Un análisis formal de causa raíz —RCA— no está incluido automáticamente en todo incidente.
Podrá proporcionarse cuando:
esté contratado;
la criticidad lo justifique;
ACCIÓN DIGITAL lo considere adecuado.
45. Postmortem
Un informe postmortem podrá incluir:
impacto;
cronología;
causa;
acciones realizadas;
medidas preventivas.
No se considera incluido salvo que el plan o la gravedad del incidente lo contemple.
46. Investigación sin causa concluyente
En sistemas complejos puede no ser técnicamente posible determinar con certeza absoluta la causa de un incidente.
ACCIÓN DIGITAL documentará, cuando corresponda:
hechos conocidos;
evidencias;
hipótesis razonables;
medidas adoptadas.
47. Monitorización
La monitorización puede detectar automáticamente:
caída;
consumo;
errores;
certificados;
servicios;
recursos.
Solo estará incluida cuando forme parte del plan contratado.
48. Monitorización ≠ soporte
La existencia de monitorización no implica automáticamente:
intervención humana;
soporte 24/7;
reparación automática;
llamada inmediata.
49. Monitorización como fuente de medición
Cuando exista un compromiso de disponibilidad, la Orden deberá identificar el sistema utilizado como fuente de medición.
En ausencia de otra definición, se utilizará el sistema de monitorización gestionado por ACCIÓN DIGITAL para el servicio afectado.
50. Disponibilidad
Solo existirá una garantía cuantitativa de disponibilidad cuando figure expresamente en la Orden.
Ejemplo:
Disponibilidad mensual objetivo: [99,X %]
51. Sin porcentaje contratado
Si la Orden no contiene un porcentaje de disponibilidad:
no existe garantía contractual de uptime expresada porcentualmente.
52. Cálculo de disponibilidad
Cuando exista SLA de disponibilidad, podrá calcularse mediante:
Disponibilidad = (Tiempo elegible − Indisponibilidad elegible) ────────────────────────────────────────────── × 100 Tiempo elegible
53. Indisponibilidad
Se considerará indisponibilidad elegible cuando el Servicio cubierto no pueda ejecutar materialmente su función principal por una causa incluida en el SLA.
54. Degradación
Una reducción de rendimiento no constituirá necesariamente indisponibilidad total.
Cuando se quiera medir degradación, deberá existir una métrica específica.
55. Periodo de medición
Salvo acuerdo distinto:
periodo de medición = mes natural.
56. Servicio medido
La disponibilidad se calculará sobre el componente expresamente identificado.
No se presumirá que el SLA de un componente se extiende automáticamente a:
Internet del CLIENTE;
dispositivo;
aplicación externa;
API no gestionada;
proveedor ajeno.
57. Mantenimiento programado
No se considerará normalmente indisponibilidad elegible aquella derivada de mantenimiento programado dentro de las ventanas permitidas y comunicado conforme al contrato.
58. Aviso de mantenimiento
Cuando sea razonablemente posible, ACCIÓN DIGITAL procurará comunicar previamente mantenimientos con impacto relevante.
El plazo de preaviso específico podrá definirse en la Orden.
59. Mantenimiento urgente
Podrá realizarse mantenimiento urgente sin preaviso completo cuando resulte necesario para:
corregir vulnerabilidad grave;
contener ataque;
impedir pérdida de datos;
evitar una interrupción mayor.
60. Exclusiones generales del SLA
Salvo pacto distinto, no computarán como incumplimiento del SLA los incidentes directamente derivados de:
mantenimiento excluido;
fuerza mayor;
acción del CLIENTE;
cambios no autorizados;
credenciales comprometidas bajo control del CLIENTE;
software no gestionado;
incumplimiento de AUP;
suspensión legítima;
impago;
entorno beta;
DEV/TEST no cubierto;
conectividad del CLIENTE;
dispositivo del CLIENTE.
61. Proveedores externos
Los fallos de terceros se analizarán conforme a las obligaciones realmente asumidas por ACCIÓN DIGITAL.
La mera dependencia de un tercero no elimina automáticamente toda responsabilidad de ACCIÓN DIGITAL.
62. Upstream sin redundancia contratada
Cuando la arquitectura contratada dependa de un único proveedor upstream y no exista redundancia contratada, la indisponibilidad exclusiva del proveedor podrá quedar fuera del SLA de ACCIÓN DIGITAL cuando así lo establezca la Orden.
63. SLA del proveedor externo
SLA UPSTREAM ≠ SLA ACCIÓN DIGITAL.
El SLA que un proveedor cloud ofrece a ACCIÓN DIGITAL no se convierte automáticamente en un compromiso idéntico frente al CLIENTE.
64. APIs externas
No se garantizará la disponibilidad de una API controlada por un tercero salvo que ACCIÓN DIGITAL haya asumido expresamente una arquitectura capaz de mitigar su indisponibilidad.
65. Rate limits
Un fallo provocado por superar límites externos no constituirá automáticamente incumplimiento de disponibilidad cuando:
el límite pertenezca al proveedor;
la capacidad contratada sea insuficiente;
el consumo exceda el dimensionamiento comunicado.
66. DDoS
Los ataques de denegación de servicio serán evaluados atendiendo a:
arquitectura;
mitigación contratada;
proveedor;
obligaciones específicas.
No todo DDoS quedará automáticamente incluido o excluido del SLA.
67. Incidente de seguridad
Los incidentes de seguridad se gestionarán prioritariamente conforme al riesgo.
La existencia de un incidente de seguridad no implica automáticamente incumplimiento contractual.
Se analizarán:
causa;
controles;
obligaciones;
actuación de las Partes.
68. Backup
El SLA de disponibilidad no constituye un SLA de backup o recuperación.
RPO y RTO se regulan separadamente en:
10 — Backup y Recuperación.
69. RTO
Recovery Time Objective — RTO es un objetivo de tiempo de recuperación.
No equivale necesariamente a un tiempo garantizado salvo que el contrato lo indique expresamente.
70. RPO
Recovery Point Objective — RPO representa el objetivo relativo al punto de recuperación de datos.
No equivale a garantía de pérdida cero.
71. Disponibilidad ≠ RTO
Un sistema puede incumplir disponibilidad sin requerir restore.
Y un desastre puede requerir restauración aunque exista un SLA ordinario de disponibilidad.
Son métricas distintas.
72. Créditos de servicio
No existirán automáticamente créditos, devoluciones o descuentos por SLA.
Solo se aplicarán cuando:
el plan contratado lo contemple;
se cumplan sus requisitos.
73. Tabla de créditos
Cuando se contrate expresamente un sistema de créditos, podrá definirse en la Orden mediante una tabla como:
| Disponibilidad mensualCrédito | |
|---|---|
| ≥ SLA contratado | 0 % |
| [RANGO 1] | [X %] |
| [RANGO 2] | [X %] |
| [RANGO 3] | [X %] |
74. Base del crédito
Salvo acuerdo distinto, cualquier crédito se calculará únicamente sobre la cuota recurrente mensual del componente directamente afectado, no sobre:
otros servicios;
proyectos;
licencias;
consumos;
costes de terceros.
75. Límite de créditos
Cuando existan créditos de servicio, su importe máximo por periodo no excederá el porcentaje establecido en la Orden.
No se acumularán ilimitadamente.
76. Solicitud de crédito
El CLIENTE deberá solicitar el crédito conforme al procedimiento establecido en la Orden.
La solicitud deberá identificar:
servicio;
fechas;
incidente;
duración estimada;
ticket relacionado.
77. Créditos y responsabilidades inderogables
Un crédito SLA no excluirá aquellas responsabilidades que legalmente no puedan limitarse o excluirse.
78. Crédito no equivalente a multa
Los créditos se conciben como compensación contractual específica vinculada al nivel de servicio, no como penalización automática por cualquier incidencia.
79. Intervenciones no incluidas
El soporte no incluye automáticamente:
nuevos desarrollos;
nuevas integraciones;
migraciones;
reconstrucción causada por terceros;
formación;
rediseño;
limpieza de datos;
tareas de otro proveedor;
cambios de alcance.
80. Diagnóstico de terceros
ACCIÓN DIGITAL podrá ayudar a diagnosticar problemas originados en sistemas de terceros.
Ese trabajo podrá:
estar incluido hasta cierto límite;
o facturarse adicionalmente;
según el plan contratado.
81. Soporte del fabricante
Cuando sea necesario abrir una incidencia con:
hosting;
software;
API;
fabricante;
SaaS;
ACCIÓN DIGITAL podrá gestionarla en nombre del CLIENTE cuando disponga de autorización.
82. Tiempo del tercero
ACCIÓN DIGITAL no garantiza los tiempos de respuesta o solución de un tercero salvo que contractualmente haya asumido una obligación independiente para mitigarlos.
83. Accesos
El CLIENTE deberá proporcionar los accesos necesarios para diagnosticar un incidente.
La falta de acceso podrá:
retrasar;
suspender;
impedir;
la resolución.
84. Cambios recientes
El CLIENTE deberá informar razonablemente sobre cambios realizados antes de una incidencia.
Por ejemplo:
plugins;
código;
DNS;
credenciales;
firewall;
permisos;
infraestructura.
85. Intervención del CLIENTE durante P1
Durante un P1, el CLIENTE deberá evitar cambios no coordinados que puedan:
alterar evidencias;
empeorar el incidente;
dificultar diagnóstico.
86. Acciones de emergencia
Durante un incidente grave ACCIÓN DIGITAL podrá realizar, dentro de las facultades contratadas:
reinicio;
aislamiento;
bloqueo;
failover;
rollback;
revocación;
restauración;
desactivación temporal.
El objetivo será minimizar el impacto.
87. Acciones destructivas
Cuando una acción de recuperación pueda implicar:
pérdida de datos;
restauración antigua;
destrucción;
cambio irreversible;
se procurará obtener autorización previa cuando la urgencia y las circunstancias lo permitan.
88. Autorización previa de emergencia
El SOW podrá contener una autorización previa para ejecutar determinadas acciones de emergencia sin aprobación individual.
Ejemplo:
reiniciar servicio;
aislar contenedor;
bloquear IP atacante;
activar backup operativo.
89. Registro
Las actuaciones de soporte podrán quedar registradas mediante:
tickets;
logs;
mensajes;
cambios;
commits;
registros técnicos.
90. Evidencia
Los registros podrán utilizarse para determinar:
tiempos;
actuaciones;
causa;
responsabilidades;
cumplimiento del SLA.
91. Hora oficial
Para el cómputo contractual se utilizará la hora registrada por los sistemas técnicos de ACCIÓN DIGITAL o la fuente de tiempo acordada.
Zona horaria de referencia:
Europe/Madrid, salvo pacto distinto.
92. Servicio degradado por capacidad
Una degradación causada directamente por haber alcanzado la capacidad contratada no constituirá automáticamente un incumplimiento.
Podrá requerir ampliación.
93. Picos no comunicados
Cuando un incremento excepcional y no previsto de carga supere el dimensionamiento, ACCIÓN DIGITAL procurará colaborar en la recuperación, pero dicha circunstancia deberá considerarse al evaluar el SLA.
94. Usuarios no autorizados
Incidentes provocados por usuarios o credenciales no adecuadamente controlados por el CLIENTE podrán quedar fuera de las garantías afectadas.
95. EOL
No se aplicarán las mismas garantías a software:
fuera de soporte;
EOL;
obsoleto;
cuando ACCIÓN DIGITAL haya recomendado razonablemente su actualización y el CLIENTE haya decidido mantenerlo.
96. Sistemas modificados
El SLA podrá quedar suspendido sobre componentes modificados por terceros sin coordinación hasta:
analizar;
validar;
restaurar;
un estado soportado.
97. Beta
Los servicios clasificados como:
beta;
preview;
experimental;
proof of concept;
no tendrán SLA de producción salvo pacto expreso.
98. Entornos de prueba
DEV, TEST, QA y STAGING no estarán cubiertos por SLA de producción salvo que la Orden diga expresamente lo contrario.
99. Soporte de IA
Los incidentes relacionados con inteligencia artificial se evaluarán distinguiendo entre:
indisponibilidad técnica;
integración rota;
output incorrecto;
alucinación;
comportamiento probabilístico.
Un Output incorrecto no constituye automáticamente una caída técnica del servicio.
100. Error de IA
Cuando un sistema de IA funcione técnicamente pero produzca un resultado incorrecto, se aplicarán las:
Condiciones de Inteligencia Artificial
y los criterios de aceptación/evaluación correspondientes.
101. Soporte de automatizaciones
Una automatización puede encontrarse:
activa;
fallida;
pausada;
esperando;
bloqueada;
parcialmente ejecutada.
El diagnóstico deberá considerar el estado real del workflow.
102. Reejecución
Una reejecución no se realizará automáticamente cuando pueda provocar:
duplicado;
doble pago;
doble envío;
doble registro.
Podrá requerirse revisión previa.
103. Disponibilidad de integración
Una integración depende normalmente de al menos:
SISTEMA A + CONEXIÓN + AUTOMATIZACIÓN + SISTEMA B
La indisponibilidad de uno de estos componentes puede afectar al resultado global.
104. Escalado técnico
ACCIÓN DIGITAL podrá escalar una incidencia internamente según:
prioridad;
especialización;
seguridad;
arquitectura.
105. Contacto de emergencia del CLIENTE
Para servicios críticos, el CLIENTE deberá mantener actualizado al menos un contacto autorizado para emergencias.
106. Imposibilidad de contactar
Cuando sea necesario adoptar una decisión urgente y no sea posible contactar con el CLIENTE, ACCIÓN DIGITAL actuará dentro de las autorizaciones previas disponibles.
Si no existe autorización suficiente, podrá optar por la medida conservadora que razonablemente reduzca el riesgo.
107. Revisiones periódicas
Los SLA podrán revisarse cuando cambie sustancialmente:
arquitectura;
volumen;
criticidad;
horario;
número de usuarios;
tecnología.
108. Cambio de SLA
Un cambio de SLA puede implicar:
nuevos recursos;
redundancia;
guardias;
monitorización;
mayor coste.
Un SLA más exigente no se obtiene únicamente modificando el número contractual.
109. SLA y arquitectura
Los compromisos deberán ser técnicamente coherentes.
No se ofrecerá razonablemente un SLA de alta disponibilidad sobre una arquitectura que contenga deliberadamente un único punto de fallo incompatible con ese compromiso.
110. SLA y precio
El precio podrá variar según:
cobertura;
horario;
tiempos;
redundancia;
guardias;
criticidad.
111. Revisión del SLA tras incidente
Un incidente grave podrá revelar la necesidad de:
aumentar capacidad;
añadir redundancia;
cambiar proveedor;
modificar arquitectura.
Estas mejoras podrán requerir un nuevo presupuesto.
112. Terminación
La finalización del Servicio implica la finalización del SLA asociado en la misma fecha, salvo que exista un periodo de soporte de transición expresamente contratado.
113. Offboarding
El soporte durante migración o salida se regirá además por:
17 — Offboarding.
El SLA ordinario podrá no ser aplicable durante actuaciones extraordinarias de migración si así se establece previamente.
114. Limitación de responsabilidad
Será aplicable el régimen establecido en:
04 — Condiciones Generales de Servicios Tecnológicos.
Este documento no amplía automáticamente el límite de responsabilidad económica.
115. Prioridad de restauración
Salvo obligación distinta, durante un incidente ACCIÓN DIGITAL podrá priorizar:
restauración segura del servicio
sobre:
identificación inmediata de la causa definitiva.
116. Deber de mitigación
Ambas Partes deberán colaborar razonablemente para reducir:
impacto;
duración;
propagación;
pérdida.
117. Uso razonable del soporte
El CLIENTE deberá utilizar los canales de soporte de forma razonable.
No se permite utilizar el soporte para:
acoso;
amenazas;
peticiones ilícitas;
actividades fuera de alcance de manera sistemática.
118. Modificaciones
Las modificaciones de estas condiciones se regirán por las Condiciones Generales.
Una versión nueva no alterará retroactivamente un SLA vigente salvo acuerdo válido o requisito legal aplicable.
119. Legislación aplicable
Será aplicable el régimen previsto en las:
Condiciones Generales de Servicios Tecnológicos
y la legislación española y europea correspondiente.
120. Contacto
ACCION DIGITAL LOCAL S.L.
NIF B75510008
Avinguda de les Glòries Catalanes, 62, Bloc B, Can Palet
08223 Terrassa, Barcelona
España
Email: info@acciondigital.es
Versión: 1.0
Fecha: 7 de agosto de 2026