¿Se pueden patentar el software, los algoritmos o los modelos de IA?

Pregunte en Internet si el software se puede patentar y encontrará dos respuestas seguras. Un lado dice que no, porque el software es abstracto. El otro dice que sí, porque existen miles de patentes de software.

Ambas respuestas son demasiado vagas para ser útiles.

Esta es la versión que desearía que los fundadores e ingenieros escucharan primero: una patente normalmente no protege un bloque de código. Los derechos de autor protegen el código que escribió como expresión. Una patente, cuando está disponible, protege una invención descrita a través de características técnicas y definida por reivindicaciones de patente, incluso si un competidor implementa posteriormente esas características con un código completamente diferente.

Es por eso que las respuestas honestas a tres preguntas comunes son todas “a veces”:

• ¿Se puede patentar el software? A veces.
• ¿Se puede patentar un algoritmo? A veces, cuando forma parte de algo más que un método abstracto.
• ¿Se puede patentar un modelo de IA? A veces, cuando la invención reivindicada es una solución técnica concreta en lugar de la etiqueta “IA” adjunta a un resultado.

Sé que “a veces” no es la respuesta satisfactoria. Pero esto lleva a la útil pregunta: ¿qué problema técnico resuelve la invención, cómo lo resuelve y qué reivindicaría exactamente la patente?

Las tres cosas que la gente sigue confundiendo

Estas tres capas son fáciles de colapsar en una sola.

El código es el texto fuente particular: las funciones, nombres de variables, estructura e implementación que escribiste. Los derechos de autor pueden proteger esa expresión, pero normalmente no impiden que alguien escriba de forma independiente un código diferente que realice la misma función.

El algoritmo es el procedimiento lógico o matemático. Una regla de clasificación, una fórmula de puntuación, un método de optimización o una arquitectura de red neuronal pueden ser intelectualmente impresionantes y comercialmente valiosos. Sin embargo, en abstracto, los métodos matemáticos y las ideas abstractas suelen estar excluidos de la protección de las patentes.

La invención implementada por computadora es el algoritmo que opera dentro de un sistema técnico definido para producir un resultado técnico. Podría ser un controlador que cambia la carga de la batería en respuesta a la degradación prevista, una tubería de procesamiento de imágenes que compensa la distorsión del sensor o un método de programación que reduce la congestión en una red de comunicaciones.

La tercera capa suele ser donde comienza un caso de patente creíble. El código es una implementación. La invención es la enseñanza técnica subyacente.

En EE. UU., agregar “en una computadora” no cambia nada

En los Estados Unidos, una reivindicación de patente de software o de IA primero debe encajar dentro de la materia elegible para patente según 35 U.S.C. 101. Los tribunales han creado excepciones para ideas abstractas, leyes de la naturaleza y fenómenos naturales. Eso significa que agregar “usar una computadora” a una regla comercial abstracta no la convierte automáticamente en una invención.

La [guía de elegibilidad de la materia] actual de la USPTO (https://www.uspto.gov/patents/laws/examination-policy/subject-matter-eligibility) pregunta, entre otras cosas, si una reivindicación de patente está dirigida a una excepción judicial y si integra esa excepción en una aplicación práctica. Sus ejemplos de IA contrastan deliberadamente las reivindicaciones de patentes que simplemente recitan conceptos matemáticos con reivindicaciones de patentes que los utilizan en una aplicación concreta.

La elegibilidad es sólo la primera puerta. La invención debe seguir siendo nueva, útil y no obvia, y la solicitud debe describirla adecuadamente. Una reivindicación de patente puede ser perfectamente “técnica” y aun así fracasar porque una patente o un documento anterior ya lo divulgaba. También puede fallar porque la aplicación promete una función sin enseñar cómo lograrla.

Esta es la razón por la que la patentabilidad del software no es un ejercicio de denominación. “Impulsado por IA”, “basado en la nube” e “implementado por un procesador” son decorativos a menos que la aplicación explique la ingeniería que hay detrás de ellos.

Europa se pregunta si la contribución es técnica

Europa utiliza un lenguaje diferente pero llega a un desafío práctico relacionado. Según el Convenio sobre Patentes Europeas, los programas informáticos y los métodos matemáticos “como tales” están excluidos. No obstante, las invenciones implementadas en ordenador pueden ser patentables cuando las características pertinentes contribuyen al carácter técnico de la invención y ayudan a resolver un problema técnico.

La guía de la EPO para 2026 establece que los modelos de inteligencia artificial y aprendizaje automático son de naturaleza matemática abstracta por sí mismos. Su uso no convierte automáticamente una invención en no patentable. Pueden contribuir cuando se aplican a un propósito técnico o se adaptan a una implementación técnica específica.

La OEP ofrece ejemplos útiles. Una red neuronal utilizada en un aparato de monitorización cardíaca para identificar latidos cardíacos irregulares puede aportar una contribución técnica. Lo mismo ocurre con la clasificación de imágenes, vídeos, audio o voz en función de las características de la señal de bajo nivel. Por el contrario, clasificar un texto sólo por su contenido lingüístico no es automáticamente un propósito técnico.

No existe una regla única a nivel mundial sobre “patentes de software”. Esto es un inconveniente, pero la lección de redacción es simple: describir la ingeniería real con suficiente detalle para que diferentes marcos legales puedan verla.

Cuatro frases que exponen la diferencia

Compara estos pares.

Débil: “Usar IA para reducir el consumo de energía”

La declaración contiene un objetivo y una herramienta de moda, pero no una invención. ¿Qué consume la energía? ¿Qué señales se observan? ¿Qué predice el modelo? ¿Qué operación física cambia? ¿Por qué ese cambio reduce el consumo en lugar de simplemente informarlo?

Más fuerte: control adaptativo de un sistema de refrigeración industrial

El sistema recibe datos de temperatura, presión, flujo y estado del compresor; genera una predicción de carga térmica a corto plazo; restringe la predicción según los límites del equipo; y cambia la secuencia del compresor para reducir la demanda máxima mientras se mantiene un rango de temperatura definido. Ahora se pueden buscar y describir el modelo, el circuito de control, las restricciones y la interacción del equipo.

Débil: “Un algoritmo que clasifica a los mejores proveedores”

Esto puede ser útil desde el punto de vista comercial, pero clasificar las opciones de negocio a partir de datos comerciales parece mucho más cercano a un proceso de decisión abstracto.

Más fuerte: enrutamiento de red bajo interferencias de radio cambiantes

El método mide las condiciones del canal a intervalos definidos, produce una estimación de la congestión a partir de datos a nivel de enlace, asigna paquetes entre rutas bajo restricciones de latencia y actualiza la tabla de enrutamiento cuando se cruza un umbral. El reclamo de la patente ya no es “elegir la mejor opción”. Está ligado al funcionamiento de un sistema de comunicaciones.

Ninguno de los ejemplos más fuertes tiene garantizada una patente. Simplemente han cruzado la línea del eslogan al mecanismo, que es donde vale la pena plantear la cuestión de las patentes.

“Utiliza una red neuronal” no es una divulgación

Las aplicaciones de IA tienen una trampa de dibujo particular: el modelo se convierte en una caja negra en la frase exacta donde ocurre todo el trabajo interesante. Veo el mismo atajo constantemente.

“El modelo genera un resultado optimizado” no le dice al lector casi nada. Es posible que un borrador útil deba explicar:

• qué representa el insumo y cómo se obtiene;
• preprocesamiento y construcción de características;
• la arquitectura del modelo relevante o las etapas de procesamiento;
• cómo se realizan el entrenamiento y la inferencia;
• restricciones, umbrales, retroalimentación o posprocesamiento;
• cómo el resultado cambia un sistema técnico; y
• qué alternativas producen el mismo efecto técnico.

No todas las aplicaciones necesitan código fuente, pesos exactos o el conjunto de datos de entrenamiento completo. Pero si el efecto depende de características particulares del conjunto de datos, es posible que sea necesario revelar esas características. La OEP señala específicamente que las características de los datos de entrenamiento necesarias para reproducir un efecto técnico deben explicarse cuando una persona capacitada no podría determinarlas sin una carga indebida.

El mismo principio se aplica fuera de la IA: no ocultar el paso inventivo detrás de la palabra “automáticamente”.

¿Puede el modelo en sí ser la invención?

A veces, los solicitantes quieren proteger un modelo entrenado como un objeto separado del sistema que lo utiliza. Esto puede resultar difícil.

Un modelo puede caracterizarse como parámetros matemáticos, una estructura de datos, una implementación legible por computadora, un método de entrenamiento, un método de inferencia o parte de un dispositivo más grande. Esas no son estrategias de reivindicación de patentes intercambiables. Su tratamiento también difiere según la jurisdicción.

En términos prácticos, el caso suele ser más sólido cuando se puede explicar al menos uno de estos:

• un uso técnico específico del modelo;
• una arquitectura modelo adaptada a una limitación técnica;
• un proceso de formación que produzca un efecto técnico demostrable;
• una implementación particular que mejora el funcionamiento del hardware u otro sistema técnico; o
• una mejora a nivel de computadora, como el uso de memoria, la distribución del procesamiento, la seguridad, la latencia o el consumo de recursos.

La guía de métodos matemáticos de la EPO ofrece un ejemplo inusualmente concreto: asignar pasos de entrenamiento con uso intensivo de datos a una GPU y pasos preparatorios a una CPU puede contribuir al carácter técnico cuando la implementación explota la arquitectura de la plataforma informática. La “IA más rápida” es vaga. Una forma definida de utilizar el hardware para lograr la mejora es mucho más útil.

No olvides la autoría de la invención cuando haya intervenido la IA

Hay una segunda cuestión de la IA que no tiene nada que ver con si la tecnología es elegible: ¿quién la inventó?

Según las [orientaciones revisadas en noviembre de 2025] de la USPTO (https://www.uspto.gov/subscription-center/2025/revised-inventorship-guidance-ai-assisted-inventions), solo las personas físicas pueden ser nombradas inventoras. Los sistemas de IA se tratan como herramientas y el estándar legal ordinario se aplica a los humanos que concibieron la invención reivindicada.

El uso de IA durante la investigación o el desarrollo no impide automáticamente una patente. Hace que la documentación sea sensata. Mantenga un registro del problema técnico que identificó el equipo, las decisiones que tomó la gente, qué resultados propuestos fueron aceptados o rechazados y cómo tomó forma la solución reclamada.

La patente no debería convertirse en un diario de cada solicitud. La empresa aún debería poder explicar la concepción humana detrás de lo que afirma la patente.

Busque más que nombres de productos

Los fundadores de software suelen buscar el nombre de su categoría de producto, no encuentran nada y se sienten aliviados. Me sentiría sospechoso. El estado de la técnica pertinente puede describir el mismo mecanismo en un mercado completamente diferente.

Una técnica de gestión de colas para trabajos en la nube puede parecerse a la programación utilizada en las telecomunicaciones. Una función de detección de fraude puede compartir arquitectura con la detección de fallas en sensores industriales. Un modelo de recomendación puede parecer novedoso en el sector minorista, pero familiar en el ranking de medios.

Busque el mecanismo técnico en varios niveles:

1. El resultado. ¿Qué logra el sistema?
2. El método. ¿Qué secuencia o modelo produce ese resultado?
3. La arquitectura. ¿Qué componentes intercambian qué datos?
4. La limitación. ¿Qué limitación técnica se está superando?
5. El efecto. ¿Qué se vuelve más rápido, más seguro, más preciso, menos intensivo en recursos o físicamente diferente?

Patenta le permite describir ese mecanismo en lenguaje común y buscar documentos de patente por significado en todas las jurisdicciones. Una vez que encuentre los sistemas más cercanos, podrá comparar sus características con las suyas y llevar las distinciones a un borrador estructurado en lugar de comenzar desde un documento en blanco.

Las bases de datos de patentes no representan todo el universo del estado de la técnica. Para el software y la IA, los artículos, los estándares, la documentación, el material de conferencias, los repositorios de código abierto y los productos públicos anteriores también pueden ser importantes. Utilice la búsqueda de patentes como un sólido punto de partida, no como una promesa de que no existe nada más.

Decida qué pertenece a la patente y qué no

Una patente no es la única forma de proteger un producto de software.

• Los derechos de autor protegen el código fuente y otras expresiones originales, no la función subyacente.
• La protección de secretos comerciales puede ser adecuada para ponderaciones de modelos, métodos de evaluación interna, procesos de limpieza de datos o técnicas del lado del servidor que pueden permanecer confidenciales.
• Una patente puede proteger un método o sistema técnico reivindicado incluso cuando un competidor escribe un código diferente.

La cuestión empresarial es si la divulgación vale el derecho potencial. Si un proceso es invisible en sus servidores y difícil de detectar desde el exterior, mantenerlo en secreto puede ser la medida más fuerte. Si la invención será visible en un producto, estándar, comportamiento API o dispositivo, la protección de la patente puede ser más valiosa.

La respuesta también puede ser una combinación: patentar la arquitectura técnica externamente significativa, mantener confidenciales los métodos de ajuste y los datos operativos y confiar en los derechos de autor del código en sí.

Una lista de verificación práctica para la redacción

Antes de iniciar un borrador de patente de software o IA, anote:

1. El problema técnico. Evite describir solo el objetivo comercial.
2. El contexto del sistema. Identifique los dispositivos, servicios, sensores, procesadores, redes o almacenamiento involucrados.
3. La ruta de procesamiento. Siga los datos desde la entrada hasta la salida técnica.
4. La distinción inventiva. Indique qué sucede aquí que el estado de la técnica más cercano no enseña.
5. El efecto técnico. Explique la mejora operativa y cómo la producen las características reclamadas.
6. La implementación. Incluya suficientes detalles para evitar que el paso clave se convierta en una caja negra.
7. Las alternativas. Registre diferentes arquitecturas, modelos, umbrales y disposiciones de implementación.
8. La evidencia. Conserve puntos de referencia, simulaciones y razonamientos de diseño sin inventar resultados que no tiene.
9. La contribución humana. Mantenga un registro práctico de invención cuando las herramientas de IA participaron en el desarrollo.

Eso es suficiente para comenzar una búsqueda significativa y un primer borrador. El borrador le dirá, sin mucha diplomacia, dónde la explicación todavía se basa en etiquetas en lugar de ingeniería.

En resumen

El software, los algoritmos y los modelos de IA no están categóricamente fuera del sistema de patentes. Tampoco son patentables simplemente porque son un código nuevo.

El candidato más sólido es una solución técnica concreta: algo que pueda explicarse como sistema o método, diferenciarse del estado de la técnica, vincularse a un efecto técnico y describirse con detalle suficiente para llevarlo a la práctica.

No empiece con “usamos IA”. Comience con el problema, el mecanismo y el cambio que produce el mecanismo.

¿Crees que tu software o sistema de IA contiene una invención técnica patentable? Descríbela en Patenta, busca el estado de la técnica más cercano y convierte la diferencia técnica que quede en un primer borrador estructurado.