CONDICIONES ESPECÍFICAS DE SISTEMAS Y AUTOMATIZACIÓN
Última actualización: 7 de agosto de 2026
Versión: 1.0
1. Objeto
Las presentes Condiciones Específicas regulan los servicios de diseño, desarrollo, configuración, implantación, integración, automatización, operación, mantenimiento y soporte de sistemas tecnológicos 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”.
Estas Condiciones complementan las Condiciones Generales de Servicios Tecnológicos.
2. Servicios comprendidos
Estas Condiciones podrán aplicarse a servicios relacionados con:
automatización de procesos;
workflows;
integraciones entre plataformas;
APIs;
webhooks;
CRM;
ERP;
sistemas de gestión;
sistemas de tickets;
bases de datos;
aplicaciones web;
middleware;
conectores;
procesos ETL;
sincronización de información;
sistemas de notificaciones;
herramientas empresariales;
gestores documentales;
sistemas de autenticación;
paneles de control;
scripts;
tareas programadas;
agentes software;
infraestructura asociada;
sistemas basados en eventos;
automatizaciones que incorporen inteligencia artificial;
otros componentes tecnológicos especificados en una Orden o SOW.
3. Aplicación conjunta
Estas Condiciones deberán interpretarse conjuntamente con:
Condiciones Generales;
Orden / Order Form;
SOW;
Condiciones de Inteligencia Artificial, cuando corresponda;
Condiciones de Hosting/VPS;
SLA y Soporte;
Seguridad y Responsabilidad Compartida;
Backup y Recuperación;
Acceptable Use Policy;
DPA;
documentación técnica incorporada al contrato.
En caso de contradicción sobre una funcionalidad concreta, prevalecerá el documento que la regule específicamente.
4. Alcance específico
Cada sistema deberá disponer, cuando la naturaleza del proyecto lo requiera, de un alcance que permita identificar:
objetivo;
entradas;
salidas;
sistemas conectados;
reglas;
automatizaciones;
usuarios;
permisos;
acciones autorizadas;
acciones prohibidas;
fuentes de datos;
sistema principal;
dependencias;
entorno;
criterios de aceptación.
Las funcionalidades no identificadas no deberán presumirse incluidas.
5. Arquitectura
ACCIÓN DIGITAL podrá diseñar la arquitectura técnica utilizando aquellos componentes que considere adecuados al alcance contratado, siempre respetando:
requisitos expresamente pactados;
seguridad;
compatibilidad;
protección de datos;
restricciones del CLIENTE;
licencias;
condiciones de terceros.
La elección técnica concreta podrá evolucionar durante el desarrollo cuando exista una justificación razonable.
6. Sistemas de terceros
Una solución podrá integrar aplicaciones o infraestructuras pertenecientes a terceros.
Por ejemplo:
CRM;
ERP;
correo electrónico;
almacenamiento;
facturación;
bancos;
plataformas publicitarias;
herramientas de comunicación;
software empresarial;
APIs externas;
sistemas cloud;
servicios de inteligencia artificial.
ACCIÓN DIGITAL no controla completamente dichos sistemas.
7. Requisitos de terceros
El CLIENTE deberá disponer de:
cuentas necesarias;
licencias;
planes adecuados;
permisos;
claves API;
autorizaciones;
capacidad contratada;
cuando dichos elementos sean necesarios para prestar el Servicio y no hayan sido expresamente incluidos por ACCIÓN DIGITAL.
8. Condiciones de proveedores externos
El funcionamiento de una integración puede depender de condiciones establecidas por terceros, incluyendo:
límites API;
límites de llamadas;
límites de almacenamiento;
límites de usuarios;
restricciones geográficas;
permisos;
políticas de uso;
cuotas;
sistemas antifraude;
condiciones económicas;
procesos de revisión;
disponibilidad.
Una restricción impuesta por un tercero no constituye automáticamente un defecto del sistema desarrollado por ACCIÓN DIGITAL.
9. APIs
Cuando una automatización utilice una API externa, su funcionamiento podrá depender de:
disponibilidad de la API;
documentación;
autenticación;
permisos;
versión;
límites;
formato de respuesta;
latencia;
comportamiento del proveedor.
ACCIÓN DIGITAL no garantiza la continuidad indefinida de una API ajena.
10. Cambios de API
Los proveedores externos pueden modificar o retirar:
endpoints;
campos;
métodos;
autenticación;
permisos;
versiones;
límites;
funcionalidades.
Cuando un cambio posterior obligue a modificar una integración ya aceptada, la adaptación podrá:
estar incluida en mantenimiento, si así se ha contratado;
o constituir trabajo adicional.
11. APIs no oficiales
No se utilizarán APIs no oficiales, técnicas de ingeniería inversa, automatización de interfaces privadas o mecanismos similares sin evaluar previamente:
estabilidad;
seguridad;
condiciones del proveedor;
legalidad;
riesgo de bloqueo.
Cuando el CLIENTE solicite una integración mediante un mecanismo no soportado oficialmente, deberá ser informado del riesgo adicional.
ACCIÓN DIGITAL podrá rechazar su implantación.
12. Webhooks
Los sistemas podrán utilizar webhooks para comunicar eventos.
El CLIENTE reconoce que un webhook externo puede:
llegar correctamente;
llegar con retraso;
llegar repetido;
llegar fuera de orden;
no llegar;
contener información incompleta;
ser rechazado por un proveedor.
El diseño del sistema deberá considerar estos escenarios cuando el riesgo lo justifique.
13. Polling
Cuando una integración no permita eventos en tiempo real, podrá utilizarse consulta periódica o polling.
La frecuencia dependerá de:
API;
límites del proveedor;
coste;
criticidad;
arquitectura;
plan contratado.
Un sistema basado en polling no debe considerarse necesariamente instantáneo.
14. Procesamiento asíncrono
Determinadas operaciones podrán realizarse mediante:
colas;
workers;
jobs;
tareas en segundo plano;
procesamiento diferido.
Por ello, la recepción de una solicitud no significa necesariamente que su procesamiento haya finalizado inmediatamente.
15. Tareas programadas
Las automatizaciones pueden ejecutarse según:
fecha;
hora;
intervalo;
evento;
condición.
Salvo SLA específico, una hora programada representa el momento previsto de inicio y no una garantía absoluta de ejecución en un segundo exacto.
16. Zona horaria
Las automatizaciones dependientes de fecha u hora deberán indicar la zona horaria aplicable cuando sea relevante.
Cuando no se haya definido otra:
se utilizará la zona horaria configurada expresamente para el sistema correspondiente.
El CLIENTE deberá informar si un proceso depende de:
cambios de horario;
múltiples países;
calendarios laborales;
festivos;
horarios comerciales.
17. Semántica de entrega
Salvo que la arquitectura y el SOW establezcan una garantía específica, ACCIÓN DIGITAL no garantiza procesamiento exactamente una única vez — exactly-once — en todas las integraciones.
Dependiendo del sistema podrá existir:
at-most-once;
at-least-once;
procesamiento idempotente;
deduplicación;
reintentos.
La estrategia adecuada se definirá según el riesgo y las capacidades de los sistemas conectados.
18. Idempotencia
Cuando una operación pueda repetirse y una duplicación pudiera generar consecuencias importantes, ACCIÓN DIGITAL podrá implementar mecanismos de idempotencia o deduplicación cuando:
sean técnicamente viables;
la API externa los permita;
estén incluidos en el alcance;
el riesgo lo justifique.
No debe presumirse que todos los sistemas externos permiten garantizar idempotencia.
19. Duplicados
Determinados eventos externos pueden producir duplicados.
Por ejemplo:
pedidos;
leads;
tickets;
notificaciones;
webhooks;
registros.
ACCIÓN DIGITAL podrá incorporar mecanismos de prevención cuando estén contemplados en la arquitectura.
La eliminación absoluta de duplicados no se garantiza salvo compromiso específico.
20. Reintentos
Ante fallos temporales podrán configurarse reintentos automáticos.
La estrategia podrá establecer:
número máximo;
intervalo;
backoff;
condición de abandono;
cola de errores;
intervención humana.
Un reintento puede provocar consecuencias diferentes dependiendo del comportamiento del sistema externo.
21. Dead-letter / cola de errores
Cuando la criticidad lo justifique, podrán utilizarse mecanismos para conservar operaciones que no hayan podido ejecutarse correctamente.
Estos mecanismos podrán permitir:
inspección;
reejecución;
corrección;
intervención manual.
Solo estarán incluidos cuando la arquitectura o plan contratado lo contemple.
22. Fallos parciales
Una automatización puede ejecutar correctamente una parte del proceso y fallar posteriormente.
Ejemplo:
1. Crear cliente ✅
2. Crear factura ✅
3. Enviar email ❌
4. Registrar notificación ❌
Un fallo posterior no implica necesariamente que las actuaciones anteriores hayan sido revertidas.
23. Transacciones distribuidas
Cuando un flujo involucra sistemas independientes, puede no existir una transacción única capaz de revertir automáticamente todas las actuaciones.
Por ello podrán utilizarse:
compensaciones;
estados;
retries;
reconciliación;
intervención manual.
24. Rollback
Un rollback de software no equivale necesariamente a un rollback de datos.
Restaurar una versión anterior de código:
no elimina necesariamente registros creados;
no revierte necesariamente emails enviados;
no revoca automáticamente operaciones realizadas;
no deshace necesariamente acciones ejecutadas en terceros.
Las operaciones que requieran reversibilidad deberán diseñarse expresamente para ello.
25. Acciones irreversibles
Se consideran especialmente sensibles operaciones como:
eliminación de información;
envío masivo;
publicación;
cambio DNS;
cancelación de servicios;
eliminación de cuentas;
modificación masiva de permisos;
transferencias económicas;
generación de obligaciones frente a terceros;
cambios destructivos en producción.
Estas acciones estarán sujetas a controles reforzados cuando el riesgo lo justifique.
26. Autorización de automatizaciones
Una automatización únicamente podrá ejecutar de forma autónoma aquellas acciones que se encuentren dentro del alcance previamente autorizado.
La mera conexión de una cuenta o concesión de una credencial no constituye autorización ilimitada para ejecutar cualquier acción disponible mediante dicha cuenta.
27. Niveles de autonomía
Cuando resulte útil, una automatización podrá clasificarse mediante niveles:
NIVEL 0 — CONSULTA
Solo obtiene y presenta información.
NIVEL 1 — PROPUESTA
Analiza y propone una actuación, pero no ejecuta.
NIVEL 2 — APROBACIÓN PREVIA
Prepara la actuación y requiere autorización humana antes de ejecutarla.
NIVEL 3 — AUTONOMÍA LIMITADA
Ejecuta automáticamente acciones previamente definidas dentro de reglas y límites concretos.
NIVEL 4 — AUTONOMÍA AMPLIADA
Solo se utilizará cuando exista autorización expresa y controles adecuados al riesgo.
El nivel aplicable deberá constar en el SOW cuando sea relevante.
28. Regla por defecto
Salvo autorización expresa:
una integración puede consultar información necesaria para el servicio;
pero no debe presumirse autorizada para ejecutar acciones críticas, destructivas o irreversibles.
Las capacidades deberán aplicarse según el principio de mínimo privilegio cuando resulte técnicamente razonable.
29. Aprobación humana
Cuando una acción requiera aprobación, ésta podrá realizarse mediante:
sistema de tickets;
panel;
correo;
interfaz;
mecanismo específicamente acordado.
La aprobación deberá permitir identificar razonablemente:
acción;
usuario;
fecha;
alcance.
30. Personas autorizadas
El CLIENTE deberá identificar qué personas pueden aprobar operaciones relevantes.
ACCIÓN DIGITAL podrá rechazar una aprobación cuando:
proceda de una persona no autorizada;
existan indicios de compromiso de cuenta;
resulte contradictoria;
supere el ámbito de autorización.
31. Límites de autorización
Una aprobación para una acción específica no implica autorización general.
Ejemplo:
aprobar:
“publicar estas 10 fichas”
no implica:
“permitir futuras publicaciones sin aprobación”.
32. Caducidad de aprobaciones
Cuando una aprobación quede obsoleta debido a:
modificación de datos;
cambio de precio;
cambio de destinatario;
cambio de configuración;
cambio material de contexto;
ACCIÓN DIGITAL podrá exigir una nueva autorización.
33. Kill switch
ACCIÓN DIGITAL podrá implementar mecanismos para detener una automatización.
Cuando exista riesgo grave o comportamiento anómalo, podrá:
desactivar workflow;
revocar integración;
detener worker;
bloquear credencial;
suspender ejecución;
pasar el sistema a modo manual.
Estas actuaciones podrán realizarse inmediatamente cuando sean razonablemente necesarias para prevenir daños.
34. Sistemas de origen y destino
Cada integración deberá identificar, cuando sea necesario:
sistema origen;
sistema destino;
dirección de sincronización;
frecuencia;
reglas de conflicto.
35. Fuente de verdad — Source of Truth
Cuando los mismos datos existan en varios sistemas, el proyecto deberá determinar cuál tiene prioridad.
Ejemplo:
Clientes → CRM = MASTER
Facturación → ERP = MASTER
Tickets → Sistema de soporte = MASTER
Si no existe una fuente de verdad definida y los sistemas presentan datos contradictorios, ACCIÓN DIGITAL no garantiza reconciliación automática correcta.
36. Conflictos de sincronización
Cuando un mismo dato sea modificado simultáneamente en distintos sistemas podrá producirse un conflicto.
La estrategia podrá ser:
última modificación prevalece;
sistema master prevalece;
revisión humana;
merge;
rechazo.
La estrategia deberá definirse cuando el riesgo sea relevante.
37. Calidad de datos
Una automatización no convierte automáticamente datos incorrectos en datos correctos.
ACCIÓN DIGITAL no responderá de errores cuyo origen directo sea:
datos incorrectos;
registros incompletos;
formatos inconsistentes;
duplicados preexistentes;
información obsoleta;
datos introducidos incorrectamente por el CLIENTE.
38. Validación
Podrán establecerse reglas de validación para comprobar:
formato;
presencia;
tipo;
rango;
consistencia;
duplicidad.
Una validación técnica no constituye necesariamente una verificación de la veracidad material del dato.
39. Transformación de datos
Las integraciones pueden transformar:
formatos;
fechas;
monedas;
nombres;
campos;
identificadores;
estructuras.
Estas reglas deberán documentarse cuando puedan afectar materialmente al significado de la información.
40. Migraciones
Una migración de datos deberá especificar:
origen;
destino;
volumen;
formatos;
mapeo;
exclusiones;
validación;
ventana;
backup;
criterio de aceptación.
No se presumirá incluida una limpieza exhaustiva de datos salvo contratación expresa.
41. Reconciliación
Cuando un proceso implique sistemas independientes, podrán realizarse verificaciones periódicas destinadas a detectar diferencias.
La reconciliación automática solo estará incluida cuando haya sido expresamente diseñada o contratada.
42. Entornos
Los proyectos podrán utilizar:
DEV;
TEST;
STAGING;
QA;
PRODUCTION.
No todos los proyectos requieren todos los entornos.
La arquitectura aplicable dependerá del alcance y riesgo.
43. Uso de producción
El entorno de producción deberá utilizarse para cargas reales una vez completadas las validaciones previstas.
El CLIENTE no deberá utilizar deliberadamente un entorno:
DEV;
TEST;
BETA;
como entorno crítico de producción salvo autorización específica.
44. Datos reales en pruebas
Se procurará evitar el uso innecesario de datos personales reales en entornos de prueba.
Cuando resulte necesario utilizarlos se aplicarán las medidas correspondientes según el riesgo y las obligaciones de protección de datos.
45. Pruebas
Dependiendo del proyecto, podrán realizarse:
pruebas funcionales;
integración;
regresión;
seguridad;
rendimiento;
recuperación;
aceptación.
Solo se considerarán contractualmente obligatorias las pruebas incluidas en el alcance o razonablemente necesarias para cumplir el servicio contratado.
46. Casos de prueba
Los tests se diseñarán sobre:
escenarios conocidos;
requisitos;
riesgos;
casos límite identificados.
La superación de pruebas no constituye garantía de ausencia absoluta de errores futuros.
47. QA
Cuando exista una fase independiente de QA, ésta podrá comprobar:
requisitos;
regresión;
seguridad;
permisos;
errores;
comportamiento esperado.
La existencia de QA reduce riesgo pero no implica perfección absoluta del software.
48. Criterios de aceptación
Un sistema se considerará conforme cuando cumpla materialmente los criterios definidos en:
SOW;
casos de aceptación;
requisitos aprobados;
documentación contractual.
Una preferencia posterior no documentada no constituye automáticamente un defecto.
49. Cambios en producción
Los cambios en producción podrán requerir:
ticket;
aprobación;
ventana;
backup;
plan de rollback;
verificación posterior.
El nivel de control dependerá del riesgo.
50. Gestión de versiones
ACCIÓN DIGITAL podrá utilizar versionado para identificar:
releases;
configuraciones;
código;
componentes;
despliegues.
La existencia de versionado no implica que todas las configuraciones de terceros puedan reproducirse exactamente.
51. Despliegues
Un despliegue podrá incluir:
1. preparación;
2. validación;
3. ejecución;
4. comprobación;
5. cierre.
Cuando una comprobación posterior falle, ACCIÓN DIGITAL podrá:
corregir;
revertir;
suspender;
activar contingencia.
52. Compatibilidad
ACCIÓN DIGITAL procurará mantener compatibilidad con las versiones expresamente soportadas.
No se garantiza compatibilidad indefinida con:
software obsoleto;
sistemas EOL;
navegadores antiguos;
APIs descontinuadas;
plugins abandonados;
versiones no soportadas.
53. End of Life
Cuando un componente quede sin soporte o represente un riesgo, ACCIÓN DIGITAL podrá recomendar o exigir su actualización para continuar prestando determinadas garantías de mantenimiento o seguridad.
La migración correspondiente podrá constituir trabajo adicional.
54. Cambios realizados por el CLIENTE
Si el CLIENTE o un tercero modifica sin coordinación:
código;
configuración;
automatización;
integración;
API;
base de datos;
permisos;
infraestructura;
plugin;
credencial;
firewall;
ACCIÓN DIGITAL podrá suspender temporalmente garantías o SLA sobre el componente afectado hasta determinar el impacto.
55. Acceso administrativo del CLIENTE
Cuando el CLIENTE disponga de acceso administrativo, deberá utilizarlo con diligencia.
El acceso administrativo implica capacidad para causar:
pérdida de datos;
indisponibilidad;
vulnerabilidades;
incompatibilidades;
errores.
ACCIÓN DIGITAL podrá recomendar limitar el acceso administrativo cuando el riesgo lo justifique.
56. Acceso de terceros contratados por el CLIENTE
El CLIENTE deberá informar razonablemente cuando permita que otro proveedor modifique componentes gestionados por ACCIÓN DIGITAL.
Cuando varios proveedores intervengan sobre un mismo sistema, las responsabilidades deberán determinarse según la causa efectiva del incidente.
57. Monitorización
Cuando esté contratada, la monitorización podrá cubrir:
disponibilidad;
procesos;
errores;
recursos;
servicios;
eventos;
seguridad.
El alcance dependerá del plan.
58. Monitorización no absoluta
La ausencia de una alerta no demuestra necesariamente la inexistencia de un incidente.
Un sistema de monitorización puede no detectar:
errores no configurados;
fallos internos de terceros;
errores semánticos;
datos incorrectos;
comportamientos nuevos.
59. Alertas
Las alertas podrán depender de:
umbrales;
reglas;
canales;
proveedores de comunicación.
La generación de una alerta no garantiza recepción inmediata por una persona salvo que exista un SLA específico.
60. Logs
Los sistemas podrán registrar:
acciones;
eventos;
errores;
accesos;
ejecuciones;
autorizaciones;
cambios;
identificadores técnicos.
El nivel de detalle dependerá de:
arquitectura;
seguridad;
capacidad;
privacidad;
coste;
plan contratado.
61. Limitaciones de logs
Los logs de ACCIÓN DIGITAL no reflejan necesariamente todo lo que sucede dentro de una plataforma externa.
Un proveedor tercero puede no facilitar:
logs completos;
causa interna;
historial ilimitado;
trazabilidad suficiente.
ACCIÓN DIGITAL no responderá por información técnica que el proveedor externo no ponga razonablemente a disposición.
62. Retención de logs
La duración de logs deberá adaptarse a:
finalidad;
riesgo;
seguridad;
protección de datos;
capacidad contratada;
obligaciones legales.
No se garantiza conservación indefinida.
63. Observabilidad
Cuando se contrate expresamente, el sistema podrá incorporar:
logs;
métricas;
alertas;
health checks;
trazas.
El nivel de observabilidad dependerá del plan técnico correspondiente.
64. Incidentes
Cuando se detecte una incidencia, ACCIÓN DIGITAL podrá:
1. clasificarla;
2. contenerla;
3. diagnosticarla;
4. corregirla;
5. verificar;
6. documentar;
7. cerrar.
Los tiempos aplicables dependerán del SLA contratado.
65. Incidente causado por terceros
Si la causa se encuentra en un proveedor externo, ACCIÓN DIGITAL podrá:
diagnosticar;
documentar;
abrir incidencia al proveedor;
aplicar workaround;
recomendar alternativa.
ACCIÓN DIGITAL no puede garantizar el plazo de reparación de un tercero sobre el que no tenga control.
66. Intervención manual
Una automatización no elimina necesariamente la intervención humana.
Podrán existir casos que requieran:
revisión;
aprobación;
corrección;
reconciliación;
desbloqueo;
reejecución;
investigación.
67. Excepciones
Los procesos empresariales pueden presentar situaciones no contempladas inicialmente.
Cuando aparezca una excepción nueva podrá ser necesario:
procesarla manualmente;
modificar el workflow;
añadir una regla;
ampliar alcance.
68. Automatización y criterio empresarial
ACCIÓN DIGITAL podrá automatizar reglas definidas por el CLIENTE.
Salvo contratación expresa, no asume la responsabilidad empresarial de decidir:
qué cliente aceptar;
qué precio aplicar;
qué factura aprobar;
qué empleado contratar;
qué contrato firmar;
qué contenido publicar;
qué decisión estratégica adoptar.
69. Comunicaciones automatizadas
Cuando un sistema envíe automáticamente:
emails;
SMS;
mensajes;
WhatsApp;
notificaciones;
comunicaciones comerciales;
el CLIENTE deberá garantizar que dispone de las bases jurídicas y autorizaciones necesarias para dichas comunicaciones.
El hecho de que ACCIÓN DIGITAL implemente técnicamente el envío no determina por sí mismo la licitud del tratamiento o comunicación ordenada por el CLIENTE.
70. Límites de envío
Los proveedores pueden imponer:
límites;
reputación;
cuotas;
filtros;
sistemas anti-spam;
verificaciones.
ACCIÓN DIGITAL no garantiza la recepción o entrega efectiva de todas las comunicaciones externas salvo que se haya asumido expresamente una obligación concreta.
71. Acciones económicas
Las automatizaciones que puedan:
emitir pagos;
aceptar cargos;
aprobar gastos;
realizar pedidos;
generar compromisos económicos;
deberán disponer de autorización expresa y controles adecuados.
Por defecto, no se presumirá autorización para que un sistema ejecute movimientos económicos ilimitados.
72. Límites operativos
Podrán establecerse controles como:
importe máximo;
volumen máximo;
destinatarios autorizados;
horario;
frecuencia;
lista permitida;
lista bloqueada;
necesidad de aprobación.
73. Rate limits
Determinados sistemas externos limitan el número o frecuencia de operaciones.
Cuando se alcance un límite:
la ejecución puede retrasarse;
entrar en cola;
reintentarse;
fallar.
La capacidad efectiva estará condicionada por las características del proveedor utilizado.
74. Consumo
Las automatizaciones pueden generar consumo de:
CPU;
RAM;
almacenamiento;
ancho de banda;
llamadas API;
tokens;
mensajes;
operaciones;
servicios de terceros.
Estos consumos pueden estar sujetos a límites y costes conforme al plan contratado.
75. Picos de carga
Un incremento extraordinario de volumen puede superar la capacidad inicialmente dimensionada.
El CLIENTE deberá informar cuando prevea:
campañas;
importaciones;
eventos;
lanzamientos;
grandes volúmenes.
Puede ser necesario ampliar recursos.
76. Escalabilidad
La existencia de una solución funcional no implica escalabilidad ilimitada.
Los límites dependerán de:
arquitectura;
infraestructura;
base de datos;
APIs;
presupuesto;
proveedores.
Una ampliación sustancial podrá requerir rediseño o cambio de plan.
77. Credenciales
Las integraciones deberán utilizar credenciales con los permisos mínimos razonablemente necesarios.
Cuando resulte posible se preferirán:
service accounts;
API keys específicas;
tokens independientes;
identidades de máquina;
frente a credenciales personales compartidas.
78. Rotación y revocación
ACCIÓN DIGITAL podrá solicitar o ejecutar, dentro de sus competencias:
rotación;
revocación;
sustitución;
de credenciales cuando exista:
sospecha de compromiso;
cambio de personal;
cambio de proveedor;
finalización de servicio;
requisito de seguridad.
79. Secretos
No deberán almacenarse secretos en:
código público;
documentación pública;
tickets abiertos;
repositorios sin protección;
cuando exista una alternativa segura razonable.
Las condiciones específicas se desarrollan en:
09 — Seguridad y Responsabilidad Compartida.
80. Copias de seguridad
Una automatización o sistema no incluye automáticamente backup completo.
El alcance de:
copias;
frecuencia;
retención;
restauración;
recuperación;
se determinará en:
10 — Backup y Recuperación.
81. Documentación
La documentación incluida será la especificada en el proyecto.
Podrá consistir en:
arquitectura;
instrucciones;
inventario;
configuración;
runbook;
SOP;
esquema;
manual.
La contratación no implica automáticamente la elaboración de documentación exhaustiva de cada línea de código o dependencia interna.
82. Documentación viva
Los sistemas evolucionan.
Cuando exista un mantenimiento activo, determinados documentos podrán actualizarse para reflejar cambios importantes.
No se garantiza que documentación histórica describa exactamente una versión posterior del sistema.
83. Formación
La formación solo estará incluida cuando se identifique expresamente.
Podrá limitarse a:
número de sesiones;
duración;
usuarios;
contenido.
La formación no implica soporte ilimitado posterior.
84. Propiedad intelectual
La titularidad de:
código;
workflows;
integraciones;
documentación;
conectores;
módulos;
componentes;
se regulará mediante:
12 — Propiedad Intelectual
y la correspondiente Orden o SOW.
85. Inteligencia artificial
Cuando una automatización incorpore:
modelo generativo;
clasificación mediante IA;
agente;
procesamiento probabilístico;
se aplicarán adicionalmente las:
06 — Condiciones de Inteligencia Artificial.
Una automatización que utiliza IA no deberá confundirse con una automatización puramente determinista.
86. Seguridad
Las medidas de seguridad se adaptarán a:
riesgo;
datos;
arquitectura;
alcance;
estado de la técnica;
coste razonable de implantación;
obligaciones aplicables.
El detalle se desarrollará mediante:
09 — Seguridad y Responsabilidad Compartida.
87. Vulnerabilidades
Si se detecta una vulnerabilidad significativa, ACCIÓN DIGITAL podrá:
limitar acceso;
desactivar funcionalidad;
actualizar;
parchear;
aislar;
suspender temporalmente el componente.
Cuando sea posible, se informará al CLIENTE.
88. Gestión de dependencias
Los sistemas pueden depender de librerías, plugins, módulos y componentes externos.
ACCIÓN DIGITAL podrá actualizar una dependencia por:
seguridad;
compatibilidad;
mantenimiento;
fin de soporte.
Una actualización que implique rediseño material podrá requerir trabajo adicional.
89. Auditorías externas
Una auditoría, pentest o certificación independiente no se considera incluida salvo contratación específica.
El CLIENTE no deberá realizar pruebas intrusivas contra infraestructura gestionada por ACCIÓN DIGITAL sin autorización previa.
90. Disponibilidad
La existencia de una automatización no implica garantía de disponibilidad continua.
Las garantías específicas únicamente existirán cuando hayan sido contratadas mediante un SLA.
91. Continuidad
Las medidas de continuidad podrán incluir:
reinicio;
supervisión;
redundancia;
failover;
backup;
recuperación.
No todas estas medidas están incluidas por defecto.
La arquitectura contratada determina la resiliencia disponible.
92. Dependencia única
Cuando el CLIENTE opte por una arquitectura económica basada en:
un único servidor;
una única región;
un único proveedor;
una única base de datos;
acepta el riesgo adicional derivado de esa decisión cuando haya sido adecuadamente informado.
La alta disponibilidad requiere infraestructura expresamente diseñada y contratada para ello.
93. Mantenimiento correctivo
Cuando esté contratado, el mantenimiento correctivo cubre la investigación y corrección de errores dentro del alcance acordado.
No incluye automáticamente:
nuevas funcionalidades;
evolución;
rediseño;
errores de terceros;
daños provocados por actuaciones externas.
94. Mantenimiento evolutivo
Las mejoras, nuevas funcionalidades y cambios de procesos se considerarán mantenimiento evolutivo.
Solo estarán incluidos si el plan contratado así lo establece.
95. Obsolescencia
ACCIÓN DIGITAL podrá informar al CLIENTE cuando una arquitectura haya quedado técnicamente obsoleta o presente riesgos crecientes.
Si el CLIENTE decide no actualizarla, determinadas garantías podrán quedar limitadas respecto de los riesgos directamente asociados a esa decisión.
96. Fin de servicio de terceros
Si un proveedor elimina una funcionalidad imprescindible, las Partes podrán acordar:
migración;
sustitución;
rediseño;
reducción del alcance;
terminación del componente afectado.
No se presume incluida gratuitamente una reconstrucción completa provocada por la retirada de un producto externo.
97. Pruebas de recuperación
Las pruebas de recuperación solo estarán incluidas cuando formen parte del servicio contratado.
Su superación acredita el resultado de la prueba realizada en ese momento y no constituye garantía absoluta frente a cualquier escenario futuro.
98. Auditoría de acciones
Cuando el sistema tenga capacidad suficiente, podrán mantenerse registros de acciones relevantes.
Ejemplo:
QUIÉN
QUÉ
CUÁNDO
SOBRE QUÉ
RESULTADO
Los niveles de auditoría deberán adaptarse a la criticidad del sistema.
99. Interfaz del CLIENTE
Las interfaces proporcionadas podrán cambiar por razones de:
usabilidad;
mantenimiento;
seguridad;
evolución.
Un cambio puramente visual que no reduzca materialmente el servicio no constituye por sí solo un incumplimiento.
100. Integraciones experimentales
Una integración que dependa de:
API beta;
producto preview;
proveedor experimental;
tecnología no estable;
podrá clasificarse como experimental y quedar sujeta adicionalmente a:
18 — Beta Terms.
101. Uso ilícito
ACCIÓN DIGITAL no estará obligada a implementar o mantener automatizaciones destinadas a:
fraude;
spam;
phishing;
acceso no autorizado;
manipulación ilícita;
vulneración de derechos;
evasión de restricciones legales.
Será aplicable la:
11 — Acceptable Use Policy.
102. Suspensión preventiva
ACCIÓN DIGITAL podrá suspender una automatización cuando exista una sospecha razonable de que continuar ejecutándola puede provocar:
pérdida relevante de datos;
fraude;
daños a terceros;
incumplimiento legal;
deterioro significativo de infraestructura;
propagación de un incidente.
La suspensión deberá limitarse, cuando resulte viable, al componente afectado.
103. Investigación posterior
Tras una suspensión preventiva podrá realizarse:
1. diagnóstico;
2. identificación de causa;
3. corrección;
4. validación;
5. reactivación.
La prioridad dependerá del SLA contratado.
104. Cambios de alcance por seguridad
Una vulnerabilidad o requisito de seguridad puede hacer necesario modificar una arquitectura.
Los cambios imprescindibles para cumplir las obligaciones asumidas por ACCIÓN DIGITAL se gestionarán conforme al contrato.
Las mejoras adicionales no incluidas podrán presupuestarse separadamente.
105. Límites de responsabilidad
La responsabilidad relacionada con sistemas y automatizaciones se regirá por las limitaciones establecidas en las:
Condiciones Generales de Servicios Tecnológicos.
Estas Condiciones no amplían por sí solas el límite económico general allí establecido salvo pacto escrito específico.
106. Responsabilidad por instrucciones
ACCIÓN DIGITAL no responderá por consecuencias directamente derivadas de una instrucción válida del CLIENTE cuando:
se haya ejecutado correctamente;
el CLIENTE estuviera adecuadamente autorizado;
ACCIÓN DIGITAL no tuviera motivos razonables para considerar manifiestamente ilegal o técnicamente peligrosa dicha instrucción.
107. Riesgos advertidos
Cuando ACCIÓN DIGITAL documente un riesgo y recomiende una medida razonable y el CLIENTE decida expresamente no aplicarla, dicha decisión deberá tenerse en cuenta para determinar responsabilidades respecto de los daños directamente relacionados con el riesgo rechazado.
108. Prohibición de garantías implícitas
No deberán considerarse asumidas garantías técnicas que no consten expresamente.
En particular, no se presumirá:
exact-once;
zero downtime;
recuperación inmediata;
ausencia de duplicados;
latencia cero;
escalabilidad ilimitada;
compatibilidad perpetua;
ausencia absoluta de bugs.
109. Cambios de estas Condiciones
Las nuevas versiones se aplicarán a futuras contrataciones y renovaciones conforme a las Condiciones Generales.
No modificarán retroactivamente el alcance de proyectos cerrados salvo acuerdo válido o necesidad jurídica que así lo exija.
110. Legislación y condiciones generales
Para cualquier aspecto no regulado aquí serán aplicables:
04 — Condiciones Generales de Servicios Tecnológicos
y la legislación correspondiente.
111. 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