Consulta:

Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 36.
Texto observado: “Modelos adaptativos: entrenamiento continuo con nuevas amenazas, credenciales expuestas y TTPs.”
Fundamento: El requisito está redactado en términos de la técnica de detección (modelos con entrenamiento continuo) y no del desempeño esperado (capacidad de detección actualizada frente a amenazas nuevas). Existen soluciones que alcanzan el mismo resultado mediante reglas y firmas actualizadas de forma continua, integración de fuentes de inteligencia de amenazas y validación por analistas. Además, el PBC no indica de qué manera el oferente deberá acreditar el cumplimiento de este punto ni cómo lo verificará el Comité de Evaluación, lo que resulta incompatible con la exigencia del Art. 59° del Decreto N° 2264/24 de acompañar los criterios con “especificaciones que permitan comprobar de manera efectiva la información facilitada por los oferentes”.
Solicitud: Se solicita a la Convocante: (i) aclarar el medio de acreditación de este requisito; y (ii) confirmar que se admitirá como cumplimiento toda solución que garantice la actualización continua de su capacidad de detección frente a nuevas amenazas, credenciales expuestas y TTPs, con independencia de la técnica empleada (aprendizaje automático, reglas actualizadas, inteligencia de amenazas o análisis humano).

Consulta:

Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 36.
Texto observado: “Dashboards personalizables con widgets que permitan filtros por criticidad y plantillas de informes.”
Fundamento: El término “widget” designa una modalidad concreta de composición de tableros, propia de la nomenclatura comercial de determinados productos. La necesidad funcional expresada por el propio requisito es la personalización de tableros, el filtrado por criticidad y la existencia de plantillas de informes. Existen plataformas que satisfacen íntegramente esas tres funciones mediante vistas configurables, paneles guardados o informes parametrizables, sin denominar “widget” a sus componentes. La verificación del cumplimiento debe recaer sobre la función y no sobre la denominación comercial (Decreto N° 2264/24, Art. 58°, segundo párrafo, en cuanto a que los signos distintivos no universales “únicamente se hará a manera de referencia”).
Solicitud: Se solicita a la Convocante confirmar que el requisito se tendrá por cumplido por cualquier solución que permita la personalización de tableros, el filtrado por criticidad y la generación de informes a partir de plantillas, con independencia de la denominación que el fabricante otorgue a los componentes de dicha personalización.

Consulta:

Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 36.
Texto observado: “API REST y Webhooks: endpoints para extracción de datos y notificaciones en tiempo real.”
Fundamento: La necesidad funcional subyacente es doble: (i) poder extraer datos de la plataforma de forma programática y (ii) recibir notificaciones en tiempo real. El “webhook” es una de las varias implementaciones posibles de la segunda función; existen mecanismos equivalentes —colas de mensajes, conectores nativos hacia SIEM/SOAR, envío por syslog, notificaciones SMTP con carga estructurada— que satisfacen idéntica necesidad. Exigir nominalmente el webhook redacta el requisito por la característica y no por el desempeño, restringiendo el universo de soluciones elegibles sin que el PBC exponga una justificación técnica de esa elección (Decreto N° 2264/24, Art. 58°).
Solicitud: Se solicita a la Convocante confirmar que se admitirá como cumplimiento del requisito cualquier mecanismo de notificación de eventos en tiempo real hacia sistemas del BCP —webhooks, conectores nativos, colas de mensajes, syslog o API con suscripción a eventos—, siempre que se acredite la entrega de la notificación en tiempo real y la posibilidad de extracción programática de los datos.

Consulta:

Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 36.
Texto observado: “Supervisión en redes sociales de cuentas falsas (LinkedIn, YouTube, Facebook, X, Instagram, entre otras) […] Monitoreo de Ejecutivos del BCP en redes sociales (LinkedIn, YouTube, Facebook, X, Instagram, entre otras).”
Fundamento: La expresión “entre otras” convierte el requisito en indeterminado. Cada plataforma social impone condiciones propias de acceso a datos (APIs con restricciones contractuales y de volumen, limitaciones de rastreo, políticas de denuncia y remoción diferenciadas) y, por tanto, la cobertura de cada una implica un desarrollo y un costo específicos. Una enumeración abierta no permite verificar el cumplimiento de manera objetiva ni comparar ofertas en igualdad de condiciones, contrariando el Art. 45 de la Ley N° 7021/22 y el Art. 58° del Decreto N° 2264/24, conforme al cual las especificaciones técnicas “deberán ser lo suficientemente claras, objetivas e imparciales, para evitar favorecer indebidamente a algún participante”.
Solicitud: Se solicita a la Convocante precisar, mediante adenda, la lista cerrada y taxativa de plataformas de redes sociales cuyo monitoreo se considerará obligatorio a los efectos de la evaluación de las ofertas, dejando constancia de que la cobertura de plataformas adicionales, en su caso, tendrá carácter deseable y no excluyente.

Consulta:

Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Soporte Técnico del Servicio”, pág. 38.
Texto observado: “Debe permitir la integración con LDAP y/o Active Directory para la autenticación y la gestión de usuarios y grupos.”
Fundamento: El PBC exige, en la misma sección, una “Plataforma SaaS como soporte al monitoreo, disponible 24/7/365” (pág. 36). En una arquitectura SaaS alojada fuera del perímetro de la Contratante, la integración literal por LDAP o Active Directory requiere exponer el servicio de directorio hacia Internet o desplegar un agente de conexión dedicado, práctica desaconsejada por las líneas base de aseguramiento aplicables a entidades financieras. El mecanismo estándar de la industria para este escenario es la autenticación federada mediante SAML 2.0 u OpenID Connect y el aprovisionamiento de usuarios y grupos mediante SCIM, integrados contra el directorio corporativo (Active Directory / Entra ID). Redactado el requisito por la tecnología de implementación y no por la función, se excluye a soluciones que satisfacen la misma necesidad —autenticación centralizada y gestión de usuarios y grupos contra el directorio del BCP— con un mecanismo funcionalmente equivalente o superior en términos de seguridad. Ello se aparta del mandato del Art. 58° del Decreto N° 2264/24, que impone establecer las especificaciones técnicas “con la mayor amplitud de acuerdo con la naturaleza específica del contrato, con el objeto de que concurra el mayor número de oferentes”.
Solicitud: Se solicita a la Convocante admitir expresamente, como funcionalmente equivalentes, los mecanismos de federación y aprovisionamiento SAML 2.0, OpenID Connect y SCIM contra el directorio corporativo del BCP, modificando la redacción del requisito en los siguientes términos: “La plataforma deberá permitir la autenticación centralizada y la gestión de usuarios y grupos contra el directorio corporativo del BCP, mediante SAML 2.0, OpenID Connect, SCIM, LDAP/Active Directory o cualquier otro mecanismo funcionalmente equivalente”.

Consulta:

Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, págs. 36 a 38 (modalidad de servicios gestionados).
Texto observado: “El servicio debe contemplar el soporte, monitoreo, configuraciones y adecuaciones de la solución utilizada para este servicio en el BCP; orientados a una modalidad de servicios gestionados.”
Fundamento: El PBC requiere una modalidad de servicios gestionados (managed service), en la cual el esfuerzo del proveedor —horas de analista, triage, validación de falsos positivos y gestión de casos— es función directa del volumen de alertas e incidentes. El pliego no proporciona información histórica ni estimada sobre dicho volumen, lo que obliga a cada oferente a construir un supuesto propio de dimensionamiento y produce ofertas económicamente no comparables, en detrimento del principio de Igualdad y Libre Competencia (Ley N° 7021/22, Art. 4°, inc. d)).
Solicitud: Se solicita a la Convocante proporcionar, a título referencial y sin que ello implique compromiso, el volumen histórico o estimado de eventos relevantes de los últimos 12 (doce) meses —tales como cantidad de dominios sospechosos detectados, campañas de phishing, perfiles falsos y solicitudes de remoción gestionadas—, a efectos de permitir un dimensionamiento uniforme del servicio gestionado por parte de todos los oferentes.

Consulta:

Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 36.
Texto observado: “Cobertura de fuentes: monitoreo 24/7 de surface, deep y dark web. […] menciones en deep y dark web, foros maliciosos y otros tipos de sitios fraudulentos.”
Fundamento: El PBC no define criterio alguno para determinar la suficiencia de la cobertura de fuentes (cantidad mínima de foros, mercados, canales de mensajería, repositorios de credenciales, etc.), ni el método por el cual la Convocante verificará su cumplimiento durante la evaluación. En ausencia de un parámetro objetivo, la evaluación de este requisito quedaría sujeta a apreciación discrecional, lo que resulta incompatible con la exigencia del Art. 59° del Decreto N° 2264/24 en cuanto a que los criterios “irán acompañados de especificaciones que permitan comprobar de manera efectiva la información facilitada por los oferentes”.
Solicitud: Se solicita a la Convocante aclarar de qué manera se acreditará y evaluará la cobertura de fuentes de deep y dark web; en particular, si será suficiente la declaración jurada del oferente acompañada de la documentación técnica del fabricante, o si se requerirá la individualización de las fuentes monitoreadas. Se solicita asimismo confirmar que no se exigirá la revelación de fuentes o métodos de recolección cuya divulgación comprometa la operación del servicio o la seguridad de la información.

Consulta:

Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 36.
Texto observado: “Se requiere como mínimo el monitoreo de 15 (quince) ejecutivos.”
Fundamento: Al igual que en el punto anterior, la expresión “como mínimo” fija un piso sin techo. En las soluciones de protección de ejecutivos (executive protection / VIP monitoring) la cantidad de personas monitoreadas constituye una unidad de licenciamiento directa. Bajo la modalidad de CONTRATO CERRADO, la indeterminación del número máximo obliga a cada oferente a asumir un supuesto distinto, lo que impide la comparación objetiva de ofertas y contraviene el deber de claridad y objetividad de las bases (Ley N° 7021/22, Art. 45) y la exigencia del propio PBC de consignar “los valores máximos o mínimos aceptables o garantizados” (PBC, Especificaciones Técnicas “CPS”, pág. 34).
Solicitud: Se solicita a la Convocante precisar la cantidad exacta o máxima de ejecutivos a ser monitoreados durante la vigencia del contrato; aclarar si dicha nómina podrá variar durante los 24 meses y, en tal caso, si las altas y bajas se compensan manteniendo el tope, o si generan un costo adicional a cargo de la Contratante.

Consulta:

Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, filas “Generalidades” y “Takedown”, págs. 36 y 37.
Texto observado: “Takedowns, eliminación de contenido malicioso en sitios fraudulentos como: deep y dark web, foros maliciosos y otros tipos de sitios. […] Debe prever la posibilidad de que se solicite hasta 20 takedowns según hallazgos, durante el periodo de prestación del servicio.”
Fundamento: El PBC contiene dos enunciados sobre el mismo objeto: uno general y sin límite cuantitativo (fila “Generalidades”) y otro que fija un tope de 20 takedowns para todo el período (fila “Takedown”). Adicionalmente, no se define la unidad de medida del takedown ni el resultado comprometido. En la práctica del mercado, un “takedown” puede computarse por URL, por dominio, por cuenta en red social, por publicación o por incidente, y el resultado puede definirse como gestión iniciada o como remoción efectiva —extremo este último que depende de terceros (registradores, hosting, plataformas) y no es plenamente controlable por el proveedor. La ausencia de estas definiciones impide dimensionar el servicio y expone al oferente a una obligación de alcance indeterminado, con incidencia directa en el régimen de multas previsto (0,5% por cada deficiencia y/o incumplimiento, pág. 51). Ello resulta incompatible con el deber de claridad y objetividad del Art. 45 de la Ley N° 7021/22 y con el principio de Razonabilidad (Art. 4°, inc. k)).
Solicitud: Se solicita a la Convocante aclarar: (i) si 20 (veinte) constituye el número máximo de takedowns incluidos en el precio del contrato para todo el período de 24 meses; (ii) cuál es la unidad de cómputo del takedown (URL, dominio, cuenta, publicación o incidente); (iii) si la obligación del proveedor es de medio (gestión y seguimiento del pedido de remoción ante el tercero responsable) o de resultado (remoción efectiva del contenido); (iv) qué tratamiento se dará a los requerimientos que excedan la cantidad de 20; y (v) si existe un plazo máximo comprometido para la gestión del takedown.