Cuando una empresa de tecnología climática obtiene una patente, es fácil pensar que la protección tecnológica ha terminado. Sin embargo, un producto real no funciona únicamente con las invenciones descritas en las reivindicaciones. Los coeficientes de calibración de los sensores, las reglas para decidir dónde instalar equipos en cada establo, el código que detecta datos faltantes, los datos de entrenamiento, los registros operativos de cada cliente, las API, los paneles y los procedimientos de respuesta en campo crean conjuntamente el rendimiento. Algunos de estos activos pueden patentarse; otros solo conservan su valor si se mantienen confidenciales, y otros requieren delimitar su uso mediante derechos de autor o contratos.

Por tanto, una estrategia de PI posterior a la patente no consiste en registrar el mayor número posible de derechos. Consiste en decidir qué activos mostrar, a quién y hasta qué nivel, y con qué medios gestionar los riesgos de filtración, copia, desarrollo independiente y reutilización después de terminar un contrato. Como cada herramienta de protección tiene requisitos y límites diferentes, una misma tecnología debe diseñarse en varias capas.

Primero hay que corregir un malentendido: una patente no es un certificado de propiedad de todo el producto

Una patente es un derecho exclusivo reconocido en un país o región determinados para una invención que cumple ciertos requisitos. Este artículo ofrece un marco operativo general; las excepciones de novedad, las invenciones laborales, la protección de datos y la eficacia contractual dependen de la legislación y los contratos de cada país, por lo que deben ser revisadas por profesionales locales. La OMPI explica que las patentes son derechos territoriales y solo tienen efecto en el país o región que las concede. Una solicitud o registro nacional no protege automáticamente el país de venta extranjero, y una solicitud internacional PCT tampoco otorga una única patente mundial. Las decisiones de entrada deben considerar país objetivo, país de fabricación, competidores y posibilidad de hacer valer el derecho.

La patente también funciona obteniendo derechos a cambio de divulgar la invención. Revelar lo esencial en un artículo, una exposición, una propuesta o una demostración al cliente antes de presentar la solicitud puede destruir la novedad en algunos países. Por el contrario, si la divulgación facilita el diseño alternativo y es difícil detectar una infracción, puede ser más adecuado un secreto empresarial. Ambos extremos —patentarlo todo u ocultarlo todo— son arriesgados.

Los derechos de autor tampoco son una solución universal. La OMPI explica que los programas informáticos y las bases de datos pueden estar protegidos por derechos de autor, pero la protección alcanza la expresión y no las ideas, los procedimientos, los métodos de operación ni los conceptos matemáticos en sí. Los derechos de autor por sí solos difícilmente impedirán que un competidor implemente independientemente la misma función con otro código. En última instancia hay que combinar patentes, secretos empresariales, derechos de autor, marcas, contratos y seguridad según el papel de cada uno.

El primer paso es crear un mapa de activos de PI

Descomponga la plataforma de metano ganadero en activos, en lugar de tratarla como una sola invención. El hardware puede incluir la disposición de sensores, los circuitos de muestreo, los equipos de calibración y los planos de fabricación. La capa analítica puede incluir fórmulas para estimar la ventilación, detección de valores atípicos, modelos de referencia, características y pesos del modelo. La capa de datos puede incluir observaciones sin procesar, etiquetas, datos de actividad, historial de calibración, emisiones derivadas e informes. La capa de software puede incluir firmware, aplicaciones Edge, código en la nube, especificaciones de API, interfaz y scripts de despliegue. La capa comercial puede incluir precios, listas de clientes, costes de instalación y evaluaciones de socios.

Para cada activo registre como mínimo propietario, creador o inventor, fecha de creación, ubicación de almacenamiento, estado de divulgación, versión del producto, valor comercial, posibilidad de ingeniería inversa, impacto de una filtración, contratos relacionados y medidas de protección. No suponga que el código de un empleado, el firmware de un contratista, un modelo creado con una universidad y los datos aportados por una granja tienen el mismo titular. Pagar algo o administrar el servidor tampoco transfiere automáticamente todos los derechos necesarios.

El mapa de activos no debe terminar como una lista del equipo jurídico. Conéctelo con el flujo real de funciones del producto, canalizaciones de datos y contratos. Por ejemplo, el elemento «modelo de emisiones v3» debe enlazar el uso permitido de los datos originales, las bibliotecas de código abierto, el repositorio, el ID de ejecución de entrenamiento, el hash del modelo desplegado y los documentos de divulgación externa. Así, el alcance de protección y las obligaciones se actualizan cuando cambia la tecnología.

Para los algoritmos, defina primero el límite entre patente y secreto empresarial

Bajo el nombre de algoritmo se mezclan cosas diferentes: métodos de procesamiento que producen un efecto técnico, arquitectura del modelo, selección de características, depuración de datos de entrenamiento, umbrales, valores de ajuste por instalación y documentos explicativos. Según la jurisdicción y las reivindicaciones concretas, algunos pueden merecer una revisión de patentabilidad, pero la etiqueta «algoritmo de IA (AI)» por sí sola no crea patentabilidad. Antes de divulgar, revise con un agente de patentes los elementos inventivos, el estado de la técnica y los países donde se busca protección.

Si el uso del producto revela su función pero dificulta descubrir sus parámetros internos, puede estudiarse una estrategia de secreto empresarial. No basta con declarar confidencial una información para protegerla. En general, la OMPI exige que tenga valor comercial por ser secreta, que solo la conozca un grupo limitado y que su titular adopte medidas razonables para mantenerla en secreto. Tampoco es un sistema para ejercer exclusividad contra quien desarrolla el mismo método de forma independiente o lo somete legalmente a ingeniería inversa.

Al tratar un algoritmo como secreto empresarial no bloquee solo los archivos del modelo. Clasifique por niveles las definiciones de características, los datos de entrenamiento y validación, los hiperparámetros, los límites de rendimiento y la configuración de despliegue, y conceda acceso únicamente a quienes lo necesiten para su trabajo. Gestione conjuntamente permisos del repositorio, autenticación multifactor, registros de exportación, cifrado, acuerdos de confidencialidad con socios y recuperación o revocación del acceso al salir o terminar un contrato. Los artículos y materiales para clientes deben ofrecer información suficiente para evaluar el rendimiento sin revelar automáticamente parámetros secretos innecesarios para reproducirlo.

Los datos no se protegen con una sola palabra: «propiedad»

Pueden surgir conflictos si una plataforma supone que posee todos los derechos solo porque almacena los datos de sensores en su servidor. Los datos de actividad aportados por una granja, los valores brutos observados por el equipo, las etiquetas de eventos añadidas por personas, las correcciones de un modelo, las emisiones agregadas, los informes del cliente y los modelos entrenados con varias granjas tienen creadores e intereses distintos. Los datos, la estructura de la base, los secretos empresariales, la información personal y los derechos contractuales de uso son cuestiones separadas.

En los contratos, exprese los permisos mediante verbos y no con una «propiedad de datos» abstracta. Separe quién puede recopilar, consultar, copiar, corregir, combinar, entrenar modelos, entregar datos a terceros y utilizarlos en afirmaciones externas, junto con finalidad, plazo, territorio y nivel de anonimización. Al terminar, defina la devolución y eliminación de los datos originales, el tratamiento de copias de seguridad, el uso continuado de estadísticas agregadas y modelos existentes, y las obligaciones legales de conservación. Conceda al verificador acceso de lectura solo durante el periodo y con el alcance necesarios para confirmar una afirmación.

Los derechos de datos amplios no son automáticamente la mejor estrategia. Un derecho indefinido con finalidad poco clara puede reducir la confianza de una granja y convertirse en una carga en la regulación extranjera y las revisiones de compras de clientes. Pero sin derechos de corrección, control de calidad y mejora del modelo necesarios para prestar el servicio, el producto es difícil de operar. Ajuste los permisos mínimos necesarios al valor que pueda explicarse al cliente.

Gestione conjuntamente el código, las dependencias y los derechos de distribución

Los derechos de autor del software protegen la expresión del código, pero en el negocio las primeras preguntas son quién lo escribió y qué derechos obtuvo la empresa. Revise los acuerdos con empleados, autónomos, contratistas y socios de investigación conjunta, y especifique la titularidad de los entregables, los derechos de modificación, reproducción, distribución y sublicencia, la entrega del código fuente y si se incluyen documentación y pruebas. Los commits y registros de revisión del repositorio ayudan a demostrar el proceso de creación y sus versiones.

El código abierto no queda exento de revisión de derechos por ser gratuito. Registre componentes, versiones, licencias, modificaciones y métodos de distribución en una lista de materiales de software, y compruebe las obligaciones de avisos y entrega del código fuente. El firmware de sensores, las imágenes Edge, los servicios en la nube y los programas instalados en el cliente se distribuyen de forma diferente; no aplique sin más la misma conclusión de licencia a todos. El código generado por AI también debe gestionarse en el proceso de desarrollo para acreditar su procedencia, revisarlo, probar su seguridad y detectar posibles conflictos de licencia.

Los contratos con clientes deben distinguir el derecho de acceso a la cuenta de la propiedad del software. El cliente puede recibir derecho a usar los resultados sin recibir el código fuente ni el modelo. A la inversa, para prepararse ante la interrupción del servicio por un proveedor, un comprador empresarial puede pedir custodia del código fuente, exportación de datos y apoyo de transición. Defina condiciones de activación, alcance, coste y deberes de confidencialidad, en vez de rechazar o transferirlo todo automáticamente.

Escenario de campo: desarrollo conjunto con una granja, una universidad y un socio fabricante

Supongamos una empresa hipotética de monitorización de metano que recopila datos en una granja, mejora un modelo de emisiones con un equipo universitario y encarga a un fabricante el firmware de una pasarela. Si la titularidad de los resultados se discute solo después de iniciar la investigación conjunta, pueden entrar en conflicto la determinación de los inventores, las publicaciones, el uso del código y el alcance del entrenamiento con datos.

Antes de comenzar, fije una lista de la PI previa que aporta cada parte. Para la PI generada en el trabajo conjunto, establezca por invención y obra la titularidad, las decisiones de solicitud, los costes, las licencias y los ámbitos comerciales. Los procedimientos de publicación universitaria deben incluir un periodo de revisión previo para presentar solicitudes y retirar secretos empresariales. Separe el consentimiento de datos de la granja para investigación, prestación del servicio, entrenamiento del modelo y estudios de caso públicos, y entregue al fabricante solo los planos, claves y módulos de firmware necesarios para producir.

La OMPI también explica que los acuerdos de transferencia tecnológica distinguen licencias de cesiones, y que los acuerdos de investigación conjunta deben tratar la PI previa, la titularidad y el acceso a resultados, beneficios y riesgos, y los derechos de comercialización. Ajuste el acuerdo con asesoría jurídica a la colaboración y jurisdicción reales, en lugar de usar una plantilla sin cambios. Este marco no constituye asesoramiento jurídico.

Norma operativa: conecte el registro de PI con una puerta de divulgación

El registro de PI debe contener más que números de patente. Registre ID y tipo de activo, propietario, creador o inventor, contratos relacionados, jurisdicción, estado de divulgación, nivel de confidencialidad, usuarios autorizados, repositorio, versión del producto, fecha de renovación o revisión y responsable de responder a infracciones o filtraciones. Compárelo cada trimestre con la hoja de ruta del producto para detectar código, datos o conocimientos que falten.

Establezca una única puerta para la divulgación externa. Antes de publicar un artículo, comunicado, propuesta, repositorio Git público, demostración en una exposición o documento de API para clientes, revise la necesidad de solicitar una patente, los secretos empresariales, los datos personales, los contratos del cliente y las obligaciones de código abierto. Conservar el resultado de aprobación y el hash de divulgación permite rastrear qué se divulgó y cuándo.

Prepare también la respuesta a incidentes. Si se filtran credenciales, se copia un repositorio, no se recupera el equipo de un empleado que se marcha o un socio usa material fuera de su finalidad, determine quién bloqueará el acceso, conservará pruebas, evaluará el impacto, enviará avisos contractuales y emprenderá acciones legales. Como es difícil restaurar el secreto después de una filtración, importan la prevención y la rapidez de respuesta.

Lista de comprobación de implementación

  • ¿Ha dividido el producto en activos de hardware, algoritmos, datos, software y conocimientos operativos?

  • ¿Ha separado correctamente la jurisdicción y el estado de las solicitudes o registros nacionales de los derechos extranjeros?

  • ¿Revisa la novedad, la información confidencial y la autorización del cliente antes de las presentaciones externas?

  • ¿Elige entre patente y secreto empresarial según la posibilidad de ingeniería inversa, el coste de divulgación y la posibilidad de hacer valer el derecho?

  • ¿Se aplican realmente la lista de secretos, sus niveles, el mínimo privilegio, los acuerdos de confidencialidad y los procedimientos de salida o terminación?

  • ¿Ha separado en el contrato los datos brutos, las etiquetas, los valores derivados, los informes y los derechos de entrenamiento del modelo?

  • ¿Ha documentado la titularidad y el uso permitido de resultados de empleados, contratistas e investigaciones conjuntas?

  • ¿Gestiona los componentes de código abierto y las obligaciones de licencia según la forma de distribución?

  • ¿El registro de PI conecta las versiones del producto, modelo y datos con los contratos relacionados?

  • ¿Expertos locales revisan las diferencias entre leyes y contratos nacionales antes de entrar en un mercado?

Conclusión: una cartera de PI es un sistema para operar los límites de la tecnología

La patente es un punto de partida importante, pero no protege a la vez los parámetros secretos de un algoritmo, los derechos de uso de datos de una granja, el código de software y los conocimientos prácticos de campo. Como los activos protegidos y las vías de exposición son distintos, coloque patentes, secretos empresariales, derechos de autor, contratos y controles de seguridad alrededor de cada activo.

Una buena estrategia de PI no encierra toda la información. Ofrezca a clientes y verificadores pruebas para juzgar el rendimiento, mientras protege mediante el mínimo privilegio los secretos innecesarios para reproducirlo. Cuando pueda rastrear quién creó algo y quién puede usarlo, dónde es efectivo y qué queda después de terminar un contrato, la PI se convierte en una base operativa para ampliar productos y colaboraciones, no en un conjunto de certificados de registro.

Fuentes