Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069498
Тема сообщения
Нарушения в ТС
Тип сообщения
Замечание к КД
Поставщик
AI-Trade ИП
Представитель поставщика
ОРАЗБАЕВА АНОРА БЕИМБЕТОВНА
Дата и время отправки сообщения
2026-10-04 19:49:41
Текст сообщения
1. В технической спецификации содержится прямое примечание о том, что установление квалификационных требований, предъявляемых к потенциальному поставщику, не допускается.
2. Одновременно пункты 5.1 и 5.2 требуют именно от потенциального поставщика предоставить в составе конкурсной заявки авторизационное письмо правообладателя и/или официального дистрибьютора.
3. Просим устранить указанное внутреннее противоречие.
4. Само программное обеспечение может полностью соответствовать всем заявленным требованиям независимо от того, имеет ли участник специальное адресное письмо.
5. Следовательно, письмо не описывает товар.
6. Оно подтверждает определенное коммерческое отношение поставщика с правообладателем или дистрибьютором.
7. Таким образом, требование фактически касается статуса потенциального поставщика.
8. Оно может быть выполнено не любым участником рынка, способным поставить легальный товар, а только субъектом, которому третья организация согласилась выдать документ.
9. Фактически появляется дополнительное условие допуска, отсутствующее в общих требованиях к товару.
10. Такая конструкция создает риск скрытой квалификации участников по признаку наличия отношений с конкретным правообладателем.
11. Особенно это очевидно из требования оформить письмо на имя конкретного заказчика и указать конкретные номер объявления и номер лота.
12. Если целью было бы лишь подтверждение легального происхождения программного продукта, достаточно было бы общего документа о статусе партнера или документа о законности лицензии.
13. Индивидуальное письмо под конкретную закупку служит уже не подтверждением свойств товара, а своеобразным разрешением третьего лица на участие в конкретном конкурсе.
14. Просим исключить такой механизм.
15. Ни правообладатель, ни официальный дистрибьютор не должны фактически определять круг участников государственной закупки.
16. Контроль допуска должен осуществляться исключительно на основании объективных требований конкурсной документации.
17. Требования должны быть одинаково выполнимыми всеми хозяйствующими субъектами без необходимости получать индивидуальное согласие потенциального конкурента, правообладателя или коммерческого посредника.
18. Наличие реестра и сертификата информационной безопасности уже предоставляет Заказчику механизмы проверки программного продукта.
19. Поэтому дополнительное письмо является избыточным.
20. Более того, по пункту 5.1 требуется одновременно три самостоятельных документарных барьера.
21. Первый — сертификат по СТ РК ISO/IEC 15408-3 с уровнем доверия не ниже 5.
22. Второй — документ о включении решения в реестр доверенного программного обеспечения и продукции электронной промышленности.
23. Третий — персональное авторизационное письмо.
24. По пункту 5.2 применяется аналогичная схема, но уже с уровнем 5+.
25. Просим пояснить, зачем при наличии первых двух объективных документов необходим третий документ, зависящий от коммерческого решения правообладателя.
26. Кроме документарных ограничений, по пунктам 5.1 и 5.2 имеется значительное число узких технических условий.
27. По пункту 5.1 объединены признаки файлового менеджера, антивируса, системы разграничения доступа и серверной криптографической инфраструктуры.
28. Требуется работа с мобильными устройствами.
29. Требуется казахский и русский интерфейс.
30. Требуется бессрочная лицензия.
31. Требуется расположенная в Казахстане криптографическая система.
32. Требуется анализ поведения.
33. Требуется машинное обучение.
34. Требуются сигнатурные базы.
35. Требуется двухпанельный режим.
36. Требуется оценочный уровень 5.
37. Требуется реестр.
38. И требуется специальное письмо.
39. Это крайне узкая совокупность признаков.
40. Просим подтвердить ее конкурентность посредством указания минимум трех независимых решений.
41. По пункту 5.2 ситуация еще более специфична.
42. Помимо сертификации и реестра, прямо описывается внутренняя архитектура программного средства.
43. Оно должно быть DXE-драйвером.
44. Должно функционировать в составе UEFI.
45. Должно реализовывать аутентификацию до загрузки ОС.
46. Должно контролировать цифровые подписи компонентов загрузочной цепочки.
47. Должно защищать загрузочный сектор.
48. Должно вести журналы.
49. При этом требуется именно уровень доверия 5+.
50. Для определения соответствия следовало бы устанавливать функциональный результат, а не единственно допустимую программную архитектуру.
51. Например, Заказчику может быть необходим запрет неавторизованной загрузки.
52. Такой результат потенциально может обеспечиваться несколькими техническими способами.
53. Требование именно DXE-драйвера исключает альтернативные архитектуры.
54. Аналогично требование сервера определенного территориального расположения должно быть обосновано характером обрабатываемой информации.
55. В ТС не раскрыто, какие именно данные арт-терапевтического кабинета требуют оценочного уровня доверия 5 и 5+.
56. Если моноблок предназначается преимущественно для учебных, творческих и административных задач, необходимо пояснить соразмерность таких требований.
57. Иначе получается, что небольшая программная часть комплекта создает основной барьер для участия поставщиков всего кабинета.
58. Участник должен поставить столы, мольберты, светильники, холсты, фартуки, краски, карандаши, кисти, гипсовые модели и одновременно выполнить специализированные требования по информационной безопасности.
59. Более того, участник должен иметь доступ именно к правообладателям соответствующих программных решений.
60. Поставщики учебного оборудования и художественных принадлежностей, не имеющие заранее оформленного партнерства с ними, оказываются поставлены в менее выгодное положение.
61. Объединение таких разнородных товаров усиливает ограничивающий эффект письма.
62. Для поставки художественных принадлежностей участнику фактически необходимо получить разрешительную документацию правообладателя специализированного ПО.
63. Это не связано с его профессиональной способностью поставить основной объем предметов кабинета.
64. Просим либо исключить адресные письма, либо выделить специализированное ПО в отдельный предмет закупки, если Заказчик считает указанные средства информационной безопасности объективно необходимыми.
65. Предпочтительным является первый вариант — сохранение единой закупки при исключении требований, контролируемых третьими лицами.
66. Легальность ПО может проверяться непосредственно при поставке.
67. Сертификационные свойства продукта — по официальным реестрам и сертификатам.
68. Технические функции — по документации разработчика.
69. Таким образом, индивидуальное письмо является необязательным элементом проверки.
70. Просим также ввести прямую формулировку о допуске эквивалентных решений.
71. Эквивалентность должна определяться по результату: защита данных, контроль загрузки, антивирусная защита, управление доступом.
72. Не следует ограничивать ее конкретным способом внутренней реализации.
73. В противном случае совокупность требований может необоснованно сужать круг участников и создавать преимущество поставщикам конкретных программных продуктов.
2. Одновременно пункты 5.1 и 5.2 требуют именно от потенциального поставщика предоставить в составе конкурсной заявки авторизационное письмо правообладателя и/или официального дистрибьютора.
3. Просим устранить указанное внутреннее противоречие.
4. Само программное обеспечение может полностью соответствовать всем заявленным требованиям независимо от того, имеет ли участник специальное адресное письмо.
5. Следовательно, письмо не описывает товар.
6. Оно подтверждает определенное коммерческое отношение поставщика с правообладателем или дистрибьютором.
7. Таким образом, требование фактически касается статуса потенциального поставщика.
8. Оно может быть выполнено не любым участником рынка, способным поставить легальный товар, а только субъектом, которому третья организация согласилась выдать документ.
9. Фактически появляется дополнительное условие допуска, отсутствующее в общих требованиях к товару.
10. Такая конструкция создает риск скрытой квалификации участников по признаку наличия отношений с конкретным правообладателем.
11. Особенно это очевидно из требования оформить письмо на имя конкретного заказчика и указать конкретные номер объявления и номер лота.
12. Если целью было бы лишь подтверждение легального происхождения программного продукта, достаточно было бы общего документа о статусе партнера или документа о законности лицензии.
13. Индивидуальное письмо под конкретную закупку служит уже не подтверждением свойств товара, а своеобразным разрешением третьего лица на участие в конкретном конкурсе.
14. Просим исключить такой механизм.
15. Ни правообладатель, ни официальный дистрибьютор не должны фактически определять круг участников государственной закупки.
16. Контроль допуска должен осуществляться исключительно на основании объективных требований конкурсной документации.
17. Требования должны быть одинаково выполнимыми всеми хозяйствующими субъектами без необходимости получать индивидуальное согласие потенциального конкурента, правообладателя или коммерческого посредника.
18. Наличие реестра и сертификата информационной безопасности уже предоставляет Заказчику механизмы проверки программного продукта.
19. Поэтому дополнительное письмо является избыточным.
20. Более того, по пункту 5.1 требуется одновременно три самостоятельных документарных барьера.
21. Первый — сертификат по СТ РК ISO/IEC 15408-3 с уровнем доверия не ниже 5.
22. Второй — документ о включении решения в реестр доверенного программного обеспечения и продукции электронной промышленности.
23. Третий — персональное авторизационное письмо.
24. По пункту 5.2 применяется аналогичная схема, но уже с уровнем 5+.
25. Просим пояснить, зачем при наличии первых двух объективных документов необходим третий документ, зависящий от коммерческого решения правообладателя.
26. Кроме документарных ограничений, по пунктам 5.1 и 5.2 имеется значительное число узких технических условий.
27. По пункту 5.1 объединены признаки файлового менеджера, антивируса, системы разграничения доступа и серверной криптографической инфраструктуры.
28. Требуется работа с мобильными устройствами.
29. Требуется казахский и русский интерфейс.
30. Требуется бессрочная лицензия.
31. Требуется расположенная в Казахстане криптографическая система.
32. Требуется анализ поведения.
33. Требуется машинное обучение.
34. Требуются сигнатурные базы.
35. Требуется двухпанельный режим.
36. Требуется оценочный уровень 5.
37. Требуется реестр.
38. И требуется специальное письмо.
39. Это крайне узкая совокупность признаков.
40. Просим подтвердить ее конкурентность посредством указания минимум трех независимых решений.
41. По пункту 5.2 ситуация еще более специфична.
42. Помимо сертификации и реестра, прямо описывается внутренняя архитектура программного средства.
43. Оно должно быть DXE-драйвером.
44. Должно функционировать в составе UEFI.
45. Должно реализовывать аутентификацию до загрузки ОС.
46. Должно контролировать цифровые подписи компонентов загрузочной цепочки.
47. Должно защищать загрузочный сектор.
48. Должно вести журналы.
49. При этом требуется именно уровень доверия 5+.
50. Для определения соответствия следовало бы устанавливать функциональный результат, а не единственно допустимую программную архитектуру.
51. Например, Заказчику может быть необходим запрет неавторизованной загрузки.
52. Такой результат потенциально может обеспечиваться несколькими техническими способами.
53. Требование именно DXE-драйвера исключает альтернативные архитектуры.
54. Аналогично требование сервера определенного территориального расположения должно быть обосновано характером обрабатываемой информации.
55. В ТС не раскрыто, какие именно данные арт-терапевтического кабинета требуют оценочного уровня доверия 5 и 5+.
56. Если моноблок предназначается преимущественно для учебных, творческих и административных задач, необходимо пояснить соразмерность таких требований.
57. Иначе получается, что небольшая программная часть комплекта создает основной барьер для участия поставщиков всего кабинета.
58. Участник должен поставить столы, мольберты, светильники, холсты, фартуки, краски, карандаши, кисти, гипсовые модели и одновременно выполнить специализированные требования по информационной безопасности.
59. Более того, участник должен иметь доступ именно к правообладателям соответствующих программных решений.
60. Поставщики учебного оборудования и художественных принадлежностей, не имеющие заранее оформленного партнерства с ними, оказываются поставлены в менее выгодное положение.
61. Объединение таких разнородных товаров усиливает ограничивающий эффект письма.
62. Для поставки художественных принадлежностей участнику фактически необходимо получить разрешительную документацию правообладателя специализированного ПО.
63. Это не связано с его профессиональной способностью поставить основной объем предметов кабинета.
64. Просим либо исключить адресные письма, либо выделить специализированное ПО в отдельный предмет закупки, если Заказчик считает указанные средства информационной безопасности объективно необходимыми.
65. Предпочтительным является первый вариант — сохранение единой закупки при исключении требований, контролируемых третьими лицами.
66. Легальность ПО может проверяться непосредственно при поставке.
67. Сертификационные свойства продукта — по официальным реестрам и сертификатам.
68. Технические функции — по документации разработчика.
69. Таким образом, индивидуальное письмо является необязательным элементом проверки.
70. Просим также ввести прямую формулировку о допуске эквивалентных решений.
71. Эквивалентность должна определяться по результату: защита данных, контроль загрузки, антивирусная защита, управление доступом.
72. Не следует ограничивать ее конкретным способом внутренней реализации.
73. В противном случае совокупность требований может необоснованно сужать круг участников и создавать преимущество поставщикам конкретных программных продуктов.
