Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, Condiciones Generales, pág. 38.
Texto observado: “El proveedor deberá garantizar durante la vigencia del contrato, que la solución se encuentre actualizada en su última versión estable.”
Fundamento: El objeto contratado es una suscripción a una plataforma SaaS (pág. 36). En este modelo, el versionado, el calendario de liberaciones y las ventanas de actualización son determinados y ejecutados por el fabricante sobre una infraestructura multi-inquilino, sin que el proveedor local tenga control sobre ellos. Una obligación de resultado redactada en términos de versionado impondría al oferente una responsabilidad sobre hechos de un tercero ajenos a su esfera de control, lo que se aparta del principio de Razonabilidad (Ley N° 7021/22, Art. 4°, inc. k)).
Solicitud: Se solicita a la Convocante confirmar que la obligación se tendrá por cumplida mediante la provisión del servicio sobre la versión productiva vigente que el fabricante mantenga para todos sus suscriptores, y que el proveedor no será responsable por el calendario de liberaciones ni por las ventanas de mantenimiento definidas por el fabricante.
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, Condiciones Generales, pág. 38.
Texto observado: “El proveedor deberá garantizar durante la vigencia del contrato, que la solución se encuentre actualizada en su última versión estable.”
Fundamento: El objeto contratado es una suscripción a una plataforma SaaS (pág. 36). En este modelo, el versionado, el calendario de liberaciones y las ventanas de actualización son determinados y ejecutados por el fabricante sobre una infraestructura multi-inquilino, sin que el proveedor local tenga control sobre ellos. Una obligación de resultado redactada en términos de versionado impondría al oferente una responsabilidad sobre hechos de un tercero ajenos a su esfera de control, lo que se aparta del principio de Razonabilidad (Ley N° 7021/22, Art. 4°, inc. k)).
Solicitud: Se solicita a la Convocante confirmar que la obligación se tendrá por cumplida mediante la provisión del servicio sobre la versión productiva vigente que el fabricante mantenga para todos sus suscriptores, y que el proveedor no será responsable por el calendario de liberaciones ni por las ventanas de mantenimiento definidas por el fabricante.
Favor adecuarse a la Adenda a ser publicada en el SICP.
22
Canales de takedown: “APIs de hosting” y marketplaces
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Takedown”, pág. 37.
Texto observado: “Soporte para email, APIs de hosting, redes sociales y marketplaces.”
Fundamento: La expresión “APIs de hosting” no corresponde a una categoría técnica de contornos definidos: los proveedores de alojamiento no exponen, con carácter general, interfaces programáticas públicas para la recepción de solicitudes de remoción, siendo el canal habitual el correo de abuse o los formularios web de cada proveedor. Del mismo modo, no se identifican los marketplaces comprendidos. La indeterminación del requisito impide verificar objetivamente su cumplimiento (Decreto N° 2264/24, Art. 58°).
Solicitud: Se solicita a la Convocante aclarar el alcance de la expresión “APIs de hosting” y confirmar que el requisito se tendrá por cumplido cuando la solución permita iniciar y gestionar solicitudes de remoción por los canales que cada proveedor de alojamiento, red social o marketplace habilite a tal efecto, incluyendo correo de abuse, formularios y, cuando existan, interfaces programáticas.
14-08-2026
03-09-2026
Canales de takedown: “APIs de hosting” y marketplaces
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Takedown”, pág. 37.
Texto observado: “Soporte para email, APIs de hosting, redes sociales y marketplaces.”
Fundamento: La expresión “APIs de hosting” no corresponde a una categoría técnica de contornos definidos: los proveedores de alojamiento no exponen, con carácter general, interfaces programáticas públicas para la recepción de solicitudes de remoción, siendo el canal habitual el correo de abuse o los formularios web de cada proveedor. Del mismo modo, no se identifican los marketplaces comprendidos. La indeterminación del requisito impide verificar objetivamente su cumplimiento (Decreto N° 2264/24, Art. 58°).
Solicitud: Se solicita a la Convocante aclarar el alcance de la expresión “APIs de hosting” y confirmar que el requisito se tendrá por cumplido cuando la solución permita iniciar y gestionar solicitudes de remoción por los canales que cada proveedor de alojamiento, red social o marketplace habilite a tal efecto, incluyendo correo de abuse, formularios y, cuando existan, interfaces programáticas.
Favor adecuarse a la Adenda a ser publicada en el SICP.
23
Gestión de casos: “ticketing integrado”
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Takedown”, pág. 37.
Texto observado: “Gestión de casos: ticketing integrado con historial, notas y escalamiento automático.”
Fundamento: El término “integrado” admite dos interpretaciones: (i) que la plataforma cuente con un módulo propio de gestión de casos; o (ii) que dicho módulo deba integrarse con el sistema de gestión de tickets ya en uso en el BCP. La segunda lectura conllevaría un desarrollo de integración cuyo alcance y costo dependen del producto de destino, no identificado en el pliego, con el consiguiente efecto sobre la comparabilidad de las ofertas y un potencial beneficio de hecho para quien conozca la plataforma instalada (Ley N° 7021/22, Art. 45).
Solicitud: Se solicita a la Convocante aclarar si el requisito se satisface con el módulo de gestión de casos propio de la plataforma ofertada, con historial, notas y escalamiento automático; o si se exige integración con un sistema de gestión de tickets preexistente del BCP, en cuyo caso se solicita indicar el producto, versión y método de integración requerido.
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Takedown”, pág. 37.
Texto observado: “Gestión de casos: ticketing integrado con historial, notas y escalamiento automático.”
Fundamento: El término “integrado” admite dos interpretaciones: (i) que la plataforma cuente con un módulo propio de gestión de casos; o (ii) que dicho módulo deba integrarse con el sistema de gestión de tickets ya en uso en el BCP. La segunda lectura conllevaría un desarrollo de integración cuyo alcance y costo dependen del producto de destino, no identificado en el pliego, con el consiguiente efecto sobre la comparabilidad de las ofertas y un potencial beneficio de hecho para quien conozca la plataforma instalada (Ley N° 7021/22, Art. 45).
Solicitud: Se solicita a la Convocante aclarar si el requisito se satisface con el módulo de gestión de casos propio de la plataforma ofertada, con historial, notas y escalamiento automático; o si se exige integración con un sistema de gestión de tickets preexistente del BCP, en cuyo caso se solicita indicar el producto, versión y método de integración requerido.
Favor adecuarse a la Adenda a ser publicada en el SICP.
24
Diseño adaptativo (responsive): medio de acreditación
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 37.
Texto observado: “[…] debe contar con un diseño adaptativo (responsive).”
Fundamento: El PBC no indica el medio por el cual se acreditará y verificará este atributo, ni si se refiere a la adaptación de la interfaz web a distintos tamaños de pantalla o a la existencia de una aplicación móvil nativa. Se trata de dos soluciones técnicas distintas, con implicancias de disponibilidad y costo diferentes.
Solicitud: Se solicita a la Convocante aclarar si el requisito se refiere a la adaptación de la interfaz web a distintos tamaños de pantalla, y confirmar que la presentación de la declaración jurada del cuadro de Especificaciones Técnicas, acompañada de la documentación del fabricante, constituye medio suficiente de acreditación.
14-08-2026
03-09-2026
Diseño adaptativo (responsive): medio de acreditación
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 37.
Texto observado: “[…] debe contar con un diseño adaptativo (responsive).”
Fundamento: El PBC no indica el medio por el cual se acreditará y verificará este atributo, ni si se refiere a la adaptación de la interfaz web a distintos tamaños de pantalla o a la existencia de una aplicación móvil nativa. Se trata de dos soluciones técnicas distintas, con implicancias de disponibilidad y costo diferentes.
Solicitud: Se solicita a la Convocante aclarar si el requisito se refiere a la adaptación de la interfaz web a distintos tamaños de pantalla, y confirmar que la presentación de la declaración jurada del cuadro de Especificaciones Técnicas, acompañada de la documentación del fabricante, constituye medio suficiente de acreditación.
Se confirma que la documentación del fabricante constituye medio suficiente de acreditación.
25
Canales de notificación: push, correo electrónico o SMS
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Protección de Ejecutivos del BCP”, pág. 37.
Texto observado: “Alertas en tiempo real: notificaciones push, email o SMS configurables por ejecutivo.”
Fundamento: La redacción con la conjunción “o” admite dos lecturas: que la solución deba ofrecer los tres canales, o que baste con uno de ellos configurable por ejecutivo. La diferencia no es menor: la notificación push presupone la existencia de una aplicación móvil propia del fabricante —funcionalidad que no todas las plataformas del segmento ofrecen— y el envío de SMS a numeración paraguaya implica la contratación de un proveedor de mensajería con costo variable, no cuantificable sin conocer el volumen previsto. La ambigüedad afecta la comparabilidad de las ofertas (Ley N° 7021/22, Art. 45).
Solicitud: Se solicita a la Convocante aclarar si el requisito se tendrá por cumplido ofreciendo al menos uno de los canales enunciados, configurable por ejecutivo, o si se exige la disponibilidad simultánea de los tres. En caso de exigirse el canal SMS, se solicita precisar el volumen mensual máximo de mensajes previsto y confirmar si su costo se considera incluido en el precio del contrato.
14-08-2026
03-09-2026
Canales de notificación: push, correo electrónico o SMS
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Protección de Ejecutivos del BCP”, pág. 37.
Texto observado: “Alertas en tiempo real: notificaciones push, email o SMS configurables por ejecutivo.”
Fundamento: La redacción con la conjunción “o” admite dos lecturas: que la solución deba ofrecer los tres canales, o que baste con uno de ellos configurable por ejecutivo. La diferencia no es menor: la notificación push presupone la existencia de una aplicación móvil propia del fabricante —funcionalidad que no todas las plataformas del segmento ofrecen— y el envío de SMS a numeración paraguaya implica la contratación de un proveedor de mensajería con costo variable, no cuantificable sin conocer el volumen previsto. La ambigüedad afecta la comparabilidad de las ofertas (Ley N° 7021/22, Art. 45).
Solicitud: Se solicita a la Convocante aclarar si el requisito se tendrá por cumplido ofreciendo al menos uno de los canales enunciados, configurable por ejecutivo, o si se exige la disponibilidad simultánea de los tres. En caso de exigirse el canal SMS, se solicita precisar el volumen mensual máximo de mensajes previsto y confirmar si su costo se considera incluido en el precio del contrato.
Favor adecuarse a la Adenda a ser publicada en el SICP.
26
Canales de notificación: push, correo electrónico o SMS
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Protección de Ejecutivos del BCP”, pág. 37.
Texto observado: “Alertas en tiempo real: notificaciones push, email o SMS configurables por ejecutivo.”
Fundamento: La redacción con la conjunción “o” admite dos lecturas: que la solución deba ofrecer los tres canales, o que baste con uno de ellos configurable por ejecutivo. La diferencia no es menor: la notificación push presupone la existencia de una aplicación móvil propia del fabricante —funcionalidad que no todas las plataformas del segmento ofrecen— y el envío de SMS a numeración paraguaya implica la contratación de un proveedor de mensajería con costo variable, no cuantificable sin conocer el volumen previsto. La ambigüedad afecta la comparabilidad de las ofertas (Ley N° 7021/22, Art. 45).
Solicitud: Se solicita a la Convocante aclarar si el requisito se tendrá por cumplido ofreciendo al menos uno de los canales enunciados, configurable por ejecutivo, o si se exige la disponibilidad simultánea de los tres. En caso de exigirse el canal SMS, se solicita precisar el volumen mensual máximo de mensajes previsto y confirmar si su costo se considera incluido en el precio del contrato.
14-08-2026
03-09-2026
Canales de notificación: push, correo electrónico o SMS
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Protección de Ejecutivos del BCP”, pág. 37.
Texto observado: “Alertas en tiempo real: notificaciones push, email o SMS configurables por ejecutivo.”
Fundamento: La redacción con la conjunción “o” admite dos lecturas: que la solución deba ofrecer los tres canales, o que baste con uno de ellos configurable por ejecutivo. La diferencia no es menor: la notificación push presupone la existencia de una aplicación móvil propia del fabricante —funcionalidad que no todas las plataformas del segmento ofrecen— y el envío de SMS a numeración paraguaya implica la contratación de un proveedor de mensajería con costo variable, no cuantificable sin conocer el volumen previsto. La ambigüedad afecta la comparabilidad de las ofertas (Ley N° 7021/22, Art. 45).
Solicitud: Se solicita a la Convocante aclarar si el requisito se tendrá por cumplido ofreciendo al menos uno de los canales enunciados, configurable por ejecutivo, o si se exige la disponibilidad simultánea de los tres. En caso de exigirse el canal SMS, se solicita precisar el volumen mensual máximo de mensajes previsto y confirmar si su costo se considera incluido en el precio del contrato.
Favor adecuarse a la Adenda a ser publicada en el SICP.
27
Conectores nativos con SIEM/SOAR no identificados
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 37.
Texto observado: “Conectividad con SIEM/SOAR: ingesta de eventos en tiempo real vía syslog, API o conectores nativos.”
Fundamento: El requisito menciona “conectores nativos” sin identificar las plataformas SIEM y SOAR en producción en el BCP ni sus versiones. Un conector nativo es, por definición, específico de un producto determinado; su exigencia sin individualización del producto de destino impide al oferente verificar previamente la compatibilidad y, en el escenario en que la Convocante evaluara la existencia de un conector nativo para un producto no revelado en el pliego, se generaría una ventaja de hecho a favor de quien conozca la plataforma instalada. La redacción del requisito con la conjunción “o” sugiere que syslog y API constituyen alternativas suficientes; corresponde confirmarlo expresamente (Ley N° 7021/22, Art. 45; Decreto N° 2264/24, Art. 58°).
Solicitud: Se solicita a la Convocante confirmar que la entrega de eventos en tiempo real mediante syslog en formato estándar (CEF, LEEF o equivalente) y/o mediante API REST satisface íntegramente el requisito, sin que resulte exigible la existencia de un conector nativo preconstruido para un producto SIEM/SOAR determinado. Subsidiariamente, en caso de que la existencia de conector nativo se considere exigible, se solicita indicar la marca, producto y versión del SIEM y del SOAR con los que deberá integrarse la solución.
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 37.
Texto observado: “Conectividad con SIEM/SOAR: ingesta de eventos en tiempo real vía syslog, API o conectores nativos.”
Fundamento: El requisito menciona “conectores nativos” sin identificar las plataformas SIEM y SOAR en producción en el BCP ni sus versiones. Un conector nativo es, por definición, específico de un producto determinado; su exigencia sin individualización del producto de destino impide al oferente verificar previamente la compatibilidad y, en el escenario en que la Convocante evaluara la existencia de un conector nativo para un producto no revelado en el pliego, se generaría una ventaja de hecho a favor de quien conozca la plataforma instalada. La redacción del requisito con la conjunción “o” sugiere que syslog y API constituyen alternativas suficientes; corresponde confirmarlo expresamente (Ley N° 7021/22, Art. 45; Decreto N° 2264/24, Art. 58°).
Solicitud: Se solicita a la Convocante confirmar que la entrega de eventos en tiempo real mediante syslog en formato estándar (CEF, LEEF o equivalente) y/o mediante API REST satisface íntegramente el requisito, sin que resulte exigible la existencia de un conector nativo preconstruido para un producto SIEM/SOAR determinado. Subsidiariamente, en caso de que la existencia de conector nativo se considere exigible, se solicita indicar la marca, producto y versión del SIEM y del SOAR con los que deberá integrarse la solución.
Favor adecuarse a la Adenda a ser publicada en el SICP.
28
Conectores nativos con SIEM/SOAR no identificados
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 37.
Texto observado: “Conectividad con SIEM/SOAR: ingesta de eventos en tiempo real vía syslog, API o conectores nativos.”
Fundamento: El requisito menciona “conectores nativos” sin identificar las plataformas SIEM y SOAR en producción en el BCP ni sus versiones. Un conector nativo es, por definición, específico de un producto determinado; su exigencia sin individualización del producto de destino impide al oferente verificar previamente la compatibilidad y, en el escenario en que la Convocante evaluara la existencia de un conector nativo para un producto no revelado en el pliego, se generaría una ventaja de hecho a favor de quien conozca la plataforma instalada. La redacción del requisito con la conjunción “o” sugiere que syslog y API constituyen alternativas suficientes; corresponde confirmarlo expresamente (Ley N° 7021/22, Art. 45; Decreto N° 2264/24, Art. 58°).
Solicitud: Se solicita a la Convocante confirmar que la entrega de eventos en tiempo real mediante syslog en formato estándar (CEF, LEEF o equivalente) y/o mediante API REST satisface íntegramente el requisito, sin que resulte exigible la existencia de un conector nativo preconstruido para un producto SIEM/SOAR determinado. Subsidiariamente, en caso de que la existencia de conector nativo se considere exigible, se solicita indicar la marca, producto y versión del SIEM y del SOAR con los que deberá integrarse la solución.
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 37.
Texto observado: “Conectividad con SIEM/SOAR: ingesta de eventos en tiempo real vía syslog, API o conectores nativos.”
Fundamento: El requisito menciona “conectores nativos” sin identificar las plataformas SIEM y SOAR en producción en el BCP ni sus versiones. Un conector nativo es, por definición, específico de un producto determinado; su exigencia sin individualización del producto de destino impide al oferente verificar previamente la compatibilidad y, en el escenario en que la Convocante evaluara la existencia de un conector nativo para un producto no revelado en el pliego, se generaría una ventaja de hecho a favor de quien conozca la plataforma instalada. La redacción del requisito con la conjunción “o” sugiere que syslog y API constituyen alternativas suficientes; corresponde confirmarlo expresamente (Ley N° 7021/22, Art. 45; Decreto N° 2264/24, Art. 58°).
Solicitud: Se solicita a la Convocante confirmar que la entrega de eventos en tiempo real mediante syslog en formato estándar (CEF, LEEF o equivalente) y/o mediante API REST satisface íntegramente el requisito, sin que resulte exigible la existencia de un conector nativo preconstruido para un producto SIEM/SOAR determinado. Subsidiariamente, en caso de que la existencia de conector nativo se considere exigible, se solicita indicar la marca, producto y versión del SIEM y del SOAR con los que deberá integrarse la solución.
Favor adecuarse a la Adenda a ser publicada en el SICP.
29
Tratamiento del atributo “deseable” en ausencia de multiplicidad de criterios
Referencia: Sección Suministros Requeridos – EETT, pág. 37, en concordancia con “Evaluación basada en multiplicidad de criterios – No Aplica” y “Ponderación de criterios de evaluación – No Aplica”, pág. 29-30.
Texto observado: “[…] el idioma requerido es el español y el deseable inglés.”
Fundamento: El PBC declara expresamente que no se aplicará evaluación basada en multiplicidad de criterios ni ponderación de criterios (pág. 29-30). En consecuencia, no existe en las bases mecanismo alguno que asigne puntaje o valor comparativo a un atributo calificado como “deseable”. El Art. 59° del Decreto N° 2264/24 dispone que “la convocante deberá detallar de manera objetiva y clara en las bases de la contratación los criterios de evaluación a ser aplicados” y que “deberá precisarse en las bases de la contratación, la ponderación relativa que se atribuya a cada uno de los criterios elegidos”. Un atributo deseable sin ponderación definida no resulta evaluable y puede generar tratamientos disímiles entre ofertas.
Solicitud: Se solicita a la Convocante confirmar que los atributos calificados como “deseables” en el cuadro de Especificaciones Técnicas no constituyen requisitos de cumplimiento obligatorio ni otorgan ventaja comparativa alguna en la evaluación, y que su ausencia no dará lugar a la descalificación de la oferta.
14-08-2026
03-09-2026
Tratamiento del atributo “deseable” en ausencia de multiplicidad de criterios
Referencia: Sección Suministros Requeridos – EETT, pág. 37, en concordancia con “Evaluación basada en multiplicidad de criterios – No Aplica” y “Ponderación de criterios de evaluación – No Aplica”, pág. 29-30.
Texto observado: “[…] el idioma requerido es el español y el deseable inglés.”
Fundamento: El PBC declara expresamente que no se aplicará evaluación basada en multiplicidad de criterios ni ponderación de criterios (pág. 29-30). En consecuencia, no existe en las bases mecanismo alguno que asigne puntaje o valor comparativo a un atributo calificado como “deseable”. El Art. 59° del Decreto N° 2264/24 dispone que “la convocante deberá detallar de manera objetiva y clara en las bases de la contratación los criterios de evaluación a ser aplicados” y que “deberá precisarse en las bases de la contratación, la ponderación relativa que se atribuya a cada uno de los criterios elegidos”. Un atributo deseable sin ponderación definida no resulta evaluable y puede generar tratamientos disímiles entre ofertas.
Solicitud: Se solicita a la Convocante confirmar que los atributos calificados como “deseables” en el cuadro de Especificaciones Técnicas no constituyen requisitos de cumplimiento obligatorio ni otorgan ventaja comparativa alguna en la evaluación, y que su ausencia no dará lugar a la descalificación de la oferta.
Se confirma que, no siendo aplicables la evaluación basada en multiplicidad de criterios ni la ponderación de criterios de evaluación conforme lo consignado en la Sección Requisitos de Participación y Criterios de Evaluación, el atributo calificado como "deseable" en el cuadro de Especificaciones Técnicas no constituye requisito de cumplimiento obligatorio, no otorga ventaja comparativa alguna en la evaluación de las ofertas y su ausencia no dará lugar a la descalificación. La evaluación técnica se practicará exclusivamente sobre los requisitos consignados como exigidos.
30
Alcance del requisito de idioma español
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 37.
Texto observado: “La plataforma debe soportar varios idiomas, el idioma requerido es el español y el deseable inglés. Además, debe contar con un diseño adaptativo (responsive).”
Fundamento: El requisito no precisa sobre qué elemento recae la exigencia de idioma español: la interfaz de usuario de la plataforma, los informes generados, las alertas, o la interacción con el equipo de soporte. Una parte relevante de las plataformas de protección de marca y vigilancia digital de nivel internacional opera con interfaz en inglés, entregando informes, alertas y soporte en español. Si la exigencia se interpretara como interfaz de usuario íntegramente en español, se reduciría de manera significativa el universo de soluciones elegibles sin que el PBC exponga la necesidad funcional que lo justifique, en contradicción con el mandato de amplitud del Art. 58° del Decreto N° 2264/24 y del Art. 45 de la Ley N° 7021/22.
Solicitud: Se solicita a la Convocante precisar el alcance de la exigencia de idioma español y, en particular, confirmar que se tendrá por cumplido el requisito cuando los informes, las alertas, la documentación entregable y la atención de soporte al BCP se presten en idioma español, aun cuando la interfaz de administración de la plataforma se encuentre disponible en idioma inglés.
Referencia: Sección Suministros Requeridos – Especificaciones Técnicas, fila “Generalidades”, pág. 37.
Texto observado: “La plataforma debe soportar varios idiomas, el idioma requerido es el español y el deseable inglés. Además, debe contar con un diseño adaptativo (responsive).”
Fundamento: El requisito no precisa sobre qué elemento recae la exigencia de idioma español: la interfaz de usuario de la plataforma, los informes generados, las alertas, o la interacción con el equipo de soporte. Una parte relevante de las plataformas de protección de marca y vigilancia digital de nivel internacional opera con interfaz en inglés, entregando informes, alertas y soporte en español. Si la exigencia se interpretara como interfaz de usuario íntegramente en español, se reduciría de manera significativa el universo de soluciones elegibles sin que el PBC exponga la necesidad funcional que lo justifique, en contradicción con el mandato de amplitud del Art. 58° del Decreto N° 2264/24 y del Art. 45 de la Ley N° 7021/22.
Solicitud: Se solicita a la Convocante precisar el alcance de la exigencia de idioma español y, en particular, confirmar que se tendrá por cumplido el requisito cuando los informes, las alertas, la documentación entregable y la atención de soporte al BCP se presten en idioma español, aun cuando la interfaz de administración de la plataforma se encuentre disponible en idioma inglés.
Se aclara que el requisito de la fila "Generalidades" del cuadro de Especificaciones Técnicas recae sobre la plataforma, la cual debe soportar el idioma español; el idioma inglés se consigna como deseable y, por tanto, no obligatorio. En consecuencia, la disponibilidad del español en la plataforma constituye requisito de cumplimiento, sin perjuicio de que los informes, alertas, documentación entregable y atención de soporte al BCP deberán igualmente prestarse en idioma español.