Los agentes de IA me han permitido construir una herramienta en días. Conseguir que un desconocido se atreva a ejecutarla en su ordenador es otro trabajo.
Estos días he construido una primera versión de RosmarOps, una herramienta de seguridad para Windows. La mayor parte del código la han escrito agentes de IA bajo mi dirección. Lee la configuración de otros agentes de programación para mostrar qué pueden alcanzar. Trabaja localmente, sin conectarse a internet, y su código es abierto.
Y Windows muestra un aviso al intentar ejecutarla.
Me fastidia, claro. Sé para qué he construido el programa y qué he decidido dejar fuera. Pero quien lo descarga no ha estado conmigo mientras lo hacía. Lee mi explicación y tiene que decidir si se la cree. Las mismas promesas podría hacerlas alguien que quisiera robarle las claves.
Una parte del trabajo de estos días ha consistido en averiguar cómo consigue un desconocido que otro desconocido confíe en un .exe. He pasado de discutir con agentes cómo construir el programa a leer condiciones de firma, requisitos de publicación y documentación sobre reputación.
De momento, ahí los agentes me ayudan a buscar y comparar opciones. No pueden hacer que alguien se fíe de mí.
El programa funciona. Ahora falta que alguien lo instale
Conseguir que el programa funcione no acaba el trabajo. Quedan las pruebas, los errores que todavía no has visto y lo que ocurra al ejecutarlo en un ordenador distinto del tuyo. Luego vendrán las actualizaciones y las preguntas de los usuarios.
Lo que ha cambiado para mí es cuánto puedo avanzar solo antes de llegar a ese punto. Los agentes me han permitido construir una primera versión en días. Otros pueden hacer lo mismo, y quien busca una herramienta acaba teniendo más opciones que tiempo para examinarlas.
Y ahí aparece una pregunta que me interesa más que la velocidad de programación: cuando producir otra herramienta resulta mucho más fácil, ¿cómo decides cuál merece entrar en tu ordenador?
Publicar el código no basta para responder. Tener una web convincente, tampoco. Las dos cosas están al alcance de quien construye algo útil y de quien prepara un engaño.
He llegado antes a una primera versión. Conseguir que alguien la conozca, entienda para qué sirve y se atreva a instalarla sigue pendiente.
Por qué Windows avisa al abrir un programa desconocido
Un aviso en pantalla puede bastar para que cierres la ventana y te olvides del programa. Es comprensible. Pero, para quien lo desarrolla, importa saber qué está avisando Windows: la falta de reputación y la detección de malware son problemas distintos.
Microsoft explica que SmartScreen considera la reputación del archivo y del editor que lo firma. Un ejecutable nuevo puede provocar un aviso incluso con una firma válida. No basta con que yo sepa quién soy: el sistema necesita señales que pueda utilizar.
Además, mi herramienta trabaja en una zona delicada. Lee configuraciones relacionadas con permisos y acceso a claves. Eso hace especialmente razonable que quien la recibe quiera entender qué lee, qué guarda y qué podría salir de su máquina. Aunque ningún antivirus detectara malware, esas preguntas seguirían siendo razonables.
Sería cómodo pedirle al usuario que ignore el aviso porque el programa es mío y tengo buenas intenciones. Pero estaría pidiéndole precisamente el comportamiento que una herramienta de seguridad debería ayudar a evitar: confiar sin comprobar.
Lo que encontré al buscar cómo firmar el programa
Al revisar las opciones encontré varias restricciones que no conocía.
Según la documentación de Microsoft sobre firma de código, desde 2024 los certificados de validación extendida, los EV, ya no proporcionan el antiguo trato favorable automático de SmartScreen. Pagar más por ese certificado no compra la desaparición del aviso.
El servicio gestionado Azure Artifact Signing admite organizaciones de la Unión Europea, pero limita la modalidad para desarrolladores individuales a Estados Unidos y Canadá. Si desarrollas como particular desde España, esa limitación importa.
Y las condiciones de SignPath Foundation, que ofrece firma a determinados proyectos abiertos, excluyen de sus certificados ciertas herramientas que identifican vulnerabilidades explotables en el entorno donde se ejecutan. Hay excepciones, así que tendría que consultar si RosmarOps encaja antes de contar con esa vía.
SignPath explica por qué impone esas condiciones: el nombre que aparece en la firma es el suyo. Si algo sale mal, también se juega su reputación. Visto así, entiendo mejor que no baste con enseñarles un repositorio.
Una firma permite comprobar quién firma el archivo y si se ha alterado después. Saber si el programa hace algo peligroso exige mirar más cosas.
Quien escribe malware también tiene agentes de IA
En su informe de agosto de 2025, Anthropic describió casos de uso malicioso de Claude, entre ellos un actor con conocimientos básicos que lo empleó para desarrollar y vender ransomware. El informe recoge casos detectados por la compañía; no permite calcular cuánto malware se produce así. Sí muestra que alguien con pocos conocimientos pudo apoyarse en la IA para hacer daño.
Las restricciones que he encontrado no demuestran que las plataformas estén endureciendo sus reglas por la IA. Algunas vienen de antes. Mi preocupación es otra: si los atacantes también pueden producir más, ¿cuánto trabajo hará falta para separar sus programas de los demás?
Desde fuera, una web cuidada, un repositorio y una explicación técnica pueden parecer señales de trabajo serio. Cada vez conviene preguntarse más qué permiten comprobar realmente.
Y quien tiene que hacer esa comprobación dispone de un tiempo limitado, igual que yo.
Microsoft Store me abre una puerta, con sus condiciones
Una de las vías que estoy estudiando es la Microsoft Store. Microsoft anunció en septiembre de 2025 el registro gratuito para desarrolladores individuales. Para paquetes MSIX, la tienda gestiona la firma tras la certificación. La ruta de instaladores MSI o EXE tiene otros requisitos: el editor debe aportar su firma.
Eso resuelve el aviso de SmartScreen asociado a esa distribución. Otros controles de seguridad siguen ahí.
Como desarrollador pequeño, entiendo el atractivo. La tienda aporta infraestructura y una relación previa con el usuario que yo todavía no tengo. A cambio, debo encajar en sus requisitos, su revisión y sus decisiones.
Me ahorra trabajo y puede facilitar que alguien instale el programa. También hace que una parte del lanzamiento dependa de decisiones que no tomo yo.
Después de tantos años en marketing, la situación me resulta familiar. Puedes tener un producto y seguir sin acceso a quien podría usarlo. Una marca conocida tampoco se libra de los controles, pero al menos no tiene que empezar explicando quién es.
Si preguntas a un asistente qué herramienta usar, le delegas parte de esa selección. Es otra puerta por la que mi programa podría llegar a alguien, aunque documentarlo bien no me garantiza que vaya a recomendarlo.
¿Cómo compruebas que el ejecutable corresponde al código publicado?
Supongamos que te interesa el programa y quieres comprobarlo. Puedes abrir el repositorio y leer el código. Pero lo que vas a ejecutar es un archivo descargado. ¿Cómo sabes que una cosa corresponde a la otra?
El código abierto permite examinar lo que has publicado. No demuestra que alguien lo haya revisado ni que el ejecutable descargado corresponda a ese código.
Una compilación reproducible permite contrastar esa correspondencia. La definición de Reproducible Builds exige el mismo código, entorno e instrucciones para obtener los artefactos especificados idénticos, bit a bit. Hay que precisar qué archivo se compara y cómo se trata la firma digital. No basta con decir que compila en mi ordenador.
Las atestaciones de procedencia permiten verificar declaraciones sobre dónde y cómo se construyó un archivo. GitHub advierte expresamente que no garantizan que el resultado sea seguro. Un proceso perfectamente identificable puede producir software vulnerable.
Y si una herramienta ofrece una puntuación, publicar su método de cálculo permite discutirla, reproducirla y detectar sus límites. No convierte la fórmula en correcta por el mero hecho de enseñarla.
Me sirve separar estas comprobaciones porque evita prometer más de lo que puedo demostrar. Publicar el código, identificar la compilación y explicar una fórmula aportan información. Todavía queda revisar si ese código y esa fórmula hacen bien su trabajo.
El código está abierto. ¿Quién lo ha revisado?
No espero que quien descargue RosmarOps se ponga a compilarlo. Yo tampoco reviso el código de cada herramienta que utilizo. Si esa fuera la condición para instalar software, haríamos pocas cosas más durante el día.
Por eso importa que pueda revisarlo alguien con los conocimientos y el tiempo necesarios: un especialista, una comunidad o el equipo de seguridad de una empresa. Otros podremos apoyarnos en su trabajo. Mientras nadie lo haya hecho, el repositorio abierto ofrece la posibilidad de revisar, no una revisión.
Abrir el código me parece un buen comienzo. Después habrá que responder cuando aparezca un fallo, escuchar a quien cuestione un resultado y mantener el programa. Esa parte de la reputación se gana con el uso y con el tiempo.
No he descubierto que distribuir sea difícil. Lo que me ha sorprendido es llegar tan pronto a este punto: tengo una primera versión y todavía mucho trabajo por delante para que alguien se fíe de ella.
Al principio contaba los días que los agentes me habían ahorrado. Ahora estoy mirando qué necesita ver alguien antes de hacer doble clic. El programa es el mismo; el trabajo que tengo delante ha cambiado.
