Entregar el usuario y la contraseña del portal de contratación pública no es una decisión menor. Estas son las preguntas que deberías hacerle a cualquier plataforma antes de hacerlo — y cómo las responde Licitarus, con el detalle técnico.
¿Es seguro conectar tu cuenta de SECOP II a una plataforma?
Confiar es una sensación. Se construye con el diseño de la página, el tono del copy y la cara de quien te lo vende, y ninguna de esas tres cosas dice nada sobre lo que pasa con tu contraseña después de que le das clic a "conectar".
La pregunta que sí sirve es otra: ¿qué puedo verificar? Dónde queda el dato, quién lo puede leer, qué se hace con él, qué pasa si lo retiro. Son preguntas con respuesta concreta. Una plataforma que no las pueda contestar con detalle técnico —o que responda con adjetivos— te está pidiendo que confíes sin verificar.
Este artículo hace dos cosas. Primero da esas preguntas, escritas para que las uses contra cualquier herramienta que te pida la cuenta del portal, sea Licitarus o cualquier otra. Después responde cada una para Licitarus, con el detalle suficiente para que puedas contrastarlo.
Copia esta lista y úsala como checklist. Un proveedor serio contesta las cinco sin rodeos; si alguna respuesta es vaga, ahí está el problema.
1. ¿Dónde se guarda la contraseña y con qué protección? La respuesta mínima aceptable es "cifrada". La respuesta útil dice con qué algoritmo y —más importante— dónde está la llave. Cifrar con una llave guardada en la misma base de datos protege muy poco: el escenario realista de filtración es que alguien se lleve un respaldo completo, y ahí se lleva el dato y la llave juntos.
2. ¿Quién puede leerla? No preguntes solo si el equipo de soporte puede verla. Pregunta si existe alguna pantalla, algún reporte o algún endpoint que la devuelva. Si existe, alguien la va a ver eventualmente.
3. ¿Qué se hace exactamente con la cuenta? La diferencia entre leer y escribir es la más importante de todas. Leer una bandeja es una cosa; presentar documentos en tu nombre en un portal de contratación pública es otra muy distinta. Pide la lista cerrada de acciones, no una descripción general.
4. ¿Qué pasa si desconecto? "Revocamos el acceso" puede significar que borraron el dato o que le cambiaron un campo de estado y la contraseña sigue ahí. Son cosas distintas. Pregunta cuál de las dos es.
5. ¿Qué pasa si la contraseña deja de funcionar? Esta es la que casi nadie hace, y es la que más riesgo esconde. Un servicio que reintenta el login automáticamente cuando el portal lo rechaza puede bloquearte la cuenta de SECOP. Vale la pena preguntarlo explícitamente.
Conviene decirlo sin adornos: SECOP II no ofrece una API ni un OAuth para el buzón del proveedor. No hay una pantalla de "autorizar aplicación" donde le des permisos acotados a una herramienta externa, como sí existe en Google o en Microsoft. Ese mecanismo, sencillamente, no está disponible en el portal.
La consecuencia es directa: la única forma de mirar tu bandeja es entrar como tú entras. Con tu usuario y tu contraseña, haciendo el mismo login que harías desde tu navegador.
Eso significa que sí hay algo que sopesar, y no tiene sentido fingir lo contrario. Una credencial que sirve para leer el buzón sirve, en principio, para todo lo demás que tu usuario puede hacer en el portal. Lo que limita el alcance no es un permiso técnico del portal —no existe—, sino lo que la plataforma decide hacer y no hacer con esa credencial, y qué tan verificable es esa decisión.
Por eso el resto de este artículo es específico. Una promesa general de que "cuidamos tus datos" no se puede contrastar. Una lista de decisiones concretas, sí.
Dónde queda la contraseña. Se guarda cifrada con AES-256-GCM, un algoritmo estándar que además de cifrar autentica el dato (detecta si alguien lo manipuló). La llave de 32 bytes es una variable de entorno del servidor y no está en la misma base de datos donde vive el dato cifrado. La separación importa por un escenario muy concreto: si un respaldo de la base se filtra, o si una clave de acceso a la base se escapa, el atacante se lleva bloques cifrados sin la llave para abrirlos.
Hay una segunda capa menos evidente. El cifrado se hace con el identificador de la empresa como dato autenticado adicional. Sin eso, mover el bloque cifrado de la empresa A a la fila de la empresa B funcionaría —la llave es la misma— y B terminaría usando la credencial de A. Con esa atadura, el descifrado falla.
Quién puede leerla. Nadie, por diseño. La tabla de credenciales tiene RLS activado y cero políticas: en Postgres eso significa deny-all, ninguna consulta desde la API pública devuelve una fila, tampoco la del dueño de la empresa. Lo único que la interfaz puede pedir es el estado de la conexión, la fecha del último uso y el último error. No hay ningún camino en el código que devuelva el usuario o la contraseña hacia el navegador.
Qué se hace con la cuenta. Tres veces al día, el proceso automático hace login, pide la lista de mensajes recibidos y compara con lo que ya conocía. Si hay algo nuevo, manda un correo a todos los miembros de la empresa. Eso es todo el alcance.
Qué se lee y qué no. Se lee la lista: remitente, asunto y fecha. Nunca se abre el detalle de un mensaje. La lista no marca nada en el portal; el detalle sí lo marca como leído. Abrirlo te borraría el indicador de «nuevo» en tu propio buzón, que es precisamente la señal que el servicio existe para que no pierdas. Es la clase de decisión que solo se toma si el objetivo es cuidar tu flujo de trabajo y no maximizar cuánto dato se extrae.
Qué pasa al desconectar. La fila se borra. Y con ella se descarta la sesión abierta del portal, que vive hasta 30 minutos en memoria del proceso. El detalle exacto está en la última sección.
Cómo lo auditas. Cada acceso queda en una bitácora que ves en el perfil de tu empresa, con fecha, hora y resultado. La ve cualquier miembro, no solo el dueño — el punto de una bitácora es que la pueda mirar quien quiera controlar.
Este merece sección propia porque es el riesgo más concreto de toda la integración, y no tiene nada que ver con hackers.
Pasa así. Cambias tu contraseña en SECOP II, como es sano hacer de vez en cuando. Se te olvida actualizarla en la plataforma. A las siete de la mañana, el proceso automático intenta entrar con la contraseña vieja y el portal lo rechaza. Si el sistema está construido para reintentar ante el fallo —el comportamiento por defecto de casi cualquier trabajo automático— vuelve a intentar. Y otra vez. Tras varios intentos fallidos seguidos con tu usuario, el portal bloquea tu cuenta de contratación pública. Tú no hiciste nada; tu cuenta quedó bloqueada igual, posiblemente en la semana en que tienes un cierre.
En Licitarus la regla es binaria: un rechazo del portal detiene el servicio. La credencial se marca como inválida, el proceso no reintenta, y sale un correo a la empresa avisando que la conexión dejó de funcionar y hay que volver a configurarla. Mientras esté marcada como inválida, ninguna corrida futura la usa — ni el cron, ni el disparo manual desde el panel de administración.
Ese principio se sostiene incluso en los casos raros. Si la base de datos no responde justo cuando hay que marcar la credencial como inválida, ese fallo se traga en silencio en vez de propagarse. Suena mal escrito así, pero es lo correcto: propagar el error haría que el orquestador reintentara el paso completo, y eso significa un segundo login con la contraseña que el portal acaba de rechazar, en cuestión de minutos. Un intento cada varias horas no dispara el bloqueo; varios seguidos, sí. La misma precaución aplica al registro de la bitácora en esa rama del código.
También hay una decisión de fail-closed. Cuando el mensaje de error del portal es ambiguo —hay un caso donde no se puede distinguir "el login no se completó" de "el portal bloqueó el intento"— se trata como credencial rechazada y se detiene todo. Perder una revisión legítima es un costo bajo. Arriesgar la cuenta del cliente, no.
La lista corta, porque es lo que separa un pedido legítimo de credenciales de un intento de phishing:
Vale la pena decir el corolario: si esas fueran las capacidades ofrecidas, la conversación sobre seguridad tendría que ser mucho más larga. Un servicio que puede presentar ofertas en tu nombre es un servicio con poder para comprometer legalmente a tu empresa. Leer una bandeja de entrada, no.
En el perfil de la empresa, en la tarjeta de la cuenta de SECOP II, hay un botón de desconectar. Lo ve el dueño de la cuenta —el mismo rol que puede conectarla—, y con eso alcanza: no hay que escribir a soporte, no hay que esperar aprobación y no hay ningún período de gracia. Nota la asimetría, porque es a propósito: conectar y desconectar es del dueño, pero la bitácora de accesos la ve cualquier miembro. Quien asume el riesgo decide; todo el equipo controla.
Al presionarlo pasan tres cosas, en este orden:
Si más adelante quieres volver a conectarla, se vuelve a configurar desde la misma tarjeta.
Lo que ofrece Licitarus con esa conexión es acotado y concreto: revisar tu buzón del SECOP tres veces al día y avisarte por correo cuando una entidad te escribe, para que el plazo de una subsanación no empiece a correr sin que nadie se entere. Todo lo demás de la plataforma —búsqueda de procesos, seguimiento, alertas, análisis de pliegos, perfil de empresa y RUP, calendario— funciona sin la cuenta del portal.
Si quieres el resto del contexto, acá está cómo funciona el buzón de SECOP II y por qué la subsanación de 24 horas es el plazo que más procesos cuesta.
Configura tu empresa en licitarus.com/signup.
Sube el pliego, obtén un análisis completo en minutos y calibra tu precio con inteligencia histórica de SECOP II.
La entidad no te llama ni te escribe al correo: te deja un mensaje dentro del portal. Si nadie entra a mirarlo, el proceso sigue sin ti. Esta guía explica dónde está el buzón, qué llega ahí y qué pasa cuando nadie lo revisa.
La entidad detecta que falta un documento y te da un plazo corto para arreglarlo. Si respondes, sigues compitiendo; si no lo ves a tiempo, quedas fuera con la oferta ya presentada. Qué es subsanable, qué no, y cómo no perder el plazo.
Licitarus cubre el ciclo completo: buscador inteligente en lenguaje natural (/licitaciones), alertas por correo con 20 gratis al mes (/alertas), y encima de eso la capa de análisis que otros no tienen: IA de pliegos, mercado histórico y simulador econométrico.
