La respuesta corta
Según la Ley 14.133/2021, la contratación de software por un órgano público brasileño empieza en la planificación: un estudio técnico preliminar que justifica la necesidad y compara soluciones, seguido de unos términos de referencia que describen qué se entregará y cómo se aceptará. Después vienen la selección del proveedor y la fiscalización del contrato.
En los proyectos de software, lo que más define el resultado es la calidad de esa planificación. Unos términos de referencia que fijan requisitos de accesibilidad, protección de datos, registro de movimientos, ritos de entrega y criterios de aceptación le dan al fiscal qué medir y al proveedor qué cumplir. Este texto es una guía general: los detalles de cada órgano siguen sus normas internas y la orientación de su asesoría jurídica.
Cómo funciona la contratación pública de software según la Ley 14.133/2021
La nueva ley de licitaciones de Brasil organiza la contratación en fases. La primera, preparatoria, es donde el órgano planifica: describe la necesidad, estudia las alternativas, estima el valor, evalúa los riesgos y define las reglas del proceso. Luego vienen la selección del proveedor y, después de la firma, la ejecución del contrato, acompañada por un gestor y fiscales designados.
La ley también valora el plan anual de contrataciones, la gestión de riesgos y la segregación de funciones, para que quien planifica, quien juzga y quien fiscaliza no sean siempre la misma persona. La modalidad y el criterio de adjudicación dependen del objeto y los define el área de licitaciones con el apoyo de la asesoría jurídica.
En software hay dos situaciones muy distintas. Una es contratar el uso de un sistema que ya existe, como licencia o servicio en la nube. La otra es contratar el desarrollo de un sistema a medida para el órgano. La planificación cambia bastante de una a otra, y el estudio técnico preliminar es el lugar indicado para hacer esa elección.
El estudio técnico preliminar va antes que todo
El estudio técnico preliminar, conocido en Brasil como ETP, es el documento que muestra que la contratación tiene sentido. Describe el problema que hay que resolver, releva las soluciones posibles en el mercado, compara los caminos y justifica la elección. También es donde el órgano estima cantidades e identifica los requisitos que orientarán los términos de referencia.
Para software, un buen ETP responde preguntas prácticas: qué rutina debe atender el sistema, quién lo usará (servidor, ciudadano, gestión), con qué sistemas debe comunicarse, qué datos personales tratará y si una solución de mercado resuelve o el caso pide desarrollo. Escuchar en esta fase a quien ejecuta el proceso a diario evita unos términos de referencia escritos solo a partir de la herramienta que alguien ya conoce.
Este relevamiento tiene mucho en común con lo que hacemos en el estudio inicial de un proyecto privado, y el razonamiento de cómo definir el alcance de un software también sirve aquí.
Qué deben incluir los términos de referencia de software
Los términos de referencia son el documento que el proveedor cumplirá y que el fiscal usará para medir. Para un sistema, deben cubrir como mínimo:
- Objeto y necesidad. Qué se contratará y qué problema de la administración resuelve, vinculado a lo que concluyó el ETP.
- Requisitos funcionales. Las rutinas que el sistema debe atender, descritas por lo que hace el usuario, y no por la tecnología.
- Requisitos no funcionales. Accesibilidad, seguridad, protección de datos, rendimiento, disponibilidad y registro de movimientos.
- Modelo de ejecución. Cómo se organizará el trabajo en entregas, con qué ritmo y con qué entornos de prueba y de producción.
- Criterios de aceptación y de medición. Qué debe estar funcionando para que cada entrega sea recibida y cómo se evaluará la calidad.
- Propiedad y transición. De quién son el código y la documentación, cómo se devuelven los datos y cómo pasa el sistema a otro equipo al final del contrato.
- Garantía y soporte. Durante cuánto tiempo el proveedor corrige defectos y cómo funcionan los tickets después de la entrega.
El punto de la propiedad merece atención especial. La Ley 14.133/2021 prevé, como regla, que en las contrataciones de desarrollo de software los derechos patrimoniales se cedan a la administración, y los términos de referencia deben tratarlo junto con la entrega del código y la documentación. El tema está detallado en de quién es el código del software a medida.
Accesibilidad, LGPD y registro de movimientos
Tres exigencias aparecen en prácticamente todo sistema público y deben estar en los términos de referencia como requisito, y no como recomendación.
La primera es la accesibilidad. La Ley Brasileña de Inclusión hace obligatoria la accesibilidad en los sitios mantenidos por órganos de gobierno. En la práctica, los sistemas siguen el eMAG, el Modelo de Accesibilidad en Gobierno Electrónico de Brasil, y las pautas internacionales WCAG, del W3C. Conviene pedir al proveedor que revise la accesibilidad en el diseño, antes de que se convierta en código, y que pruebe con lector de pantalla y navegación por teclado antes de cada entrega.
La segunda es la LGPD, la ley brasileña de protección de datos, que tiene reglas específicas para el tratamiento de datos por el poder público. El sistema debe tratar solo los datos necesarios para la finalidad, con control de acceso por perfil, y el contrato debe definir el papel del proveedor en el tratamiento de esos datos.
La tercera es el registro de movimientos: quién hizo qué, cuándo y en qué registro. En un sistema público, ese historial es lo que permite responder a una solicitud de acceso a la información, a un cuestionamiento del control interno o a un reclamo del ciudadano.
En Ágil Cidadão, nuestro sistema de atención al ciudadano, cada movimiento de una solicitud queda registrado con autor, fecha, mensaje y adjunto, la gestión define por perfil quién ve cada servicio y la interfaz usa componentes accesibles. Son ejemplos de cómo estos requisitos se convierten en funcionalidades concretas.
Ritos de entrega y aceptación del sistema
El software contratado en una única entrega al final del plazo es el escenario de mayor riesgo para el órgano: el problema solo aparece cuando ya no hay tiempo de corregirlo. La ley prevé la recepción provisoria y la definitiva del objeto, y los términos de referencia pueden organizar el desarrollo en entregas parciales, cada una con su aceptación.
Un rito que funciona bien tiene cuatro momentos: planificar qué entra en el ciclo y cuál es el criterio de aceptación de cada ítem, mostrar el sistema funcionando al final del ciclo, dejar que el equipo del órgano pruebe en un entorno de homologación y registrar formalmente la aceptación o las pendientes. Es la misma lógica de los sprints con demostración que describimos en cómo trabajamos.
Cuanto más claro el criterio de aceptación, menos espacio para discusión en la recepción. "El ciudadano puede abrir una solicitud desde el celular, adjuntar documentos y recibir un número de protocolo" es verificable. "Sistema de protocolo moderno e intuitivo" no lo es.
Documentación para la fiscalización del contrato
El fiscal del contrato necesita evidencia para certificar cada entrega, y esa evidencia debe producirse durante la ejecución, y no armarse a las apuradas al final. Los términos de referencia pueden exigir al proveedor, en cada entrega:
| Documento | Qué muestra | Por qué le importa al fiscal |
|---|---|---|
| Informe de la entrega | Lo que se hizo en el ciclo, vinculado a los ítems de los términos de referencia | Permite comparar lo ejecutado con lo contratado |
| Registro de la aceptación | Ítems aprobados, pendientes y quién aprobó | Respalda la recepción y la liberación del pago |
| Notas de versión | Qué cambió en el sistema en cada publicación | Ayuda a rastrear defectos y responder cuestionamientos |
| Documentación técnica | Arquitectura, instalación, integraciones y accesos | Garantiza la continuidad del sistema al final del contrato |
| Informe de accesibilidad y seguridad | Pruebas realizadas y problemas corregidos | Comprueba el cumplimiento de los requisitos no funcionales |
Los proveedores que ya documentan decisiones, versiones y riesgos como parte de su método entregan esa evidencia sin esfuerzo adicional. Al evaluar propuestas y en la reunión inicial del contrato, conviene pedir ejemplos de ese material. Si la duda es qué implica un sistema a medida, la página de desarrollo de software a medida resume los frentes de trabajo de un proyecto.