IPOS eleva el nivel de redacción para patentes de IA y datos

Con su guía complementaria sobre solicitudes de patente relacionadas con IA, IPOS ha dejado una señal bastante clara para quienes redactan este tipo de expedientes: el problema ya no es solo defender que una invención basada en software no debe verse automáticamente como abstracta. El problema real es demostrar que la reivindicación y la memoria describen una contribución técnica reconocible, vinculada a un problema concreto y no a un modelo matemático presentado con lenguaje de sector.

Por eso esta actualización importa tanto. La presión práctica se desplaza hacia zonas que muchas solicitudes siguen tratando de forma demasiado genérica: el tratamiento de datos de entrenamiento, la mejora del dataset, los ajustes del modelo después del entrenamiento y el nivel de detalle necesario para explicar por qué esos pasos producen un resultado técnico. Si la reivindicación sigue pareciendo un algoritmo genérico, o un modelo ejecutado sobre hardware convencional sin más, el riesgo de quedar atrapado en la objeción por método matemático no desaparece. Lo que IPOS está pidiendo, en el fondo, es una cadena visible: qué hace el modelo, con qué entradas y salidas trabaja, en qué entorno técnico opera y qué consecuencia técnica se obtiene.

La cuestión ya no es la IA en abstracto, sino si la reivindicación describe una solución técnica real

Muchas solicitudes de patentes sobre IA siguen arrancando con una fórmula conocida: se menciona una red neuronal o un modelo de aprendizaje automático, se añade que sirve para clasificar, controlar, predecir u optimizar, y se deja que el sector de aplicación haga el resto. IPOS está dando a entender que esa forma de redactar pierde fuerza. El examen se centra en construir la reivindicación, identificar su contribución real y preguntarse después si esa contribución cae únicamente en materia excluida, como un método matemático, un método de negocio o la mera presentación de información. Eso cambia bastante el enfoque. No basta con introducir vocabulario de IA.

El punto débil suele estar en un lenguaje funcional demasiado amplio para revelar un problema técnico específico. Decir que el modelo sirve “para controlar un sistema” o “para gestionar riesgo” puede sonar útil, pero sigue siendo demasiado abierto si no se entiende qué sistema, qué restricción técnica y qué relación causal existe entre las etapas reivindicadas y la solución propuesta. Las solicitudes más sólidas serán las que definan el problema con la suficiente precisión como para que parezca técnico, y no solo sectorial. Ahí es donde una solicitud deja de sonar a promesa general y empieza a leerse como una arquitectura concreta.

El trabajo sobre datos de entrenamiento gana protagonismo, pero el dataset no puede quedarse en contenido informativo

Una de las partes más valiosas de la guía de IPOS es que no trata el trabajo sobre datos de entrenamiento como algo accesorio. Reconoce de forma expresa que puede buscarse protección cuando las características del dataset forman parte del método de entrenamiento, o cuando la invención consiste en generar o mejorar un conjunto de datos dirigido a un problema específico. Esto es especialmente relevante para IA generativa, modelización industrial, predicción médica o verificación de identidad, donde muchas veces la aportación inventiva no está solo en la arquitectura del modelo, sino en la selección, síntesis, aumento, depuración o estructuración de los datos.

Pero la frontera también queda bastante nítida. Si el dataset se describe solo por su contenido informativo o por la forma en que se entrega, la solicitud sigue corriendo el riesgo de ser vista como simple presentación de información. Desde el punto de vista comercial, esta distinción es clave. La expresión “datos de entrenamiento” no hace el trabajo jurídico por sí sola. Hay que explicar cómo actúan esas características dentro del proceso técnico, cómo influyen en el entrenamiento o en la inferencia y por qué ayudan a resolver el problema identificado. En la práctica, esto obliga a adelantar detalle de ingeniería. La procedencia de los datos, la lógica de selección, el etiquetado, el aumento y las restricciones de uso ya no pueden quedarse en un segundo plano si son la base real de la reivindicación.

El fine-tuning y los ajustes posteriores al entrenamiento necesitan algo más que prometer mejor rendimiento

Los ejemplos de la guía también dejan entrever dónde se tensará el examen para las reivindicaciones sobre ajuste del modelo. En lenguaje de negocio se habla de fine-tuning, adaptación, poda, extensión u optimización. En lenguaje de patentes, esas etiquetas no bastan. Si la reivindicación solo afirma que una red ya entrenada se amplía, se reduce, se repondera o se ajusta sin anclar ese paso a un problema técnico concreto, la contribución real puede seguir considerándose una variación algorítmica abstracta. “Más precisión” o “mejor rendimiento” no es todavía una posición patentable si no se dice en qué sistema, bajo qué limitación y con qué efecto verificable ocurre.

La vía más segura es devolver esos ajustes al contexto del sistema. ¿El cambio permite ejecutar una tarea computacional en un procesador con recursos limitados? ¿Mejora la predicción de un parámetro concreto de fabricación? ¿Ayuda a detectar antes un evento médico bien definido? ¿Corrige escasez o desequilibrio de muestras en detección de fraude? Ese tipo de anclaje hace que la reivindicación se lea como solución técnica y no como guion genérico de optimización. Para las solicitudes de IA generativa esto pesa todavía más, porque el fine-tuning suele describirse como una capacidad amplia y casi automática. IPOS está obligando a explicar por qué ese ajuste era necesario, qué cambió técnicamente y qué consecuencia medible produjo en el sistema.

La carga de divulgación se adelanta, y la preparación de la evidencia también

IPOS indica que, cuando la materia reivindicada depende de características particulares del dataset de entrenamiento, esas características deben divulgarse salvo que resulten evidentes o puedan determinarse sin carga indebida. Esa frase tiene bastante más alcance de lo que parece. En muchas solicitudes de IA, la fragilidad empezará a verse no solo en actividad inventiva, sino también en soporte y suficiencia descriptiva. Una memoria que dibuja el modelo en términos amplios pero dice poco sobre las características de los datos, los criterios de selección, las condiciones de entrenamiento o la forma de validación puede quedar expuesta por varios flancos al mismo tiempo.

Eso obliga a cambiar el flujo interno de preparación. Un esquema habitual ha sido recibir del equipo técnico un diagrama del modelo y añadir más tarde la narrativa de aplicación. Para expedientes más sólidos, suele ser preferible invertir ese orden: definir primero el problema técnico, identificar después las características del dataset y los pasos de procesamiento que realmente importan, fijar métricas de evaluación y comparaciones de referencia, y solo entonces decidir qué va en la reivindicación independiente y qué debe quedar en los ejemplos para sostenerla. Para quien quiera reducir el riesgo de una objeción por método matemático, métricas concretas de rendimiento, experimentos comparativos y datos de efecto a nivel de sistema empiezan a parecer menos un lujo y más el material mínimo para que la solicitud se mantenga en pie.

La consecuencia de fondo de esta actualización no es que Singapur se haya vuelto hostil a las patentes de IA. Lo que ha hecho IPOS es reducir el espacio para la redacción ambigua. El tratamiento de datos de entrenamiento, el ajuste del modelo y la forma de desplegar el algoritmo ahora exigen una escritura más precisa. Quienes consigan conectar con claridad el problema técnico, el procesamiento reivindicado, las características de los datos y el efecto técnico resultante tendrán muchas más posibilidades de atravesar el examen con menos fricción.