Legal advisory para IT

Guía de auditoría legal para empresas IT: qué revisar en licencias, SOW y anexos

Tema Licencias de software, SOW y compliance contractual
Enfoque Revisión documental y riesgos legales
Lectura 12 min

Una auditoría legal bien hecha no se limita a “tener documentos”. Para licencias y contratos de servicios, revisa coherencia entre el licenciamiento, el alcance (SOW) y los anexos que aterrizan entregables, restricciones de uso, garantías y responsabilidades.

Volver al Blog Ver artículos destacados
Checklist rápida (para empezar la auditoría)
  • Licencias: tipo, territorio, duración, condiciones de uso y sublicencias.
  • SOW: alcance, supuestos, entregables, criterios de aceptación y cambios.
  • Anexos: tratamiento de datos, confidencialidad, garantías y limitaciones de responsabilidad.
  • Trazabilidad: que no existan contradicciones entre contrato marco, SOW y anexos.

Este contenido es orientación general para empresas IT. Para decisiones concretas, revisa tu caso con asesoría legal.

Por qué una revisión legal de licencias, SOW y anexos evita sobrecostes y bloqueos

En proyectos digitales, la parte legal no es un apéndice. Licencias mal descritas, SOW con entregables ambiguos o anexos que contradicen el contrato marco suelen convertirse en fricción durante el despliegue, en reclamaciones por incumplimiento, o en discusiones sobre alcance y uso. Una auditoría legal bien enfocada reduce riesgos operativos y aporta trazabilidad: qué se autorizó, bajo qué condiciones y para qué finalidad.

1) Licencias: revisa el “derecho de uso” antes que el nombre del software

Empieza identificando la naturaleza del permiso. No basta con saber qué producto “es” (software, SaaS, librerías, contenidos). Lo importante es el alcance de uso: quién puede usar, en qué entorno, con qué límites, y cómo se transfiere o subcontrata el uso.

  • Alcance por entidad: ¿la licencia está concedida a la empresa cliente, a la proveedora o a ambas? ¿aplica por filial, por ubicación, o por usuarios?
  • Alcance técnico: ¿se permite el uso en entornos cloud/on-prem? ¿hay restricciones por sistema operativo, región, o tipo de infraestructura?
  • Usuarios y roles: ¿está limitado a usuarios finales, equipos técnicos, administradores, o cuentas de servicio? ¿hay límites de “asientos” o de instancias?
  • Derechos sobre modificaciones: ¿se permite configuración, adaptación, scripts, integraciones o extensiones? ¿qué pasa con cambios derivados?
  • Subprocesadores y terceros: si hay subcontratistas, ¿la licencia permite su intervención? ¿se exige notificación o autorización previa?
  • Transferencia y reventa: si existe reventa, cesión o “paso” de licencias, revisa condiciones y formalidades. Evita asumir que la licencia es transferible.

2) SOW (Statement of Work): convierte “entregable” en un objeto verificable

El SOW es donde se materializa el trabajo. Si no defines criterios verificables, cualquier aceptación puede discutirse. La auditoría debe validar que el SOW se conecta de forma coherente con el contrato y que no introduce responsabilidades fuera de lo acordado.

  • Alcance: descripción funcional y técnica suficiente para ejecutar. Si el SOW depende de “documentación adjunta”, asegúrate de que esa documentación exista y esté identificada.
  • Entregables: formato, versión, contenido mínimo, y criterios de aceptación (qué evidencia se entrega y cómo se valida).
  • Supuestos: hipótesis operativas, datos requeridos por el cliente, dependencias y condiciones previas.
  • Cambios: procedimiento de modificación del alcance. Cuándo se considera cambio, cómo se estima coste/tiempo y cómo se aprueba.
  • Calendario: hitos, ventanas de revisión, y plazos realistas para pruebas y ciclos de corrección.
  • Interfaz legal: referencias cruzadas al contrato marco, SLA/soporte (si aplica) y anexos técnicos o de seguridad.

3) Anexos: detecta contradicciones, “zonas grises” y derechos no expresados

Los anexos suelen concentrar lo delicado: seguridad, protección de datos, licencias complementarias, documentación de uso, o condiciones de incorporación de terceros. Durante la auditoría, realiza una lectura comparativa entre contrato, SOW y anexos para localizar incoherencias.

Recomendación de auditoría

Busca explícitamente cláusulas que limiten el uso, definiciones que cambian entre documentos, y anexos que introducen obligaciones fuera del cuerpo principal.

  • Jerarquía documental: qué documento prevalece si hay conflicto.
  • Definiciones: términos clave (entregable, entorno, usuario, servicio, datos, desarrollo) deben ser consistentes.
  • Seguridad y cumplimiento: obligaciones alineadas con la operación del proveedor (y no solo con promesas genéricas).
  • Propiedad y uso: qué se entrega, qué se licencia, y con qué condiciones se permite reutilizar materiales o componentes.
  • Documentación de licencias: manuales, “end user license terms”, políticas de uso y evidencia de adquisición/licenciamiento.

Cómo convertir la auditoría en un informe accionable

Una auditoría útil no se limita a “señalar riesgos”. Debe priorizar hallazgos, proponer acciones, y dejar claro el impacto. Estructura el resultado en tres capas: (1) hallazgo, (2) riesgo y (3) recomendación concreta con el documento o cláusula relacionada.

  1. Clasifica por severidad (alto, medio, bajo) según impacto en ejecución, cumplimiento y capacidad de explotación de la solución.
  2. Asocia evidencia: identificadores del documento, fecha, versión, y extracto relevante.
  3. Propón acciones: redacción sugerida, cláusula alternativa o requisito operativo (por ejemplo, obtener confirmación de sublicencia).
  4. Planifica responsables y plazos: quién debe corregir, cuándo se valida y qué decisión requiere aprobación.

Errores frecuentes en empresas IT

  • Asumir que el contrato marco “cubre todo”, sin revisar licencias específicas y anexos de uso.
  • Confundir SOW y anexos técnicos como equivalentes, cuando uno fija aceptación y el otro fija requisitos.
  • Ignorar restricciones de subprocesamiento: si la operación real incluye terceros, la autorización legal debe reflejarlo.
  • Dejar criterios de aceptación sin medios de verificación, lo que debilita la posición durante la conformidad final.