Listado de la etiqueta: Inteligencia Artificial
Comentarios Proyecto de Ley IA en Chile
Existe una urgencia por regular la IA en Chile y, para ello, se ha tomado como referencia el Reglamento de IA de EU con ya dos proyectos de ley. Sin embargo, a pesar de nuestra preferencia por la legislación europea, no se ha analizado cómo EU regula la IA.
Regulación de IA y sistemas de gestión de riesgos
Regulación de IA y sistemas de gestión de riesgos
En un panorama (global) donde las altas cargas regulatorias presionan los presupuestos de cumplimiento dentro de una organización, se hace imperativo gestionar los recursos de una forma eficiente y en eso, la capacidad de implementar y operar un sistema de gestión de riesgos se convierte en una práctica esencial que permite a una empresa dar prioridad a aquellos riesgos críticos y a los más inmediatos por encima de los riesgos menores, pudiendo establecer una planificación sostenible y de acuerdo a cada contexto (y bolsillo).
La metodología de evaluación de riesgos que se implementa debe poder evaluar la probabilidad, el tamaño y los impactos del riesgo y la naturaleza y adecuación de los controles que deben aplicarse para mitigarlo. Esto no se puede lograr sin el uso de puntos de referencia fiables con los que se puedan comparar, contrastar y juzgar estas cuestiones, en esencia como punto de referencia está la Ley secundada por estándares técnicos.
Esto es así, dentro del contexto de delitos económicos, protección de datos personales y ciberseguridad (con una nueva normativa entrante), pero no había existido claridad sobre la gestión de riesgos en materia de inteligencia artificial, ni desde el punto de vista de los desarrolladores ni de los desplegadores de está tecnología.
Digo «había» porque desde hace poco la certeza ha dejado de lado la incertidumbre. En un corto periodo de tiempo se ha establecido un estándar común, que para muchos les será familiar si conocen las normas ISO, que tiene como referencia una norma vinculante y un estándar técnico.
La norma vinculante es el nuevo Reglamento Europeo de IA, conocido como Ley de IA, que dentro de las obligaciones que aplica a los sistemas de alto riesgo, incorpora un sistema de gestión de riesgo a la luz y de acuerdo con las practicas que por años ha acuñado el estándar ISO 31000, por ejemplo, (nadie está inventando la rueda en esta materia). ISO tiene una norma específica para gestión de riesgos en sistemas de IA, que es la ISO 42001.
Dicho Reglamento establece las directrices para un sistema de gestión de riesgos robusto y eficaz y que si bien es exigible para los sistemas de IA de alto riesgo, debiese ser la norma y regla común no solo para cualquier desarrollador sino que para cualquier empresa que adquiere un sistema de IA y lo despliega en sus operaciones.
El Artículo 9, en particular, indica los componentes del sistema de gestión de riesgo y que es lo que espera se traduzca como un cumplimiento eficaz de la norma.
Aquí les dejo un esquema del contenido de este artículo, que ilustra la profundidad e importancia que adquieren los sistemas de gestión de riesgos:
- Establecimiento y Mantenimiento: Se debe establecer, implementar, documentar y mantener un sistema de gestión de riesgos para los sistemas de IA de alto riesgo. Este sistema será un proceso continuo y planificado durante todo el ciclo de vida del sistema de IA.
- Proceso Iterativo: El sistema de gestión de riesgos es un proceso iterativo y continuo que incluye revisiones y actualizaciones periódicas.
- Etapas del Sistema de Gestión de Riesgos: Determinación y Análisis de Riesgos: Identificar y analizar riesgos conocidos y previsibles para la salud, seguridad o derechos fundamentales cuando se usa el sistema de IA según su finalidad prevista. Estimación y Evaluación de Riesgos: Evaluar riesgos que podrían surgir tanto en el uso previsto como en un uso indebido razonablemente previsible. Evaluación de Otros Riesgos: Analizar otros riesgos basándose en los datos recopilados a través del sistema de vigilancia poscomercialización (Artículo 72). Adopción de Medidas de Gestión de Riesgos: Implementar medidas específicas para gestionar los riesgos identificados.
- Riesgos Abordables: Solo se consideran aquellos riesgos que pueden mitigarse o eliminarse razonablemente mediante el desarrollo, diseño del sistema o suministro de información técnica adecuada.
- Consideración de Interacciones: Las medidas de gestión de riesgos deben tener en cuenta los efectos y posibles interacciones entre los requisitos para minimizar los riesgos de manera eficaz.
- Riesgos Residuales: Se deben considerar aceptables los riesgos residuales asociados a cada peligro y el riesgo residual general del sistema de IA.
- Medidas de Gestión de Riesgos Adecuadas: Eliminación o Reducción de Riesgos: Reducir los riesgos mediante un diseño y desarrollo adecuados del sistema. Medidas de Mitigación y Control: Implementar medidas adecuadas para controlar los riesgos no eliminables. Provisión de Información y Formación: Proporcionar la información necesaria y formación adecuada a los responsables del despliegue.
- Conocimiento y Experiencia del Responsable del Despliegue: Tener en cuenta el conocimiento técnico, experiencia, educación y formación del responsable del despliegue y el contexto de uso del sistema.
- Pruebas de los Sistemas de IA de Alto Riesgo: Determinación de Medidas Adecuadas: Realizar pruebas para determinar las medidas de gestión de riesgos más adecuadas. Coherencia con la Finalidad Prevista: Asegurar que el sistema funciona según su propósito y cumple con los requisitos establecidos. Pruebas en Condiciones Reales: Realizar pruebas en condiciones reales según sea necesario (Artículo 60). Parámetros y Umbrales Definidos: Utilizar parámetros y umbrales de probabilidad adecuados durante las pruebas.
- Atención a Colectivos Vulnerables: Considerar el impacto potencial en menores de 18 años y otros colectivos vulnerables al implementar el sistema de gestión de riesgos.
- Integración con Otros Requisitos de Gestión de Riesgos: Los proveedores pueden integrar estos aspectos en sus procedimientos internos de gestión de riesgos según otras disposiciones relevantes del Derecho de la Unión.
Me gustaría hacer un alcance final sobre la gestión de riesgos en IA, que puede que en esta norma no se logre apreciar con claridad. No debemos olvidar que los sistemas de IA son, en primer lugar, sistemas sociotécnicos, no se pueden explicar ni conceptualizar solo con elementos técnicos, por lo que, las decisiones de diseñadores, desarrolladores e implementadores, así como, el contexto social donde son desplegados juegan un rol fundamental a la hora de conceptualizar y analizar riesgos y daños. Este enfoque en materia de gestión de riesgos en IA es fundamental. Un buen ejemplo de esta mirada lo desarrolla el NIST con su programa piloto ARIA, lanzado hace unos días, como una nueva aproximación a la gestión de riesgos, tomando en consideración todo el componente social y contextual que está indefectiblemente unido a las consecuencias del uso de esta tecnología. Recomiendo mucho echar un vistazo por la página web del NIST y este proyecto piloto, es muy interesante.
IA y PI
Escrito por Catherine Muñoz
No existe una forma unitaria de protección de sistemas de inteligencia artificial, a través de la propiedad intelectual. Para determinar cual es la protección, es preciso distinguir entre (1) dataset, (2) algoritmos y modelos u otro tipo de métodos matemáticos.
Históricamente la protección de softwares y bases de datos estaba radicada exclusivamente en el derecho de autor. Al respecto, el Convenio de Berna establece en su artículo 1° que «la obra literaria y artística comprenderá todas las producciones del dominio literario, científico y artístico, cualquiera que sea el modo o la forma de su expresión.» Por su parte, el artículo 10.1 del Acuerdo sobre los Aspectos de los Derechos de Propiedad Intelectual relacionados con el Comercio (ADPIC 2002) dispone que «Los programas de ordenador, ya sea en el código fuente o en el código objeto, estarán protegidos como obras literarias en virtud del Convenio de Berna (1971)”.
El código fuente es la expresión de los programas informáticos escritos en caracteres alfanuméricos en un texto plano[1]. Por su parte, el código objeto corresponde a la compilación del código fuente[2]. Sobre la base de las normas mencionadas anteriormente, ambas expresiones se consideran una obra literaria y se protegen como una expresión de una idea.
Sin embargo, en la actualidad la protección de dataset, modelos y algoritmos por el derecho de autor posee serios inconvenientes. Básicamente, el problema radica en que la idea o funcionalidad subyacente detrás de este tipo de tecnología, no es protegida por el derecho de autor.
Un punto fundamental para entender esta problemática es el principio de «idea-expresión», uno de los principios del derecho de autor, que postula básicamente que las ideas como tales no están protegidas por la propiedad intelectual (derecho de autor o copyright) ; en otras palabras, se protege la forma de expresión de una idea y no la idea en sí. Esto está en concordancia con el fin principal del derecho de autor que busca la promoción y desarrollo del arte, no correspondiendo a un mecanismo de recompensa por los esfuerzos, en este caso del autor, como si ocurre en el sistema de patentes de invención [3].
Asimismo, existen otros inconvenientes, el sistema de derechos de autor protege al autor contra la copia literal de líneas de un código fuente. Esto deja abierta la posibilidad de que los competidores eviten las infracciones implementando el mismo algoritmo con un texto diferente[4]
Respecto de las bases de datos, la situación es similar, el derecho de autor protege las bases de datos o las diferentes formas de recopilar información, pero no incluye la funcionalidad técnica de estas bases de datos, que en definitiva en el caso de las ML son su característica más preciada.
Secretos comerciales y machine learning
Un secreto comercial no es un derecho de propiedad intelectual, sin perjuicio de ser una institución protegida por este tipo de normas y que corresponde a un mecanismo de protección bastante equivalente a los derechos industriales, permitiendo proteger información no divulgada, siempre y cuando ésta sea secreta, tenga valor comercial y algún grado razonable de protección. Es fácil de aplicar, no requiere ningún registro, plazo y no tiene requisitos adicionales. Yo siempre digo que los secreto comercial no son un derecho de propiedad intelectual sino algo mucho mejor.
Al respecto, el Acuerdo sobre los Aspectos de los Derechos de Propiedad Intelectual relacionados con el Comercio (ADPIC) en su artículo 39° establecen el marco de la protección contra la competencia desleal prevista en el artículo 10 bis del Convenio de París, disponiendo que “la información comercial pertinente debe protegerse de la divulgación no autorizada siempre que cumpla los siguientes requisitos: i) ser tratada como secreta, ii) tener un valor comercial por ser secreta, y iii) haber sido objeto de medidas razonables, según las circunstancias, por la persona que tiene el control legal de la información, para mantenerla secreta”.
Los dataset, pueden ser los mayores activos de una empresa tecnológica, en términos generales, se protegen a través de secretos comerciales. Al respecto, teniendo presente que los desarrolladores necesitan datos de buena calidad para obtener modelos más precisos, estos son procesados por complejos y costosos mecanismos de ajustes.[5]
En consecuencia, las empresas que poseen dataset de alta calidad, buscarán no compartirlo con otras empresas o el público y mantenerlos en secreto, disfrutando así de una importante ventaja comparativa. Sin perjuicio de lo anterior, existen empresas que se ven obligadas a compartir sus datos por razones estratégicas de negocio, como pueden ser aquellas que estén dentro de alianzas con otras empresas o con instituciones públicas, pero el primer supuesto es la regla general y la mejor opción para la protección de los dataset.
Si bien los secretos comerciales son una protección adecuada para los dataset, no lo son para la mayor parte de algoritmos y modelos de ML. Aunque el secreto comercial posee una protección que supera cualquier derecho de patentes, siempre lleva implícita la condición que no pueda ser obtenido de forma independiente, condición que muchas veces no está presente en este tipo de tecnologías, presentado una serie de desventajas este tipo de protección.
En primer lugar, uno de los problemas de los secretos comerciales en relación con la protección de algoritmos y modelos, es la frecuente rotación de ingenieros de software en el mercado tecnológico, siendo este campo limitado y de alta demanda [6]. Consecuencia de lo anterior, la rotación de especialista es alta, lo que dificulta la distinción entre la divulgación de los secretos comerciales de un trabajo anterior y los conocimientos adquiridos a través de la experiencia laboral [7].
En segundo lugar, la existencia de ML de ingeniera inversa, es decir, de sistemas que deconstruyen otros sistemas para revelar sus diseños o extraer información del mismo, pone a los secretos comerciales en desventaja, ya que es posible usar estos sistemas y develar algoritmos y modelos sin ser divulgados, agregando además el hecho que es posible que la tecnología sea adquirida lícitamente de forma independiente.[8] En vista de estos inconvenientes, las empresas tecnológicas básicamente se han visto obligadas a patentar una parte de sus algoritmos y modelos.
Patentes y machine learning (ML).
Los sistemas de patentes y en general las normas sobre propiedad industrial se encuentran armonizadas y estandarizadas a nivel global. Comparten los mismos principios y normas básicas, basados principalmente en el Convenio de París y el Acuerdo sobre los ADPIC, por lo que por ejemplo, las normas sustantivas europeas son las mismas que las chilenas.
Los titulares de sistemas de AI se han visto obligados a patentar algoritmos y modelos de ML en aquellos casos en que los secretos comerciales son ineficaces, también son parte de políticas internas de patentar y licenciar libremente evitando potenciales conflictos. En consecuencia, existe un creciente interés por este tipo de protección por parte de particulares y entes públicos.
Al respecto, la totalidad de los países desarrollados han creado políticas de incentivo para el registro de patentes de sistemas de AI, como una forma de fomentar la investigación y la inversión de empresas extranjeras.
La ley N° 19.039 sobre propiedad industrial en el artículo 31° define como invención a “toda solución a un problema de la técnica que origine un quehacer industrial. La invención podrá ser un producto o un procedimiento o estar relacionada con ellos”. En general en el derecho comparado no existen muchas legislaciones que definan una invención ya que es un concepto en constante cambio y definirlo es limitarlo.
Por su parte, el artículo 38° de dicho cuerpo legal, indica las materias que no son patentables, tales como, descubrimientos, teorías científicas, métodos matemáticos, sistemas, principios o planes económicos, financieros, comerciales, de negocios o de simple verificación y fiscalización; y los referidos a las actividades puramente mentales o intelectuales o materias de juego. En estas materias excluidas hay un denominador común y es que en ellas, la actividad inventiva está ausente.
Como es posible apreciar dentro de las materias no patentables están precisamente los modelos matemáticos, es decir, tanto algoritmos como modelos de ML están excluidos de patentabilidad. Al respecto, el Reglamento de la Ley 19.039 señala específicamente que los métodos matemáticos se encuentran excluidos de patentabilidad acuerdo al artículo 37° letra c) cuando se intente proteger explícitamente como categoría un producto de programa computacional (software), o un método matemático o un algoritmo que ejecuta sus procesos, o también lo anterior cuando se implementan en un sistema computacional convencional.
Esta norma de exclusión está presente en todas las legislaciones, no obstante debido al auge del ML se han implementado en muchas de ellas, modificaciones e interpretaciones a sus normas para que los sistemas de IA puedan acceder a registros de patentes.
Así por ejemplo, la Oficina Europea de Patentes (EPO) en el año 2018 publicó una versión actualizada de las «Directrices para los examinadores de patentes», que modificó completamente las normas para interpretar las exclusiones de patentabilidad de los modelos matemáticos. En consecuencia, la nueva interpretación establece que si una solicitud de patente se basa en un método matemático que implique el uso de medios técnicos como un ordenador, no puede ser excluida de la patentabilidad siempre y cuando tenga un carácter técnico en su conjunto.
Para este fin, el modelo matemático debe producir un efecto técnico que cumpla una función técnica, mediante su aplicación a un campo de la tecnología y/o su adaptación a una aplicación técnica específica. Además, se requieren requisitos adicionales como un propósito técnico específico, limitándose funcionalmente a la finalidad técnica, para lo cual debe existir un vínculo suficiente entre el objetivo técnico y los pasos del método matemático, por ejemplo, especificando cómo se relacionan la entrada y la salida de la secuencia de pasos matemáticos con el objetivo técnico, de modo que el método matemático esté vinculado causalmente a un efecto técnico[9].
Estas normas establecen altos estándares de divulgación específicas, que los titulares de ML deben cumplir para acceder al registro de una solicitud de patente, por lo que se puede obtener información relevante sobre su funcionamiento, complementada además con patentes del estado del arte cercano que pueden ser elementos aportantes a la transparencia tantas veces requeridas por estos sistemas. La información de la gran mayoría de las oficinas de patentes es pública y están disponibles de manera online, por lo que obtener este tipo de información es relativamente sencillo.
[1] Source Code Definition by The Linux Information Project», Linfo.Org, 2001, http://www.linfo.org/source_code.html
[2] «Object Code Definition», Linfo.Org, 2007, http://www.linfo.org/object_code.html.
[3] Jean-Marc Deltorn and Franck Macrez, «Authorship in the Age of Machine Learning and Artificial Intelligence», SSRN Electronic Journal, 2018.
[4] Jin Hyunjong, «Think Big! The Need For Patent Rights In The Era Of Big Data And Machine Learning», Jipel.Law.Nyu.Edu, 2019, https://jipel.law.nyu.edu/vol-7-no-2-3/.
[5]»What Is Data Preprocessing? – Definition from Whatis.Com”, Searchsqlserver, 2005, https://searchsqlserver.techtarget.com/definition/data-preprocessing.
[6] The Battle For Top AI Talent Only Gets Tougher From Here», WIRED, 2017, https://www.wired.com/2017/03/intel-just-jumped-fierce-competition-ai-talent
[7] Un caso famoso que refleja esta cuestión es «Uber contra Waymo». Google Alphabet demandó a Uber por robo de secretos comerciales y competencia desleal argumentando que el ex ingeniero de Google, Anthony Levandowski, robó secretos comerciales relacionados con la tecnología de vehículos autónomos «Waymo» y llevó esos datos a Uber. La defensa de Uber se centró en el hecho de que el ex ingeniero de Google simplemente aplicó sus conocimientos y experiencia en el campo de los vehículos autónomos y no se pudo probar un robo de secreto comercial. Más detalles ver «Waymo V. Uber: Everything to Know about the Trade Secrets Trial», Fortune, 2018, https://fortune.com/2018/02/05/waymo-v-uber-what-you-need-to-know-about-the-high-stakes-self-driving-tech-trial/.
[8] “Is Reverse Engineering” Misappropriation of Trade Secrets? | JD Supra», JD Supra, 2020, https://www.jdsupra.com/legalnews/is-reverse-engineering-misappropriation-96161/.
[9] European Patent Office, Guidelines for examination in the European Patent Office, 2018, Munich: www.european-patent-office.org/legal/gui_lines/
[10] Hall Bronwyn, Patents, Innovation, and Development (May 10, 2020). Max Planck Institute for Innovation & Competition Research Paper No. 20-07, Available at SSRN: https://ssrn.com/abstract=3598855 or http://dx.doi.org/10.2139/ssrn.3598855
