La tesina o el proyecto final de Ingeniería en Sistemas que se hace para una empresa real es el trabajo más valorado por los jurados y el que más problemas de integridad genera, porque mezcla dos regímenes que no se llevan bien: el de la empresa, que quiere que nada se publique, y el de la universidad, que exige que el trabajo se lea, se defienda y se deposite. Entre los dos está el estudiante, que muchas veces firmó un acuerdo de confidencialidad sin leerlo, escribió el código en horario laboral y descubre en la última semana que no puede mostrar ni el sistema ni los datos con los que lo probó.
Esta guía resuelve ese conflicto antes de que aparezca. Recorre qué se firma con la empresa y qué se negocia, de quién es el código según la ley argentina, qué se puede publicar del sistema, del repositorio y de los datos, cómo se anonimiza un conjunto de datos de producción, qué licencias se declaran y cómo se cumple el depósito en el repositorio institucional sin violar el acuerdo. Sirve para la tesina de grado de Ingeniería en Sistemas de Información, Ingeniería en Informática, Licenciatura en Sistemas y Licenciatura en Informática, y para el proyecto final de las regionales de la UTN.
Antes de escribir una línea: qué se firma con la empresa
Casi toda empresa que acepta un proyecto final pide un acuerdo de confidencialidad. Firmarlo es razonable; firmarlo sin condiciones es el error que después impide defender la tesina. El acuerdo tiene que decir cuatro cosas, y si no las dice, se piden por escrito antes de empezar:
| Cláusula | Qué tiene que decir | Qué pasa si falta |
|---|---|---|
| Objeto de la confidencialidad | Qué información es confidencial: datos de clientes, procesos internos, arquitectura de sistemas existentes, cifras de negocio. Enumerado, no «toda la información». | La empresa puede objetar cualquier párrafo de la tesina, incluido el marco teórico. |
| Uso académico autorizado | Que el estudiante puede describir el problema, el diseño, la arquitectura y los resultados en un trabajo académico que se defiende ante un jurado y se deposita en un repositorio. | La tesina no se puede leer fuera de la empresa y el jurado no la puede evaluar. |
| Revisión previa | Que la empresa revisa el texto en un plazo definido (quince o treinta días) para pedir que se retiren datos identificatorios, no para aprobar el contenido técnico. | La revisión se convierte en un veto sin plazo. |
| Titularidad y licencia del código | De quién es el código, y si el estudiante puede conservar una versión para mostrar o publicar bajo una licencia acordada. | Se aplica el régimen legal por defecto, que suele favorecer a la empresa. |
Hay un actor más: la universidad. Muchas facultades tienen un convenio marco con la empresa o un modelo de acta de proyecto final que define estos puntos, y si existe, se usa ese y no el contrato de la empresa. Preguntá en la secretaría de la carrera antes de firmar nada.
De quién es el código: la Ley 11.723 y la relación laboral
En Argentina el software está protegido como obra intelectual por la Ley 11.723 de Propiedad Intelectual, que desde la reforma de la Ley 25.036 incluye expresamente los programas de computación, en código fuente y objeto, entre las obras protegidas. La titularidad depende de cómo se produjo el programa, y esa es la pregunta que tenés que responder antes de decidir qué publicás:
- Si sos empleado de la empresa y desarrollaste el sistema en el desempeño de tus funciones, la ley le atribuye la titularidad al empleador, salvo pacto en contrario. Podés describir el trabajo en la tesina, pero no publicar el código sin autorización.
- Si sos un estudiante externo que desarrolla para la empresa sin relación laboral, la titularidad es tuya salvo que el acuerdo la ceda. Es el caso más frecuente en los proyectos finales y el que más conviene aclarar por escrito, porque la empresa suele asumir que el código es suyo.
- Si hubo un equipo de dos o tres estudiantes, la obra es en colaboración y la titularidad es compartida; el acuerdo con la empresa lo firman todos.
La distinción entre el código y la tesina importa: aunque el código sea de la empresa, la tesina es tuya, y el jurado evalúa la tesina. Lo que necesitás garantizar es el derecho a describir el desarrollo, a mostrar fragmentos ilustrativos y a exhibir el sistema en la defensa. Lo que podés negociar es una licencia para conservar una versión, en general con los datos y las integraciones específicas de la empresa retirados.
Qué se publica del sistema y qué no
La tesina no tiene que incluir el código completo para ser evaluable. Lo que el jurado necesita está en cuatro planos, y cada uno tiene un tratamiento de confidencialidad distinto:
- El problema y el contexto. Se describe la empresa por rasgos (sector, tamaño, tipo de operación) y el problema por su naturaleza técnica, sin cifras de negocio que la identifiquen. Si la empresa autorizó el nombre, se usa; si no, se anonimiza como se hace en cualquier tesina sobre la empresa donde trabajás.
- El diseño y la arquitectura. Diagramas de componentes, de despliegue, de secuencia, modelo de datos. Casi nunca son confidenciales si se retiran los nombres de sistemas internos, las direcciones de servidores y las credenciales. Es la parte más valiosa para el jurado.
- Fragmentos de código. Se incluyen los que ilustran una decisión técnica (un patrón, un algoritmo, una integración), nunca la totalidad. Cada fragmento se revisa por secretos: claves, tokens, rutas internas, nombres de clientes en comentarios o en datos de prueba.
- El repositorio. Si el código es tuyo y la empresa lo autoriza, un repositorio público con una licencia declarada suma mucho en la evaluación. Si no, un repositorio privado al que se da acceso al jurado durante la evaluación es una solución aceptada en varias facultades; se documenta en el anexo cómo acceder.
El capítulo de desarrollo, con los diagramas, las decisiones y las pruebas que el jurado espera ver, está desarrollado en la guía sobre el capítulo de desarrollo de una tesina de Ingeniería en Sistemas; acá lo que cambia es qué de todo eso pasa por el filtro de confidencialidad.
Datos de producción: cómo se anonimizan y cómo se declara
El sistema se probó con datos reales de la empresa, y esos datos son casi siempre datos personales de clientes, empleados o proveedores. La Ley 25.326 de Protección de Datos Personales exige consentimiento o base legal para tratarlos, y el acuerdo con la empresa casi nunca cubre que aparezcan en un documento público. Cuatro decisiones resuelven el problema:
- Nunca se incluyen datos de producción en la tesina ni en el repositorio, ni en capturas de pantalla, ni en fixtures de prueba, ni en archivos de configuración versionados. La revisión del historial del repositorio es parte del cierre del proyecto.
- Se genera un conjunto de datos sintético con la misma estructura y distribución aproximada, y se documenta cómo se generó. Es lo que se muestra en la defensa y lo que se publica.
- Si la evaluación necesita resultados sobre datos reales (tiempos de respuesta, precisión de un modelo), se reportan los agregados, no los registros, y se declara en metodología que la evaluación se corrió sobre datos de producción bajo el acuerdo de confidencialidad, con acceso solo dentro de la empresa.
- Si el sistema procesa datos sensibles (salud, finanzas personales, datos biométricos), el protocolo de anonimización se describe como parte del diseño y no como un trámite, porque es una decisión de ingeniería que el jurado evalúa.
Cuando usaste un conjunto de datos público para entrenar o probar, se cita como cualquier otra fuente; la forma está en la guía sobre cómo citar bases de datos, datasets y software en APA 7. Si entrevistaste a usuarios o a personal de la empresa para relevar requerimientos, esas entrevistas llevan consentimiento informado como en cualquier investigación; el modelo está en la guía sobre el consentimiento informado en la investigación.
Licencias: las que usaste y la que declarás
Una tesina de Sistemas depende de decenas de bibliotecas, y cada una tiene una licencia que condiciona lo que podés hacer con tu propio código. El jurado espera dos cosas: que sepas qué licencias tienen las dependencias principales y que declares la licencia de tu trabajo.
| Licencia de la dependencia | Qué permite | Qué te obliga |
|---|---|---|
| MIT, BSD, Apache 2.0 | Uso, modificación y redistribución, incluso en software cerrado | Conservar el aviso de licencia; Apache además exige indicar las modificaciones |
| GPL v2 y v3 | Uso y modificación | Si redistribuís el programa que la incorpora, tiene que ser bajo GPL con el código fuente disponible |
| LGPL | Enlazar la biblioteca desde software con otra licencia | Las modificaciones a la biblioteca misma se publican bajo LGPL |
| AGPL | Como GPL | La obligación de publicar el fuente se activa también cuando el software se usa por red, lo que afecta a los servicios web |
La consecuencia práctica: si la empresa quiere un sistema cerrado y vos incorporaste una biblioteca GPL o AGPL, hay un conflicto que se resuelve antes de entregar, cambiando la dependencia o negociando con la empresa. La tesina incluye un anexo con las dependencias principales y sus licencias; es una página y evita una pregunta incómoda en la defensa.
Para tu propio código, si podés publicarlo, elegí una licencia y ponela en el repositorio: MIT o Apache 2.0 si querés máxima reutilización, GPL si querés que las derivaciones sigan siendo abiertas. Para el documento de la tesina, una licencia Creative Commons es lo habitual en los repositorios universitarios, y la elegís al depositar. Si el código no se publica, se declara igual: «el código fuente es propiedad de la empresa y no se distribuye; se incluyen fragmentos ilustrativos con su autorización».
El depósito en el repositorio institucional y el embargo
La Ley 26.899 obliga a las instituciones del sistema científico a depositar en repositorios de acceso abierto la producción financiada con fondos públicos, y muchas universidades extienden esa política a las tesinas de grado. Si tu tesina tiene información confidencial, la solución no es no depositar, sino usar los mecanismos que el propio repositorio prevé: el embargo temporal, que difiere el acceso público por un plazo, y la versión pública, que es la tesina con los anexos confidenciales retirados. Lo habitual es depositar la versión pública de inmediato y, si la empresa lo pide, embargar la completa por el plazo acordado. Los plazos, las licencias y el procedimiento están en la guía sobre el depósito de la tesina en el repositorio.
El acuerdo de confidencialidad tiene que ser compatible con esto. Una cláusula que prohíba el depósito en cualquier forma choca con el reglamento de la facultad y es lo primero que hay que negociar; una cláusula de revisión previa con plazo y un embargo de doce o veinticuatro meses satisfacen a casi todas las empresas.
Inteligencia artificial en el código y en el texto
Dos aclaraciones que el jurado de Sistemas espera hoy. Primera: si usaste asistentes de código, se declara en metodología qué herramientas, para qué tareas y cómo verificaste el resultado; el código asistido es tuyo en la medida en que lo entendés y lo defendés. Segunda: pegar código o documentación de la empresa en un asistente de IA en la nube puede violar el acuerdo de confidencialidad y la Ley 25.326 si hay datos personales; se usan herramientas locales o se pregunta a la empresa qué autoriza. Lo que dicen los reglamentos de las universidades argentinas sobre el uso de IA en la tesina está en la guía sobre si se puede usar IA en la tesina.
Cómo se escribe todo esto en la tesina
Un apartado de «consideraciones legales y de confidencialidad» en el capítulo de contexto o en el metodológico, de una o dos carillas, con cinco puntos: el acuerdo con la empresa y su alcance, la titularidad del código, el tratamiento de los datos, las licencias de las dependencias y de tu trabajo, y el régimen de depósito. En anexos, el acta o convenio con datos identificatorios tachados, el listado de dependencias con licencias y la descripción del conjunto de datos sintético. Escrito así, el jurado ve que el problema de integridad estaba resuelto antes de la defensa, que es exactamente lo que evalúa.
Preguntas frecuentes
¿Puedo hacer la tesina sobre un sistema que ya desarrollé en mi trabajo?
Sí, con autorización escrita de la empresa, y con una salvedad: si el código es del empleador, la tesina describe el desarrollo y puede incluir fragmentos autorizados, pero no se publica el repositorio. La contribución académica se evalúa igual.
¿La empresa puede impedirme defender la tesina?
No, si el acuerdo contempla el uso académico. Puede pedir que se retiren datos identificatorios y puede pedir un embargo en el repositorio, pero la defensa ante un jurado es un acto académico que el acuerdo tiene que prever. Si tu acuerdo no lo prevé, pedí una adenda.
¿Qué hago si ya subí datos reales al repositorio?
Reescribí el historial para eliminarlos, rotá cualquier credencial que haya quedado expuesta y avisá a la empresa. Un archivo borrado en el último commit sigue estando en el historial.
¿Necesito registrar el software en la Dirección Nacional del Derecho de Autor?
No para la tesina. El registro es voluntario y sirve como prueba de fecha y autoría, pero la protección de la Ley 11.723 existe desde la creación de la obra. Si vas a comercializar el sistema, conviene; para defenderlo, no hace falta.
¿Puedo usar una biblioteca GPL en un sistema para una empresa?
Podés usarla internamente sin problema; la obligación de publicar el fuente se activa al redistribuir el programa (o, con AGPL, al ofrecerlo por red). Si la empresa va a distribuir o vender el sistema, elegí una dependencia con licencia permisiva o negociá con la empresa.