El desarrollo de software es una actividad técnica, creativa, económica y jurídica. No consiste únicamente en escribir instrucciones en un lenguaje de programación: comprende el análisis de una necesidad, el diseño de una solución, la selección de tecnologías, la programación, las pruebas, la implementación, el mantenimiento y la evolución permanente del sistema.
1. Concepto de software
El software puede definirse como el conjunto organizado de instrucciones, datos, estructuras, configuraciones y componentes que permiten que un dispositivo informático ejecute determinadas funciones.
- Hardware: componentes físicos, como procesadores, discos, memorias, servidores y dispositivos.
- Software: instrucciones y elementos lógicos que hacen funcionar el hardware.
- Firmware: software incorporado en dispositivos electrónicos para controlar su funcionamiento básico.
- Datos: información que el software recibe, almacena, transforma o transmite.
Un sistema informático moderno puede comprender:
- código fuente;
- código compilado o ejecutable;
- bases de datos;
- interfaces gráficas;
- archivos de configuración;
- manuales y documentación técnica;
- servicios web y API;
- bibliotecas y dependencias;
- pruebas automatizadas;
- scripts de instalación;
- infraestructura como código;
- certificados, claves y secretos;
- modelos de inteligencia artificial;
- documentación jurídica y contractual.
No todos estos elementos reciben necesariamente la misma protección jurídica. Por eso, al definir la titularidad de un proyecto no basta con afirmar que una parte es “dueña del programa”: debe precisarse qué componentes comprende esa titularidad.
2. Ciclo de vida del desarrollo de software
2.1. Relevamiento y análisis de requisitos
En esta etapa se determina qué problema debe resolverse, quién utilizará el sistema y qué funciones deberá cumplir.
- Requisitos funcionales: qué debe hacer el sistema.
- Requisitos no funcionales: rendimiento, seguridad, disponibilidad, portabilidad, escalabilidad y facilidad de uso.
- Requisitos jurídicos: protección de datos, trazabilidad, consentimiento, conservación y auditoría.
- Requisitos operativos: plataformas, servidores, respaldos, soporte y recuperación.
2.2. Diseño y arquitectura
Se define la estructura general del sistema: módulos, capas, bases de datos, API, interfaces, autenticación, infraestructura, integraciones externas y reglas de seguridad.
Entre las arquitecturas posibles se encuentran:
- aplicaciones monolíticas;
- sistemas cliente-servidor;
- microservicios;
- aplicaciones web y móviles;
- sistemas distribuidos;
- servicios en la nube;
- sistemas embebidos;
- sistemas en tiempo real;
- arquitecturas orientadas a eventos.
La elección técnica puede tener consecuencias jurídicas. El uso de una nube extranjera puede implicar transferencias internacionales de datos; una biblioteca puede imponer obligaciones de licencia; y una plataforma cerrada puede provocar dependencia tecnológica.
2.3. Programación
La programación consiste en escribir el código fuente mediante lenguajes como:
- Python: automatización, análisis de datos, inteligencia artificial y aplicaciones web.
- C y C++: sistemas operativos, software embebido, videojuegos y alto rendimiento.
- C#: aplicaciones empresariales, servicios web y software de escritorio.
- Java: sistemas empresariales, servidores y aplicaciones Android.
- JavaScript y TypeScript: aplicaciones web, servidores y soluciones multiplataforma.
- Go: servicios de red, infraestructura y sistemas distribuidos.
- Rust: software de sistemas con énfasis en seguridad de memoria.
- Dart y Flutter: aplicaciones móviles, web y de escritorio.
- SQL: consulta y administración de bases de datos relacionales.
2.4. Pruebas
Las pruebas pueden ser:
- unitarias;
- de integración;
- funcionales;
- de regresión;
- de rendimiento;
- de carga y estrés;
- de seguridad;
- de usabilidad;
- de accesibilidad;
- de compatibilidad;
- de recuperación;
- de aceptación.
El contrato debería determinar quién prueba, qué entorno se emplea, qué defectos impiden la aceptación, qué plazo tiene el cliente para formular observaciones y cuándo se considera aceptada una entrega.
2.5. Implementación y despliegue
Es el proceso de instalar y poner el software en funcionamiento, ya sea en equipos del cliente, servidores propios, servicios de nube, tiendas de aplicaciones o contenedores.
Deben definirse responsabilidades sobre:
- dominios y certificados digitales;
- cuentas de nube y servidores;
- bases de datos;
- credenciales;
- copias de seguridad;
- actualizaciones;
- disponibilidad y recuperación.
2.6. Mantenimiento y evolución
El mantenimiento puede ser:
- Correctivo: reparación de errores.
- Adaptativo: adecuación a cambios técnicos o normativos.
- Perfectivo: mejora de funciones existentes.
- Preventivo: reducción de riesgos futuros.
- De seguridad: corrección de vulnerabilidades.
- Evolutivo: incorporación de nuevas funciones.
Debe distinguirse entre garantía por defectos y mantenimiento evolutivo. Corregir un error preexistente no equivale a desarrollar gratuitamente nuevas funciones.
3. Características que debe tener un buen software
Un software de calidad no se mide solamente por su apariencia o por la cantidad de funciones que ofrece. Debe satisfacer atributos técnicos verificables, que suelen expresarse como requisitos no funcionales.
Exactitud
Debe producir resultados correctos conforme a las reglas funcionales y jurídicas definidas.
Fiabilidad
Debe funcionar de forma consistente durante el período y bajo las condiciones previstas.
Robustez
Debe manejar entradas inválidas, fallos externos y condiciones adversas sin bloquearse indebidamente.
Seguridad
Debe proteger la confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad.
Disponibilidad
Debe estar operativo cuando los usuarios lo necesitan, conforme al nivel de servicio pactado.
Rendimiento
Debe responder con rapidez razonable y utilizar eficientemente CPU, memoria, red y almacenamiento.
Escalabilidad
Debe soportar un crecimiento de usuarios, operaciones o datos sin degradación inaceptable.
Portabilidad
Debe poder trasladarse a otras plataformas o infraestructuras con cambios controlados.
Compatibilidad
Debe funcionar junto con los sistemas operativos, navegadores, dispositivos y formatos previstos.
Interoperabilidad
Debe intercambiar datos con otros sistemas y comprender correctamente su estructura y significado.
Usabilidad
Debe ser comprensible, coherente, fácil de aprender y tolerante a errores humanos.
Accesibilidad
Debe poder ser utilizado por personas con diferentes capacidades físicas, sensoriales o cognitivas.
Mantenibilidad
Debe poder corregirse, actualizarse y ampliarse mediante código claro, modular y documentado.
Auditabilidad
Debe permitir reconstruir acciones, usuarios, fechas, versiones y cambios relevantes.
Recuperabilidad
Debe poder restaurar datos y operaciones después de un fallo o incidente.
Resiliencia
Debe aislar fallos, continuar parcialmente operativo y recuperarse de manera controlada.
3.1. Exactitud o corrección
La exactitud significa que el software realiza los cálculos correctamente, aplica las reglas de negocio, procesa los datos sin alterarlos indebidamente y genera resultados coherentes.
Un programa de liquidación laboral, por ejemplo, debe calcular correctamente salarios, licencias, aguinaldo, indemnizaciones y descuentos. Un error puede producir consecuencias económicas y jurídicas relevantes.
3.2. Fiabilidad o confiabilidad
Es la capacidad de funcionar correctamente durante un período determinado y bajo condiciones definidas. Puede medirse mediante frecuencia de fallos, tiempo medio entre fallos, tasa de errores, tiempo de recuperación y porcentaje de operaciones exitosas.
3.3. Robustez
Un sistema robusto valida entradas, maneja excepciones, informa errores, utiliza transacciones y falla de manera controlada. Debe poder responder ante datos incompletos, archivos dañados, interrupciones de red o servicios externos indisponibles.
3.4. Seguridad
La seguridad debe incorporarse desde el diseño. Comprende autenticación, autorización, cifrado, gestión de sesiones, mínimos privilegios, trazabilidad, actualización de dependencias, copias de seguridad y respuesta ante incidentes.
3.5. Disponibilidad
Puede expresarse mediante porcentajes de tiempo activo y regularse en un Acuerdo de Nivel de Servicio o SLA. Deben precisarse mantenimientos programados, exclusiones, tiempos de respuesta y compensaciones.
3.6. Rendimiento y eficiencia
Un sistema puede ser funcionalmente correcto y resultar inútil si tarda demasiado en responder. Las métricas pueden incluir tiempo de respuesta, transacciones por segundo, consumo de CPU, memoria, latencia y usuarios concurrentes.
3.7. Escalabilidad
La escalabilidad puede ser:
- Vertical: aumentar los recursos de un servidor.
- Horizontal: agregar servidores o instancias.
- Funcional: incorporar nuevos módulos.
- Geográfica: atender usuarios en nuevas regiones.
- Organizacional: soportar múltiples empresas o dependencias.
3.8. Portabilidad
La portabilidad reduce la dependencia tecnológica y facilita la migración entre sistemas operativos, servidores, proveedores de nube y bases de datos. Puede lograrse mediante estándares abiertos, contenedores, lenguajes multiplataforma y separación entre lógica e infraestructura.
3.9. Interoperabilidad
La interoperabilidad comprende dimensiones técnicas, sintácticas, semánticas, organizacionales y jurídicas. Puede implementarse mediante API, JSON, XML, CSV, protocolos abiertos y estándares sectoriales.
3.10. Usabilidad y accesibilidad
La usabilidad procura que el sistema sea comprensible, intuitivo y eficiente. La accesibilidad procura que pueda ser utilizado por personas con diferentes capacidades, mediante navegación por teclado, lectores de pantalla, contraste adecuado, textos alternativos y formularios correctamente etiquetados.
3.11. Mantenibilidad, modularidad y extensibilidad
Un software mantenible debe poseer código claro, módulos separados, documentación, pruebas automatizadas y control de versiones. La modularidad facilita sustituir componentes; la extensibilidad permite incorporar nuevas funciones sin reescribir todo el sistema.
3.12. Auditabilidad y trazabilidad
El sistema debería permitir reconstruir quién realizó una acción, cuándo, qué datos modificó, qué versión estaba activa y qué decisión automatizada se produjo. Esta característica es especialmente relevante en sistemas jurídicos, financieros, sanitarios y administrativos.
3.13. Recuperabilidad
Dos conceptos habituales son:
- RPO: cantidad máxima admisible de datos que podrían perderse.
- RTO: tiempo máximo aceptable para recuperar el servicio.
No basta con realizar copias de seguridad: es necesario probar periódicamente que pueden restaurarse.
3.14. Documentación y observabilidad
La documentación puede incluir manuales, arquitectura, modelo de datos, API, procedimientos de respaldo, despliegue, recuperación, mantenimiento y licencias. La observabilidad se apoya en registros, métricas, trazas y alertas.
3.15. Cumplimiento normativo
Según el sector, el software puede necesitar cumplir normas sobre protección de datos, consumo, propiedad intelectual, firma electrónica, accesibilidad, ciberseguridad, archivo documental, regulación financiera, salud o transparencia.
4. Metodologías de desarrollo
4.1. Modelo en cascada
Divide el proyecto en etapas sucesivas: análisis, diseño, programación, pruebas e implementación. Puede ser adecuado cuando los requisitos son estables.
4.2. Metodologías ágiles
Dividen el trabajo en ciclos breves e incrementales. Entre los enfoques más conocidos se encuentran Scrum, Kanban, programación extrema y desarrollo iterativo.
El contrato debería regular:
- prioridades e iteraciones;
- responsables de aprobar tareas;
- criterios de aceptación;
- cambios de alcance;
- presupuesto y horas;
- registro de decisiones.
4.3. DevOps y DevSecOps
DevOps integra desarrollo y operaciones. DevSecOps incorpora la seguridad durante todo el ciclo, mediante análisis automático, pruebas, control de secretos, revisión de dependencias, firma de artefactos y trazabilidad.
5. Protección jurídica del software en Uruguay
5.1. Derecho de autor
En Uruguay, el software se protege principalmente por el régimen de derecho de autor de la Ley N.º 9.739 y sus modificaciones. La protección comprende el código fuente, el código objeto y otras expresiones originales vinculadas con el programa.
La protección recae sobre la forma concreta de expresión, no sobre las ideas, procedimientos, métodos de operación o conceptos matemáticos considerados en sí mismos.
La idea abstracta de “crear una aplicación para administrar estudios jurídicos” no queda monopolizada. Lo protegido es la expresión concreta del código, la documentación, la estructura original y los demás elementos creativos.
5.2. Código fuente y código objeto
El código fuente es el texto escrito por los programadores. El código objeto es el resultado ejecutable de compilar o transformar ese código.
La entrega del ejecutable no implica necesariamente la entrega del código fuente. El contrato debe decir expresamente si se entrega, cuándo, en qué repositorio, con qué documentación y con qué facultades de modificación, distribución o sublicenciamiento.
5.3. Derechos patrimoniales y morales
Los derechos patrimoniales permiten autorizar o prohibir reproducción, distribución, adaptación, transformación, comunicación y comercialización. La adquisición de una copia no equivale a adquirir estos derechos.
También deben considerarse los derechos vinculados con la autoría, los créditos, las modificaciones y la relación personal del creador con la obra.
6. Titularidad del software
Determinar quién escribió el código no resuelve automáticamente quién puede explotarlo económicamente. Pueden intervenir programadores, diseñadores, arquitectos, empleados, contratistas, empresas, clientes y proveedores externos.
6.1. Desarrollo independiente
La persona que desarrolla un programa por iniciativa propia suele ser titular originaria de su contribución. Es conveniente conservar repositorios, archivos originales, correos, versiones, documentación y constancias registrales.
6.2. Relación laboral o encargo
La legislación uruguaya contiene presunciones específicas para programas de ordenador y bases de datos realizados dentro de determinadas relaciones laborales o de encargo. Sin embargo, sigue siendo recomendable regular por escrito:
- qué software está comprendido;
- qué desarrollos previos conserva el programador;
- si la cesión es exclusiva;
- territorio y plazo;
- derecho a sublicenciar;
- documentación y bases de datos;
- reutilización de componentes genéricos;
- cadena de titularidad.
6.3. Desarrollo colaborativo
Los proyectos con varios colaboradores deberían utilizar acuerdos de contribución, declaraciones de autoría, cesiones o licencias, políticas de incorporación de código e identificación de dependencias.
7. Registro de software en Uruguay
La protección no depende necesariamente de la inscripción. Sin embargo, el registro puede ser útil para documentar la existencia, denominación, versión, fecha, autoría, titularidad y determinados actos de transferencia.
El registro no sustituye la cadena contractual. Si participaron varias personas, el solicitante debería poder acreditar cómo adquirió los derechos sobre cada contribución.
8. Software y patentes
El software se protege principalmente por derecho de autor. La legislación uruguaya excluye, en principio, los programas de computación considerados aisladamente del concepto de invención patentable.
Una solución tecnológica que combine software con componentes físicos o con un procedimiento técnico puede requerir un análisis específico sobre novedad, actividad inventiva, aplicación industrial y carácter técnico.
9. Licencias de software
Una licencia es la autorización mediante la cual el titular permite a otra persona realizar determinados actos respecto del software. Puede delimitar usuarios, dispositivos, territorio, plazo, finalidad, modificación, distribución, sublicenciamiento, soporte, actualizaciones e ingeniería inversa.
9.1. Software propietario
El titular reserva la mayoría de los derechos y permite solamente los usos expresamente autorizados. Normalmente restringe el acceso al código fuente, la copia, la modificación y la redistribución.
Ventajas
- mayor control sobre la explotación;
- posibilidad de cobrar licencias o suscripciones;
- protección del código como secreto empresarial;
- control centralizado de versiones.
Desventajas
- dependencia del proveedor;
- menor capacidad de auditoría;
- riesgo de discontinuación;
- costos recurrentes;
- dificultades de migración.
9.2. Freeware
Es software gratuito cuyo titular conserva el control jurídico. Puede mantener cerrado el código, prohibir modificaciones, limitar el uso comercial o incorporar publicidad. “Gratuito” describe el precio, no la libertad jurídica.
9.3. Shareware, trial y freemium
El shareware o trial limita el tiempo o las funciones. El modelo freemium ofrece una versión básica gratuita y cobra por funciones avanzadas. Deben informarse claramente precios, renovaciones, cancelación y tratamiento de datos.
9.4. Software libre
El software libre concede libertades para:
- ejecutar el programa;
- estudiar su funcionamiento;
- modificarlo;
- copiarlo y redistribuirlo;
- distribuir versiones modificadas.
Software libre no significa necesariamente gratuito. Puede cobrarse por copias, instalación, personalización, soporte, alojamiento o servicios empresariales.
9.5. Código abierto
El software de código abierto se distribuye bajo una licencia que permite acceder al código, utilizarlo, modificarlo y compartirlo dentro de determinadas condiciones.
9.6. Licencias permisivas
MIT
Permite usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y vender copias, con la obligación principal de conservar el aviso de copyright y la licencia.
BSD
Tiene un funcionamiento similar a MIT. Algunas variantes incluyen reglas sobre el uso del nombre de los autores para promocionar productos derivados.
Apache License 2.0
Es permisiva, pero regula de forma más detallada los avisos, las patentes de
colaboradores y el archivo NOTICE.
9.7. Licencias copyleft
GPL
Es una licencia de copyleft fuerte. Cuando se distribuye una obra derivada, normalmente debe facilitarse el código fuente y mantenerse la licencia correspondiente.
LGPL
Se utiliza principalmente para bibliotecas y permite, bajo ciertas condiciones, su vinculación con aplicaciones que no están íntegramente bajo GPL.
MPL 2.0
Aplica un copyleft limitado principalmente al nivel de archivo, lo que permite combinar archivos MPL con otros sujetos a licencias diferentes.
AGPL
Extiende determinadas obligaciones de acceso al código fuente a sistemas modificados que se utilizan a través de una red.
9.8. Comparación básica de licencias
| Licencia | Tipo | Uso comercial | Integración propietaria | Obligación principal |
|---|---|---|---|---|
| MIT | Permisiva | Sí | Sí | Conservar aviso y licencia. |
| BSD | Permisiva | Sí | Sí | Conservar avisos y cumplir la variante aplicable. |
| Apache 2.0 | Permisiva | Sí | Sí | Avisos, licencia y regulación de patentes. |
| MPL 2.0 | Copyleft limitado | Sí | Sí, bajo condiciones | Mantener bajo MPL los archivos cubiertos y modificados. |
| LGPL | Copyleft débil | Sí | Generalmente sí | Compartir modificaciones de la biblioteca y cumplir requisitos de vinculación. |
| GPL | Copyleft fuerte | Sí | Generalmente no en una obra derivada cerrada distribuida | Distribuir el código correspondiente bajo GPL. |
| AGPL | Copyleft fuerte de red | Sí | Generalmente no para la obra cubierta | Ofrecer el código ante interacción remota con una versión modificada. |
9.9. Código visible no equivale a código abierto
Una licencia puede permitir examinar el código y, al mismo tiempo, prohibir el uso comercial, la modificación, la distribución o la competencia. En esos casos se habla de source available, no necesariamente de software libre o de código abierto.
9.10. Licenciamiento dual
Un mismo programa puede ofrecerse bajo una licencia libre para determinados usos y bajo una licencia comercial para empresas que desean integrarlo en productos propietarios. Para ello, quien licencia debe tener derechos suficientes sobre todas las contribuciones.
10. Software como servicio — SaaS
En el modelo SaaS, el usuario accede al programa mediante Internet y normalmente no recibe una copia completa ni la propiedad del software.
El contrato debería regular:
- niveles de servicio;
- disponibilidad;
- mantenimiento;
- respaldos;
- recuperación;
- propiedad de los datos;
- exportación;
- interoperabilidad;
- confidencialidad;
- subcontratistas;
- ubicación de servidores;
- incidentes;
- suspensión;
- eliminación de información;
- terminación;
- migración.
11. Dependencias y cadena de suministro
Casi ningún software moderno se desarrolla completamente desde cero. Se utilizan frameworks, bibliotecas, paquetes, imágenes de contenedores, sistemas operativos, API, bases de datos, servicios de nube y herramientas de compilación.
Cada dependencia puede tener:
- una licencia diferente;
- obligaciones de atribución;
- vulnerabilidades;
- componentes transitivos;
- restricciones contractuales;
- patentes asociadas.
Medidas recomendables:
- mantener un inventario de componentes;
- registrar versiones;
- conservar textos de licencia;
- generar un listado de atribuciones;
- analizar vulnerabilidades;
- actualizar dependencias;
- utilizar un SBOM;
- revisar la procedencia del código.
Dos componentes pueden ser técnicamente compatibles y jurídicamente incompatibles. La compatibilidad debe analizar obligaciones de copyleft, patentes, atribución, forma de vinculación y distribución conjunta.
12. Protección de datos personales
Cuando el software trata datos personales, su diseño debe incorporar las obligaciones de la Ley N.º 18.331. No basta con publicar una política de privacidad: deben existir medidas técnicas y organizativas efectivas.
12.1. Privacidad desde el diseño
- recopilar solamente los datos necesarios;
- separar bases de datos;
- cifrar información;
- limitar accesos;
- registrar operaciones;
- establecer plazos de conservación;
- anonimizar o seudonimizar cuando corresponda;
- facilitar el ejercicio de derechos;
- documentar transferencias.
12.2. Privacidad por defecto
La configuración inicial debe ser razonablemente protectora: mínima recopilación, permisos limitados, conservación temporal y desactivación inicial de funciones invasivas.
13. Seguridad informática
La seguridad debe formar parte de todo el ciclo de desarrollo. Entre los riesgos frecuentes se encuentran:
- contraseñas débiles;
- credenciales en el código;
- inyección de instrucciones;
- controles de acceso deficientes;
- falta de cifrado;
- bibliotecas vulnerables;
- errores de configuración;
- validación insuficiente;
- permisos excesivos;
- API sin protección;
- sesiones inseguras;
- copias de seguridad deficientes.
Entre las prácticas recomendables se encuentran:
- modelado de amenazas;
- revisión de código;
- análisis estático y dinámico;
- pruebas autorizadas;
- autenticación multifactor;
- mínimos privilegios;
- cifrado;
- separación de entornos;
- gestión de secretos;
- auditoría;
- copias de seguridad;
- firma de versiones.
14. Contratos de desarrollo de software
Un contrato debería regular, como mínimo, los siguientes elementos:
14.1. Objeto y alcance
- sistema, módulos y plataformas;
- usuarios e integraciones;
- documentación y entregables;
- funciones incluidas y excluidas;
- servicios y costos externos;
- alojamiento y mantenimiento.
14.2. Requisitos de calidad
Deben definirse exactitud, robustez, seguridad, disponibilidad, rendimiento, escalabilidad, portabilidad, compatibilidad, accesibilidad, mantenibilidad, interoperabilidad y recuperación mediante criterios medibles.
14.3. Cronograma y precio
Deben establecerse hitos, entregas parciales, dependencias, obligaciones del cliente, modalidad de pago y consecuencias de retrasos.
14.4. Cambios de alcance
- solicitar el cambio;
- analizar su impacto;
- presupuestarlo;
- aprobarlo;
- actualizar el cronograma;
- documentarlo.
14.5. Criterios de aceptación
Debe precisarse quién prueba, durante cuánto tiempo, qué constituye un defecto, qué gravedad impide aceptar y cómo se corrigen las observaciones.
14.6. Propiedad intelectual
Deben regularse autoría, titularidad, cesión o licencia, exclusividad, territorio, plazo, sublicencias, desarrollos previos, dependencias, código fuente y documentación.
14.7. Confidencialidad
Debe protegerse el código, las credenciales, las bases de datos, los modelos de negocio, los secretos empresariales, la información personal y la arquitectura de seguridad.
14.8. Mantenimiento y soporte
Deben definirse horarios, canales, tiempos de respuesta, clasificación de incidentes, actualizaciones, versiones, costos y exclusiones.
14.9. Responsabilidad
Conviene regular fallos, inexactitud, pérdida de datos, indisponibilidad, incidentes de seguridad, infracción de derechos, límites de responsabilidad y fuerza mayor.
14.10. Terminación y salida
Debe preverse entrega de código, exportación de datos, devolución de información, eliminación de copias, migración, transferencia de credenciales y asistencia de transición.
15. Depósito o escrow del código fuente
El escrow consiste en depositar el código fuente y su documentación ante un tercero para que sean entregados al cliente si ocurre un supuesto pactado, como insolvencia, abandono del mantenimiento, cierre de la empresa o incumplimiento grave.
El depósito debe actualizarse con cada versión importante. Un código desactualizado, sin documentación ni instrucciones de compilación, puede carecer de utilidad práctica.
16. Inteligencia artificial en el desarrollo
Los asistentes de inteligencia artificial pueden generar código, documentar, crear pruebas, localizar errores, traducir entre lenguajes y proponer configuraciones.
16.1. Riesgos técnicos
- código incorrecto;
- vulnerabilidades;
- dependencias inexistentes;
- funciones obsoletas;
- errores de lógica;
- ausencia de pruebas;
- rendimiento deficiente.
16.2. Riesgos jurídicos
- procedencia desconocida de fragmentos;
- incompatibilidad de licencias;
- divulgación de información confidencial;
- tratamiento indebido de datos personales;
- dificultad para acreditar autoría;
- ausencia de trazabilidad.
El código generado por inteligencia artificial debe ser revisado, probado, documentado, analizado en seguridad y controlado respecto de las licencias. La herramienta no elimina la responsabilidad profesional de quien selecciona, integra y entrega el resultado.
17. Recomendaciones prácticas
Para el desarrollador
- utilizar contratos escritos;
- definir los derechos que transfiere;
- separar código previo y código del cliente;
- conservar el historial de versiones;
- revisar licencias y dependencias;
- definir métricas de calidad;
- documentar el sistema;
- proteger credenciales y secretos;
- regular mantenimiento y soporte.
Para el cliente
- exigir una especificación funcional;
- definir requisitos de calidad;
- aclarar si recibirá el código fuente;
- controlar dominios, servidores y cuentas;
- conocer las licencias de terceros;
- prever exportación y migración de datos;
- exigir pruebas de aceptación;
- evitar la dependencia absoluta de una sola persona.
Para ambas partes
- mantener un repositorio versionado;
- aprobar cambios por escrito;
- separar desarrollo, prueba y producción;
- incorporar privacidad y seguridad desde el diseño;
- crear un inventario de componentes;
- prever la finalización de la relación contractual.
18. Conclusión
El software es al mismo tiempo una obra intelectual, una herramienta técnica, un activo empresarial, un servicio, un conjunto de datos y procesos, y una posible fuente de responsabilidad.
Su calidad no depende únicamente de que “funcione”. Un buen software debe ser exacto, fiable, robusto, seguro, disponible, eficiente, escalable, portable, interoperable, usable, accesible, mantenible, documentado, auditable, recuperable y adaptable.
La elección entre software propietario, libre, abierto, permisivo o copyleft debe responder a una estrategia técnica, jurídica y empresarial. La programación, la seguridad, la calidad, la propiedad intelectual, los contratos y la protección de datos forman parte de un mismo sistema.