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.
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: .
Esta guía 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.