En la práctica habitual de PyMEs argentinas, buena parte de los servicios de IT se contrata con poca formalidad: un presupuesto por WhatsApp, una aprobación verbal, un email confirmando “dale, arrancá”. Funciona mientras hay confianza y las cosas salen bien. Deja de funcionar apenas aparece una diferencia interpretativa.
“Me dijiste que incluía el servidor.” “Pensé que eso se cobraba aparte.” “¿Cuánto tardás en responder cuando algo se rompe?” “Al cambiar de proveedor, ¿quién se queda con las contraseñas?” Las respuestas a esas preguntas, cuando aparecen en una discusión, dependen de lo que cada parte recordaba (o entendió en su momento). Sin un acuerdo escrito, no hay árbitro.
Un contrato de servicios IT no tiene que ser un documento legal pesado. Puede ser un acuerdo de 3 a 6 páginas, escrito en lenguaje claro, que responda las preguntas clave antes de que aparezcan como conflicto. Ese mismo documento protege al cliente (que sabe qué esperar) y al proveedor (que sabe qué se comprometió a entregar y qué no).
Las siete cláusulas que no deberían faltar
1. Alcance del servicio
Qué cosas están incluidas y qué cosas no. Muy importante ser específico. “Soporte de sistemas” es demasiado amplio; el conflicto es inevitable.
Mejor: “Soporte remoto y presencial para los equipos informáticos detallados en el Anexo I. Incluye: resolución de incidentes, configuración de software estándar, gestión de usuarios, mantenimiento preventivo. No incluye: proyectos de migración, implementación de nuevos sistemas, desarrollo de aplicaciones, instalaciones en nuevas ubicaciones. Estos se cotizan por separado.”
El Anexo I debería detallar los equipos cubiertos (cantidad, identificación), y actualizarse cuando cambie.
2. Paquete de horas y modalidad
Si el servicio es por abono mensual con horas prepagadas, dejar claro:
– Cantidad de horas mensuales incluidas.
– Qué incluyen esas horas (monitoreo, incidentes, mantenimiento, etc.).
– Qué pasa si un mes se superan: ¿se facturan adicionales? ¿a qué valor? ¿se consumen del mes siguiente?
– Qué pasa si un mes sobran: ¿se acumulan para el siguiente? ¿se pierden?
– Diferencia entre horas comerciales y horas fuera de horario o fines de semana.
Esta sola cláusula elimina muchas discusiones típicas sobre “ese tiempo no contaba”.
3. Tiempos de respuesta
Qué significa “responder ante un incidente” y cuánto se tarda. Ejemplos razonables para un abono típico de PyME:
– Incidente crítico (sistema operativo caído, pérdida de conectividad total): respuesta en 1-2 horas.
– Incidente alto (un usuario sin poder trabajar): 4 horas.
– Incidente medio (problema que permite seguir trabajando con limitaciones): 1 día hábil.
– Incidente bajo (consulta o mejora): 3 días hábiles.
Con horarios de cobertura claros: por ejemplo “lunes a viernes, 9 a 18 horas”. Fuera de ese horario, se define si hay guardia y a qué costo.
4. Confidencialidad y tratamiento de datos
El proveedor, al prestar el servicio, accede a información sensible: datos de clientes, finanzas, contratos internos. El contrato debería establecer:
– Compromiso de confidencialidad sobre toda la información conocida en el marco del servicio.
– Prohibición de usar esa información para otros fines.
– Obligación de no compartirla con terceros sin autorización expresa.
– En caso de terminar el contrato, devolución o destrucción de datos que el proveedor tuviera en sus sistemas.
Es una cláusula corta pero fundamental, en particular si la empresa tiene datos alcanzados por la Ley 25.326 (clínicas, estudios contables, cualquier negocio que tenga datos personales de clientes).
5. Propiedad de la documentación y contraseñas
Quién es dueño de lo que se genera durante el servicio: inventarios, mapas de red, documentación de configuraciones, contraseñas de sistemas del cliente.
La regla sana: todo lo que se genera en el marco del servicio pertenece al cliente. El proveedor puede tener copia de trabajo, pero la copia autoritativa queda en la empresa. Las contraseñas deben estar accesibles para el cliente en un gestor compartido, no solo en la computadora del proveedor.
Esto evita el escenario clásico donde, al querer cambiar de proveedor, la empresa descubre que no tiene acceso a contraseñas críticas o a la documentación de cómo está armada su propia infraestructura.
6. Salida y transición
Qué pasa cuando el contrato termina, por cualquier motivo (decisión del cliente, del proveedor, vencimiento natural):
– Plazo de aviso previo (30-60 días típicamente).
– Obligación del proveedor de entregar toda la documentación, contraseñas, inventarios, y cualquier dato técnico relevante.
– Período de transición durante el cual el proveedor colabora con el sucesor si lo hubiera.
– Devolución de información que el proveedor tuviera guardada.
– Conservación de datos: ¿el proveedor los borra de sus sistemas?, ¿cuándo?, ¿cómo se acredita?
Esta es, con diferencia, la cláusula menos atendida y la que genera más problemas después.
7. Responsabilidad y límites
Qué responsabilidad asume el proveedor si algo sale mal. Esto es delicado: un proveedor no puede asumir responsabilidad ilimitada por daños que exceden por mucho el valor del servicio prestado. Pero algo de responsabilidad debe haber, al menos proporcional al contrato.
La cláusula típica: “La responsabilidad del proveedor se limita al monto pagado por el servicio en los últimos X meses, excluyendo daños indirectos, lucro cesante o pérdida de datos”. Y cláusulas de buen comportamiento: “El proveedor actuará con diligencia profesional razonable y aplicará buenas prácticas de la industria”.
Qué hacer si se está empezando
Si hoy la empresa no tiene acuerdos escritos con sus proveedores IT, no hace falta reemplazarlos todos de un día para el otro. Un camino práctico:
1. Elegir una plantilla base de contrato (hay modelos disponibles, o puede redactarla un abogado con conocimiento del rubro).
2. Proponérselo a los proveedores actuales como “ordenar el acuerdo que ya tenemos”. Un proveedor serio no debería objetar; de hecho, puede proponer ajustes razonables.
3. Renovar el acuerdo anualmente, con ajustes si los hubiere.
Si algún proveedor se resiste a firmar un acuerdo escrito básico, conviene tomar nota: esa resistencia es, en sí misma, información útil sobre el nivel de profesionalismo disponible.
Desde la otra perspectiva (el proveedor)
Desde el lado del proveedor, un contrato escrito también protege: aclara qué se comprometió a hacer (y qué no), establece cómo se cobran adicionales, limita exposición legal, y ordena la relación con el cliente. Un proveedor que sugiere formalizar el acuerdo no está complicando las cosas: está trabajando con seriedad.
¿Hay acuerdo escrito con el proveedor IT actual de tu empresa? Si la respuesta es “creo que hay un presupuesto de hace tiempo” o “fue todo hablado”, vale formalizarlo. Los problemas de relación comercial no suelen aparecer hasta que aparecen; cuando aparecen, tener un documento que defina las reglas ahorra tiempo y confusión.
