Tu proveedor creó tu aplicación: ¿también eres dueño del código?

Una empresa paga por desarrollar su plataforma de ventas. Cuando intenta cambiar de proveedor descubre que el repositorio pertenece a la cuenta personal del desarrollador, varios servicios están registrados a nombre de la agencia, no existe documentación técnica y el contrato solamente habla de entregar una plataforma. La aplicación funciona, pero la empresa no sabe si puede modificarla, comercializarla o encargar su continuidad a otra persona. Pagar el desarrollo y recibir una contraseña no resuelve, por sí solos, esas preguntas.

Una aplicación no es una sola pieza. Puede integrar código fuente y código objeto, bases de datos, diseños, documentación, infraestructura en la nube, dominios, modelos de inteligencia artificial, bibliotecas de código abierto y servicios de terceros. Cada componente puede tener una persona titular, una licencia y condiciones de uso diferentes. Por eso el control empresarial debe revisarse en dos dimensiones: la jurídica, que define las facultades de explotación, y la operativa, que permite acceder, mantener y trasladar la solución.

La Ley Federal del Derecho de Autor protege los programas de computación —incluidos expresamente los de inteligencia artificial desde la reforma del 14 de mayo de 2026— como obras literarias, tanto en código fuente como en código objeto. Los derechos patrimoniales comprenden, entre otras facultades, autorizar o prohibir su reproducción, modificación, distribución, ingeniería inversa y comunicación pública. Tener una copia de los archivos o acceso temporal a una plataforma no equivale necesariamente a contar con todas esas facultades.

El contrato es el punto de control. La ley permite transmitir derechos patrimoniales u otorgar licencias, pero exige que esos actos consten por escrito. También contempla las obras realizadas por encargo y señala que los términos del contrato deben ser claros y precisos; en caso de duda prevalece la interpretación más favorable al autor. En consecuencia, no conviene basar la estrategia en una frase genérica como ‘entrega de la plataforma’. Deben definirse los entregables, los derechos, las modalidades de explotación, la remuneración y cualquier límite aplicable.

No debe confundirse el desarrollo por personal de la empresa con el realizado por un proveedor independiente. Para los programas creados por empleados en el ejercicio de sus funciones o siguiendo instrucciones del empleador, la ley contiene una regla específica sobre derechos patrimoniales, salvo pacto en contrario. Un contrato con una agencia, consultor o fábrica de software exige revisar las reglas de obra por encargo, transmisión o licencia y las circunstancias del proyecto. La factura acredita una operación comercial, pero no sustituye la precisión contractual.

Los componentes de terceros requieren una auditoría separada. Una biblioteca de código abierto puede permitir uso comercial y modificación, pero su licencia puede imponer condiciones de atribución, distribución, conservación de avisos o disponibilidad de código. Los servicios de nube, mapas, pagos, mensajería, modelos y analítica también pueden depender de suscripciones que no pertenecen al cliente. Solicita un inventario de dependencias, versiones, licencias, costos recurrentes y cuentas asociadas antes de aceptar el entregable.

El repositorio debe estar bajo una cuenta institucional, con administradores designados, autenticación robusta y mecanismos de recuperación. La empresa necesita recibir el historial de versiones, ramas activas, instrucciones de despliegue, variables y secretos gestionados por un medio seguro, arquitectura, esquema de base de datos y documentación suficiente para operar. No publiques credenciales en el repositorio ni las intercambies dentro de anexos contractuales; documenta el procedimiento para entregarlas, rotarlas y revocarlas.

Conviene convertir cada hito de pago en una recepción verificable. Define qué versión se entrega, qué pruebas debe superar, dónde quedará almacenada, qué documentación la acompaña, quién la acepta y cómo se corregirán defectos. Conserva evidencia de las versiones recibidas y evita que el último pago dependa únicamente de una demostración visual. Una aplicación desplegada puede ocultar dependencias, accesos o componentes que solamente serán visibles al revisar el repositorio y la infraestructura.

Tu checklist de recepción tecnológica debe incluir: descripción de entregables; código fuente y objeto; repositorio institucional; derechos transmitidos o licenciados; facultades de modificar, reproducir y comercializar; componentes y licencias de terceros; bases de datos y documentación; infraestructura y servicios externos; credenciales y recuperación; garantía y corrección de errores; mantenimiento y niveles de servicio; confidencialidad y seguridad; transición a otro proveedor; y evidencia de aceptación de cada versión. La lista debe adaptarse al contrato y al modelo de operación.

Haz una prueba antes de cerrar el proyecto: pide a una persona técnica que no participó en el desarrollo localizar el repositorio, desplegar una versión en un entorno seguro y explicar qué servicios necesita para funcionar. Después verifica con el equipo jurídico qué derechos tiene la empresa sobre cada componente relevante. Si otro proveedor no podría continuar mañana sin depender de cuentas personales o autorizaciones pendientes, la recepción todavía no está completa. La continuidad digital se construye antes del cambio de proveedor, no durante la crisis.