Contratos de mantenimiento informático: qué debe incluir el de tu empresa

La mayoría de contratos de mantenimiento informático que firman las pymes protegen más al proveedor que al cliente. Están redactados para que el proveedor siempre tenga una salida ante cualquier incumplimiento, mientras el cliente paga una cuota mensual sin poder medir si está recibiendo lo que contrató. El SLA que parece comprometido tiene definiciones tan vagas que nunca se incumple formalmente. El alcance que parece amplio tiene exclusiones suficientes para rechazar la mitad de las peticiones.

No es necesariamente mala fe del proveedor: es que redactar un contrato que te proteja como cliente requiere saber qué cláusulas pedir. Esta guía describe las seis secciones que un contrato de mantenimiento IT debe tener para que sea útil para quien lo paga, con las preguntas concretas que hay que hacer antes de firmarlo.

1. SLA con penalizaciones reales

El SLA (Service Level Agreement) es la parte del contrato que más se negocia y la que más frecuentemente resulta inútil en la práctica. Un SLA sin consecuencias por incumplimiento es una declaración de intenciones, no un compromiso. Las cuatro preguntas que definen si el SLA es real:

• ¿Cuáles son los tiempos de primera respuesta por tipo de incidencia? El contrato debe definir al menos cuatro categorías: crítica (sistema de producción caído, brecha de seguridad), alta (servicio degradado que afecta a varios usuarios), media (problema de un usuario que no puede esperar), baja (tarea no urgente, petición de cambio). Con tiempos concretos en horas, no en "lo antes posible".
• ¿Cuáles son los tiempos de resolución objetivo, distintos de los tiempos de respuesta? Responder en una hora y resolver en tres días no es aceptable para una incidencia crítica. El tiempo de resolución es el que determina el impacto real en el negocio.
• ¿Cuál es la penalización concreta por incumplimiento? Descuento en la factura del mes, horas adicionales sin cargo, crédito para el período siguiente. Sin penalización concreta, el proveedor no tiene incentivo para cumplir el SLA.
• ¿Cuál es el protocolo para incidencias críticas fuera del horario de cobertura? Un sistema crítico que cae el viernes a las 21:00 no puede esperar al lunes por la mañana. Si el servicio es solo 8x5, el contrato debe definir qué ocurre en ese escenario y a qué número llamar en emergencia.

La verificación práctica de si el SLA es real: pide al proveedor métricas de cumplimiento de SLA de los últimos 6 meses con clientes actuales de perfil similar al tuyo. Un proveedor con servicio real puede mostrar esos datos. Uno que no los tiene o se niega a compartirlos probablemente no está cumpliendo el SLA con regularidad. Para una comparativa de lo que ofrece el mercado, el artículo sobre cómo elegir proveedor IT externo describe las preguntas que mejor filtran la calidad real del servicio.

2. Alcance del servicio: qué incluye y qué no

La mayor fuente de disputas en los contratos IT es el alcance ambiguo. "Mantenimiento de sistemas informáticos" puede significar cualquier cosa desde resolver cualquier problema de cualquier equipo y software hasta limitarse a responder a las llamadas de soporte sin gestión proactiva ninguna. El contrato debe ser específico.

Lo que debe estar explícito en el alcance incluido:

• Inventario de sistemas cubiertos: número de equipos (con posibilidad de actualizar el número si cambia), lista de servidores, switches, firewalls, NAS, impresoras de red, y cualquier otro dispositivo gestionado.
• Tipo de incidencias cubiertas: hardware, software, usuario final (no sabe cómo usar una aplicación), configuración de sistemas, instalación de nuevos equipos.
• Tareas proactivas incluidas: actualizaciones de seguridad, revisión de backups, monitoring de sistemas, revisión mensual de logs de seguridad, mantenimiento preventivo de equipos.
• Aplicaciones específicas soportadas: Microsoft 365, el ERP de la empresa, el software específico del sector. Si el proveedor no da soporte a tu aplicación de gestión principal, que conste por escrito y define quién lo da.
• Modalidad del soporte: remoto exclusivamente, o con visitas a la oficina en qué condiciones (incluidas en la tarifa o con coste adicional).

Lo que está excluido también debe estar explícito. Si el proveedor no cubre el software de contabilidad porque es de un proveedor externo, que conste por escrito. Si las visitas para instalación de hardware nuevo tienen coste adicional, que el precio esté definido. Sin exclusiones explícitas, cada petición que el proveedor no quiere gestionar dentro de la tarifa se convierte en una negociación.

3. Comparativa de tipos de contrato de mantenimiento IT

4. Escalado de incidencias y gestión de problemas

Define qué ocurre cuando el nivel de primer soporte no puede resolver una incidencia en el tiempo comprometido. Sin un proceso de escalado definido, las incidencias complejas quedan atascadas en el primer nivel indefinidamente, con el cliente esperando actualizaciones que no llegan y sin claridad sobre quién está trabajando en el problema.

El proceso de escalado debe definir: cuándo se escala (tiempo o condición específica que activa el escalado), a quién se escala (técnico senior, especialista, proveedor de software), en cuánto tiempo se ejecuta el escalado, y quién comunica el estado al cliente durante el proceso. El interlocutor del proveedor en cada nivel debe estar identificado por nombre o por rol, no por un número genérico de soporte que puede rebotar entre personas.

La gestión de problemas (distinción con gestión de incidencias) también debe estar cubierta: cuando una incidencia se repite tres veces en el mismo sistema en un mes, eso no es solo una incidencia recurrente, es un problema que requiere análisis de causa raíz. El contrato debe definir si el proveedor tiene la obligación de hacer ese análisis y de proponer soluciones preventivas cuando detecta patrones repetidos.

5. Propiedad de datos y documentación de infraestructura

Cuando termina la relación con el proveedor, ¿qué te llevas y qué se queda con él? Esta sección es la que más se negocia mal y la que más problemas genera en el cambio de proveedor. Los datos son legalmente siempre de tu empresa, pero sin cláusulas contractuales explícitas, el proveedor puede retener documentación técnica y credenciales en sus propias herramientas, lo que hace muy difícil el cambio.

Lo que el contrato debe garantizar explícitamente: acceso permanente a toda la documentación de tu infraestructura en un formato portable (no solo dentro de las herramientas internas del proveedor), credenciales de todos los sistemas bajo gestión en un gestor de contraseñas al que tú tienes acceso o que se te entrega si termina la relación, propiedad explícita de todos los datos alojados en sistemas gestionados por el proveedor, y la obligación del proveedor de entregar toda esa información en un plazo máximo definido (5-10 días laborables) al finalizar el contrato.

Una señal de alerta en la negociación: el proveedor que se niega a incluir la entrega de documentación en el contrato o que pone condiciones a esa entrega. Un proveedor que trabaja bien no necesita retener documentación como mecanismo de fidelización porque su servicio es lo que fideliza al cliente. Para verificar que el inventario de tu infraestructura está correctamente documentado, el artículo sobre inventario de activos IT describe qué debe incluirse en esa documentación.

6. Condiciones de terminación y transición asistida

La cláusula de terminación define cómo termina la relación cuando cualquiera de las partes lo decide. Un preaviso de 30-60 días es razonable para contratos de mantenimiento IT. Los contratos de permanencia obligatoria de 2-3 años son excesivos: la tecnología cambia, las necesidades cambian, y quedar atrapado durante años con un proveedor inadecuado es un riesgo real que no necesitas asumir.

La transición asistida es la cláusula más importante y la más frecuentemente ausente. Define la obligación del proveedor de cooperar activamente durante el periodo de transición al nuevo proveedor: entrega de documentación técnica completa en formato legible por el nuevo proveedor, transferencia de accesos y credenciales, disponibilidad mínima para responder preguntas técnicas del nuevo proveedor durante un periodo de 15-30 días, y comunicación coordinada con el cliente durante todo el proceso.

Sin esta cláusula, el cambio de proveedor puede convertirse en una pesadilla: el proveedor saliente no coopera, el nuevo proveedor no tiene información suficiente, el cliente queda en medio sin soporte funcional durante semanas. Esta situación es más habitual de lo que parece, especialmente cuando la terminación ocurre en malos términos. La transición bien ejecutada requiere que el nuevo proveedor pueda verificar que tiene acceso a todos los sistemas antes de que el anterior se desconecte. Para planificar una transición correcta, los servicios de mantenimiento informático incluyen protocolos de transición tanto de entrada como de salida.

7. Caso real: cambio de proveedor sin cláusula de transición

Una distribuidora de material de construcción de Murcia con 16 empleados y servidores locales decidió cambiar de proveedor IT tras dos años de servicio insatisfactorio. El proveedor saliente no tenía ninguna obligación contractual de cooperar en la transición: el contrato solo decía "30 días de preaviso y fin del servicio".

El proveedor saliente, ante la pérdida del cliente, no respondió las llamadas del nuevo proveedor durante las primeras dos semanas. No entregó la documentación de los servidores. Las contraseñas del servidor principal estaban solo en su gestor de contraseñas interno, al que el nuevo proveedor no tenía acceso. El acceso al panel de DNS del dominio estaba registrado a nombre del técnico del proveedor saliente, que no respondía los mensajes.

El resultado: tres semanas de caos parcial, con el nuevo proveedor teniendo que reconstruir la configuración del servidor mediante acceso de emergencia con contraseñas de recuperación, la recuperación del dominio a través del registrador requirió una semana de trámites, y la empresa estuvo sin soporte IT efectivo durante ese período. El coste estimado en horas del equipo interno y del nuevo proveedor en gestionar la transición fue superior a 2.000 euros. Con una cláusula de transición asistida bien redactada, todo ese proceso habría tomado una semana de forma ordenada.

Por dónde empezar mañana

1. Lee el contrato actual con el proveedor IT y busca las cinco cláusulas: SLA con penalizaciones, alcance explícito, escalado de incidencias, propiedad de documentación y credenciales, condiciones de terminación y transición. Si alguna no existe o es ambigua, tienes una brecha en la protección como cliente.
2. Verifica que tienes acceso a la documentación de tu infraestructura: inventario de equipos, diagrama de red, configuraciones de servidores y firewalls. Si esa documentación está solo en los sistemas del proveedor y no tienes copia, pídela ahora, sin esperar a un cambio de proveedor.
3. Verifica que tienes acceso a las credenciales de los sistemas críticos: servidor, router, firewall, panel de DNS del dominio, Microsoft 365 administrador. Si alguna de esas credenciales está solo en poder del proveedor, solicita acceso esta semana. Si el proveedor se niega o pone obstáculos, eso es información relevante sobre la relación.
4. Si estás evaluando un contrato nuevo, negocia la inclusión de las cláusulas de propiedad de documentación y transición asistida antes de firmar. Los proveedores serios no tienen problema en incluirlas porque saben que su servicio es lo que mantiene al cliente, no la retención de información.

Preguntas frecuentes