¿Qué debe incluir un contrato SaaS en Chile?

Según el servicio, los riesgos y las normas aplicables, normalmente conviene definir el servicio, usuarios, precio, vigencia, niveles de servicio, soporte, datos, seguridad, propiedad intelectual, subcontratación, responsabilidad, suspensión, terminación y salida. No existe una lista legal ni una plantilla única que sirva igual para un software auxiliar y una plataforma crítica.

¿Un SLA es obligatorio en todo contrato SaaS?

No existe un SLA legal único y obligatorio para todo SaaS. Si las partes ofrecen o acuerdan disponibilidad, soporte, mantenimiento o remedios, conviene definir cómo se miden, qué se excluye, quién reporta y qué ocurre ante un incumplimiento. Un SLA debe reflejar capacidades técnicas reales.

¿Quién es titular del software y qué derechos tiene cada parte sobre los datos?

Son materias distintas. La titularidad del software depende de su origen, de los vínculos laborales o encargos y de las estipulaciones aplicables. Cuando el proveedor es titular, normalmente concede una licencia o acceso. El contrato también debe precisar qué derechos tendrá cada parte sobre datos empresariales, compilaciones, configuraciones, integraciones y desarrollos específicos, sin tratar los datos personales como una propiedad general.

¿Qué debe decir el contrato sobre datos personales?

Debe reflejar quién decide las finalidades y medios, quién trata datos por instrucciones, qué categorías y finalidades existen, qué terceros participan y cómo se gestionan seguridad, derechos, conservación y salida. La Ley 19.628 está vigente y su reforma por la Ley 21.719 entra en vigor el 1 de diciembre de 2026; la preparación contractual debe considerar ambas etapas sin asumir que todos los servicios tienen el mismo rol.

¿El proveedor responde siempre por una caída o incidente?

La respuesta depende de la ley aplicable, el contrato, la causa, las obligaciones asumidas y el daño acreditado. El acuerdo puede distribuir riesgos y establecer límites o soluciones, pero no conviene negociar esas cláusulas aisladas del SLA, los controles de seguridad, las obligaciones de indemnizar y las reglas legales obligatorias que pudieran aplicar.

¿Puede el proveedor usar servicios en la nube o subcontratistas?

Puede estructurarse contractualmente. Cuando un tercero trate datos por cuenta del responsable, el encargo debe documentarse conforme a la normativa aplicable. Para otros terceros críticos, el nivel de información, autorización y responsabilidad debe definirse según el riesgo y el contrato.

¿La Ley del Consumidor se aplica a todo servicio SaaS?

No automáticamente. Debe revisarse si la relación concreta encaja en los conceptos de proveedor y consumidor y si existen reglas legales obligatorias. También debe considerarse el régimen especial que extiende determinadas normas de consumo a micro y pequeñas empresas frente a sus proveedores. Cuando corresponda, la oferta, las condiciones electrónicas, el mecanismo de aceptación, la información del servicio y las cláusulas de adhesión requieren una revisión específica.

Ref. LC·CO·SAAS

Corporativo tech · Contratos

Contratos SaaS: redacción, revisión y negociación

Traducimos el servicio, los datos, la seguridad, los niveles de servicio y la forma de terminar la relación y devolver o eliminar los datos a un contrato que pueda operar y negociarse.

El problema

Un contrato SaaS debe reflejar cómo funciona el servicio

Un contrato SaaS no se resuelve cambiando nombres en una plantilla de licencia. Debe conectar la oferta comercial con el nivel de disponibilidad que el proveedor realmente puede ofrecer, el soporte, el uso de datos, la infraestructura, las integraciones y la forma en que las partes enfrentarán una interrupción o el término del servicio.

Cuando esas capas no coinciden, el proveedor puede comprometer capacidades que no puede operar y el cliente puede asumir que cuenta con garantías, controles o derechos de salida que nunca fueron pactados. Revisamos el acuerdo desde ambas posiciones para hacer visibles esas diferencias antes de la firma o renovación.

El trabajo no certifica que una plataforma sea segura ni reemplaza una evaluación técnica. Convierte decisiones comerciales, técnicas y jurídicas verificables en obligaciones, límites, responsables y mecanismos de seguimiento comprensibles.

Señales de alerta

Cuándo conviene actuar.

Señal 01
La orden de compra, la propuesta comercial, los términos de servicio y el anexo de datos contienen condiciones distintas.
Señal 02
El SLA promete disponibilidad, créditos o tiempos de respuesta que no han sido validados por operaciones.
Señal 03
La plataforma trata datos personales, pero no están claros los roles, instrucciones, subcontratistas que también usan datos (subencargados) ni reglas de devolución o eliminación.
Señal 04
El contrato confunde la titularidad del software con los derechos que tendrá cada parte sobre los datos o los desarrollos adicionales.
Señal 05
No existe un procedimiento concreto para incidentes, suspensión, continuidad, terminación o asistencia de salida.
Señal 06
La negociación se concentra en el límite de responsabilidad sin identificar antes los riesgos y obligaciones que ese límite cubriría.

Alcance

Qué incluye el trabajo de Legalcore

El alcance final se define después de revisar antecedentes. Estos son los frentes que normalmente ordenamos.

Servicio y reglas de uso

Definimos el servicio contratado, usuarios, ambientes, exclusiones, dependencias, integraciones, implementación y reglas de uso aceptable.

Nivel de servicio (SLA) y soporte

Ordenamos métricas de disponibilidad, exclusiones, mantenimiento, severidades, canales, horarios, escalamiento, tiempos objetivo y créditos cuando se acuerden.

Datos y privacidad

Delimitamos roles, finalidades e instrucciones; revisamos derechos, conservación, devolución, eliminación, subcontratistas que también usan datos (subencargados) y transferencias según los tratamientos reales.

Seguridad e incidentes

Conectamos los controles que el proveedor efectivamente puede sostener con deberes de colaboración, evidencia, notificación contractual y respuesta a incidentes.

Propiedad intelectual y licencias

Separamos software preexistente, licencia de acceso, documentación, datos del cliente, configuraciones, integraciones y desarrollos específicos.

Proveedores y subcontratación

Revisamos el uso de servicios de infraestructura en la nube y terceros críticos, el estándar de responsabilidad aplicable y los mecanismos de información o cambio que convenga pactar.

Precio y evolución del servicio

Alineamos cobro, impuestos, reajustes, renovación, cambios de plan, uso excedente y procedimiento para modificar funcionalidades o términos.

Responsabilidad y soluciones ante incumplimientos

Negociamos declaraciones, obligaciones de indemnizar, límites, exclusiones, seguros y soluciones contractuales según los riesgos identificados, sin asumir que existe una fórmula universal.

Continuidad, término y salida

Definimos suspensión, causales de término, transición, formato y ventana de exportación, eliminación, asistencia de salida y costos asociados cuando correspondan.

Antecedentes

Qué necesitamos para empezar

Borrador de contrato, términos de servicio, orden de compra, propuesta y anexos que estén en negociación.
Descripción funcional del producto, planes, usuarios, integraciones, límites de uso y exclusiones relevantes.
SLA y matriz de soporte operables: métricas, mantenimiento, severidades, horarios, escalamiento y remedios ofrecidos.
Mapa básico de datos y proveedores: categorías, finalidades, ubicaciones, infraestructura, subencargados y plazos de conservación.
Controles de seguridad que puedan respaldarse, procedimiento de incidentes y materiales entregados a clientes.
Modelo comercial: precios, renovación, reajustes, consumo adicional, descuentos y compromisos de permanencia.
Requisitos de continuidad, exportación, migración o eliminación al término, desde la perspectiva técnica y de negocio.

Si no tienes todo, partimos con lo disponible y dejamos visible qué falta. No envíes claves ni información sensible por un canal no acordado.

Riesgos

Riesgos de postergar la decisión

Vender o contratar un servicio distinto del que describen la propuesta, el producto y sus anexos.
Disputas por caídas, soporte o créditos cuando las métricas y exclusiones del SLA son ambiguas.
Tratar o subcontratar datos sin roles, instrucciones, controles y mecanismos de salida suficientemente definidos.
Ceder por error software, desarrollos o derechos sobre datos, o recibir una licencia insuficiente para el uso esperado.
Mantener renovaciones, reajustes, suspensiones o cambios unilaterales difíciles de aplicar o cuestionables para el tipo de cliente.
Quedar sin acceso oportuno a datos y configuraciones al terminar, aumentando el costo y riesgo de migración.

Proceso

Cómo trabajamos

Al terminar cada etapa sabrás qué se decidió, quién debe actuar y qué documento recibirás.

01
Delimitar la posición y el negocio
Confirmamos si representamos al proveedor o al cliente, qué se contrata, cuán crítico es y qué puntos comerciales ya están acordados.
Resultado de la etapa
Ficha de alcance, documentos aplicables, prioridades y responsables por validar.
02
Levantar la operación real
Contrastamos el borrador con producto, soporte, seguridad, privacidad, facturación y salida para detectar promesas o vacíos operativos.
Resultado de la etapa
Matriz de brechas, preguntas y decisiones pendientes por área.
03
Redactar o revisar
Preparamos el contrato y sus anexos, o marcamos el texto de la contraparte con explicaciones y alternativas negociables.
Resultado de la etapa
Borrador o versión comentada, más un registro de riesgos y supuestos.
04
Negociar con mandato claro
Priorizamos puntos críticos, qué puede ceder cada parte y las alternativas antes de intercambiar versiones o participar en reuniones.
Resultado de la etapa
Posición de negociación, control de cambios y acuerdos por cerrar.
05
Cerrar y activar
Revisamos consistencia entre contrato, anexos y propuesta, y dejamos visibles obligaciones, fechas y responsables posteriores a la firma.
Resultado de la etapa
Paquete contractual final y ficha de obligaciones para la operación.

Alcance y presupuesto

Entregables, tiempos y honorarios

Antes de empezar, la propuesta indicará qué incluye el servicio, quién participa, cómo trabajaremos y cuánto costará.

Entregables

Contrato SaaS nuevo o versión revisada con control de cambios.
Anexo de niveles de servicio y soporte, cuando forme parte del encargo.
Anexo de tratamiento de datos ajustado a los roles y flujos informados.
Cláusulas de seguridad, incidentes y subcontratación coherentes con la operación validada.
Matriz de riesgos, posiciones de negociación y decisiones pendientes.
Versión final limpia y cuadro de consistencia entre documentos contractuales.
Ficha de obligaciones, hitos, renovaciones, responsables y próximos pasos.

Plazos estimados

Como referencia, una revisión acotada suele planificarse en 5 a 10 días hábiles y una redacción integral en 10 a 20 días hábiles desde que contamos con antecedentes suficientes. La negociación con la contraparte se estima por etapas y no tiene un plazo garantizable.

Puede variar según

— Complejidad, criticidad y nivel de personalización del servicio.
— Cantidad y consistencia de contratos, anexos y políticas involucrados.
— Disponibilidad de equipos de producto, seguridad, privacidad y finanzas para validar.
— Número de versiones, reuniones y tiempos de respuesta de la contraparte.
— Necesidad de coordinar legislación extranjera o asesores de otra jurisdicción.

Cómo se cobran los honorarios

Revisión

Honorario fijo por documento y alcance definidos, con una versión comentada y reunión de cierre; las rondas adicionales se cotizan o incorporan expresamente.

Redacción

Honorario por proyecto para contrato base y anexos acordados, sujeto al levantamiento previo del producto, la operación y los flujos de datos.

Negociación

Bolsa de horas, tarifa por hora o etapas cerradas según el número esperado de versiones, reuniones y contrapartes.

El precio depende del alcance de cada caso. Recibirás una cotización antes de comenzar.

Preguntas frecuentes

Lo que conviene aclarar primero

¿Qué debe incluir un contrato SaaS en Chile?: Según el servicio, los riesgos y las normas aplicables, normalmente conviene definir el servicio, usuarios, precio, vigencia, niveles de servicio, soporte, datos, seguridad, propiedad intelectual, subcontratación, responsabilidad, suspensión, terminación y salida. No existe una lista legal ni una plantilla única que sirva igual para un software auxiliar y una plataforma crítica.
¿Un SLA es obligatorio en todo contrato SaaS?: No existe un SLA legal único y obligatorio para todo SaaS. Si las partes ofrecen o acuerdan disponibilidad, soporte, mantenimiento o remedios, conviene definir cómo se miden, qué se excluye, quién reporta y qué ocurre ante un incumplimiento. Un SLA debe reflejar capacidades técnicas reales.
¿Quién es titular del software y qué derechos tiene cada parte sobre los datos?: Son materias distintas. La titularidad del software depende de su origen, de los vínculos laborales o encargos y de las estipulaciones aplicables. Cuando el proveedor es titular, normalmente concede una licencia o acceso. El contrato también debe precisar qué derechos tendrá cada parte sobre datos empresariales, compilaciones, configuraciones, integraciones y desarrollos específicos, sin tratar los datos personales como una propiedad general.
¿Qué debe decir el contrato sobre datos personales?: Debe reflejar quién decide las finalidades y medios, quién trata datos por instrucciones, qué categorías y finalidades existen, qué terceros participan y cómo se gestionan seguridad, derechos, conservación y salida. La Ley 19.628 está vigente y su reforma por la Ley 21.719 entra en vigor el 1 de diciembre de 2026; la preparación contractual debe considerar ambas etapas sin asumir que todos los servicios tienen el mismo rol.
¿El proveedor responde siempre por una caída o incidente?: La respuesta depende de la ley aplicable, el contrato, la causa, las obligaciones asumidas y el daño acreditado. El acuerdo puede distribuir riesgos y establecer límites o soluciones, pero no conviene negociar esas cláusulas aisladas del SLA, los controles de seguridad, las obligaciones de indemnizar y las reglas legales obligatorias que pudieran aplicar.
¿Puede el proveedor usar servicios en la nube o subcontratistas?: Puede estructurarse contractualmente. Cuando un tercero trate datos por cuenta del responsable, el encargo debe documentarse conforme a la normativa aplicable. Para otros terceros críticos, el nivel de información, autorización y responsabilidad debe definirse según el riesgo y el contrato.
¿La Ley del Consumidor se aplica a todo servicio SaaS?: No automáticamente. Debe revisarse si la relación concreta encaja en los conceptos de proveedor y consumidor y si existen reglas legales obligatorias. También debe considerarse el régimen especial que extiende determinadas normas de consumo a micro y pequeñas empresas frente a sus proveedores. Cuando corresponda, la oferta, las condiciones electrónicas, el mecanismo de aceptación, la información del servicio y las cláusulas de adhesión requieren una revisión específica.

Autoría y revisión

Autor: Equipo jurídico Legalcore; Abogados autores
Revisión: Equipo jurídico Legalcore; Revisión legal

Revisado el 29 de julio de 2026. Cada contrato debe corresponder al servicio, flujo de datos, capacidad técnica y posición comercial de las partes.

Fuentes oficiales

Siguiente lectura

Servicios y guías relacionadas

Privacidad y datos

Ley 21.719: qué debería revisar primero una empresa

Antes de cambiar políticas o comprar herramientas, conviene entender qué datos trata la empresa, por qué los usa y quién interviene.

29 de julio de 20266 min

Leer guía

Siguiente paso

Revisemos tus antecedentes y definamos el próximo paso.

Cuéntanos qué necesitas revisar y qué plazo debes cuidar. Te diremos qué antecedentes faltan y si podemos ayudarte.

Solicitar revisión de contrato SaaS