Servicio
Disponibilidad, mantenimiento, soporte, incidentes y capacidad.
Public Procurement Guide
Contratación Pública de Tecnología
Contratar tecnología exige traducir una necesidad pública en arquitectura, niveles de servicio, derechos sobre datos, pruebas, transición y salida. Comprar componentes sin diseñar el ciclo de vida puede convertir una adjudicación correcta en una implementación inviable.
Por Rodrigo RomeroÚltima revisión jurídica:
01
Contratar una capacidad, no una lista de piezas
La entidad debe definir usuarios, procesos, volúmenes, integraciones, datos, seguridad, disponibilidad, soporte y evolución. Las marcas o especificaciones aisladas no explican cómo funcionará el servicio completo ni cómo será aceptado.
- Estado actual, objetivo y arquitectura de referencia.
- Requisitos funcionales, no funcionales y de operación.
- Dependencias de conectividad, identidad, datos y terceros.
- Modelo de servicio, licenciamiento, consumo y escalabilidad.
- Pruebas, migración, puesta en producción y estabilización.
02
Nube, SaaS y servicios administrados
El contrato debe reflejar que el servicio cambia, consume recursos y depende de infraestructura compartida. Deben definirse métricas, límites, cambios, soporte, subprocesadores, localización o transferencias de datos y condiciones de terminación.
Datos
Titularidad, acceso, tratamiento, respaldo, retención y devolución.
Economía
Usuarios, consumo, incrementos, servicios adicionales y costo de salida.
Cambio
Actualizaciones, deprecación, roadmap, compatibilidad y notificación.
03
Continuidad y ciberseguridad contractual
Una cláusula genérica de seguridad no distribuye responsabilidades. Deben alinearse controles, notificación de incidentes, cooperación, evidencia, recuperación y continuidad con el riesgo del servicio.
- Roles de seguridad y matriz de responsabilidad compartida.
- Requisitos de acceso, registro, vulnerabilidades y terceros.
- Notificación, contención, investigación y comunicación de incidentes.
- RTO, RPO, respaldos, pruebas y recuperación.
- Continuidad del proveedor y transición ante terminación.
04
Propiedad intelectual e interoperabilidad
Deben distinguirse software preexistente, desarrollos específicos, configuraciones, documentación, datos, modelos, conectores y componentes de terceros. La entidad necesita derechos suficientes para operar y evolucionar, sin exigir transferencias innecesarias que reduzcan competencia.
- Licencias, usuarios, territorio, plazo y restricciones.
- Derechos sobre entregables y componentes preexistentes.
- APIs, formatos, documentación e interoperabilidad.
- Código fuente o escrow solo cuando el riesgo lo justifique.
- Transferencia de conocimiento y capacidad de mantener.
05
Exit plan y vendor lock-in
La salida se diseña al entrar. Un proveedor puede cumplir durante años y aun así dejar una transición costosa si los datos no son portables, las configuraciones no están documentadas o las licencias bloquean continuidad.
- 01
Inventariar
Datos, configuraciones, integraciones, documentación, activos y dependencias.
- 02
Portar
Formatos, medios, APIs, calidad y validación de extracción.
- 03
Transferir
Conocimiento, accesos, soporte y cooperación con sucesor.
- 04
Continuar
Servicio durante transición y gestión de riesgos.
- 05
Cerrar
Borrado, certificaciones, revocación, activos y obligaciones sobrevivientes.
Control editorial
Revisión y fuentes oficiales
Última revisión jurídica: .
Este contenido ofrece información general. La norma, los criterios administrativos, los documentos y los términos aplicables deben revalidarse para el procedimiento concreto y la fecha de actuación.
Texto Único de la Ley 22 de 2006 y su reglamentación
Compilación oficial publicada por la Dirección General de Contrataciones Públicas, incluyendo el Decreto Ejecutivo 439 de 2020 y sus modificaciones incorporadas.
Consultar fuente oficialSistema Electrónico PanamaCompra
Portal oficial para consultar actos públicos, documentos, publicaciones y actuaciones asociadas a cada procedimiento.
Consultar fuente oficialBiblioteca Sistematizada de Pronunciamientos de la DGCP
Criterios administrativos oficiales que deben seleccionarse y revisarse según la materia, etapa y hechos del caso concreto.
Consultar fuente oficialPreguntas frecuentes
Antes de comenzar.
¿La firma implementa la plataforma?
La práctica se concentra en estrategia, requerimientos, procurement, contratos, gobierno, riesgo y acompañamiento vendor-neutral; no se presenta como integrador o fábrica de software.
¿La nube debe prohibirse por tratarse de datos públicos?
No existe una respuesta universal. Deben evaluarse clasificación, régimen aplicable, arquitectura, seguridad, residencia, transferencias, continuidad y controles contractuales.
¿Un SLA alto garantiza continuidad?
No. Deben revisarse la forma de medición, exclusiones, remedios, recuperación, dependencias y capacidad de salida.
Evaluación preliminar
¿Necesita evaluar una contratación pública?
Podemos revisar el problema, la etapa, la documentación disponible y el siguiente paso responsable.