Cuando una dependencia no quiere pagar un software alegando fallas, no respondas solamente con capturas del sistema funcionando. Necesitas demostrar qué se contrató, qué se entregó y qué se recibió conforme.
La discusión debe separar lo que el contrato exigía de lo que sería deseable tener, porque no son lo mismo.
Empieza por los documentos que definen la obligación
Reúne:
Reúne las bases de licitación, la propuesta técnica y económica, el contrato, anexos y adendas. Relaciona cada requisito con manuales, entregables, actas de entrega-recepción, validaciones y comunicaciones sobre errores. El expediente debe mostrar qué se prometió, qué cambió por acuerdo y qué fue efectivamente entregado.
Después conserva versiones y pruebas de aceptación. Un acta puede acreditar recepción sin demostrar que todos los procesos funcionaban, mientras una lista tardía de fallas puede incluir mejoras que nunca estuvieron contratadas. La discusión debe separar defectos, cambios de alcance, infraestructura aportada por la dependencia y uso posterior del sistema.
En un caso real de software contratado por una dependencia, la discusión sobre pago y cumplimiento no pudo resolverse con una demostración en pantalla. Hubo que revisar bases de datos, contrato, entregables, actas y el uso que la propia institución había hecho del sistema. Esos elementos permitían separar lo entregado de lo prometido y una falla real de una explicación administrativa genérica.
El uso posterior no demostraba que todo funcionara perfectamente, así como una queja no demostraba que nada se hubiera entregado. La revisión identificó componentes, operaciones y periodos para saber qué estaba disponible y qué faltaba. También evitó atribuir al desarrollador inicial los cambios realizados por otros participantes después de la aceptación.
El proveedor debe conservar repositorios, versiones, comunicaciones y actas sin modificar la entrega para hacerla parecer más completa. El abogado relaciona los hallazgos con el contrato y el procedimiento administrativo; el peritaje documenta funcionamiento y límites. Reconocer defectos reales no debilita una reclamación: la hace precisa. La meta es que el pago y las obligaciones se discutan sobre hechos verificables, no sobre una presentación preparada para la ocasión.
El proveedor debe evitar modificar la versión original para hacerla pasar por la entregada. Si corrige, documenta qué cambió y cuándo. El análisis técnico debe reconocer lo que sí cumple y las limitaciones de la evaluación, mientras el abogado determina cómo se relacionan esos hechos con pago, aceptación y procedimiento administrativo.
Una mejor práctica puede ser recomendable, pero si no fue contratada, no necesariamente demuestra incumplimiento.
Compara requisito contra entrega
Construye una tabla:
- Qué se pidió.
- Qué se ofreció.
- Qué se entregó.
- Qué se validó.
- Qué objeción existe.
Si la dependencia firmó conformidad técnica, esa aceptación es evidencia relevante. No elimina posibles defectos posteriores, pero obliga a explicar qué cambió en la evaluación.
Una revisión independiente también sirve antes del conflicto
No todos los dictámenes nacen de una disputa. Una revisión preventiva puede documentar cumplimiento mientras nadie lo cuestiona.
Un tercero puede revisar contrato, entregables y acta de conformidad con metodología y preservación. Eso ayuda ante auditorías, cambios de administración o nuevas interpretaciones.
No conviertas defectos en simulación sin evidencia
Una falla real no implica automáticamente incumplimiento total ni fraude. Debes analizar:
- Si afecta requisitos contratados.
- Si impide operar.
- Si fue causada por proveedor, plataforma o cliente.
- Si fue reportada y atendida.
- Si hubo aceptación posterior.
Evita también que te acusen de defectos que solo existen por expectativas no contratadas.
Preserva evidencia técnica
Conserva código, versiones, configuración, manuales, actas y registros. No presentes solo el folleto comercial: el análisis debe incluir el sistema y sus archivos cuando sea necesario.
Si hay pruebas de funcionamiento, que sean reproducibles y documentadas con versión, entorno y resultados.
El pago debe discutirse con trazabilidad de aceptación
Un contrato de software gubernamental o sistema para una dependencia exige relacionar entregables, pruebas, observaciones y uso efectivo con el alcance contratado. Un acta de conformidad no responde toda la funcionalidad, y una lista tardía de errores no demuestra por sí sola incumplimiento total. El proveedor necesita preservar versiones; el abogado necesita separar requisitos, mejoras y dependencias de la contraparte. El análisis no revela código reservado ni convierte una demostración superficial en prueba completa.
Prueba entrega, aceptación y condiciones reales
Relaciona cada entregable con el contrato, el oficio de entrega, el ambiente y las personas receptoras. Si existieron pruebas de aceptación, conserva casos, resultados, observaciones y correcciones. Una lista de fallas elaborada mucho después debe compararse con lo que se recibió y utilizó durante la operación.
Documenta si la dependencia usó el sistema, cuánto tiempo y con qué datos. El uso no siempre equivale a aceptación jurídica total, pero es un hecho técnico que puede contrastar con la afirmación de que nunca funcionó. Evita presentar ese uso como respuesta automática a toda obligación.
Preserva código, versiones, bases de prueba, registros y manuales. No cambies el sistema para que pase una evaluación sin documentar la modificación. Si una corrección era necesaria, guarda la versión anterior y explica su relación con los requisitos contratados.
Revisa también la infraestructura a cargo de la dependencia: servidores, enlaces, certificados, licencias y permisos. Una falla por un componente que otra parte debía proporcionar no puede describirse honestamente como simple defecto de programación.
Separa requisitos originales, cambios solicitados y mejoras deseables. No todo lo que faltaría para hacer un producto ideal era parte del precio y del alcance. Con esa clasificación, la reclamación puede apoyarse en incumplimientos demostrables y no en una discusión genérica sobre si el software gustó o tenía aspecto moderno.
