viernes, 9 de octubre de 2026

El riesgo de confusión en la economía algorítmica

 



¿La economía algorítmica se refiere a un humano, a un consumidor humano, cuando hace referencia al consumidor que se confunde?


1 Introducción


El riesgo de confusión constituye una de las categorías más tradicionales del Derecho de marcas. Se parte de la base de que una marca distingue determinados productos o servicios y, por ello, el derecho de marcas procura evitar que otro signo genere en el público una percepción equivocada acerca de su origen empresarial. Esa idea se sustenta en que es una persona la que percibe el signo, lo compara con sus recuerdos, lo relaciona con determinados productos y decide si existe o no una vinculación empresarial. Un ser humano es el consumidor, destinatario de los mensajes del mercado para que contrate el producto o servicio que lleva la marca.

Algo ha cambiado. La economía digital comienza a alterar ese presupuesto.

Cuando un consumidor busca un producto en Internet, puede no observar el conjunto de marcas disponibles. Un buscador selecciona y ordena resultados, luego una plataforma determina qué productos mostrar primero, un sistema de recomendación construye un conjunto personalizado de alternativas, un asistente de inteligencia artificial puede sintetizar las opciones y recomendar una sola, finalmente un agente de inteligencia artificial, en determinados escenarios, puede llegar a ejecutar la compra.

Ya no se trata solamente de si el consumidor A confunde la marca X con la marca Y. Ahora tambíén puede pasar que este el consumidor A no llegó a considerar X porque un sistema algorítmico entendió que Y era equivalente, alternativa, sustituta o recomendada en relación con X, y que por alguna razón era bastante como opción (por ejemplo por ser más barata, por ejemplo por estar a la venta en un comercio más próximo).

Se ha advertido precisamente que la inteligencia artificial funciona crecientemente como un filtro entre consumidor, producto y marca, y que esta transformación puede obligar a reconsiderar conceptos tradicionales como el consumidor medio, la confusión y la responsabilidad. (OMPI, 2020). El problema no consiste, por tanto, en determinar si la tecnología “elimina” al consumidor humano, sino en determinar cuánto de la percepción relevante para el Derecho sigue siendo producido directamente por el consumidor y cuánto es construido previamente por sistemas que organizan aquello que el consumidor puede percibir.


2 La confusión como fenómeno humano en el Derecho tradicional


La concepción clásica del riesgo de confusión descansa sobre una apreciación de la percepción del público relevante. No se trata de exigir una confusión efectiva de cada consumidor, sino de determinar desde el punto de vista jurídico si, dadas determinadas circunstancias, existe una posibilidad razonable de que el público atribuya un origen empresarial común o económicamente vinculado a signos diferentes.

En el ámbito europeo, que ofrece una construcción dogmática particularmente desarrollada sobre este punto, el análisis considera conjuntamente la similitud de los signos, la similitud de los productos o servicios, el carácter distintivo de la marca anterior y el grado de atención del público relevante. La apreciación es global y no requiere que todos los consumidores resulten confundidos, tal como indican las directrices de la EUIPO.

La doctrina del “consumidor medio” funciona como una herramienta jurídica de abstracción. No describe estadísticamente a una persona determinada, ni supone que el consumidor sea especialmente diligente o particularmente distraído. Constituye un parámetro normativo para evaluar la percepción relevante en materia de marcas.

El Derecho uruguayo no utiliza en la ley n.° 17.011 una formulación legislativa idéntica a la construcción europea del consumidor medio, pero la confusión – a veces también expresada como confundibilidad - ocupa un lugar estructural en el sistema marcario uruguayo.

El artículo 1 de la ley 17.011 de 25 de setiembre de 1998 define la marca por su aptitud para distinguir los productos o servicios de una persona física o jurídica de los de otra. Su artículo 6 dispone que las marcas deben ser claramente diferentes de las ya inscriptas o en trámite, precisamente para evitar confusión respecto de los mismos productos o servicios o de productos o servicios concurrentes. Su artículo 14 reconoce el derecho a oponerse al uso o registro de una marca que pueda producir confusión entre productos o servicios. Esta estructura normativa permite concluir que la confusión no es un accidente externo al sistema marcario uruguayo, sino uno de los ejes sobre los que se articula.


3 Oferta y marca


En el comercio tradicional, el consumidor se enfrenta con un universo relativamente visible de alternativas. Puede ingresar a un establecimiento, observar productos, comparar envases, reconocer signos, escuchar recomendaciones y formar una decisión. Esto cambió en internet.

El consumidor puede realizar una variedad de acciones, como por ejemplo:

a escribir “zapatillas deportivas” en un buscador y recibir una determinada secuencia de resultados; b formular la misma pregunta en una plataforma de comercio electrónico y obtener una selección diferente;

c preguntarle a un asistente de inteligencia artificial cuál es la mejor alternativa y recibir tres opciones;

d decir simplemente “comprame unas zapatillas para correr” y delegar progresivamente la selección.

En cada una de estas situaciones, el consumidor continúa existiendo, pero su universo perceptivo es previamente seleccionado por un intermediario tecnológico. Al respecto se ha señalado que los sistemas de inteligencia artificial pueden actuar como verdaderos “filtros” entre consumidor y marca, en cuyo entorno el problema no reside únicamente en que el algoritmo recomiende algo, sino en que el consumidor puede desconocer la totalidad de las alternativas existentes en el mercado y tomar su decisión sobre un universo considerablemente reducido por el sistema. (OMPI, 2020).

De manera que en la economía algorítmica para poder analizar si ha podido haber riesgo de confusión hay que saber qué signos, productos y alternativas fueron previamente puestos delante del consumidor y bajo qué lógica.


4 Se confunde el consumidor o es confundido por el algoritmo


Supongamos el caso de una persona que busca una marca determinada y un asistente de IA responde: “Si te interesa X, te recomiendo Y, es una alternativa equivalente.”. Si Y utiliza un signo visual o denominativo semejante a X, el consumidor puede interpretar que existe una relación empresarial, pero también puede suceder que el sistema no está simplemente mostrando Y, sino construyendo una equivalencia semántica entre X e Y.

Este escenario puede provocar tres niveles diferentes de confusión:

a confusión marcaria, si el consumidor atribuye a Y el origen empresarial de X o cree que existe una vinculación entre ambas;

b confusión inducida por la interfaz, si el consumidor interpreta la proximidad de los resultados como una señal de equivalencia o relación;

c confusión algorítmicamente producida o inducida, si el sistema clasifica o presenta dos signos como equivalentes aun cuando desde el punto de vista jurídico no lo sean.

Esta última situaicón obliga a distinguir entre la similitud de los signos y la similitud creada por el intermediario tecnológico. Un sistema puede no reproducir una marca, pero puede establecer asociaciones que tengan un efecto económico equivalente o incluso más intenso. Puede presentar una marca desconocida como “similar a” una marca notoria, como “alternativa” a ella o como producto que “cumple la misma función”.


5 Consumidor medio y consumidor personalizado


El concepto de consumidor medio presupone una cierta homogeneidad metodológica. El juez debe imaginar al público relevante y valorar cómo percibiría los signos. La personalización algorítmica fragmenta esa imagen, dado que dos consumidores pueden realizar exactamente la misma búsqueda y recibir resultados diferentes. Uno puede visualizar una marca porque previamente adquirió productos de ella, mientras que otro puede recibir una marca competidora porque el algoritmo estima que su comportamiento, ubicación, historial o perfil hacen más probable esa elección.

El consumidor deja de ser solamente “medio” y pasa a ser individualmente perfilado. Esto hace compleja la determinación general de la existencia de riesgo de confusión, porque ya no depende de la percepción del público relevante, sino que se tiene como referente un público en el cual cada integrante recibe una experiencia marcaria distinta.

La respuesta no debería ser abandonar el concepto de consumidor medio, pero es necesario reformular su utilización. El consumidor medio de la economía algorítmica no debería ser imaginado necesariamente como una persona que observa autónomamente un mercado completo. Debe contemplarse también que su percepción puede estar condicionada por una arquitectura de información personalizada. En otras palabras, el parámetro puede seguir siendo humano, pero las condiciones de formación de su percepción ya no son exclusivamente humanas.


6 La personalización puede aumentar y no disminuir el riesgo de confusión


La personalización de la que hablamos suele presentarse como una herramienta destinada a facilitar la elección, pues cuanto mejor conoce el sistema al consumidor, mejores serían las recomendaciones. Desde una perspectiva económica, esto puede reducir los costos de búsqueda, pero desde el Derecho de marcas y del consumidor, la personalización puede producir el efecto inverso.

Un consumidor expuesto a una cantidad menor de alternativas puede prestar más confianza a la recomendación del sistema. Y cuanto mayor sea esa confianza, mayor puede ser la relevancia jurídica de una asociación incorrecta.

La OECD ha señalado que las tecnologías digitales, los algoritmos y los sistemas basados en grandes volúmenes de datos pueden generar beneficios de personalización, pero también nuevas vulnerabilidades. Asimismo, advierte que los consumidores procesan información con menor eficacia en determinados contextos de compra en línea y recurren más a reglas simplificadas de decisión cuando existe sobrecarga informativa. (OECD, 2024).

El fenómeno es muy evidente cuando la recomendación aparece revestida de una apariencia de neutralidad, dirigida a que el consumidor pueda interpretar: “El algoritmo me recomendó esto porque es lo mejor para mí.”. En realidad, la recomendación puede estar influida por publicidad, acuerdos comerciales, margen económico, disponibilidad de stock, comisión o parámetros internos de la plataforma.


7 El Derecho uruguayo ante el tema


La ley n.° 17.250 de 11 de agosto de 2000, de Relaciones de Consumo, establece que toda información referente a una relación de consumo debe ser clara y que la información difundida por cualquier medio puede obligar al oferente e integrar el contrato celebrado con el consumidor, artículos 13 y 14. Su artículo 24 prohíbe la publicidad engañosa y considera engañosa aquella modalidad de información o comunicación que pueda inducir a error al consumidor, incluso por omisión de datos esenciales, respecto de aspectos como la naturaleza, cantidad, origen o precio de los productos o servicios.

Es de destacar que la norma presenta una notable capacidad de adaptación tecnológica, pues no define el medio publicitario de manera cerrada. Por ello, una recomendación comercial generada o presentada mediante una interfaz algorítmica no debería quedar fuera del análisis simplemente porque no adopte la forma tradicional de un anuncio.

Aquí aparece una cuestión central: si una plataforma presenta una recomendación comercial como si fuera una conclusión neutral del sistema, cuando en realidad responde a una finalidad económica no explicitada, la eventual confusión ya no es solamente marcaria. Puede existir también un problema de información y publicidad frente al consumidor.


8 El algoritmo como nuevo intermediario de la función distintiva


La ley n.° 17.011 atribuye a la marca una función esencialmente distintiva, vimos que el artículo 1 vincula expresamente la marca con la aptitud de distinguir productos o servicios de una persona respecto de los de otra. En el entorno físico, la marca cumple esa función mediante su presencia en el producto, el envase, el establecimiento o la publicidad.

Sin embargo, en el entorno digital aparece un nuevo actor, porque es el sistema que decide cuándo, dónde y junto a qué otras marcas aparece el signo. Esto permite pensar que la función distintiva ya no depende únicamente de las características intrínsecas del signo, sino también de su contexto algorítmico de presentación.

Una marca puede ser perfectamente distintiva en términos denominativos y gráficos y, sin embargo, quedar funcionalmente desdibujada si un sistema de recomendación la presenta sistemáticamente junto a otra marca como si fueran equivalentes. La distinción entre signo y contexto adquiere entonces una nueva dimensión.

El Derecho de marcas tradicional analiza principalmente el signo en relación con productos, servicios y público. La economía algorítmica obliga a incorporar una cuarta variable: la estructura tecnológica de presentación.


9 Buscadores y riesgo de confusión


Los buscadores mediatizan la oferta de productos o servicios con marcas. La búsqueda puede contener una marca concreta, pero el resultado puede presentar productos de terceros. También puede ocurrir que el consumidor escriba un término genérico y el buscador lo conduzca hacia determinados signos. En estos casos, la confusión puede aparecer antes de que exista una interacción directa con el producto.

El consumidor no recibe simplemente información, recibe una jerarquización de información que tiene significado económico. En la economía digital, aparecer primero puede ser casi tan importante como tener una marca fuerte, de allí que la disputa por la atención pueda transformarse en una disputa por el significado de los signos.

El Derecho de marcas debería prestar atención no solamente a si una plataforma “usa” una marca ajena, sino también a cómo la utiliza dentro de su arquitectura de resultados y recomendaciones.


10 Asistentes de IA


Los asistentes de inteligencia artificial han introducido un cambio relevante. Un buscador tradicional devuelve una lista, de manera que el usuario conserva una carga considerable de selección. Un asistente conversacional puede hacer algo diferente: sintetizar, comparar, recomendar y explicar. Mientras el sistema contesta “Estas son algunas marcas que encontré”, el usuario puede comprender que está frente a una enumeración. Sin embargo, si dice “Esta es la mejor alternativa a X”, está efectuando una operación intelectual diferente, está construyendo una relación entre marcas. Si además ejecuta la compra, la intermediación se vuelve transaccional.

Se ha identificado ya esta posibilidad al analizar los asistentes de compra basados en inteligencia artificial y señalaba que, en escenarios de delegación significativa, surge una pregunta especialmente difícil: ¿quién es el consumidor relevante cuando la decisión de compra es adoptada total o parcialmente por el sistema? (OMPI, 2020).

La situaicón lleva a preguntarse si puede existir, desde la perspectiva jurídica, un “riesgo de confusión” sin que exista una intervención cognitiva humana significativa en el momento de la selección. Probablemente sí, pero la respuesta exige separar dos cuestiones: la existencia del riesgo de confusión y la imputación de la conducta que lo produjo.


11 Confusión humana y error algorítmico no son equivalentes


Un sistema de inteligencia artificial puede tener un error, sin que ello constituya o provoque confusión marcaria. Un modelo puede recomendar incorrectamente un producto por un error estadístico, una base de datos defectuosa o una inferencia equivocada. Eso no significa automáticamente que exista riesgo de confusión en sentido marcario.

El concepto de confusión conserva un componente normativo que queda claro en la experiencia europea, en la cual la apreciación del riesgo de confusión no constituye una mera medición empírica de las preferencias o errores psicológicos del consumidor. Se trata de una construcción jurídica que utiliza hechos relativos al comportamiento y percepción del público, tal como enseñan las Directrices de la EUIPO, por lo cual el algoritmo no sustituye al concepto jurídico de consumidor.

Lo que cambia es el entorno cognitivo dentro del cual ese consumidor forma su percepción. Esta distinción resulta decisiva para evitar dos extremos igualmente inconvenientes: considerar que todo error algorítmico constituye infracción marcaria o, inversamente, sostener que los algoritmos son jurídicamente irrelevantes porque “el consumidor siempre decide”.


12 Personalización y la protección de datos


La personalización algorítmica requiere datos, que se encuentran en el historial de navegación, compras anteriores, preferencias, ubicación, comportamiento y otros elementos que son utilizados para construir perfiles y determinar qué productos o marcas presentar.

En Uruguay, la ley n.° 18.331 de Protección de Datos Personales, artículo 16, reconoce el derecho a no quedar sometido a determinadas decisiones con efectos jurídicos significativos basadas en tratamientos automatizados destinados a evaluar aspectos de la personalidad o comportamiento, y contempla el derecho a impugnar determinadas decisiones y obtener información sobre los criterios de valoración y el programa utilizado. Aunque esta disposición no fue concebida específicamente para el Derecho de marcas ni para sistemas de recomendación comercial, revela una idea jurídica de fondo de enorme importancia para la economía algorítmica, como lo es que la automatización no elimina la exigencia de explicabilidad ni la posibilidad de cuestionar determinadas consecuencias de una decisión basada en datos.


13 La “confusión por contexto”


El nuevo escenario tecnológico que nos rodea puede dar lugar a una variante de confusión, que se ha denominado confusión por contexto algorítmico.

Supongamos que existen dos marcas suficientemente diferentes en términos visuales y fonéticos, que claramente, en condiciones tradicionales, difícilmente producirían confusión. Sin embargo, en una plataforma se pueden estar presentando sistemáticamente “Marca A — alternativa a Marca B”. O un asistente de IA responde ante una búsqueda que “Si buscás B, A es una opción equivalente.”. De esta forma el sistema ha creado una asociación que no necesariamente estaba contenida en los signos.

La interrogante en este caso para por definir si puede una conducta del intermediario generar una asociación relevante desde el punto de vista jurídico aunque los signos, considerados aisladamente, no sean confundibles. La respuesta no debería ser automáticamente afirmativa, pero el interrogante merece ser incorporado al análisis porque el contexto digital puede tener una capacidad asociativa extraordinariamente superior a la que tenía la presentación tradicional del signo.

El punto es más complejo respecto de marcas notorias o particularmente distintivas. La ley n.° 17.011, artículo 5, otorga protección frente a reproducciones, imitaciones o traducciones de marcas notoriamente conocidas en determinadas circunstancias. Una plataforma que utiliza una marca notoria como referencia para posicionar sistemáticamente terceros productos puede estar aprovechando no solamente la capacidad distintiva del signo, sino también su capacidad de orientar tráfico y atención.


14 La confusión como problema de información


Desde esta perspectiva, puede observarse una convergencia entre propiedad intelectual y derecho del consumidor. Por un lado, la marca organiza información sobre origen empresarial y, por otro lado, la publicidad transmite información —o puede transmitir desinformación— sobre productos y servicios. Luego, el algoritmo organiza el acceso a esa información. Por esto, cuando el algoritmo altera la percepción del origen empresarial, no estamos ante tres problemas independientes. Una alteración en cualquiera de esos eslabones puede afectar la decisión final.

La ley n.° 17.250 contiene una lógica compatible con esta perspectiva porque no limita sus exigencias informativas a soportes físicos tradicionales. La información difundida por cualquier forma o medio de comunicación puede producir consecuencias de relevancia jurídica y la publicidad engañosa incluye comunicaciones capaces de inducir a error incluso mediante omisiones relevantes. El punto hoy es determinar cuándo una estructura de recomendación deja de ser una herramienta técnica para convertirse en un instrumento relevante de comunicación comercial.


15 La falsa neutralidad algorítmica


En el lenguaje del entorno de la economía digital percibimos las expresiones de los algoritmos como una opción técnica, con apariencia de neutralidad.

Es más fácil para un consumidor desconfiar de un vendedor que afirma que su producto es “el mejor”, que no creer una recomendación que parece provenir de un sistema objetivo. Sin embargo, los algoritmos comerciales no son necesariamente neutrales, pues pueden incorporar objetivos empresariales, parámetros económicos, contratos publicitarios o criterios destinados a maximizar conversión, permanencia o rentabilidad.

La OECD ha destacado que las llamadas prácticas comerciales oscuras pueden modificar la arquitectura de elección y dirigir, engañar, coaccionar o manipular al consumidor; asimismo, advierte que el aprendizaje automático puede permitir una personalización cada vez más refinada de estas prácticas. (OECD, 2022). Por eso, el problema de la confusión algorítmica no debe limitarse al supuesto de una IA que “se equivoca”. También debe contemplar la posibilidad de una IA que optimiza deliberadamente una determinada asociación comercial.


16 Teoría del “consumidor aumentado”


Un posibilidad que se plantea en los razonamientos que valoran la incidencia de los cambios tecnológicos y sus efectos en los conceptos tradicionales es reconstruir el concepto de “consumidor medio”. Esta propuesta se encamina a sostener que el consumidor contemporáneo podría ser entendido como un consumidor aumentado, cuya experiencia de mercado se encuentra parcialmente mediada por tecnologías de búsqueda, recomendación, personalización y asistencia.

No es un consumidor menos humano, sino un consumidor cuya percepción está tecnológicamente mediada. Esto tiene una consecuencia metodológica directa, cual es que al evaluar el riesgo de confusión debería considerarse, cuando las circunstancias lo justifiquen, no solamente la percepción abstracta del público frente a los signos, sino también las condiciones tecnológicas concretas en las cuales esos signos son presentados.

Hay numerosos factores que en determinados mercados sería muy importante conocer para disponer de información básica en los casos concretos, tales como:

a si la búsqueda es textual, visual o por voz;

b si el consumidor recibe una lista o una única recomendación;

c si el sistema explica por qué recomienda una marca;

d si existen resultados patrocinados;

e si la personalización modifica sustancialmente el universo de alternativas; entre tantas otras.

Cada litigio marcario no puede derivar en una auditoría tecnológica, pero es muy importante reconocer que la percepción del consumidor depende cada vez más de la arquitectura mediante la cual recibe la información.


17 El Derecho de marcas y la economía de la atención


Hoy se reinterpretan varios temas en torno al concepto de la economía de la atención. La marca tradicionalmente competía por ser recordada, mientras que la marca digital compite además por ser seleccionada por el algoritmo. El objetivo empresarial ya no es únicamente que el consumidor reconozca una marca cuando la ve, pues puede consistir en lograr que el sistema la coloque delante del consumidor cuando este todavía no sabe qué quiere comprar.

Esto transforma el poder económico de la intermediación. Una plataforma que controla la recomendación puede tener una influencia considerable sobre la función económica de las marcas: determina qué signos son visibles, cuáles son comparados, cuáles aparecen como alternativas y cuáles desaparecen del campo de atención.

La propiedad intelectual y el derecho de la competencia están muy vinculados de esta manera. La marca protege la capacidad distintiva del signo, mientras que el eerecho de la competencia puede tener que examinar el poder de quien controla la infraestructura que determina qué signos llegan a ser visibles. El control del acceso al signo puede derivar en actos anticompetitivos.


EN DEFINITIVA

El consumidor que confunde sigue siendo humano, pero en la economía algorítmica, el consumidor humano ya no constituye necesariamente el único agente cognitivo relevante. Antes de que perciba una marca, un sistema puede haber seleccionado el contenido que verá, antes de que compare productos, un algoritmo puede haber reducido las alternativas, antes de que formule una preferencia, un asistente puede haber construido una recomendación y antes de que decida, una plataforma puede haber determinado qué opción resulta más visible.

Hay que comprender que la percepción humana puede estar algorítmicamente configurada y se verá que el riesgo de confusión del siglo XXI no necesariamente surge de que dos empresarios utilicen signos semejantes, pues puede surgir también de que una infraestructura digital construya entre dos signos una relación que el consumidor interpreta como significativa.

El Derecho uruguayo dispone de conceptos suficientemente flexibles para enfocar situaciones en este contexto, pero su aplicación deberá abandonar una visión excesivamente estática del mercado y reconocer que la distintividad se experimenta hoy dentro de sistemas de búsqueda, recomendación, personalización y atención.

No es problema el concepto de consumidor medio como tal, sino que para impedir confusiones hay que recurrir a temas tecnológicos de la estructura operativa de acceso a productos o servicios en las plataformas digitales, donde la marca ha adquirido hoy una serie de funciones técnicas más allá de la finalidad distintiva originaria.



Referencias bibliográficas


European Union Intellectual Property Office. (2024). Trade mark guidelines: Part C—Opposition, Section 2—Double identity and likelihood of confusion. Directrices EUIPO. https://guidelines.euipo.europa.eu/2214311/1983183/trade-mark-guidelines/1-introduction


Organisation for Economic Co-operation and Development. (2022). Dark commercial patterns. OECD Digital Economy Papers, No. 336. OECD Publishing. https://doi.org/10.1787/44f5e846-en.


Organisation for Economic Co-operation and Development. (2024). Consumer policy and digital technologies. OECD. https://www.oecd.org/en/topics/sub-issues/consumer-policy-and-digital-technologies.html


Organización Mundial de la Propiedad Intelectual. (2020). El Derecho de marcas: ¿al día con la IA? Revista de la OMPI. https://www.wipo.int/es/web/wipo-magazine/articles/trademark-law-playing-catch-up-with-artificial-intelligence-55800


Organización Mundial de la Propiedad Intelectual. (2020). WIPO conversation on intellectual property (IP) and artificial intelligence (AI): Revised issues paper on intellectual property policy and artificial intelligence. WIPO. https://www.wipo.int/edocs/mdocs/mdocs/en/wipo_ip_ai_2_ge_20/wipo_ip_ai_2_ge_20_1_rev.pdf


Uruguay. (1998). Ley n.° 17.011 de 25 de setiembre de 1998, Ley de marcas, nombres comerciales e indicaciones geográficas. IMPO.

Uruguay. (2000). Ley n.° 17.250 de 11 de agosto de 2000, Ley de Relaciones de Consumo. IMPO.

Uruguay. (2008). Ley n.° 18.331 de 11 de agosto de 2008, Ley de Protección de Datos Personales. IMPO.



jueves, 8 de octubre de 2026

Post 1 El software también es una obra protegida por propiedad intelectual – 1 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada


Cuando se habla de propiedad intelectual y software, todavía es frecuente pensar que el derecho protege únicamente una parte muy particular del producto tecnológico: el código fuente. Sin embargo, la mirada debe ser mucho más amplia.

La ley n.° 9.739, en la redacción dada por la ley n.° 17.616, incluye expresamente entre las obras protegidas a los programas de ordenador, tanto en código fuente como en código objeto. También comprende determinadas compilaciones de datos y la expresión de ideas, informaciones y algoritmos cuando se encuentran formuladas en secuencias originales ordenadas para ser utilizadas por dispositivos de procesamiento de información.

Esto es importante porque el software no debería analizarse desde el punto de vista jurídico como un simple conjunto de instrucciones técnicas. Detrás de esas instrucciones existe una actividad creativa susceptible de generar derechos de autor.

El derecho de autor uruguayo reconoce al titular facultades exclusivas de reproducción, distribución, publicación, traducción, adaptación, transformación, comunicación y puesta a disposición de la obra, entre otras. En un entorno digital, la reproducción comprende también determinadas formas de almacenamiento electrónico.

Por eso, copiar un programa, incorporar código ajeno a otro desarrollo, distribuir una aplicación o ponerla a disposición del público no son simplemente decisiones técnicas o comerciales. Pueden constituir actos de explotación de una obra protegida y, por tanto, requieren analizar quién es titular de los derechos y qué autorizaciones existen.

Hay que tener en cuenta, además, que la propiedad intelectual no protege las ideas en abstracto del mismo modo que protege su expresión. Una idea de negocio, una funcionalidad imaginada o una solución conceptual no se convierten automáticamente en un monopolio jurídico porque alguien las haya pensado primero. El problema jurídico aparece cuando esa idea se exterioriza en una creación protegible o cuando intervienen otros institutos, como el secreto empresarial, las patentes en los casos admitidos por la legislación o la competencia desleal.

Esto explica por qué dos desarrolladores pueden llegar independientemente a soluciones funcionalmente semejantes sin que necesariamente exista infracción de derechos de autor de uno al otro. La comparación jurídica deberá concentrarse en aquello que efectivamente está protegido y en la forma en que fue utilizado.

También conviene distinguir el software de otros activos que suelen acompañarlo. Una aplicación puede tener simultáneamente: código fuente, código objeto, documentación técnica, manuales, diseño gráfico, interfaz de usuario, bases de datos, contenidos, nombre comercial, marca, dominio, secretos empresariales, datos personales, componentes de terceros, bibliotecas de código abierto , así como algoritmos y conocimientos técnicos.

Cada uno puede estar sometido a un régimen jurídico diferente.

Por eso, para un desarrollador, proteger el software no significa simplemente registrar el código. Significa identificar correctamente todos los activos intelectuales que integran el proyecto y determinar quién es titular de cada uno, bajo qué título y con qué alcance.

La propiedad intelectual aparece así desde el primer momento del proyecto: antes de programar, durante el desarrollo, al contratar colaboradores, al incorporar componentes de terceros y, finalmente, al comercializar el producto.


Regla práctica

Antes de lanzar una aplicación, conviene poder responder documentalmente cuatro preguntas:

¿Qué creamos? ¿Quién lo creó? ¿Quién es su titular? ¿Con qué autorizaciones se incorporó cada componente? Si esas cuatro preguntas no tienen respuestas claras, existe un problema jurídico aunque el programa funcione perfectamente. Lo mejor es atenderlo cuando antes.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 2 ¿De quién es el código? Autor, desarrollador, empresa y cliente – 2 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



Uno de los problemas jurídicos más frecuentes en proyectos de software es la respuesta a la pregunta - aparentemente sencilla - “¿de quién es el programa?”, que recibe respuestas diferentes según la perspectiva de quién la formule.

El desarrollador puede pensar: “lo programé yo”.

La empresa puede responder: “lo pagamos nosotros”.

El cliente puede sostener: “fue desarrollado específicamente para nuestra empresa”.

Las tres afirmaciones pueden tener relevancia, pero no son desde el punto de vista jurídico equivalentes.Ni determinan por sí una relación de titularidad con la creación intelectual.

Hay que comenzar por definir qué sucede desde el punto de vista del derecho de autor. La ley n.° 9.739 reconoce como titulares al autor, sus sucesores, colaboradores y adquirentes a cualquier título, entre otros sujetos previstos por la norma.

En materia de programas de ordenador existe, además, una regla especialmente importante para quienes desarrollan software profesionalmente. La legislación uruguaya establece que, cuando las creaciones referidas a programas de ordenador y bases de datos son realizadas en el marco de una relación de trabajo, pública o privada, cuyo objeto total o parcial tenga una naturaleza similar, se presume que el autor ha autorizado al empleador o comitente, salvo pacto en contrario, en forma ilimitada y exclusiva respecto de los derechos patrimoniales y del ejercicio de los derechos morales. Esta previsión fue incorporada al derecho uruguayo por la ley n.° 19.858. La regla que establece aclara una de las situaciones que históricamente generaron más incertidumbre en materia de software, como lo es qué sucede cuando un programador desarrolla una creación dentro de una relación profesional.

Si bien la presunción legal sigue una lógica de razonabilidad, para el caso en que no haya manifestación alguna entre las partes, siempre es aconsejable que haya un contrato escrito que documente la relación. Cuanto más valioso sea el software, más importante resulta documentar la titularidad.

Un desarrollador contratado para crear una aplicación desde cero debería tener claramente establecido qué ocurre con el código fuente, el código objeto, documentación, bibliotecas propias, componentes preexistentes, herramientas de desarrollo, mejoras, actualizaciones, módulos reutilizables, desarrollos futuros así como derechos sobre versiones sucesivas, entre otras creaciones.

También debe distinguirse entre un empleado y un desarrollador independiente. Si una empresa contrata a un desarrollador externo para construir un sistema, no es prudente limitarse a escribir en una factura “desarrollo de software”. El contrato debería determinar expresamente qué derechos recibe el cliente, cuáles conserva el desarrollador y qué ocurre con los elementos preexistentes.

Especialmente importante es diferenciar el software desarrollado específicamente para el cliente de las herramientas generales que el desarrollador ya utilizaba.

Por ejemplo, un programador puede haber creado antes una biblioteca propia, un framework, una arquitectura reusable o determinados módulos genéricos. Si los incorpora al proyecto, la empresa cliente no debería recibir inadvertidamente derechos exclusivos sobre todo aquello que existía antes.

La solución contractual puede consistir en identificar:

a background IP: conocimientos, código, herramientas y componentes preexistentes;

b foreground IP: desarrollos realizados específicamente para el proyecto.

Esta distinción, muy utilizada en contratos tecnológicos, permite evitar conflictos posteriores.

También es conveniente establecer quién podrá reutilizar determinadas soluciones después de terminado el proyecto. Para un desarrollador independiente, esta cuestión puede ser decisiva: una cesión excesivamente amplia podría impedirle volver a utilizar conocimientos y herramientas generales que constituyen parte de su actividad profesional.

No solamente hay que saber quién pagó el software, sino cuáles con las creaciones realizadas, por quién, en qué relación contractual y qué se acordó respecto de ellos.


Regla práctica

Nunca entregar un software comercialmente relevante sin haber documentado previamente la titularidad de sus derechos. El contrato no es un mero complemento administrativo del desarrollo, desde el punto de vista jurídico la definición clara a nivel de derechos que documenta un contrato integra la estructura del negocio que se quiere desarrollar.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 3 Registrar el software en Uruguay, su verdadero alcance – 3 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



En Uruguay, la protección jurídica del software no depende para su existencia como obra protegida por derecho de autor de un registro constitutivo. No obstante, la inscripción registral, con documentación específica y un depósito – que como excepción cuando se trata de código fuente es reservado – le da una base de mayor certeza a los activos empresariales.

Por ello, se utilizó con frecuencia la herramienta registral en este caso, al punto que se instrumentó una dinámica específica, incluso traslando la competencia registral para dichas creaciones a la oficina típica de la propiedad industrial. La ley n.° 20.212 creó el Registro de Software, llevado por la Dirección Nacional de la Propiedad Industrial, y el Decreto N.º 39/025 reglamentó su procedimiento, y al consagrar esta nueva reglamentación se actualizaron algunos conceptos, dotando de mayor precisión a este régimen.

La normativa contempla, entre otros objetos, programas de ordenador en código fuente o código objeto, determinadas compilaciones de datos y expresiones originales de ideas, informaciones y algoritmos formuladas en secuencias ordenadas para ser utilizadas por dispositivos de procesamiento de información. También pueden inscribirse las transmisiones de derechos patrimoniales sobre esas obras.

La primera cuestión que debe quedar clara es que registrar no es lo mismo que crear el derecho.

El Decreto N.º 39/025 establece expresamente que la falta de inscripción no impide la protección de la obra conforme al régimen de derecho de autor.

Registrar es importante, fundamentalmente, para tener fecha cierta, presunción de autoría y de integridad de la obra y sobre determinadas situaciones jurídicas vinculadas con ella. En un conflicto, no es indiferente poder presentar una constancia oficial relativa a una determinada creación, su identificación, su solicitante y otros elementos del registro. Como dijimos, no es determinante de la existencia del derecho, pero desde el punto de vista probatorio es le da solidez a las afirmaciones de existencia por su fecha y referencia integral.

Esto adquiere particular importancia en software porque los desarrollos evolucionan constantemente.

Una aplicación puede tener una primera versión, luego una actualización, posteriormente una modificación sustancial y finalmente una nueva arquitectura. Mantener ordenada la documentación de las versiones puede ser tan importante como conservar el propio código.

El Decreto 39/025 establece un procedimiento específico, contempla la publicación de la solicitud en el Boletín de la Propiedad Industrial y regula, entre otras cuestiones, oposiciones, reivindicación y transferencias.

Hay además una consecuencia contractual muy interesante, porque el decreto dispone que la enajenación o transferencia de una obra debe realizarse por escrito para ser válida y produce efectos frente a terceros desde su inscripción.

Esto convierte al registro en una pieza particularmente relevante cuando el software constituye un activo empresarial que se vende, aporta, licencia, transfiere o utiliza como parte de una operación societaria.

De todas maneras, registrar tampoco sustituye otras medidas.

Una empresa tecnológica debería conservar los contratos suscriptos con desarrolladores, repositorios y control de versiones, la correspondiente documentación técnica, registros de cambios, identificación de autores en sentido material, los contratos de cesión o licencia, licencias de componentes de terceros que ha utilizado para elaboración de un software, documentación sobre software libre si es el caso, evidencia de las versiones, así como documentación de utilización de herramientas de IA, entre demás extremos de hecho que informen sobre el proceso de desarrollo del sotware.


Regla práctica

Cuando un software constituye un activo empresarial relevante, conviene pensar el registro como parte de una estrategia de gestión de activos intelectuales, y no como un trámite aislado.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 4 Software libre y código de terceros – 4 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada




Uno de los errores más frecuentes consiste en tratar el código disponible en Internet como si fuera desde el punto de vista jurídico libre. Que un código pueda descargarse no significa que pueda utilizarse sin condiciones. Siempre hay que saber cuál es el régimen de titularidad y de explotación del código que se utilizará para el desarrollo del software.

La cuestión es especialmente importante respecto del software libre y de código abierto.

Uruguay posee incluso una definición legal de software libre. La ley n.° 19.179 establece que es aquel licenciado de modo que permita usarlo para cualquier propósito, acceder al código fuente para estudiarlo y modificarlo, copiarlo y distribuirlo, y mejorar el programa y liberar esas mejoras, bajo las condiciones previstas por la propia licencia.

Esto demuestra que software libre no equivale a software sin derechos. Por el contrario, precisamente porque existen derechos de propiedad intelectual, el titular puede establecer mediante una licencia determinadas condiciones para el uso, modificación y distribución del programa.

Por eso, antes de incorporar una biblioteca, framework, módulo o fragmento de código de terceros, a un desarrollador debería identificar:

b quién es el titular;

c cuál es la licencia;

d qué usos permite;

e si exige atribución;

f si exige conservar determinados avisos;

g si existen obligaciones respecto de modificaciones;

h si existen obligaciones de distribución del código fuente;

i si existen restricciones de combinación con otros componentes;

j si el uso comercial está permitido;

k qué ocurre con las versiones modificadas.

La cuestión es importante desde el punto de vista jurídico y empresarial.

Una startup puede estar desarrollando un producto con intención de captar inversión o ser adquirida. Si en su software existen componentes cuyas licencias generan obligaciones incompatibles con el modelo de negocio proyectado, el problema puede aparecer durante una due diligence, cuando modificar la arquitectura resulta costoso.

Lo mismo sucede con el código copiado de repositorios públicos. Un desarrollador puede encontrar una solución perfectamente funcional, incorporarla rápidamente y olvidarse de su procedencia. Meses después, la empresa puede descubrir que el código estaba sujeto a una licencia incompatible con la forma en que distribuye su producto.

La gestión profesional de software exige entonces una suerte de trazabilidad jurídica del código. No solamente debe saberse qué hace cada componente. Debe saberse de dónde proviene y bajo qué condiciones puede utilizarse. Esto también alcanza a los llamados “snippets” encontrados en páginas de programación, foros, repositorios y documentación técnica.


Regla práctica

Cada proyecto profesional debería tener un inventario de componentes de terceros - incluido software libre y open source - con indicación de su licencia y de las obligaciones que genera.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/


Post 5 Algoritmos, know-how y secretos empresariales, qué no conviene publicar – 5 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



No todo lo valioso de un software debería hacerse público. De hecho, en determinados proyectos, publicar demasiado puede ser desde el punto de vista jurídico contraproducente.

El código fuente puede estar protegido por derecho de autor, pero una empresa puede poseer además conocimientos técnicos, métodos de implementación, parámetros, procesos, documentación interna, arquitectura, información comercial y otros conocimientos cuyo valor depende precisamente de que permanezcan reservados. Aquí aparece el secreto empresarial como complemento de la propiedad intelectual. Para un desarrollador, esto puede comprender desde una determinada arquitectura técnica hasta la forma concreta de entrenar un modelo, optimizar una base de datos, procesar información o resolver un problema de rendimiento.

También puede comprender información que no sería apropiado considerar patentable o que la empresa sencillamente prefiere mantener fuera de la divulgación pública.

La decisión entre publicar, registrar, patentar - cuando corresponda - o mantener bajo secreto una determinada solución tecnológica requiere análisis previo. Esto es importante porque la ley n.° 17.164, artículo 13, excluye expresamente de la materia patentable a los programas de computación considerados aisladamente. Eso no significa que toda innovación tecnológica vinculada con software sea jurídicamente irrelevante para el sistema de patentes. El software relacionado con creaciones patentables integra un conjunto que en el sistema de la ley n.° puede merecer el registro como patente de invención. Dependerá del caso. La cuestión debe analizarse según el objeto concreto de la invención y la forma en que se presenta.

Por otra parte, publicar información técnica puede afectar una eventual estrategia de protección mediante patente cuando existe una invención patentable vinculada al desarrollo. La divulgación también puede destruir o debilitar el carácter reservado que una empresa pretende atribuir posteriormente a determinada información.

Por eso, antes de presentar una aplicación, publicar un repositorio o realizar una demostración técnica ante terceros, conviene preguntarse:

a ¿qué estoy mostrando?

b ¿qué información necesito proteger?

c ¿qué información debe conocer el cliente?

d ¿qué información puede conocer un proveedor?

e ¿qué información debería quedar sometida a confidencialidad?

El contrato de confidencialidad - NDA - puede ser importante, pero no debería ser la única medida. La protección de información reservada requiere también medidas organizativas y técnicas razonables.

Un repositorio privado, permisos diferenciados, autenticación, control de accesos, políticas internas y documentación sobre quién puede acceder a determinadas partes del proyecto forman parte de la protección jurídica del activo.


Regla práctica

Antes de publicar código, documentación o arquitectura técnica, identificar qué parte del conocimiento es pública, qué parte está protegida por derecho de autor y qué parte tiene valor precisamente porque permanece confidencial. Luego, que se decida si darla o no a conocimiento público, pero a sabiendas del alcance de la decisión.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 6 Marcas, interfaces, diseños y contenidos, mucho más qué código – 6 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



Una aplicación puede funcionar perfectamente y, sin embargo, estar desde el punto de vista jurídico mal protegida, porque el software comercial no se agota en el programa.

Supongamos una aplicación denominada NOVA, con un logotipo determinado, una interfaz gráfica característica, ilustraciones, textos, sonidos, tutoriales, personajes y una página web. Allí pueden existir varios activos intelectuales diferentes.

El nombre o signo distintivo puede ser susceptible de protección marcaria. La ley n.° 17.011 define la marca como un signo con aptitud para distinguir productos o servicios de una persona física o jurídica de los de otra.

Elegir el nombre de una aplicación no debería ser una decisión exclusivamente de marketing. Antes de invertir en publicidad, desarrollo de identidad visual y adquisición de usuarios, conviene realizar una búsqueda de disponibilidad y analizar las clases correspondientes.

De todas maneras, marca y software son activos diferentes. Una empresa puede ser titular del código de una aplicación y no tener adecuadamente protegido su nombre comercial ni los signos que utiliza como sus marcas. También puede suceder lo contrario, que puede tener una marca registrada, pero carecer de documentación suficiente sobre la titularidad del código.

También la interfaz gráfica merece atención, el llamado “look & feel”. Los elementos visuales de una aplicación pueden estar vinculados con diferentes formas de protección según su naturaleza concreta: derecho de autor, diseño industrial, marca u otras figuras.

Un desarrollador que incorpora fotografías, música, tipografías, ilustraciones, videos o textos de terceros no adquiere automáticamente el derecho de utilizarlos comercialmente porque haya comprado una licencia de uso de una plataforma. Hay que revisar qué licencia fue adquirida, para qué territorio, durante cuánto tiempo y con qué finalidad.

La misma lógica se aplica a los recursos visuales utilizados para diseñar interfaces.

Por eso, una buena auditoría de propiedad intelectual de una aplicación debería incluir por separado elementos tales como:

a código;

b diseño;

c contenido;

d marca;

e dominio;

f bases de datos;

g documentación;

h componentes de terceros, entre otros que pudieran identificarse al caso concreto.

Cada activo puede tener un titular diferente y, además, requerir un mecanismo de protección diferente.


Regla práctica

Cuando se comercializa una aplicación, no hay que proteger solamente “el software”. Hay que construir un mapa de todos los activos intelectuales que hacen reconocible y explotable al producto.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 7 Datos personales y software, un activo tecnológico con información de personas – 7 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



Una aplicación puede ser desde el punto de vista jurídico impecable desde la perspectiva del derecho de autor y, sin embargo, presentar problemas importantes respecto de los datos que procesa. Esto ocurre especialmente con plataformas, aplicaciones de salud, fintech, comercio electrónico, educación, recursos humanos, redes sociales y sistemas que utilizan perfiles de usuarios.

En Uruguay, la ley n.° 18.331 de protección de datos personales, reconoce la protección de los datos personales como un derecho fundamental y establece reglas sobre su tratamiento. La ley establece, como principio general, que el tratamiento es lícito cuando existe consentimiento libre, previo, expreso e informado, sin perjuicio de las excepciones legales. Además, cuando se recolectan datos personales deben proporcionarse determinadas informaciones al titular, entre ellas la finalidad del tratamiento, la existencia de la base de datos, la identidad del responsable y los derechos que puede ejercer. Para el desarrollador, esto genera una consecuencia importante, pues la estructura de software no debería diseñarse separadamente de la estructura jurídica de los datos. Esto tiene consecuencias técnicas.

Si una aplicación recoge datos que no necesita, almacena información durante más tiempo del necesario, permite accesos indiscriminados o mezcla bases de datos con finalidades distintas sin analizar previamente su legitimidad, el problema no se soluciona agregando posteriormente una cláusula de privacidad. La privacidad debe estar presente desde el diseño para que sea un desarrollo ajustado a derecho. El desarrollador debería recibir instrucciones claras sobre:

a qué datos se recogen;

b para qué se utilizan;

c quién puede acceder;

d dónde se almacenan;

e cuánto tiempo se conservan;

f con quién se comparten;

g qué medidas de seguridad se aplican;

h cómo se eliminan;

i cómo se atienden los derechos de los titulares.

La protección de datos también se conecta con la propiedad intelectual. Una base de datos puede contener información personal y, simultáneamente, presentar elementos de selección o disposición susceptibles de protección autoral. Pero los derechos sobre la estructura o sobre determinados elementos de una base de datos no significan que la empresa pueda apropiarse libremente de los datos personales contenidos en ella.

Son planos jurídicos diferentes. La empresa puede tener derechos sobre una base de datos y, al mismo tiempo, estar sometida a obligaciones respecto de las personas cuyos datos procesa.


Regla práctica

Cuando se desarrolla software que procesa datos personales, no alcanza con tener definido cómo programamos esta función, sino también qué tratamiento de datos implica esta función y bajo qué condiciones jurídicas puede realizarse.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 8 Inteligencia artificial y desarrollo de software: ¿quién responde por el código generado? - 8 de 10



Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



La inteligencia artificial está modificando rápidamente la actividad de los desarrolladores, como la de todo el mundo. En este tema, una parte del código hoy puede ser escrita directamente por una persona y otra parte puede ser sugerida, completada, transformada o generada mediante herramientas de IA.

Esto ha introducido una nueva dimensión en la gestión de propiedad intelectual.

En primer lugar, hay que preguntarse quién es el autor de un código generado con inteligencia artificial. La respuesta no debería buscarse en una afirmación automática del tipo “si lo utilizó un programador, todo es suyo” ni en la contraria “si lo generó una IA, nadie tiene derechos”.

La cuestión depende de las circunstancias concretas de creación y del grado de intervención humana.

En Uruguay, la base de la respuesta se encuentra en la ley n.° 9.739 que, como hemos ya comentado en esta serie, protege las creaciones intelectuales por derecho de autor y contempla expresamente los programas de ordenador como obra protegida.

Sin embargo, el uso de IA introduce interrogantes adicionales, del tipo de las siguientes:

a ¿quién diseñó el problema que debía resolverse?

b ¿quién formuló las instrucciones?

c ¿quién seleccionó la respuesta?

d ¿quién modificó el código?

e ¿quién integró el resultado?

f ¿quién realizó la depuración?

g ¿qué elementos fueron creados autónomamente por la herramienta?

h ¿la herramienta fue autorizada para utilizar los datos introducidos?

i ¿qué condiciones contractuales tiene el proveedor de IA?, entre otras variables para considerar.

En segundo lugar, hay quepreguntarse si el código generado puede incorporar material protegido de terceros. Un desarrollador puede recibir una sugerencia aparentemente original que, sin saberlo, reproduzca una estructura o fragmento existente. Por eso, utilizar IA no elimina la necesidad de revisar el código. La empresa debería establecer políticas sobre el uso de herramientas generativas, especialmente cuando se incorporan al desarrollo profesional.

Conviene determinar, entre otros factores:

a qué herramientas están autorizadas;

b qué información puede introducirse;

c qué información está prohibido introducir;

d quién revisa el código generado;

e cómo se documenta su utilización;

f cómo se verifica la procedencia de componentes;

g cómo se gestiona la confidencialidad;

h quién asume las responsabilidades contractuales frente al cliente.

También hay que analizar especialmente cuando se introduce en una herramienta externa lo que puede ser código fuente confidencial o información de clientes. En este caso, el problema deja de ser exclusivamente de propiedad intelectual y puede involucrar también secreto empresarial, confidencialidad, protección de datos y obligaciones contractuales.

El desarrollador profesional debería adoptar, por tanto, como regla básica, que la IA puede ser una herramienta de desarrollo, pero no sustituye la trazabilidad jurídica del software.


Regla práctica

En proyectos profesionales conviene conservar evidencia de cómo se incorporaron elementos generados o asistidos por IA, especialmente cuando el software tiene valor económico relevante. Se trata de poder explicar a posteriori cómo se creó el activo y bajo qué condiciones.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



 

Post 9 Vender, licenciar o entregar software, parecido no es lo mismo – 9 de 10



Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



Una de las confusiones más habituales en el mercado tecnológico consiste en utilizar la expresión “vender software” en alusión a diversas operaciones que en realidad desde el punto de vista jurídico son diferentes. Siendo más específico, se puede afirmar que una empresa puede vender una copia, otorgar una licencia, desarrollar software a medida, prestar acceso mediante SaaS, ceder derechos patrimoniales, entregar código fuente, mantener el código bajo su control y permitir solamente el uso. Todas estas acciones no son lo mismo.

El derecho de autor reconoce al titular facultades exclusivas de explotación, entre las que se incluye reproducir, distribuir, adaptar, transformar y poner la obra a disposición del público. Por eso, un contrato tecnológico debe determinar qué está recibiendo realmente el cliente.

Imaginemos una empresa que contrata un sistema por cinco años. Hay mucha información que le conviene tener para la toma de decisiones al respecto en dicho plazo. Por ejemplo, es importante que sepa si puede copiarlo, modificarlo, contratar a otro desarrollador para mantenerlo, entregarlo a una empresa vinculada, sublicenciarlo, utilizarlo después de terminar el contrato, si recibe el código fuente y tiene derecho a realizarle modificaciones, quién será titular de las mejoras, entre varias interrogantes que derivan de la aplicación de claros principios del régimen legal.

Todas estas preguntas deberían estar respondidas.

El modelo SaaS agrega, como diferencia importante, que muchas veces el cliente no recibe una copia ni adquiere el código. Recibe un derecho contractual de acceso a una funcionalidad tecnológica. En ese caso, el contrato debe ocuparse de disponibilidad, seguridad, niveles de servicio, mantenimiento, continuidad, datos, confidencialidad, propiedad intelectual y terminación.

Cuando existe una cesión de derechos patrimoniales sobre una obra, la documentación adquiere especial importancia. El régimen registral uruguayo contempla expresamente las transmisiones de derechos patrimoniales sobre software y el Decreto N.º 39/025 establece requisitos para su transferencia y eficacia frente a terceros.

La diferencia entre licencia y cesión también es decisiva para ambas partes, no son negocios que resulten indiferentes entre sí. El desarrollador que concede una licencia conserva determinados derechos, mientras que el que cede derechos puede desprenderse de facultades patrimoniales mucho más amplias. El cliente que adquiere una licencia puede tener un excelente producto para utilizar, pero no necesariamente puede modificarlo, venderlo o transferirlo. Por eso, el precio de un proyecto no debería ser el único elemento negociado. También debe negociarse qué derecho recibe el cliente por ese precio.


Regla práctica

Nunca utilizar expresiones genéricas como “el software pertenece al cliente” sin definir exactamente qué significa “pertenece”. ¿Se trata de propiedad del soporte, licencia de uso, cesión de derechos patrimoniales, acceso al código, derecho de modificación o una combinación de estos elementos? Son todas situaciones distintas.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/